Ubiquitous Computing Module II Assignment: Characteristics of Ubiquitous Computing

For last module's assignment, I proposed applying the principles of Ubiquitous Computing to the timetabling system for ASIO EduERP. In this module, I'll analyse what principles are lacking in the current system and what characteristics of UbiComp can be applied to it. In my last post, I showed a chart of ASIO's University Timetabling Module Principles. For reasons of added clarity and ease of use, I've re-drawn that chart in CMapTools:

I have color-coded the chart as follows: orange represents system modules, blue represents user input and green is the human-readable data we are most interested on, the calendars. Analyzing the chart, we see some interesting design decisions. The system lacks considerably in transparency, forcing users (students, teachers and administrative staff, weirdly identified as "Timetables" in the chart, as if they are not actual people but simple "timetable-spewing-sources") to approach the system to feed and to receive information from it. This is a symptom of system-centric design, as opposed to a user-centric design approach. These personas (student, teacher, staff), as defined in Blonkvist, 2002, allow us to understand that different users have different interests and, therefore, approach the system with different outcomes in mind. By taking behavior into account, we are better equipped to allow information to dissolve into behavior (Greenfield, 2010). To decrease opacity, we must remove (at least some of) the cognitive effort of interacting with the system (Kuniavsky, 2010). I have then re-jiggled the chart, without adding any other modules, but re-imagining the relationships between them:

In this new relationship map, users (Students and Teachers) approach the system directly through the data they are most interested in, namely, their personal calendars. These context-aware calendars are completely tailored to the target user's needs, accessible though their media of choice (web, device or desktop calendar application), allowing for a Bring Your Own Device philosophy (Ballagas et al, 2004). Changes the users apply to their calendars are then routed through the underlying system modules, validated, and returned to the users, transparently, as simple confirmation or error messages, according to the availability of the chosen options. This way, there is a layer separating the human context of the user from the ICT context (Poslad, 2011) of the system, in the form of the calendar. This awareness makes direct access to the underlying modules superfluous, albeit still possible (represented by light cyan arrows). A challenge that remains to be approached is how to integrate the third persona (staff) into this context-aware scenario, given that their relationship to the system does not happen through calendars, but through timetable entry and correction (represented by a dark orange arrow). Further investigation is needed to better integrate all usage scenarios into the fold, isolating the users completely from the system modules and creating a more transparent environment.

References

Blonkvist, S (2002). Persona – an overview. KTH Royal Institute of Technology.
Ballagas et. al. (2004). BYOD: Bring Your Own Device. UBICOMP 2005
Greenfield, A. (2010). Everyware: The Dawning Age of Ubiquitous Computing (1st ed.). New Riders Publishing.
Kuniavsky, M. (2010). Smart Things: Ubiquitous Computing User Experience Design (1st ed.). Morgan Kaufmann.
Poslad, S. (2011). Ubiquitous Computing: Smart Devices, Environments and Interactions (1st ed.). Wiley.