GUI Bloopers Don'ts and Do's for Software Developers and Web Designers |
|
|
|
|
| Jeff Johnson |
| March 2000, Morgan Kaufmann Publishers, Paperback, 584 pages, ISBN 1558605827
|
|
|
|
 |
|
GUI Bloopers looks at user interface design bloopers from commercial
software, Web sites, and information appliances, explaining how intelligent,
well-intentioned professionals made these dreadful mistakes--and how you
can avoid them. While equipping you with all the theory needed to learn
from these examples, GUI expert Jeff Johnson also presents the reality
of interface design in an entertaining, anecdotal, and instructive way.
This is an excellent, well-illustrated resource for anyone whose work
touches on usability issues, including software engineers, Web site designers,
managers of development processes, QA professionals, and usability professionals.
Features
- Takes a learn-by-example approach that teaches you to avoid common
errors by asking the appropriate questions of your own interface designs.
- Includes two complete war stories, drawn from the author's personal
experience, that describe in detail the challenges faced by UI engineers.
- Covers bloopers in a wide range of categories: GUI components, layout
and appearance, text messages, interaction strategies, Web site design,
responsiveness issues, management decision-making, and even more at
www.GUI-bloopers.com.
- Organized and formatted based on the results of its own usability
testing--so you can quickly find the information you need, packaged
in easily digested pieces.
|
 |
|
Acknowledgments
Introduction
Chapter 1--First Principles
Introduction
1.1 Principle 1: Focus on the users and their tasks, not the technology
1.1.1 Understand the users
1.1.2 Understand the tasks
1.1.3 Interactive products and services function in a broad context
1.2 Principle 2: Consider function first, presentation later
1.2.1 What "consider function first" does not mean
1.2.2 What "consider function first" does mean
1.2.3 Develop a conceptual model
1.3 Principle 3: Conform to the users' view of the task
1.3.1 Strive for naturalness
1.3.2 Use the users' vocabulary, not your own
1.3.3 Keep program internals inside the program
1.3.4 Find the correct point on the power/complexity trade-off
1.4 Principle 4: Don't complicate the users' task
1.4.1 Common tasks should be easy 36
1.4.2 Don't give users extra problems to solve
1.5 Principle 5: Promote learning
1.5.1 Think "outside-in," not "inside-out"
1.5.2 Consistency, consistency, consistency, but don't be naive
about it
1.5.3 Provide a low-risk environment
1.6 Principle 6: Deliver information, not just data
1.6.1 Design displays carefully; get professional help
1.6.2 The screen belongs to the user
1.6.3 Preserve display inertia
1.7 Principle 7: Design for responsiveness
1.7.1 Defining responsiveness and the lack thereof
1.7.2 Responsiveness on the Web: A big deal
1.7.3 Summary of responsiveness design principles
1.8 Principle 8: Try it out on users, then fix it!
1.8.1 Test results can surprise even experienced designers
1.8.2 Schedule time to correct problems found by tests
1.8.3 Testing has two goals: Informational and social
1.8.4 There are tests for every time and purpose
Further reading
Chapter 2--GUI Component Bloopers
Introduction
2.1 Complicating access to functionality
2.1.1 Blooper 1: Dynamic menus
2.1.2 Blooper 2: Duplicate menu items
2.1.3 Blooper 3: Hidden functions
2.1.4 Blooper 4: No keyboard equivalents
2.2 Unconventional application windows
2.2.1 Blooper 5: Confusing primary windows with dialog boxes
2.2.2 Blooper 6: Commands are only on toolbar buttons
2.2.3 Blooper 7: All menubar commands are on toolbar
2.3 Misusing choice controls and tabs
2.3.1 Blooper 8: Confusing checkboxes and radiobuttons
2.3.2 Blooper 9: One-from-N settings with no initial value
2.3.3 Blooper 10: Using a checkbox for a non-ON/OFF setting
2.3.4 Blooper 11: Using command buttons as toggles
2.3.5 Blooper 12: Using tabs as radiobuttons
2.3.6 Blooper 13: Too many tabs
2.4 Providing faulty feedback
2.4.1 Blooper 14: Buttons that trigger on "mouse down"
2.4.2 Blooper 15: Ambiguous selections
2.4.3 Blooper 16: Not showing busy cursor
2.5 Abusing text fields
2.5.1 Blooper 17: Using text fields for read-only data
2.5.2 Blooper 18: Overusing text fields
2.5.3 Blooper 19: Type-in fields that behave abnormally
Further reading
Chapter 3--Layout and Appearance Bloopers
Introduction
3.1 Poor layout and arrangement of windows and dialog boxes
3.1.1 Blooper 20: Mixing dialog box control buttons with content
control buttons
3.1.2 Blooper 21: Layout that doesn't reflect usual or natural order
of settings
3.1.3 Blooper 22: Poor initial window location
3.2 Goofs with group boxes and separators
3.2.1 Blooper 23: Misusing group boxes
3.2.2 Blooper 24: Inconsistent group box style
3.2.3 Blooper 25: Inconsistent separator style
3.3 Shoddy labeling and spacing
3.3.1 Blooper 26: Radiobuttons spaced too far apart
3.3.2 Blooper 27: Inconsistent property label alignment
3.3.3 Blooper 28: Poor label placement
3.3.4 Blooper 29: Unlabeled scrolling container components 3.4 Troublesome
typography and graphic design
3.4.1 Blooper 30: Inconsistent text fonts
3.4.2 Blooper 31: Tiny fonts
3.4.3 Blooper 32: Inactive controls insufficiently grayed out
Further reading
Chapter 4--Textual Bloopers
Introduction
4.1 Unprofessional writing
4.1.1 Blooper 33: Inconsistent terminology
4.1.2 Blooper 34: Unclear terminology
4.1.3 Blooper 35: Speaking Geek
4.1.4 Blooper 36: Careless writing
4.2 Unfriendly messages and labels
4.2.1 Blooper 37: Clueless error messages
4.2.2 Blooper 38: Misuse (or nonuse) of "..." on command labels
4.2.3 Blooper 39: Inconsistent use of colons on setting labels
4.2.4 Blooper 40: Tooltips that say the same thing as the visible
label
4.3 Misleading window titles
4.3.1 Blooper 41: Same title on different windows
4.3.2 Blooper 42: Window title doesn't match invoking command
Further reading
Chapter 5--Interaction Bloopers
Introduction
5.1 Allowing implementation to dictate GUI
5.1.1 Blooper 43: Exposing the implementation to users
5.1.2 Blooper 44: Asking users for random numbers
5.1.3 Blooper 45: TTY GUIs
5.2 Presenting information poorly
5.2.1 Blooper 46: Overwhelming users with decisions and detail
5.2.2 Blooper 47: Easily missed information
5.2.3 Blooper 48: Unexpected rearrangement of display
5.2.4 Blooper 49: Instructions that go away too soon
5.3 Setting stumbling blocks for users
5.3.1 Blooper 50: Similar functions with inconsistent user interfaces
5.3.2 Blooper 51: Unnecessary or poorly marked modes
5.3.3 Blooper 52: Installation nightmares
5.4 Diabolical dialog boxes
5.4.1 Blooper 53: Too many levels of dialog boxes
5.4.2 Blooper 54: Dialog boxes that trap users
5.4.3 Blooper 55: Cancel button doesn't cancel
5.4.4 Blooper 56: OK and Cancel do the same thing
Further reading
Chapter 6--Web Bloopers
Introduction
6.1 Web structure and interaction bloopers
6.1.1 Blooper 57: Web site structure reflects organization structure
or history
6.1.2 Blooper 58: Back doesn't go where users expect
6.1.3 Blooper 59: Complicating searching
6.2 Web component, layout, and appearance bloopers
6.2.1 Blooper 60: Hidden links
6.2.2 Blooper 61: Links that don't provide enough information
6.2.3 Blooper 62: Buttons that provide no click feedback
6.2.4 Blooper 63: Displaying long lists as very long pages
Further reading
Chapter 7--Responsiveness Bloopers
Introduction
7.1 Common responsiveness bloopers (Bloopers 64-75)
7.1.1 Examples of responsiveness bloopers
7.2 Reasons for poor responsiveness
7.2.1 Reason 1: The facts about responsiveness are not widely known
7.2.2 Reason 2: UI designers rarely consider responsiveness during
design
7.2.3 Reason 3: Programmers equate responsiveness with performance
7.2.4 Reason 4: Programmers treat user input like machine input
7.2.5 Reason 5: Developers use simple, naive implementations
7.2.6 Reason 6: GUI software tools, components, and platforms are
inadequate
7.2.7 Reason 7: Managers hire GUI programmers who lack the required
skill
7.3 Avoiding responsiveness bloopers: Design principles
7.3.1 Responsiveness is not the same thing as performance
7.3.2 Processing resources are always limited
7.3.3 The user interface is a real-time interface
7.3.4 All delays are not equal; the software need not do everything
immediately
7.3.5 The software need not do tasks in the order in which they
were requested
7.3.6 The software need not do everything it was asked to do
7.3.7 Human users are not computer programs
7.4 Avoiding responsiveness bloopers: Techniques
7.4.1 Timely feedback
7.4.2 Parallel problem solution
7.4.3 Queue optimization
7.4.4 Dynamic time management
7.4.5 Summary of responsiveness techniques
7.4.6 Overcoming the obstacles to adoption of responsiveness techniques
Further reading
Chapter 8--Management Bloopers
Introduction
8.1 Counterproductive attitude
8.1.1 Blooper 76: Misunderstanding what user interface professionals
do
8.1.2 Blooper 77: Treating user interface as low priority
8.1.3 Blooper 78: Discounting the value of testing and iterative
design
8.2 Counterproductive process
8.2.1 Blooper 79: Using poor tools and building blocks
8.2.2 Blooper 80: Anarchic development
8.2.3 Blooper 81: No task domain expertise on the design team
8.2.4 Blooper 82: Giving programmers the fastest computers
Further reading
Chapter 9--Software Reviews
Introduction
9.1 Eudora Pro 4.0 installation
9.1.1 The ordeal
9.1.2 Conclusions
9.2 Kodak Picture Disk 1.2
9.2.1 Executive summary
9.2.2 Organization
9.2.3 Limitations
9.2.4 General
9.2.5 Startup
9.2.6 Main window
9.2.7 Slideshow dialog box
9.2.8 Slideshow window
9.2.9 Edit Picture window
9.2.10 Print Preview window
9.2.11 Print Setup dialog box
9.2.12 Print Setup Options dialog box
9.2.13 Rotate Picture dialog box
9.2.14 Organize Pictures dialog box
9.2.15 Export dialog box
Chapter 10--War Stories of a User Interface Consultant
Introduction
10.1 A Fork in the Tale: Simplifying the controls of an
interactive movie game
10.1.1 Background
10.1.2 The analysis
10.1.3 Redesign: Physical actions
10.1.4 Redesign: Speech and thought
10.1.5 Redesign: Evaluation and discussion
10.1.6 Other aspects of the user interface
10.1.7 Lessons and concluding thoughts
10.2 The Flintstones may be in your TV: Designing controls for a set-top
box
10.2.1 Job 1: UI review that unexpectedly turned into a UI design
10.2.2 Job 2: UI review to check implementation of design
10.2.3 Job 3: Emergency redesign of a front panel
10.2.4 Job 4: Second UI design
10.2.5 Lessons learned
Appendix: How This Book Was Usability Tested
Bibliography
Index
About the Author |
|
 |
|
Jeff Johnson is president and principal consultant at UI Wizards,
Inc., a product usability consulting firm (www.uiwizards.com). He has
worked in the field of Human-Computer Interaction since 1978--as software
designer and implementer, usability tester, manager, researcher at several
computer and telecommunications companies, and consultant. In the course
of his career, he has written many articles, cowritten several books,
and given numerous presentations on a variety of topics in Human-Computer
Interaction.
|
 |
|
Amazon.com
In GUI Bloopers, consultant Jeff Johnson uses 550+ pages to illustrate
common pitfalls in user interface design, the all-important iceberg tip
that end users confuse with applications and that developers confuse with
end users. Reporting on 82 incidents of bad design, Johnson manages to cover
the essential point of his message: software designers should think of their
user interfaces from the user's point of view. Not profound, but profoundly
overlooked in most low-end to mid-range development efforts. His codification
of GUI design in eight predictable principles will help GUI newbies realize
that the customer must be pleased with the product. Of course, the customer
doesn't always understand what he or she wants. Hence, GUI development is
iterative. When the customer is not at hand, a surrogate will do, so usability
testing is essential.
The bloopers include mistakes in window design, labeling consistency,
visual/grammatical parallel construction, coherence of look and feel,
and clarity. Most perceptively, Johnson observes that CPU speed in the
development group hides many design mistakes. Moreover, context-scoping,
already a subtle problem in software design, must be implemented in GUI
design. Input error handling is the most psychologically sensitive of
all GUI design characteristics. User error messages can easily be too
vague or too specific, and diagnostic error messages should be user-manageable,
if not actually user-interpretable.
Like the Hollywood outtakes that gave us the "blooper," the entertainment
quotient here is measured in mistakes, not successes. Teaching by counter
example rather than by example at an estimated ratio of three to one,
Johnson panders to our invertebrate instinct to measure our own successes
by someone else's failure. To his credit, he recognizes that user interfaces
include pedestrian texts (like his) as well as graphical interfaces for
computer applications. His self-referential style gives the book an egocentric
slant, but he is both priest and practitioner: he submitted a draft to
usability testers and reports the results in an appendix. One criticism
was that there were too many negative examples. Hmmm.
Thanks to other tester comments, GUI Bloopers is a browsable
book, allowing the few nuggets of wisdom to be located. For the most part,
the book's value can be captured by reading the seven-page table of contents
carefully. --Peter Leopold
The
author, Jeff Johnson , March 13, 2000
Why I wrote GUI Bloopers
As a user-interface design consultant, I go from company to company,
advising them on how to make their computer-based products or services
easier to use. Over the years, I found that certain errors are very common:
I see them again and again, in company after company. I decided to start
a collection of these common design errors, and eventually arranged with
Morgan-Kaufmann to publish them in a book. That's where GUI Bloopers came
from. I hope it is useful to you. |
|
