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

« Everything you can imagine is real » (Picasso) « Everything you model can be turned into a real interface »

Outline Conceptual modeling of user interfaces Forward engineering Reverse engineering Lateral engineering Conclusion

Conceptual modeling of user interfaces

Forward engineering

Reverse engineering

Lateral engineering

Conclusion

1.1 Why is conceptual modeling of user interfaces desirable? “ The presentation layer outside the scope of CSCD” (Antoni Olivé) A domain model is certainly not a presentation model, but there could be a mapping between UIs remained for many years the poor parent of conceptual modeling and software engineering It emerged during late 80’s Still growing The complexity and the variety of user interfaces (UI) is dramatically increasing The paradigm of « one system fits all » is no longer valid

“ The presentation layer outside the scope of CSCD” (Antoni Olivé)

A domain model is certainly not a presentation model, but there could be a mapping between

UIs remained for many years the poor parent of conceptual modeling and software engineering

It emerged during late 80’s

Still growing

The complexity and the variety of user interfaces (UI) is dramatically increasing

The paradigm of « one system fits all » is no longer valid

1.1 Diversity of users Traditional users People with disabilities Visual, motor, cognitive

Traditional users

People with disabilities

Visual, motor, cognitive

1.1 Variety of tasks Users want to determine their path on each platform [Forrester Research, Inc., 2003]

Users want to determine their path on each platform

1.1 Heterogeneousness of platforms

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

1.1 Consequence Proliferation of developments 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

Proliferation of developments

1.1 Consequence Why is it difficult? For the designer: Multiplicity of contexts of use No systematic design method For the user: Poor usability of resulting UI UI not adapted to the genuine context of use For the developer: Increase of development and maintenance costs Increasing development complexity Little of no factoring out of common elements Fold & Drop technique : P. Dragicevic

Why is it difficult?

For the designer:

Multiplicity of contexts of use

No systematic design method

For the user:

Poor usability of resulting UI

UI not adapted to the genuine context of use

For the developer:

Increase of development and maintenance costs

Increasing development complexity

Little of no factoring out of common elements

1.2 What does it cover? Conceptual modeling should cover Presentation: external manifestation of the UI that is perceivable to the user (static) Dialog: ordering in time and space of operations performed by the user/system (dynamic) Modalities of interaction Graphical Vocal Haptic, tactile

Conceptual modeling should cover

Presentation: external manifestation of the UI that is perceivable to the user (static)

Dialog: ordering in time and space of operations performed by the user/system (dynamic)

Modalities of interaction

Graphical

Vocal

Haptic, tactile

1.2 What does it cover? User Platform Domain Task Environment

1.3 Abstraction #1: the concrete UI Starting point: FUI = Final User Interface Mark-up languages: HTML, WML, cHTML Programming languages: Visual Basic, Java Many manifestations of the same object Abstraction with respect to the toolkit Presentation aspects Events: generating, passing, controlling Attributes: external (e.g., font) vs internal (e.g. state) Primitives: life cycle

Starting point: FUI = Final User Interface

Mark-up languages: HTML, WML, cHTML

Programming languages: Visual Basic, Java

Many manifestations of the same object

Abstraction with respect to the toolkit

Presentation aspects

Events: generating, passing, controlling

Attributes: external (e.g., font) vs internal (e.g. state)

Primitives: life cycle

1.3 Abstraction #1: the concrete UI Definitions Original: Abstract Interaction Object = abstraction of the same Concrete Interaction Objects independently of their underlying presentation and dialog We have introduced this abstraction in 1993! Current: Concrete Interaction Object = abstraction of interaction objects with respect to the underlying toolkit [ 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

Definitions

Original: Abstract Interaction Object = abstraction of the same Concrete Interaction Objects independently of their underlying presentation and dialog

We have introduced this abstraction in 1993!

Current: Concrete Interaction Object = abstraction of interaction objects with respect to the underlying toolkit

1.3 Abstraction #1: the concrete UI Each graphicalCIO has specific properties such as isVisible, isEnabled, fgColor, and bgColor. Each graphicalCIO is sub-typed into one of the two possible categories: graphicalContainer, and graphicalIndividualComponent CUI Model CUI Model CIO CIO graphicalCIO graphicalCIO graphicalContainer graphicalContainer graphicalIndividualComponent graphicalIndividualComponent GrafiXML [ Limbourg, 2004 ] CUI Model CIO graphicalCIO graphicalContainer graphicalIndividualComponent graphicalContainer graphicalIndividualComponent

Each graphicalCIO has specific properties such as isVisible, isEnabled, fgColor, and bgColor.

Each graphicalCIO is sub-typed into one of the two possible categories: graphicalContainer, and graphicalIndividualComponent

1.3 Abstraction #2: the abstract UI Different CIOs can be used for the same purpose, but with different interaction modalities Definition Abstract Container = set of Abstract Individual Component AIC = abstraction of CIOs of the same type, but independently of any interaction modality Abstract User Interface (AUI) = decomposition into AC+AIC

Different CIOs can be used for the same purpose, but with different interaction modalities

Definition

Abstract Container = set of Abstract Individual Component

AIC = abstraction of CIOs of the same type, but independently of any interaction modality

Abstract User Interface (AUI) = decomposition into AC+AIC

1.3 Abstraction #2: the abstract UI [ Limbourg, 2004 ]

1.3 Abstraction #2: the abstract UI Notation: based on canonical abstract prototypes: Larry Constantine, Helmut Windl, James Noble, & Lucy Lockwood: http:// www.forUse.com IdealXML [ Montero et al ., 2005 ] Abs.container A. component input output navigation control select

Notation: based on canonical abstract prototypes: Larry Constantine, Helmut Windl, James Noble, & Lucy Lockwood: http:// www.forUse.com

1.3 Abstraction #3: the task Task = set of actions carried out by a user in a given context to reach a goal Logical decomposition of task into sub-tasks Temporal ordering: LOTOS operators T1 >> T2 Enabling T1 [ ]>> T2 Enabling + information passing T1 |> T2 Suspend/resume T1 [ ] T2 Choice T1 [> T2 Disabling (e.g. Form submit) T1 |=| T2 Independence (any order, but finished) T1* Iteration T1{n} Finite iteration T1 ||| T2 Concurrency T1 |[x]| T2 Concurrency + information passing [T] Optional T Recursion [Paternò et al ., 1997] CTTE Editor

Task = set of actions carried out by a user in a given context to reach a goal

Logical decomposition of task into sub-tasks

Temporal ordering: LOTOS operators

T1 >> T2 Enabling

T1 [ ]>> T2 Enabling + information passing

T1 |> T2 Suspend/resume

T1 [ ] T2 Choice

T1 [> T2 Disabling (e.g. Form submit)

T1 |=| T2 Independence (any order, but finished)

T1* Iteration

T1{n} Finite iteration

T1 ||| T2 Concurrency

T1 |[x]| T2 Concurrency + information passing

[T] Optional

T Recursion

1.3 Abstraction #3: the task Task definition = action + object Action types Acquire, render, modify, publish, compute, derive,… Object types: Element, list, table, collection, compound,…

Task definition = action + object

Action types

Acquire, render, modify, publish, compute, derive,…

Object types:

Element, list, table, collection, compound,…

1.3 Abstraction #3: the task [ Limbourg, 2004 ]

1.3 Abstraction #4: the context of use Context of use= triple (U,P,E) where U is a user model: from cognitive psychology P is a platform model: subset of UAProf (W3C) E is an environment model: from ubiquitous computing Pick & Drop technique : J. Rekimoto [ Cameleon project , 2004 ]

Context of use= triple (U,P,E) where

U is a user model: from cognitive psychology

P is a platform model: subset of UAProf (W3C)

E is an environment model: from ubiquitous computing

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 isExecutedIn (ex): x manipulates (ma): { , } x These mappings can be established:

1.3 Mapping the models Mapping the models with a mapping model (!!) [ Limbourg, 2004 ]

Mapping the models with a mapping model (!!)

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

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

2. Forward engineering 2.1 Task and domain models 2.2 From T&D to AUI Model-to-model transformation 2.3 From AUI to CUI Model-to-model transformation 2.4 From CUI to FUI [ Limbourg, 2004 ]

2.1 Task and domain models

2.2 From T&D to AUI

Model-to-model transformation

2.3 From AUI to CUI

Model-to-model transformation

2.4 From CUI to FUI

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 Definition of AUI structure Which objects should be logically grouped? Definition of AIC types Which « functionnality » should assume AICs and what data do they manipulate ? Definition of spatio-temporal arrangement How should AIC be arranged in space and/or in time ? Definition of dialog control What is the valid flow of action on AIOs ? [ Limbourg, 2004 ]

Definition of AUI structure

Which objects should be logically grouped?

Definition of AIC types

Which « functionnality » should assume AICs and what data do they manipulate ?

Definition of spatio-temporal arrangement

How should AIC be arranged in space and/or in time ?

Definition of dialog control

What is the valid flow of action on AIOs ?

2.2 From T&D to AUI Definition of AUI structure [ Limbourg, 2004 ]

Definition of AUI structure

2.2 From T&D to AUI Definition of AIC types AC = Abstract Component AIC = Abstract Individual Component CIC = Concrete Interaction Component [ Limbourg, 2004 ]

Definition of AIC types

2.2 From T&D to AUI Definition of spatio-temporal arrangement [ Limbourg, 2004 ]

Definition of spatio-temporal arrangement

2.2 From T&D to AUI All transformations are in UsiXML Each model = instance of meta-model Each model = graph as instance of graph type Each model-to-model transformation = graph transformation Set of productions

All transformations are in UsiXML

Each model = instance of meta-model

Each model = graph as instance of graph type

Each model-to-model transformation =

graph transformation

Set of productions

2.2 From T&D to AUI Typed model-to-model transformation 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 ]

Typed model-to-model transformation

2.2 From T&D to AUI TransformiXML

TransformiXML

2.3 From AUI to CUI Definition of CUI structure Which AIC is a window? Definition of CIO type Which « widget » should represent which AIO ? Definition of placement What layout can be specified between CIOs Definition of navigation Which container can be started or closed from which container? Definition of dialog control What is the dialog local to each CIO? What is the valid flow of action on CIOs? [ Limbourg, 2004 ]

Definition of CUI structure

Which AIC is a window?

Definition of CIO type

Which « widget » should represent which AIO ?

Definition of placement

What layout can be specified between CIOs

Definition of navigation

Which container can be started or closed from which container?

Definition of dialog control

What is the dialog local to each CIO?

What is the valid flow of action on CIOs?

2.3 From AUI to CUI Definition of CIO structure [ Limbourg, 2004 ] NAC LHS RHS ::= NAC LHS RHS ::=

Definition of CIO structure

2.3 From AUI to CUI Definition of placement [ Limbourg, 2004 ]

Definition of placement

2.4 From CUI to FUI Model-to-code transformation By rendering (interpretation) Java ( InterpiXML ) Tcl/tk ( QtkiXML ) Flash ( FlashiXML ) By code generation HTML Visual Basic

Model-to-code transformation

By rendering (interpretation)

Java ( InterpiXML )

Tcl/tk ( QtkiXML )

Flash ( FlashiXML )

By code generation

HTML

Visual Basic

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

3. Reverse engineering 3.1 From FUI to CUI 3.2 From CUI to AUI, task & domain

3.1 From FUI to CUI

3.2 From CUI to AUI, task & domain

3.1 From FUI to CUI Do you have the source code? Markup languages (e.g., HTML): static code analysis ( ReversiXML ) Do you have the compiled code? Programming languages (e.g., compiled C): resource file extraction and static code analysis Do you have the running application? Video analysis: computer vision Do you have only the documentation? Image analysis: image processing [ Bouillon & Vanderdonckt , 2004 ]

Do you have the source code?

Markup languages (e.g., HTML): static code analysis ( ReversiXML )

Do you have the compiled code?

Programming languages (e.g., compiled C): resource file extraction and static code analysis

Do you have the running application?

Video analysis: computer vision

Do you have only the documentation?

Image analysis: image processing

3.1 From FUI to CUI ReversiXML [ Bouillon & Vanderdonckt , 2004 ]

ReversiXML

3.2 From CUI to AUI, task & domain Code-to-model and model-to-model CUI to AUI [ Limbourg, 2004 ]

Code-to-model and model-to-model

CUI to AUI

3.2 From CUI to AUI, task & domain Re-engineering = reverse + forward Possible re-interpretation by QtkiXML [Bouillon & Vanderdonckt, 2004]

Re-engineering = reverse + forward

Possible re-interpretation by QtkiXML

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

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

3.3 Lateral engineering Definition = model-to-model transformation applied at the same level of abstraction Same context of use Across various contexts of use Examples Simple CUI adaptation: widget replacement Design-time vs run-time adaptation

Definition = model-to-model transformation applied at the same level of abstraction

Same context of use

Across various contexts of use

Examples

Simple CUI adaptation: widget replacement

Design-time vs run-time adaptation

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 ]

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 the group of radioButtons. [ Limbourg et al ., 2004 ]

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

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 ]

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

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

Example 1: widget replacement (9)

Example 2: Adaptation Two forms of adaptation Adaptability: user-initiated Adaptivity: system-initiated Four steps: user, system, third party, combination Detection Computation Decision Execution 2 Adaptivity forms UI remain the same: vectorial UIs UI change at run-time: plastic UIs

Two forms of adaptation

Adaptability: user-initiated

Adaptivity: system-initiated

Four steps: user, system, third party, combination

Detection

Computation

Decision

Execution

2 Adaptivity forms

UI remain the same: vectorial UIs

UI change at run-time: plastic UIs

Example 2: Plastic UI [ Grolaux , Van Roy, Vanderdonckt , 2002 ]

Example 3: multimodal UI Need for additional abstraction Additional transformation rules [ Stanciulescu , Limbourg, Michotte , Vanderdonckt , 2005 ]

Need for additional abstraction

Additional transformation rules

Example 4: Crazy UIs Use the same model for 3D UI: Cube for migration across platforms in virtual reality: MigriXML [ Molina, Vanderdonckt , Gonzalez, 2005 ]

Use the same model

for 3D UI: Cube

for migration across platforms in virtual reality: MigriXML

5. Conclusion A multi-path support of MDA 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

A multi-path support of MDA

5. Conclusion Conceptual modeling of UIs Separation of concerns is feasible Correlability of models is required It is possible to have multiple abstractions on demand Not all models should be involved Everything is in UsiXML Extreme modeling or extreme engineering Everything is in the model: relatively easy Model-to-model transformation: harder Model-to-code generation: hardest Industrial practise Multi-path development Sketching of UI

Conceptual modeling of UIs

Separation of concerns is feasible

Correlability of models is required

It is possible to have multiple abstractions on demand

Not all models should be involved

Everything is in UsiXML

Extreme modeling or extreme engineering

Everything is in the model: relatively easy

Model-to-model transformation: harder

Model-to-code generation: hardest

Industrial practise

Multi-path development

Sketching of UI

Future trend: sketching? [ Coyette & Vanderdonckt , 2005 ]

I would like to dedicate this talk to Prof. Em. François Bodart (Univ. of Namur, BE) for Inoculating me the virus of (meta-)modeling and structured design of information systems Sharing with me his vision about user interfaces and interactive information systems

Prof. Em. François Bodart (Univ. of Namur, BE) for

Inoculating me the virus of (meta-)modeling and structured design of information systems

Sharing with me his vision about user interfaces and interactive information systems

I would like to thank BCHI team members for their involvement and their constant effort in the UsiXML initiative among others Laurent Bouillon : ReversiXML, UsiXML Benoît Collignon : PlastiXML Adrien Coyette : SketchiXML Murielle Florins : Graceful degradation Monica Gemo : multi-platform UIs and annotations Juan Gonzalez : 3D UsiXML Donatien Grolaux : detachable UIs, DistriXML Josefina Guerrero : UIs for workflows Quentin Limbourg : multi-path development, UsiXML, all tools Céline Mariage : MetroWeb, guidelines Benjamin Michotte : GrafiXML, TransformiXML, UsiXML José Pascual Molina : MigriXML, VUIToolkit Francisco Montero : IdealXML Adrian Stanciulescu : ModaliXML, UsiXML Daniela Trevisan : augmented reality …

BCHI team members for their involvement and their constant effort in the UsiXML initiative among others

Laurent Bouillon : ReversiXML, UsiXML

Benoît Collignon : PlastiXML

Adrien Coyette : SketchiXML

Murielle Florins : Graceful degradation

Monica Gemo : multi-platform UIs and annotations

Juan Gonzalez : 3D UsiXML

Donatien Grolaux : detachable UIs, DistriXML

Josefina Guerrero : UIs for workflows

Quentin Limbourg : multi-path development, UsiXML, all tools

Céline Mariage : MetroWeb, guidelines

Benjamin Michotte : GrafiXML, TransformiXML, UsiXML

José Pascual Molina : MigriXML, VUIToolkit

Francisco Montero : IdealXML

Adrian Stanciulescu : ModaliXML, UsiXML

Daniela Trevisan : augmented reality

…

I would like to thank João Falcão e Cunha, Oscar Pastor, Nuno Jardim Nunes The CAiSE Advisory Committee Janice Bubenko Collette Roland Arne Solvberg

João Falcão e Cunha, Oscar Pastor, Nuno Jardim Nunes

The CAiSE Advisory Committee

Janice Bubenko

Collette Roland

Arne Solvberg

… 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