1

ConcurTaskTrees: An Engineered Approach to Model-based Design of Interactive Systems

Fabio Paternò

ISTI-C.N.R.

Via G.Moruzzi 1, 56100 Pisa, Italy

fabio.paterno@isti.cnr.it

Task models represent the intersection between user interface design and more engineering approaches by providing designers with a means of representing and manipulating a formal abstraction of activities that should be performed to reach user goals. For this purpose they need to be represented with notations able to capture all the relevant aspects. In this paper the ConcurTaskTrees notation is described and discussed with particular attention to recent evolutions stimulated by experiences with its use and the need to address new challenges.

Keywords: Task models, notations, concurrent tasks, context of use, cooperative applications. Introduction One universally agreed upon design principle to obtain usable interactive systems is “Focus on the users and their tasks”. Indeed, 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 (Paternò, 1999). Thus, knowing the tasks necessary to goal attainment is fundamental to the design process. Although task models have long been considered in human-computer interaction, only recently user interface developers and designers have realised their importance and the need for engineering approaches to task models to better obtain effective and consistent solutions. 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. In order to be meaningful, the task model of a new application should be developed through an interdisciplinary collaborative effort involving the various relevant viewpoints. By drawing on the various fields of competence we can obtain user interfaces that can effectively support the desired activities. This means that the user task model (how users think that the activities should be performed) shows a close correspondence to the system task model (how the application assumes that activities are performed). 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).

2

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 such as CTTE (publicly available at http://giove.cnuce.cnr.it/ctte.html) 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. Although task models have long been considered in human-computer interaction, only recently have user interface developers and designers realised their importance and the need for engineering approaches to task models to better obtain effective and consistent solutions. An engineering approach should address at least four main issues:

• availability of flexible and expressive notations able to describe clearly the possible activities; it is important that these notations are sufficiently powerful to describe interactive and dynamic behaviours; such notations should be readable so that they can be interpreted also by people with low formal background;

• need for systematic methods to support the specification, analysis, and use of task models, to facilitate their development and support designers in using the knowledge that they incorporate to address the design of the user interface and its evaluation; often even designers who developed some task analysis and modelling did not use them for the detailed design of the user interface because of this lack of structured methods which should give rules and suggestions about how to use information in the task model for the concrete design; such criteria can also be incorporated in tools aiming to support interactively designers.

• support for the reuse of good design solutions to problems which occur across many applications; this is relevant especially in an industrial context where developers often have to design applications which address similar problems, thus it would be useful to have design solutions structured and documented in such a way as to support easy reuse and tailoring in different applications.

• availability of automatic tools to support the various phases of the design cycle; also the development of these tools should pay attention to user interface aspects so as to have intuitive representations and providing information useful for the logical activities of designers.

Task models can be useful both in the construction and the use of an interactive system. Indeed they are useful:

• For designers and developers: because they support high-level, structured approaches which allow integration of both functional and interactional aspects

• For end users: because they support the generation of more understandable systems. This chapter provides first the basic concepts on which ConcurTaskTrees (Paternò, 1999) has been developed. It does not only provide an introduction of the notation but it also discusses some issues that have revealed to be important during its development and later application to a number of projects: the relationships among task models and more informal representations, how to use them to support the design of applications accessible through multiple devices, how they can be integrated with standard software engineering methods such as UML, how to represent task models of multi-user applications, what tool support they need in order to ease and broaden their analysis by designers. In the chapter we will also touch upon some experiences of using ConcurTaskTrees (CTT) in a number of projects. Basic concepts Of the relevant models, task models play a particularly important role because they indicate the logical activities that an application should support to reach users’ goals.

3

A goal is either a desired modification of state or an inquiry to obtain information on the current state. Each task can be associated with a goal which is the state change derived by its performance. Each goal can be associated with one or multiple tasks: there can be different tasks to achieve the same goal. Tasks can range from a very high abstraction level (such as deciding a strategy for solving a problem) to a concrete, action-oriented level (such as selecting a printer). Basic tasks are elementary tasks that cannot be longer decomposed because they do not contain any control element. For example, making a flight reservation is a task that requires a state modification (adding a new reservation in the flight data base) whereas querying the available flights from Pisa to London is one task that just requires an inquiry of the current state of the application. Making a reservation is a task that can be decomposed into lower level tasks such as specifying departure and arrival town, time and seat preferences and so on. It is better to distinguish between task analysis and task modelling. While the purpose of task analysis is to understand what tasks should be supported and what their related attributes are, the aim of task modelling is to identify more precisely the relationships among such tasks. The need for modelling is most acutely felt when the design aims to support system implementation as well. If we gave developers only a set of scenarios, they would have to make many design decisions on their own in order to obtain a complete system. This is why UML has widely been adopted in software engineering: its purpose is to provide a set of related representations (ranging from use cases to class diagrams) to support designers and developers across the various phases of the design cycle. There are various types of task models that can be considered: • The task model of an existing system, its purpose is to describe how activities should be

performed in an existing, concrete system in order to understand its limitations, problems, features and so on;

• The task model of an envisioned system, in this case the goal is to define how a new system, often supported by some new technology should support achievement of users’ goals to improve some aspect of existing systems;

• The user task model, how the user actually thinks that tasks should be performed. Many usability problems derive from a lack of direct correspondence between the user and the system task model.

The design cycle represented in Figure 1 shows how the various task models can be considered. Often people start with the task model of the existing system and have requirements for designing a new system (for example, the use of some new technology). Thus, the modelling activity is used to identify the task model of a new, envisioned system that can be the starting point for the design of the concrete user interface. In order to have a first discussion regarding the preliminary design ideas designers often use early, rapid prototypes through paper, mock-ups and similar things. The envisioned task model and the early prototypes are the input for the actual design and development of the engineered prototype that will then become the delivered system. Constraints in the development of the system can bring to obtain a system whose task model is different from the initial envisioned model. So, if task models are used to support the evaluation of the system then a kind of reverse engineering work has to be done in order to identify the actual system task model that needs to be evaluated.

More generally, task mo• Improve understa

designers to claritheir constraints atogether with desthis technique (Panumber of issues

• Record the resultof the activities stakeholders (desi

• Support effective user interface then

• Support usabilitypredict time perfoanalyse the user a2002).

• Support the user automatically genthey perform disa

• Documentation, thsystem according

Informal descriptionOne issue often discudescriptions during thedifferences between theScenarios (Carroll, 20importance of scenario

Requirements of The New System

Existing System's

Task Model

Envisioned System's Task Model

Early System's Prototype

Design

Current Prototype's Task Model

Engineered Prototype

Reverse Modelling

Evaluation

Task Modelling Design

and Development

Figure 1: Use of task models in the design cycle

4

dels can be used for many purposes: nding of the application domain, the modelling exercise constraints fy about what tasks should be supported, their mutual relationships, nd so on. In a project on air traffic control, we developed task models igners who had been working for a long time in this domain without ternò, Santoro, et al., 2000). They admitted that this exercise raised a that they never considered before. of interdisciplinary discussion, since they are the logical description to support they should consider the viewpoint of all the relevant gners, developers, end users, domain expert, client, …). design, if a direct correspondence is created between the tasks and the users can accomplish their goals effectively and satisfactorily. evaluation, in this case task models can be used in various ways: to rmance, such as in GOMS approaches (John and Kieras, 1996) or to ctual behaviour, such as in WebRemUSINE (Paganelli and Paternò,

during a session, they can be used also at run-time, for example to erate task oriented help that can help users to reach their goals when bled actions explaining how to enable and perform them. ey can also be useful to provide documentation about how to use a

to the tasks supported.

s versus task modelling ssed is whether to use structured abstractions or more informal design cycle. This section provides an analysis of similarities and se approaches. 00) are the most well-known type of informal description. The s is generally recognised and their adoption in current practise is

5

impressive. Often scenarios are used even by people who have no knowledge of the HCI literature. When people want to discuss design decisions or requirements for a new system it is very intuitive to propose scenarios in terms of examples of possible use. A question is: what is a scenario? Sometimes one may get the impression that any type of description of system use can be a scenario. All this brings to mind a similar discussion on use cases; see for example (Cockburn, 1997), where the authors have classified 18 definitions of use cases depending on four issues (Purpose, Contents, Plurality and Structure). It can be useful to distinguish among various types of informal descriptions: stories, scenarios, use cases and task analysis. Stories include some emotional aspects (Imaz and Benyon, 1999). Scenarios provide a description of a single, concrete, detailed use of a system. Use cases are a bit more general and describe groups of use. Task analysis aims to be even more general. Scenarios, on the one hand, and task analysis and modelling, on the other, should not be confused. Actually, each can be applied without the other, even though it is advisable to use both of them. More generally, it is telling that the practise of software engineering applies scenarios mainly in the requirements phase. Thus, their strong point is the ability to highlight issues and stimulate discussion while requiring limited effort to develop, at least as compared to other more formal techniques. However, a scenario describes a single system use, there is a need for other techniques that may provide less detail but broader scope. Here is where task analysis comes in. Moreover, task analysis should be distinguished from task modelling. While the purpose of task analysis is to understand what tasks should be supported and what their related attributes are, the aim of task modelling is to identify more precisely the relationships among such tasks. The need for modelling is most acutely felt when the design aims to support system implementation as well. If we gave developers only a set of scenarios, they would have to make many design decisions on their own, likely without the necessary background, in order to obtain a complete system. This is why UML (Booch, Rumbaugh, et al., 1999) has been widely adopted in software engineering: its purpose is to provide a set of related representations (ranging from use cases to class diagrams) to support designers and developers across the various phases of the design cycle. Often it is difficult to immediately create a model from scratch. To overcome this problem various approaches have been explored. CRITIQUE (Hudson et al., 1999) is a tool that aims to create KLM/GOMS models (Card, Moran et al., 1983) from the analysis of use session logs. The model is created following two types of rules: the types of KLM operators are identified according to the type of event, and new levels in the hierarchical structure are built when users begin working with a new object or when they change the input to the current object. In this approach the limitation is that the task model only reflects the past use of the system and not other potential uses. U-Tel (Tam, Maulsby et al., 1998) analyses textual descriptions of the activities to support and then automatically associates tasks with verbs and objects with nouns. This approach can be useful but it is too simple in order to obtain general results. The developers of ISODE (Paris, Tarby, et al., 2001) have considered the success of UML and provide some support to import Use Cases created by Rational Rose in their tool for task modelling. The ConcurTaskTrees Environment (CTTE) (Mori, Paternò et al., 2002) supports the initial modelling work through the possibility of loading an informal textual description of a scenario or use case and interactively selecting the information of interest for the modelling. In this way, the designer can first identify tasks, then create a logical hierarchical structure and finally complete the task model. The use of these features is optional: designers can start to create the model directly using our editor but such features can be useful to ease the work of modelling. To develop a task model from an informal textual description, designers first have to identify the different roles. Then, they can start to analyse the description of the scenario, trying to identify the main tasks that occur in the scenario’s description and refer each task to a particular role. It is possible to specify the category of the task, in terms of performance allocation. In addition, a description of the task can be specified, along with the logical objects used and handled. Reviewing the scenario description, the designer can identify the

6

different tasks and then add them to the task list. This must be performed for each role in the application considered. When each role’s main tasks in the scenario have been identified, it might be necessary to make some slight modifications to the newly defined task list. This allows designers to avoid task repetition, refine the task names so as to make them more meaningful, and so on. Once designers have their list of activities to consider, they can start to create the hierarchical structure that describes the various levels of abstractions among tasks. The final hierarchical structure obtained will be the input for the main editor that allows specification of the temporal relationships and the tasks’ attributes and objects. How to represent the task model Many proposals have been put forward to represent task models. Hierarchical task analysis (Sheperd, 1989) has a long history and is still sometimes used. More generally, such notations can vary according to various dimensions:

• syntax (textual vs graphical), there are notations that are mainly textual, such as UAN (Hartson and Gray, 1992) where there is a textual composition of tasks enriched with tables associated with the basic tasks. GOMS is mainly textual, even if CPM-GOMS has a more graphical structure because it has been enhanced with PERT-charts that highlight the parallel activities. ConcurTaskTrees and GTA (van der Veer, Lenting et al., 1996), are mainly graphical representations aimed at better highlighting the hierarchical structure. In ConcurTaskTrees the hierarchical structure is represented from top to down whereas in GTA it is from left to right.

• set of operators for task composition, this is a point where there are substantial differences among the proposed notations. As table 1 shows, UAN and CTT are those that provide the richest set of temporal relationships. This allows designers to describe more flexible ways to perform tasks.

• level of formality, in some case notations have been proposed without paying sufficient attention to define the meaning of the operators. The effect is that sometimes when task models are created, it is unclear what is actually being described. This is because the meaning of many instances of such composition operators is unclear.

Table 1: Comparison of operators among notations for task modelling.

X X X X X Pre-post condition X X X Performance

X X Objects

X X Allocation

X X X X Iteration

X X Optionality

X X X X Only CPM-GOMS

Concurrency

X X X Interruption

X X X Order independence

X X X X X Sequence

GTA MAD CTT UANGOMS

7

The main features of ConcurTaskTrees are:

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

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

• Graphical syntax, a graphical syntax often (though not always) is easier to interpret, in this case it reflects the logical structure so it has a tree-like form.

• Rich set of temporal operators, a rich set of possible temporal relationships between the tasks can be defined. This set provides more possibilities than those offered by concurrent notations, such as LOTOS. This sort of aspect is usually implicit, expressed informally in the output 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 enabled from a semantic point of view.

• Task allocation, how the performance of the task is allocated is indicated by the related category and it is explicitly represented by using icons.

• Objects and task attributes, once the tasks are identified it is important to indicate the objects that have to be manipulated to support their performance. Two broad types of objects can be considered: the user interface objects and the application domain objects. Multiple user interface objects can be associated to a domain objects (for example, temperature can be represented by a bar-chart of a textual value).

For each single task it is possible to directly specify a number of attributes and related information. They are classified into three sections: General information. It includes the identifier and extended name of the task, its category and type, frequency of use, some informal annotation that the designer may want to store, indication of possible preconditions and whether it is an iterative, optional or connection task. While the category of a task indicates the allocation of its performance, the type of a task allows designers to group tasks depending on their semantics. Each category has its own types of tasks. In the interaction category examples of task types are: selection (the task allows the user to select some information); control (the task allows the user to trigger a control event that can activate a functionality); editing (the task allows the user to enter a value); monitoring; responding to alerts, …. This classification is useful to drive the choice of the most suitable interaction or presentation techniques to support the task performance. Frequency of use is another useful type of information because the interaction techniques associated with more frequent tasks need to be better highlighted to obtain an efficient user interface. The platform attribute (desktop, PDA, cellular, …) allows the designer to indicate for what type of devices the task is suitable. This information is particularly useful in the design of nomadic applications (applications that can be accessed through multiple types of platforms). It is also possible to specify if there is any specific precondition that should be satisfied before performing the task. Objects. For each task, it is possible to indicate the objects (name and class) that have to be manipulated to perform it. Objects can be either user interface or domain application objects. It is also possible to indicate the right access of the user to manipulate the objects when performing the considered task. Since the performance of the same task in different

8

platforms can require the manipulation of different sets of objects, it is possible to indicate for each platform what objects should be considered. In multi-user applications different users may have different right accesses. Time performance. It is also possible to indicate estimated time of performance (including a distinction among minimal, maximal and average time of performance). Table 2 shows more in detail the temporal operators provided by CTT.

Hierarchy Tasks at same level represent different options or different tasks at the same abstraction level that have to be performed. Read levels as “In order to do T1, I need to do T2 and T3”, or “In order to do T1, I need to do T2 or T3”

Enabling Specifies second task cannot begin until first task performed. Example: I cannot enroll at university before I have chosen which courses to take.

Choice Specifies two tasks enabled, then once one has started the other one is no longer enabled. Example: When accessing a web site it is possible either to browse it or to access some detailed information.

Enabling with information passing Specifies second task cannot be performed until first task is performed, and that information produced in first task is used as input for the second one. Example: The system generates results only after that the user specifies a query and the results will depend on the query specified.

Concurrent tasks Tasks can be performed in any order, or at same time, including the possibility of starting a task before the other one has been completed. Example: In order to check the load of a set of courses, I need to consider what terms they fall in and to consider how much work each course represents

Concurrent Communicating Tasks Tasks that can exchange information while performed concurrently Example: An application where the system displays a calendar where it is highlighted the data that is entered in the meantime by the user.

9

Task independence Tasks can be performed in any order, but when one starts then it has to finish before the other one can start. Example: When people install new software they can start by either registering or implementing the installation but if they start one task they have to finish it before moving to the other one.

Disabling The first task (usually an iterative task) is completely interrupted by the second task. Example: A user can iteratively input data in a form until the form is sent.

Suspende-Resume First task can be interrupted by the second one. When the second terminates then the first one can be reactivated from the state reached before Example: Editing some data and then enabling the possibility of printing them in an environment where when printing is performed then it is no possible to edit.

Table 2: Temporal operators in ConcurTaskTrees. It is important to remember that hierarchy does NOT represent sequence. In Figure 2 the goal of the designer is to specify that “In order to book a flight, I have to select a route, then select a flight and lastly perform the payment”. However the specification is wrong because the sequential temporal evolution should be represented linearly from left to right instead of from top to down.

Figure 2: Example of wrong specification of sequential activities.

When there is a need to get back at some point in the specification then it is possible to use the structure of the model and the iterative operator. For example, in Figure 3 once the task CloseCurrentNavigation is performed then the task SelectMuseum is enabled again because the parent task is iterative. This means that it can be performed multiple times and so its first subtask is enabled once the last one has been completed.

10

Figure 3: Example of parent iterative task. Optional tasks have a subtle semantics in CTT. They can be used only with concurrent and sequential operators. Their name is closed between squared brackets. For example, in Figure 4 Specify type of seat and Specify smoking seat are optional tasks. This means that once the mandatory sibling tasks (Specify departure and Specify arrival) are performed then both the optional tasks and the task after the enabling operator (Send request) are enabled. If the task after the enabling operator is performed then the optional tasks are no longer available.

Figure 4: Example of optional tasks.

In the task model, tasks inherit the temporal constraints of the ancestors. So, for example in Figure 5 ShowAvailability is a sub-task of MakeReservation and since Make Reservation should be performed after SelectRoomType then this constraint will apply also to ShowAvailability.

Figure 5: Example of inheritance of temporal constraints. With this approach to represent task models it is possible to represent slightly different behaviours even with small modifications in the specification. The two examples in Figure 6 have the same structure but the iteration in one case is in the parent task, in the other one is in the subtasks. So, the first example means that there is a task (Booking flights) that can be performed multiple times. Each time the two subtasks should be performed once. At the end, they will be performed the same number of times. In the other case the parent task has two iterative subtasks. This means that each of them can be performed an undefined number of times that is completely independent from the number of times that the other one is performed.

11

Figure 6: Example of different structures in task model specifications. Some of the features described were not included in the original version of CTT. The order independence operator has been included in order to provide an immediate description of a specific type of constraint. It differs from the concurrent operator because with the order independence when a task is started then it has to be completed before starting another one. Whereas with concurrent tasks it is possible to start the performance of another one before the completion of the first task started. Another feature of the notation recently added is the platform attribute. It allows designers to specify for what type of platform the task is suitable. In addition, it is also possible to specify for each object manipulated by the task in which platform it is suitable to support them. This type of information allows designers to better address the design of nomadic applications that can be accessed through a wide variety of platforms. The basic idea is that designers start to specify the task model for the entire nomadic application. Then, it is possible to derive the system task model for each platform considered by filtering tasks through the platform attribute. An example of specification Figure 7 represents the task model of a mobile phone. The task model is not complete for sake of brevity. It is important to note that the task model depends on the features of one specific type of cellular phone. This example shows that task models can also be useful to analyse the design of more recent mobile systems. The model is structured into two sequential parts: one dedicated to connect to the phone the other one to handle the communication. At any time it is possible to switch off the phone. The first part is a sequence of interactive and system tasks. Then, there is the part dedicated to the actual use of the phone, which is iterative because a user can perform multiple uses in a session. First of all, users have to decide what they want to do. Next, there are two main choices: either make a call (the most frequent function) or use other functions. In case of a call, the user can either select the number from a list or recall and enter it. The other possible uses are not detailed for sake of brevity.

Figure 7: Example of task model specification with ConcurTaskTrees.

12

UML and Task Models Model-based approaches have often been used in software engineering. If we consider UML, the most successful model-based approach for design of software systems, we can notice a considerable effort to provide models and representations to support the various phases and parts of the design and development of software applications. However, despite the nine representations provided by UML, none of them is particularly oriented to supporting the design of user interfaces. Of course, it is possible to use some of them to represent aspects related to the user interface but it is clear that this is not their main purpose. Aiming at integrating the two approaches (task models represented in ConcurTaskTrees and UML), there can be various basic philosophies that are outlined below. Such approaches can exploit, to different extents, the extensibility mechanisms built into UML itself (constraints, stereotypes and tagged values) that enable extending UML without having to change the basic UML metamodel. The types of approaches are: • Representing elements and operators of a task model by an existing UML notation. For

example, considering a ConcurTaskTrees model as a forest of task trees, where ConcurTaskTrees operands are nodes and operators are horizontally directed arcs between sibling nodes, this can be represented as UML class diagrams. Specific UML class and association stereotypes, tagged values and constraints can be defined to factor out and represent properties and constraints of CTT elements;

• Developing automatic converters from UML to task models, for example using the information contained in system-behaviour models supported by UML (use cases, use case diagrams, interaction diagrams) to develop task models.

• Building a new UML for interactive systems, which can be obtained by explicitly inserting ConcurTaskTrees in the set of available notations, while still creating semantic mapping of ConcurTaskTrees concepts into UML metamodel. This encompasses identifying correspondences, at both the conceptual and structural levels, between ConcurTaskTrees elements and concepts and UML ones, and exploiting UML extensibility mechanisms to support this solution;

Of course, there are advantages and disadvantages in each approach. In the first case, it would be possible to have a solution compliant with a standard that is already the result of many long discussions involving many people. This solution is surely feasible. An example is given in (Nunes and Falcao, 2000): CTT diagrams are represented as stereotyped class diagrams; furthermore, constraints associated with UML class and association stereotypes can be defined so as to enforce the structural correctness of ConcurTaskTrees models. However, the key issue is not only a matter of expressive power of notations, but it is also a matter of representations that should be effective and support designers in their work rather than complicate it. The usability aspect is not only important for the final application, but also for the representations used in the design process. For example, activity diagrams are general and provide good expressive power to describe activities. However, they tend to provide lower level descriptions than those in task models and they require rather complicated expressions to represent task models describing flexible behaviours. Thorny problems also emerge from the second approach. It is difficult to first model a system in terms of object behaviours and then derive a meaningful task model from such models because object-oriented approaches are usually effective for modelling internal system aspects but less adequate to capturing users' activities and their interactions with the system. The third approach seems to be more promising in capturing the requirements for an environment supporting the design of interactive systems. However, attention should be paid so that software engineers who are familiar with traditional UML can make the transition to this new method easily while limiting the degree of extension from the current UML standard. More specifically, use cases could be useful in identifying tasks to perform and related requirements, but then there is no notation suitable to representing task models, while there are various ways to represent the objects of the system to design. This means that there is a wide gap that needs to be filled in order to support models important for the design of user interfaces.

13

In defining a UML for Interactive Systems (Paternò, 2001) the use of task models represented in CTT can be explicitly introduced. However, not all UML notations are equally relevant to the design of interactive systems; the most important in this respect appear to be use case, class diagrams and sequence diagrams. In the initial part of the design process, during the requirement elicitation phase, use cases supported by related diagrams should be used. Use cases are defined as coherent units of externally visible functionality provided by a system unit. Their purpose is to define a piece of coherent behaviour without revealing the internal structure of the system. They have shown to be successful in industrial practise. Next, there is the task modelling phase that allows designers to obtain an integrated view of functional and interactional aspects. Interactional aspects, related to the ways to access system functionality, in particular cannot be captured well in use cases; so, in order to overcome this limitation they can be enriched with scenarios, informal descriptions of specific uses of the system considered. More user-related aspects can emerge during task modelling. In this phase, tasks should be refined, along with their temporal relationships and attributes. The support of graphically represented hierarchical structures, enriched by a powerful set of temporal operators, is particularly important. It reflects the logical approach of most designers, allows describing a rich set of possibilities, is declarative, and generates compact descriptions. In parallel with the task modelling work, the domain modelling is also refined. The goal is to achieve a complete identification of the objects belonging to the domain considered and the relationships among them. At some point there is a need for integrating the information between the two models. Designers need to associate tasks with objects in order to indicate what objects should be manipulated to perform each task. This information can be directly introduced in the task model. In CTT it is possible to specify the references between tasks and objects. For each task, it is possible to indicate the related objects, including their classes and identifiers. However, in the domain model more elaborate relationships among the objects are identified (such as association, dependency, flow, generalisation, …) and they can be easily supported by UML class diagrams. There are two general kinds of objects that should be considered: the presentation objects, those composing the user interface, and application objects, derived from the domain analysis and responsible for the representation of persistent information, typically within a database or repository. These two kinds of objects interact with each other. Presentation objects are responsible for creating, modifying and rendering application objects. The refinement of task and objects can be performed in parallel, so that first the more abstract tasks and objects are identified and then we move on the corresponding more concrete tasks and objects. At some point the task and domain models should be integrated in order to clearly specify the tasks that access each object and, vice versa, the objects manipulated by each task. Task models for multi-platform applications The availability of an increasing number of device types ranging from small cellular phones to large screens is changing the structure of many applications. It is often the case that within the same application users can access its functionality through different devices. In nomadic applications users can access the application from different locations, through different devices. This means that context of use is acquiring an increasing importance and it is important to understand its relationships with tasks. In general, it is important to understand what type of tasks can actually be performed in each platform. In a multi-platform application there are various possibilities:

• Same task on multiple platforms in the same manner (there could be only a change of attributes of the user interface objects);

• Same task on multiple platforms with performance differences: o Different domain objects, for example, presenting information on works of

arts can show different objects depending on the capability of the current device;

14

o Different user interface objects, for example, in a desktop application it is possible to support a choice among elements graphically represented, whereas the same choice in a wap phone is supported through a textual choice;

o Different task decomposition, for example, accessing a work of art through a desktop can support the possibility of accessing related information and further details not supported through a wap phone.

o Different temporal relationships, for example, a desktop system can support concurrent access to different pieces of information that could be accessed only sequentially through a platform with limited capabilities.

• Tasks meaningful only on a single platform, for example, browsing detailed information makes sense only with a desktop system.

• Dependencies among tasks performed on different platforms; for example, during a physical visit to a museum users can annotate works of art that should be shown first when they access the museum web site.

Task models for cooperative applications Providing support for cooperative applications is important because the increasing spread and improvement of Internet connections makes it possible to use many types of cooperative applications. Consequently, tools supporting the design of applications where multiple users can interactively cooperate are more and more required. In our approach, when there are multi-user applications the task model is composed of various parts. A role is identified by a specific set of tasks and relationships among them. Thus, there is one task model for each role involved. In addition, there is a cooperative part whose purpose is to indicate the relationships among tasks performed by different users. The cooperative part is described in a manner similar to the single user parts: it is a hierarchical structure with indications of the temporal operators. The main difference is that it includes cooperative tasks: those tasks that imply actions by two or more users in order to be performed. For example, negotiating a price is a cooperative task because it requires actions from both a customer and a salesman. Cooperative tasks are represented by a specific icon with two persons interacting with each other. In the cooperative part, cooperative tasks are decomposed until we reach tasks performed by a single user that are represented with the icons used in the single user parts. These single user tasks will also appear in the task model of the associated role. They are defined as connection tasks between the single-user parts and the cooperative part. In the task specification of a role, (see for example Figure 8, top part) we can identify connection tasks because they are annotated by a double arrow under their names.

15

Figure 8: Simplified example of cooperative task model.

The effect of this structure of representation is that in order to understand whether a task performance is enabled, it is required to check both the constraints in the relative single user part and the constraints in the cooperative part. It may happen that a task without constraints regarding the single user part is not enabled because there is a constraint in the cooperative part indicating that another user must first perform another task. If we consider the example in Figure 8 we can see the Search Product task performed by a customer and the Provide Info Product task performed by a salesman. If we consider each part of the task model in isolation, these two tasks can be started immediately. However, if we consider the additional constraint indicated in the part below we can see that the Provide list products task (by the salesman) needs to wait first the performance of the Ask information task (by the customer) in order to be enabled. We are aware that in cooperative applications users interact not only while performing their routine tasks but also when some external event blocks the work flow. Moreover, such events can create situations where previously defined tasks need to be changed and/or repeated. The task model associated with a certain role enables distinguishing both individual tasks and tasks that are related to cooperation with other users. Then, moving on to the cooperative part it is possible to see what the common goals are and what cooperation among multiple users is required in order to achieve them. The set of temporal operators also allows describing flexible situations where when something occurs, then activities need to be performed in a different manner. Of course, specifying flexible behaviours implies increasing the complexity of the specification. Trying to anticipate everything that could go wrong in complex operations would render the specification exceedingly complex and large. The extent to which designers want to increase the complexity of the specification to address these issues depends on many factors (such as the importance for the current project, resources available, experience in task modelling). The CTTE tool allows different ways to browse the task model of cooperative applications. The designer can interactively select the pane associated with the part of the task model of interest (in Figure 8 there is an example with a task model composed of a cooperative part and two roles, Customer and Sales Representative). In addition, when connection tasks are selected in the task model of a role (they are highlighted by a double arrow below their name)

16

then it is possible to automatically visualise where they appear in the cooperative part and vice versa.

Figure 9: The layout of CTTE. Tool support Table 3 summarises some features deemed important for analysis tools of task models and shows how they are supported by some of the currently available tools. The features provided by CTTE (see Figure 9) highlight its contribution to understanding the possibilities in terms of the analyses that can be performed with such tools. The first row indicates whether the tools are able to consider concurrent tasks, that is, their analysis is not limited to sequential tasks. Next, we look at their ability to analyse cooperative tasks involving multiple users. Then, we consider whether they are able to calculate some metrics. CTTE is also able to compare two models with respect to a set of metrics. Euterpe (van Welie, van der Veer, et al., 1998) also supports the calculation of some metrics to analyse a specification and find inconsistencies or problems. The remaining features considered are the ability to predict task performance. This is usually supported by tools for GOMS such as QDGOMS (Beard, Smith, et al.) and interactively simulate the task model’s dynamic behaviour. Interactive simulation is also another important feature supported by a few tools, such as VTMB (Biere, Bomsdorf, B. et al., 1999).

CTTE Euterpe VTMB QDGOMS IMAD* Adept Concurrent

tasks XXX XXX XXX XXX XXX

Cooperative tasks

XXX XXX

Metrics XXX XXX Reachability XXX Performance evaluation

XXX XXX

Simulator XXX XXX Table 3: Comparison of Tools for Task Modelling

17

Conclusions CTT and the related environment represent a contribution to engineering the use of task model in the design, development and evaluation of interactive systems. In this chapter the main features of the notation have been discussed and indications about how to address important related issues (such as integration with UML, design of multi-platform applications, task models for cooperative applications) have also been provided. The approach has also stimulated a good deal of research work: (Nunes and Falcao, 2000) propose a transformation from UML to CTT, in (Sage and Johnson, 1997) there is a proposal for integrating CTT and a functional language to obtain a user interface prototyping environment, while (Pribeanu, Limbourg et al., 2001) explore solutions to extend CTT to include context of use information. Furthermore, the reference framework for plastic user interfaces (Calvary, Coutaz et al., 2001) considers task models (in particular represented by CTT) as a starting point for the design work, and the MEFISTO project, which aimed to identify methods supporting design of air traffic control applications, provided an integration between task models represented by CTT and system models represented by ICO Petri Nets (Navaree, Palanque et al., 2001). In addition, the notation and tool have been used for teaching purposes and in various projects all over the world. References Beard D., Smith D., Denelsbeck K., Quick and Dirty GOMS: A Case Study of Computed Tomography, Human-Computer Interaction, V.11, N.2, pp.157-180, 1996. Biere, M., Bomsdorf, B., Szwillus G., Specification and Simulation of Task Models with VTMB, Proceedings CHI’99, Extended Abstracts, ACM Press, pp.1-2, 1999. G.Booch, J.Rumbaugh, I.Jacobson, Unified Modeling Language Reference Manual, Addison Wesley, 1999 Card, S., Moran, T., Newell, A., The Psychology of Human-Computer Interaction, Lawrence Erlbaum, Hillsdale, 1983. G. Calvary, J. Coutaz, D. Thevenin A Unifying Reference Framework for the Development of Plastic User Interfaces, Proceedings Engineering HCI '01, Springer Verlag, pp.218-238, Toronto, 2001. Carroll J. (2000), Making Use – Scenario-based design of human-computer interactions, the MIT Press. Cockburn, A., 1997. Structuring use cases with goals. J Object-oriented Program. http://members.aol.com/acockburn. Gamma E., Helm R., Johnson R., Vlissides J., “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison Wesley, 1995. Hartson R., Gray P., “Temporal Aspects of Tasks in the User Action Notation”, Human Computer Interaction, Vol.7, pp.1-45, 1992. Hudson, S., John, B., Knudsen, K., Byrne, M., “A Tool for Creating Predictive Performance Models from User Interface Demonstrations”, Proceedings UIST’99, ACM Press, 1999. Imaz, M., Benyon, D., 1999. How stories capture interactions. Proceedings Interact'99, pp. 321-328. John, B., Kieras, D., “The GOMS Family of Analysis Techniques: Comparison and Contrast”. ACM Transactions on Computer-Human Interaction, Vol.3, N.4, pp.320-351, 1996. Q. Limbourg, B. Ait El Hadj, J. Vanderdonckt, G. Keymolen, E. Mbaki, Towards Derivation of Presentation and Dialogue from Models: Preliminary Results, Proceedings DSV-IS 2000, Lecture Notes in Computer Science 1946, pp.227-248, Springer Verlag, 2000. Navarre D., Palanque P., Paternò, F., Santoro C., Bastide R., A Tool Suite for Integratine Task and System Models through Scenarios, pp.88-113, Sprinter Verlag LNCS 2220.

18

N.Numes, J.Falcao, Towards a UML profile for user interface development: the Wisdom approach, Proceedings UML'2000, Lecture Notes Computer Science, pp.50-58, Springer Verlag. Mori G., Paternò F., Santoro C., (2002), CTTE: Support for Developing and Analyzing Task Models for Interactive Systems Design, IEEE Transactions on Software Engineering, September 2002. L.Paganelli, F. Paternò, Intelligent Analysis of User Interactions with Web Applications. Proceedings ACM IUI 2002, pp.111-118, ACM Press. Paris, C., Tarby, J. & Vander Linden, K., (2001). A Flexible Environment for Building Task Models. Proceedings of the HCI 2001, Lille, France Paternò, F., (1999) Model-Based Design and Evaluation of Interactive Application. Springer Verlag, ISBN 1-85233-155-0. F.Paternò, Towards a UML for Interactive Systems, Proceedings Engineering HCI '01, Springer Verlag, pp. 175-185, Toronto, 2001. F. Paterno', C.Santoro and 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. Pribeanu, C., Limbourg Q., Vanderdonckt J. (1991), Task Modelling for Context-sensitive User Interfaces, Proceedings DSV-IS 2001, pp.49-68, Sprinter Verlag LNCS 2220. Sage, M., Johnson C., Haggis: Executable specifications for interactive systems, Proceedings DSV-IS’97, pp.93-109, Springer Verlag. Scapin, D., Pierret-Golbreich, C., “Towards a Method for Task Descrption: MAD”, Proceedings Work with Display Unit, pp. 78-92, Elsevier, 1989. Sheperd (1989), Analysis and Training in Information Technology Tasks, in D.Diaper (ed.), Task Analysis for Human-Computer Interaction, chapter 1, pp.15-55, Ellis Horwood, Chichester, 1989. Tam, R.C.-M., Maulsby, D., and Puerta, A., “U-TEL: A Tool for Eliciting User Task Models from Domain Experts”, Proceedings IUI’98, ACM Press, 1998 van der Veer, G., Lenting, B., Bergevoet, B., “GTA: Groupware Task Analysis - Modelling Complexity”, Acta Psychologica, 91, pp. 297-322, 1996. van Welie M., van der Veer G.C., Eliëns A., “An Ontology for Task World Models”, Proceedings DSV-IS’98, pp.57-70, Springer Verlag, 1998.