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 Rio de Janeiro – 18-19 september 2007

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 © Chuck Suscheck 2000, communication personnelle

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. Vue Vue Notify(Modele modele) Notify(Modele modele) * enregistre Modele Modele att1 : int att1 : int att2 : String att2 : String * Service1() Service1() Service2() Service2() Controleur Controleur Invoque AddModeleListener() AddModeleListener() getData() getData() HandleEvent() HandleEvent() Reuse First: Design Patterns 1 • MVC or PAC • Foundation of most toolkits and UIMSs • Described in terms of class and sequence diagrams

15. UI c:Controler v1:View v2:View m:Model AddModelListener() AddModelListener() Event() Service1() Notify(model) getData() Notify(model) 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

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. Functioning versus Usage Structuring • Extraterrestrial • Example of a computer system • We have a database with the following schema: • Propose a menu tree allowing to manipulate that database Manages Client Sales Man 1,1 1,n

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

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

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 • … U=1/F

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)