Ubiquitous Computing Module IV Assignment: Design Issues

In this post, I will try to analyse what are some of the issues the project of ubiqutifying ASIO EduERP might entail. By moving away from the centralized calendar website to the user's personal choice of calendaring application (be it on the web, on a mobile device, on a desktop or all of the above), we are basically inviting issues of multiple interfaces. There is no predictable point of entry, there is no single interface, but myriad apps with their own sets of features, constraints and limitations. The single most difficult thing, in this case, is knowing when a given feature is or isn't available to the user on his chosen platform - Can he accept/decline invitations?  Can he push changes back to us?

The safest route is to assume no interactivity whatsoever is available on his chosen platform, and implement all of them as web applets[1]: whenever there is need for user input, a simple, responsive website should be developed for the given input. Should the user's platform provide for that functionality, the website is redundant and can be ignored. Should it be needed, the user can resort to the web solution. Communications between system and user should use a widespread platform, such as email or text messaging (user's choice) containing human-readable information and links to the applet solution as well as the WebDAV content (computer-readable), so whatever context the user finds himself in (reading through his mobile device or desktop computer) he can take the appropriate action (open the web applet, receive the WebDAV link and let his application deal with it, leave the message for another time/context).

Likewise, the system should be able to issue and deal with redundant communication[2]. The existence of multiple points of entry dictates that at least some users will choose to, at different moments, use different interfaces for the same information. That must be not only be designed for, but even be encouraged. The system should, therefore, be able to deal with modal changes (some input coming from the web, other through WebDAV, etc) and sometimes modal redundancy (same input from different sources). These multi-modal inputs should never introduce new complexity, but should always simplify communication with the system. Instead of issuing arcane error messages, the system should just deal with it sending confirmation messages that sound like natural conversation (i.e. instead of saying "you reversed a given option", say "you seem to have changed your mind, are you sure?").

In this way, some of the following design issues are addressed: multiple interfaces, smartness, existing practices, feature parity, seamless of interaction and ubiquitous access. Understanding user's needs is also such an important feature that its lack was the main drawback of ASIO EduERP that inspired the creation of this project, so it is also (hopefully) addressed by it.

References:

[1] Hassler, V.; Then, O., "Controlling applets' behavior in a browser," Computer Security Applications Conference, 1998. Proceedings. 14th Annual , vol., no., pp.120,125, 7-11 Dec 1998.

[2] Stanciulescu, A., "A Methodology for Developing Multimodal User Interfaces of Information Systems", Ph.D. thesis, Université catholique de Louvain, Louvain, Belgique, 2008.