Cameleon Reference Framework

The Cameleon Reference Framework decomposes user interface design into a number of different components that seek to reduce the effort in targeting multiple contexts of use.

The Cameleon Reference Framework

Domain Models

These focus on the information handled by the application. The domain models define the data types for properties and methods accessed by the user interface. These can be annotated with information on defaults and constraints. Domain models are generally speaking specified by an information systems specialist based upon the business requirements for the application. One approach to representing domain models is with UML diagrams, another is to use an interface definition language such as WebIDL supplemented by annotations defining integrity constraints.

Task Models

These describe the tasks that the user and the system carry out to achieve the application's objectives. The tasks are described at a high level that is independent of how these are realized on a particular platform. Tasks can be decomposed into subsidiary tasks. You can express ordering constraints and preconditions, e.g. where some tasks need to be carried out before others. Tasks can be marked as being relevant for specific classes of platforms, e.g. desktop computers with large displays that make it practical to offer a wider range of marketing options as compared to the more focused approach needed for devices with smaller displays. Task models make it easy to discuss the application behavior without getting distracted by the details of the user interface. A meta-model for tasks based upon the ConcurTaskTrees (CTT) notation is available as a Working Draft from the MBUI Working Group.

Abstract User Interface

These are models of the user interface that are independent of the choice of platform and of the modes of interaction (visual, aural, tactile). An example is the Abstract UI component for selecting a value from an enumeration. The Abstract UI models can be annotated with such details as whether a feature is frequently used or best left for the advanced user. You can indicate that one part of the user interface is relevant only if some precondition holds. An editor's draft for the meta-model for the Abstract UI is available from the MBUI Working Group.

Concrete User Interface

These model the user interface for a given platform, e.g. desktop PC, tablet, smart phone, connected TV and so forth. As an example, you could specific that a selection is to be made with a set of radio buttons, or as a drop down list. You can construct the user interface from standard controls, or you can make use of custom controls where needed. These have to be defined by skilled developers due to the level of detailed technical knowledge involved. The Concrete UI includes layout policies, e.g. vertical, horizontal or grid, but the details of the styling are left to the UI skins that are applied when generating the Final UI.

Final User Interface

These are created for a specific class of device, e.g. an iPhone, or an Android tablet. The Final User Interface is generally created automatically by the authoring tool, taking into account the user interface skins selected by the designer. This frees UI designers from having to deal with the details of each class of device, e.g. the JavaScript or CSS tweaks needed for a given browser on a given device. Such details are left to specialist programmers. Examples of targets for the Final User Interface include HTML5 for web browsers, Java for desktops, J2ME for feature phones, iOS and Android for smart phones and tablets.

Context of Use

This covers user preferences, the kinds of platforms the application will be deployed on, and environmental properties that the application can be designed to adapt to, e.g. device orientation, the ambient light and noise levels, the remaining battery level, the device location and so forth. The user interface skins control how the concrete user interface is mapped into the final user interface. At run-time adaptation may be handled locally by the final user interface, e.g. via a web page script that responds to changes in ambient light levels to switch between a day time and a night time color scheme. For Web applications another possibility is to track the context of use on the server in conjunction with a cloud-based adaptation engine that sends updates to the user interface to the client.

Using the Cameleon Reference Framework in Authoring Tools

At the time of writing the Cameleon Reference Framework has only been implemented in research tools such as UsiXML and MARIA. These take a top down approach where you start with the Domain models, then create the Task models, and proceed to create the Abstract UI and then the Concrete UI before generating the Final UI. The models for successive layers can be initialized automatically using transformations, e.g. expressed as XSLT scripts that embody design knowledge. Designers can then adjust the models as needed, but are responsible for adjusting higher level models to keep then in synch.

Many designers prefer to work at the Concrete UI level, starting with a low fidelity version of the user interface that blocks out the design, e.g. with placeholder text such as Lorem ipsum dolor. This allows for discussion with the customer commissioning the app without getting side tracked by the details. There is a need for automated support for propagating changes from the Concrete UI level up to the Abstract UI, Domain and Task models, and back down to other platforms at the Concrete UI level. Techniques for achieving this are still at the research stage, and are focusing on constraint based search through the design space. Note that the mapping from the Abstract UI to the Concrete UI involves design knowledge about layout, and relies on information about the size of UI controls taking into account the text used for labels.

Relationship to Localization

It is increasingly important to be able to deliver applications in multiple human languages, both within a single country and also when addressing an international audience. Effective authoring tools reduce the effort involved in localizing applications which effects styling and image resources as well as text. Model-based techniques need to support localization at the different levels of the Cameleon Reference Framework.

Relationship to Accessibility

There are many kinds of impairments and this complicates designing accessible applications. It is something that has to be considered from the start of a project and not just tacked on at the end. Model-based techniques can simplify the effort involved through preserving the relationships between different levels of abstraction. This can then be used to annotate the Final User Interface in ways that can be exploited by assistive technologies such as Braille readers. For HTML, this involves annotating the object models using WAI-ARIA, which describes how to add semantics and other metadata to HTML content in order to make custom user interface controls and dynamic content more accessible. Effective model-based authoring tools can apply such annotations automatically, as well as helping to ensure that image, audio and video resources are complemented by the appropriate accessible descriptions.

Graphical user interfaces typically involve user interaction events such as key up/down, mouse click and mouse move. These are at a low level of abstraction and specific to particular classes of device. IndieUI Events is an abstraction between physical, device-specific user interaction events and inferred user intent such as scrolling or changing values. This provides an intermediate layer between device- and modality-specific user interaction events, and the basic user interface functionality used by web applications. The idea of there being events at different levels of abstraction fits nicely into the Cameleon Reference Framework, and the ability to specify behavior cleanly at each level of abstraction. The IndieUI Working Group is also working on providing web applications with the means to get information about user needs and preferences, see the editor's draft.

References

1. G. Calvary et al. The Cameleon reference framework, The Cameleon project, 2002.