Context classification for device-independent Web-Applications

Introduction

Unfortunately context-aware applications do not come for free. Application development needs to take into account context while designing and implementing applications. To ease that, requirements from application development need to be considered when designing context frameworks. Our contributions to the workshop are requirements from the application developer's point of view on context delivery and on how to apply context to applications especially for the professional use. Of special interest are abstractions necessary for efficient application development of context-aware application.

Context abstractions

Very often, details do not mean anything to application programmers as they are processes experts, and most likely they have only very little knowledge about a specific context area.
As an example a context expert for mobile devices knows that a certain screen size entails changes to the user interface, for instance splitting the application across multiple screens, but the application developer might not be aware of that.

There are several solutions to this situation. You might want to educate application developers to become context experts or include context experts to the development process, but while this makes perfect sense in some cases, it becomes very expensive in the general case.
In summary we faced two major challenges during recent application development. The high level of technical details is of little use for application development, since it is simply too expensive to deal with all these details and that pure technical abstraction seems inappropriate. We believe that a different kind of abstraction might help handling the amount of alterations and reduce the level of details.
Application developers and context experts should jointly create abstractions that include experts' knowledge from context and software development. Therefore we strongly encourage the development of a device classification, as proposed in the device taxonomy discussion [3].

Device classes are abstractions from physical devices, depending on their similar behaviour. But what is the similar behaviour?
There have been many attempts to classify devices by pure technical means. These often lead to device classes with devices gathered by display size as Palm-size, Phone-size.
But is user interaction with a mobile application really an issue of pure technical features of a device?
Consider an example here. Assume that we build a mobile application for two different "devices": a voice (e.g. VoiceXML [4]) and a WAP (Wireless Application Protocol) application. These applications are obviously different "devices" from a technical point of view. While the voice solution is based on a server based voice browser and VoiceXML, the phone has a build-in browser and uses WAP. From a pure technical classification you would not put them into a single class.

But an alternate way of comparing devices from a usability viewpoint is to consider a task and the speed for the completion of that task.
A selection from a list of alternatives (e.g. a selection list) is such a task. Let's assume that we know from psychology research that the human brain is able to hold up to approximately seven pieces of information. So for the task there should not be more than 7 options at a time, since both "devices" cannot display more than seven options at a time.
Let's assume that when comparing the time for the completion of the task we find that the time a user needs for the selection is about the same for both devices.
Therefore the two devices share the same behaviour for the task of selection and would be in the same device class from a usability perspective, but in different classes from a technical perspective.

We propose to group them by their usability behaviour rather than the technical features and vote for including other "soft" parameters as well. This is especially true since - as we all know from experiences with WAP - usability is a very influencing factor in developing applications. We think that by developing applications with device classes in mind and some device-independent authoring technology we might be able to build applications that remains usable for all physical devices within a device class.

Conclusion

References