1. CMPUT 301: Lecture 26,27 Models of the User Lecturer: Martin Jagersand Department of Computing Science University of Alberta Notes based on previous courses by Ken Wong, Eleni Stroulia Martin Jagersand

2. 2 User Requirements Modeling Purpose: –capturing the needs of users Approaches: –socio-technical models –soft systems methodology –participatory design

3. 3 Socio-Technical Models What: –for a system, represent the social, organizational, human and technical aspects of its design –identify requirements from both human and technical perspectives –because technology is not developed or used in isolation Many variations: USTM, CUSTOM, OSTA, ETHICS

4. 4 Socio-Technical Models Identify and describe: –organizational context –primary goals, historical background –stakeholders –motivation, job satisfaction, knowledge, skills, power, tasks, needs for training –workgroups –role, characteristics, relationships within/without the organization

5. 5 Socio-Technical Models Identify and describe: –task-object pairs –required tasks and applicable objects –success criteria –reliability, performance, user satisfaction, etc. –technical system –components, architecture, integration, etc.

6. 6 Socio-Technical Models Stakeholder: –anyone who is concerned with the success or failure of the system –not just end users –who are they?

7. 7 Socio-Technical Models Stakeholders (airline booking system): –primary –those who use the system –e.g., travel agency staff, airline booking staff –secondary –those who receive output or provide input –e.g., customers, airline management

8. 8 Socio-Technical Models Stakeholders (airline booking system): –tertiary –those who are affected by its success/failure –e.g., competitors, civil aviation authorities, airline shareholders –facilitating –those who design and evolve it –e.g., information systems staff

9. 9 Socio-Technical Models Stakeholder analysis: –What does the stakeholder have to achieve? How is success measured? –What knowledge and skills does the stakeholder have? –What attitude towards computer technology does the stakeholder have? –Does the stakeholder have to consider issues of responsibility, security, or privacy? –etc.

10. 10 Soft Systems Methodology Technology and people are both considered as components of the system Stages: 1.recognize problem or opportunity –begin analysis 2.develop a rich picture –form detailed problem description –stakeholders, workgroups, tasks, etc. –gathered via observation, interviews, questionnaires 3.generate root definitions –create for each stakeholder perspective

11. 11 Soft Systems Methodology Root definition for airline management (airline booking system): –clients –those who receive output or benefit from the system –e.g., customer (a traveller) –actors –those who perform tasks within the system –e.g., travel agent

12. 12 Soft Systems Methodology Root definition for airline management (airline booking system): –transformations –processing of inputs into outputs –e.g., customer travel request into sale of seat on flight and profit for company –world view (Weltanshauung in book) –how the system is perceived –e.g., profits can increase if sales are more efficient

13. 13 Soft Systems Methodology Root definition for airline management (airline booking system): –owner –those who own the system and can authorize changes –e.g., airline management –environment –the world in which the system operates –e.g., civil aviation regulations, contract law, etc.

14. 14 Soft Systems Methodology More stages: –devise conceptual model –determine what the system must do to satisfy the root definitions –build hierarchy of transformations, tasks, and technologies (from what to how) –compare real world with conceptual model –identify anomalies and potential concerns

15. 15 Soft Systems Methodology Final stage: –determine necessary changes –identify social, procedural, and structural changes to would improve or benefit the system –reengineer business processes

16. 16 Participatory Design Incorporate the user as an active member of the design team (not just as an experimental subject) Why: –because the users are experts in the application domain and work context –Makes design work/use oriented instead of system oriented –Puts users on equal level with designers

17. 17 Participatory Design Methods: –Workshops, committees –establish common ground between designer and user –understand the design from each other’s points of view –e.g., designer asks about work context and user asks about capabilities and technology

18. 18 Participatory Design Methods: –brainstorming –informal, unstructured, unfiltered pooling of design ideas –storyboarding –potential designs of day-to-day tasks –pencil and paper exercises –e.g., paper mockups of the user interface

19. 19 User requirement modeling Compare approaches: –socio-technical models –soft systems methodology –participatory design What is major focus of each? Differences?

20. CMPUT 301: Lecture 27 Models of the User Lecturer: Martin Jagersand Department of Computing Science University of Alberta Notes based on previous courses by Ken Wong, Eleni Stroulia Martin Jagersand

21. 21 Cognitive Models What: –model some aspect of the user’s intentions, processing, or required knowledge while interacting with an interface –to understand user behavior (somewhat as a computing mechanism)

22. 22 Cognitive Models Two categories: –user and associated task language –goal and task hierarchies –articulation translation from task to input language –linguistic models –physical and device-level models

23. 23 Goal and Task Hierarchies What: –form a hierarchy of goals and subgoals –focus on low-level behavior or unit tasks that do not involve reasoning or problem solving –possibly predict low-level user performance or cognitive load –e.g., time to do a task

24. 24 Goal and Task Hierarchies Two models: –GOMS –goals, operators, methods, selection –CCT –cognitive complexity theory

25. 25 GOMS Four elements: –goals –what user wants to achieve –operators –basic actions affecting system state or user mental state –methods –goal decompositions into subgoals –selection –predicted choice of methods

26. 26 GOMS Minimizing a window: –Methods: –GOAL: ICONIZE-WINDOW [SELECT GOAL: USE-CLOSE-METHOD MOVE-MOUSE-TO-WINDOW-TITLE POP-UP-MENU CLICK-OVER-CLOSE-OPTION GOAL: USE-L7-METHOD PRESS-L7-KEY ] –Selection: –user Sam: rule 1: USE-CLOSE-METHOD unless another rule applies rule 2: if the application is a game USE-L7-METHOD

27. 27 GOMS Sub-goal stack: –depth corresponds to load on short-term memory –Issue: When is closure of a goal? –e.g., goal to get cash at ATM, collect money, collect card? –Experimentally can compare GOMS method traces to user task analysis results

28. 28 CCT Cognitive Complexity Theory What: –goal decomposition expressed using production rules in long-term memory –if condition then action –system (device) described using generalized transition networks –like state transition diagram

29. 29 CCT Production rules for editing in vi: –(SELECT-INSERT-SPACE IF (AND (TEST-GOAL perform unit task) (TEST-TEXT task is insert space) (NOT (TEST-GOAL insert space) (NOT (TEST-NOTE executing insert space))) THEN ((ADD-GOAL insert space) (ADD-NOTE executing insert space) (LOOK-TEXT task is at %LINE %COL))) –… World state (external and user short term memory): –(GOAL perform unit task) (TEXT task is insert space) (TEXT task is at 5 23) (CURSOR 8 7)

30. 30 CCT Updated short-term memory: –(GOAL perform unit task) (TEXT task is insert space) (TEXT task is at 5 23) (CURSOR 8 7) (GOAL insert space) (NOTE executing insert space) (LINE 5) (COL 23)

31. 31 CCT Other production rules that can fire: –move cursor to appropriate place –(INSERT-SPACE-1 IF (AND (TEST-GOAL insert space) (NOT (TEST-GOAL move cursor)) (NOT (TEST-CURSOR %LINE %COL))) THEN ((ADD-GOAL move cursor to %LINE %COL))) –… –actually insert space –(INSERT-SPACE-2 … –clean up short-term memory –(INSERT-SPACE-DONE …

32. 32 CCT Measurements: –number of goal terms in short-term memory corresponds to cognitive load –more production rules  interface more difficult to learn Flexibility –production rules can model concurrent plans, ie editing text while drinking tea. (Remember GOMS sequential)

33. 33 CCT Issues: –size of description can be huge (see p 236 in book) –some rules only set up other rules and may not have any cognitive significance

34. 34 Linguistic Models Two models: –BNF –Backus-Naur Form to describe dialog grammar –Previously used to describe syntax of programming languages –task-action grammar –similar but uses parameterized grammar rules

35. 35 BNF Elements: –non-terminals –terminals (lowest-level actions) –::=is defined as (can be replaced by) –+sequence (or use space) “and” –|choice “or” Syntax: ::= –left-hand-side only has non-terminals

36. 36 BNF Grammar for choosing and creating a polyline (generates valid dialogs): –draw-line ::= select-line + choose-points + last-point select-line ::= position-mouse + CLICK-MOUSE choose-points ::= choose-one | choose-one + choose-points choose-one ::= position-mouse + CLICK-MOUSE last-point ::= position-mouse + DBL-CLICK-MOUSE position-mouse ::= empty | MOVE-MOUSE + position-mouse

37. 37 BNF Measurements: –number of rules or number of + and | operators can help measure the interface complexity –But: depends on how the grammar is written –e.g., sub choose-one within choose-points

38. 38 Task-Action Grammar enhances BNF by considering consistency in the grammatical structure and encoding domain knowledge better measures of ease of learning

39. 39 Task-Action Grammar BNF: –copy ::= ‘cp’ + filename + filename | ‘cp’ + filenames + directory –move ::= ‘mv’ + filename + filename | ‘mv’ + filenames + directory Task-action grammar: –file-op[Op] := command[Op] + filename + filename | command[Op] + filenames + directory –command[Op=copy] := ‘cp’ command[Op=move] := ‘mv’

40. 40 Physical and Device Models Two models: –keystroke-level model –three-state model

41. 41 Keystroke-Level Model What: –model the execution of a simple, low-level task using the user interface –e.g., changing the type style of a word –goal is already formed –i.e., no high-level mental activity, method already chosen

42. 42 Keystroke-Level Model Operators: –motor –Kkeystroke –Bbutton click with mouse –Ppoint with mouse –Hhome (move hand to/from keyboard) –Ddraw lines with mouse –mental –Mmentally prepare for an action –system response –Rdisplay response

43. 43 Keystroke-Level Model Editing a character in text: –move hand to mouse –H[mouse] –position mouse after wrong character –PB[LEFT] –return hand to keyboard –H[keyboard]

44. 44 Keystroke-Level Model Editing a character in text: –delete character –MK[DELETE] –type correction –K[char] –reposition insertion point –H[mouse]MPB[LEFT]

45. 45 Keystroke-Level Model Times for various operators: –Kpress key –good typist (90 wpm)0.12 s –poor typist (40 wpm)0.28 s –non-typist1.20 s –Bmouse button –up or down0.10 s –click0.20 s

46. 46 Keystroke-Level Model Times for various operators: –Ppoint –average1.10 s –Fitts’ law0.1 log 2 (D/S + 0.5) s –Hhome –to and from keyboard0.40 s

47. 47 Keystroke-Level Model Times for various operators: –Ddrawdepends –Mmental prepare1.35 s –Rresponsemeasure

48. 48 Keystroke-Level Model Combining operators: –times depend on user skill –choice of operators also depend on user skill –determine level of user expertise before analyzing times –times are best used relatively (for comparing different interactions)

49. 49 Keystroke-Level Model Mental operator: –where to insert? –where there are slight pauses for recall –one “chunk” == one mental operator –e.g., entering a command name

50. 50 Keystroke-Level Model Iconize window: –close menu method, hand on mouse –P[window menu] 0.1 log 2 (12.5/1.25+0.5) s –B[LEFT down] 0.1 s –MP[to close item] 1.35 s + 0.1 log 2 (4/1+0.5) s –B[LEFT up] 0.1 s –predicted time = 2.1 s

51. 51 Keystroke-Level Model Iconize window: –L7 key method, hand on mouse –H[to keyboard] 0.4 s –MK[L7 key] 1.35 s + 0.28 s –predicted time = 2.03 s

52. 52 Keystroke-Level Model Issues: –model has been empirically validated on various systems and tasks –predictions are accurate –(Error about 20%) –low-level interaction only –fastest is best?

53. 53 Three-State Model What: –model of input devices –state 0no input –state 1tracking –state 2dragging Fitts law have different coefficients in: 1.Different states 2.For different input devices (ie mouse, trackball, lightpen etc…)

54. 54 Three-State Model Mouse:

55. 55 Three-State Model Light pen:

56. 56 Three-State Model Fitts’ law: a + b log 2 (D/S + 1) –where D is distance to target, S is size of target, a and b are coefficients that depend on user skill, pointing device, and device state

57. 57 End What did I learn today? What questions do I still have?