What Did You Learn Last Week

1
What Did You Learn Last Week?

• Why "establish" requirements, as opposed to, say,
  "acquire" requirements?
• Why is it so important to get the requirements
  right?
• What is the difference between functional,
  usability, and user experience requirements?
• Why would one choose to use an interview instead
  of a questionnaire, and vice versa?
• What is a contextual inquiry?

2
Lecture 7 Task Interface Representations
(Preece 10.6-10.7 11)
3
Special Research Activity Reminder

• From Feb. 20 through Feb. 29, you will
  participate in a required research activity
  outside of class (worth 2 of your course grade
  participation in associated research study is
  optional)
• We already scheduled you for a 90 min. slot if
  you havent been scheduled, please talk to me
  after class
• Sessions start TOMORROW, and take place in EME
  228 (VEUPL)

4
Note!

• User Action Notation material based on
• Hix, D., Hartson, H.R. (1993). Developing
  User Interfaces Ensuring Usability Through
  Product and Process. New York Wiley, pp.
  152- 182.

5
Lecture Overview

• Part I Task Descriptions
• Part II State Transition Networks
• Part III User Action Notation

6
Part ITask Descriptions
7
Overview of Task Descriptions

• Scenarios
• An informal narrative story, simple, natural,
  personal, not generalizable
• Use cases
• Assume interaction with a system
• Assume detailed understanding of the interaction
• Essential use cases
• Abstract away from the details
• Do not have the same assumptions as use cases
• Task Analysis
• Documents existing system or activity
• Step-by-step description of task
• Hierarchical task analysis will be covered here

8
ScenarioShared Calendar
The user types in all the names of the meeting
participants together with some constraints such
as the length of the meeting, roughly when the
meeting needs to take place, and possibly where
it needs to take place. The system then checks
against the individuals calendars and the
central departmental calendar and presents the
user with a series of dates on which everyone is
free at the same time. Then the meeting could be
confirmed and written into peoples calendars.
Some people, though, will want to be asked before
the calendar entry is made. Perhaps the system
could email them automatically and ask that it be
confirmed before it is written in.
9
Use CaseShared Calendar
1. The user chooses the option to arrange a
meeting. 2. The system prompts user for the names
of attendees. 3. The user types in a list of
names. 4. The system checks that the list is
valid. 5. The system prompts the user for meeting
constraints. 6. The user types in meeting
constraints. 7. The system searches the calendars
for a date that satisfies the constraints. 8.
The system displays a list of potential dates. 9.
The user chooses one of the dates. 10. The system
writes the meeting into the calendar. 11. The
system emails all the meeting participants
informing them of them appointment
10
Use CaseShared Calendar (cont.)
Some alternative courses (scenarios) 5. If the
list of people is invalid, 5.1 The system
displays an error message. 5.2 The system
returns to step 2. 8. If no potential dates are
found, 8.1 The system displays a suitable
message. 8.2 The system returns to step 5.
11
Essential Use CaseShared Calendar (Constantine
Lockwood)
arrangeMeeting USER INTENTION SYSTEM
RESPONSIBILITYarrange a meeting
request meeting attendees
constraints identify meeting attendees
constraints search calendars for
suitable dates suggest potential
dateschoose preferred date book meeting
12
You Try It

• Working with your project group, take 5-10
  minutes to develop a key scenario, use case, or
  essential use case that your project software
  must be able to handle.
• If you have time, try to translate your
  description into two or three formats (scenario,
  use case, essential use case)
• Be prepared to share your work with the class

13
Hierarchical Task Analysis

• Involves breaking a task down into subtasks, then
  sub-sub-tasks and so on.
• Each grouping specifies a plan for how a task
  might be performed in practice to achieve goal
• Starting point User goal
• Identify main tasks to achieve that goal
• Subdivide as appropriate

14
Hierarchical Task AnalysisExample
Borrow a book from the library
0
plan 0 do 1-3-4. If book isnt on the shelf
expected, do 2-3-4.
go to the library
find required book
retrieve book from shelf
take book to counter
3
2
1
4
plan 2 do 2.1-2.4-2.5. If book not identified
from information available, do 2.2-2.3-2.4-2.5
access search screen
enter search criteria
identify required book
access catalog
note location
2.1
2.2
2.3
2.4
2.5
15
You Try It

• Working with your project group, take 5 minutes
  to translate the scenario description you just
  developed into a hierarchical task analysis
• Since a hierarchical task analysis required more
  detail, you will need to envision how a user
  would perform the task with your future system
• Be prepared to share your hierarchical task
  analysis with the class

16
Discussion Which Notation Is Best?

• Which notation worked best for you?
• Why?
• What are the advantages and disadvantages of each
  notation?

17
Part IIState Transition Networks
18
State Transition Networks

• Definition A network in which nodes denote
  interface states, and arcs denote user
  interface-level actions that give rise to
  transitions between states
• Options for representing interface states
• Interface screen shots useful when transitions
  have tangible visual effects in the user
  interface, e.g., menus appear
• Labeled interface states useful when transitions
  change interface state without visible effects,
  e.g., when user initiates "mousedown" event on a
  draggable object
• In most cases, STNs contain a mix of the above

19
Representing Transitions

• Transitions must state specific user
  interface-level events, e.g.,
• Mousedown on "Elbow" object
• Click on "Copy" in "File" menu
• Type "enter"
• Note Specify user interface-level events at the
  highest level needed to clearly distinguish a
  transition
• E.g., "Click" instead of "mousedown" followed by
  "mouseup" is sufficient in most cases

20
How to Create an STN

• Focus on tasks, rather than trying to create a
  general STN for entire interface
• For each task, use the STN to specify user
  interface-level actions with which users can
  complete the task
• If appropriate, also include incorrect user
  interface-level actions and what they lead to
• E.g., if the user interface anticipates that
  users will make errors, then include the
  erroneous user interface-level actions and your
  system's response to them

21
STN for Task Create an array of size 5 in ALVIS
Click on Array Tool
Mousdown on Animation Canvas
Move mouse to array tool
Mouse move on Animation Canvas
Mousedown on Animation Canvas
Start
Finish
22
Notes on STNs

• Not all transitions are included, because of the
  space limitations of these slides
• You should create an STN for each task sequence
  in your interface this example just scratches
  the surface of (an old version of) ALVIS
• A more readily understandable design
  representation may well be a working low fidelity
  prototype (which youll create for your design
  doc)

23
Part IIIUser Action NotationNote This
material is based onHix, D., Hartson, H.R.
(1993). Developing User Interfaces Ensuring
Usability Through Product and Process. New York
Wiley, pp. 152- 182.
24
User Action Notation (UAN)

• Origins Developed by Antonio Siochi, H. Rex
  Hartson, and Deborah Hix of Virginia Tech in
  1980s
• Purpose To provide a notation for recording UI
  design that is precise, concise, unambiguous, and
  detailed
• The UAN is intended to be written primarily by
  someone designing the interaction component of an
  interface, and to be read by all developers,
  particularly those designing and implementing the
  user interface (Hix Hartson, 1993, p. 152)

25
Components of the UAN

• User Notation Specifies user actions
• Mouse cursor move
• Precisely describes users interface-level
  actions
• Mouse button up M
• Mouse button down Mv
• Action taken in context of some object ,
  e.g., file icon
• Character input Kcommand, e.g.,
• Khelp
• K(filename) where filename is a variable
• K(user ID A-ZA-Z 0-9) where user ID is a
  variable and what follows it is a regular
  expression
• Note Notation is input device independent!

26
Components of the UAN (cont.)

• More User Notation
• Can use logic notation
• ? for all
• ? not
• equals
• ? not equals
• More object actions
• refers to a specific instance (e.g., file
  icon), to distinguish it from a general variable
  (e.g., file icon)
• itemgt item follows cursor
• item cornergtgt item rubberbands to cursor
• x,y arbitrary number of repetitions
• x,y 1 or more times (can also specify exact
  number)

27
Components of the UAN (cont.)

• Conditions of viability
• Can state specific conditions under which a user
  action is viable by prefacing it with a
  condition
• condition action1 action2 action3

28
Components of the UAN (cont.)

• Feedback Notation Specifies system responses
• Item highlights !, e.g., file icon!
• Item unhighlights -!, e.g., file icon-!
• Interface State Captures system state in terms
  of state variables
• E.g., file iconMv could lead to a state in
  which selected file icon

29
Putting it Together The UAN Table
30
Example UAN for Select File Icon on Windows
Desktop
Stated more succinctly
31
Example Windows Task of Moving a File Icon
32
Note The UAN is Extensible!

• The UAN is a flexible, user-friendly notation
• You are free to make up new functions and
  notation as needed to accommodate the needs of
  your task
• In the previous examples, we defined several
  functions to accommodate our needs
• outline()
• redisplay()
• Lets keep this flexibility in mind as we work
  through more examples

33
Example Creating a New Array of size 5 in ALVIS
34
Example Creating a New Variable in ALVIS
35
Possible Solution Creating a New Array in ALVIS
36
Possible Solution Creating a New Variable in
ALVIS
37
Summary

• Scenarios, use cases, and essential use cases
  provide tools for helping us think and reason
  about the tasks to be supported by software
• Hierarchical task analysis provides a more formal
  means for documenting possible trajectories
  through a task
• State Transition Networks allow us to represent
  user tasks in terms of progressions through
  concrete interface state
• User Action Notation allows us to specify user
  interaction with an interface even more precisely
• WOZ Pro supports quick and easy construction of
  low fidelity user interface prototypes

38
For Thursday

• Download and install the ALVIS 2.1 application
  from
• http//eecs.wsu.edu/veupl/soft
• Download and install WOZ Pro 1.1 application (if
  you have a Tablet PC)
• Make sure you know how to perform screen
  captures I recommend installing SnagIt from
  http//www.techsmith.com