A MDA-Compliant Environment for Developing User Interfaces of Information Systems  Jean Vanderdonckt [email_address] Head ...
« Everything you can imagine is real » (Picasso) « Everything you model can be turned into a real interface »
Outline <ul><li>Conceptual modeling of user interfaces </li></ul><ul><li>Forward engineering </li></ul><ul><li>Reverse eng...
1.1 Why is conceptual modeling of user interfaces desirable? <ul><li>“ The presentation layer outside the scope of CSCD” (...
1.1 Diversity of users <ul><li>Traditional users </li></ul><ul><li>People with disabilities </li></ul><ul><ul><li>Visual, ...
1.1 Variety of tasks <ul><li>Users want to determine their path on each platform </li></ul>[Forrester Research, Inc., 2003]
1.1 Heterogeneousness of platforms
1.1 Multiplicity of contexts of use TV is multi-media family device #1 Family Device Booking notification Everywhere conne...
1.1 Consequence <ul><li>Proliferation of developments </li></ul>UI #12 UI #11 UI #10 UI #9 Application 3 UI #8 UI #7 UI #6...
1.1 Consequence <ul><li>Why is it difficult? </li></ul><ul><ul><li>For the designer: </li></ul></ul><ul><ul><ul><li>Multip...
1.2 What does it cover? <ul><li>Conceptual modeling should cover </li></ul><ul><ul><li>Presentation: external manifestatio...
1.2 What does it cover? User Platform Domain Task Environment
1.3 Abstraction #1: the concrete UI <ul><li>Starting point: FUI = Final User Interface </li></ul><ul><ul><li>Mark-up langu...
1.3 Abstraction #1: the concrete UI <ul><li>Definitions </li></ul><ul><ul><li>Original: Abstract Interaction Object = abst...
1.3 Abstraction #1: the concrete UI <ul><li>Each graphicalCIO has specific properties such as isVisible, isEnabled, fgColo...
1.3 Abstraction #2: the abstract UI <ul><li>Different CIOs can be used for the same purpose, but with different interactio...
1.3 Abstraction #2: the abstract UI [ Limbourg, 2004 ]
1.3 Abstraction #2: the abstract UI <ul><li>Notation: based on canonical abstract prototypes:  Larry Constantine, Helmut W...
1.3 Abstraction #3: the task <ul><li>Task = set of actions carried out by a user in a given context to reach a goal </li><...
1.3 Abstraction #3: the task <ul><li>Task definition = action + object </li></ul><ul><ul><li>Action types </li></ul></ul><...
1.3 Abstraction #3: the task [ Limbourg, 2004 ]
1.3 Abstraction #4: the context of use <ul><li>Context of use= triple (U,P,E) where </li></ul><ul><ul><li>U is a user mode...
1.3 Abstraction #4: the context of use [ Limbourg, 2004 ]
1.3 Mapping the models [ Montero   et  al ., 2005 ] triggers (tg): {  ,  } x updates (up):   x observes (ob):   x isExecut...
1.3 Mapping the models <ul><li>Mapping the models with a mapping model (!!) </li></ul>[ Limbourg, 2004 ]
1.4 What do we have so far? Final User Interface (FUI) Concrete User Interface (CUI) Abstract User Interface ( AUI ) Task ...
1.4 What do we have so far? Concrete user Interface S Final user Interface S Task and  Domain S Abstract user Interface S ...
2. Forward engineering <ul><li>2.1 Task and domain models </li></ul><ul><li>2.2 From T&D to AUI </li></ul><ul><ul><li>Mode...
2.1 Task and domain models
2.1 Task and domain models [ Limbourg, 2004 ]
2.1 Task and domain models
2.2 From T&D to AUI <ul><li>Definition of AUI structure </li></ul><ul><ul><li>Which objects should be logically grouped?  ...
2.2 From T&D to AUI <ul><li>Definition of AUI structure </li></ul>[ Limbourg, 2004 ]
2.2 From T&D to AUI <ul><li>Definition of AIC types </li></ul>AC = Abstract Component AIC = Abstract Individual Component ...
2.2 From T&D to AUI <ul><li>Definition of spatio-temporal arrangement </li></ul>[ Limbourg, 2004 ]
2.2 From T&D to AUI <ul><li>All transformations are in UsiXML </li></ul><ul><ul><li>Each model = instance of meta-model </...
2.2 From T&D to AUI <ul><li>Typed model-to-model transformation </li></ul>Uses language Meta-Meta-Model Graph Structure  i...
2.2 From T&D to AUI <ul><li>TransformiXML </li></ul>
2.3 From AUI to CUI <ul><li>Definition of CUI structure </li></ul><ul><ul><li>Which AIC is a window?  </li></ul></ul><ul><...
2.3 From AUI to CUI <ul><li>Definition of CIO structure </li></ul>[ Limbourg, 2004 ] NAC LHS RHS ::= NAC LHS RHS ::=
2.3 From AUI to CUI <ul><li>Definition of placement </li></ul>[ Limbourg, 2004 ]
2.4 From CUI to FUI <ul><li>Model-to-code transformation </li></ul><ul><ul><li>By rendering (interpretation) </li></ul></u...
2.4 What do we have so far? Concrete user Interface S Final user Interface S Task and  Domain S Abstract user Interface S ...
3. Reverse engineering <ul><li>3.1 From FUI to CUI </li></ul><ul><li>3.2 From CUI to AUI, task & domain </li></ul>
3.1 From FUI to CUI <ul><li>Do you have the source code? </li></ul><ul><ul><li>Markup languages (e.g., HTML): static code ...
3.1 From FUI to CUI <ul><li>ReversiXML </li></ul>[ Bouillon &  Vanderdonckt , 2004 ]
3.2 From CUI to AUI, task & domain <ul><li>Code-to-model and model-to-model </li></ul><ul><ul><li>CUI to AUI </li></ul></u...
3.2 From CUI to AUI, task & domain <ul><li>Re-engineering = reverse + forward </li></ul><ul><li>Possible re-interpretation...
3.2 What do we have so far? Concrete user Interface S Final user Interface S Task and  Domain S Abstract user Interface S ...
3.2 What do we want to get? Final user Interface T Concrete user Interface T Task and  Domain T Abstract user Interface T ...
3.3 Lateral engineering <ul><li>Definition = model-to-model transformation applied at the same level of abstraction </li><...
Example 1: widget replacement (1) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;yes&quot;?> < ...
Example 1: widget replacement (2)
Example 1: widget replacement (3) The UsiXML graph before applying any rule
Example 1: widget replacement (4) LHS RHS NAC Rule 1: Create a new comboBox with the same  id  and  name  as the name of t...
Example 1: widget replacement (5) Rule 1: Create a new comboBox with the same  id  and  name  as the name of the group of ...
Example 1: widget replacement (6) LHS RHS ::= Rule 2: Convert every radioButton within the group “x” into an item for the ...
Example 1: widget replacement (7) Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”...
Example 1: widget replacement (8) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;yes&quot;?> < ...
Example 1: widget replacement (9)
Example 2: Adaptation <ul><li>Two forms of adaptation </li></ul><ul><ul><li>Adaptability: user-initiated </li></ul></ul><u...
Example 2: Plastic UI [ Grolaux , Van Roy,  Vanderdonckt , 2002 ]
Example 3: multimodal UI <ul><li>Need for additional abstraction </li></ul><ul><li>Additional transformation rules </li></...
Example 4: Crazy UIs <ul><li>Use the same model </li></ul><ul><ul><li>for 3D UI: Cube </li></ul></ul><ul><ul><li>for migra...
5. Conclusion <ul><li>A multi-path support of MDA </li></ul>UsiXML model: Abstract user interface UsiXML model: Concrete u...
5. Conclusion <ul><li>Conceptual modeling of UIs </li></ul><ul><ul><li>Separation of concerns is feasible </li></ul></ul><...
Future trend: sketching? [ Coyette  &  Vanderdonckt , 2005 ]
I would like to dedicate this talk to <ul><li>Prof. Em. François Bodart (Univ. of Namur, BE) for </li></ul><ul><ul><li>Ino...
I would like to thank <ul><li>BCHI team members for their involvement and their constant effort in the UsiXML initiative a...
I would like to thank <ul><li>João Falcão e Cunha, Oscar Pastor,  Nuno Jardim Nunes </li></ul><ul><li>The CAiSE Advisory C...
…  and you for your attention Free download and register USer Interface eXtensible Language http:// www.usixml.org SIMILAR...
Upcoming SlideShare
Loading in …5
×

A MDA-Compliant Environment for Developing User Interfaces of Information Systems

1,780 views

Published on

This presentation, entitled "A MDA-Compliant Environment for Developing User Interfaces of Information Systems" summarizes the characteristics of the User Interface eXtensible Markup Language, as a support for model-driven engineering of user interfaces. This presentation was the keynote address for the CAISE'2005 conference (Porto, June 16, 2005).

Published in: Business, Technology
  • Be the first to comment

A MDA-Compliant Environment for Developing User Interfaces of Information Systems

  1. 1. A MDA-Compliant Environment for Developing User Interfaces of Information Systems Jean Vanderdonckt [email_address] Head of BCHI Lab, http://www.isys.ucl.ac.be/bchi
  2. 2. « Everything you can imagine is real » (Picasso) « Everything you model can be turned into a real interface »
  3. 3. Outline <ul><li>Conceptual modeling of user interfaces </li></ul><ul><li>Forward engineering </li></ul><ul><li>Reverse engineering </li></ul><ul><li>Lateral engineering </li></ul><ul><li>Conclusion </li></ul>
  4. 4. 1.1 Why is conceptual modeling of user interfaces desirable? <ul><li>“ The presentation layer outside the scope of CSCD” (Antoni Olivé) </li></ul><ul><ul><li>A domain model is certainly not a presentation model, but there could be a mapping between </li></ul></ul><ul><li>UIs remained for many years the poor parent of conceptual modeling and software engineering </li></ul><ul><ul><li>It emerged during late 80’s </li></ul></ul><ul><ul><li>Still growing </li></ul></ul><ul><li>The complexity and the variety of user interfaces (UI) is dramatically increasing </li></ul><ul><li>The paradigm of « one system fits all » is no longer valid </li></ul>
  5. 5. 1.1 Diversity of users <ul><li>Traditional users </li></ul><ul><li>People with disabilities </li></ul><ul><ul><li>Visual, motor, cognitive </li></ul></ul>
  6. 6. 1.1 Variety of tasks <ul><li>Users want to determine their path on each platform </li></ul>[Forrester Research, Inc., 2003]
  7. 7. 1.1 Heterogeneousness of platforms
  8. 8. 1.1 Multiplicity of contexts of use TV is multi-media family device #1 Family Device Booking notification Everywhere connectivity for simple data exchange Travelling Travel booking site Powerful interface for complex operations Working Multimedia Travel programme Sporting Experience Role Location
  9. 9. 1.1 Consequence <ul><li>Proliferation of developments </li></ul>UI #12 UI #11 UI #10 UI #9 Application 3 UI #8 UI #7 UI #6 UI #5 Application 2 UI #4 UI #3 UI #2 UI #1 Application 1 Platform #4 Platform #3 Platform #2 Platform #1 Application 1 Application 2 Application 3 UI model #1 UI model #2 UI model #3 Platform #1 Platform #2 Platform #3 Platform #4 Platform model #1 Platform model #2 Platform model #3 Platform model #4
  10. 10. 1.1 Consequence <ul><li>Why is it difficult? </li></ul><ul><ul><li>For the designer: </li></ul></ul><ul><ul><ul><li>Multiplicity of contexts of use </li></ul></ul></ul><ul><ul><ul><li>No systematic design method </li></ul></ul></ul><ul><ul><li>For the user: </li></ul></ul><ul><ul><ul><li>Poor usability of resulting UI </li></ul></ul></ul><ul><ul><ul><li>UI not adapted to the genuine context of use </li></ul></ul></ul><ul><ul><li>For the developer: </li></ul></ul><ul><ul><ul><li>Increase of development and maintenance costs </li></ul></ul></ul><ul><ul><ul><li>Increasing development complexity </li></ul></ul></ul><ul><ul><ul><li>Little of no factoring out of common elements </li></ul></ul></ul>Fold & Drop technique : P. Dragicevic
  11. 11. 1.2 What does it cover? <ul><li>Conceptual modeling should cover </li></ul><ul><ul><li>Presentation: external manifestation of the UI that is perceivable to the user (static) </li></ul></ul><ul><ul><li>Dialog: ordering in time and space of operations performed by the user/system (dynamic) </li></ul></ul><ul><ul><li>Modalities of interaction </li></ul></ul><ul><ul><ul><li>Graphical </li></ul></ul></ul><ul><ul><ul><li>Vocal </li></ul></ul></ul><ul><ul><ul><li>Haptic, tactile </li></ul></ul></ul>
  12. 12. 1.2 What does it cover? User Platform Domain Task Environment
  13. 13. 1.3 Abstraction #1: the concrete UI <ul><li>Starting point: FUI = Final User Interface </li></ul><ul><ul><li>Mark-up languages: HTML, WML, cHTML </li></ul></ul><ul><ul><li>Programming languages: Visual Basic, Java </li></ul></ul><ul><li>Many manifestations of the same object </li></ul><ul><li>Abstraction with respect to the toolkit </li></ul><ul><ul><li>Presentation aspects </li></ul></ul><ul><ul><li>Events: generating, passing, controlling </li></ul></ul><ul><ul><li>Attributes: external (e.g., font) vs internal (e.g. state) </li></ul></ul><ul><ul><li>Primitives: life cycle </li></ul></ul>
  14. 14. 1.3 Abstraction #1: the concrete UI <ul><li>Definitions </li></ul><ul><ul><li>Original: Abstract Interaction Object = abstraction of the same Concrete Interaction Objects independently of their underlying presentation and dialog </li></ul></ul><ul><ul><li>We have introduced this abstraction in 1993! </li></ul></ul><ul><ul><li>Current: Concrete Interaction Object = abstraction of interaction objects with respect to the underlying toolkit </li></ul></ul>[ Vanderdonckt & Bodart , 1993 ] PR_IO_Create PR_IO_Display IO created IO displayed IO activated IO deactivated IO undisplayed IO destroyed PR_IO_Deactivate PR_OI_Erase PR_OI_Destroy PR_IO_Activate PR_IO_Activate PR_IO_ChangeAttribute
  15. 15. 1.3 Abstraction #1: the concrete UI <ul><li>Each graphicalCIO has specific properties such as isVisible, isEnabled, fgColor, and bgColor. </li></ul><ul><li>Each graphicalCIO is sub-typed into one of the two possible categories: graphicalContainer, and graphicalIndividualComponent </li></ul>CUI Model CUI Model CIO CIO graphicalCIO graphicalCIO graphicalContainer graphicalContainer graphicalIndividualComponent graphicalIndividualComponent GrafiXML [ Limbourg, 2004 ] CUI Model CIO graphicalCIO graphicalContainer graphicalIndividualComponent graphicalContainer graphicalIndividualComponent
  16. 16. 1.3 Abstraction #2: the abstract UI <ul><li>Different CIOs can be used for the same purpose, but with different interaction modalities </li></ul><ul><li>Definition </li></ul><ul><ul><li>Abstract Container = set of Abstract Individual Component </li></ul></ul><ul><ul><li>AIC = abstraction of CIOs of the same type, but independently of any interaction modality </li></ul></ul><ul><ul><li>Abstract User Interface (AUI) = decomposition into AC+AIC </li></ul></ul>
  17. 17. 1.3 Abstraction #2: the abstract UI [ Limbourg, 2004 ]
  18. 18. 1.3 Abstraction #2: the abstract UI <ul><li>Notation: based on canonical abstract prototypes: Larry Constantine, Helmut Windl, James Noble, & Lucy Lockwood: http:// www.forUse.com </li></ul>IdealXML [ Montero et al ., 2005 ] Abs.container A. component input output navigation control select
  19. 19. 1.3 Abstraction #3: the task <ul><li>Task = set of actions carried out by a user in a given context to reach a goal </li></ul><ul><li>Logical decomposition of task into sub-tasks </li></ul><ul><li>Temporal ordering: LOTOS operators </li></ul><ul><ul><li>T1 >> T2 Enabling </li></ul></ul><ul><ul><li>T1 [ ]>> T2 Enabling + information passing </li></ul></ul><ul><ul><li>T1 |> T2 Suspend/resume </li></ul></ul><ul><ul><li>T1 [ ] T2 Choice </li></ul></ul><ul><ul><li>T1 [> T2 Disabling (e.g. Form submit) </li></ul></ul><ul><ul><li>T1 |=| T2 Independence (any order, but finished) </li></ul></ul><ul><ul><li>T1* Iteration </li></ul></ul><ul><ul><li>T1{n} Finite iteration </li></ul></ul><ul><ul><li>T1 ||| T2 Concurrency </li></ul></ul><ul><ul><li>T1 |[x]| T2 Concurrency + information passing </li></ul></ul><ul><ul><li>[T] Optional </li></ul></ul><ul><ul><li>T Recursion </li></ul></ul>[Paternò et al ., 1997] CTTE Editor
  20. 20. 1.3 Abstraction #3: the task <ul><li>Task definition = action + object </li></ul><ul><ul><li>Action types </li></ul></ul><ul><ul><ul><li>Acquire, render, modify, publish, compute, derive,… </li></ul></ul></ul><ul><ul><li>Object types: </li></ul></ul><ul><ul><ul><li>Element, list, table, collection, compound,… </li></ul></ul></ul>
  21. 21. 1.3 Abstraction #3: the task [ Limbourg, 2004 ]
  22. 22. 1.3 Abstraction #4: the context of use <ul><li>Context of use= triple (U,P,E) where </li></ul><ul><ul><li>U is a user model: from cognitive psychology </li></ul></ul><ul><ul><li>P is a platform model: subset of UAProf (W3C) </li></ul></ul><ul><ul><li>E is an environment model: from ubiquitous computing </li></ul></ul>Pick & Drop technique : J. Rekimoto [ Cameleon project , 2004 ]
  23. 23. 1.3 Abstraction #4: the context of use [ Limbourg, 2004 ]
  24. 24. 1.3 Mapping the models [ Montero et al ., 2005 ] triggers (tg): { , } x updates (up): x observes (ob): x isExecutedIn (ex): x manipulates (ma): { , } x These mappings can be established:
  25. 25. 1.3 Mapping the models <ul><li>Mapping the models with a mapping model (!!) </li></ul>[ Limbourg, 2004 ]
  26. 26. 1.4 What do we have so far? Final User Interface (FUI) Concrete User Interface (CUI) Abstract User Interface ( AUI ) Task & Domain Rendering Code Modality-independent Abstract Individual Component Task Classes HTML push button Download Down Load Toolkit-independent Concrete Interaction Object Final User Interface (FUI) Concrete User Interface (CUI) Abstract User Interface ( AUI ) Task & Rendering Code Task Classes <input type=submit value=“Download&quot; name= Download Download Down Load Down Load Windows push button Method triggered: download a file Object: computer file OSF/Motif XmButton Graphical 2D push button Digital control AIC VRML97/X3D button Software key Function key Graphical 3D push button Physical push button Physical control AIC Control AIC
  27. 27. 1.4 What do we have so far? Concrete user Interface S Final user Interface S Task and Domain S Abstract user Interface S S=Source context of use UsiXML unsupported model UsiXML supported model User S Reification Platform S Environment S
  28. 28. 2. Forward engineering <ul><li>2.1 Task and domain models </li></ul><ul><li>2.2 From T&D to AUI </li></ul><ul><ul><li>Model-to-model transformation </li></ul></ul><ul><li>2.3 From AUI to CUI </li></ul><ul><ul><li>Model-to-model transformation </li></ul></ul><ul><li>2.4 From CUI to FUI </li></ul>[ Limbourg, 2004 ]
  29. 29. 2.1 Task and domain models
  30. 30. 2.1 Task and domain models [ Limbourg, 2004 ]
  31. 31. 2.1 Task and domain models
  32. 32. 2.2 From T&D to AUI <ul><li>Definition of AUI structure </li></ul><ul><ul><li>Which objects should be logically grouped? </li></ul></ul><ul><li>Definition of AIC types </li></ul><ul><ul><li>Which « functionnality » should assume AICs and what data do they manipulate ? </li></ul></ul><ul><li>Definition of spatio-temporal arrangement </li></ul><ul><ul><li>How should AIC be arranged in space and/or in time ? </li></ul></ul><ul><li>Definition of dialog control </li></ul><ul><ul><li>What is the valid flow of action on AIOs ? </li></ul></ul>[ Limbourg, 2004 ]
  33. 33. 2.2 From T&D to AUI <ul><li>Definition of AUI structure </li></ul>[ Limbourg, 2004 ]
  34. 34. 2.2 From T&D to AUI <ul><li>Definition of AIC types </li></ul>AC = Abstract Component AIC = Abstract Individual Component CIC = Concrete Interaction Component [ Limbourg, 2004 ]
  35. 35. 2.2 From T&D to AUI <ul><li>Definition of spatio-temporal arrangement </li></ul>[ Limbourg, 2004 ]
  36. 36. 2.2 From T&D to AUI <ul><li>All transformations are in UsiXML </li></ul><ul><ul><li>Each model = instance of meta-model </li></ul></ul><ul><ul><li>Each model = graph as instance of graph type </li></ul></ul><ul><ul><li>Each model-to-model transformation = </li></ul></ul><ul><ul><ul><li>graph transformation </li></ul></ul></ul><ul><ul><ul><li>Set of productions </li></ul></ul></ul>
  37. 37. 2.2 From T&D to AUI <ul><li>Typed model-to-model transformation </li></ul>Uses language Meta-Meta-Model Graph Structure is instance of Meta-Model Our 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 Our transformation catalog [ Limbourg, 2004 ]
  38. 38. 2.2 From T&D to AUI <ul><li>TransformiXML </li></ul>
  39. 39. 2.3 From AUI to CUI <ul><li>Definition of CUI structure </li></ul><ul><ul><li>Which AIC is a window? </li></ul></ul><ul><li>Definition of CIO type </li></ul><ul><ul><li>Which « widget » should represent which AIO ? </li></ul></ul><ul><li>Definition of placement </li></ul><ul><ul><li>What layout can be specified between CIOs </li></ul></ul><ul><ul><li>Definition of navigation </li></ul></ul><ul><ul><li>Which container can be started or closed from which container? </li></ul></ul><ul><li>Definition of dialog control </li></ul><ul><ul><li>What is the dialog local to each CIO? </li></ul></ul><ul><ul><li>What is the valid flow of action on CIOs? </li></ul></ul>[ Limbourg, 2004 ]
  40. 40. 2.3 From AUI to CUI <ul><li>Definition of CIO structure </li></ul>[ Limbourg, 2004 ] NAC LHS RHS ::= NAC LHS RHS ::=
  41. 41. 2.3 From AUI to CUI <ul><li>Definition of placement </li></ul>[ Limbourg, 2004 ]
  42. 42. 2.4 From CUI to FUI <ul><li>Model-to-code transformation </li></ul><ul><ul><li>By rendering (interpretation) </li></ul></ul><ul><ul><ul><li>Java ( InterpiXML ) </li></ul></ul></ul><ul><ul><ul><li>Tcl/tk ( QtkiXML ) </li></ul></ul></ul><ul><ul><ul><li>Flash ( FlashiXML ) </li></ul></ul></ul><ul><ul><li>By code generation </li></ul></ul><ul><ul><ul><li>HTML </li></ul></ul></ul><ul><ul><ul><li>Visual Basic </li></ul></ul></ul>
  43. 43. 2.4 What do we have so far? Concrete user Interface S Final user Interface S Task and Domain S Abstract user Interface S S=Source context of use UsiXML unsupported model UsiXML supported model User S Reification Abstraction Platform S Environment S
  44. 44. 3. Reverse engineering <ul><li>3.1 From FUI to CUI </li></ul><ul><li>3.2 From CUI to AUI, task & domain </li></ul>
  45. 45. 3.1 From FUI to CUI <ul><li>Do you have the source code? </li></ul><ul><ul><li>Markup languages (e.g., HTML): static code analysis ( ReversiXML ) </li></ul></ul><ul><li>Do you have the compiled code? </li></ul><ul><ul><li>Programming languages (e.g., compiled C): resource file extraction and static code analysis </li></ul></ul><ul><li>Do you have the running application? </li></ul><ul><ul><li>Video analysis: computer vision </li></ul></ul><ul><li>Do you have only the documentation? </li></ul><ul><ul><li>Image analysis: image processing </li></ul></ul>[ Bouillon & Vanderdonckt , 2004 ]
  46. 46. 3.1 From FUI to CUI <ul><li>ReversiXML </li></ul>[ Bouillon & Vanderdonckt , 2004 ]
  47. 47. 3.2 From CUI to AUI, task & domain <ul><li>Code-to-model and model-to-model </li></ul><ul><ul><li>CUI to AUI </li></ul></ul>[ Limbourg, 2004 ]
  48. 48. 3.2 From CUI to AUI, task & domain <ul><li>Re-engineering = reverse + forward </li></ul><ul><li>Possible re-interpretation by QtkiXML </li></ul>[Bouillon & Vanderdonckt, 2004]
  49. 49. 3.2 What do we have so far? Concrete user Interface S Final user Interface S Task and Domain S Abstract user Interface S S=Source context of use UsiXML unsupported model UsiXML supported model User S Reification Abstraction Platform S Environment S
  50. 50. 3.2 What do we want to get? Final user Interface T Concrete user Interface T Task and Domain T Abstract user Interface T T=Target context of use Concrete user Interface S Final user Interface S Task and Domain S Abstract user Interface S S=Source context of use http://www.plasticity.org UsiXML unsupported model UsiXML supported model User S User T [ Cameleon project , 2004 ] Environment T Reification Abstraction Reflexion Translation Platform S Environment S Platform T
  51. 51. 3.3 Lateral engineering <ul><li>Definition = model-to-model transformation applied at the same level of abstraction </li></ul><ul><ul><li>Same context of use </li></ul></ul><ul><ul><li>Across various contexts of use </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Simple CUI adaptation: widget replacement </li></ul></ul><ul><ul><li>Design-time vs run-time adaptation </li></ul></ul>
  52. 52. Example 1: widget replacement (1) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;yes&quot;?> < cuiModel name =&quot; MyModel &quot;> < version modifDate =&quot; 2004-03-24T17:09:17.402+01:00 &quot; xmlns =&quot;&quot;> 7 </ version > < authorName xmlns =&quot;&quot;> Youri </ authorName > < window height =&quot; 500 &quot; width =&quot; 600 &quot; name =&quot; Formulaire (2/5) &quot; id =&quot; window_1 &quot;> < box relativeHeight =&quot; 100 &quot; name =&quot; box1_0 &quot; id =&quot; box1_0 &quot;> < box type =&quot; vert &quot; name =&quot; boxTodo &quot; id =&quot; boxTodo &quot;> ... < box type =&quot; horiz &quot; name =&quot; box_2_2_2_1 &quot; id =&quot; box_2_2_2_1 &quot;> < textComponent defaultContent =&quot; Sexe &quot; isBold =&quot; true &quot; id =&quot; label_2 &quot;/> < radioButton groupName =“ grupo01 &quot; defaultContent =&quot; Femme &quot; defaultState =&quot; false &quot; id =&quot; radiobutton_0 &quot;/> < radioButton groupName =&quot; grupo01 &quot; defaultContent =&quot; Homme &quot; defaultState =&quot; true &quot; id =&quot; radiobutton_1 &quot;/> </ box > ... </ box > </ box > </ window > </ cuiModel > Excerpt for an usiXML CUI specification. [ Limbourg et al ., 2004 ]
  53. 53. Example 1: widget replacement (2)
  54. 54. Example 1: widget replacement (3) The UsiXML graph before applying any rule
  55. 55. Example 1: widget replacement (4) LHS RHS NAC Rule 1: Create a new comboBox with the same id and name as the name of the group of radioButtons. [ Limbourg et al ., 2004 ]
  56. 56. Example 1: widget replacement (5) 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
  57. 57. Example 1: widget replacement (6) LHS RHS ::= Rule 2: Convert every radioButton within the group “x” into an item for the comboBox “x”, we have just created. [ Limbourg et al ., 2004 ]
  58. 58. Example 1: widget replacement (7) 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
  59. 59. Example 1: widget replacement (8) <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;yes&quot;?> < cuiModel name =&quot; MyModel &quot;> < version modifDate =&quot; 2004-03-24T17:09:17.402+01:00 &quot; xmlns =&quot;&quot;> 7 </ version > < authorName xmlns =&quot;&quot;> Youri </ authorName > < window height =&quot; 500 &quot; width =&quot; 600 &quot; name =&quot; Formulaire (2/5) &quot; id =&quot; window_1 &quot;> < box relativeHeight =&quot; 100 &quot; name =&quot; box1_0 &quot; id =&quot; box1_0 &quot;> < box type =&quot; vert &quot; name =&quot; boxTodo &quot; id =&quot; boxTodo &quot;> ... < box type =&quot; horiz &quot; name =&quot; box_2_2_2_1 &quot; id =&quot; box_2_2_2_1 &quot;> < textComponent defaultContent =&quot; Sexe &quot; isBold =&quot; true &quot; id =&quot; label_2 &quot;/> < comboBox id =&quot; comboBox001 &quot; name =&quot; label_3 &quot; isDropDown =&quot; true &quot;> < item id =&quot; radiobutton_0 &quot; name =&quot; radiobutton_0 &quot; defaultContent =&quot; Femme &quot;/> < item id =&quot; radiobutton_1 &quot; name =&quot; radiobutton_1 &quot; defaultContent =&quot; Homme &quot;/> </ comboBox > ... </ box > </ box > </ window > </ cuiModel > Excerpt from the final transformated usiXML specification
  60. 60. Example 1: widget replacement (9)
  61. 61. Example 2: Adaptation <ul><li>Two forms of adaptation </li></ul><ul><ul><li>Adaptability: user-initiated </li></ul></ul><ul><ul><li>Adaptivity: system-initiated </li></ul></ul><ul><li>Four steps: user, system, third party, combination </li></ul><ul><ul><li>Detection </li></ul></ul><ul><ul><li>Computation </li></ul></ul><ul><ul><li>Decision </li></ul></ul><ul><ul><li>Execution </li></ul></ul><ul><li>2 Adaptivity forms </li></ul><ul><ul><li>UI remain the same: vectorial UIs </li></ul></ul><ul><ul><li>UI change at run-time: plastic UIs </li></ul></ul>
  62. 62. Example 2: Plastic UI [ Grolaux , Van Roy, Vanderdonckt , 2002 ]
  63. 63. Example 3: multimodal UI <ul><li>Need for additional abstraction </li></ul><ul><li>Additional transformation rules </li></ul>[ Stanciulescu , Limbourg, Michotte , Vanderdonckt , 2005 ]
  64. 64. Example 4: Crazy UIs <ul><li>Use the same model </li></ul><ul><ul><li>for 3D UI: Cube </li></ul></ul><ul><ul><li>for migration across platforms in virtual reality: MigriXML </li></ul></ul>[ Molina, Vanderdonckt , Gonzalez, 2005 ]
  65. 65. 5. Conclusion <ul><li>A multi-path support of MDA </li></ul>UsiXML model: Abstract user interface UsiXML model: Concrete user interface Rendering Final user interface UsiXML models: task, domain Generative programming Graph transformations Graph transformations Derivation rules IdealXML ReversiXML FlashiXML VisualiXML TransformiXML GrafiXML VisiXML SketchiXML FormiXML KnowiXML
  66. 66. 5. Conclusion <ul><li>Conceptual modeling of UIs </li></ul><ul><ul><li>Separation of concerns is feasible </li></ul></ul><ul><ul><li>Correlability of models is required </li></ul></ul><ul><ul><li>It is possible to have multiple abstractions on demand </li></ul></ul><ul><ul><li>Not all models should be involved </li></ul></ul><ul><ul><li>Everything is in UsiXML </li></ul></ul><ul><ul><li>Extreme modeling or extreme engineering </li></ul></ul><ul><ul><ul><li>Everything is in the model: relatively easy </li></ul></ul></ul><ul><ul><ul><li>Model-to-model transformation: harder </li></ul></ul></ul><ul><ul><ul><li>Model-to-code generation: hardest </li></ul></ul></ul><ul><li>Industrial practise </li></ul><ul><ul><li>Multi-path development </li></ul></ul><ul><ul><li>Sketching of UI </li></ul></ul>
  67. 67. Future trend: sketching? [ Coyette & Vanderdonckt , 2005 ]
  68. 68. I would like to dedicate this talk to <ul><li>Prof. Em. François Bodart (Univ. of Namur, BE) for </li></ul><ul><ul><li>Inoculating me the virus of (meta-)modeling and structured design of information systems </li></ul></ul><ul><ul><li>Sharing with me his vision about user interfaces and interactive information systems </li></ul></ul>
  69. 69. I would like to thank <ul><li>BCHI team members for their involvement and their constant effort in the UsiXML initiative among others </li></ul><ul><ul><li>Laurent Bouillon : ReversiXML, UsiXML </li></ul></ul><ul><ul><li>Benoît Collignon : PlastiXML </li></ul></ul><ul><ul><li>Adrien Coyette : SketchiXML </li></ul></ul><ul><ul><li>Murielle Florins : Graceful degradation </li></ul></ul><ul><ul><li>Monica Gemo : multi-platform UIs and annotations </li></ul></ul><ul><ul><li>Juan Gonzalez : 3D UsiXML </li></ul></ul><ul><ul><li>Donatien Grolaux : detachable UIs, DistriXML </li></ul></ul><ul><ul><li>Josefina Guerrero : UIs for workflows </li></ul></ul><ul><ul><li>Quentin Limbourg : multi-path development, UsiXML, all tools </li></ul></ul><ul><ul><li>Céline Mariage : MetroWeb, guidelines </li></ul></ul><ul><ul><li>Benjamin Michotte : GrafiXML, TransformiXML, UsiXML </li></ul></ul><ul><ul><li>José Pascual Molina : MigriXML, VUIToolkit </li></ul></ul><ul><ul><li>Francisco Montero : IdealXML </li></ul></ul><ul><ul><li>Adrian Stanciulescu : ModaliXML, UsiXML </li></ul></ul><ul><ul><li>Daniela Trevisan : augmented reality </li></ul></ul><ul><ul><li>… </li></ul></ul>
  70. 70. I would like to thank <ul><li>João Falcão e Cunha, Oscar Pastor, Nuno Jardim Nunes </li></ul><ul><li>The CAiSE Advisory Committee </li></ul><ul><ul><li>Janice Bubenko </li></ul></ul><ul><ul><li>Collette Roland </li></ul></ul><ul><ul><li>Arne Solvberg </li></ul></ul>
  71. 71. … and you for your attention Free download and register USer Interface eXtensible Language http:// www.usixml.org SIMILAR, the European task force making user interfaces similar to human-to-human communication http:// www.similar.cc Home Page of BCHI Lab http:// www.isys.ucl.ac.be / bchi

×