ConcurTaskTrees

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.

The main features of ConcurTaskTrees are:

• Hierarchical structure, a hierarchical structure is something very intuitive, in fact often when people have to solve a problem tend often to decompose it into smaller problems still maintaining the relationships among the smaller parts of the solution; the hierarchical structure of this specification has two advantages: it provides a large range of granularity allowing large and small task structures to be reused, it enables reusable task structures to be defined at both a low and a high semantic level.

• Graphical syntax, a graphical syntax often (not always) is more easy to interpret, in this case it should reflect the logical structure so it should have a tree-like form;

Concurrent notation, operators for temporal ordering are used to link subtasks at the same abstraction level. This sort of aspect is usually implicit, expressed informally in the outputs of task analysis. Making the analyst use these operators is a substantial change to normal practice. The reason for this innovation is that after an informal task analysis we want designers to express clearly the logical temporal relationships. This is because such ordering should be taken into account in the user interface implementation to allow the user to perform at any time the tasks that should be active from a semantic point of view.

• Focus on activities, thus it allows designers to concentrate on the most relevant aspects when designing interactive applications that that encompass both user and system-related aspects avoiding low levels implementation details that at the design stage would only obscure the decisions to take.

This notation has shown two positive results:

• an expressive and flexible notation able to represent concurrent and interactive activities, also with the possibility to support cooperations among multiple users and possible interruptions;
• compact, understandable representation, the key aspect in the success of a notation is the ability to provide many information in an intuitive way without requiring excessive efforts from the users of the notation. ConcurTaskTrees is able to support this as it has been demonstrated by its use also by people working in industries without a background in Computer Science.

A set of tools to develop task models in ConcurTaskTrees, to analyse their content and to generate corresponding user interfaces are being developed and are available at http://giove.isti.cnr.it/ctte.html, which has been used by many organizations (see a list at http://giove.cnuce.cnr.it:8443/CTTE/Externaluse.jsp)

Information on publications, courses, presentations, and thesis regarding ConcurTaskTrees is available at http://giove.cnuce.cnr.it/CTT_publications/index.html

Describing Errors by CTT

One of the main issues with traditional approaches to task modelling, such as Hierarchical Task Analysis (HTA) or GOMS, is that they tend to describe error-free behaviours. More recent approaches, such as CTT, overcome such limitation thanks to the use of a set of temporal operators, which allow designers to describe flexible, and more realistic, behaviours. For example, it is possible to describe concurrent activities, activities that interrupt others or the possibility to suspend/resume activities. In the figure below there is a simple example to clarify this possibility. It considers editing a file, which is decomposed into opening, followed ([]>> is the sequential operator) by the actual editing, which can be interrupted at any time ([> is the disabling operator) by the closing task. Editing the document is an iterative task (indicated by the * symbol), decomposed into enter content, which can be interrupted by the occurence of an error. The latter can be followed by some activity to recover from the error. The recovery is optional (indicated by the name between squared brackets) because the user may not realise that the error occurred. After that, since the editing task is iterative then it is possible to continue to enter content.