Model-driven engineering (MDE) of user interfaces consists in describing a user interface and aspects involved in it (e.g., task, domain, context of use) in models from which a final interface is produced. With one big win in mind: when the user’s requirements or the context of use change, the models change accordingly and so does the supporting user interface. Models and a method for developing user interfaces based on MDE are presented in this tutorial supporting forward engineering (a new interface is produced), reverse engineering (an existing interface is improved), and lateral engineering (an existing interface is adapted to a new context of use). Software supporting this method will be used based on UsiXML (User Interface eXten-sible Markup Language), a XML-compliant user interface description language.

1. Model-Driven Engineering of User Interfaces: Promises, Successes, Failures, and Challenges Jean Vanderdonckt Université catholique de Louvain (UCL) Louvain School of Management (LSM) Information Systems Unit (ISYS) Belgian Laboratory of Computer-Human Interaction (BCHI) http://www.isys.ucl.ac.be/bchi Place des Doyens, 1 – B-1348 Louvain-la-Neuve (Belgium)

26. Do we need more models? Demo FlashiXML

29. So what we have now is Concrete user Interface S Final user Interface S Task and Domain S Abstract user Interface S S=Source context of use User S [Calvary et al.,2003] In GrafiXML Platform S Environment S

32. Graceful degradation [Florins & Vanderdonckt,2004]

33. Transformation rules

34. Transformation rules Add all >> Add > << Remove all < Remove >> > << < > < Group box Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 1 Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7

35. Transformation rules

42. Preference example Problem Solution 1 Solution 2 (RE1) (RE2) suggests suggests avoids contradicts respects = for = against (A1) = drop down list requires less space than radio buttons (A2) = some possible values become obsolete when they are infrequently used (A3) = drop down list shows better then current value than the possible values (A4) = radio buttons are faster and easier to manipulate than drop down list (A5) = radio buttons are recommended in Microsoft Windows style guide (A6) = radio buttons do not allow users to change the values drop down list radio buttons (A4) is contradicted by (A2) and (A3) : the widget should be more used for output than input. (A6) is contradicted by (A3) : it is better to present all possible values than only one at a time (A5) is an autority argument , and can fall in front of (A1)+(A2)+(A3) [Vanderdonckt,1997] (A1) (A2) (A3) (A4) (A5) (A6) Standard compatibility (e.g. Windows) Cognitive respect Minimal actions Dialog representativity Prompting Clarity contradicts

43. Theory of argumentation [Toulmin,1975] [Perelman, 1978] Design problem Design option parameter (parameter, value) Is described by Is solved by Accepted solution Set of admissible solutions Solution 1 Solution 2 Solution n Counter-argument (rebuttal, counter-claim) Argument (ground, typically data) can be rejected because of Can be accepted thanks to Is justified by Design claim Warrant Is reinforced by Qualifier satisfied unsatisfied Is related to corresponds to Is justified by Is qualified by

46. Revisitation [Bouillon,2006]

52. Demonstration DistriXML [Grolaux & Vanderdonckt,2005]

53. Demonstration using two displays from two different computers DistriXML

54. Example using a Pocket PC DistriXML

59. This is not a floating toolbar Process DistriXML

60. This is migration ! Computer B Process Process Computer A DistriXML

66. Thank you very much for your attention For more information and downloading, http://www.isys.ucl.ac.be/bchi http://www.usixml.org User Interface eXtensible Markup Language http://www.similar.cc European network on Multimodal UIs