Task models are the cornerstone of user-centred design methodologies for user interface design. Therefore, they deserve attention in order to produce them effectively and efficiently, while guaranteeing the reproducibility of a task model: different persons should in principle obtain the same task model, or a similar one, for the same problem. In order to provide user interface designers with some guidance for task modelling, a list of canonical task types is proposed that offers a unified definition of frequently used tasks types in a consistent way. Each task type consists of a a task action coupled with a task object, each of them being written according to design guidelines. This list provides the following benefits: tasks are modelled in a more consistent way, their definition is more communicable and shared, task models can be efficiently used for model-driven engineering of user interfaces.
Report
Share
Report
Share
1 of 30
More Related Content
Towards Canonical Task Types for User Interface Design
1. 1 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Towards Canonical Task Types
for User Interface Design
Juan Manuel Gonzalez-Calleros, Josefina Guerrero-
García, Jean Vanderdonckt and Jaime Muñoz-Arteaga
Université catholique de Louvain (UCL),
Louvain School of Management (LSM)
Information Systems Unit (ISYS)
juan.m.gonzalez@uclouvain.be
jean.vanderdonckt@uclouvain.be
Sistemas de Información
Universidad Autónoma de Aguascalientes
jmunozar@correo.uaa.mx
2. 2 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
3. 3 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Introduction
• The task model is today a cornerstone of many
activities carried out during the User Interface (UI)
development life cycle, such as, but not limited to:
– user-centred design,
– task analysis
– task modelling
– model-driven engineering of user interfaces
– human activity analysis
– safety critical systems
– real-time systems.
4. 4 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Model-driven engineering of
user interfaces
Environment T
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
Reification
Abstraction
Reflexion
Translation
http://www.plasticity.org
UsiXML
unsupported
model
UsiXML
supported
model
User S Platform S Environment S Platform TUser T
5. 5 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Introduction
• The many degrees of freedom offered by task
modelling should not let us to forget the quality of the
resulting task model.
• Labels, definitions, goals, and properties used for a
task suffer from many drawbacks
– Limited:
• completeness in task modeling
• consistency in task modeling
• correctness in task modeling
6. Introduction
• Modelling a task based on well-defined semantics and
using a well-understood notation are key aspects.
• A list of canonical task types is proposed that
addresses the aforementioned concerns of task
modelling.
• Our goal is to provide methodological means to
systematically derive UI.
• The list is just about the name of the task and
properties and not its structure, thus remaining flexible
for task modelling.
6 November 9-11, 2009 - Mérida, Mexico CLIHC’09
7. 7 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
8. 8 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Several MBUI development methods rely on attributes
that describe the User Interface interaction ([Frank
1993] [Paternò 2002][Puerta 1997] ...)
• The User Interface interaction is composed of two
elements:
– The task type sometimes referred as UI action or activity
– The task item, as proposed by [Constantine 2002], that
is manipulated or required in the UI interaction.
9. 9 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Task Types Name spaces
have been created in
different research
domains:
• Graphical User
Interfaces
• Web Interaction
• Input Devices
10. 10 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Some taxonomies of task
Types are very much
related to interaction
devices [Foley 1984]
SELECTION
S1 From screen with direct pickdevice S1.1 Light pen
S1.2 Touch pane;
S2 Indirect with cursor match S2.1 Tablet
S2.2 Mouse
S2.3 Joystick(absolute)
S2.4 Joystick(velocity)
S2.5 Trackball
S2.6 Cursor control keys
S3 With character string name (See text input)
S4 Time scan S4.1 Programmed function keyboard
S4.2 Alphanumeric keyboard
S5 Button Push S5.1 Programmed function keyboard
S5.2 Soft keys
S6 Sketch recognition S6.1 Tablet and stylus
S6.2 Light pen
S7 Voice input S7.1 Voice recognizer
P1 Direct with locator device P1.1 Touch panel
P2 Indirect with locator device P2.1 Tablet
P2.2 Mouse
P2.3 Joystick(absolute)
P2.4 Joystick(velocity-controlled)
P2.5 Trackball
P2.6 Cursor control keys with
auto-repeat
P3 Indirect with directional commands P3.1 Up-down-left-right arrow keys
(See selection)
P4 With numerical coordinates (See text input)
P5 Direct with pickdevice P5.1 Light pen tracking
P5.2 Search for light pen
O1 Indirect with locator device O1.1 Joystick(absolute)
O1.2 Joystick(velocity-controlled)
O2 With numerical value (See text input)
Q1 Direct with valuator device Q1.1 Rotary potentiometer
Q1.2 Linear potentiometer
Q2 With character string value (See text input)
Q3 Scale drive with one axis of locator device Q3.1 Tablet
Q3.2 Mouse
Q3.3 Joystick(absolute)
Q3.4 Joystick(velocity-controlled)
Q3.5 Trackball
Q4 Light handle Q4.1 Light pen
Q4.2 Tablet with stylus
Q5 Up-down count controlled by commands Q5.1 Programmed function keyboard
Q5.2 Alphanumeric keyboard
T1 Keyboard T1.1 Alphanumeric
T1.2 Chord
T2 Stroked character recognition T2.1 Tablet with stylus
T3 Voice recognition T3.1 Voice recognizer
T4 Direct pickfrom menu with locator device T4.1 Light pen
T4.2 Touch panel
T5 Indirect pickfrom menu with locator device (See positioning)
POSITION
ORIENT
QUANTIFY
TEXT
11. 11 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Shortcomings:
• Always dependency between the name space
and the modality of interaction
• Cognitive tasks
• Gestures
• Feedback
• System Functionalities
12. 12 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
13. 13 November 9-11, 2009 - Mérida, Mexico CLIHC’09
A comparative analysis of User
Interface Actions
• More than two hundred names were identified.
14. 14 November 9-11, 2009 - Mérida, Mexico CLIHC’09
A comparative analysis of User
Interface Actions
• Comparative analysis on the name spaces
• Comparing names
• Context of use
• Definitions
• Group task types with similar definitions but
different names (choose, select, …)
• Determine which was the most abstract set of task
considering
• Modality and platform independent
15. A comparative analysis of User
Interface Actions
15 November 9-11, 2009 - Mérida, Mexico CLIHC’09
16. 16 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
17. Practical Use of the canonical list of
task types
17 November 9-11, 2009 - Mérida, Mexico CLIHC’09
1. Help to decide how to name a task
For example, for a multimodal task
18. Practical Use of the canonical list of
task types
18 November 9-11, 2009 - Mérida, Mexico CLIHC’09
2. Selection of task type and task item
19. Practical Use of the canonical list of
task types
19 November 9-11, 2009 - Mérida, Mexico CLIHC’09
3. Selection of user categories
20. 4. User Interface Concretization of the Task
20 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Practical Use of the canonical
list of task types
Concrete user
Interface S
Final user
Interface S
Task and
Domain S
Abstract user
Interface S
Task Type + Action
Item
Facet
Select + Element
Input
Concrete
Interaction Object
Selection
Widget
21. Practical Use of the canonical list of
task types
21 November 9-11, 2009 - Mérida, Mexico CLIHC’09
5. User Interface Concretization of the Task based on tables for
selecting widgets based on semantic properties
22. 22 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
23. Case Study
23 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• An Information System of a Travel Agency for organizing a trip
• The scenario and the requirements of the problem are captured in a
workflow using FlowiXML [Guerrero 2008]
24. Case Study
24 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• Tasks in the process are detailed using task models
25. Case Study
25 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• Attributes identified for the tasks
Task Task
Type
Task Item User
category
Facet
Insert Name Create Element Interactive Input
Insert Zip Code Create Element Interactive Input
Select Age category Select Element Interactive Input
Select Gender Select Element Interactive Input
26. Case Study
26 November 9-11, 2009 - Mérida, Mexico CLIHC’09
User Interface Action Types Facet Specification Information to take into account Possible Abstract Interaction
Component
“create name” and “create zip Code” Create attribute value Data type, domain characteristics A text output with a text input
associated to it
“select gender and select age
Category”
Select attribute value
+ selection values
known
Data type, domain characteristics,
selection values
A dropdown list, a group of radio
buttons textual or characters.
27. 27 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of User Interface Actions
4. Practical Use of the canonical list of task types
5. Case Study
6. Conclusion
28. Conclusion
• A list of canonical UI task action types associated
to task models was presented.
• This proposal overcomes the limitations of task
modeling in the context of MDE UI development
• The proposal provides methodological means to
systematically derive UI.
• This work is focused on task modeling
specifications and UsiXML
28 November 9-11, 2009 - Mérida, Mexico CLIHC’09
29. Conclusion
• Future Work
– Investigate task relationships
– Evaluation of this technique
– Multimodal and Multidevice concretization what
if the task is no longer available
29 November 9-11, 2009 - Mérida, Mexico CLIHC’09
30. For more information and downloading,
http://www.isys.ucl.ac.be/bchi
http://www.usixml.org
User Interface eXtensible Markup Language
http://itea.defimedia.be/usixml-france
ITEA2 Call 3 project (2008026)
Special thanks to all members of the team!
Thank you very much for your
attention
Editor's Notes
Task Modelling plays an important role in the context of MDE. Briefly MDE is:
Research work on model-based design of user interfaces has sought to address the challenge of reducing the costs for developing and maintaining user interfaces through a layered architecture that separates out different concerns:
Application task models, data and meta-data
Abstract Interface (device and modality independent, e.g. select 1 from N)
Concrete Interface (device and/or modality dependent, e.g. use of radio buttons)
Implementation on specific devices (e.g. HTML, SVG or Java)
Each layer embodies a model of behavior (e.g. dialog models and rule-based event handlers) at a progressively finer level of detail. The relationships between the layers can be given in terms of transformations, for example, between objects and events in adjoining layers. XML is well suited as a basis for representing each layer, with the possible exception of the final user interface, which may be generated automatically, guided via author supplied policies.
High level development suites can be provided to shield authors from the underlying XML representations. For example, a data model could be manipulated as a diagram, while the user interface could be defined via drag and drop operations together with editing values in property sheets. The development suite is responsible for maintaining the mappings between layers and verifying their consistency. Authors can choose to provide alternative mappings as needed to address different delivery contexts.
As it can be seen worng decision in task modelling are in detriment of the User Interface
Incompleteness: labels, definitions, goals, and properties used for a task suffer from many drawbacks such as short name, name without action verb or without object (and therefore non-compliant with the traditional interaction paradigm of action+object), name that is incompatible with its definition, no usage of standard classification.
Inconsistency: labels, definitions, goals, and properties used for a task do not have unique names (e.g., a label, a goal is duplicated), there are some homonyms; there are some synonyms (e.g., tasks having the same semantics but wearing different names).
Incorrectness: labels, definitions, goals, and properties used for a task violate some of Meyer’s seven sins of specification (i.e., noise, silence, surspecification, contradiction, ambiguity, forward reference, and suroptimism).
Task Modelling plays an important role in the context of MDE. Briefly MDE is:
Research work on model-based design of user interfaces has sought to address the challenge of reducing the costs for developing and maintaining user interfaces through a layered architecture that separates out different concerns:
Application task models, data and meta-data
Abstract Interface (device and modality independent, e.g. select 1 from N)
Concrete Interface (device and/or modality dependent, e.g. use of radio buttons)
Implementation on specific devices (e.g. HTML, SVG or Java)
Each layer embodies a model of behavior (e.g. dialog models and rule-based event handlers) at a progressively finer level of detail. The relationships between the layers can be given in terms of transformations, for example, between objects and events in adjoining layers. XML is well suited as a basis for representing each layer, with the possible exception of the final user interface, which may be generated automatically, guided via author supplied policies.
High level development suites can be provided to shield authors from the underlying XML representations. For example, a data model could be manipulated as a diagram, while the user interface could be defined via drag and drop operations together with editing values in property sheets. The development suite is responsible for maintaining the mappings between layers and verifying their consistency. Authors can choose to provide alternative mappings as needed to address different delivery contexts.
As it can be seen worng decision in task modelling are in detriment of the User Interface