From Task Analysis and Task Modeling to Task Model

Engineering

Philippe Palanque

LIIHS-IRIT

Université Paul Sabatier

palanque@irit.fr – http://liihs.irit.fr/palanque

From a joint tutorial with Fabio Paterno at World Congress on Formal Methods 99

Rio de Janeiro – 18-19 september 2007Rio de Janeiro – 18-19 september 2007

Structure of the lecture

Introduction to Model-based Approaches State of art in Task ModelsConcurTaskTreesTask Models for Cooperative ApplicationsExercisesTask Models in Usability Evaluation

Why Model-based approaches?

Highlight important informationHelp to manage complexity Useful to support methodsOne important aspect of most

development methodsReason about models ...

Significant Models in HCI

Task modelsCognitive architecturesUser modelsDomain ModelsContext ModelsPresentation ModelsDialogue models…

UML and HCI

Model-based approachNine notationsLack of consideration of the user interfaceToo early consideration of the user

interface

How to improve it?Refine use case in task models?

Digression: UML for Interactive Systems

Outline

What UML is and is notWhat is in Interactive Systems

Engineering IS engineering UML and IS engineering

What could be UML for Interactive Systems

UML History

End of the 80’s : competition between OO analysis and design methods Booch : particularly suited for design and

implementation OOSE (Jacobson) : focus on requirements engineering

OMT-2 (Rumbaugh) : focus on analysis and on data-oriented applications

1994 : Rumbaugh rejoin Booch at Rational 1995 : Jacobson rejoin Rational 14 November 1997 : UML adopted by the OMG

What is UML ? Not a method (design process)

« The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems »

Language : lexical (graphical), syntax (diagrams), semantic Visualise : graphical representation Specification : precise, complete, non-ambiguous Construction : translation towards programming langages Documentation : from requirements to tests

UML by itself

© Chuck Suscheck 2000, communication personnelle

CollaborationDiagram

DeploymentDiagram

UseCaseRealization

ComponentDiagram

SequenceDiagram

UseCaseDiagram

ActivityDiagram

ObjectDiagram

ClassDiagramRequirement

Component

StateChart

UseCase

Object

Class

1

0..*

Instance of

Supports

Mirrors

Snapshot

Behavior specified by

Behavior specified by

1..*

1..*

Modeled By

Behavior specified by

Shows behavior for

Behavior specified by

1

1

Realized by

Deployed upon

Use of diagrams

Prescriptive diagrams : describe the system as it should be or how it should behave at any time Class, StateCharts, Use Cases, Activities,

Components, Deployment

Descriptive diagrams : represent a state or a possible or typical behaviour of the system Object, Sequence, Collaboration

What is in Interactive Systems Engineering Producing solutions to problems if possible by

reuse of experience Various contributions

Abstraction first: architectures Reuse first: design patterns Semantic first: metaphors Implementation first: toolkits Presentation first: UIMS and RAD Process first : iterative, UCD process Model first: model-based approaches

Abstraction first : architectures

Seeheim and Arch ? Describe typical structure for IS Describe relationship between components Structure promoted for reuse, portability, …

Possible use of extension mechanisms By definition not in UML Stereotypes Class Diagrams (functional core or

presentation) an attribute associated to a class (only a documentation)

Tagged Values

Reuse First: Design Patterns 1

MVC or PAC Foundation

of most toolkits and UIMSs

Described in terms of class and sequence diagrams

Vue

Notify(Modele modele)

Controleur

HandleEvent()

Modele

att1 : int

att2 : String

Service1()

Service2()

AddModeleListener()

getData()

*

*

enregistre

Invoque

Notify(Modele modele)

Vue

HandleEvent()

Controleur

att1 : int

att2 : String

Service1()

Service2()

AddModeleListener()

getData()

Modele

c:Controler v1:ViewUI m:Modelv2:View

AddModelListener()

AddModelListener()

Event()

Service1()

Notify(model)

Notify(model)getData()

getData()

Reuse First: Design Patterns 2

Nothing about the use of the design pattern for the application

Some tools claim to support design patterns usually only cut and paste use of diagrams … against the spirit of design patterns

Semantic first: metaphors

Widely used for UI design Desktop, rooms (file managers) Making Movie, Xtv, Whizz (software classes) Village (web sites)

Nothing to do with UML

Implementation first: toolkits

UML description of a toolkit would be very useful for designer Hard to master Poor documentation No or few rationale

No widely-used toolkit described in terms of UML beyond inheritance tree

Presentation first: RAD

Iterative rapid prototyping Widely used Promote User centred design Evaluation based

UML users’ guide Software development life cycle p. 33-34 “the UML is largely process-independent […]. However,

[…] you should consider a process that is Use case driven Architecture-centric Iterative and incremental

XP versus Rational Unified Process in general

Model first: model-based approaches (1)

Many models can be build for model-based UI Design Domain model (including data model) Task model and scenarios User model Platform model (link to toolkit and environment) Dialogue model (behaviour of the application I/O) Presentation model (appearance of the application) Application model (commands and data the application

provides) …

Model first: model-based approaches (2) Fully taken into account

Domain model (including data model) class and object diagrams (organisational charts, …)

Application model (commands and data the application provides) main focus of UML

Partially accounted for Task model and scenarios (through use cases) Dialogue model state charts (state and events) and sequence

diagrams Not considered

User model Platform model (link to toolkit and ) Presentation model (appearance of the application)

Back to the topic of the session : Task Analysis

Definitions

TaskGoalBasic TaskTask Analysis <> Activity analysis Task Modeling

What is the point of task analysis?

Determine What the users do The tools they use to do their work The information they know or the information

they must know for performing their work

Cover all/most casesCover all/most users

One small example

To clean the house Take the vacuum cleaner Plug it in Use it in all the rooms When the bag is full, empty it Store the vacuum cleaner

You must know Where is the vacuum cleaner Where are the plugs How to remove the bag Where are the new bags Evaluate if a room is clean or not

Information gathering

Planned procedure Ask the boss Look at the manual

Actual procedure Ask the operator Record operator behaviour

Optimal procedure The target for a good system

Task Analysis (Web application for museum)

Tourist general and clear information in limited amount access by spatial representations guided navigation

Art student some basic knowledge choice among different types of information

Expert precise requests detailed description of the information requested

Beware about the abstraction level

If you ask the following question:What are you doing?

You can get: I am striking ctrl-B keys I make "bonjour" in bold I make on word bold I highlight a word I am modifying a document I am writing a letter I keep contact with my familly I am waiting for a phone call

Building the task tree

1 Build a list of tasks 2 Gather high-level tasks 3 Breakdown low level tasks

Where to stop ? Is the action « empty bag » decomposed enough? Objective: only decompose pertinent tasks (objective

optimization/automation of work) User actions: cognitive/motor usually not that interesting to

decompose (except for performance evaluation) System activity MUST not be represented (will be in other models)

Highest level = reproduction of the specie Lowest level = biological life (breathe, drink a coffee , …)

Example: make a cup of tea

Refining Models

Once the model is built (whatever notation you use) How to be sure that it is correct? How to improve it?

Some heuristics Coupled actions: e.g., where is "turn gas on"? Restructure : e.g. make a task generic “make pot” Balance : e.g. is “pour tea” simpler than “make pot”? Generalise: e.g. make one cup … make many

Example: make a cup of tea

Examples of task analysis

Tourist Book a train ticket Find a monument in the city Game of 15

A client using a cash machine Withdraw money Check the balance on the account …

Party : The game of 15

The game is played by 2You have the following tokens 1, 2, 3, 4, 5, 6, 7, 8, 9People play in turn, each player take one token at a

time, one token can only be taken onceThe first with 3 token of which the sum adds up to 15

is the winner

Play this game without tool (paper, pencil or other! )

Party : The game of 15

Analyze one player taskPropose a decomposition in sub tasks

Propose an interface (paper +pencil or computer tool) for this gameThe user interface must (of course) help the

player to achieve his task

Beware !

Not a cognitivist approach Don’t include the system Make sure models are correct No algorithmic description (calculation of who is

the winner) No task migration (the system performs tasks

assigned to the player) Who starts (difference between you play

together and you play with ME - elbow communication)

Task Analysis

Play the game of 15

Ensure turn taking Choose a tokenEvaluate if there

is a winner

Remember token I have already taken

Remember the Remaining tokens

Your solution

Another solution

8

1

6

3

5

7

4

9

2

Extraterrestrial Example of a computer system

We have a database with the following schema:

Propose a menu tree allowing to manipulate that database

ClientClient ManagesManages Sales ManSales Man1,1 1,n

Functioning versus Usage Structuring

Client

Sales man

AddDeleteModifyDisplay

AddDeleteModifyDsisplay

Functioning structure

View of the computer Scientist The tree structure

reflects the database structure

Grouping is made by function code similarity

Example of task

« I spent my day at work entering information for new clients and I must associate them with the more suitable sales man (according to various criteria) … sometimes I receive an invoice from a sales man recently recruited. In such a case, I must create both the new sales man and the client. Sometimes a sales man quits the company. Usually they leave the company for another one and the clients follow them. I then have to delete the sales man and all its related … »

Propose a tree structure adapted to the tasks

Sales ManagementAdd

Delete its Clients

Modify

Display

Add Sales Man

Delete Sales Man

Display Sales Man information

Add Sales ManDisplay Sales Man information

Usage structure (1/2)

User interface is structured according to the task

Things are still problematic

There is no Menu for deleting clients (without sales man) Client modification …

There is Access to clients through their sales man Display of client information without getting to their sales

man first …

U=1/F

Back to the second topic of the session : Task Modeling

Engineering task models

Flexible and expressive notationsSystematic methods able to indicate how

to use information in the task modelsAvailability of automatic tools to use such

information efficiently

The many possible task models

Existing System One or many systems One or many operators

Envisioned System One or many systems One or many operators

Variation of models (co-evolution)

Use of Task Models

Better understanding of the application (and in particular its use)

Record discussions (multidisciplinary) Help design Help usability evaluation Help performance evaluation Help user in performing the tasks (contextual

help) Documentation (content + structure)

Representations of Task Models

Hierarchical task analysisGOMS familyUANK-made (web)AMBOSS (web)Different syntax (textual vs graphical)Different level of formalityDifferent set of operators for task composition

GOMS Example

GOAL: EDIT-MANUSCRIPTGOAL: EDIT-UNIT-Task repeat until no more unit tasks

GOAL: ACQUIRE-UNIT-TASKGET-NEXT-PAGE if at end of manuscriptGET-NEXT-TASK

GOAL: EXECUTE-UNIT-TASKGOAL:LOCATE-LINE

[select: USE-QS-METHODUSE-LF-METHOD]

GOAL: MODIFY-TEXT[select: USE-S-METHOD

USE-M-METHOD]VERIFY-EDIT

Limitations of GOMS

It does not consider user errorsIt does not consider the possibility of

interruptionsIt considers only sequential tasksIt can be inadequate for distributed

applications (such as web-based applications)

UAN - User Action Notation

2 complementary set of information A hierarchy of tasks LOTOS (proche de CTT) A table for describing states and feedback

Textual notation Introduced in 1992 (Hix & Hartson huge

success Developing user interfaces Ensuring, Usability Through Product & Process)

Example of UAN specification

Task: BuildRequest:((SelR | ClearR | IconifyR)*--> SpecField+)

Task: SelApplicationUser Action Interface Feedback Interface State~[x,y in AppICON] (t<tdoubleClick) w’!: w’-!

UnMap(PrevAppliMenu)Map(AppMenu)UnMap(AppICON)

CurAppli=AppCurMenu=AppMenu

ConcurTaskTrees

Focus on Activities Hierarchical StructureGraphical SyntaxRich set of temporal operatorsTask allocationObjects and task attributes

Task Models vs Scenarios

Scenarios are informal descriptions of a specific use in a specific context

Task models describe the possible activities and their relationships

Scenarios can support task developmentTask models can support scenarios

identification

Moving from scenarios to tasks

Find verbs = tasksFind words = objects Find adverbs = temporal relationships

Temporal Operators

Enabling T1 >> T2 or T1 [ ]>> T2 Disabling T1 [> T2 Interruption T1 |> T2Choice T1 [ ] T2 Iteration T1* or T1{n} Concurrency T1 ||| T2 T1 |[]| T2Concurrency (must finish first) T1 |=| T2 Optionality [T]

Operators Priority

Ambiguity in the model

Ambiguity removed

Priority: [], |||, [>, >>

Interaction tasksSelection

Edit

Control

…

Application taskOverview

Comparison

Locate

Grouping

...

Tasks types

Inheritance of relationships

Relationships task/subtasks

Optional tasks

Tool Support in CTTE

Flexible editing of the task modelUsing informal descriptions in modelling Checking completeness of the specificationSaving the specification in various formatsSimulating the task model Comparing task modelsRunning scenarioshttp://giove.cnuce.cnr.it/ctte.html

CTT Editor

Task Simulator

User1

User2 User3

Cooperative part

t1t2

t3

t1(User1) t3 (User3)

Modelling Multi-User Applications

Cooperative aspects

Exercises

Develop a task model in ConcurTaskTrees from the game 15 previous model

Develop a task model for a an ATM Think about normal behaviours Abnormal behaviours

Exercise: ATM constraints

Insert_Card, Enter_Code, Witdraw_CardRequest_Cash, Select_Amount, Withdraw_Cash

Request_Cash Select_Amountbefore

Insert_Card Withdraw_Cardbefore

Enter_Code Insert_Cardjust after

andSelect_Amount

Insert_CardWithdraw_Cashbefore

ATM: Tasks

Goal: Get cashPrerequisite:

Have a card Know the amount to withdraw Know PIN number

Results Take cash Take card

ATM: Task Model

ATM: Task Model

ATM: Task Model

ATM: Task Model

ATM: User Error

Prevent post-completion errors

Definition of a post completion errorExamples Modify previous task model to prevent

post-completion errors

Limitations of current approaches in UI designVisual tools do not support mapping

between logical activities and UI elementsUML is oriented to the system designNo available tools for task-based design

(when existing, not publicly available and limited functionality)

Grouping tasks that share the same parent taskCommunicating concurrent tasks (|[]|) are

presented close to each other

The task model structure

Both sets are shown in the same presentation unit (when they exchange information, []>>)

The sets are presented at different times The sets are presented in different presentation unit

at the same time

Supporting enabling operator

Jo*

Submit

Name:

Name AgeJohansen 52Jones 27Joxibon 18

Jo*

Submit

Name:

Age:

Name AgeJohansen 52Jones 21

Results:

>20

Results:

Situation 1 Situations 2 and 3

Deriving information from operators

Task-interface relationships

Tasks-interface relationships

Tasks-interface relationships

Conclusions – insights ??

Should we generate UI from task models ? Video store user interface Spotfire User Interface

How to relate task models with other models?