brugergrænseflader til apparater brga presentation 4: guidelines & heuristics
TRANSCRIPT
Brugergrænseflader til apparater BRGA
Presentation 4:
Guidelines & Heuristics
2
Outline
• Recap Until Now• Cognitive HCI & Methods that we employ
• Cognitive Walkthrough
• Methods vs. Guidelines & Heuristics• Types of Guidelines & Heuristics• Nielsen’s 9 (10) Heuristics and How to use• Other Guidelines • Patterns of Usability• Method: Heuristic Evaluation
3
Until Now
• Cognitive HCI & Human Capabilities• The Human Mind as an information processor•The Human Body as input/output•Hard Science•Predictions/Calculations
• GOMS/KLA/Fitts Law•Methods for analysis
• Expert review• Designers: CW
•Today• Distilled experiences: Guidelines &
Heuristics + Heuristic Evaluation
Today: Usability Heuristics
Avoid common design pitfalls by following design principles: guidelines & heuristics
Inspect an interface for usability problems with these principles (Heuristic evaluation)
Design principles
Broad usability statements that guide a developer’s design efforts
• use the users language• provide feedback…
Derived from common design problems across many systems and many researchers and developers experiences = Patterns of Usability
6
Available guidelines
• General guidelines• Shneiderman’s 8 Golden Rules of Interface Design• Nielsen’s 9 principles of design• Normans 4 principles of good design• Molich’s 5 guidelines for screen dialogs• MANY OTHERS – look for yourselves at ACM and Cite Seer
• Area specific guidelines• Agricultural• Mobile / Office Workers• Leisure activities (designing for the home)
• Technology/Platform specific guidelines• Windows (Microsoft guidelines), MS SmartPhone, Tablet PC,
Apple, Nokia WAP Guidelines, ELO Touchscreen
7
Usability Patterns
• Usability Patterns are emerging • Relates to many of the same issues• Has design scope – not review• We will look at some later
8
General Guidelines & Heuristics
• Guidelines = Heuristics = Experiences
• We will be looking at Nielsen’s 9 guidelines next
• Guidelines are easy to understand, so I will not spend time introducing you to them in detail – please read
• Remember: be critical
9
Usability Engineering – Jakob Nielsen
Nine principles of design1. Simple and natural dialog2. Speak the user’s language3. Minimize user’s memory load4. Be consistent5. Provide feedback6. Provide clearly marked exits7. Provide shortcuts8. Deal with errors in a positive manner9. Provide help
(+ Prevent Errors in BRGA-1)
Heuristic Evaluation
Fairly coarse grained model
1. Simple and natural dialogue
• use the user’s conceptual model
• match the users’ task sequence
• minimize mapping between interface and task semantics
From Microsoft applications
Only display what isUseful for the current task
11
1. Simple and natural dialogue
Present exactly the information the user needs• less is more
• less to learn, to get wrong, to distract...• information should appear in natural order
• related information is graphically clustered• order of accessing information matches user’s
expectations• remove or hide irrelevant or rarely needed
information• competes with important information on
screen• remove modes Redesigned from 5
clicks to 1 + more natural mapping.
All daily tasks were mapped to main screen
12
1. Simple and natural dialogue
• Microsoft Inductive User Interface Guidelines
• Deductive• Deduce: to conclude by reasoning
The user must deduce from interface “What do I have to do here?”
• Bad user mental model support
• Inductive• Induce: to lead or move by influence or
persuasion • Split dialogs into simple task atomic
units that only have one purpose• Less is more principle
13
My program gave me the message Rstrd
Info.What does it mean?
That’s restricted
informationBut surely you can tell me!!!
No, no… Rsdrd Info stands for “Restricted
Information”
Hmm… but what does it mean???
It means the program is too busy
to let you log on
Ok, I’ll take a coffee
2. Speak the users’ language
2. Speak the users’ language
Terminology based on users’ language for task• e.g. withdrawing money from a bank machine
Use meaningful mnemonics, icons & abbreviations• eg File / Save
• Ctrl + S (abbreviation)
• Alt FS (mnemonic for menu action)
• (tooltip icon)
15
2. Speak the users’ language
• Glossary: UK English -> US English -> DK English • Use Mappings and Metaphors
• Between users conceptual model and the information appliances’ display
• > may be achieved by understanding the users work domain and jargon (e.g. through field studies & interviews)
• Draw on the users ”non-technical” knowledge by using metaphors e.g. ”trash can” for removing files
• Problem: metaphors may deceive the users (the trash can does NOT completely remove the file from disk)
• “Upcomming Bills” -> “Pick the Bill you would like to pay”
3. Minimize user’s memory load
Computers good at remembering, people are not!
Promote recognition over recall• menus, icons, choice dialog boxes vs commands, field
formats, support data entry best possible to reduce errors
• relies on visibility of objects to the user (but less is more!)
From Microsoft applications
17
3. Minimize user’s memory load
Cognitive Overload
4. Be consistent
Consistency -> confident users -> explanatory learningConsistent syntax of input (within MS Windows, application, and the dialog)
Consistent language and graphics• same visual appearance across the system (e.g. widgets)
• same information/controls in same location on all windows
• Microsoft IUI: Use Templates
Consistent effects• commands, actions have same effect in equivalent situations
• predictability, reliability
Ok Cancel OkCancel Accept Dismiss
Cancel
Ok
19
4. Be Consistent
• Beware of conventions learned with other products might become a problem:
Where to expect the power button?
5. Provide feedback
Continuously inform the user about • what the system is doing• how it is interpreting the user’s input• user should always be aware of what is going on
> Doit
What’s it doing?
> DoitThis will take5 minutes...
Time for coffee.
Support the users mental model of the system state
21
5. Provide feedback
What did I select?
What mode am I in now?
How is the system
interpreting my actions?
Microsoft Paint
22
5. Provide feedback
• Provide constant feedback• Also provide partial information
• While throwing coins into the vending machine, update for each coin
• When a problem occurs – light the display, and turn it off again as soon as the problem is resolved
• Support Mental Model of Users at all times
23
5. Provide feedback
Be as specific as possible, based on user’s input
Best within the context of the action – context supportsgood mapping of system image and mental model
24
5. Provide feedback
Response time
- how users perceive delays:
< 0.1 s perceived as “instantaneous”
1 s user’s flow of thought stays uninterrupted, but delay noticed
10 s limit for keeping user’s attention
focused on the dialog
> 10 s user will want to perform
other tasks while waiting
Dealing with long delays – use “action symbols”
• Cursors• for short transactions• typically < 10s
• Percent done dialogs• time left• estimated time
• In case of no clue?• tell the user
5. Provide feedback
How do I get
out of this?
6. Provide clearly marked exits
6. Provide clearly marked exits
Users don’t like to feel trapped by the computer!• should offer an easy way out of as many situations as possible
Strategies:• Cancel button (for dialogs waiting for user input)
• Universal Undo (can get back to previous state)
• Interrupt (especially for lengthy operations)
• Quit (for leaving the program at any time)
• Defaults (for restoring a property sheet)
• BE CONSISTENT
• Dangerous with limited undo
Core Dump
7. Provide shortcuts
Experienced users - perform frequent operations quickly
Strategies:• keyboard and mouse accelerators
• abbreviations• command completion• context menus• function keys• double clicking vs menu selection
• navigation jumps • e.g., going to window/location directly, and avoiding
intermediate nodes• history systems
• www: ~60% of pages are revisits
29
Keyboard accelerators for
menus
Customizable toolbars andpalettes for
frequent actions
Split menu, with recently used fonts on top
Scrolling controls for page-sized
increments
Double-click raises object-specific menu
Double-click raises toolbar
dialog box
Support multiple accelerator technologies
8. Deal with errors in a positive manner
Errare humanum est - People will make errors!
Errors we make:• Mistakes
• conscious deliberations lead to an error instead of correct solution – often because of bad UI mappings
• Slips
• unconscious behaviour gets misdirected en route to satisfying goal
– e.g. drive to store, end up in the office, juice in bowl– usually due to inattention, interruptions– often arises from similar actions (deleting inbox instead of
draft)
Designing for slips
General rules• prevent slips before they occur
• detect and correct slips when they do occur
• user correction through feedback and undo
• support the mental model of the user
• context should be kept clear
• avoid modes
I can’t believe I pressed Yes...
A problematic message to a nuclear power plant operator
8. Deal with errors in a positive manner
33
Adobe's ImageReady
AutoCAD Mechanical
Windows NotepadMicrosoft's NT Operating System
8. Deal with errors in a positive manner
Provide meaningful error messages• error messages should be in the user’s task language
• don’t make people feel stupid – help them1. “Error 25”
2. “Cannot open this document”
3. “Cannot open “chapter 5” because the application “Microsoft Word” is not on your system”
4. “Cannot open “chapter 5” because the application “Microsoft Word” is not on your system. Open it with “WordPad” instead?”
8. Deal with errorsin a positive manner
8. Deal with errors in a positive manner
Prevent errors• try to make errors impossible
• modern widgets: can only enter legal data
Provide reasonableness checks on input data• on entering order for office supplies
• 5000 pencils is an unusually large order. Do you really want to order that many?
User Interface PatternsForgiving FormatInput Hint
9. Provide help
Help is not a replacement for bad design!
Simple systems:• walk up and use; minimal instructions
Most other systems• feature rich
• simple things should be simple
• learning path for advanced featuresVolume 37: A user's guide to...
Documentation and how it is used
Many users do not read manuals• prefer to spend their time pursuing their task
Usually used when users are in some kind of panic• paper manuals unavailable in many businesses
• online documentation better
• good search/lookup tools
• online help specific to current context
Sometimes used for quick reference• syntax of actions, possibilities...
• list of shortcuts ...
Volume 37: A user's guide to...
38
Excercise (5 min.)
• Each student gets 1 heuristic• Find good examples (2 min.)• Plenum
39
Top 10 Usability Guidelines for WAP
1. Implement navigational menus using a <select> elements2. Keep soft key labels to 5 characters or less.3. Use Wizards instead of forms4. Keep the content that appears above select and input fields to 1 or 2
lines max (including images).5. Assign the most commonly chosen action or most intuitive task
to the accept soft key6. Don't use the <go> task to navigate to a card that is already on the
history stack7. Allow the user to dial phone calls from the application by pressing a
single key8. Use the format attribute to constrain text input fields to only
allow valid character types9. Don't set a deck's expiration (maxage) to a low value unless the
content is highly volatile10. Ensure all decks are smaller than 500 bytes
40
Design Guidelines for Windows• Excerpts from Microsoft on “Visual Design”:
• http://msdn2.microsoft.com/en-us/library/ms997613.aspx• Color:
• Some percentage of the population may have color-identification problems. This can affect the accessibility of your software to the widest possible audience. For example, about 9 percent of the adult male population have some form of color confusion.
• Access Keys:• Always define an access key for the label of any control or
menu item. The only exceptions are the OK and Cancel buttons because the ENTER and ESC keys typically serve as the access keys to these buttons. Also, avoid having the same access key used by more than one control in a single context or more than one item on the same menu.
• Animation:• Avoid gratuitous use of animation. When animation is used only
for a decorative effect, it can distract or annoy the user. To use animation most effectively, use it for a specific purpose or condition. Avoid repeating the animation unless the condition persists or reoccurs. You should provide the user with the option of turning off the animation or otherwise customizing the animation effects.
41
Pocket PC Guidelines• Pocket PC User Interface Guidelines Excerpts
• http://msdn2.microsoft.com/en-us/library/ms854763.aspx• Usability:
• Use the following checklist to confirm that an application user interface meets basic usability requirements:
• Dialog boxes do not contain irrelevant information because it diminishes the visibility of relevant information.
• Information appears in a logical order in the dialog box based on the functionality provided. The information is communicated using words and concepts that are familiar to a user.
• Instructions for using an application are visible or easily accessible whenever appropriate. Avoid complicated instructions.
• When appropriate, the same user action is consistently used to complete the same application operation.
• Appropriate feedback is provided to a user within a reasonable time. • Shortcuts for experienced users are provided for completing tasks.
• Tabs• On Windows Mobile-based Pocket PCs, use tabs in an application to group related information
and functionality. Consider the following when you include tabs in an application: • So that the user does not need to scroll to view the tabs, avoid creating more tabs than can fit on
the screen at one time. • So that the user does not need to scroll to view the controls, ensure that all of the edit controls are
visible on a property sheet when the input panel is displayed. • To keep the content area uncluttered at the top of the screen, place tabs at the bottom of the
screen. • Label Attributes• Use the 8pt, Tahoma black font
42
Touchscreen Guidelines
• Excerpts from www.elotouch.com• Use a Simple Point-and-Click Interface• Large buttons
• rule of Thumb-sized buttons
• No double-clicking• No pull-down menus• No scrolling or scroll bars• No dragging• Turn the Cursor Off• Many more …
43
Touchscreen Guidelines
• Excerpts from SAPDesignGuilds guidelines http://www.sapdesignguild.org/resources/TSDesignGL/Index.htm
• Gestures• Simple gestures, that are easy to remember, can be used on
stylus-operated touchscreens for often-used functions. Gestures are simple "drawings" like letters or symbols. Here are a few examples:
• Deleting items by striking them through or crossing them out (the Apple Newton used a "W" for this operation.
• Marking items by adding a cross ("X") or "Ã". • Identifying a user by his or her signature (handwriting). • Gestures are not well suited to finger-operated
touchscreens, as the use drag operations with fingers are not recommended in the literature.
PDF: http://www.sapdesignguild.org/resources/TSDesignGL/TSDesignGL.pdf
Heuristic Evaluation
Systematic inspection to see if interface complies to guidelines (could be these 9 – and/or others)
Method• 3-5 inspectors• usability engineers, end-users, double experts…• inspect interface in isolation• ~1–2 hours for simple interfaces• compare notes afterwards
• single evaluator only catches ~35%• of usability problems• 5 evaluators catch 75% (nielsen)
Works for paper, hi-fi prototypes, and working systems
45
Heuristic Evaluation Method
Breifing session• Which interfaces & tasks to evaluate• Usage scenario• Which Heuristics to use
Evaluation period• Each evaluator is on his own for 1-2 hours• Two passes of checks using the heuristics• Record all problems
Debriefing session• Evaluators come together to discuss findings, prioritize the
problems and suggest solutions
Heuristic Evaluation
Advantages:• “minimalist” approach
• a few guidelines identify many common usability problems• easily remembered, easily applied with modest effort
• discount usability engineering / Gurillia HCI• end users not required• cheap and fast way to inspect a system – or even mock-up• can be done by usability experts, double experts, and end users
Problems:• can’t be treated as a simple checklist• subtleties involved in their use• evaluators might not understand the domain• for every 1 problem found, 1 false alarm and ½ is missed (preece et al.)