1 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Towards Canonical Task Types
for User Interface Design
Juan Manuel Gonzale...
2 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of U...
3 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Introduction
• The task model is today a cornerstone of many
activities ca...
4 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Model-driven engineering of
user interfaces
Environment T
Final user
Inter...
5 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Introduction
• The many degrees of freedom offered by task
modelling shoul...
Introduction
• Modelling a task based on well-defined semantics and
using a well-understood notation are key aspects.
• A ...
7 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of U...
8 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Several MBUI development methods rely on attributes
tha...
9 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Task Types Name spaces
have been created in
different r...
10 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Some taxonomies of task
Types are very much
related to...
11 November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art
• Shortcomings:
• Always dependency between the name spa...
12 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of ...
13 November 9-11, 2009 - Mérida, Mexico CLIHC’09
A comparative analysis of User
Interface Actions
• More than two hundred ...
14 November 9-11, 2009 - Mérida, Mexico CLIHC’09
A comparative analysis of User
Interface Actions
• Comparative analysis o...
A comparative analysis of User
Interface Actions
15 November 9-11, 2009 - Mérida, Mexico CLIHC’09
16 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of ...
Practical Use of the canonical list of
task types
17 November 9-11, 2009 - Mérida, Mexico CLIHC’09
1. Help to decide how t...
Practical Use of the canonical list of
task types
18 November 9-11, 2009 - Mérida, Mexico CLIHC’09
2. Selection of task ty...
Practical Use of the canonical list of
task types
19 November 9-11, 2009 - Mérida, Mexico CLIHC’09
3. Selection of user ca...
4. User Interface Concretization of the Task
20 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Practical Use of the canonic...
Practical Use of the canonical list of
task types
21 November 9-11, 2009 - Mérida, Mexico CLIHC’09
5. User Interface Concr...
22 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of ...
Case Study
23 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• An Information System of a Travel Agency for organizing a tr...
Case Study
24 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• Tasks in the process are detailed using task models
Case Study
25 November 9-11, 2009 - Mérida, Mexico CLIHC’09
• Attributes identified for the tasks
Task Task
Type
Task Item...
Case Study
26 November 9-11, 2009 - Mérida, Mexico CLIHC’09
User Interface Action Types Facet Specification Information to...
27 November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
1. Introduction
2. State of the Art
3. A comparative analysis of ...
Conclusion
• A list of canonical UI task action types associated
to task models was presented.
• This proposal overcomes t...
Conclusion
• Future Work
– Investigate task relationships
– Evaluation of this technique
– Multimodal and Multidevice conc...
For more information and downloading,
http://www.isys.ucl.ac.be/bchi
http://www.usixml.org
User Interface eXtensible Marku...
Upcoming SlideShare
Loading in...5
×

Towards Canonical Task Types for User Interface Design

1,062

Published on

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.

Published in: Technology, Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,062
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 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
  • Towards Canonical Task Types for User Interface Design

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. A comparative analysis of User Interface Actions 15 November 9-11, 2009 - Mérida, Mexico CLIHC’09
    16. 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. 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. 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. 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. 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. 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. 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. 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. 24. Case Study 24 November 9-11, 2009 - Mérida, Mexico CLIHC’09 • Tasks in the process are detailed using task models
    25. 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. 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. 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. 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. 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. 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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×