Usability Metrics in Adaptive Agent-Based Tutoring Systems

USIXML: a Language Supporting
Multi-Path Development of User
Interfaces
Quentin Limbourg1, Jean Vanderdonckt1, Benjamin
Michotte1, Laurent Bouillon1, Víctor M. López Jaquero1,2
1Belgian
Laboratory of HCI
University Catholic of Louvain
Louvain-la-neuve, Belgium
July, 2004 (Hamburg, Germany)
2Computer
Science Research Institute (I3A)
LoUISE Research Group
University of Castilla-La Mancha
Albacete, Spain
usiXML
1
UIs ARE RUNNING FAST
... AFTER CHANGE








Task redefinitions
Tasks reallocation
Organizational adaptation
Domain evolution
Obsolescence of languages
New languages
New platforms
…
July, 2004 (Hamburg, Germany)
usiXML
2
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
July, 2004 (Hamburg, Germany)
usiXML
3
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.
July, 2004 (Hamburg, Germany)
usiXML
4
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)
July, 2004 (Hamburg, Germany)
usiXML
5
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)
July, 2004 (Hamburg, Germany)
usiXML
6
MODEL-TO-MODEL
TRANSFORMATION IS THE NAME OF THE GAME
Meta-Meta-Model
Graph Structure
is instance of
Meta-Model
usiXML Meta-Model
Meta-Model Subset 1
Meta-Model Subset 2
e.g., Task+Domain Model
e.g., Concrete UI Model
Uses language
is instance of
is instance of
Initial UI Model
Transformation Rule
Resultant UI Model
e.g., MyTaskAndDomainModel
usiXML Transformation Catalog
e.g., MyConcreteUIModel
July, 2004 (Hamburg, Germany)
usiXML
7
DEVELOPMENT PATH
CONNECTION TO TRANSFORMATIONS
Methodological World
Development
Development
path
path
1 isComposedOf
*
Development
Development
step
step
1 isComposedOf
*
Development
Development
sub-step
sub-step
1
isRealizedBy
Graph Transformation World
0..1
Transformation
Transformation
System
System
1
isComposedOf
*
Transformation
Transformation
Rule
Rule
A development library and transformation models are
available to store and resuse the defined development paths
and transformations.
July, 2004 (Hamburg, Germany)
usiXML
8
TRANSFORMATION PATHS,
STEPS, SUB-STEPS

Task and
Task and
Domain
Domain
Reification


Abstraction

Abstract
Abstract
User
UserInterface
Interface
Translation
Code Generation



Concrete
Concrete
User
UserInterface
Interface


User
UserInterface
Interface
Code
Code
July, 2004 (Hamburg, Germany)
usiXML
Code Reverse
Engineering
Forward Engineeri
section 4.1.1
section 4.1.2
section 4.1.3
Reverse Engineerin
section 4.2.1
section 4.2.2
section 4.2.3
Context Adaptatio
section 4.3.1
section 4.3.2
section 4.3.3
9
TRANSFORMATIONS
 In the literature:
– APIs
– XSLT
– …
 Drawbacks
–
–
–
–
July, 2004 (Hamburg, Germany)
Execution semantics is poorly defined
Consistency of resultant model
Procedurality
Cryptic syntax
usiXML
10
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.
July, 2004 (Hamburg, Germany)
usiXML
11
HOW IT WORKS …

Find an occurrence of LHS in G (this
occurrence is called a match). If several
occurrences exist, choose one nondeterministically.

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.
r
LHS
m*
m
G
RHS
r*
G’
 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.
July, 2004 (Hamburg, Germany)
usiXML
12
VISUAL SYNTAX
RHS
LHS
::=
July, 2004 (Hamburg, Germany)
usiXML
13
EXAMPLE
WIDGET REPLACEMENT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cuiModel name="MyModel">
<version modifDate="2004-03-24T17:09:17.402+01:00" xmlns="">7</version>
<authorName xmlns="">Youri</authorName>
<window height="500" width="600" name="Formulaire (2/5)" id="window_1">
<box relativeHeight="100" name="box1_0" id="box1_0">
<box type="vert" name="boxTodo" id="boxTodo">
...
<box type="horiz" name="box_2_2_2_1" id="box_2_2_2_1">
<textComponent defaultContent="Sexe" isBold="true" id="label_2"/>
<radioButton groupName=“grupo01" defaultContent="Femme"
defaultState="false" id="radiobutton_0"/>
<radioButton groupName="grupo01" defaultContent="Homme"
defaultState="true" id="radiobutton_1"/>
</box>
...
</box>
</box>
</window>
</cuiModel>
Excerpt for an usiXML CUI specification.
July, 2004 (Hamburg, Germany)
usiXML
14
EXAMPLE
WIDGET REPLACEMENT
July, 2004 (Hamburg, Germany)
usiXML
15
EXAMPLE
WIDGET REPLACEMENT
The usiXML graph before aplying any rule
July, 2004 (Hamburg, Germany)
usiXML
16
EXAMPLE
WIDGET REPLACEMENT
Rule 1: Create a new comboBox with the same
id and name as the name of the group of
radioButtons.
NAC
RHS
LHS
July, 2004 (Hamburg, Germany)
usiXML
17
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
July, 2004 (Hamburg, Germany)
usiXML
18
EXAMPLE
WIDGET REPLACEMENT
Rule 2: Convert every radioButton within the
group “x” into an item for the comboBox “x”, we
have just created.
LHS
RHS
::=
July, 2004 (Hamburg, Germany)
usiXML
19
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
July, 2004 (Hamburg, Germany)
usiXML
20
EXAMPLE
WIDGET REPLACEMENT
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cuiModel name="MyModel">
<version modifDate="2004-03-24T17:09:17.402+01:00" xmlns="">7</version>
<authorName xmlns="">Youri</authorName>
<window height="500" width="600" name="Formulaire (2/5)" id="window_1">
<box relativeHeight="100" name="box1_0" id="box1_0">
<box type="vert" name="boxTodo" id="boxTodo">
...
<box type="horiz" name="box_2_2_2_1" id="box_2_2_2_1">
<textComponent defaultContent="Sexe" isBold="true" id="label_2"/>
<comboBox id="comboBox001" name="label_3" isDropDown="true">
<item id="radiobutton_0" name="radiobutton_0" defaultContent="Femme"/>
<item id="radiobutton_1" name="radiobutton_1" defaultContent="Homme"/>
</comboBox>
...
</box>
</box>
</window>
</cuiModel>
Excerpt from the final transformated usiXML specification
July, 2004 (Hamburg, Germany)
usiXML
21
EXAMPLE
WIDGET REPLACEMENT
July, 2004 (Hamburg, Germany)
usiXML
22
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)
July, 2004 (Hamburg, Germany)
usiXML
23
TRANSFORMIXML API
July, 2004 (Hamburg, Germany)
usiXML
24
GRAFIXML
July, 2004 (Hamburg, Germany)
usiXML
25
FLASHIXML
July, 2004 (Hamburg, Germany)
usiXML
26
TRANSFORMIXML GUI
July, 2004 (Hamburg, Germany)
usiXML
27
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 .
July, 2004 (Hamburg, Germany)
usiXML
28
FUTURE WORK
 Pattern expression using usiXML chunks.
 Extension to other modalities (e.g., 3D, multimodal).
 Integration of other models in the framework
(e.g., workflow models?).
 Continue the development of ongoing tools …
July, 2004 (Hamburg, Germany)
usiXML
29
THANK YOU!
See you on www.usixml.org !
July, 2004 (Hamburg, Germany)
usiXML
30