INTEGRATING MODEL-BASED AND TASK-BASED APPROACHES TO USER INTERFACE GENERATION

This is a draft of the article published at the Springer LNCS series Reference: España, S., Pederiva, I., Panach, J. I. and Abrahao, S. (2006). Integrating Model-based and Task-based approaches to user interface generation. Conference on Computer-Aided Design of User Interfaces (CADUI 2006), Bucharest, Romania, Springer. INTEGRATING MODEL-BASED AND TASK-BASED APPROACHES TO USER INTERFACE GENERATION Sergio España, Inés Pederiva, Jose Ignacio Panach, Silvia Abrahão Department of Information Systems and Computation Valencia University of Technology, Camino de Vera s/n, 46071 Valencia, Spain Abstract: Traditionally, the Software Engineering community has been interested in defining methods and processes to develop software by specifying its data and behaviour disregarding user interaction. On the other hand, the Human- Computer Interaction community has defined techniques oriented to the modelling of the interaction between the user and the system, proposing a user-centred software construction. This paper aspires to reconcile both visions by integrating a task model into a sound, model-based software development process. The use of CTT task trees embedded in a model-based approach makes it possible to establish mapping rules between task structure patterns describing interaction and the elements of the abstract interface model. This proposal is underpinned by the MDA-based technology OlivaNova Method Execution, which makes user-centred software generation a reality. Keywords: Functional Requirements, User Interaction, Model-based, Task-based, User Interface, Code Generation. 1. INTRODUCTION One challenging goal in the context of Software Engineering (SE) and Human-Computer Interaction (HCI) is to provide proper bridges between their best-known software production methods and techniques. SE is considered to be strong in specifying functional requirements, while HCI is centered on defining user interaction at the appropriate level of abstraction. In either case, software production methods that combine the most functional-oriented, conventional requirements specification with the most

2 interaction-oriented, user interface modelling are strongly required. Furthermore a necessity in developing quality software is to find how to link all the relevant steps in conformance with a full software production process. Model transformation technologies (i.e. MDA approaches [14]) make it possible to provide a global software process where the requirements model includes all the relevant aspects of the analysed problem (structure, behaviour and user interaction) from the beginning. These are first projected onto a Conceptual Schema and onto the final software product later. The intended contribution of this paper is to provide the basis to build such a software production process, with two basic principles in mind: Model Transformation is used to automate the conversion of the Requirements Model into the Conceptual Model and then convert this conceptual model into the System Design and Implementation. A Model Compiler implements the corresponding mappings. Each modeling step provides appropriate methods to deal properly with the specification of structural, functional and interaction properties. In this paper, we present an approach in this context, introducing some interesting and original aspects. Our intention is to combine two well-known techniques that come from different fields: a sound functional specification (Use Cases from SE [7]) is enriched by an interaction model (CTT Model from HCI [19]). Then a set of mappings allows the derivation of the Conceptual Schema. The approach presented here has been successfully implemented in OlivaNova Model Execution (ONME), an MDA-based tool that generates a software product that corresponds to the source Conceptual Schema. Without going into detail on the technical aspects of the model compilation, we intend to demonstrate that conceptual modeling is more powerful when user interaction and system behaviour are modelled within a unified view at the early stage of requirements elicitation. The paper is structured as follows. Section 2 presents an overview of model-based user interface development environments proposed in the literature. Section 3 introduces a software production process that combines model-based and task-based approaches. Section 4 describes a case study that illustrates the application of our software production process. Finally, section 5 presents the conclusions, some lessons learned derived from the process application, and future work. 2. RELATED WORK From an HCI point of view, there are a number of model-based user interface development environments (MB-UIDEs) reported in the literature. In da Silva s survey [3], several MB-UIDEs are reviewed, distinguishing

two generations of tools. The aim of the first generation was to provide a run-time environment for user interface models; some examples are COUSIN [6], HUMANOID [24], MIKE [17], UIDE [9] and UofA [23]. The second generation aimed to provide support for interface modelling at a high level of abstraction. Examples of these environments include ADEPT [12], AME [13], DIANE+ [26], FUSE [11], GENIUS [8], MASTERMIND [25], MECANO [20], MOBI-D [21], TADEUS [4], Teallach [5], and TRIDENT [1]. Many of the second generation of MB-UIDEs rely on a domain model. This model is often a description of the domain entities and relationships between them, which are represented as a declarative data model (as in MECANO and MOBI-D), an entity-relationship data model (as in GENIUS), or an object-oriented data model (as in FUSE). Some MB-UIDEs like ADEPT, FUSE, TADEUS, TRIDENT and USIXML propose task models as a primary abstract interaction modelling, from which the abstract interface models (or its equivalent dialogue models) are later derived. It is important to remark that USIXML [27] is an XML-based interface description language that is supported by a suite of tools, ranging from creating UI sketches to generating the final UI. Therefore, we will consider USIXML as an MB-UIDE for the purposes of this review. Table Error! No hay texto con el estilo especificado en el documento.-1 shows a comparison between some of the reviewed MB- UIDEs. Note that there are still some unresolved issues already addressed in previous reviews [22]. In general terms, there is poor lifecycle support, lack of integration between models to provide a full software production process and lack of functionality specification leading to no functionality generation. In addition, none of the reviewed MB-UIDEs allow the specification of the actual functionality of the application being built. Table Error! No hay texto con el estilo especificado en el documento.-1. Review of several MB-UIDEs MB-UIDE Whole lifecycle support Model integration Functionality specification and generation Interface generation Domain model Mobi-D Yes Yes No / No Guided Declarative Mastermind No Yes No/No Yes Declarative Adept Yes Yes No/No Yes In Task model Genius No Yes No/No Yes Entity relationship Fuse No Yes Partial/No Yes Object model Tadeus Yes Yes No / No Yes Object model Trident Yes Yes No/No Yes Enhanced data models Usixml No Yes No / No Yes Class diagram 3

4 The result is that the application being modelled can t be completely generated. For example, USIXML has properly mapped the elements of a task model to the elements of a domain and interface models by defining a transformation model and the corresponding support tools [10][16]; although there are tools that deal with the final user interface generation, no business layer is generated due to the lack of a functional model. From a SE point of view, some development methods and environments have been proposed. They normally use a class diagram-like model to capture the system structure and a process model to fix the functionality that the system is supposed to provide. In addition, in recent years some CASE tools (Toghether, Rational Rose, Poseidon, etc.) have been proposed with the objective of providing some kind of automation to manage these models. However, interaction modelling is not a key issue when requirements and conceptual modelling is represented in a software production process. 3. MODEL-BASED INTERFACE DEVELOPMENT WITH OLIVANOVA MODEL EXECUTION In this section, we present a complete software production process that combines functional requirements specification, user interaction design, and implementation. It is defined on the basis of OlivaNova Model Execution (ONME) [2], a model-based environment for software development that complies with the MDA paradigm [14] by defining models of a different abstraction level. Figure Error! No hay texto con el estilo especificado en el documento.-1 shows the parallelism between the models proposed by MDA and the models dealt with in OO-Method [18] (the methodology underlying ONME). Figure Error! No hay texto con el estilo especificado en el documento.-1. A MDA-based development framework for UI development

At the most abstract level, a Computation-Independent Model (CIM) describes the IS without considering if it will be supported by any software application; in OO-Method, this description is called the Requirements Model. The Platform-Independent Model (PIM) describes the system in an abstract way, having in mind that it will somehow be computerized but still disregarding the underpinning computer platform; this is called the Conceptual Model in OO-Method. ONME implements an automatic transformation of the Conceptual Model into the source code of the final user application. This is done by a Model Compilation process that has implicit knowledge about the target platform. This step is equivalent to the Platform Specific Model (PSM) defined by MDA. In the following, we explain the main steps of our software production process in more detail. 3.1 Obtaining Functional Requirements The first step in the construction of a software system is the requirements elicitation. Its purpose is to specify what the customer needs. In our process, this step is accomplished through the definition of a Requirements Model [7]. Following a top-down decomposition, the functionality of the system is specified without considering its implementation on a software application. The requirements model is composed by: a mission statement, a function refinement tree, and a use-case model. The mission statement describes the purpose of the system in one or two sentences. The external interactions can always be partitioned into functions. These functions are hierarchically structured in a Functions Refinement Tree (FRT) where the root is the mission statement, the internal nodes are business activities, and the leaves are use cases. Finally, the Use Case Model includes the interaction between the system and an external actor. The interaction is decomposed into steps in the use-case specification. 3.2 Eliciting User Interaction In order to document interaction requirements, we propose the use of the Concur Task Trees (CTT) notation [19]. The interaction between the user and the system is specified by means of a task model, resulting in a hierarchical task tree in which the tasks have different granularity and are related by temporal operators. Functional requirements obtained in the previous step are the input for this step. A CTT tree is built for each use case. It specifies how the user interacts with the system in order to accomplish the task required. The use case constitutes a high-level task that is decomposed into lower granularity tasks; it is important to define the criterion of decomposition [7]: we propose 5

6 to reach basic tasks concerning data elements. There is a deep mapping between elements of the use-case specification and elements of its correspondent task model: the steps of the use case involving elemental data manipulation appear as basic tasks of the task tree. For example, the introduction or selection of a piece of data being described in the use-case specification results in an interaction task of the lowest granularity, which consists of the user introducing or selecting that data in the interface. Sometimes this interaction modelling process involves several use cases, which results in their restructuring; that is, the interaction requirements reorganize the functional requirements. This way, we are dealing with the user localization of the system s functionality; that is, how the user can find and invoke the functions that he/she needs. These interaction requirements complete the CIM level of our development approach. Due to the fact that our intention is to go further down in the development process, we build the task trees with certain structures of tasks that we have observed to be very frequent. The next section explains how those structures are later mapped to presentation patterns of the PIM level. 3.3 Modelling Data, Behaviour, and Interaction After the Requirements Model and the CTTs are specified, the data, behaviour, and presentation issues should be modeled. In order to cover the data and behaviour perspectives, OO-Method defines a PIM called Conceptual Model [18] consisting of: the Object Model, the Dynamic Model, and the Functional Model, which can all be designed using the Requirements Model as input. The Object Model specifies the object structure and its static interactions. It is modelled in an extended UML class diagram. The Dynamic Model represents the control, the sequences of events and the interaction between the objects. The Functional Model specifies how events change the object states and. Finally, the behaviour of the system is modeled by the Functional and Dynamic Models working together. To model the interaction between the system and the user, OO-Method incorporates a Presentation Model. Based on a pattern language called Just-UI [15], it divides the interaction in three levels: Level 1. Hierarchy of Actions Tree (HAT): It organizes the functionality that will be presented to the different users who access the system. Level 2. Interaction Units (IUs): It represents abstract interface units that the user will interact with to carry out his/her tasks. There are four types of UIs: Service IU, Instance IU, Population IU, and Master/Detail IU. A Service IU models a dialogue whose objective is to help the user execute a service. An Instance IU models the data presentation of a class

instance. A Population IU models the presentation of a set of instances of a class. Finally, a Master/Detail IU represents more complex interactions that deal with master/slave presentations. Level 3. Elementary patterns (EPs): These patterns constitute the primitive building blocks of the UI and allow the restriction of the behaviour of the different interaction units. There are 11 patterns, but for the purposes of this paper, we are going to use only the following: (1) introduction: it captures the main features of data types that the user will introduce into the system; (2) filter: it defines selection criteria and obtains the instances that fulfil the constraint expressed; (3) order criteria: it orders instances using one or more attribute; (4) actions: it allows the user to execute object services. As suggested in Figure Error! No hay texto con el estilo especificado en el documento.-1, the CTTs obtained in the eliciting user interaction step can be used as a starting point to define the Presentation Model instead of defining it from scratch. Consequently, there is a direct mapping between parts of the CTT and the Presentation Model. To do that, we have to define a design pattern for CTT and concrete names for their components. We show some of them in Table Error! No hay texto con el estilo especificado en el documento.-2. Table Error! No hay texto con el estilo especificado en el documento.-2. Some matching between CTT and Presentation Model CTT Presentation Model Two abstract tasks related by an Enabling with information Master / Detail passing temporal operator An abstract task whose name starts with New or Modify Service IU An abstract task whose name starts with List Population IU An abstract task whose name starts with Detail Instance IU An interaction task named Select filter Filter An interaction task named Select sort criteria Order criteria An interaction task leaf of a subtree that has been mapped to a Introduction Service IU An interaction task whose name starts with Demand Action 3.4 Generating the System Once we have completed the PIM, the next step is to take advantage of ONME automatic production of the source code (Code Model). Nowadays, ONME implements a Model Compilation process to automatically transform the information captured in the Conceptual Model in a full software system in the following platforms: Visual Basic, C #, ASP. NET, Cold Fusion and JSP; using as repository SQL server 2000, ORACLE or DB2. The resulting application is a three-layer application that includes the interface tier, the 7

8 application tier, and the persistence tier. As an explanation of the transformation patterns implemented by the ONME, Table Error! No hay texto con el estilo especificado en el documento.-3 shows the correspondences between PIM elements and representations employed in the concrete widgets for the Visual Basic platform [15]. Table Error! No hay texto con el estilo especificado en el documento.-3. Some Transformation Patterns Presentation model VB component Hierarchical action tree (HAT) Application menu Interaction unit MDI child form Service IU MDI child form with entry controls Simple type service argument Entry control Object-valued service Generic control OIDSelector argument Filter Filter control Filter variable Entry control Actions Button panel Action item Button Service throw Accept button and code to validate and invoice the service Cancellation Cancel button and code to close the formulary Services invocation Code for linking business logical layer with service invoice Data presentation Code for formatting and data recovery 4. A CASE STUDY This section shows the construction of a system using the proposed software production process. The system to be built is OlivaNova Automatic Tweaking, part of the ONME suite. It is intended to automate subtle manual changes requested by clients after the code generation. Each project can have different versions with its own requirements and transformed code. 4.1 Obtaining Functional Requirements In order to explain our proposal, we have selected one task of this system: create a version. In this task, the user must select an existing project and add a new version for it. In Figure Error! No hay texto con el estilo especificado en el documento.-2 (a), we show part of the FRT in which this task is included.

9 Figure Error! No hay texto con el estilo especificado en el documento.-2. Functions Refinement Tree for the Tweaking system Once we have the FRT, the Use-Case Model can be obtained from the leaves of the tree. Our case study will be centered on the Create version use case that corresponds to the leaf that is marked in the FRT. Figure Error! No hay texto con el estilo especificado en el documento.-2 (b) presents the specification of this use case. It consists of a use case description, the actors who can invoke it, the conditions needed to execute it and the list of events which compose it. 4.2 Eliciting User Interaction In this step, we take each use case and build the task tree by describing the interaction that occurs between the user and the system. We first build the listing use cases because they often constitute the precondition and, as a consequence, a path for accessing other use cases. Following with the example, Figure Error! No hay texto con el estilo especificado en el documento.-3 shows the CTT model for the Create version use case. Figure Error! No hay texto con el estilo especificado en el documento.-3. CTT model for the Create version use case

10 The root of the task tree is the use case whose interaction is being modelled. Since this use case has the selection of a project as a precondition, we reuse the List versions from project CTT, and we include the Demand the creation of a new version interactive task. Once the precondition is covered, the path to reach the Create version use case is clear. We can now identify the mapping between the steps of the use-case specification (see previous section) and the lowest level tasks; for example, step 5 Indicate the relative path of the project has its correspondent interaction task: Relative path. It is also noticeable that several use cases have been reorganized: the main functionality of Create version (the New version abstract task) is accessed through the interface of the List projects and List versions use cases. 4.3 Modelling Data, Behaviour and Interaction As mentioned in Section 3.3, an Object Model, a Dynamic Model, and a Functional Model are used for modelling the data and behaviour of the system. However we are going to focus only on the modelling of the user interaction. The Presentation Model is defined by using the Just-UI [15] patterns; Figure Error! No hay texto con el estilo especificado en el documento.-4 (a) shows the system s first two levels of presentation patterns. The patterns that appear highlighted in gray, are detailed in (b). Figure Error! No hay texto con el estilo especificado en el documento.-4 (b), shows the services and the arguments of Create_Instance. HAT Changes Project Projects Projects Version Changes List Versions from Project List Project s Users Versions List Files from Version Versions Files Files and Changes HAT Changes Project List Versions from Project Versions Others Change Types Change Natures Users Edit List Users List Projects from User Arguments: Project_id. Version_id Description Relative_path Services: Create_instance Delete_instance Modify_instance A Administrators List Administrator New Delete (a) (b) Figure Error! No hay texto con el estilo especificado en el documento.-4. Presentation Model for the Tweaking system To design this model, we consider the CTT generated in the previous step. In particular, Figure Error! No hay texto con el estilo especificado en el documento.-4 (b) was generated by the definition provided in Figure

Error! No hay texto con el estilo especificado en el documento.-3. The left subtree of the CTT is the precondition of the use case and it maps to a Master/Detail pattern. The interactive task defined in Figure Error! No hay texto con el estilo especificado en el documento.-3 Demand the creation of a new version has a correspondence with the call of another IU. As a consequence, the right side of the tree should be analyzed in order to determine its associated pattern. This tree corresponds to a Service IU and, as the name of the use case specifies, its execution will call the Create_Instance service. As this service corresponds to a service defined in the Object Model, it turns towards an early model validation, based on the traceability of the Presentation Model and the Use Cases. 4.4 Generating the System Using the ONME technology, the translation patterns described in Table Error! No hay texto con el estilo especificado en el documento.-3 are automatically applied to the Presentation Model shown in Figure Error! No hay texto con el estilo especificado en el documento.-4. The result of this process is the application shown in Figure Error! No hay texto con el estilo especificado en el documento.-5. The HAT has become the application menu and the List Version from Project and Versions patterns have been turned into windows. In the List Versions from Project window, we can invoke the tasks related to the versions listed by a project. It contains the task to create a version (button marked). Once the button is clicked, the New Version window appears to introduce the information to create a version. 11 Figure Error! No hay texto con el estilo especificado en el documento.-5. New version window The following table shows each presentation model component that is used to define the New version window and its interface component implementation.

12 Table Error! No hay texto con el estilo especificado en el documento.-4. Correspondences between the presentation model and the final interface Presentation model Final interface Hierarchical action tree (HAT) Service IU The whole window Service throw and Cancellation Simple type service argument Introduction pattern for a date field Code for validating date format 5. SUMMARY AND FUTURE WORK Software production methods need a complete software production process that properly integrates system functionality, behaviour, and user interaction in the early stages of the system lifecycle. This process should also allow the sketching, modelling, and prototyping of UIs. In accordance with these ideas, we have presented a software production process that starts from requirements elicitation and uses CTT notation based on tasks to build a full software system, not just its user interface. To do this, we embedded the CTT notation in a model-based development approach by respecting its original semantics. As a consequence, the user interface is designed by taking into account the way in which the user interacts with the system. Some lessons learned while applying the proposed software production process include the following: The CTT models help to create the Presentation Model by providing a user-centered approach. There are previous works related to deriving the model of the application menu from the FRT. However we believe that functional requirements elicitation should concentrate on first finding out all the basic functionalities of the system, and arranging how it will be presented to the user later in the process. Another problem concerning the CTT notation usage was found: different participants happened to build distinct task models for the same task. This can be attributed to the lack of a well-defined methodological guide. This problem could be partially solved by defining a set of task patterns which can be composed to build the CTT tree; The use of CTT to model user interaction through a particular use case does not lead to a model of the interface itself, but rather to a model of how he/she will use the interface to accomplish that task. This subtle difference makes it hard to derive the Presentation Model because the transformation is not always straightforward. The proposed process will be empirically validated in the near future to prove its effectiveness. Future work should also integrate an application that

would implement CTT drawing using these proposed patterns. This would allow CTT nodes to be reused easily. 13 REFERENCES [1] Bodart, F., Hennebert, A., Leheureux, J., Provot, I., and Vanderdonckt, J.. (1994) A Model-Based Approach to Presentation: A Continuum from Task Analysis to Prototype. In Proceedings of DSV-IS'94, pp. 25-39, Bocca di Magra. [2] Care Technologies: http://www.care-t.com Last visited: Jan-2006 [3] da Silva, P. P. (2001) User interface declarative models and development environments: A survey. Interactive Systems. Design, Specification, and Verification, 8th International Workshop, DSV-IS 2001, Glasgow, Scotland, Springer-Verlag Berlin. [4] Elwert, T. and Schlungbaum, E. (1995) Modelling and Generation of Graphical User Interfaces in the TADEUS Approach. In Designing, Specification and Verification of Interactive Systems, pp. 193-208, Vienna, Springer. [5] Grifiths, T., Barclay, P., McKirdy, J., et al. (1999) Teallach: A Model-Based User Interface Development Environment for Object Databases. In Proceedings of UIDIS'99, pp. 86-96, Edinburgh, UK. IEEE Press. [6] Hayes, P., Szekely, P. and Lerner, R. (1985) Design Alternatives for User Interface Management Systems Based on Experience with COUSIN. Proceedings of SIGCHI'85, pp. 169-175. Addison-Wesley, April 1985. [7] Insfrán, E., Pastor, O., Wieringa, R. (2002). Requirements Engineering-Based Conceptual Modelling. Requirements Engineering, Vol. 7, Issue 2, p. 61-72. Springer-Verlag. [8] Janssen, C., A. Weisbecker, et al. (1993 ). Generating user interfaces from data models and dialogue net specifications. Proceedings of the SIGCHI conference on Human factors in computing systems Amsterdam, The Netherlands ACM Press: 418-423 [9] Kim, W. and Foley, J. (1990) DON: User Interface Presentation Design Assistant. In Proceedings of UIST'90, pp. 10-20. ACM Press, October 1990. [10] Limbourg, Q. and J. Vanderdonckt (2004). Addressing the mapping problem in user interface design with UsiXML Proceedings of the 3rd annual conference on Task models and diagrams Prague, Czech Republic ACM Press: 155-163. [11] Lonczewski, F. and Schreiber, S. (1996) The FUSE-System: an Integrated User Interface Desgin Environment. Computer-Aided Design of User Interfaces, pp. 37-56, Namur, Belgium, Namur University Press. [12] Markopoulos, P., Pycock, J., Wilson, S. and Johnson, P. (1992) Adept - A task based design environment. Proceedings of the 25th Hawaii International Conference on System Sciences, pp. 587-596. IEEE Computer Society Press. [13] Märtin, C. (1996) Software Life Cycle Automation for Interactive Applications: The AME Design Environment. Computer-Aided Design of User Interfaces, pp. 57-74, Namur, Belgium. Namur University Press. [14] MDA: http://www.omg.org/mda Last visit: Dec-2005 [15] Molina P., User interface specification: from requirements to automatic generation,, PhD Thesis, DSIC, Universidad Politécnica de Valencia, March 2003 (in Spanish). [16] Montero, F., V. López-Jaquero, et al. (2005). Solving the mapping problem in user interface design by seamless integration in IdealXML. Proc. of DSV-IS'05, Newcastle upon Tyne, United Kingdom, Springer-Verlag. [17] Olsen, D. (1989) A Programming Language Basis for User Interface Management. Proceedings of SIGCHI'89, pp. 171-176, May 1989. [18] Pastor, O., J. Gómez, et al. (2001). "The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming." Information Systems 26(7): 507-534.

14 [19] Paternò, F., C. Mancini, et al. (1997). ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models. Proceedings of the IFIP TC13 International Conference on Human-Computer Interaction, Chapman & Hall, Ltd.: 362-369. [20] Puerta, A. (1996). The Mecano Project: Comprehensive and Integrated Support for Model-Based Interface Development. Computer-Aided Design of User Interfaces CADUI'96, pp. 19-36, Namur, Belgium, Namur University Press. [21] Puerta, A. and Maulsby, D. (1997) Management of Interface Design Knowledge with MODI-D. In Proceedings of IUI'97, pp. 249-252, Orlando, FL, USA. [22] Puerta, A. R., H. Eriksson, et al. (1994). Beyond data models for automated user interface generation Proceedings of the conference on People and computers IX Glasgow Cambridge University Press: 353-366. [23] Singh, G. and Green, M. A high-level user interface management system. Proceedings of SIGCHI'89, pp. 133-138, May 1989. [24] Szekely, P. (1990) Template-Based Mapping of Application Data to Interactive Displays. Proceedings of UIST'90, pp. 1-9. ACM Press, October 1990. [25] Szekely, P., Sukaviriya, P., Castells, P., Muthukumarasamy, J., and Salcher, E. (1996) Declarative Interface Models for User Interface Construction Tools: the MASTERMIND Approach. In Engineering for HCI, pp. 120-150, London, UK, Chapman & Hall. [26] Tarby, J. and Barthet, M.. (1996) The DIANE+ Method. Computer-Aided Design of User Interfaces, pp. 95-119, Namur, Belgium, Namur University Press. [27] Vanderdonckt, J., Q. Limbourg, et al. (2004). USIXML: a User Interface Description Language for Specifying Multimodal User Interfaces. Proceedings of W3C Workshop on Multimodal Interaction WMI'2004, Sophia Antipolis, Greece.