1. usiXML July, 2004 (Hamburg, Germany) 1 USIXML: a Language Supporting Multi-Path Development of User Interfaces Quentin Limbourg 1, Jean Vanderdonckt 1, Benjamin Michotte 1, Laurent Bouillon 1, Víctor M. López Jaquero 1,2 2 Computer Science Research Institute (I3A) LoUISE Research Group University of Castilla-La Mancha Albacete, Spain 1 Belgian Laboratory of HCI University Catholic of Louvain Louvain-la-neuve, Belgium

2. usiXML July, 2004 (Hamburg, Germany) 2 UIs ARE RUNNING FAST... AFTER CHANGE  Task redefinitions  Tasks reallocation  Organizational adaptation  Domain evolution  Obsolescence of languages  New languages  New platforms ……

3. usiXML July, 2004 (Hamburg, Germany) 3 DEVELOPMENT PATHS  To face these challenges several development paths may be identified: –Forward engineering –Reverse engineering –Adaptation to context of use –Middle-out approach –Widespread approach

4. usiXML July, 2004 (Hamburg, Germany) 4 MULTI-PATH DEVELOPMENT  To support these approaches in a single framework we need: –An ontology of concepts valid for all paths. –A central strorage of models. –A mean to express model transformations. –An execution mechanism for performing transformations.

5. usiXML July, 2004 (Hamburg, Germany) 5 ONTOLOGY  Task (CTT + minor improvements).  Domain (Class + Object diagram + improvements)  Abstract User Interface (vocabulary independent of the modality)  Concrete user interface (vocabulary independent of the platform)  Context of use (subset of CC/PP standard)  Inter-model relationship mappings (traceability, integration of all views)

6. usiXML July, 2004 (Hamburg, Germany) 6 SYNTAX  Abstract syntax –Directed, labelled, attributed, typed graphs. –Nodes are concepts. –Edges are relationships between these concepts. –Result: a UI specification is a BIG WHOLE graph.  Concrete syntax : USIXML –User Interface eXtensible Mark-Up Language –(graph structure is achieved by defining explicitly relationships)

7. usiXML July, 2004 (Hamburg, Germany) 7 MODEL-TO-MODEL TRANSFORMATION IS THE NAME OF THE GAME Uses language Meta-Meta-Model Graph Structure is instance of Meta-Model usiXML Meta-Model Meta-Model Subset 1 e.g., Task+Domain Model is instance of Meta-Model Subset 2 e.g., Concrete UI Model is instance of Initial UI Model e.g., MyTaskAndDomainModel Resultant UI Model e.g., MyConcreteUIModel Transformation Rule usiXML Transformation Catalog

8. usiXML July, 2004 (Hamburg, Germany) 8 DEVELOPMENT PATH CONNECTION TO TRANSFORMATIONS A development library and transformation models are available to store and resuse the defined development paths and transformations.

9. usiXML July, 2004 (Hamburg, Germany) 9 TRANSFORMATION PATHS, STEPS, SUB-STEPS

10. usiXML July, 2004 (Hamburg, Germany) 10 TRANSFORMATIONS  In the literature: –APIs –XSLT –…–…  Drawbacks –Execution semantics is poorly defined –Consistency of resultant model –Procedurality –Cryptic syntax

11. usiXML July, 2004 (Hamburg, Germany) 11 CONDITIONAL GRAPH REWRITTING  Generalization of string grammars.  Grounded execution semantics (pushout construction).  Side-effect free.  Attractive syntax.  Declarativeness.  Seamlessness with ontological world (rules manipulate patterns of specification).  The rules are applied in a pure sequential programmed graph rewritting manner.

12. usiXML July, 2004 (Hamburg, Germany) 12 HOW IT WORKS …  Find an occurrence of LHS in G (this occurrence is called a match). If several occurrences exist, choose one non- deterministically.  Check preconditions of both type PAC and NAC. If not verified, then skip.  Remove the part of G which corresponds to (LHS – K), where K is the morphism specified between LHS and RHS.  Add RHS – K to the result of last step.  Embed RHS – K into G – (L – K) as it is given by the corresponding relation between RHS – K and K.  Check postconditions of both type PAC (and notably that the resulting graph is properly typed) and NAC. If not verified, then undo the transformation rule.

13. usiXML July, 2004 (Hamburg, Germany) 13 VISUAL SYNTAX

14. usiXML July, 2004 (Hamburg, Germany) 14 EXAMPLE WIDGET REPLACEMENT 7 Youri... <radioButton groupName=“grupo01" defaultContent="Femme" defaultState="false" id="radiobutton_0"/> <radioButton groupName="grupo01" defaultContent="Homme" defaultState="true" id="radiobutton_1"/>... Excerpt for an usiXML CUI specification.

15. usiXML July, 2004 (Hamburg, Germany) 15 EXAMPLE WIDGET REPLACEMENT

16. usiXML July, 2004 (Hamburg, Germany) 16 EXAMPLE WIDGET REPLACEMENT The usiXML graph before aplying any rule

17. usiXML July, 2004 (Hamburg, Germany) 17 EXAMPLE WIDGET REPLACEMENT LHS RHS NAC Rule 1: Create a new comboBox with the same id and name as the name of the group of radioButtons.

18. usiXML July, 2004 (Hamburg, Germany) 18 EXAMPLE WIDGET REPLACEMENT Rule 1: Create a new comboBox with the same id and name as the name of the group of radioButtons. The usiXML graph after aplying the first rule

19. usiXML July, 2004 (Hamburg, Germany) 19 EXAMPLE WIDGET REPLACEMENT LHSRHS ::= Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”, we have just created.

20. usiXML July, 2004 (Hamburg, Germany) 20 EXAMPLE WIDGET REPLACEMENT Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”, we have just created. The usiXML graph after aplying the second rule

21. usiXML July, 2004 (Hamburg, Germany) 21 7 Youri...... EXAMPLE WIDGET REPLACEMENT Excerpt from the final transformated usiXML specification

22. usiXML July, 2004 (Hamburg, Germany) 22 EXAMPLE WIDGET REPLACEMENT

23. usiXML July, 2004 (Hamburg, Germany) 23 TOOL SUPPORT  Running prototypes –TransformiXML API : transformation tool –GrafiXML : CUI Hi-Fi + Code Generator (Java Swing, XHTML) –SketchiXML : CUI Sketching Lo-Fi –VisiXML : CUI Lo-Fi, MS Visio Plug-in –FlashiXML : flash renderer –ReversiXML : reverse engineering from HTML to CUI  In development: –TransformiXML GUI : transformation tool –Task and AUI editors –Tcl/Tk renderer  In cooperation : –Teresa (F. Paterno, CUI level)

24. usiXML July, 2004 (Hamburg, Germany) 24 TRANSFORMIXML API

25. usiXML July, 2004 (Hamburg, Germany) 25 GRAFIXML

26. usiXML July, 2004 (Hamburg, Germany) 26 FLASHIXML

27. usiXML July, 2004 (Hamburg, Germany) 27 TRANSFORMIXML GUI

28. usiXML July, 2004 (Hamburg, Germany) 28 CONCLUSIONS  Key ideas: –usiXML represents specification models as BIG WHOLE graphs, it allows the expression of (1) multiple levels of abstraction of UI models (2)development steps (of all sorts) by using conditional graph rewritting rules.  Advantages of our approach: –Ontological commitment: our language can be criticized as it is defined in all its dimensions, from concepts to concrete syntax, from task and domain until concrete user interface. –Opens the black box of transformation. –Decomposes transformation into meaningful chunks: separation of concern at methodological level. –Capitalization on transformational heuristics. –Multiple-entry points and multiple exit points = flexibility. –Model exchange formalism -> tool interoperability. –Extendibility, usiXML was planned to receive contributions (3D, multi-modal, multi-surface interaction). –Tracaebility of design decisions.

29. usiXML July, 2004 (Hamburg, Germany) 29 FUTURE WORK  Pattern expression using usiXML chunks.  Extension to other modalities (e.g., 3D, multi- modal).  Integration of other models in the framework (e.g., workflow models?).  Continue the development of ongoing tools …

30. usiXML July, 2004 (Hamburg, Germany) 30 THANK YOU! See you on www.usixml.org !