Towards Canonical Task Types for User Interface Design
Download as PPT, PDF6 likes733 views
The document discusses the importance of task modeling in user interface (UI) development, proposing a canonical list of task types to enhance task modeling quality. It outlines the state of the art in UI interactions, comparative analysis of user actions, and a case study related to a travel agency information system. The conclusion emphasizes the proposal's contribution to improving systematic UI design and future research directions.
![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.](https://image.slidesharecdn.com/gonzalez-clihc2009-101024044434-phpapp02/85/Towards-Canonical-Task-Types-for-User-Interface-Design-8-320.jpg)
![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](https://image.slidesharecdn.com/gonzalez-clihc2009-101024044434-phpapp02/85/Towards-Canonical-Task-Types-for-User-Interface-Design-10-320.jpg)
![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]](https://image.slidesharecdn.com/gonzalez-clihc2009-101024044434-phpapp02/85/Towards-Canonical-Task-Types-for-User-Interface-Design-23-320.jpg)
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
- #5: 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
- #6: 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).
- #21: 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