Ubiquitous Computing Module V Assignment: SWOT analysis and rough timeframe for implementation

BYOD for Asio EduERP/School calendaring

Strengths

• All required technologies are here, just not correctly deployed/integrated
• Easy to assemble a team experienced in development and interface design
• Direct interest of the University in improving the existing system
• Direct interest from users (students and staff) in integrating scheduling in their existing workflow

Weaknesses

• Not all stakeholders might see the use for the system (do not use computer based calendars etc)
• Multiple platforms make for very widespread testing platform (many opportunities for incompatibility)
• Might incur in unpredictable costs (large volumes of SMS messaging, for example)

Opportunities

• Create a de-facto standard for academic calendaring
• Synergies between service providers and universities can bring new partnerships
• Steer universities away from closed-sourced implementations in the future

Threats

• Asio is fully standards compliant, but closed-source, access to code might be impossible
• Asio has own closed source alternative: Asio Edu App
• Resistance to FOSS is still a reality in many Universities
• No sponsorship, no project
• Timeframe is very limited and inflexible - must work within the academic calendar

Rough Timeframe

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.

Ubiquitous Computing Module III Assignment: Enabling Technologies

In 2008, for the first time, laptop sales surpassed desktops [iSuppli]. Sometime between late 2013 [IDC] and 2015 [Gartner], tablets will surpass both laptops and desktops. These trends were made possible by the advances in power efficiency and computational capability predicted by Moore's law, and they are one of the driving forces behind BYOD (Bring Your Own Device), thanks to the fact that most people nowadays consider a portable computer to be their main computational device. This shift in behavior, especially in high-growth markets (such as Brazil, Russia, India, South Africa, Malaysia, Singapore and United Arab Emirates), has been blurring the lines between work and personal devices and between work and personal time [Ovum]. Another enabling technology that has great influence in BYOD behavior are wireless communication technologies. Wireless communication ranges from Near Field (NFC and RFID), passing through Personal Area (such as Bluetooth and Wireless USB), Local Area (Wi-Fi, RFID), Metropolitan (Wi-Fi, WiMAX, Muni Wi-Fi) and Wide Area (WiMAX, 3G and 4G telephony). Most of these technologies overlap and some even make use of one another (Bluetooth Smart or 4.0, for example, can use NFC to negotiate pairing and use Direct Wi-Fi to increase file transfer speeds), and are therefore part of the same IEEE standards family, 802.

Speaking of standards, one of the main forces of adoption of Internet protocols is the adherence to IETF (Internet Engineering Task Force) standards. The IETF is an open standards organization, mostly run by volunteers and with no membership requirements, but its standards are well regarded and taken into consideration by other standard organizations such as ISO and the W3C (the World Wide Web Consortium), responsible for HTML and related standards and Ecma International, the European Computer Manufacturers Association. WebDAV and related protocols are IETF standards, HTML is a W3C standard, JavaScript (in the form of as EcmaScript) has been standardized by ISO and Ecma; as has JSON, JavaScript Object Notation. Cerri and Fughetta (2007) classified standards in a gradation between closed, disclosed, concerted, open concerted and open de jure. Although none of the standards cited above reach the highest level of openness in Cerri and Fughetta, they do all belong to the open concerted definition, for they are all developed and managed by an official standardization body or by an open group or consortium. This allows everyone to implement solutions based on these standards, even to base their own standards on these.

The best way to develop a solution based on open standards and to ensure its implementation is through the adoption of Open Source Software. OSS provides for a reference implementation that can be replicated and easily audited by external parties, ensuring there are no implementation mistakes. It also allows for easier adoption, because its replicability leads to widespread dissemination (Davidson and Heineke, 2007).

These are the main enabling technologies and/or strategies that orient my proposed implementation of a ubiquitous solution: portable, wireless communication devices with low-power, high performance processors, in the form of the users own personal computing devices, Whenever possible, respecting the users own choice of software implementation is key, therefore the solution must implement open protocols and standards to allow the user to choose his own solutions to his scheduling and messaging needs. When there are no existing solutions on the client side, or when such solutions do not provide for all the needed functionality, Open Source implementations of standards-based solutions (such as dynamic web applications based on HTML, JavaScript and JSON) can supplement existing solutions without breaking users workflow (i.e. without forcing users to log into a specific website just to complete a given task). All the communication between existing solutions, functionality extenders and the underlying system should also happen using open protocols, allowing for rapid implementation by other educational organizations without forcing them to move out of their existing implementations (save when the organizations have no control over existing implementations, i.e. when they use commercial, closed-source software). This would allow for widespread adoption, not only by users served by ASIO such as the staff and students of Tallinn University but also by other educational institutions.

References:

• Cerri D, Fuggetta A. Open standards, open formats, and open source. J Systems Softw 2007;80(11):1930-1937.
• Davidson SM, Heineke J. Toward an effective strategy for the diffusion and use of clinical information systems. J Am Med Inform Assoc 2007;14(3):361-367.

Bonus round: analysis of existing competing solutions

Fedena is an open source, web-based student information system developed in India for the government of Kerala. It is built on Ruby on Rails and allows for the development of plugins. It is entirely used via a web browser also has the ability to communicate with students, parents, teachers and staff via SMS and but is otherwise unable to integrate with users mobile systems, such as calendaring.

SchoolTool, likewise, is an open-source SIS written in Python and completely web-based. It is included in the Edubuntu Linux distribution. Besides being web-accessible, it is also able to import and export most of its data as Excel spreadsheets and CSV (comma-separated values), but it cannot communicate in real-time with other calendaring systems.

OpenSIS is another open-source SIS, based on PHP and MySQL. It is available as a free community version, has premium paid upgrades and integration features and is also available in a Cloud SaaS (Software as a Service) version. Although premium versions integrate to other systems such as Moodle, OpenSIS also has no BYOD provisions.

SIMS is the closed-source School Information Management System developed for use in the United Kingdom. Although it is commercial, closed-source software, it was paid for by the Bedfordshire County Council and enjoys 80% adoption in the England and Wales. It is based on Microsoft SQL and accessible via web through Microsoft SharePoint. Although the British Educational Communications and Technology Agency has established an Interoperability Framework for British Schools, SIMS does not implement it.

Of all systems mentioned above, probably only SIMS users would have a hard time implementing a standards-based communication and collaboration platform for BYOD, a problem it shares with ASIO EduERP itself, since it is also a closed-source, commercial solutions.

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.

Ubiquitous Computing Module I Assignment: a design and development scenario for the implementation of ubiquitous technology

My first challenge, certainly, was bringing the focus to a palpable, quantifiable problem. I (and I believe most people who even knows the concept of ubiquitous computing) still tend to think of it as a pie-in-the-sky, all-or-never concept, in a 'the status quo of computing is this, but it should actually be like that' way. Finding a single application where ubiquitous computing principles are poorly applied proved elusive for a while, and then it hit me.
Most people reading the blog post are current users of Student Information Systems. The purpose of these systems is to handle student information, class schedules, classrooms assignments, academic progression, discipline and so many other school administration subjects. Even though the name leads you to think that such systems are supposed to hand information over to students, most of these systems are built around a school administration workflow, leaving two of the most common users out of the development loop: students and teachers.
Now you must be thinking 'where does this guy take such preposterous ideas?', especially if you are part of school staff. Let us look at a chart from Asio EduERP, the Finnish/Estonian system we use here at Tallinn University, shall we?

Look at how the workflow is presented. Students and teachers are peripheral data-sources, not central parts of the system. You may say that is just a stylistic decision, but it reflects a development philosophy where these users needs are not taken into consideration.  Let us consider this screenshot of the resulting calendar of a given student, as output by Asio:

 

I'll give you time to search for all the export options on this screenshot. Did you find one? Maybe the little printer button on top of the agenda, and that's it. Tell me: when was the last time you printed a school calendar, 1998? Adding insult to injury, Asio/ÕIS requires Firefox or Internet Explorer to run. No explicit Webkit support means no Chrome, Safari, iPhone, iPad or Android support. In my research of several different SIS (OpenSIS, SchoolTool, QuickSchools, SIMS, etc) I found a single one that had any mobile support: Fedena, developed in India as the basis for Sampoorna, the system that centralizes information on all 15,000 schools of the state of Kerala.

So what do I propose? I believe the simplest, most cost-effective solution to the over-centralization of SIS in general and of Asio/ÕIS in particular would be the use of WebDAV extensions to its various input/output systems. WebDAV is an IETF standard expansion of HTTP built to facilitate collaboration in managing web systems. It describes methods of sending data back to web servers, turning HTTP into a two-way protocol. It is also the basis of CalDAV and CardDAV, the protocols used to synchronize calendars and contact lists between web services and mobile devices. By implementing WebDAV into a SIS a teacher could, for instance, have his Google Calendar update automatically when new classes are scheduled, or negotiate conflicts if he has a personal appointment that impedes his appearance in class. Students could be instantly notified on their mobile phones or laptops when a class is up (or moved), and even receive invitations to classes they showed interest in and 'RSVP' to those classes, instead of having to log into to system every time they need to review information, then manually input all that data into their calendar or class scheduling application of choice. It is a simple solution that accommodates the growing tendency of BYOD (Bring Your Own Device) while taking into consideration the principles of modern ubiquitous computing philosophy.