Warning:
This wiki has been archived and is now read-only.

Task Meta Models

From Model-based User Interfaces Incubator Group Wiki
Jump to: navigation, search

Task Models for User Interface Design

Task Models describe how to perform activities to reach users' goals.

Of the relevant models in the human-computer interaction field, task models play an important role because they represent the logical activities that should support users in reaching their goals. Knowing the tasks necessary to goal attainment is fundamental to the design process. The need for modelling is most acutely felt when the design aims to support system implementation as well. If we gave developers only informal representations (such as scenarios or paper mock-ups), they would have to make many design decisions on their own, likely without the necessary background, to obtain a complete interactive system. Task models represent the intersection between user interface design and more systematic approaches by providing designers with a means of representing and manipulating an abstraction of activities that should be performed to reach user goals.

There are many reasons for developing task models. In some cases the task model of an existing system is created in order to better understand the underlying design and analyse its potential limitations and how to overcome them. In other cases designers create the task model of a new application yet to be developed. In this case, the purpose is to indicate how activities should be performed in order to obtain a new, usable system that is supported by some new technology.

Task models can be represented at various abstraction levels. When designers want to specify only requirements regarding how activities should be performed, they consider only the main high-level tasks. On the other hand, when designers aim to provide precise design indications then the activities are represented at a small granularity, thus including aspects related to the dialogue model of a user interface (which defines how system and user actions can be sequenced). The subject of a task model can be either an entire application or one of its parts. The application can be either a complete, running interactive system or a prototype under development. The larger the set of functionalities considered, the more difficult the modelling work. Tools open up the possibility of modelling entire applications, but in the majority of cases what designers wish to do is to model some sub-sets in order to analyse them, and to identify potential design options and better solutions. Task models can be used for many types of applications: there are applications that are clearly goal-oriented and so the tasks are clearly structured, other applications support a wide range of options open at any time, with the continuous possibility for the users to freely decide what to do and how to do it, in this case the task model should not be particularly structured in order to allow such possibilities.


Many task models, task analysis methods, and supporting tools have been introduced in the literature and are widely used in practice. Below you can find formal descriptions of different representations of task models. For this purpose, a meta-model of each task model is expressed as a UML class diagram. More details can be found in the further readings section.


Task Models Description

In order to compare existing approaches to task models a common ground is needed. In this case we use meta-models. A complete description of each work can be found in [Guerrero 2008].


AMBOSS Task Meta-Model

The task models developed with AMBOSS (Giese, Mistrzyk, Pfau, Szwillus & von Detten, 2008) describe the hierarchical tree structure of the tasks including the temporal relation between the tasks (formal part of the model) and their description (semi part of the model). On account of this reason that framework shows task models on a semi-formal level. The task model is composed of tasks, rooms, roles and task relationships. Tasks are, notably, described with attributes such as name and type. The type attribute identifies one of the three basic task types: interactive, system, abstract.

The task also has attributes to determine its duration, the precondition, the severity (indicator for the possible damage that arises from this task), the occurrence, the detection (the likelihood that this failure will be detected), the riskfactor (an integer that arises of the multiplication of three values severity, occurrence and detection); and additionally it is possible to make a riskfactor write protected.

AMBOSS Task Meta-Model

AMBOSS Task Meta-Model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Giese, Mistrzyk, Pfau, Szwillus & von Detten (2008).


ANSI/CEA-2018 Task Meta-Model

ANSI/CEA-2018 is a standard for task model descriptions, which has the potential of significantly improving the usability of computer-controlled electronic products and software interfaces in general. An ANSI/CEA-2018 task model description is an XML document (it is not a graphical formalism) whose syntax and semantics is specified by the standard. The primary use of the XML document is to be interpreted by a device at run-time to guide the user in achieving the described tasks. Detail on this task model can be found in the ANSI/CEA-2018 page.

ANSI CEA task meta-model

ANSI CEA task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: ANSI/CEA-2018.

CTT Task Model

ConcurTaskTrees is a notation for task model specifications which has been developed to overcome limitations of notations previously used to design interactive applications. Its main purpose is to be an easy-to-use notation that can support the design of real industrial applications, which usually means applications with medium-large dimensions. Details can be found on ConcurTaskTrees page.

Diane+ Task Meta-Model

Diane+ (Tarby and Barthet, 1996) is used during the user requirement analysis phase and can guide the design of the user interface. It uses a graphical notation to represent task decomposition as well as temporal and logical relationships among tasks. A Diane+ diagram explicitly indicates whether a task is to be accomplished by the end user (manual), the system (automatic), or a combination of both (interactive). The main characteristics of Diane+ are: the various representations of an interactive application, the abstraction level, the aims and the user´s logics, the dialogue control sharing between man and machine, the adaptation of dialogue to users, and the OPAC data model. There are two important points to be made about the way in which Diane+ models a task. First, the procedures describe only the characteristics specific to an application and do include the standard actions common to most applications, such as quit, cancel, and so on. This assumes that the supposed standard actions, previously defined, really apply to the application of interest. (If a standard action does not apply, this would be indicated.). Secondly, the described procedures are not mandatory; what is not forbidden is allowed.

Diane task meta-model

Diane task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Tarby, J. and Barthet, M. (1996).

GOMS Task Meta-Model

Goals, Operators, Methods, and Selection rules (GOMS) model, developed by Card, Moran and Newell(1983), consists of descriptions of the Methods needed to accomplish specified Goals. Methods are view as a series of steps consisting of Operators that the user performs. A Method may call for subgoals to be accomplished, so the Methods have a hierarchical structure. If there is more than one Method to accomplish a Goal, the Selection rules choose the appropriate Method depending on the context (Kieras, 2004). Today, there are several variants of the GOMS analysis technique, and many applications of the technique in real-world design situations (John and Kieras, 1996). GOMS makes a clear distinction between tasks and actions. First, task decomposition stops at task units. Second, actions that in GOMS are termed operators are specified by the methods associated with unit tasks. Action modeling varies depending on the GOMS model and the method specification. Operators are cognitive and physical actions the user has to perform in order to accomplish the task goal. Since each operator has an associated execution time (determined experimentally), a GOMS model can help in predicting the time needed to perform a task.


GOMS task meta-model

GOMS task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Card, Moran and Newell(1983), John and Kieras, (1996), Kieras, (2004).

GTA Task Meta-Model

Groupware Task Analysis (GTA) (van der Veer, van der Lenting & Bergevoet, 1996) was developed as a means to model the complexity of tasks in a co-operative environment. GTA describes the task world focusing on: agents, roles, work and situation. Agents often indicates people, either individual or in groups. In situations where information technology is applied, actors will be non-human agents, or systems that comprise collaboration between human agents and machine agents. Roles indicate classes of actors to whom certain subsets of tasks are allocated; the role can be obtained by assignment, delegation, mandate or because of a situational context. GTA focus on the structural as well as dynamic aspect of the work, it take task as the basic concept and goal as an attribute. Tasks can be identified at various levels of complexity; complex tasks may be split up between actors or roles, unit tasks and basic tasks may be decomposed further into (user) actions and (system) events. The task structure is hierarchical. Analyzing a task world from the viewpoint of the situations means detecting and describing the environment (physical, conceptual, and social) and the objects in the environment. Objects may be physical things, or conceptual (non-material) things like messages, password or signatures. Its framework describes a task world ontology that specifies the relationships between the concepts on which the task world is modeled. Based on this ontology a supporting tool to model task knowledge was also developed: EUTERPE (Welie, van der Veer, & Eliëns, 1998).

GTA task meta-model

GTA task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: van der Veer, van der Lenting & Bergevoet (1996), van Welie, van der Veer, & Eliëns (1998).

HTA Task Meta-Model

Hierarchical Task Analysis (HTA) was developed by Annett and Duncan (1967) as a general method for examining complex tasks. It was primarily aimed at training users to perform particular tasks. The HTA method employs natural language to express operations and task conditions plans. By adopting an operation as the main unit of description, HTA maintains neutrality in task descriptions. The stopping rule means that the values of the system and not simple those of human factors are taken into account in the human factors contribution to the design process. Principal steps in conducting HTA are (Annett 2000):decide the purpose(s) of the analysis; get agreement between stakeholders on the definition of task goals and criterion measures; identify sources of task information ad select means of data acquisition; acquire data and draft decomposition table/diagram; recheck validity of decomposition with stakeholders; identify significant operations in light of purpose of analysis; and generate and test hypotheses concerning factors affecting learning and performance. HTA has been shown to aid human factor and resource decision-making, including the design of teams and jobs, operating procedures, selection methods, interface design, and training, as well as reliability assessment and quantification. It also supports task analysis for teamwork.


HTA task meta-model

HTA task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Annett and Duncan (1967), (Annett 2000).

TKS Task Meta-Model

The theoretical keystone of Task Knowledge Structure (TKS) method (Johnson and Johnson, 1989) relies on the possession and utilization of knowledge and its structure in human memory. A TKS has two main structures: the goal structure representing knowledge about how to undertake the task, and the taxonomic structure that represents declarative knowledge about the task elements. The elements of a TKS are: actions & objects, object representativeness, procedures, plans and goals & subtasks. Goal structure identifies the goal and sub-goals contained within the TKS. The goal structure also includes the enabling and conditional states that must prevail if a goal of sub-goal is to be achieved. In this way the goal structure represents the plan for carrying out the task; the plan is carried out through a procedural structure. A procedure is a particular element of behaviour, at the lowest level it can be an action or an object. Strategies are particular sequences of procedures. Taxonomic structure involves action(s) and object(s) knowledge. This includes the representativeness of the object or action, the class membership, and other attributes such as the procedures in which it is commonly used; its relation to other objects and actions, and its features.


TKS task meta-model

TKS task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Johnson and Johnson (1989).


TOOD Task Meta-Model

The purpose of Task Object-Oriented Description (TOOD) Mahfoudhi (1997), Ormerod and Shepered (2004) is to formalize the user task by jointly using the object-oriented approach and Object Petri Nets. The concepts borrowed from the object approach make it possible to describe the static aspect (Static task model) of tasks and Petri Nets enable the description of dynamics and behaviour (Dynamic task model).

The method consists of four steps: hierarchical decomposition of tasks, identification of descriptor objects and world objects, definition of elementary and control tasks, and integration of concurrency. Each task is treated as an instance of a task class identified by a name and an identifier and characterized by a goal, a type (i.e., human, automatic, interactive, and cooperative), the level in the hierarchy, and the total amount of task components. The task body represents a task hierarchy organized using three logical constructors (i.e., AND, OR, and XOR). Each task is then associated with a task control structure (TCS) made up of six classes of descriptor objects that are consumed when the task is carried out and they are aggregated.

TOOD task meta-model

TOOD task meta-model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008), abstracted from: Mahfoudhi (1997), Ormerod and Shepered (2004).

UsiXML Task Meta-Model

Though USer Interface eXtensible Language (UsiXML ) is a XML-compliant markup language that describes the user interface for multiple contexts of use, it describes a task model (Guerrero, Vanderdonckt and Gonzalez 2008) where tasks are organized in a high-level of abstraction called processes. A process consists of a number of tasks and a set of relationships among them. The definition of a process indicate which tasks must be performed and in what order. A task can be: user, abstract, interaction or application task. It is decomposed into subtasks to consider hierarchical structure of a task tree; operators are used to link them on the same level of decomposition. A task may manipulate objects through actions. It introduces the concept of Job instead of role. Jobs are the total collection of tasks, duties, and responsibilities assigned to one or more positions which require work of the same nature and level. The job concept allows assembling tasks under a same umbrella in a way that is independent of individual resources in the organization unit. In this way, several individuals could play a particular job, and jobs could be interchanged dynamically. Typically, only resources and their roles within organizations are modeled in most task models, we consider that the place where the tasks are executed is an important aspect in the environment where the collaboration is developed. Thus, the concept of organizational unit is considered, it is a formal group of people working together with one or more shared goals or objectives. It could be composed of other organizational units. Resources are characterized thanks to the notion of user stereotype. But a same task could require other types of resources such as material resources (e.g., hardware, network) or immaterial resources (e.g., electricity, power). The agenda is a list of tasks that are assigned to user stereotype. A user stereotype has one and only one agenda and an agenda belongs to one and only one user stereotype. The concept of agenda is useful to cope with the cooperative aspects. It is also possible to allocate or offer tasks to user stereotypes through the agendas.


UsiMXL Task Meta-Model

UsiMXL Task Meta-Model,

Source: Guerrero, Vanderdonckt, and Gonzalez (2008).

Compasion of Task Models for User Interface Design

The task models presented in previous section exhibit a variety of concepts and relationships. The differences between concepts include differences of vocabulary used for the same concept across models. They have, also, different bases of formalization, and scopes. This section presents the analysis and results obtained after the comparison of the task models. It is important to realize that the way we mark a notation is subjective and it is based on our experience.

Task Model Relationships

AMBOSS ANSI/CEA CTT Diane + GOMS GTA HTA TKS TOOD UsiXML Relevance
Decomposition Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Hierarchy Must
Sequence Seq +- Ordered = true, information passing (Postcondition) Enabling, enabling with information passing Ordered sequence Sequence Seq Fixed sequence Sequence Sequence Enabling, enabling with information passing Must
Iteration X +- MinOccurs+ MaxOccurs Iteration, finite iteration Loop +- Loop (If, then, else) X +- Stop rules X X Iteration, finite iteration Should
Choice ALT +- Precodition Choice Required choice, free choice +- Or (If, then, else) Or Selective rule Or Choice Deterministic choice, undeterministic choice, inclusive choice Should
Optionality Barrier MinOccurs/MaxOccurs Optional Optional Optional (If, then, else) Start condition X X X Optional Should
Interruption X X Suspend- resume, disabling X Interruption (If, then, else) Stop condition Stop rules X Interruption Suspend- resume, disabling, disabling with information passing Should
Concurrency SER Ordered = false Concurrent, concurrent communicating tasks, independence unordered sequence Concurrency (If, then, else) X Selective rule X Concurrency Independent concurrency, concurrency with information passing, order independence Should
Cooperation Precondition X Cooperative X X Cooperation Teamwork Collaboration(FKS extension) Collaboration Cooperation Should
Parallel PAR, SIM X X Parallel X And Dual task (time sharing) And Simultaneity parallelSplit (process model) Should

Further Readings

Annett, J., & Duncan, K. (1967). Task analysis and training design. Occupational Psychology, 41, 211–227.

Annett, J. (2004). Hierarchical Task Analysis. Diaper, D. and Stanton, N.A. (Eds.). The Handbook of Task Analysis for Human-Computer Interaction. Mahwah, NJ.: Lawrence Erlbaum Associates. pp. 67-82.

Barthet, M.-F., & Tarby, J.-C. (1996). The Diane+ method. In J. Vanderdonckt, (Ed.), Computer-aided design of user interfaces (pp. 95–120). Namur, Belgium: Presses Universitaires de Namur.

I.Breedvelt, F.Paternò, C.Severiins, “Reusable Structures in Task Models”, Proceedings Design, Specification, Verification of Interactive Systems ’97, Granada, June 97, pp.251-265, Springer Verlag.

Giese, M., Mistrzyk, T., Pfau, A., SzwillusG. & von Detten M. (2008), "AMBOSS: A Task Modeling Approach for Safety-Critical Systems", Pisa : Springer-Verlag, Berlin, 2008. 7th Int. Workshop on Task Models and Diagrams TAMODIA'2008. http://mci.cs.uni-paderborn.de/pg/amboss/

Guerrero, J., Vanderdonckt, J., Gonzalez Calleros, J.M. (2008), FlowiXML: a Step towards Designing Workflow Management Systems, "Journal of Web Engineering", Vol. 4, No. 2, 2008, pp. 163-182.

Guerrero Garcia, J., Vanderdonckt, J., Gonzalez Calleros, J.M. (2008), Towards a Multi-Users Interaction Meta-Model. IAG Working Paper 08/28, Université catholique de Louvain, 2008.

John, B. E.,&Kieras, D. E. (1996). The GOMS family of user interface analysis techniques: Comparison and contrast. ACM Transactions on Computer-Human Interaction, 3, 320–351.

Limbourg, Q., Vanderdonckt, J. (2002), Comparing Task Models for User Interface Design, Chapter 6, in Diaper, D. and Stanton, N. (Eds.), " The Handbook of Task Analysis for Human-Computer Interaction " Lawrence Erlbaum Associates, Mahwah, 2002.

Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., López Jaquero, V. (2004) UsiXML: a Language Supporting Multi-Path Development of User Interfaces, Proc. of 9th IFIP Working Conference on Engineering for Human-Computer Interaction jointly with 11th Int. Workshop on Design, Specification, and Verification of Interactive Systems EHCI-DSVIS’2004 (Hamburg, July 11-13, 2004). LNCS, Vol. 3425, Springer-Verlag.

Limbourg, Q. (2004) Multi-Path Development of User Interfaces. Ph.D Thesis, Université catholique de Louvain, 2004.

Mahfoudhi, A., Abed, M.,&Tabary,D. (2001). From the formal specifications of user tasks to the automatic generation of the HCI specifications. In A. Blandford, J. Vanderdonckt, & P. Gray, (Eds.), People and computers XV (pp. 331–347). London: Springer.

Mahfoudhi, A.(1997). TOOD: Une méthodologie de description orientée objet des tâches utilisateur pour la spécification et la conception des interfaces hommes–machines. Ph.D. thesis, Univ. Of Valenciennes.

Ormerod, T.C. & Shepherd, A. (2004). Using Task Analysis for Information Requirements Specification: The Sub-Goal Template (SGT) Method. Diaper, D. and Stanton, N.A. (Eds.). The Handbook of Task Analysis for Human-Computer Interaction. Mahwah, NJ.: Lawrence Erlbaum Associates. pp. 347-365.

Paternò F., Model-based Design and Evaluation of Interactive Applications, Springer Verlag, ISBN 1-85233-155-0, 1999.

Paternò F., ConcurTaskTrees: An Engineered Notation for Task Models, Chapter 24, in Diaper, D., Stanton, N. (Eds.), The Handbook of Task Analysis for Human-Computer Interaction, pp.483-503, Lawrence Erlbaum Associates, Mahwah, 2003.

F. Paternò, C. Santoro), S. Tahmassebi, “Formal Models for Cooperative Tasks: Concepts and an Application for En-Route Air Traffic Control”, Proceedings DSV-IS’98, pp.71-86, June’98, Abingdon, Springer Verlag.

F.Paternò, C.Santoro, V.Sabbatino, Using Information in Task Models to Support Design of Interactive Safety-Critical Applications, Proceedings AVI’2000, pp.120-127, ACM Press, May 2000, Palermo.

Tarby, J., & Barthet, M. (1996). The DIANE+ Method, International Workshop of Computer-Aided Design of User Interfaces, June 5-7, Facultés Universitaires Notre-Dame de la Paix.

van der Veer, G.C., van der Lenting, B.F., & Bergevoet, B.A.J., (1996). GTA: Groupware Task Analysis - Modeling Complexity. Acta Psychologica 91, 297–322

van Welie, M., van der Veer, G.C., & Eliëns, A. (1998). EUTREPE: Tool support for analyzing cooperative environments. Paper presented at the Ninth European Conference on Cognitive Ergonomics, Limerickm Ireland.


UsiXML Consortium Web site