Friday, February 25

1  Prototypes and Walkthrough Scenarios Due Today  Heuristic Evaluation  A Little More Design  Universal Access postponed  HCI Theory and Practice  Looking Ahead SEng 5115 February 25, 2004

2 Prototypes and Walkthrough Scenarios  What are we looking for?

 appropriate level of detail • • to perform walkthrough to perform heuristic eval  thought and attention SEng 5115 February 25, 2004

3 Heuristic Evaluation  Guidelines, rules of thumb  Task-free -- applied to entire interface  Nielsen and Molich  nine heuristics (more or less)  procedure for using them SEng 5115 February 25, 2004

4 The Procedure  Several independent evaluators  each uses the same checklist  each works alone  each makes a list of usability problems  Combine lists into a single list  works well as a group activity SEng 5115 February 25, 2004

Heuristics 1.0 – circa 1990

6 Simple and Natural Dialog  no irrelevant or rarely relevant information  order of dialog matches tasks  good graphic design and use of color  grouping and proximity  “Less is more” SEng 5115 February 25, 2004

7 Speak the User’s Language  words and concepts from user’s world  don’t use system-specific engineering terms  focus on user’s point of view  mappings and metaphors SEng 5115 February 25, 2004

8 Minimize User Memory Load  show range or sample inputs  use generic actions across application  don’t make user remember things between actions  leave information on screen until not needed SEng 5115 February 25, 2004

Be Consistent 9  same information in same location  consistency with user model  consistency with task  consistency with experience  consistency within application  same action sequence for similar results across application SEng 5115 February 25, 2004

Provide Feedback  users should see the effect of their actions on the system  “restate and rephrase user’s input”  phrase using user’s terms and specific data  response times  0.1, 1.0, 10  “reassurance” displays SEng 5115 February 25, 2004 10

11 Provide Clearly Marked Exits  if users go someplace that doesn’t interest them, they should be able to get back quickly and gracefully  support exploration  support undo consistently  support interruption of long-lived events SEng 5115 February 25, 2004

Provide Shortcuts  help experienced users avoid long dialogs or messages that they don’t need  type- and click-ahead  keyboard shortcuts  good default values  macros and scripting  reuse/edit history  example: Framemaker “books” SEng 5115 February 25, 2004 12

Provide Good Error Messages  clear and in simple language  need obscure details, dig deeper  specific problem, specific advice  lead towards solution  non-accusatory, supportive  helps user solve problem

and

encourages exploration  graceful error behavior SEng 5115 February 25, 2004 13

14 Prevent Errors  every error message should be scrutinized--can the error be prevented?

 recall vs. identify  confirmation  modes  cognitive overlap SEng 5115 February 25, 2004

15 Help and Documentation  outside primary scope of this course  understand uses of manual  tasks, scenarios  context, environment  design and test documentation/help  value for specific tasks SEng 5115 February 25, 2004

Heuristics 2.0 – circa 1994

17 Visibility of system status  The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. SEng 5115 February 25, 2004

18 Match between system and the real world  The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. SEng 5115 February 25, 2004

19 User control and freedom  Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. SEng 5115 February 25, 2004

20 Consistency and standards  Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. SEng 5115 February 25, 2004

21 Error prevention  Even better than good error messages is a careful design which prevents a problem from occurring in the first place. SEng 5115 February 25, 2004

22 Recognition rather than recall  Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. SEng 5115 February 25, 2004

23 Flexibility and efficiency of use  Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. SEng 5115 February 25, 2004

24 Aesthetic and minimalist design  Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. SEng 5115 February 25, 2004

25 Help users recognize, diagnose, and recover from errors  Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. SEng 5115 February 25, 2004

26 Help and documentation  Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. SEng 5115 February 25, 2004

27 Exercise: Heuristic Evaluation  Work in teams of two half-groups  Don’t have both halves work with same group  We will diversify perspectives  Each team should show prototype  describe project  step through an example  try to limit to 5-7 minutes each SEng 5115 February 25, 2004

28 Exercise, continued  Count off in the group to find starting heuristics (from the 1994 set)  1, 3, 5, 7, 9, 1, etc.

 Each person spends 7-10 minutes, focusing on 2-3 heuristics  move forward if yours don’t apply well  Jot down any problems you find  remember how you found them SEng 5115 February 25, 2004

Exercise, continued  Each person should report problems found  One person from the project group should organize the problems  Then, move to the second project and repeat  Finally, be prepared to discuss the experience you had SEng 5115 February 25, 2004 29

Discussion on Heuristic Evaluation

31 A Bit More on Design  Initiative  A few common paradigms  The books of Tufte SEng 5115 February 25, 2004

Initiative  System-driven interfaces  Forms with responses  Presented menus  User-driven interfaces  Many parallel alternative actions  Typically event-driven  Mixed-initiative interfaces  Agent models … SEng 5115 February 25, 2004 32

33 Paradigms  Editors  Virtual stores  Control panels  … SEng 5115 February 25, 2004

34 Tufte 

The Visual Display of Quantitative Information

(1983) 

Visual Explanations

(1990) 

Envisioning Information

(1997) SEng 5115 February 25, 2004

35 HCI Theory and Practice  What is Theory?

 Example Theories  Applications  How it is Generated SEng 5115 February 25, 2004

What is Theory?

 Research results digested into a generalized and understandable form  We hope applicable to problems 36 SEng 5115 February 25, 2004

37 Example Theories  Model Human Processor  Activity Theory  Information Foraging  Norman’s Model of Human Action  … SEng 5115 February 25, 2004

38 Model Human Processor  From Card, Moran, and Newell  Basis behind formal action analysis  Reduces human information processing to basic perceptual and cognitive elements  Does not address social behaviors SEng 5115 February 25, 2004

39 Activity Theory  From the work of Vygotsky  Object-orientedness  Internalization/Externalization  Tool mediation  Hierarchical structure  Development SEng 5115 February 25, 2004

40 Information Foraging Theory  Pirolli, Card, and others  Human attention to cost as well as value of information  Cues such as “information scent”  Optimal foraging SEng 5115 February 25, 2004

41 Applications  Positive View  Saves time and mistakes  Negative View  Public library  Toothbrush SEng 5115 February 25, 2004

42 How theory is Generated  Start with some insight/model  Gather data to support/develop  Generalize and test  Operationalize through tools and techniques SEng 5115 February 25, 2004

Looking Ahead  Saturday, March 5  Testing designs on users • Usability testing • Logging  Friday, March 11  In usability laboratory  4 brief usability studies • • Real-world cases (bettycrocker.com) Volunteers will be sought SEng 5115 February 25, 2004 43

44 Looking Ahead  Walkthrough results due  “raw” notes • notes from each step of walkthrough • for cases where issues are raised, note likely frequency of problem: • always, often, sometimes, rarely, never • • copy of prototype used, markups copy of scenarios used (note changes or fixes)  processed results • 1-2 pages of issues identified • solutions not needed, those come later • indicate approximate severity (high, med, low) SEng 5115 February 25, 2004