Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

Towards Canonical Task Types for User Interface Design

by Jean Vanderdonckt

859 views

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 ...

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.

Accessibility

View text version

Categories

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

File a copyright complaint

1 Embed 11

http://localhost

11

Statistics

Likes: 3
Downloads: 8
Comments: 0
Embed Views: 11
Views on SlideShare: 848
Total Views: 859

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

3 Likes

Raudy López 1 year ago
Juan Glez Calleros, Researcher at University of Puebla 1 year ago
Julia Debari 2 years ago

Towards Canonical Task Types for User Interface Design Presentation Transcript

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
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
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:
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Model-driven engineering of user interfaces November 9-11, 2009 - Mérida, Mexico CLIHC’09 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 Environment T Reification Abstraction Reflexion Translation Platform S Environment S Platform T
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
November 9-11, 2009 - Mérida, Mexico CLIHC’09
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.
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
November 9-11, 2009 - Mérida, Mexico CLIHC’09
State of the art November 9-11, 2009 - Mérida, Mexico CLIHC’09
- 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:
State of the art November 9-11, 2009 - Mérida, Mexico CLIHC’09
- Task Types Name spaces have been created in different research domains:
State of the art November 9-11, 2009 - Mérida, Mexico CLIHC’09
- Some taxonomies of task Types are very much related to interaction devices [Foley 1984]
State of the art November 9-11, 2009 - Mérida, Mexico CLIHC’09
- Shortcomings:
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
November 9-11, 2009 - Mérida, Mexico CLIHC’09
A comparative analysis of User Interface Actions November 9-11, 2009 - Mérida, Mexico CLIHC’09
- More than two hundred names were identified.
A comparative analysis of User Interface Actions November 9-11, 2009 - Mérida, Mexico CLIHC’09
- Comparative analysis on the name spaces
- Group task types with similar definitions but different names (choose, select, …)
- Determine which was the most abstract set of task considering
A comparative analysis of User Interface Actions November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Practical Use of the canonical list of task types
- Help to decide how to name a task
November 9-11, 2009 - Mérida, Mexico CLIHC’09 For example, for a multimodal task
Practical Use of the canonical list of task types
- Selection of task type and task item
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Practical Use of the canonical list of task types
- Selection of user categories
November 9-11, 2009 - Mérida, Mexico CLIHC’09
- User Interface Concretization of the Task
Practical Use of the canonical list of task types November 9-11, 2009 - Mérida, Mexico CLIHC’09 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
Practical Use of the canonical list of task types
- User Interface Concretization of the Task based on tables for selecting widgets based on semantic properties
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Case Study
- 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]
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Case Study
- Tasks in the process are detailed using task models
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Case Study
- Attributes identified for the tasks
November 9-11, 2009 - Mérida, Mexico CLIHC’09 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
Case Study 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.
Outline
- Introduction
- State of the Art
- A comparative analysis of User Interface Actions
- Practical Use of the canonical list of task types
- Case Study
- Conclusion
November 9-11, 2009 - Mérida, Mexico CLIHC’09
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
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Conclusion
- Future Work
November 9-11, 2009 - Mérida, Mexico CLIHC’09
Thank you very much for your attention 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!