Automatically generating personalized user interfaces with Supple
Representing interfaces, devices and users
Download 5.78 Mb. View original pdf
|
| 3. Representing interfaces, devices and users Like other automatic user interface generation systems, Supple relies on an interface specification ( I) . Additionally, Supple also uses an explicit device model ( D) to describe the capabilities and limitations of the platform for which the interface is to be generated. Finally, in order tore ect individual differences among usage patterns, Supple additionally includes a usage model, represented in terms of user traces ( T ) . We describe each of these components below. 3.1. Functional interface specification ( I) Supple adopts a functional representation of user interfaces—that is, one that says what functionality the interface should expose to the user instead of how to present those features. Like a number of previous systems (e.g., [1,57,62]), Supple represents basic functionality in terms of types of data that need to be exchanged between the application and the user. Semantic groupings of basic elements are expressed through container types, which also serve as reusable abstractions. This is in contrast to several other systems that use task-oriented specification languages (e.g., [67,81]), which try to capture the logical activities performed with the user interface by representing not only user interface objects, but also the dependencies among them. By specifying user interfaces at a higher level of abstraction, task-oriented languages allow for greater flexibility in generating concrete user interfaces from any abstract specification. For example, a hotel reservation interface can be instantiated as a step-by-step wizard for novice users or as a single view for hotel registration staff and travel agents. We chose not to adopt this task-oriented approach for two reasons. First, because task-oriented descriptions are typically first compiled into a data-oriented functional description [67], our use of a functional specification does not preclude a future use with a task-oriented system. Second, task-oriented languages are particularly useful for capturing task-oriented processes such as store checkout or making a hotel reservation. Most direct manipulation systems, however, support abroad range of possible tasks and make simultaneously available numerous reversible actions. Such interfaces would not benefit significantly from a task-oriented representation. To illustrate our approach, the upper part of Fig. 1 shows the formal specification of the interface fora simple application for controlling lighting, ventilation, and audiovisual equipment in a classroom. Formally, an interface is defined to be I ≡ S f , C I , where S f is a tree of interface elements, and C I is a set of interface constraints specified either by the designer at design time, or by the user at run time through Supple’s customization mechanism (Section The interface elements included in the functional specification correspond to units of information that need to be conveyed via the interface between the user and the controlled appliance or application. The interface constraints can, in principle, constrain any aspect of interface presentation. In practice, we rely on the following three classes of constraints: • equality constraints, which allow multiple instances of the same type (for example, all three lights in the Classroom interface in Fig. 1) to be rendered identically; • constraints limiting the set of presentation options for an element, which allow the user, for example, to use the customization mechanism to constrain light intensity to be rendered with a slider or to forbid the use of tab panes at the top level of the Classroom interface; • interdependence constraints (for example, a stylistic requirement that a checkbox cannot be rendered as the sole element inside a tab pane). The elements in the functional specification are defined in terms of their type. There are several classes of types: Download 5.78 Mb. Share with your friends:
|