Re: call for comments on publishing task models spec

Dear colleagues,

Please find few comments and/or suggestions below:

0- General comments
a) the document is ambiguous. It has to make clear whether the task  
metamodel that is described (section 3.4, typically Figure 1) is pure  
CTT or the W3C Task metamodel. We should name it to remove this  
ambiguity.

b) everywhere, change "application" with "interactive system"

1- Abstract
Task models are useful when designing, developing, executing and  
evaluating interactive systems. They describe the logical activities  
that have to be carried out in order to reach the user’s goals. This  
document covers the specification of Task Models, with a meta-model  
expressed in UML, and an XML Schema that can be used as the basis for  
interchange of Task Models between different user interface design  
time and run time tools.

2- Introduction
a) Task models provide a goal oriented description of a user interface  
suitable for reviewing temporal relationships between tasks, and their  
decomposition into subtasks, but avoiding the need for the level of  
detail required for a full description of the user interface. This  
makes it easier to talk through a user interface design without  
getting distracted by the details.
Each task describes an activity that has to be carried out to fulfil  
the user's goals. Tasks can be represented at various abstraction  
levels. When designers only want to specify requirements on how  
activities should be carried out, they just need consider the main  
high-level tasks. On the other hand, when designers aim to provide  
more precise design indications, then the activities are represented  
at a finer granularity, for example, covering the temporal sequence of  
tasks to be carried out by the user or application[TO BE SUPPRESSED: ,  
as well as any preconditions for each task]

=>

Task models provide a goal oriented description of a user interface  
suitable for reviewing temporal relationships between tasks, and their  
decomposition into subtasks, but avoiding the need for the level of  
detail required for a full description of the user interface. This  
makes it easier to talk through a user interface design without  
getting distracted by the details.
Each task describes an activity that has to be carried out to fulfil  
the user's goals. Tasks can be represented at various abstraction  
levels. When designers only want to specify requirements on how  
activities should be carried out, they just need consider the main  
high-level tasks. On the other hand, when designers aim to provide  
more precise design indications, then the activities are represented  
at a finer granularity, for example, covering the temporal sequence of  
tasks to be carried out by the user or the sytem.


b) The purpose of this document is to define a standard for  
interchange of task models. The initial proposal is based on the  
widely adopted ConcurTaskTrees (CTT) notation. [TO BE SUPPRESSED: ,  
Further variations to this notation may be added in the future, if  
useful.]

=>

The purpose of this document is to define a standard for interchange  
of task models. The initial proposal is based on the widely adopted  
ConcurTaskTrees (CTT) notation.



2- Specific requirements for task meta-model

In this section there are some requirements that have been  
specifically identified for task models.

Req1: Separation of static aspects from dynamic aspects
Req2: Separation of the hierarchical structure from other aspects
Req3: Possibility of relating task performance to the context of use  
(even if modelling the context of use is not in the scope of this  
document)
Req4: Provide an initial taxonomy of task types (optional usage)
a) The relevence of the requirements must be justified

b) Are these requirements satisfied by the task M2 described in 3.4?

c) To which extent are these requierements specific to Task M2 (see  
for instance Req1)?


3- Meta-Model

a) CTT is a visual notation for describing task models.

=> To be removed as the metamodel under study is the W3C one.



b)The tasks represented through such a notation have a hierarchical  
structure and use a set of temporal operators to describe the  
relations between tasks.

=> The tasks have a hierarchical structure and use the CTT set of  
temporal operators to describe the relations between them.

The operators include both N-ary operators and 1-ary operators. They  
are described in the following list:

Interleaving (T1 ||| T2 ||| … TN): The connected tasks can be  
performed concurrently, without any specific constraint.
Order independence (T1|=|T2 |=| … TN): the tasks can be performed in  
any order;
Synchronisation (T1|[]|T2 |[]| … TN): The tasks are synchronised each  
other TO BE EXPLAINED
Parallelism (T1||T2 || … TN): The tasks are performed in true  
paralllelism.
Choice (T1[]T2[] … TN): in this case it is possible to choose one  
task from a set of tasks and, once the choice has been made, the  
chosen task can be performed
Disabling (T1[>T2[> … TN): the left-hand task is deactivated once the  
right-hand task has started; Because the tasks have to  be ordered  
(left, right), the keyword Ordered needs to be added to the SubTask  
association in the UML diagram (Figure 1)
Suspend-Resume (T1 |> T2|> … TN): The right-hand task interrupts the  
left-hand task one. When it is finished, the left-hand task can be  
reactivated from the state it was before the interruption. Same comment
Enabling (T1>>T2>> … TN) (with or without information passing): in  
the first case the left-hand task enables the right-hand task when it  
completes. In the second case the same occurs, but information is  
passed from the left-hand task task to the right-hand task;Same comment
Iteration (T*): the task is performed iteratively: when it terminates,  
its execution is started again from the beginning.
Optional ([T]): the task is optionally performed.
c) Table 1 does not cover all of the temporal operators cited abibe

d) UsiXML needs to be included in Table1.


e) The text below has to be generalized from CTT to W3C tak metamodel:

"Figure 1 below represents CTT concepts as a UML class diagram. The  
CTT operators are all N-ary except iteration and optionality, which  
are both unary. The N-ary operator relationship is associated to 2..N  
subtasks to model that N-ary operators are associated to the  
decomposition of a task into its subtasks.

It is also worth pointing out that CTT operators have different  
priorities. For N-ary operators the priority associated to each  
operator is expressed by the order in which it appears in the UML  
class diagram in Figure 1 (e.g. the choice is the operator which has  
the highest priority).

Another key concept of the CTT notation is task allocation: how each  
task is to be carried out is indicated by the related category and is  
explicitly represented using icons. There are four possibilities"

f) in sections 3.1 and 3.2, "application task" should be renamed as  
"system task" (to be consistent with Figure 1)

g) In section 3.2, the tasks types is a mix of nouns and verbs. To be  
made homoegeneous. Visualize should be generalized to Render/Rendering.

h) In section 3.3

. replace "platform" with "context of use (user, platform,  
environment)".

. "Modelling all the possible contexts of use is out of the scope of  
this document." -> Modelling the context of use is out of the scope of  
this document.

. "reading" (implies graphics) -> "consulting"

i) In section 3.4, "Figure 1 shows the class diagram representing the  
ConcurTaskTrees meta-model."-> Figure 1 shows the class diagram  
representing the W3C task meta-model.

j) UML class digram:

- Nary-operator should include only one type attribute whose value  
could be "choice" OR "interleaving" OR etc. As currently expressed,  
the Nary operator can be BOTH choice AND interleaving AND etc.

- Task subclasses: the predef_type should belong to the Task abstract  
class so that to make it possible to define types of abstraction  
tasks. Types enumerations should also be provided

- Task decomposition: 2..* -> + ordered + 0..* . Otherwise the tree  
has no leaf nodes.

- Task: In order to increase the exprressive power of the metamodel  
and to better cover UI plasticity, we suggest to move Frequency and  
Context_of_Use as attributes of 1-aryOperator, and to change the  
cardinality from 0..1 to 0..*. By doing so, it is possible to specify  
that a task is frequent on PC, but not on PDA. Similarly, we can  
express that it is optional on PDA, and not on PC.

- ext-type could perhaps be added as an attribute for 1-aryOperator  
and N-aryOperator.

- As discussed previously, the notion of Actor in charge of executing  
the task should be modeled as an attribute of the 1-ary Operator so  
that to easily support the dynamic migration of tasks execution  
between human and system.

- The Condition part (ConditionGroup, BinaryOperator,  
ConditionLitteral) is not clear (and is not described in the text).  
Would it be possible to clarify the nature of the BinaryOperator (type  
attribute missing)? It is also unclear whether ConditionLitteral are  
elementary.


We are pleased to observe that our suggestions made in Pisa have been  
adopted in the UML class diagram. Thank you for this.
However, we believe that it would be more appropriate to list all of  
the active contributors as co-authors as opposed to be just  
acknowledged.

All the best

Joelle and Gaelle



Le 16 juil. 12 à 20:07, Dave Raggett a écrit :

> This is a call for comments on publishing the following document as a
> First Public Working Draft:
>
>  http://www.w3.org/2011/mbui/drafts/task-models/
>
> My aim is to ask for a formal resolution in this week's MBUI telecon  
> to
> publish the document.
>
> p.s. this was derived from the Google Doc, although it took quite a  
> bit
> of work!
> -- 
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>

-------------------------------------------------------------------------------------------------------------------
Gaelle CALVARY
Professeur en Informatique -  Grenoble INP
Directeur adjoint du Laboratoire d'Informatique de Grenoble (LIG)
41 rue des mathématiques, BP 53, 38041 Grenoble Cedex 9, France
TeŽl : (+33) (0)4 76 51 48 54  -  Fax : (+33) (0)4 76 63 56 86 -  http://iihm.imag.fr/calvar 
y
-------------------------------------------------------------------------------------------------------------------