Transcript ID lecture-2

Interaction Design
Specification
(lecture-6)
Prof. Dr. Matthias Rauterberg
Faculty Industrial Design
Technical University of Eindhoven
[email protected]
21-October-2002
Key references/literature[1]
•
•
•
•
•
•
•
•
•
Lifecycle Model:
Mayhew, D. (1999), The usability engineering lifecycle. Morgan Kaufmann. [ISBN
1-55860-661-4]
Buckingham Shum, S. & Hammond, N. (1994), Transferring HCI modelling and
design techniques to practitioners--a framework and empirical work. [download
PDF]
State-Transition-Diagram (STD):
Horrocks, I. (1999), Constructing the user interface with statecharts. AddisonWesley. [ISBN 0201342782]
Jacob, R. (1983), Executable Specifications for a Human-Computer Interface. ACM
CHI’83 Proceedings, pp. 28-34. [download PDF]
Harel, D. (1987), Statecharts--a visual formalism for complex systems. Science of
Computer Programming, vol 8, pp. 231-274. [download PDF]
Petri-Net (PN):
Reisig, W. (1992), A Primer in Petri Net Design. Springer. [ISBN: 0387520449]
Tanniru, M. & Sakthivel, L. (1987), Knowledge based support for system
verification during requirement analysis. ACM Proceedings. [download PDF]
Murata, T. (1989), Petri Nets--properties, analysis, and applications. Proceedings
of the IEEE, vol. 77(4), pp. 541-580. [download PDF]
Reisig, W. et al. (2000), Introductory tutorial to Petri Nets. [download PDF]
(c) M. Rauterberg, TU/e
2
Key references/literature[2]
•
•
•
•
Goal-Operation-Method-Selection (GOMS):
Card S, Moran T, & Newell A (1983), The psychology of human
computer interaction, Lawrence Erlbaum Assoc, Hillsdale, NJ
John, B. & Kieras, D. (1994), The GOMS family of analysis techniques--tools
for design and evaluation. [download PDF]
Kieras, D. (1996), A guide to GOMS model usability evaluation using
NGOMSL. [download PDF]
User-Action-Notation (UAN):
Hartson, H. R., Siochi, A.C., & Hix, D. (1990), "The UAN--a useroriented representation for direct manipulation interface designs",
ACM Transactions of Information Systems, 8(3), pp. 181-203.
[download PDF]
•
•
Hix, D. & Hartson, H. R., (1993) “Developing user interfaces”, Wiley.
(Chapter 6 and 7)
Hartson, H.R. & Gray P. D. (1992), "Temporal aspects of tasks in the
User Action Notation”, Human Computer Interaction, 7(92), pp. 1-45.
(c) M. Rauterberg, TU/e
3
The Lifecycle Model
concept
formulation
technical
analysis
user task
analysis
Begin
business/
market
analysis
requirements
HW/SW
design
interaction
design
narrative
design
object/
space
design
design
platform
prototype
implementation
interaction
prototype
integration
performance
evaluation
(c) M. Rauterberg, TU/e
evaluation
content
prototype
usability
evaluation
aesthetic
evaluation
4
End
The Usability Engineering Lifecycle
(c) M. Rauterberg, TU/e
5
User Interaction Specification
• Most important approaches/notations to specifying
interaction:
– State-Transition-Diagrams (STD)
– Petri Nets (PN)
– Goal-Operation-Methods-Selections (GOMS)
– User Action Notation (UAN)
• Aim to provide more detailed descriptions of
interaction between user and system.
• Refinement of task model in terms closer to system.
• Provides medium of discussion and review between
human factors designers and systems developers.
(c) M. Rauterberg, TU/e
6
State Transition Diagram (STD)
Basic Elements
state
State transition
State
= set of values that describe an object (its condition/situation) at
a specific moment in time
{State is determined based on the attribute values}
State transition
= relationship indicating a state change
{atomic (i.e. non-interruptible)}
(c) M. Rauterberg, TU/e
7
STD Example 1: Draw Circle
Select ‘circle’
Highlight ‘circle’
Start
Click on centre
Click on circumference
Rubber band
Draw circle
Finish
Circle1
Circle2
Menu
Select ‘line’
Highlight ‘line’
(c) M. Rauterberg, TU/e
Click on first point
Rubber band
Line1
Line2
Finish
Double click
Draw last line
Click on point
Draw line and
rubber band from new point
8
STD Example 1 (cont’d)
Select ‘circle’
Highlight ‘circle’
Click on centre
Click on circumference
Rubber band
Draw circle
Finish
Circle1
Circle2
Press escape key
Start
Menu
Select ‘line’
Highlight ‘line’
Click on first point
Line1 Rubber band Line2
Arc from each state back to menu
Become messy!
(c) M. Rauterberg, TU/e
Finish
Double click
Draw last line
Click on point
Draw line and
rubber band from new point
9
Hierarchical STD Example 2
Not more
powerful, but
more simple
and flexible
Main
Menu
Select ‘graphics’
Pop-up submenu
Graphics submenu
Select ‘text’
Pop-up submenu
Text submenu
Select ‘paint’
Pop-up submenu
(c) M. Rauterberg, TU/e
Paint submenu
10
Hierarchical STD Example 2 (cont’d)
From Menu
Click on centre
Click on circumference
Rubber band
Draw circle
Finish
Circle1
Circle2
Press help
button
Help submenu
(c) M. Rauterberg, TU/e
Press help
button
Help submenu
11
Petri Nets (PN)
• First introduced by Carl Adam Petri in
1962.
• A diagrammatic tool to model concurrency
and synchronization in distributed
systems.
• Very similar to State Transition Diagrams.
• Used as a visual communication aid to
model the system behaviour.
• Based on strong mathematical foundation.
(c) M. Rauterberg, TU/e
12
PN: Building Blocks
Basic Elements
place
transition
counter
Place for user input
arcs
inhibitor
•
PN consists of three types of components: places (circles), transitions
(rectangles) and arcs (arrows):
– Places represent possible states of the system;
– Transitions are events or actions which cause the change of
state; And
– Every arc simply connects a place with a transition or a transition
with a place.
(c) M. Rauterberg, TU/e
13
PN: Formal Definition
A Petri net (PN) is a 5 tuple
PN (P,T,IN,OUT,M)
where:
P = {p1,p2,....,p~} is a finite set of places,
T = {t1, t2, …,tn} is a finite set of transitions
IN: (PxT)S
OUT: (TxP)S
M:
Marking vector
(c) M. Rauterberg, TU/e
14
PN: Formal Definition (cont’d)
IN are input functions defining directed arcs from
places to transitions
OUT are output functions defining directed arcs
from transitions to places
S is a set of all nonnegative integers k such that:
• If k = 1 a directed arc is drawn without a label
• If k > 1 a directed arc is drawn with label k.
• If k = 0 no arc is drawn.
(c) M. Rauterberg, TU/e
15
PN: Firing Rules for Transitions
• A specific transition ti is said to be enabled if each input
place pi is marked with at least w(pi,ti) tokens where
w(pi,ti) is the weight of the arc from pi to ti.
• An enabled transition may or may not fire depending on
whether or not the event actually takes place .
• The firing of an enabled transition ti removes w(pi,ti)
tokens from each input place pi of ti, and adds w(pj,ti)
tokens to each output place pj of ti where w(pi,ti) is the
weight of the arc from input place pi to ti, and w(pj,ti) is
the weight of the arc from ti to output place pj
(c) M. Rauterberg, TU/e
16
PN: Change of States (1)
• is denoted by a movement of token(s)
(black dots) from place(s) to place(s);
and is caused by the firing of a
transition.
• The firing represents an occurrence of
the event or an action taken.
• The firing is subject to the input
conditions, denoted by token
availability.
(c) M. Rauterberg, TU/e
17
PN: Change of States (2)
• A transition is firable or enabled when
there are sufficient tokens in its input
places.
• After firing, tokens will be transferred
from the input places (old state) to the
output places, denoting the new state.
• Note that the examples are Petri nets
representation of a finite state machine (FSM).
PNs are much more powerful to model
systems beyond FSMs.
(c) M. Rauterberg, TU/e
18
PN: basic modeling (1)
t1
t1
t2
(b) Conflict
t3
t1
t2
t3
t2
© Concurrency
(a) Sequencetial execution
(c) M. Rauterberg, TU/e
19
PN: basic modeling (2)
t1
t2
t3
t1
t4
(d) Synchronation
(c) M. Rauterberg, TU/e
(e) Merging
20
PN: basic modeling (3)
t1
(f) Confusion
(c) M. Rauterberg, TU/e
t2
t3
t1
t2
(g) Priorites
21
PN Example: Font Selection
Bold on
Italic on
User presses
italic
T1
T2
User presses
bold
T3
T4
User presses
italic
Bold off
(c) M. Rauterberg, TU/e
22
PN Example: a finite-state machine (1)
Consider a vending machine
• It accepts either nickels or dimes
• Sells 15c or 20c candy bars
• The vending machine can hold up to 20c
• Coin return transitions are omitted
the next slides are the state diagram of this
vending machine which represented by the Petri net
Any finite-state machine (or its state diagram) can be
modeled with a state machine.
(c) M. Rauterberg, TU/e
23
PN Example: a finite-state machine (2)
Get 15c candy
Deposit 5c
5c
Deposit 10c
15c
Deposit 5c
Deposit 5c
0c
p1
Deposit 5c
Deposit 10c
10c
Deposit10c
20c
Get 20c candy
(c) M. Rauterberg, TU/e
24
What is GOMS?
•
•
•
•
A family of user interface modeling techniques
Goals, Operators, Methods, and Selection rules
Input: detailed description of UI and task(s)
Output: various qualitative and quantitative
measures
• Usefully approximations possible
• Based on Model Human Processor
(c) M. Rauterberg, TU/e
25
Members of GOMS Family
• Keystroke-Level Model (KLM) [see Card, Moran, Newell (1983)]
• Natural GOMS Language (NGOMSL) [see Kieras (1988+)]
• Critical Path Method or
Cognitive, Perceptual, and Motor GOMS
(CPM-GOMS)
[see John (1990+)]
(c) M. Rauterberg, TU/e
26
What GOMS can model
• Task must be goal-directed
– Some activities are more goal-directed than
others
– Even creative activities contain goaldirected tasks
• Task must a routine cognitive skill - as
opposed to problem solving as in
Cognitive Walkthrough
• Serial and parallel tasks
(c) M. Rauterberg, TU/e
27
GOMS Output
• Functionality coverage and consistency
– Does User-Interface contain needed
functions?
– Are similar tasks performed similarly?
(NGOMSL only?)
• Operator sequence
– In what order are individual operations
done?
– Abstraction of operations may vary among
models
(c) M. Rauterberg, TU/e
28
GOMS Output (cont’d)
• Execution time
– By expert
– Very good rank ordering
– Absolute accuracy ~10-20%
• Procedure learning time (NGOMSL only)
– Accurate for relative comparison only
– Does not include time for learning domain
knowledge
• Error recovery
(c) M. Rauterberg, TU/e
29
Applications of GOMS
•
•
•
•
Compare User-Interface designs
Profiling
Sensitivity and parametric analysis
Building a help system
– GOMS modeling makes user tasks and goals
explicit
– Can suggest questions users will ask and the
answers
(c) M. Rauterberg, TU/e
30
Other GOMS techniques
• NGOMSL
– Regularized level of detail
– Formal syntax, so computer interpretable
– Gives learning times
• CPM-GOMS
– Closer to level of Model Human Processor
– Much more time consuming to generate
– Can model parallel activities
(c) M. Rauterberg, TU/e
31
GOMS Approach
Goals are what the user wants to achieve
Operators are basic actions user performs
Methods: decomposition of a goal into subgoals/operators
Selection means of choosing between competing methods
(c) M. Rauterberg, TU/e
32
Concept: Goals
• Something the user wants to achieve
• Examples?
– go to airport
– delete File
– create directory
• Hierarchical structure
– may require many subgoals
(c) M. Rauterberg, TU/e
33
Concept: Methods
• Sequence of steps to accomplish a goal
– goal decomposition
– can include other goals
• Assumes method is learned & routine
• Examples
– drag file to trash
– retrieve from long-term memory command
(c) M. Rauterberg, TU/e
34
Concept: Operators
• Specific actions (small scale or atomic)
• Lowest level of analysis
– can associate with times
• Examples
–
–
–
–
–
Locate icon for item on screen
Move cursor to item
Hold mouse button down
Locate destination icon
User reads the dialog box
(c) M. Rauterberg, TU/e
35
Concept: Selection Rules
• If [more than one method to accomplish a
goal] (Selection rules) pick (method to
use)
• Examples
– IF <condition> THEN accomplish <GOAL>
– IF <car has automatic transmission> THEN
<select drive>
– IF <car has manual transmission> THEN
<find
car with automatic transmission>
(c) M. Rauterberg, TU/e
36
Operators vs. Methods
• Operator: the most primitive action
• Method: requires several Operators or
subgoal invocations to accomplish
• Level of detail determined by
– KLM level - key press, mouse press
– Higher level - select-Close-from-File-menu
– Different parts of model can be at different
levels of detail
(c) M. Rauterberg, TU/e
37
GOMS description How to Use GOMS
• Generate task description
– pick high-level user Goal
– write Method for accomplishing Goal - may invoke
subgoals
– write Methods for subgoals
• this is recursive
• stops when Operators are reached
• Evaluate description of task
• Apply results to User-Interface
• Iterate!
(c) M. Rauterberg, TU/e
38
GOMS Example 1: PDA Text Entry
• goal: enter-text-Newton
– move-pen-to-text-start
– goal: enter-word-Newton ...repeat until no more
words
• write-letter ...repeat until no more letters
• [select: goal: correct-misrecognized-word]
...if incorrect
• expansion of correct-misrecognized-word goal
– move-pen-to-incorrect-letter
– write-letter
(c) M. Rauterberg, TU/e
39
GOMS Example 2: Iconise Window
GOAL: ICONISE-WINDOW
.
[select GOAL: USE-CLOSE-METHOD
.
MOVE-MOUSE-TO-WINDOW-HEADER
.
POP-UP-MENU
.
CLICK-OVER-CLOSE-OPTION
GOAL: USE-L7-METHOD
.
PRESS-L7-KEY]
For a particular user:
Rule 1: Select USE-CLOSE-METHOD unless another rule
applies
Rule 2: If the application is GAME, select L7-METHOD
(c) M. Rauterberg, TU/e
40
GOMS & KLM Example 2 (cont’d)
Six execution phase operators
Physical motor
K - key stroking
P - pointing
H - homing
B - button pressing
Mental
M - mental preparation
System
R - response
Times are empirically determined (T=Task).
T_execute = T_K + T_P + T_H + T_B + T_M + T_R
(c) M. Rauterberg, TU/e
41
GOMS & KLM Example 2 (cont’d)
assume hand starts on mouse
USE-L7-METHOD
USE-CLOSE-METHOD
H[to keyboard] 0.40
P[to menu]
M
1.35
B[LEFT down] 0.1
K[L7 key]
0.28
M
1.35
P[to option]
1.1
B[LEFT up]
0.1
Total
(c) M. Rauterberg, TU/e
2.03 secs
Total
1.1
3.75 secs
42
GOMS Example 3: Graph Drawer
• goal: draw-graph
– goal: draw-node ...repeat until no more nodes
• goal: draw-circle
– draw-circle-gesture
– goal: verify-circle-gesture
• [select: goal: correct-gesture] ...if
misrecognized or drawn incorrectly
– goal: connect-node ...repeat until no more
connections
• draw-line-gesture
• move-pen-to-node-just-drawn
– goal: name-node
• make-naming-gesture
• goal:enter-text
(c) M. Rauterberg, TU/e
43
GOMS Example 3 (cont’d)
• expansion of correct-gesture goal
– move-pen-to-undo-button
– tap-undo-button
• goal: copy-node
– move-pen-to-node
– draw-copy-gesture
– drag-pen-to-destination
(c) M. Rauterberg, TU/e
44
GOMS Example 4: Editing
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
(c) M. Rauterberg, TU/e
45
GOMS Example 5: DOS File Delete
• Goal: Delete a File
• Method for accomplishing goal of deleting a file
– retrieve from Long term memory that command
verb is “del”
– think of directory name & file name and make it
the first listed parameter
– accomplish goal of entering & executing command
– return with goal accomplished
(c) M. Rauterberg, TU/e
46
GOMS Example 6: Mac File Delete
• Goal: Delete a File
• Method for accomplishing goal of deleting a file
– find file icon
– accomplish goal of dragging file to trash
– Return with goal accomplished
(c) M. Rauterberg, TU/e
47
Advantages of GOMS
•
•
•
•
•
Gives qualitative & quantitative measures
Model explains the results
Less work than user study – no users!
Easy to modify when UI is revised
Research: tools to aid modeling process
since it can still be tedious
(c) M. Rauterberg, TU/e
48
Disadvantages of GOMS
•
•
•
•
Not as easy as HE, guidelines, etc.
Takes lots of time, skill, & effort
Only works for goal-directed tasks
Assumes tasks performed by experts
without error
• Does not address several UI issues,
– readability, memorizability of icons, commands
(c) M. Rauterberg, TU/e
49
User Action Notation (UAN)
•
•
•
•
•
Developed by Hix and Hartson
Further refined by Hartson and Gray
Is neutral about the user and interface technology
Aims to show how tasks match computer devices
Elements
– Symbols and operators
– Conditions and options
– Tables of user action, feedback and system
action/state
– Temporal relations and constraints
(c) M. Rauterberg, TU/e
50
UAN: Symbols and Operators
• Existing UAN uses special characters for mouse movement
and button actions
[remark: in this introduction text notation will be used]
• Example operators
– move_mouse(x,y)*
– release_button(x’,y’)
– highlight(icon)
– de_highlight(icon)
– file = select()
(c) M. Rauterberg, TU/e
51
UAN: Conditions and Options
• while (condition) TASK
• if (condition) then TASK
• iteration A* or A+
• waiting can be an operation on a task
(c) M. Rauterberg, TU/e
52
UAN: Tables
• Three columned table
USER ACTION
clicking mouse
entering text
moving mouse
(c) M. Rauterberg, TU/e
FEEDBACK
highlighting object
echo characters
show icon moving
SYSTEM STATE
selecting file
setting string
NULL
53
UAN: Temporal relations
• strict sequence
A,B
• B follows completion of A
• Order independence
A&B
• A and B can be done in any order
• Concurrence with
A|| B
• A and B are done simultaneously
• Interruptible by
A->B
• A can interrupt B
• Interleavable
A<|>B
• Swapping between A and B
(c) M. Rauterberg, TU/e
54
Move object from front to back
(c) M. Rauterberg, TU/e
55
UAN for moving object to back
select_object, choose_bring_to_back
USER ACTION
click(x,y)
FEEDBACK
then
highlight_object
send_to_back_item
move_to_back
move_object_in_list
SYSTEM STATE
if intersect_object
object=selected
send_to_back_item is a separate UAN task for standard menu
item selection
Note: object is still highlighted and selected at end of task
(c) M. Rauterberg, TU/e
56
UAN: Example 1
• drag and drop a file in the recycling bin
(partial
example)
USER ACTION
FEEDBACK
SYSTEM STATE
mouse_down(x,y)
drag_icon(x,y)*
if intersect(icon,x,y)
icon = selected
then highlight(icon)
show_outline(icon)
if intersect(bin,x,y)
then hightlight(bin)
mouse_up(x’,y’)
if intersect(bin,x’,y’)
then hide(icon)
show_bin_full()
(c) M. Rauterberg, TU/e
57
UAN: Example 1a
• That was only a partial example:
• Amend it to show what happens if the mouse is released
without the icon over the bin
• Generalize the example to drag an icon over any object,
e.g.
• Bin
• Folder
• Application
(Hint: will need to use conditions )
(c) M. Rauterberg, TU/e
58
UAN: Example 1b
USER ACTION
FEEDBACK
mouse_down(x,y)
drag_icon(x,y)*
SYSTEM STATE
if intersect(object,x,y)
object = selected
then highlight(object)
show_outline(object)
if intersect(target,x,y)
then highlight(target)
mouse_up(x’,y’)
if intersect(target ,x’,y’)
then hide(object)
intersect_action(target)
else draw(object)
Generic drag and drop interaction: action depends on target
(c) M. Rauterberg, TU/e
59
UAN: Example 2
• Clicking on a URL with temporal
constraints
USER ACTION
FEEDBACK
SYSTEM STATE
mouse_down(x,y)
if intersect(URL,x,y)
then colour(link)
mouse_up(x,y)
fetch(URL)
if intersect(URL,x,y)
URL = visited
What if after mouse_up() I click on another URL?
Two choices
A, B Must complete the first selection before making another
or
A <- B Can interrupt the first task by the second
(c) M. Rauterberg, TU/e
60
Optional Exercises (1)
1. Give the UAN description of choosing an item from a
hierarchical, pop-up menu like the Windows 95 ‘Start’
menu. Include the description of what occurs when a
menu item is not selected.
2. Give UAN descriptions of drawing operations in a tool like
PowerPoint. Example operations include:
• drawing a line
• drawing circle and ellipse
• drawing a multi-segment line
• Moving part of a grouped object to the front
(c) M. Rauterberg, TU/e
61
Optional Exercises (2)
3.In a computer tank game describe the steps needed to
maneuver towards a moving target and shoot at it.
Assume a combination of mouse and keyboard keys can
be used.
[You may need to break this down into several tasks and
combine them]
4. Describe the steps needed to land an aircraft in a flight
simulator game. You may need temporal relations to
check actions such as landing gear, speed, rate of descent
are correct before landing.
5. Choose an interaction sequence you have had problems
with and describe and analyze the problem in UAN
(c) M. Rauterberg, TU/e
62