Developing advanced User Interfaces (UI) is very challenging, in particular when many variants of a same UI are to be produced for different platforms. The development of plastic user interfaces is even more demanding. In Human Computer Interaction, plasticity denotes the capacity of a UI to withstand variations of the context of use while preserving usability. A context of use is a triplet < user, platform, environment >. Plasticity raises many issues for both the design and run time of UIs. This paper shows how Model Driven Engineering concepts can be used in this area.
The core idea of this paper is to investigate Model Driven Engineering for the development and execution of plastic UIs. In HCI, plasticity denotes the capacity of a UI to withstand variations of context of use while preserving usability. A context of use refers to the triplet < user, platform, environment >. With ubiquitous computing, UIs are no longer confined in a unique desktop, but they can be distributed or migrated among a dynamic set of interaction resources. As a result, UIs must be mold dynamically in order to adapt gracefully to the new context of use. While product line approaches deal with the production of variants of UIs (e.g., a UI specifically crafted for PC or PDA or phone), plasticity is even more challenging coping with the change of the context of use. The UI can fully migrate from one platform to another one (e.g., from a PC to a PDA when the battery of the PC gets low); the UI may be redistributed among a set of platforms (e.g., a remote controller will migrate to a PDA) or the UI may stay on the current platform but be remold in order to accommodate to variations in the context of use (e.g., luminosity level). Adaptation should be done in an opportunistic manner for preserving usability.
While code-centric approaches might be suited for the development of simple and single UIs, they simply fail for developing plastic UIs. Many facets of the interactive system, in particular its plasticity domain (i.e., the set of contexts of use it is able to cover) must be modeled explicitly. This is what Model Driven Engineering is suited for.
Figure 1 shows an overview of a MDE framework based on the
European CAMELEON project [
The paper is threefold. Section 2 focuses on the right part of Figure 1, that is the development of "rigid" (i.e., not plastic) UIs. Specific requirements for plasticity are described in Section 3 (left part of Figure 1). Finally Section 4 concludes the paper. Context of Use
Property
Domain
Before addressing the specific requirements for plasticity, let's see
how Model Driven Engineering can be used for the development
of classical rigid UIs by opposition to plastic UIs. This implies the
use of (1) a development process (or better said a family of
development processes), (2) a set of metamodels and (3) a set of
mappings and transformations. A more detailed discussion on this
approach can be found in [
Current industrial practices are still mostly code-centric (right
bottom of Figure 1). Conversely, Model Driven Engineering
processes are based on successive refinements of models, with the
integration of new information at each step [
Metamodels are keys to Model Driven Engineering. To be
productive, each model must be accompanied with a precise and
explicit metamodel (otherwise the model cannot be interpreted
and transformed by a machine). The development of classical
rigid UIs implies five metamodels [
Task. A task describes how a user's objective can be reached by following a given procedure. From a MDE point of view, task models are trees made of binary and unary operators. Concept. This model describes the domain of discourse. Typically such models can be described using UML class diagrams. These are usually referred as Domain Model in Software Engineering and Product Line communities.
Workspace. Also referred as Abstract User Interface [
Interactor. Also referred as Concrete User Interface in [
P r o g r a m . The last "models" are direct abstractions of programs and/or other implementation techniques. Such models are Platform Specific Models (PSM) in the MDE jargon. They just represent the actual implementation of the UI.
Obviously, all models expressed with these metamodels should be connected together because they just represent different points of view on the same UI. Mappings and transformations are briefly discussed in the next section.
With metamodels, mappings and transformations are the
cornerstones of MDE. Without them, all the models would be
isolated. Conversely, the idea is to incrementally transform
abstract models at high level of abstraction (Platform Independent
Models, PIM in MDE jargon) into Platform Specific Models. This
is obviously an over simplification. Monolithic code generators
are not suited for advanced user interfaces. MDE approaches are
based on libraries of small composable and extensible
transformations. The designer selects and if necessary tunes the
appropriate transformations. If no transformation is available, a
new one can be written thanks to transformation languages. It is
then added to a library for further use. In this way, expertise can
be captured and packaged into transformation libraries.
Quite often transformation engines are associated to specific
modeling environments based on a given set of metamodels for UI
development. This is the case for instance for TransformiXML
[
The core idea of our approach is to use generic Model Driven
Engineering techniques and extensive libraries of metamodels.
This approach is being investigated in the Zooomm project [
The rule TaskToSpace creates one workspace w per user task t. The workspace takes the name of the task; The rule OrOperatorToSequence applies to the task model. It transforms all OR operators o between two user tasks ( o . R i g h t T a s k ) into two sequence operators (from o.motherTask to o.leftTask and o.leftTask to o.rightTask). module M2TaskToM2Workspace { from M1Task : M2Task to M1Workspace : M2Workspace -- One workspace for each task rule TaskToSpace { from t : M2Task!Task to w : M2Workspace!Space (
name <- t.name }
) ... -- OrOperator rule OrOperatorToSequence{ from o : M2Task!BinaryOperator (
o.name = "or" ) to leftSequence : M2Workspace!Sequence ( origin<- [Task2Space.e]o.motherTask,
destination<-[Task2Space.e]o.rightTask )
As shown on the left of Figure 1, additional models are necessary for the engineering of plastic UIs.
For plasticity, we need additional metamodels for capturing both the context of use and the usability of the interactive systems. • •
User. This model represents the end-user of the interactive
system. It may capture general information (e.g., age,
gender), the skill level of the end-user (e.g. Rasmussen [
Platform. This model exhibits the hardware and software
platform sustaining the interaction. It is fundamental when
considering redistributable UIs. The simple metamodel
below describes the hardware core elements of such a system
[
While models are mostly used at design time in MDE and
product-line engineering, plasticity may rely on an extensive use
of models at run-time. Moreover, all abstraction levels and
traceability links are required during execution to compute the
adaptation. For instance, moving a selection task from a PC to a
PDA is easier when reasoning at the task level rather than at the
implementation level. The corresponding interactors can be
simply found by following the mapping links [
The use of models is not new in User Interface development. First attempts have been directed towards full automatic generation of UI code. Experience has shown that the resulting UIs were usually poor in terms of usability. Moreover, the use of quite monolithic code generators make it impossible to customize the interface when needed and specific heuristics based on application domains could not be integrated. Finally, existing environments were not designed with interoperability in mind.
The approach presented in this paper is quite different. Instead on focusing on the user interface only, general Model Driven Engineering techniques have been used. The key idea is to merge experiences from both the MDE and the UI development communities. Instead of developing specific model based tools such as transformation languages for the development of UI, reusing emerging MDE technologies is promising. First versions might not be fully suited to UI development specificities, but if this is the case, this would lead to new requirements for MDE. The framework presented here is used both at design time and run-time. This last point is quite innovative with respect to rational MDE applications that consider platform migration as a quite heavy development process.
This work has been supported by the SIMILAR European Network of Excellence. 6.