Ubiquitous computing has amplified the need for interactive systems to be able to adapt to their context of use (<User, Platform, Environment>) while preserving usability. This property is called plasticity. Until now, efforts have been put on the functional aspect of adaptation, neglecting the usability part of the definition. This paper investigates MDE mappings for embedding both the description and control of usability. It first provides a general definition and metamodel of the notion of “mapping” that are not devoted to Human-Computer Interaction (HCI). A mapping describes a transformation that preserves properties. A transformation is performed by a set of transformation functions that can be described either by a function and/or an execution trace. The mappings properties provide the designer with a means for both selecting the most appropriate transformation functions and previewing the resulting design. When applied to HCI, mappings are appropriate for both describing and controlling ergonomic criteria either at design time or at runtime. Mappings are rubber bands that link together different perspectives of a same User Interface (UI). They break when the UI goes outside its plasticity domain.
Jean-Marie Favre 2
In Human-Computer Interaction (HCI), plasticity refers to the ability of a User Interface (UI) to withstand variations of context of use (<User, Platform, Environment>) while preserving usability. Until now, efforts have been put on the functional aspect of adaptation. Model Driven Engineering (MDE) has been seen as promising [3] [10]. At MDDAUI’05, we presented a MDE approach promoting the description of a UI as a net of models and mappings (called octopus) [17]. In this paper, we go one step further investigating the usability part of the plasticity definition. We show how usability can be described and controlled along the mappings that compose a UI (the octopus legs). The idea was roughly sketched in [18].
The paper is threefold. In a first section, it provides a short reminder of the octopus vision and a basic case study for illustration. Then, it elaborates a general definition and metamodel of the notion of “mapping” that are not devoted to HCI but applicable to the domain as demonstrated on the case study. Finally, the paper opens a discussion on issues and perspectives in the areas of advanced UIs and MDE in general.
Taking benefit from the past in HCI, the idea is to describe a UI as a net of models and mappings. The models define different perspectives on a same UI: domain concepts, user’s task, workspaces (Wks) and interactors (I) (Figure 1). For their deployment, these models require resources that are supplied either by the functional core (FC) and/or the context of use (in particular, the platform that provides the end-user with input and output devices). Deployment is modeled as a set of mappings (the gray boxes on Figure 1). Models and mappings are compliant to metamodels.
As illustration, let us consider a basic booking system inspired from Nogier’s book [13]. For making a reservation, the end-user is supposed to first specify the date, then the period of the day (morning versus evening), and finally the number of seats he/she would like to book. Figure 2 illustrates a sub-part of the corresponding octopus: the mappings between tasks, concepts and interactors. In Figure 2a, dashes have been introduced at the interactor level to make explicit the fact that the task “Specify the date” is mapped on two guiding labels (“Date”, “mm/dd/yy”). In case a, there is no (human) error protection: text fields do not prevent the end-user from bad entries. In contrast in Figure 2b, the calendar and the radio buttons decrease the risk of error when specifying the date and the period of the day.
This paper deals with usability. It shows how usability can be described along mappings. To that end, it provides a general definition and metamodel of mappings that go beyond HCI.
Our mapping metamodel is centered on the notion of transformation. Thus, we first define the notions of mappings and transformations before presenting the metamodel.
In the MDA literature (see Table 1), the term “mapping” is far
from being clear. However, it is clearly coupled with
transformations.
On Figure 3, “f(x)=x+2” is a transformation model that is
compliant to a mathematical metamodel. A transformation model
describes (the m relation) a transformation function in a predictive
way: in our example, {(
Next section provides a metamodel of mappings based on these clarifications.
The metamodel provided in Figure 4 is a general purpose mapping metamodel. The core entity is the Mapping class. A mapping links together entities that are compliant to Metamodels (e.g., Task and Interactor). A mapping can specify Transformation functions (e.g., {(Specify the date, Date: --/--/-- (mm/dd/yy)), (Specify period of the day, “Period of the day: - (M: Morning; E: Evening)), …}) by patterns. A Pattern is a transformation model. It links together source and target elements (ModelElement) to provide a predictive description of the transformation function. In addition, a mapping can describe the execution trace of the transformation function. The trace is made of a set of Links between Instances of ModelElements. The couple (Specify the date, Date: --/--/-- (mm/dd/yy)) is an example of Link. A mapping conveys a set of Properties (e.g., “Error protection”). A property is described according to a given reference framework (Referential) (e.g., Bastien&Scapin[1] that define eight criteria among which is the “Error protection”). These properties are descriptive. They qualify either the global set of mappings or one specific element: a mapping, a pattern or a link.
Associated transformations are in charge of maintaining the consistency of the net of models by propagating modifications that have an impact on other elements. For instance, if replacing an interactor with another one decreases the UI consistency, then the same substitution should be applied to the other interactors of the same type. This is the job of the associated functions which performs this adaptation locally. Error protection to measure the extent to which the UI prevents the end-user from bad actions; Homogeneity-Consistency to consistency in the UI (e.g., style). ensure a global As pointed out in Figure 5: mappings) associates the same type of interactor (input fields) to all the user’s actions; Error protection is guaranteed in Figure 5b thanks to interactors that preserve the user from mistakes (calendar and radio buttons).
In Figure 5, the scope of compatibility (e.g., C1, C2, C3) is one mapping whilst homogeneity-consistency and error protection deal with the global net of mappings (C4 on a and b). · · · · ·
Compatibility is preserved along all the mappings linking together tasks and interactors: the UI fully supports the user’s task (Figures 5 a and b); Homogeneity-Consistency is satisfied in Figure 5a as the transformation function (that is modeled by the For legibility, Figure 5 only mentions the criteria that are satisfied. For instance, the “Error protection” that is not preserved in Figure 5a has not been mentioned. In reality, octopuses should tell the extent to which each criteria is satisfied (positively or negatively).
This work provides a sound basis for future work. Next section elaborates on perspectives for both HCI and MDE communities.
In 2000, B. Myers stated that model-based approaches had not found a wide acceptance in HCI. They were traditionally used for automatic generation and appeared as disappointing because of a too poor quality of the produced UIs. He envisioned a second life for models in HCI empowered by the need of device independence. In our work, we promote the use, the description and the capitalization of elementary transformations that target a specific issue.
A UI is described as a net of models and mappings both at design
time and runtime. At design time, mappings convey properties
that help the designer in selecting the most appropriate
transformation functions (or set of transformation functions).
Either the target element of the mapping is generated according to
the transformation function that has been selected, or the link is
made by the designer who then describes the mapping using a
transformation model. We envision adviser tools for making the
designer aware of the properties he/she is satisfying or neglecting.
At runtime, mappings are the key for reasoning on usability.
However, it is not easy as (
Beyond HCI, this work provides a general contribution to MDE. It defines a mapping metamodel and clarifies the notions of mappings and transformations. Mappings are more than a simple traceability link. They can be either predictive (transformation specifications) or descriptive (supported properties), as a result covering both the automatic generation and the hand-made linking. Moreover mapping models can embed transformation in order to manage models consistency. This is new in MDE as most of the approaches currently focus on direct transformation. Our mapping metamodel will be stored in the international Zoo of metamodels: the ZOOOMM project [6].
The work has been supported by the European project EMODE. Authors would like to thank Joëlle Coutaz and Alexandre Demeure for their strong contribution. Metamodels are edited under Topcased plugin for eclipse: http://www.topcased.org.