CMPUT 301 Lecture 26 27 Models of the

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

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

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 3

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 4

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

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

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 7

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 8

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

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 10

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 11

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 12

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

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 14

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

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 16

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 17

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 18

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

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

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

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 22

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 23

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

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 25

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-L 7 -METHOD PRESS-L 7 -KEY ] – Selection: – user Sam: rule 1: USE-CLOSE-METHOD unless another rule applies rule 2: if the application is a game USE-L 7 -METHOD 26

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 27

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 28

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

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

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

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

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 33

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 34

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

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 36

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 37

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

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

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

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 41

Keystroke-Level Model • Operators: – motor –K –B –P –H –D keystroke button click with mouse point with mouse home (move hand to/from keyboard) draw lines with mouse – mental –M mentally prepare for an action – system response –R display response 42

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

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

Keystroke-Level Model • Times for various operators: –K press key – good typist (90 wpm) – poor typist (40 wpm) – non-typist –B 0. 12 s 0. 28 s 1. 20 s mouse button – up or down – click 0. 10 s 0. 20 s 45

Keystroke-Level Model • Times for various operators: –P point – average – Fitts’ law –H 1. 10 s 0. 1 log 2 (D/S + 0. 5) s home – to and from keyboard 0. 40 s 46

Keystroke-Level Model • Times for various operators: –D –M –R draw mental prepare response depends 1. 35 s measure 47

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

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 49

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 50

Keystroke-Level Model • Iconize window: – L 7 key method, hand on mouse – H[to keyboard] 0. 4 s – MK[L 7 key] 1. 35 s + 0. 28 s – predicted time = 2. 03 s 51

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

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

Three-State Model • Mouse: 54

Three-State Model • Light pen: 55

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 56

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