The structure of our task model is based on the ConcurTaskTrees (CTT) notation. As we discussed, CTT is a descriptive notation suitable for defin- ing task model specifications for interactive applications[49]. Due to the well-defined hierarchical structure and expressive temporal constructors, this notation provides means to define and analyse task models. Using this notation we define a task model as a tree with nodes as tasks that can be performed by either the user or the system. Using the tree structure, each task can be divided into smaller sets of subtasks until the task cannot be decomposed any further. We call these non-decomposable tasksinterac- tion tasks, as these tree leaves describe the actual interaction with the user interface, e.g., select an item or give an input. Branch nodes are used to create the necessary abstraction to define separated branches for specific tasks. We call these branch nodesabstraction tasks. Temporal constructors define the execution order. We define the set of temporal relationships in Table 4.1.
4.3.1
Formal description
The structural task model is structured as an recursive tree with a single distinguishable root node as the top node with the direction of the vertices going downwards. Each task can contain an ordered list of subtasks as children. Temporal constructors are used to define the possible execution paths between two subtasks at the same level. Tasks can only have a tem- poral constructor with the previous or next task in the list. The operational semantics of these constructors are defined in Table 4.1. The amount of subtasks of a task is not bound to any limit.
Name Symbol Example Meaning
SequenceEnabling >> t1>>t2 t1 has to be finished before the user can start t2.
Choice [] t1 [] t2 The user chooses explicitly between t1 and t2. The user can’t execute both. Interleaving ||| t1|||t2 The user can start both tasks at the
same time, or switch between tasks when a task is not finished yet.
OrderIndependence |=| t1| − |t2 The user chooses explicitly between t1 and t2 and should execute both. The first task should be finished before starting with the next task.
SuspendResume |> t1|>t2 t2 can cause t1 to suspend. When t2 finishes it can reinstate t1. For exam- ple, in this context t2 could be render- ing an image such that the input fields in t1 can’t be edited.
Disabling [> t1 [>t2 t2 can cause t1 to disable. When t2 fin- ishes, t1 can’t be reinstated.
Table 4.1: Temporal constructors with their symbols and meaning as de- fined by CTT [49] t0 t1 t2 t4 t5 t3 >> >> [] (a) t0 t1 >> t4 [] t5 >> t3 (b)
4.3.2
Operational Semantics
The CTT notation allows one to define workflows of the task model suc- cinctly. However, defining the temporal constructors that should define the order of tasks is not sufficient to obtain the supported workflows in all cases. For example, if we look at Figure 4.2b, it can be unclear which workflows are supported. Therefore, we need to define a solution for this problem. A typical solution would be to define precedence and associa- tivity conventions among operators to resolve ambiguity [57]. However, we would argue that the hierarchical structure gives the user enough pos- sibilities to define such a priority among operators by defining dedicated subtrees. In addition, this would increase the complexity of the task model and that is what we want to avoid. The simplest approach would be to de- fine no precedence and left associativity among operators. In that case, the possible execution traces of the task model can be expressed in the follow- ing formula in Listing 5. The original approach of CTT defines a priority amongst operators, as defined in Listing 6, which results in a different for- mula, as listed in Listing 7.
t0 ⇐⇒t1>>(t4[](t5>>t3))
t0 ⇐⇒t1∨(t4∧(t5∨t3))
Listing 5: Formula to evaluate if t0 is finished when operators are left- associative without precedence
Choice [ ] Interleaving ||| Disabling [> SuspendResume |> OrderIndependence |=| SequenceEnablingIn f o [ ]>> SequenceEnabling >>
Listing 6: Precedence amongst operators according to the CTT notation
t0 ⇐⇒t1>>(t4[]t5)>>t3
t0 ⇐⇒t1∧(t4∨t5)∧t3
Listing 7: Formula to evaluate if t0 is finished when operators are left- associative with precedence as defined in Listing 6
Both solutions are examined, and both solutions should resolve ambiguity. Further research is needed to verify if our concerns about increased com- plexity are legitimate. A different solution is to prohibit the use of different temporal constructors on the same level. For this solution we would re- quire clear rules to define what combination of constructors are allowed. This solution however, would lower the expressiveness of the language, and the modeller is required to understand and apply these rules.
For the rest of this research we choose the simplest approach of defining no precedence and left-associativity among operators. When the supported workflows of the task model are not clear from its visual presentation, as in Figure 4.2b, the user can examine the generated execution traces to get the necessary feedback. In Appendix B, we defined a procedure to obtain these execution traces.