Context classification for device-independent Web-Applications
Positioning Paper for the W3C Workshop on Delivery Context
by Cedric Ulmer, Markus Lauff, Axel Spriestersbach
Axel Spriestersbach The amount of web-based information and applications in company intranets makes it hard for professional users to retain an overview on information necessary for completing their work. Portal software like the mySAP Enterprise Portal provides the user with a selection of intranet and WWW content tailored to the professional needs.
Roles (e.g. your role as employee and developer within your company) and user profiles helped improving user satisfaction in accessing information. Including more context will become important for better customer satisfaction in adapting applications to the user's needs. The arrival of portable devices with reduced or different usability from typical computer screens also emphasises the need of more relevant context information to ease the use of applications on such devices.
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 is often defined by and for experts in a certain context area. Thus these definitions are often very detailed and purely technical.
For instance the WAG UAProf  implemented in CC/PP includes device information down to the resolution of the screen. For application development that is dependent on the screen size, changes to the user interface for every of these devices would be necessary. Considering the amount of devices available today this means a lot of alterations.
Application development without any abstractions is inefficient and expensive and only a few applications will be built and deployed.
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 .
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 ) 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.
In this paper we illustrated the need for abstractions from physical devices and classifications into device classes to ease application development. We also voted for including non-technical issues in context descriptions. In an upcoming project we will be focusing on usability classification and development support for device independence. Therefore we believe interaction with the Delivery Context working group would be of mutual benefit. Plus, the point of view of an application programming company such as SAP could positively influence the way context experts will create requirements for Context Delivery.
 mySAP Enterprise Portals, SAP-AG,
 A. Spriestersbach, H. Vogler, F. Lehmann, T. Ziegert, "Integrating Context Information into Enterprise Applications for the Mobile Workforce - Case Study", Mobile Commerce Workshop MOBICOM 2001.
 Device Taxonomy,
 VoiceXML Forum,
 WAG UAProf, Proposed Version 30-May-2001, Wireless Application Protocol Forum Ltd.;