Balance General Desde el Propio Sujeto Analizando

A large amount of user interface modeling approaches has been proposed over the years from different directions. Early examples of declarative languages allowing the abstract specification of user inter- faces can be found in 1985 with Cousin [Hayes et al.85] and ADM [Schulert et al.85]. They evolved toModel-Based User Interface Development Environments(MB-UIDE) which used different kinds of models to guide the developer from abstract specifications to the final user interface. Figure 4.1 shows the model-based development process and the common kinds of models according to overview papers like those by Szekely [Szekely96] or da Silva [da Silva00].

The most abstract kinds of models commonly used are task model and domain model. Thetask

modelspecifies the tasks which are activities either by the user or the system which have to be ac- complished to reach the user’s goals. Examples for kinds of task models areCTT (ConcurTaskTrees, [Paternò et al.97, Paternò99], see section 4.1.2) orTKS (Task Knowledge Structure, [Johnson and Johnson89, Johnson91]). An overview on task models is provided in [Limbourg et al.01].

The domain model(also called application model ordata model) specifies the structure of the application logic. It can be specified for instance in terms of a UML class diagram or an Entity- Relationship Diagram [Chen76].

The Abstract User Interface Model (AUI) is specified based on the task model and the domain model. It is sometimes composed of anabstract presentation modeland adialogue model. It spec- ifies the user interface in an abstract and platform-independent way in terms of abstract interaction objects. Abstract Interaction Objects(AIO, introduced in [Vanderdonckt and Bodart93]), sometimes also calledinteractors, are user interface objects which enable the user for instance to input data or select an object on the user interface. They can be seen as an abstraction of widgets and are indepen- dent from any visual representation, platform or modality. The AIOs are grouped intoPresentation Units(also calledPresentations, Views, orInteraction Spaces) which can be seen as the abstraction of a window in a graphical user interface. For the abstract presentation model, no common diagram used throughout different approaches exists.

The dialogue model specifies the dialogue how to interact with the AIOs. It can be specified for example in terms of State-Transition diagrams [Wasserman85], or Petri Nets [Palanque et al.93]. An comparison of different possibilities for modeling the dialogue is provided in [Cockton87]. Some approaches use only the task model, or a refined version of it, to specify the interaction and do not use an additional dialogue model. Thus, the term abstract user interface model refers sometimes to the abstract presentation model only.

Finally, theConcrete User Interface Model(CUI) realizes the AUI for a specific modality in terms of concrete widgets and layout.

While most existing approaches and tools comply more or less with this general framework, the concrete kinds of models and diagrams used by them varies significantly. Several surveys list and compare the models used in the different existing approaches, e.g. Griffiths [Griffiths et al.98], Schlungbaum [Schlungbaum96], daSilva [da Silva00], and Gomaa [Gomaa et al.05]. In addition, [Limbourg04] compares various approaches regarding further properties like mappings and trans- formations between the models and methodological issues. MB-UIDEs surveyed in at least three of these comparisons are ADEPT [Markopoulos et al.92], AME [Märtin96], FUSE [Lonczewski and Schreiber96], GENIUS [Janssen et al.93], HUMANOID [Szekely et al.92], JANUS [Balzert95], MASTERMIND [Szekely et al.95], MECANO [Puerta96], MOBI-D [Puerta and Maulsby97], TADEUS [Elwert and Schlungbaum95], Tealleach [Griffiths et al.99], TRIDENT [Bodart et al.95], and UIDE [Foley et al.91]. Altogether, 34 approaches were compared. This shows that there exists a really large number of relevant proposals. The missing common agreement about the best models and diagram types to be used is one of the main problems of MB-UIDEs [da Silva00, Clerckx et al.04] and might be one of the reasons why user interface models have not gained stronger popularity until now.

Even if user interface modeling has not become widely established until now, paradigms like Ubiquitous Computing [Weiser99] or Ambient Environments [Wisneski et al.98] which strongly in- fluence the Human-Computer Interaction area might significantly increase the importance of user interface modeling: Future applications are expected to run on various different devices, like mobile devices, public displays or computers embedded into items of every-day life. Moreover, expectations include that users will be able to seamlessly switch applications between devices and be able to share information everywhere they are. To provide the desired degree of usability, applications must be able to adapt to the various contexts of use which includes the user, the devices, and further influencing properties of the environment like the user’s location [Schmidt et al.99, Coutaz and Rey02]. In such a scenario it will be very difficult to design the user interfaces for all the different contexts and devices by hand. Moreover, an application’s user interface should be able to adapt to new kinds of devices and contexts of use which have not been prospected at design time. Thus, it will be necessary to specify user interfaces on a higher level of abstraction from which the user interfaces adapted to the current context can be derived. User interface models will then play an essential role [Myers et al.00].

Current approaches in the user interface modeling area focus on such capabilities. As a result, the general MB-UIDE framework from figure 4.1 has been extended by the CAMELEON reference framework [Calvary et al.03] shown in figure 4.2. It adds generic models required to capture the context of use of the application likeuser model, platform modelandenvironment model. Theevo- lution model specifies the how the application switches between different configurations according to relevant context changes. The transition modelspecifies how these transitions between different configurations should be performed avoiding discontinuities between them. These models, together with the task model and the domain model (here: concepts model) are the initial models which have to be specified by the modeler during the design process. From these models the specification of Tasks-and-Concepts, Abstract User Interface and Concrete User Interface is derived.

Context 2 Context 1 Platform User Environment Transition Evolution Concepts Tasks Concepts and Tasks Abstract UI Concrete UI Final UI for Context 1 re ificatio n/abstrac tion Translation Platform User Environment Transition Evolution Concepts Tasks Concepts and Tasks Abstract UI Concrete UI Final UI for Context 1 re ificatio n/abstrac tion

Figure 4.2: The CAMELEON reference framework according to [Calvary et al.02, Calvary et al.03]

different contexts. The vertical transformations specify the refinement of specifications during the design process. The reference framework explicitly allows starting the development process on any level of abstraction as well as a flexible order of transitions between levels of abstraction because many approaches are not strictly top-down or support reverse engineering steps. [Calvary et al.02] examines several existing approaches in terms of the framework. Furthermore, a general schema for the application’s context-sensitive behavior at runtime is provided.

An advanced feature of user interfaces in ambient environments is the capability of flexible mi- gration over different devices to utilize available devices as profitably as possible. For example, if the user gets to a room with a large display she wants for some information to be presented on the large display. In particular, it is sometimes desirable to allow not only migration of the whole user interface but rather partial migration: For example, when using a large display it might be useful to provide the visualization part (i.e. purely output) on the large display while the control part (buttons etc.) should be rendered on the user’s personal mobile device as supported by [Bandelloni and Paternò04, Ban- delloni et al.04] or [Braun and Mühlhäuser05]. A taxonomy and general discussions of user interface migration can be found in [Berti et al.05, Luyten and Coninx05].

Two concrete examples approaches are described in the next section: UsiXML, and XML-based

approach which realizes the design-time part of the reference framework very closely, andDynamo- Aidwhich provides an example for context-sensitivity at runtime.

A subclass of user interface modeling languages with increasing practical relevance are XML- based languages focusing only on concrete user interface specification. They allow a declarative and often platform-independent specification of the user interface but do not aim to support the devel- opment process or to provide abstract models. The user interface specifications can be executed for example by mappings onto specific platforms, like inUIML(see section 4.1.2), or by player compo- nents. Of course, the latter ones can only be executed on platforms for which a player component exists. Such languages can be found more and more even in large open-source projects or as part of

commercial tools by large vendors. For example,XUL[XUL] is part of the Mozilla Project[Moz]

and is interpreted by theMozilla Browser.MXMLis provided byAdobe[Ado] and enables declarative specification of user interfaces for theFlex framework[Kazoun and Lott07] and is compiled into Flash

files to be executed in the Flash player (see section 2.3). XAML[XAM] is developed byMicrosoft

[Mic] and can be compiled into Windows .NET applications or be interpreted by XAML players. Due to their declarative nature, their ability to run on several platforms, and their similarity with CUI models, it is often useful to consider XML-based user interface specification languages either as target format or directly as CUI model in model-based user interface development approaches.