From Task Analysis and Task Modeling to Task Model Engineering

Philippe Palanque

LIIHS-IRIT Université Paul Sabatier [email protected]

– 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 2007

Structure of the lecture  Introduction to Model-based Approaches  State of art in Task Models  ConcurTaskTrees  Task Models for Cooperative Applications  Exercises  Task Models in Usability Evaluation

Why Model-based approaches?

 Highlight important information  Help to manage complexity  Useful to support methods  One important aspect of most development methods  Reason about models  ...

Significant Models in HCI  Task models  Cognitive architectures  User models  Domain Models  Context Models  Presentation Models  Dialogue models  …

UML and HCI  Model-based approach  Nine notations  Lack of consideration of the user interface  Too 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 not  What 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

Class Requirement UseCaseDiagram ClassDiagram

1..* Snapshot

Activ ityDiagram

Modeled By Supports 1..*

UseCase Obj ectDiagram

1 Realized by 1

UseCaseRealization

Behav ior specif ied by

SequenceDiagram

Mirrors Behav ior specif ied by

CollaborationDiagram

Shows behav ior f or Behav ior specif ied by Instance of 0..*

Obj ect

1 Behav ior specif ied by

ComponentDiagram Component StateChart

Deploy ed upon © Chuck Suscheck 2000,

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

enregistre * Invoque *

Reuse First: Design Patterns 2

UI

  Nothing about the use of the design pattern for the application

Event()

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

c:Controler v1:View Service1() getData() v2:View AddModelListener() AddModelListener() Notify(model) Notify(model) getData() m:Model

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  Task  Goal  Basic Task  Task 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 cases  Cover 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 2 3 Build a list of tasks Gather high-level tasks 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 2  You have the following tokens 1, 2, 3, 4, 5, 6, 7, 8, 9  People play in turn, each player take one token at a time, one token can only be taken once The 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 task  Propose a decomposition in sub tasks  Propose an interface (paper +pencil or computer tool) for this game  The 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 token Evaluate 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

Functioning versus Usage Structuring  Extraterrestrial  Example of a computer system  We have a database with the following schema: Client Manages Sales Man 1,1 1,n  Propose a menu tree allowing to manipulate that database

Functioning structure  View of the computer Scientist  The tree structure reflects the database structure  Grouping is made by function code similarity Client Add Delete Modify Display Sales man Add Delete Modify Dsisplay

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

Usage structure (1/2)  User interface is structured according to the task Sales Management Add Display Sales Man information Add Sales Man Display Modify Display Sales Man information Add Sales Man Delete Sales Man Delete its Clients

Things are still problematic  There is no  Menu for deleting clients (without sales man)  Client modification  …

U=1/F

 There is  Access to clients through their sales man  Display of client information without getting to their sales man first  …

Back to the second topic of the session : Task Modeling

Engineering task models  Flexible and expressive notations  Systematic methods able to indicate how to use information in the task models  Availability 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 analysis  GOMS family  UAN  K-made (web)  AMBOSS (web)  Different syntax (textual vs graphical)  Different level of formality  Different set of operators for task composition

GOMS Example GOAL: EDIT-MANUSCRIPT GOAL: EDIT-UNIT-Task repeat until no more unit tasks GOAL: ACQUIRE-UNIT-TASK GET-NEXT-PAGE if at end of manuscript GET-NEXT-TASK GOAL: EXECUTE-UNIT-TASK GOAL:LOCATE-LINE [select: USE-QS-METHOD USE-LF-METHOD] GOAL: MODIFY-TEXT [select: USE-S-METHOD USE-M-METHOD] VERIFY-EDIT

Limitations of GOMS  It does not consider user errors  It does not consider the possibility of interruptions  It considers only sequential tasks  It 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: SelApplication

User Action ~[x,y in AppICON]  (t

UnMap(PrevAppliMenu) Map(AppMenu) UnMap(AppICON) Interface State CurAppli=App CurMenu=AppMenu

ConcurTaskTrees  Focus on Activities  Hierarchical Structure  Graphical Syntax  Rich set of temporal operators  Task allocation  Objects 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 development  Task models can support scenarios identification

Moving from scenarios to tasks  Find verbs = tasks  Find words = objects  Find adverbs = temporal relationships

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

Operators Priority  Ambiguity in the model  Ambiguity removed  Priority: [], |||, [>, >>

Tasks types

Interaction tasks

Selection Edit Control …

Application task

Overview Comparison Locate Grouping ...

Inheritance of relationships

Relationships task/subtasks

Optional tasks

Tool Support in CTTE  Flexible editing of the task model  Using informal descriptions in modelling  Checking completeness of the specification  Saving the specification in various formats  Simulating the task model  Comparing task models  Running scenarios  http://giove.cnuce.cnr.it/ctte.html

CTT Editor

Task Simulator

Modelling Multi-User Applications t1 User1 t2 User2 t1(User1) t3 (User3) Cooperative part User3 t3

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_Card



Request_Cash, Select_Amount, Withdraw_Cash

before

Select_Amount Request_Cash Select_Amount

and

Insert_Card Insert_Card Enter_Code

before before just after

Withdraw_Cash Withdraw_Card Insert_Card

ATM: Tasks  Goal: Get cash  Prerequisite:  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 error  Examples  Modify previous task model to prevent post-completion errors

Limitations of current approaches in UI design  Visual tools do not support mapping between logical activities and UI elements  UML is oriented to the system design  No available tools for task-based design (when existing, not publicly available and limited functionality)

The task model structure  Grouping tasks that share the same parent task  Communicating concurrent tasks (|[]|) are presented close to each other

Supporting enabling operator  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 Situation 1 Situations 2 and 3 Name: Jo* Submit Name: Age: Jo* >20 Results: Name Age Johansen 52 Jones 27 Joxibon 18 Submit Results: Name Age Johansen 52 Jones 21

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?