Technical Requirements for a
Delivery Context Independent User Interface Model

Position Paper for the W3C Workshop on Device Independent Authoring Techniques
Sep. 25-26, 2002, SAP University, St. Leon-Rot, Germany.

Gottfried Zimmermann, Gregg Vanderheiden
zimmer@trace.wisc.edu, gv@trace.wisc.edu
Trace R&D Center, UW-Madison, USA


Abstract

This position paper describes technical requirements for user interface models which can be used to construct concrete user interfaces (in real time) that match the preferences and constraints of users. These constraints can be the result of the device the user is currently employing, the abilities (or disabilities) of the user, or the user's current environment. These requirements can be used to identify authoring techniques for specifying user interface models that can be rendered into a wide variety of user interfaces as appropriate for specific delivery contexts.

This paper focuses on requirements. At the workshop, the authors also intend to share preliminary ideas and concepts to meet these requirements, as currently being discussed within V2. V2 is a technical committee of ANSI / INCITS (InterNational Committee for Information Technology Standards) that is working on an alternative interface access standard including a specification for a Universal Remote Console.

Introduction

The goal of a Universal Remote Console (URC) is to let people use a single personal device to control arbitrary (compatible) electronic devices and services (collectively called targets) by harnessing standard protocols and formats that work across a broad range of targets and access devices. The URC could be any access device that is tailored to the user's needs. The URC may employ any of a wide variety of output and input techniques, including graphical, audio, or tactile output; and keyboard, mouse, switch-based or stylus input, voice or gesture recognition; or any combination of these. It may also be limited to only one input and one output form (e.g. only keyboard input and text output).

The requirements for accommodating a variety of user access devices are similar to the requirements for providing access to a variety of users, including users with disabilities. This paper defines technical requirements that are common for both scenarios.

Some of the requirements described are touched on in the "Authoring Scenarios for Device Independence" [1]. This paper aims to view these and additional requirements from a perspective of how they apply to target services as well as to target devices.

Requirements

1. Baseline model across all access devices and users

The user interface model should include a baseline model that is ideally usable as a "greatest common denominator" across all delivery contexts (access devices, users, and use environments). The baseline model provides the essentials for a functional presentation (as defined in [1]) of a target device or service, and can be used as a fall-back solution if there is no specialized user interface model available for a specific access device and/or user group.

The baseline model contains only modality-independent information, i.e. electronic text, which can be rendered in any modality. It must not contain any assumptions regarding specific input or output capabilities of the access device, nor regarding the user's preferences and abilities.

It must be possible to deliver only the baseline solution to the access device as a flexible and cost-effective user interface model, thus increasing the applicability and generalizability, and accommodating a wide variety of access devices with minimum requirements on the target manufacturer.

The baseline model has to be provided by the manufacturer or provider of a target device/service.

2. Customized model for specific access devices and users

Although the baseline model provides full (with the modality-specific exception) access to the functionality of a target, users might find it more appealing and more efficient to use a customized presentation (as defined in [1]), i.e. a user interface that is more tuned to their preferences and the specific capabilities of their access device. The customized model typically includes

Customized user interface models for specific devices and users may be defined by the manufacturer or provider of a target, or by third parties.

Note: Some target devices or services may be inherently inaccessible to some users or access devices even though all of the targets' controls and operational displays are made accessible either by the baseline or the customized model. For example, an LP record player can be designed to be fully operable by someone who is deaf but they cannot access the music that it generates. The baseline model may not be able to affect content which is displayed by a product but not generated by it. There may also be activities which cannot be made accessible in a fashion that would allow them to be used successfully in real time (e.g. flying a jet fighter, competing in a Dutch auction).

3. Internationalization

The user interface model should be easily localizable for different countries. This should include the translation of text as part of the baseline or customized model, the replacement of user interface elements such as images, animations, and pronunciation information, and the adaptation of country and language dependent data formats (such as date, time, numbers, and currency). Consequently, internationalization may also include the modification of high-level information, such as rearrangement of the layout, in order to reflect changes in text lengths and text orientation, or cultural differences in color coding.

One implication of the easy location requirement is that a localized user interface model can be provided by a third party as an add-on to the user interface provided by the target's manufacturer or provider.

Another implication is the distinction between transmission data formats and localized data formats, for both input and output. This includes formats for date, time, numbers, and currency, but also identifiers for selected items from a list of localized strings, for example. It is the responsibility of the user agent to provide the necessary translation from transmission data formats to localized data formats, and vice versa.

4. Natural language interfaces

The support for natural language interfaces is a direct result of the baseline model which provides the semantic information necessary for natural language access.

Additional support for localization, colloquial terms, etc. is available through online-dictionaries, and thesauri.

5. Adaptable and self-adapting user and device models

The user interface model should support the ability of advanced user agents to adapt themselves according to the needs and preferences of users and their environments. This includes dynamic changes on the user interface made by the user during a session, as well as self-adaptation of the user interface by learning from the user's behavior. For example, a user could ask their TV "What is the weather forecast for tomorrow?" Let's assume there are two channels available that broadcast weather information, so the TV could ask back which of the two channels the user wanted. Then, the user's preference for weather channels could be used later for disambiguation of similar situations.

In any case, the adaptation should be made persistent for subsequent sessions with the same user, if appropriate. An adaptation made for one user may even apply to all users in a certain user group whose members trust each other.

Specific representations for user interface elements should bear sufficient information about themselves (metadata) so that intelligent user agents could use this information in assembling a customized user interface on the fly.

6. Layered help

Layered help denotes the concept of providing help information in pieces, usually starting with short help items, and then constantly increasing the detail level provided. The user controls how deep they want to immerse themselves into the layers of available help information.

It should also be possible to reference other help items in the content of a help text item.

7. Web services for assistance

The user interface model should make it possible for the user agent to employ Web services for support in rendering specialized user interfaces, or employing specialized interaction techniques.

For example, a user agent may use a translation web service for translating a user interface into a different language on the fly. Another example is the use of natural language processing web services in order to provide natural language user interfaces for mobile user agents.

Web services could also be used to provide users with a variety of different user interface styles or skins for particular targets and/or access devices.

8. Make user interface design easy

The user interface model should allow for sophisticated authoring tools for user interface design which allow the designer to specify a device and user specific user interface, but at the same time infer an appropriate baseline model to be used with any device and any user.

This might include test tools to check for completeness of a baseline model. These test tools could be integrated into authoring tools to allow for efficient methods of support during the design phase.

References

[1] Lewis, R. (2002). Authoring Scenarios for Device Independence. Informal public draft of possible W3C Note. 29 July 2002. Retrieved, Sep. 6, 2002, from the WWW: http://www.w3.org/2001/di/public/as/as-draft-20020729.html.