From Task Analysis and Task Modeling to Task Model Engineering

1. 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

2. 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

3. 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 ...

4. Significant Models in HCI Task models Cognitive architectures User models Domain Models Context Models Presentation Models Dialogue models �

5. 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?

6. Digression: UML for Interactive Systems

7. 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

8. 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

9. 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

10. UML by itself

11. 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

12. 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

13. 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

14. Reuse First: Design Patterns 1 MVC or PAC Foundation of most toolkits and UIMSs Described in terms of class and sequence diagrams

15. 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

16. 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

17. 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

18. 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

19. 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) �

20. 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)

21. Back to the topic of the session : Task Analysis

22. Definitions Task Goal Basic Task Task Analysis <> Activity analysis Task Modeling

23. 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

24. 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

25. 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

26. 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

27. 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 ?

28. 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 , �)

29. Example: make a cup of tea

30. 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

31. Example: make a cup of tea

32. 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 �

33. 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! )

34. 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

35. 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)

36. Task Analysis

37. Your solution

38. Another solution

39. Extraterrestrial Example of a computer system We have a database with the following schema: Propose a menu tree allowing to manipulate that database Functioning versus Usage Structuring

40. Functioning structure View of the computer Scientist The tree structure reflects the database structure Grouping is made by function code similarity

41. 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

42. Usage structure (1/2) User interface is structured according to the task

43. 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 �

44. Back to the second topic of the session : Task Modeling

45. 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

46. 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)

47. 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)

48. 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

49. GOMS Example

50. 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)

51. 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)

52. Example of UAN specification

53. ConcurTaskTrees Focus on Activities Hierarchical Structure Graphical Syntax Rich set of temporal operators Task allocation Objects and task attributes

54. 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

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

56. Temporal Operators Enabling T1 >> T2 or T1 [ ]>> T2 Disabling 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]

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

58. Tasks types

59. Inheritance of relationships

60. Relationships task/subtasks

61. Optional tasks

62. 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

63. CTT Editor

64. Task Simulator

65. Modelling Multi-User Applications

66. Cooperative aspects

67. 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

68. Exercise: ATM constraints Insert_Card, Enter_Code, Witdraw_Card Request_Cash, Select_Amount, Withdraw_Cash

69. ATM: Tasks Goal: Get cash Prerequisite: Have a card Know the amount to withdraw Know PIN number Results Take cash Take card

70. ATM: Task Model

71. ATM: Task Model

72. ATM: Task Model

73. ATM: Task Model

74. ATM: User Error

75. Prevent post-completion errors Definition of a post completion error Examples Modify previous task model to prevent post-completion errors

76. 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)

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

78. 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

79. Deriving information from operators

80. Task-interface relationships

81. Tasks-interface relationships

82. Tasks-interface relationships

83. Conclusions � insights ?? Should we generate UI from task models ? Video store user interface Spotfire User Interface How to relate task models with other models?