Identification Criteria in Task Modeling

1 HCIS’2008 – Milan, September 8-9th, 2008, during IFIP World Congress 2008

Identification Criteria in Task Modeling

Josefina Guerrero García, Jean Vanderdonckt, and Christophe Lemaigre

Université catholique de Louvain (UCL)Louvain School of Management (LSM)

Information Systems Unit (ISYS)Place des Doyens, 1 – B-1348 Louvain-la-Neuve (Belgium)

http://www.isys.ucl.ac.be/


Outline

• Introduction and motivations

• Toward methodological guidance for task modeling– Model– Task life cycle– Identification criteria

• Case study

• Conclusion and future work


Introduction and motivations

• A task is an activity to be performed in order to reach a goal.

• A task model is supposed to capture most elements describing how a task is carried out by a particular user in a given context of use or in a given scenario.

• Task modeling has become today a widely recognized activity in the User Interface (UI) development life cycle.



• Despite the recent advances, task modeling still remains a challenging problem:– There exists a significant gap on the means to be used to

obtain a task model .– When some guidance is provided, it mainly consists of

syntactical rules which are completely independent of the domain of human activity.

– This often results in many variations in the task model obtained in the end: different people may produce different, possibly inconsistent, task models for the same design problem because they do not share the same perception or rules.

– People experience some trouble in identifying the points where to start the task modeling and where to stop it.



– People may diverge on their interpretation of what needs to be captured in a task model and what not, in particular what makes a task and what does not make a task?

– This problem is even more acute when task modeling is conducted in the context of a larger design problem such as workflow modeling.

• We propose a set of criteria in order to identify tasks during task modeling in an unambiguous way that results into a task model exhibiting desired properties of quality such as completeness, consistency.

• In addition, starting and stopping criteria provide designers with guidance on when and how to start and finish the task modeling.


Underlying Model

TaskTask

Task ResourceTask Resource

User StereotypeUser Stereotype

MaterialMaterial

ImmaterialImmaterial

ProcessProcess

WorkflowWorkflow

1..*

0..1

1..*

1..*

1..*

ContextContext

DomainDomain

PlatformPlatform

EnvironmentEnvironment

Abstract UIAbstract UI

Concrete UIConcrete UI

Final UIFinal UI

0..*

0..*

0..*

1..*

0..n

Task & domain

AUI level

CUI level

FUI level


Expanded task life cycle

Taskcreated

Taskoffered

Taskallocated

Taskdelegated

Taskstarted

Tasksuspended

Taskcancelled

Taskfailed

Taskcompleted

Taskfinished

define

offerstart

start

startallocate

delegatereturn

cancel fail

suspendresume

run, redo

undo, repeat

finish

reviewTask

created

Taskoffered

Taskallocated

Taskdelegated

Taskstarted

Tasksuspended

Taskcancelled

Taskfailed

Taskcompleted

Taskfinished

define

offerstart

start

startallocate

delegatereturn

cancel fail

suspendresume

run, redo

undo, repeat

finish

review


Identification criteria

• Since a task is defined as an operation executed while four dimensions remain constant (i.e., time, space, resources, information), any variation of any of these four dimensions, taken alone or combined, thus generate a potential identification of a new task in the task modeling activity.

– Change of space (or change of location): when the scenario indicates a change of location of the operations, a change of task may occur.

– Change of resource: when the scenario suggests that new or different resources are exploited, a change of task may occur.

• Change of resource of type “User stereotype”

• Change of resource of type “material” • Change of resource of type “immaterial”



– Change of time: when the scenario indicates a different time period in which the task is performed, a change of task may occur.

• Existence of an interruption • Existence of a waiting point : Waiting point of type “decision”

or “accumulation” • Permanence of execution unit • Periodicity of execution

– Change of nature: when the scenario represents a change of category, a change of task may occur. A task may have any of the following nature: manual, automated, interactive or mechanical. Any change of this nature may indicate a change of task.



• Some stopping criteria based on the task life cycle are:

– For horizontal stopping: when the task is finished, or the task is canceled or the task failed.

– For vertical stopping: when a task can be performed in a simple and well-determined way (i.e. the task cannot be decomposed in sub-tasks), when the task is executed by a software system and we do not intend to replace this system with anything else.



Time Space (location)

Resource Type

Workflow

Series of time periods

Different locations; same organization

Same or different groups of resources

-

Process Series of time periods

Different locations

Within groups, group as a whole, or among groups

Primary (production), secondary (support), or tertiary (managerial)

Task Same time period

Same location

One or two types of resources

User, interactive, system, abstract, or machine task


Case study

• To process claims that result from car accidents, the company uses the following procedure:

– Every claim is registered by a desk clerk. He introduces the customer’s full name, policy number, and the problem’s details in the insurance company system.

– After the registration, an employee checks the insurance’s information as the status, the insurance’s coverage, and the damage history.

– Also, he phones to the garage to get the cost of the damages.


Case study

– After executing these tasks a decision is made by the manager, with two possible outcomes, positive or negative.

– If the decision is positive, then the insurance company will pay. An accountant handles the payment.

– The secretary of the insurance company sends a letter to the customer. Also, a letter will be sent to the customer when the decision is negative explaining the causes of the rejection.


Case study


Task

Process

Workflow


Conclusion

• We have introduced a set of precise criteria that can be used in order to identify a task in a textual scenario and to distinguish a task from other concepts like process and workflow.

• The main advantage of these criteria is that they could be used for any task modeling activity, whatever the task model notation or method used; as: Hierarchical Task Analysis (HTA), Méthode Analytique de Description de tâche (MAD); Goals, Operators, Methods, and Selectors (GOMS), Task Knowledge Structures (TKS), Groupware Task Analysis (GTA), ConcurTaskTree (CTT).


Conclusion

•In order to support this activity in scenario-based design, a software has been implemented in Java 1.5

•This method has been validated on several real-world case studies

CASE STUDY TASKS IDENTIFIED

Bank credit for a car 20

Organization of a Triathlon 72

Personalized order of compression stockings over Internet

25

How to get my driving license 25

Airport passenger workflow 20


Future work

• Future work includes the evaluation of task analysis methods.

• Empirical evaluation will be conducted confronting two groups of task analysts, the first group, designing a solution without using the guidelines and the second using them. Thus, these results will contribute to the credibility of the proposal.


Thank you very much for your attention

For more information and downloading,http://www.isys.ucl.ac.be/bchi

http://www.usixml.orgUser Interface eXtensible Markup Language

http://www.similar.ccEuropean network on Multimodal UIs

Special thanks to all members of the team!

http://www.isys.ucl.ac.be/bchi

http://www.usixml.org/

http://www.similar.cc/

Identification Criteria in Task Modeling

Business

change of task

new task

task models

task modeling activity

ifip world congress

change of category

workflow modeling

future work hcis2008