Choosing the right task modelling notation: A taxonomy - CiteSeerX

Choosing the right task modelling notation: A taxonomy Sandrine Balbo1, Nadine Ozkan2 and Cécile Paris3 1

Modem Media, 183 Eversholt Street, London NW1 1BU - UK Email: [email protected]

2

Lanterna Magica, 433 West St-Joseph, suite 20, Montreal, QUE H2V 2P3 - Canada Email: [email protected] 3

CSIRO MIS, Locked Bag 17, North Ryde, NSW 1670 – Australia Email: [email protected]

A number of task modelling notations have been developed in the HumanComputer Interaction (HCI) communities, often with different goals and thus different strengths. Usually, each model is designed to be employed at a specific phase of the Software Development Life Cycle (SDLC). Without an explicit understanding of the different attributes of these models, it is difficult to select a specific one to achieve one's goals. To address this issue, we propose a taxonomy consisting of several axes. The elements of the taxonomy have been defined according to various criteria we have found useful to consider when having to decide on a specific methodology or task model. In this chapter, we first present our taxonomy. We then illustrate it with a few examples. We choose these models either because we used them ourselves, or because they are the most popular in the literature. Keywords: taxonomy, task modelling notation, development life cycle, communication, usability, modelling, adaptability, coverage, extensibility, use case, scenario, MAD, DIANE+, UAN, functional flow, GOMS.

Introduction A number of task modelling notations have been developed in the Human-Computer Interaction (HCI) community, often with different goals and thus different strengths. For example, each notation is usually designed to be employed at a specific phase of the Software Development Life Cycle (SDLC), or for the design of a specific type of system. Without an explicit understanding of the different attributes of these notations, it is difficult to select a specific one to achieve one’s goals. To address this issue, we have tried to organise the various notations in a taxonomy consisting of several axis, building on the work of (Balbo, 1994), (Brun and Baudoin-Lafon, 1995) and (van Welie, et al., 1998). The elements of the taxonomy have been defined according to various criteria we have found useful to consider when deciding on a specific task modelling notation. In this chapter, we present our taxonomy. We then illustrate the main axis in the taxonomy with sample notations. We choose these notations either because we used them ourselves, or because they are the most representatives of the literature. We ensure that together they cover a wide range of issues that must be addressed.

The aim of our taxonomy is two-fold. On the one hand, it is intended to help system designers (in a wide sense) choose an appropriate notation. The intention is to help first to determine what attributes are required of a notation to suit specific purposes, then to consider different available notations which exhibit the appropriate attributes, and finally, to choose amongst them. We believe that a clear understanding of the various attributes of different notations and what they can cover helps ensure an appropriate choice of notation. The intention here is to improve and facilitate the practice of task modelling. On the other hand, the taxonomy is also meant to provide a “state-of-the-art” global view of the state of task modelling practice. This allows the research community to assess the usefulness of task modelling, understand what is the covered today by notations, what types of new notations might be needed, etc.

Taxonomy definition We combine and build on factors from the taxonomies introduced by (Balbo, 1994), (Brun and Baudoin-Lafon, 1995) and (van Welie, et al., 1998). We found, however, that these taxonomies should be augmented and updated in order: • to reflect our specific aims, as defined above, and also, • to incorporate specificities of recent types of systems or recent constraints imposed on systems, e.g., Web applications, applications for mobile devices, multi-platform applications (i.e., the same applications deployed on several platforms, such as PC and Palm). In this section, we present the various axes of our taxonomy. Each axis is described, along with its potential values. Note that while the first two axes of our taxonomy refer to when and how a notation is used, the other axes refer to the various characteristics a notation may have. Axis 1- Goal/aim of using a notation The first axis of the taxonomy refers to the desired goal in using task modelling. Task modelling can be used for a variety of purposes: for system design, for system evaluation, for the automatic generation of parts of the system, etc. Moreover, task models can take on different levels of abstraction, from high-level user-oriented models to more detailed systemoriented ones (Paris, et al., 2001), each level serving a different purpose throughout the software development life cycle (SDLC). Hence, in order to systematise our approach to the desired goal, we refer to the various phases of the software development lifecycle as potential values for the “goal” axis. We borrow the phases defined by IBM in (Bardon, et al., 2001), because they seem sufficiently general to accommodate other methodologies. These phases are listed below. Axis 1- 1st value: Discover and Define. This first phase is an exploration of the various concerns that will impact system design. It consists in understanding the requirements of the various stakeholders, the target environment, the type of functionality required, the various constraints that must be taken into account, etc. When task modelling is used at this phase, it is for high-level descriptions, rather than as a fine-grained method (as it is used in later phases). The aim here is to “identify the main tasks and the main objects that are relevant for the user. Here, the level of abstraction is very high; the tasks are “black boxes” and the objects are objects that the user employs” (Paris, et al., 2001, p. 317). A similar approach is developed in the Scenario Based Design (SBD) methodology (Rosson and Carroll, 2001), where problem scenarios are used to analyse requirements. We briefly illustrate the use of task modelling here by examining the design of “innovative” systems (Ozkan, et al., 1998b). Innovative systems are those that either create new possibilities and new tasks, or that have a major impact on existing tasks, virtually

transforming them into new ones. Task modelling, even before the real design of a system starts, is useful for innovative systems, as it allows one to map out the future application’s environment, including the place of the application in the environment, and how it might impact it. Performing a task analysis thus facilitates projecting the future environment and understanding the system’s place within it. It also highlights some of the requirements placed by the future environment on the system. While this is important for any applications, it is crucial for the design of innovative systems. For example, the introduction of an automatic on-line help generator can change dramatically the tasks and functions of technical writers (Paris, et al., 1998a). A task modelling analysis will help understand the impact of the technology, and the possibilities it may create. (Refer to (Ozkan, et al., 1998a) and (Paris, et al., 2000) for further discussion of this use of task modelling.) Axis 1- 2nd value: Design By design, here, we mean system design, user interface design, and documentation design, all of which are activities ideally taking place in parallel from some common specifications. This is the phase when task modelling is traditionally mostly used, because it provides an understanding and an explicit representation of how the system will function in its relationship with the user. Thus the main use of task modelling is for user interface design. Task modelling here also usually impacts system architecture, through the identification of common functions across an application, which correspond to common architectural modules. A specialised use of task modelling at this stage consists in the definition of generic functionalities, i.e., functionalities that should exist and function consistently across a suite of applications (such as the “File Open” functionality). Here, we touch on the idea of a “task model library”, valid across several applications, and which would eventually be implemented in a software library, ensuring consistency and learnability over several applications. We have, for example, defined a task library for the UI-Card application suite (UICard Project description, 2002). A similar specialised use of task modelling at this stage is for defining the user interface of an application that must be deployed on several platforms, and that must function as consistently as possible across them (Thevenin and Coutaz, 1999). Finally, there is increasing evidence (e.g., Balbo and Lindley, 1997) that task modelling can be used for another type of design, often overlooked in software development, namely documentation design. Task modelling can help organise the functional system documentation (as opposed to the other types of system documentation, defined in (Paris, et al., 1998a)). Axis 1- 3rd value: Develop and Deploy For the implementation phase, following (Brun and Baudoin-Lafon, 1995), we consider that a notation could aim to achieve two purposes: • The derivation of the generic functions of the system. Some task modelling notations may highlight the fact that some functions of the application are generic throughout all its modules, and should be implemented as such. (This is akin to the architectural concerns discussed in the previous section; here, however, we refer specifically to concerns of implementation efficiency.) • The automatic generation of all or parts of the final system. For our purposes, this could include the automatic generation of part of the system itself, portions of the user interface, or even the automatic generation of portions of the end-user documentation. (Refer to (Vanderdonckt and Berquin, 1999) for an example of the automatic generation of portions of the user interface, and (Paris, et al., 1998b) for an example of the automatic generation of portions of the end-user documentation.)

The appropriate degree of formality of a notation depends on what parts of the final system should be generated: by definition, formal notations are those used for the automatic generation of code, while semi-formal notations can be used for the automatic generation of end-user documentation. Axis 1- 4th value: Evaluation and Prediction Some task modelling notations were designed specifically for user interface evaluation. Of special interest among these are predictive notations, e.g., the extended family of GOMS models (John and Kieras, 1994). These can be used to predict time on task, successful task completion and the effect of errors on time performance. Other notations, whether specifically designed for evaluation or not, are commonly used to design empirical usability tests, either experimental or more naturalistic. (See (Paternò, 1999) for a description of various modelbased usability evaluation techniques.) Usability The usability of a notation covers two distinct notions, and hence two axes in our taxonomy are related to it. The first notion refers to the ease with which a task model can be read and understood for the purposes of communicating a design to participants to the SDLC other than the task modelling team. Here, the notion of usability integrates that of learnability and readability. The second notion concerns the ease with which task models are generated, maintained and manipulated (modified) within the task modelling team. For this second purpose, the notion of usability also includes that of ease of use. Both notions of usability are discussed below. Axis 2- Usability for communication Although task modelling notations are usually not designed explicitly for this purpose, our own experience (e.g., Paris, et al., 2000) well as other sources (e.g., van Welie, et al., 2000) show that the communicative function of task models is one of their major values: in practice, task models often act as a franca lingua among all or a subset of the parties involved in and impacted by the development and introduction of an application. In general, communication throughout the SDLC is a crucial and frequent activity that involves people from widely different backgrounds: software architects, user interface designers and evaluators, graphic artists, implementers and testers, technical writers, end-users and various stakeholders. The main communication activities needed to support the various phases of the SDLC are: • to illustrate and validate user requirements, • to define the vocabulary to be used in the user interface and in the system’s documentation, • to validate feasibility, • to design and validate the system’s documentation, • to integrate usability evaluation in the system development life cycle. In order to support effectively one or several of these communication purposes, a notation must typically be easy to read and quick to be learned by neophytes, i.e., by people with no background in task modelling. Obviously, graphical, semi-formal notations are more suited to this purpose than are formal notations. See (Ozkan, et al., 1998a) for an experimental study of a graphical notation’s usability. Axis 3- Usability for modelling tasks Another related and less frequent concern regarding usability refers to the degree of ease with which task models are generated and manipulated. This concern is relevant in settings where a notation is to be used strictly by the design and development team (for automatic generation purposes for example) and where there are tight deadlines, or when there is high staff

turnover. In these cases, efficient communication is crucial, but here, the notation’s usability must be high for professionals. In addition, the notation should, ideally, be commonly used, and abundantly documented and illustrated. Axis 4 - Adaptability This characteristic refers to whether or not the notation can be adapted easily to fit a new situation when necessary. We have found that feature to be an important one as we apply task models in novel and varied situations, to be exploited in innovative ways. We consider three types of extensibility: (1) adaptability to new aims. For example, can a task notation originally intended for the design phase be employed for evaluation? (2) adaptability to new types of systems. This applies to notations that are specialised. Notations have been developed for specific types of systems, such as real-time and simulation. Can such notations be successfully and easily applied to other types of systems? (3) adaptability to new systems requirements. For example, a new requirement for some types of applications is that they must be deployed on several platforms (e.g., PalmPilot and PC) with similar, or at least compatible, user interfaces. Can the notation accommodate these new requirements? This characteristic is obviously linked to “expressive power” below: one may decide to choose a notation that is limited in expressive power, but flexible enough to be easily adapted. Axis 5 - Coverage or expressive power This refers to the breadth of what the notation can express. Specific task attributes that may be important to represent (depending on the application) are: a. optionality (i.e., whether a task is mandatory or optional); b. task agency (i.e., who must perform the task: the user, the system, or both); c. levels of decomposition: is decomposition allowed, and is there a limit to the permitted number of levels of decomposition? d. temporal relationships amongst tasks; These include the various notions of synchronisation of actions (sequencing, alternatives, composition – i.e., A and/or B-, and iteration), parallelism (interleaved or true parallelism), and delays; and finally, e. non standard actions, for example, actions that represent the management of errors of interface feedback to the end-user. For example, a notation used for the automatic generation of on-line help should allow the representation of system feedback upon a user action. This characteristic is obviously linked to that of “extensibility” below: a notation which does not meet some particular requirement in terms of coverage can still be adequate, provided its coverage can be extended. Axis 6 – Extensibility Linked to “coverage” and to “adaptability” above is the ease with which a notation’s coverage can be extended. Often, a notation used in a situation or for a purpose other than that originally intended will require some adaptations in terms of coverage. The choice of a notation then depends on whether these extensions can be made easily or not. For example, Diane+, when used for the automatic generation of systems documentation, was easily augmented in order to represent notions specific to this domain (Paris, et al., 2000). In general, it is a safe rule of thumb that graphical, semi-formal notations can easily be extended to express relationships or concepts not originally included. Other notations, such as the more formal ones, are more difficult to extend.

Synthesis In this section, we have presented our taxonomy by discussing its various axis. Table 1 summarises our taxonomy’s axes, and the values for each axis. Axis 1. Goal 2. Usability for communication 3. Usability for modelling 4. Adaptability 5. Coverage Optionality Agency Decomposition Temporal Non standard 6. Extensibility

Values Discover & Define / Design / Develop & Deploy / Evaluate & Predict High / Medium / Low High / Medium / Low High / Medium / Low High / Medium / Low Yes / No Yes / No Yes / No Yes / No Yes / No High / Low

Table 1: Our taxonomy: its axes and their values In italics are the elements that may help setting a value for the “coverage” axis As we have highlighted throughout this section, these axes are not independent. In fact, there are many interdependencies among them. In this sense, because the axes are not “orthogonal”, the taxonomy is not “formal”, i.e., it cannot be used to systematically reason about notations. Formal reasoning is not our purpose here. As stated above, the aim taxonomy is to serve as a repository of current task modelling practices. In this sense, it is a “living” entity, which should ideally be updated regularly in order to remain a useful resource for both researchers and practitioners.

Examples of Task Modelling Notations In the previous section, we have described the various characteristics that one could seek when choosing a task modelling notation, and various attributes that a task modelling notation could cover. In this section, we discuss six well-known and widely used notations, examining which characteristics they exhibit and which attribute they cover. This section will thus illustrate the meaning of each attribute of our taxonomy with concrete examples, and enable the reader to understand how well known notations fit in the taxonomy. It is important to realise that, in some cases, the way we “rate” the notation with respect to the taxonomy is subjective and reflects our experience. For example, while one can state whether a notation allows for the representation of task decomposition, it would be hard to state with absolute truth that a notation has value “high” for adaptability. This has to be a value judgement, which we will do based on our experience. We review the following notations: • Use Cases and scenarios (Jacobson, et al., 1992; Constantine and Lockwood, 1999); • MAD (Sebillotte, 1995; Rodriguez and Scapin, 1997; Scapin and Bastien, 2001); • Diane+ (Tarby and Barthet, 1996; Tarby and Barthet, 2001); • UAN (Hix and Hartson ,1993); • Site maps and functional flows, as used for the development of web sites at Modem Media (Modem Media, 2002), an international online advertising and web agency; and, finally,

•

KLM and CPM-GOMS (Card, et al., 1983; John and Kieras, 1994).

We have personally employed these notations, either in industry or with industrial partners, with the exception of KLM and CPM-GOMS. Each notation is illustrated with the same example: an extract of the task: “Booking a Flight”, as defined in the www.Go-fly.com web site. For the sake of simplicity, and to be able to go straight to the points we wish to illustrate, we only keep a subset of all the actions that are required. In particular, for the step corresponding to the selection of the flight, we only represent the selection of the departure and arrival airports. Although this example is simple, the task still requires the representation of: • a hierarchy of tasks, • both user’s and system’s actions, • sequences of tasks and actions, and • parallel actions (e.g., all the parameters for the flight besides the departure and arrival airports can be entered in parallel). In each of the subsection below, we first briefly introduce the notation, describe the task of booking a flight as represented with the specific notation under consideration, and, finally, discuss the attributes covered by the notations. Use Cases and Scenarios Use Cases are narrative descriptions about the interaction between a user – in some user role and a system, within the specific use of a complete system, with a goal that is meaningful to the user. Uses cases are essentially stories that describe the intended interactions between a user and a system. Although (Jacobson, et al.,1992) define use cases as tools to specify all the functionalities of a system, they are meant to be informal and imprecise. As such, their main use is at the “Discover and Define” phase of the SDLC. In the later versions of the Unified Modelling Language, use cases take a non-narrative form (Rumbaugh, 1999). In UML, uses cases are used primarily to capture the high-level user-functional requirements of a system (Kenworthy, 2002), which, again, correspond to the first phase of the SDLC. Another nontextual narratives form of use cases has been developed by (Constantine and Lockwood, 1999): the essential use cases. Their aim is to highlight more explicitly the interaction itself. We use essential use cases to illustrate our example below. Before doing so, however, we briefly describe scenarios, in order to establish their similarities to use cases. A scenario is a particular instantiation of a use case, and many scenarios will be extracted from one particular use case. Scenarios are also mainly represented using narrative descriptions. They describe the setting, the actor(s) and the events of a user-computer interaction. In addition, they include information about user’s mental activities (e.g., goals, plans and reactions). There is generally no notation associated to them, and no formal approach to deal with them, although the approach proposed by (Rosson and Carroll, 2001) restricts the type of narratives one can write by requesting a specific set of stories for different scenarios, corresponding to the different elements one is trying to elucidate. For example, to analyse requirements, one should have problem scenarios, which tell a story of current practice; to envision new designs, activity scenarios, which specify functionalities, should be written. Information scenarios provide details about the information that the system will provide to the user. Yet, other types of scenarios, interaction scenarios, describe user actions and system feedback. Generally, scenarios emphasise realism and richness of details. In contrast, use cases, in particular essential use cases, extract the basics of the interaction capturing the essence of a subset of scenarios. An essential use case, as introduced by (Constantine and Lockwood, 1999), represents a streamlined version of a use case. The notion of a use case map is also defined. This map interrelates the set of use cases for one

development. We illustrate this concept in our example below. Figure 1 presents the use case map, while tables 2 and 3 show the essential use cases for the task of booking a flight. In a use case map, uses cases can be related in various ways. For example, in figure 1, we have two types of relations between use cases: extensions (links labelled extends) and composition (links labelled uses). The ‘Select other parameters’ use case extends ‘Find the right flight’, as it expresses optional tasks that are to be run in parallel to the mandatory task of ‘Find the right flight’. The composition link indicates that a use case is a component of another use case. So ‘Choose a flight’ is a component, or sub-use case, of ‘Find the right flight’. In tables 2 and 3, composition is indicated with the “>” symbol in front of the call to the sub-use case. Choose a flight uses uses extends

Find the right flight

uses

Pay

Select other parameters

Book a flight uses

Issue receipt & ticket

Figure 1: Use Case map extract for Booking a flight User Intention

System Responsibility

> Find the right Flight > Pay > Issue Receipt & Ticket Table 2: Use Case for Book a Flight User Intention

System Responsibility

Select departure airport Update return airport list Select return airport > Choose a flight Flight selected Table 3: Use Case for Find the Right Flight Use cases, scenarios, and even essential use cases are fairly informal ways to perform a task analysis. As such, then, their main usage is at the “Discover and Define” phase of the SDLC, providing a rich setting as context for the later stages of the design process. Essential uses cases may be also employed in designing the interface, as they provide a streamlined specification of the interaction between the user and the system. While they can also be a useful tool to facilitate communication amongst all the parties involved (everyone understands a narrative), care must be taken: because language is imprecise, one may not be sure that all parties really understand the same thing with the same textual narrative. Because uses cases and scenarios are textual narratives, they are adaptable: one can describe what needs to be described. Similarly, their expressive power is quite large, once again

because they are written in a rich representation, i.e., language. This, on the other hand, decreases their formality and ability to be exact, precise and unambiguous. For example, it may actually be quite awkward to express unambiguously various formal relationships between actions (e.g., whether a task may be interrupted or not). Clearly, use cases and scenarios have no “generative power”, i.e., no elements of the final system can be generated automatically. Méthode Analytique de Description (MAD) MAD (Sebillotte, 1995; Rodriguez and Scapin, 1997; Scapin and Bastien, 2001) is both a task notation and a methodology for the acquisition of task knowledge based on extensive interviews with end-users. In MAD, tasks are decomposed hierarchically and linked by temporal and logical relations in its associated graphical representation. A task or sub-task is represented as a tree whose nodes are tasks, sub-tasks or elementary actions. Each task, sub-task or elementary action is characterised by its name, appearing in the tree, along with additional information recorded either on the tree itself or in separate text tables. The additional information states the task’s goal, its initial and final states, pre- and post-conditions and some attributes. These attributes indicate whether the task is iterative or not, whether it is optional or mandatory, whether it is a priority task (i.e., a task allowed to interrupt other tasks) and whether the task is interruptible. Our sample task using the MAD notation is shown in figure 2. To Book a Flight, the user must first “Find the Right Flight”, then “Pay”. The system then will “Issue receipt and ticket”. System actions are indicated with a square shaped box. These three actions are sequential, as indicated by the annotation SEQ. The figure 2 shows several levels of decompositions, reflecting the hierarchy of tasks and sub-tasks. Some of the tasks are decomposed elsewhere (i.e., outside this diagram). This is indicated with shadowed boxes: so, in figure 2, “Pay”, “Issue receipt and ticket”, “choose a flight” are all decomposable tasks whose decomposition is now shown here. Only task names are shown here for the sake of simplicity, and not their associated notes contained in the separate text tables. Book a flight SEQ Find the right flight SEQ

Enter flight details PAR

Display all flights corresponding to details

Select departure and arrival airports SEQ

Select departure airport

Pay

Issue receipt and ticket

Choose a flight

Select other parameters

Update return airport list with possible flights

Select return airport

Figure 2: Extract of the MAD description

MAD stipulates that end-user task analysis and description contribute to user requirements analysis, and is thus intended to be used at the beginning of the SDLC, that is in the “Discover and Define” phase. However, MAD task descriptions can also be exploited at later phases, for example for the design of the user interface and of the help content, as described for the APLCRATES project in (Balbo and Lindley, 1997). With respect to our taxonomy, then, MAD can be used for the first two values of “Goal”. Its use for the “Develop and Deploy” and “Evaluate” is not as clear. In the “Develop and Deploy” phase, MAD could be used to identify and specify the generic functions of the system. It could not be used to generate automatically any part of the final system. Finally, while a MAD description can be manually used in evaluation to compare actual usage to intended usage (as specified in the model), its use in evaluation is not a formal or systematic one. Our experience with respect to usability for communication is that MAD is a very good tool for communication. This is due to its semi-formality: the graphical notation mixed with textual description is, on the one hand, easy to understand, and, on the other hand, sufficiently precise to ensure common understanding. This was in fact one of the major role the notation played in a project which included all actors within the development team addressing decision support system development, database definition, on-line help, user manual definition, and also the end-users and management on the client side (Balbo and Lindley, 1997; Paris, et al., 2000). In the context of the APLCRATES project, the MAD notation was used for two purposes: to help in the design of the user interface and the various documentations, and to represent the expertise extracted from the domain experts. This latter use presented a new situation for MAD, one for which it was not originally designed, and for which the notation had to be extended and adapted. We encountered no major difficulties in doing so. We thus found the notation adaptable to this new situation and extensible to fit the new requirements. On the other hand, in the Isolde project, where we wanted to exploit task models for the automatic generation of on-line help, we preferred using DIANE+ instead of MAD, because of the lowlevel of formality of MAD, which limits its generative power (as a lot of information is still represented in free text). In terms of coverage, MAD allows for the representation of a hierarchy, without any restrictions on the number of levels allowed. The attribute “Agency” (i.e., whether an action is to be performed by the user or the system) can be represented in a limited way: MAD cannot represent the notion that an action may need to be performed by both agents. MAD can represent some of the temporal relationships amongst actions. It cannot, however, represent formally, as part of its diagrammatic notation, the number of iterations (i.e., this task is to be repeated N number of times). This information can be expressed, but this has to be done through the textual descriptions attached to each task. Because MAD is a semi-formal notation that employs both graphics and text, it combines formal (through the graphical notation) and informal (through text) coverage, and extensibility is high, but as more information is represented in textual form, its generative ability diminishes, and there is an increased risk of ambiguity. DIANE+ DIANE+ (Tarby and Barthet, 1996; Tarby and Barthet, 2001), a descendent of DIANE (Barthet, 1988) is similar to MAD in that it is also to be used during the user requirement analysis phase and can guide the design of the user interface. Like MAD, it uses a graphical notation to represent task decomposition as well as temporal and logical relationships among tasks. In DIANE+, though, more information is explicitly and formally represented. For example, a DIANE+ diagram explicitly indicates whether a task is to be accomplished by the

end-user, by the system, or by a combination of both. DIANE+ also allows for the formal representation within the diagram of concepts such as iteration and optionality. Figures 3 and 4 show the DIANE+ version of our Flight Booking example. The top-level functionalities are shown, as well as the “Select departure and arrival airports” function. In DIANE+ diagrams, a task is represented by a box containing the name of the task (usually quite short) and, when appropriate, the constraints on the number of times the task can be executed (to represent iteration). These constraints are expressed by two integers (i,j) where i is the minimum number of times the task can be executed, and j is the maximum. Default values are (0,n) for optional tasks and (1,n) for mandatory tasks. In the original DIANE+, another tuple of integers is associated to the task to express the number of iterations on a task’s sub-tasks. In our work with DIANE+, while we kept the iteration constraint on a task, we discarded the ability to express the number of iterations on a task’s sub-tasks, as it seemed confusing and as sub-tasks iterations could be expressed in alternate ways. The decomposition of a task is expressed in the big rectangle linked to that task. Like MAD, DIANE+ does not impose any restrictions on the number of levels that can exist in a decomposition hierarchy. DIANE+ represents optionality explicitly: a box drawn with a full line indicates a mandatory task while a dashed line indicates an optional task. The shape of the box represent Agency: an ellipse-shaped box indicates that the task is purely manual, i.e., performed by the end-user; a rectangle-shaped box indicates an automatic task, i.e., performed by the system; and, finally, a rounded-shaped box indicates an interactive, i.e., a task performed by the end-user together with the system. In Figures 3 and 4, all tasks shown are either interactive or automatic. As in MAD, a shadow around a task box indicates that the task is to be decomposed elsewhere. For example, “Select departure and arrival airport” is shown as decomposable in figure 3, and its decomposition is given in figure 4. Task preconditions, system feedback to a task and task termination can also be indicated explicitly in a diagram, although none are shown in our example.

Book a flight

Find the right flight

Enter flight details Display all flights corresponding to details

Select departure and arrival airports Select other parameters

Pay Choose a flight Issue receipt and ticket

Figure 3: Description of Flight Booking example using DIANE+ Select departure and arrival airports

Select departure airport

Update return airport list with possible flights

Select return airport

Figure 4: The task “Select dep. & ar. airports” described in DIANE+

DIANE+ allows for the representation of temporal relations amongst actions such as sequencing and parallelism. The sequence is represented through the arrow symbol. When tasks can be done in parallel, they are shown in the same decomposition box but without any arrow between them as for the two sub-tasks composing “Enter flight details” in figure 3. DIANE+ can also represent Boolean connectors, such as OR, XOR and AND. While still a semi-formal notation, DIANE+ is more powerful in its formal representational than MAD. In some situations, this augmented representational power becomes crucial, as demonstrated in the Isolde case study (Paris, et al., 2000). The discussion thus far mostly addresses the coverage provided by DIANE+. We now turn briefly to the other axis of our taxonomy. Originally, the notation was developed mostly to be used in the first two phases of the SDLC. We have ourselves used it extensively in these phases. We note in particular our use of the notation during the “Discover and Develop” stage in the design of innovative technology, to identify the place of new technology in a working environment (Paris, et al., 1998a), and, during the “Design” stage of system design, to develop a set of functionality to be consistent across applications, using the “task library” concept, in the UICard Project (UICard Project description, 2001). Its author has since advocated its use during the remaining phases of the design cycle (Paris, et al., 2001). We have illustrated its use during the “Develop and Deploy” phase of the SDLC, by automatically producing from task models written in the notation excerpts of the on-line help to be associated with a system (a major aspect of the Isolde project), thus showing that the notation could help with one of the aims of that phase of the SDLC. As for the other aim of a task model in that phase, we found that the models used within the UICard project indeed helped the software engineers derive generic functions of the systems to be implemented, and helped them structure their code. Our experience shows that DIANE+, like MAD, can be used as a communication tool. We exploited the notation in the UICard project as a tool to convey to software designers the functionalities required. We also performed an experiment to test the usability of the notation with technical writers (Ozkan, et al., 1998a). This experiment tested the usability of Diane+ for communication (can the technical writers understand the models) as well as its usability for modelling (can the technical writers produce DIANE+ models). Finally, we found that we were able to both extend and adapt the notation for our purposes, namely the automatic generation of on-line help, without problems. User Action Notation (UAN) Similarly to MAD, DIANE+ and to Use Cases to some extent, User Action Notation (UAN) (Hix and Hartson, 1993) is based on a hierarchical decomposition of the task. UAN was created to answer the need to formalise the communication between the UI designers and the development team. To this end, UAN concentrates on providing a way to represent the user interface specifications of an interactive system, and more precisely what users will see and how they will interact with the system. UAN was designed to be used during user requirement analysis as well as during user interface design. The notation employed to represent that decomposition is not graphical but expressed with tables, similar to the Essential Use Cases. At its highest levels, and as shown in tables 4 to 7, the notation allows for the representation of task decomposition and the temporal relationships that may exist among sub-tasks (sequence, iteration, repeating choice, concurrence, etc.). In our illustration below sequencing is represented vertically, in the absence of any other symbol, while the “||” symbol refers to the fact that the two sub-tasks can

be executed in parallel. Table 4 describes the sequence of two tasks composing the “Book a flight” high level task. Task: Book a flight (Find the right flight Pay) Table 4: Decomposition of the task “Book a flight” Task: Find the right flight (Enter flight details Choose a flight) Table 5: Decomposition of the task “Work on the file” Task: Enter flight details (Select Dep.&Arr. airports || Select other ) Table 6: Decomposition of the task “Enter flight details” Task: Select Dep.&Arr. airports (Select departure airport Select arrival airport) Table 7: Decomposition of the task “Select Dep.&Arr. airports” At the elementary action level, the notation is based on a 3-column table, where each column represents an aspect of the task to be modelled: in the left column, we find the (temporal) sequence of physical actions to be performed by the end-user to execute the task (using a specific syntax). The middle column describes the feedback from the system on execution of the end-user’s actions. Finally, the right column records how the corresponding system variables change as a result of the end-user’s actions described in the 1st column. In table 8, we illustrate the elementary action level of decomposition with the task “Select departure airport”. To accomplish this task, the end-user must move the mouse onto the pull down menu “Departure airports” (~(Pulldown departure airports)), and then click on the mouse (Mv). As a result of this user action, the system displays the Departure airport list (Airports pulldown appears). Moving the mouse on top of an item in the list (~(dep. airport pulldown item)) triggers the system to highlight that particular item, as shown in the interface feedback column. Then the end-user must stop the cursor on top of the desired airport and releases the mouse (M^). At this point, the system variable is set to the selected departure airport, and the arrival airport list is updated. These are system internal operations. Task: Select departure airport User Actions ~(Pulldown departure airports) Mv ~(dep. airport pulldown item) M^

Interface feedback Airports pulldown appears

Interface state

airport name is highlighted departure airport remains in dep. airport is selected pulldown field and arrival airport list is updated Table 8: Decomposition of the task “Select departure airport” with UAN

This level of description can be seen as very low level, as it represents the sequence of primitive actions that the end-user performs, and how the system reacts. It is, however, a

detailed, systematic and non-ambiguous description of the interface, of how the user is to interact with the system, and of the result of the interactions on the underlying system. It thus links user actions with internal system actions. UAN is closer to specific software specification (for the user interface at least) than MAD or DIANE+ are. It was designed as a tool to communicate the interface requirements to software specialist as opposed to a tool used to communicate with end-users. This requirement makes its communication and modelling usability capacity lower than notations like DIANE+ or MAD for example. The formalism used to describe the interaction makes it less readily understandable to the novice. UAN enables, via its table format, to represent agency, decomposition, temporal relationship and to a certain extend non standard coverage, but it does not provide a formal representation of the optional character of a task. UAN requires some experience before being confident in using the notation, although, as for MAD or DIANE+, because of its semi-formality, the notation is easily extendable to new needs. Functional Flows (FFlows) The use of Functional Flows (FFlows) presented here is drawn from designing web sites. As a general rule, FFlows are developed by HCI experts in collaboration with the other members of the team. Once the high level of the interaction between pages is defined by the Site Map (which shows the organisation of the main pages of a site), FFlows are used to share and kickstart the detail understanding and representation of the specific behaviour of pages and popups. An individual FFlow is a fine-grained representation of the interaction between a welldefined sub-set of pages and pop-ups. We describe briefly in table 9 the various components of a FFlow. They are then illustrated with our example.

Weekly diary (default)

A page

Register

Please register

A pop-up

Create new account

close 'please register ' pop-up

Link to User action System another Flow action Table 9: graphical elements of a FFlow

username entered & valid

Conditional branching

All pages and pop-ups are present in the FFlows, but only some of the user actions and system actions are represented. The user and system actions represented within the FFlow are actions that trigger the loading of another page or pop-up.

Go-fly.com availability & booking page

Select departing airport from pulldown menu

Update arrival airport pull down menu

Select arrival airport from pull down menu

Select all other parameters

Select 'Check availability & book'

Check for errors

Error

Error message

No errors click 'Ok'

close Error popup

Select flight page

etc.

Figure 5: an extract of the FFlow for Booking a Flight As for the elementary action level of UAN, FFlows are designed once the interaction choices have been made. They present the detail of the behaviour of a well-defined subset of pages within a web site. With regards to our taxonomy, the aim of FFlows is definitively within the “Design” and “Develop and Deploy” phases, with their main use during “Development and Deploy”. FFlows are used to define and organise the fine grain of the interaction between the various functionalities provided on the web site. They can also be used while validating and testing the web site under construction, in the same way use cases and scenarios would. These, however, would be used to a lesser extent during validation and testing, because, as textual narratives, they are less formal and inclined to be interpreted in various different ways. Because FFlows specify in detail the behaviour of the pages within a site, they support the communication between all parties involved in the design of a website, from the stakeholders to the developers. The graphical nature of the representation of all pages involved in the site via the FFlow makes it indeed a robust communication tool. Our usage of FFlows is to represent web interaction, and this usage includes a limited number of graphical elements, suited for these interactions. The adaptability of the notation for other applications, outside the representation of web interaction, is unclear. In this environment, the coverage is low as there is no need to represent optionality or decomposition. The KLM and CPM models of the GOMS (Goal, Operator, Method, Selection) family We present below a brief description of two models of the GOMS family. These descriptions are kept to the minimum to help understand our first discussion around the use of the Keystrokes Level Modelling, or KLM, for evaluation (Card, et al., 1983). We also briefly illustrate the CPM-GOMS (John and Kieras, 1994), based on the Model Human Processor. The CPM stands for the fact that this notation models Cognitive, Perceptive, and Motor tasks. At the keystroke level, GOMS is used for predictive evaluation, as a quantitative tool for measuring performance. This is in contrast to the all the notations mentioned previously. These were to be used mostly during the initial stages of the SDLC (as MAD or the use

cases), or to support development (as UAN or the FFlows). GOMS aims at providing models of the expected behaviour of expert users. It provides four levels of abstractions, depending on the designer’s goal: task, functions, arguments and physical actions. At the keystroke level, there are only physical actions. The GOMS basic elements are the Goals, the Operators, the Methods and the Selection rules: • A Goal defines a state to be reached. It is realised through the execution of a set of operator, and is decomposed hierarchically. • An Operator is an elementary action (not decomposed further) within the abstraction level considered. Its execution triggers a change both in the mental model of the end-user and in the system. All operators have an execution time associated with them. These have been inferred from empirical experiments, and it is through them that predictive evaluation is performed: given a sequence of operators, one can predict how long the goal will take. Execution times for the operators at the keystroke level are given in table 10. All operators belonging to the same abstraction level have similar execution time. • A Method describes the process to reach a goal. It represents user know-how and is expressed through decomposition of sub-goals and operators. • A Selection rule is used when more than one method can be used to reach a given goal. It provides a way to select which method should be chosen. Operator Execution time K (Keystroking): on the keyboard, for an expert 0.35 seconds P (Pointing): using the mouse 1.03 + variable H (Homing): movement of the hand when leaving 0.4 seconds the mouse or keyboard D (Drawing) 0.161 + variable M (Mental activity) 1.35 seconds R (Response time): system response time varies Table 10: Keystroke operators and their execution time (John and Kieras, 1994) For example, considering our Flight booking example, for the selection within the pull down list of departure airports, this would be expressed by the following: Move cursor on top of Departure airport pulldown list: Click mouse down: Response time to display pulldown menu: Move cursor on top of desired airport: Release mouse: Table 11: KLM model

M+P K R M+P K

The keystroke level model can be employed to guide the user interface design process, by predicting the time required for a user to perform a task, or by helping in comparing analyses to detect problems in software already designed. Figure 6 shows the representation of our sample task using GOMS-CPM. (We removed any mention of execution time from this diagram.)

System Response Perceptual operator: Visual Cognitive operator

{

Right Hand

Motor operators:

…

System RT

…

See Menu Departure Airport list Determine whichReturn file which Airport

Initiate Mouse Movement Move Mouse to Departure Airport list

Click Mouse Button

… Move mouse to ‘London Stansted’

Click Mouse Button

… …

Left Hand Move eyes to list

Eye Movement

…

Figure 6: GOMS-CPM model Unlike the other GOMS models, GOMS-CPM recognises cognitive and perceptual tasks as operators, and realises that these operators do not need to be performed serially; rather they can be done in parallel as required by the task. Figure 6 shows the operators presented along a time axis, the width of each box representing the time to perform the action. Several distinct processes may be performed in parallel, each contributing to the performance of an individual goal. This GOMS modelling method is often called the ‘Critical Path Method’, because of its ability to show the precise tasks that determine the duration of the task. The critical path is shown in figure 6 through the greyed boxes. Given such a model, GOMS-CPM predicts execution time based upon an analysis of component activities.

Using the taxonomy to compare notations In this report we presented a taxonomy built to help compare and contrast task modelling notations and identify their strengths. This taxonomy provides us with a basis on which to choose a task modelling notation that support a specific set of attributes.

Axis \ Notations

Use Cases

MAD

DIANE+

UAN

1. Goal

Dis&Def Design

Dis&Def Design

Dis&Def Design Dv&Dp

Dis&Def Design Dv&Dp

Ev&Pred High

High

High

High

High

High High Yes Yes

Yes

High Medium No Yes (partially) Yes (variable) Yes (partially) No

High

High

2. Usability for communication 3. Usability for modelling 4. Adaptability 5. Coverage Optionality Agency Decomposition Temporal Non standard 6. Extensibility

Yes (variable) Yes

FFlows

GOMS Dis&Def

Medium

Design Dv&Dp Ev&Pred High

Ev&Pred Medium

High

Low

Medium

Low

High High Yes Yes

Medium Medium No Yes

Low Medium No No

Yes (variable) Yes (partially) Yes

Yes (variable) Yes

(unclear) Low No Yes (partially) No

High

Yes

Yes (partially) Yes

Yes (fixed) Yes (partially) No

High

High

Medium

Table 12: Placing the methodologies in our classification In bold are the SDLC stage for which the notation was designed. The above table shows our assessment of how the methodologies rate on the axes of our taxonomy. We use the same notation as in the previous table. The taxonomy allows to determine explicitly the similarities and differences among these various notations, thus enabling comparisons and supporting decision making as to which is best suited for a specific purpose.

Conclusion In this paper, we have proposed a taxonomy of task modelling notations. This taxonomy helps understanding and comparing the various attributes of different notations in a systematic way. The impact of the taxonomy is two-fold. Firstly, for the practice of HCI, this taxonomy helps system designers and evaluators in choosing a notation suited to their purposes, and in applying task modelling in an appropriate way. Secondly, in terms of HCI research, the taxonomy helps in understanding the global picture of task modelling notations today, in assessing where the need for new notations arises, in order, for example, to cover attributes in the taxonomy which are currently either not addressed or only partly addressed.

Acknowledgements Cécile Paris gratefully acknowledges the support of Office of Naval Research (ONR), grant N00014-96-0465, for its support of the Isolde project, which contributed to the analysis required to investigate the issues presented in this paper, and for its support during the writing of this paper.

References Balbo, S. (1994) Évaluation ergonomique des interfaces utilisateur: un pas vers l'automatisation. PhD thesis. University of Grenoble I, France. Balbo, S. and Lindley, C. (1997) Adaptation of a Task Analysis Methodology to the Design of a decision Support System. in the Proceedings of Interact’97, Sydney, Australia. 355:361. Barthet, M-F. (1988) Logiciels Interactifs et Ergonomie, Modèles et Méthodes de Conception. Editions Dunod Informatique. Bardon, D., Berry, D., Bjerke, C., J. and Roberts D. (2001) Crafting the Compelling User Experience: Using a Methodical Software Engineering Approach to Model Users and Design. Make IT Easy 2001 Conference Tutorial. An IBM corporation online publication available at www-3.ibm.com/ibm/easy/eou_ext.nsf /Publish/1650 (accessed 21/03/2002). Brun, P. and Baudouin-Lafon, M. (1995) A taxonomy and evaluation of formalisms for the specification of interactive systems. In the Proceedings of HCI’95, Huddersfield (UK). Card, S. K., Moran, T. P. and Newell, A. (1983) The Psychology of Human Computer Interaction. Lawrence Erlbaum Associates. Constantine, L. and Lockwood, L. (1999) Software for use: a practical guide to the Models and Methods of User-Centered Design. Addison-Wesley - ACM press. Hix, D. and Hartson, R. (1993) Developing User Interfaces, Ensuring Usability through Product & Process. Wiley. Jacobson, I., Christerson, W., Jonsson, P. and Övergaard, G. (1992) Object-Oriented Software engineering, a use case driven approach. Addison-Wesley. John, B. and Kieras, D. (1994) The GOMS family of analysis techniques: Tools for design and evaluation. Carnegie Mellon University School of Computer Science Technical Report No. CMU-CS-94-181. Kenworthy, E. (2002) The Object Practitioner's Guide. Available at http://www.zoo.co.uk/~z0001039/PracGuides/ (accessed Jan 2002). Modem Media (2002) Company web site: www.modemmedia.com (accessed March 2002) Ozkan N., Paris, C. and Balbo, S. (1998a) Understanding a Task Model: An Experiment. In People and Computer XIII - Proceedings of HCI'98. Sheffield (UK). Springer-Verlag. 123:137. Ozkan, N, Paris, C and Simpson-Young, B. (1998b) Towards an Approach for Novel Design. In the Proceedings of the OzCHI’98 conference, Adelaide, Australia. Paris, C., Ozkan, N. and Bonifacio, F. (1998a) The Design of New Technology for Writing On-Line Help. In People and Computer XIII - Proceedings of HCI'98, Sheffield, UK. 189:205. Paris, C., Ozkan, N. and Bonifacio, F. (1998b) Novel Help for On-Line Help. In Proceedings of ACM SIGDOC'98 (The Sixteen Annual International Conference on Computer Documentation). Quebec City, Canada. 70:79.

Paris, C., Balbo, S. and Ozkan, N. (2000) Novel Uses of Task Models: Two Case Studies. In Cognitive Task Analysis. J.M.C. Schraagen, S.E. Chipman and V. L. Shalin (Eds.), Mahwah, NJ: Lawrence Erlbaum Associates. 261:274. Paris, C., Tarby, J-C. and Vander Linden, K. (2001) A Flexible Environment for Building Task Models. In the Proceedings of HCI 2001. Lille, France. 313:330. Paternò, F. (1999) Model-Based Design and Evaluation of Interactive Applications. Springer Verlag. Rodriguez, F. G. and Scapin, D. L. (1997) Editing MAD* task descriptions for specifying user interfaces, at both semantic and presentation levels. In Proceedings of the Eurographics Workshop (DSV-IS'97): Design, Specification, and Verification of Interactive Systems '97. Granada, Spain. M. D. Harrison, J. C. Torres (Ed). Springer-Verlag/Wien. 193:208. Rosson, M. B. and Carroll, J. M. (2001) Usability Engineering: Scenario-based Development of Human Computer Interaction. Morgan Kaufmann. Rumbaugh, J., Jacobson, I. and Booch, G. (1999) The Unified Modeling Language Reference Manual. Addison-Wesley, Reading, MA. Scapin, D. and Bastien, C. (2001) Analyse des tâches et aide ergonomique à la conception: l'approche MAD*. In Interactions Homme-Machine pour les Systèmes d'Information, Tome 1: Analyse et conception de l'IHM. C. Kolski (ed.). Hermès. Sebillotte, S. (1995) Methodology guide to task analysis with the goal of extracting relevant characteristics for interfaces. Technical report for Esprit project P6593. INRIA, Rocquencourt (France). Tarby, J-C. and Barthet, M-F. (1996) The DIANE+ Method, in the Proceedings of the Second International Workshop on Computer-Aided Design of User Interfaces. Namur (Belgium). Tarby, J-C. and Barthet, M-F. (2001) Analyse et Modélisation des Tâches dans la Conception des Systèmes d'Information : mise en œuvre avec la méthode Diane+. in Analyse et conception de l'IHM, Interaction pour les Systèmes d'Information. Volume 1. Kolski C. (eds). Editions HERMES. Thevenin, D. and Coutaz, J. (1999) Plasticity of User Interfaces: Framework and research agenda, in the Proceedings of the Interact‘99 conference. Sasse and Johnson (eds.). ISO Press, IFIP TC.13. UICard (2002) a CISRA online project description, available at www.research.canon.com.au/uicard/index.html (accessed January 2002). van Welie, M., van der Veer, G. and Eliëns, A. (1998) An Ontology for Task World Models, in the Proceedings of the 5th International Eurographics Workshop on Design Specification and Verification of Interactive Systems DSV-IS98. Abingdon, UK. pp. 57:70 (available online at: http://www.cs.vu.nl/~gerrit/gta/) van Welie, M., van der Veer, G. and Koster, A. (2000) A. Integrated Representations for Task Modelling, in the Proceedings of the Tenth European Conference on Cognitive Ergonomics. pp. 129:138.Linköping, Sweden.

Vanderdonckt, J. and Berquin, P. (1999) Towards a Very Large Model-based Approach for User Interface Development. In Proceedings of 1st Int. Workshop on User Interfaces to Data Intensive Systems UIDIS’99. Paton & Griffiths (éds.). IEEE Computer Society Press, Los Alamitos. pp. 76:85.