Avoiding Inaccuracies in Task Models

Abstract

In the field of user-centered design of interactive systems, task models play a major role, especially in defining requirements, or during the system validation phase. They lean on precise semantics, based on a set of formal operators. In this article, we demonstrate how the addition of new description tools (pre-conditions, objects) introduced ambiguities in model interpretation, and we propose our solutions to solve this problem.

1 Introduction

Task models come from the wider domain of the analysis of users [3]. Initially oriented towards the human factor studies, they were first used in Computer Science to help structure the description of observable human activities, using more or less technical aspects [5]. Gradually, task modelling explored new avenues, and turned to interactive system design with methods such as MAD [8]. Becoming more and more formal, authors developed tools that support the proposed methodologies, resulting in a significant extension of task model usage, as illustrated by the pair CTT/CTTE [7].

The main strength of task modeling in the field of interactive application design stands in the capacity to distinguish the role played by human operators from the role played by the studied system, and to express prescribed tasks that take into account the completeness of an activity by the way of operators that describe the task dynamics.

Meanwhile, the task models were more and more enriched, in response to the addition of much richer elements such as actors of the activity, or the “world objects” manipulated during the activity. Notions initially somewhat formalized, such as the condition for the execution of tasks, were then clarified. The proposals converged.

However, the evolution of task models is also characterized by a lack of general synthesis, which leads to inaccuracies in the interaction between separate notions proposed by different authors. In this article, we focus on one such elements: consistency between the temporal operators and task associated conditions. The latter, formally developed recently in the methods, have not been specifically linked with the dynamic semantics expressed through temporal operators, which can lead to several inaccuracies.

As Caffiau et al. showed [2], only the tools developed to support the models can accurately solve the problem of model interpretation. We therefore restricted our study to only maintained and widely available tools only, which illustrate by example the semantic models, namely the tools including a simulator.

First, we study, illustrated by examples, basic concepts manipulated by the task models. Then, we present some limitations to the interpretation of the task models currently offered through a case study. Finally, we offer some clarification of the semantics in order to lead to unambiguous semantics, before concluding with some perspectives.

2 Task Model Key Concepts

Despite their diversity (tens of task models have been proposed within the past thirty years), the majority of developed task models offer similar principles, based on a breakdown of tasks inspired by hierarchical planning [9]. This is the case of historical models such as [3, 8], but also of all those currently supported by a maintained tool (CTT [7], K-MAD [1], eCOM, HAMSTERS [6]). Beyond this structural semantics, they have a dynamic semantics, informally described in the first models, then formalized through a set of attributes attached to tasks and temporal operators governing relations between tasks. In the remainder of this article, we will focus on three formalisms, CTT, K-MAD and HAMSTERS, which include a powerful simulation tool.

2.1 Common Features in Most Models

Over the years, especially because of the increasingly important use of task models in the field of interactive system design, the different models have incorporated identical or quite similar notions.

To illustrate these concepts, we use an example, which represents the activity of exchanging an amount of money between two currencies as follows: the user determines the amount he/she wishes to convert, as well as the two concerned currencies, without prejudice to the order in which he/she performs these operations, then the system calculates the conversion rate.

Categorizing Tasks.

In order to clearly identify the responsibilities between human and system tasks, a categorization was proposed, distinguishing the tasks performed by humans without any interaction with the system (human tasks), those conducted by the system without human intervention (system tasks) and those involving both the user and the system (interactive tasks). In our example, the cognitive task that determines the amount of money to convert and both currencies is human task, while the two entering data tasks (amount and choice of currencies) are interactive tasks, and the calculation itself is a system task. Typically, a specific category of tasks (abstract tasks) is dedicated to the nodes of the task tree; it breaks down into tasks of different nature, here the main task “Converting”.

Some formalisms such as HAMSTERS offer much finer categories, differentiating interactive input or output tasks, cognitive human tasks, etc (Table 1).

Table 1. Examples of tasks in different notations

Temporal Dynamics.

Historically, the concept of planning [3, 8] was associated to task/sub-task decomposition, giving task models the ability to express some kind of dynamics. The definition of the first tools that interpret and render this dynamics (CTTE, MAD*/Alacie [4]) quickly converged on the inclusion of a limited number of operators to determine the dynamic behavior of tasks between them. Four main operators relying on the LOTOS operators [11] have been defined, which allowed the specification of subtasks as sequential, parallel or unordered, or a choice between subtasks.

In the example, the conversion task of an amount of money between two currencies is described, according to the CTT formalism on Fig. 1, and K-MAD on Fig. 2. The behavior of these two models is exactly the same, the node tasks of the tree (Converter, Choose Currency, Prepare) being only used for structuring the model. Operators play a major role in the operational semantics of task models. Based on these operators, simulators offer an interactive simulation of task models. The user is able to dynamically explore the model, each elementary task is proposed according to the semantics of the operators. So when two tasks are linked in sequence, only the first is available to the user, and the second one becomes available only when the first one is “executed”. Conversely, when several tasks are governed by a “no order” operator, they are all available at the same time: the user is supposed to choose which one to do first.

Fig. 1.

A simple task with CTT

Fig. 2.

A simple task with K-MAD

In CTT, operators are binary, and located between two sub-tasks of a same task. The “Determine” task that allows the user to provide the parameters of its conversion (amount, and starting and destination currencies conversion) is the first to be performed, because of the sequence operator (>>operator for “Activation” in CTT). Then the operator composition allows three interactive tasks (“Enter…”) capture the different parameters of the conversion to be performed in any order (operator | = | for “OrderIndependance” in CTT). The task “Calculate”, which calculates and displays the result, is a system task, and is connected through a sequence operator. In the K-MAD formalism, temporal operators are linked to the task decomposition, and apply to all subtasks of one super task. Written constraints are stronger, requiring the creation of intermediate tasks like “Prepare” where with CTT, the task “Choose Currency” is not mandatory. However, the bracketing is made implicit in K-MAD, while in CTT, operator precedence solves ambiguities. HAMSTER has meanwhile proposed the “expression tree” solution that avoids intermediate tasks for the only purpose of structuring operators.

The dynamic behavior can be enriched as attributes with unary operators, which apply individually to the tasks. The first of them is the optionality operator; it establishes that, during the simulation, optional subtasks can be ignored by the human who performs the task. Thus, the optional tasks cannot belong to the system task category.

The Iteration Case.

The different models all offer an iteration operator for describing a task that can/should happen repeatedly. Conforming to the strict hierarchical organization, this operator is a task attribute. If the concept of iteration is present in all models, how to express the condition of iterations (or iteration stop) differs greatly between models. While the first task model formalisms expressed iteration by the description of the task schedule leaving the whole of the human initiative (Johnson, MAD), the authors proposed two different ways to control iteration.

In CTT and HAMSTERS, the iteration stop is delegated to an external task, which role is to interrupt the current iteration. In Fig. 3, Task_2 is iterative (indicated by the asterisk next to the name of the task), and is divided into three sub-tasks that run in sequence. After Task_6, Task_4 becomes available again. The only way to stop the iteration consists in choosing Task_3, which is available at any time during the iteration thanks to the deactivation operator ([>), which aborts the task that precedes it (Task_2).

Fig. 3.

Iteration with CTT

In K-MAD, where there is no disabling operator, the chosen option is an intrinsic condition that control the iteration, identical to a “while statement” in programming languages. This sets the task condition within the iterative task itself. For example, for a task that must take place a fixed number of times, it is possible to express the condition as [3]. However, the expression of more complex terms requires having objects and expressions.

Objects and Expressions.

Since the early works on task models, the word “condition” was always used. However it was not formalized to a great extent in the tools that support the notations, as demonstrated in [2]. Recently, the simulators have become capable of taking into account the actual values of objects, thus conditioning the execution of tasks to the value of objects. K-MADe was the first widely accessible tools offering the ability to set pre-calculable conditions used by the simulator to allow or deny access to a task. CTTE offers the ability to set pre-conditions and post-conditions since version 2.5, released in 2011. However, K-MAD is the only notation proposing a “WHILE” construct. K-MADe and HAMSTERS propose a concept of edge effect (Assignment in HAMSTERS) to describe an operation performed on objects by the task. CTTE does not offer this feature, and the user must change the object values by hand to enable compliance with the conditions. However, CTTE is the only tool to manage the concept of post-condition, which corresponds to assertions on the value of objects at the end of tasks.

Objects can be independent or dependent from tasks. While K-MAD and HAMSTERS define them as independent from the tasks, CTT considers them as an integral part of the tasks, which forced its authors to add an operator to exchange objects between tasks.

If the way to express conditions changes from one formalism to another, treatment of pre-conditions by the simulator is universal: which the precondition is false, the task turns unavailable to the user, which can result in blocking the task model (K-MADe) or in its early termination (CTTE).

2.2 Task Model Limits

The primary objective of task models is to describe precisely a prescribed or observed activity. As we mentioned in the introduction, as part of the design of interactive applications, the clear separation of the roles or users from those played by the system is a key item. Furthermore, the precise semantics of notations is intended to guarantee a unique interpretation of the model. If this target is met by categorizing tasks, it is not the same as regards to the dynamic semantic models. The multiplicity of mechanisms can lead to inconsistencies in the model behavior, which prevents the building of precise and unambiguous descriptions.

In this section, we will describe, with the support of examples, the concrete problems one can meet when designing task models.

Not so Accurate Semantics.

While authors of task models aim principally to avoid ambiguity, it is clear that firstly multiple mechanisms may lead to inconsistencies, and secondly gaps or unsaid things in the description of models can generate different interpretations of specific situations.

The first lack of precision concerns the notion of optional task. Is it a choice made by the system or only a choice given to the user? The second concerns the vagueness of the semantics of errors in task models: does it mean that the model is “stuck” running, or does it mean that the model is false? In general, the articles describing the task models do not focus on these issues, and only the tools can give an echo of the proposed dynamic behavior.

Case Study.

To illustrate our study, consider the following example: model the task of keeping the score sheet of a volleyball match. The volleyball rules determine that a match consists of a maximum of five sets, the team that wins three of them wins the game. One way of describing the activity is to say that one must play three sets, then a fourth and a fifth if necessary. Both sets are optional, depending on system status (here, the current set score).

The use of CTT formalism¹ (Fig. 4) requires to manage the end of repetition as a creation of a task that will disable it. By the rules of the formalism, this task cannot be optional, hence the creation of the abstract task “Finish match.” To achieve this task, sets 4 and 5 (if necessary) should be played, and then the score sheet needs to be completed. These tasks are optional (as indicated by brackets around the name of the task), but not left to the user’s choice: they must be based on the score result.

Figure 5 shows the same activity modeled with K-MAD. The ITER and OPT bold symbols respectively denote the existence of an iteration on the task 2 (N 2) “Mark normal set” and optional for tasks 3 and 3.2.

Fig. 4.

“Keep the score sheet of a volleyball match” modeled with CTT

Figure 6 shows the same activity modeled with HAMSTERS. The iteration and optional symbols are noticed to the left and right of the assigned task.

Fig. 5.

“Keep the score sheet of a volleyball match” modeled with K-MAD

The difference in model decomposition is explained by a strict rule of CTT formalism: to get out of a repetitive task, the only way is to have a following mandatory task with a disabling operator. This prohibits the shape used in the K-MAD model, where the task following the repetition is optional (Fig. 5).

Fig. 6.

“Keep the score sheet of a volleyball match” modeled with HAMSTERS

Limits of Optional Tasks.

None of the three solutions is satisfactory from the point of view of volleyball rules. When interpreting the dynamic semantics of task models, we find that nothing prevents the user to “play” four or five sets with the same winner team.

Using Pre-conditions.

From the earliest works on task models, conditionality of tasks was highlighted. The concept of pre-condition, which allows conditioning the execution of a task to a condition expressed as a Boolean, has been proposed. According to his/her scenario choice, the task model user is able to guide the simulation of the model following his/her own perception of conditions. Thus, in our example, terms like “If no team has scored 3 sets” would correspond to a good pre-condition for the game tasks of the 4^th and 5^th sets. However, this condition is not based on any concrete evidence of the model, and cannot be formally exploited by simulators. In [2], the authors demonstrate the interest in the use of formal preconditions using computable expressions in the design of interactive systems based on task modeling. In fact, the three studied tools currently include computable expressions, based on more or less complex objects.

K-MADe manages digital objects, boolean or text that can be used to define pre-conditions attached to tasks or iteration terms (building “while” expressions). It also manages collections to handle objects in lists, stacks, tables, etc. CTTE manages objects of various types, which can be used for automatic generation of interfaces, but only offers the basic expression operators (equality, inequality, lower, upper).

In our case, the three tools can enrich the model description using calculable pre-conditions. It is possible to define such a condition in the form SetsA < 3 AND SetsB < 3 for both tasks matching the 4^th and 5^th sets, which will prohibit the realization of these tasks if the condition is not met.

One can notice that preconditions are completely invisible in the CTT model, while K-MAD and HAMSTERS give a feedback on their existence.

What Behavior?

One might expect to have the same behavior for these models. It is not the case, as using the simulators can show. The way the simulators work is quite similar. At each step of the simulation, a framework offers the user a set of available/enabled tasks. Double-clicking on one of these tasks can “run” it and the simulator then recalculates all available tasks (Task Enabled Set) based on the operators of the model. In the case of CTTE simulator, actions for which preconditions are not checked do not appear among the available tasks. However, in the case of K-MADe, they are available, but not executable (i.e. a double-click on such a task does not result in change of state, a message informs that the pre-conditions is false).

Figure 7 shows the enabled tasks at the end of the repetition, in a situation where no team has won 3 sets (the game is not finished, you have to play the 4^th set).

Fig. 7.

Enabled tasks in CTTe (left) and K-MADe (right)

If the situation is properly managed in CTT thanks to taslk preconditions, K-MADe offers an illogical action that pass the action “Finish the game.” This is due to the lack of consideration of the conditions in the node tasks.

Note also that the failure to carry out an optional task is translated differently in the simulators: in the case of K-MADe, you must explicitly “Pass” the action, while for CTTE, simply trigger the next task. Therefore, an optional task cannot be the last task of the model in CTT, because in this case one cannot complete the model without running the optional task.

In both cases, what can we observe? The only graphical representation of task models does not allows to predict the behavior of the model. Indeed, the only parameter that appears clearly on the graph is the optional nature of the task. Although, in some cases, the user must decide whether the optional task is done or not, in other cases, like here, not achieving the 4^th and 5^th sets it is not a user’s choice, but is determined by the system status.

The combination of pre-conditions with the optional unary operator seems to solve the problem: in fact, adding a pre-condition on the system task “Calculate result”, we can make it inaccessible until the conditions are not met. This solution is however not satisfactory for several reasons.

The Ambiguous Optional Attribute.

What is the actual meaning of the optionality of tasks? Does it represent a decision to be made by the human operator who may or may not decide to do this task at this moment, or is it related to the system status, that is to say a situation in which the task should be performed if a condition is true, and omitted if not? Here, in the case of volleyball, the fourth set cannot be omitted if none of the teams has won more than 2 sets. The only way to prevent the user from validating the optional nature of the task is to put a precondition on the next task/s, to inactivate it/them. Besides the fact that this has no special meaning, it imposes a writing discipline that greatly complicates task model building and validation for modellers.

How do task models handle task optionality? In CTT, any task may be optional. During the simulation, if no pre-conditions are present, the task can be executed or ignored. In the absence of precondition definition, one can consider this choice as legal, because the task model user is supposed to master every aspect of the played scenario. However, if the preconditions are used, this behavior is no longer acceptable. Indeed, this would allow the user to override the pre-condition of a system task. In the case of K-MAD, a system task cannot be defined as optional, reducing the sense of optionality to a decision of the user of the model. But in this case, it is never possible to not execute…

The Failure Semantics.

The third important point concerns the semantics of model failure. Using the only semantics of operators necessarily leads to a consistent state of the model, with one or more tasks to run (the model is still active) or not (the model is completed). The introduction of pre-conditions can lead to more complex situations. So what about a model where all possible tasks contain only tasks which pre-condition are false? CTTE ignore this case, considering that the list is empty, so that the model is completed. In contrast, K-MADe considers that the model is “blocked”: it does not end in a normal situation.

3 Towards a More Accurate Semantics

We believe that the existence of “holes” in the task model semantics prevents task model authors to reach their main objective. An unambiguous semantics seems an essential prerequisite to any good modelling.

Some authors have noted a lack in the expressive possibilities of task models. This is the case of [10], which proposes to add some operators to CTT. Two of them are linked to our problem: the unary “Stop” operator and a modified choice operator. The “Stop” operator consists of an attribute that can manually interrupt the current task model during simulation. It allows taking into account one error that occurs during a task. The example given by the authors regard such a login task, where the user can decide to abort his task (user selectable, called deterministic), and where the system may fail the task if entering a wrong password (system selection, qualified non-deterministic).

Our proposal has two points: the definition of the concept of failure of the current activity, and the definition of a new attribute, in addition to the “Optional” attribute, to define the “Blocking” status of a task.

3.1 Current Task Failure

A task model describes a human activity. Ideally, this activity is always legal and valid. However, for the purpose of specifying interactive system (or parts of an interactive system), what does a deadlock mean, where no task is attainable because the conditions for their running are not met? The Sinnig’s “Stop” operator [10] is intended to allow the incorporation of early termination of a task tree. It is an interruption provided explicitly by the task model developer. But what about the case where the model has a more attainable solution determined by the set of expressions that govern the preconditions tasks? In CTTE, the answer given is to consider that the model simulation is finished “normally”. We believe that this solution is not suitable for using task models to validate interactive systems. We therefore propose the following rule: as one task remains present in the list of available tasks, the activity is completed. If a task cannot be activated, then the activity is in error. This notion, which does not currently exist in task models, allows us to consider the concept of validity or invalidity of scenarios.

3.2 Redefining Optionality

The examples discussed above demonstrate the lack of precision concerning the definition of the optional nature of the tasks in task models. Is this optionality only due to actions of the human actor in activity, should it be related to the system status, or the intrinsic nature of the task?

In our example, the 4^th and 5th volleyball sets are not mandatory but depend on the system status. In a state, they are required, in another state, they are prohibited. The Sinnig’s proposition, which consider the choice operator as either a user choice (deterministic as proposed) or a system choice depending on the system status (non deterministic) cannot therefore take into account all cases. Thus, it is not possible to define a task whose pre-condition determines the optional nature, but in the end, is also optional from the perspective of the user. Our proposal is to distinguish between two notions associated with the unsystematic character of a task.

• The optional nature of a task (attribute “Optional”) is only attached to the choice of the human actor of the task model, which can freely choose to achieve the task or not. Therefore, a system task cannot be optional.

• We propose to define a new attribute, called “blocking.” This attribute defines the behavior associated with the possible pre-condition expressed on tasks. So if “blocking” is true, the task cannot be omitted by the user. It shall be enforced if the pre-condition is true. However, if the pre-condition is false, the task will block the full model, which will then be in check. By default, a task is still “blocking” intrinsically, without precondition (which is always true to have a pre-condition) This task must be performed. Only the positioning of this task in a building with an ‘alternative’ operator unblocks the model.

  The advantage of this solution lies in the possibility of combining the two operators together. A blocking and optional task corresponds to the case where the user can override the completion of a task whatsoever.

4 Conclusion

In this article, we introduced and illustrated some inaccuracies of task models, which can be explained by the addition of new concepts in the originally defined formalism. We offer a solution to solve ambiguities generated by these inaccuracies.

Another field of study concerns the concept of interruption, and its link with the dynamic models as currently defined.