GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers

366 Pages·2000·9.2 MB·English

by  Jeff Johnson

Release Team[oR] 2001
[x] programming
GUI Bloopers: Don'ts and Do's for Software Developers
and Web Designers
by Jeff Johnson ISBN: 1558605827

Morgan Kaufmann Publishers © 2000, 559 pages

This book cuts right to the core of the most common interface

problems, offering a real-world advice to the computer
s oftware programmer.
Companion Web Site

Table of Contents
Back Cover

Synopsis by Anne Fischer Lent
No single person can know everything, which is why this book is a must for
anyone designing a GUI (graphical user interface). Software programmers
and web site designers can easily lose sight of exactly how a person will
interface with their design. With no guidance or feedback from the user,
bloopers are bound to abound. Author Jeff Johnson, who is a specialist in
human-computer interaction, discusses mistakes that software programmers
are likely to make in layout, text, interaction, responsiveness, management
and more. His overall approach of designing from the outside in turns the
programmer’s focus to the end user. Loads of examples, both good and bad,
are included.

- 2 -
Table of Contents
GUI Bloopers - 4
Acknowledgments - 5
Introduction - 6
Chapter 1 - First Principles - 11
Chapter 2 - GUI Component Bloopers - 42
Chapter 3 - Layout and Appearance Bloopers - 94
Chapter 4 - Textual Bloopers - 132
Chapter 5 - Interaction Bloopers - 171
Chapter 6 - Web Bloopers - 229
Chapter 7 - Responsiveness Bloopers - 253
Chapter 8 - Management Bloopers - 282
Chapter 9 - Software Reviews - 317
Chapter 10 - War Stories of a User Interface Consultant - 336
How This Book Was Usability Tested - 360
Bibliog raphy - 362
About the Author - 366

Back Cover
GUI Bloopers looks at user interface design bloopers from commercail
software, Web sites, and information appliances, explaining how intelligent,
well-intentioned professionals make 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 intructive way.
This is an excellent, well-iiustrated resource for anyone whose work touches
on usability issues, including software engineers, Web site designers,
managers of development processes, QA professionals, and usability
professional.
Features
Takes a learn-by-example approach that teaches you to avoid comon
errors by asking the appropriate quwstions of your own interface designs.
Includes two complete war stories drawn from the author's personal
experience.
Covers bloopers in a wide range of categories: GUI components,
layout and apprearance, text messages, interaction strategies, Web site
design, responsiveness issues, management decision-making, and even
more at www.gui-bloopers.com.
Organized and fromatted based on the results of its own usability
testing -- so you can quickly find the information you need, packaged in easily
digested pieces.
- 3 -
About the Author
Jeff Johnson is a 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 a software designer, usability tester, manager, and
r esearcher.

GUI Bloopers
Don'ts and Do's for Software Developers and Web Designers
Jeff Johnson
UI Wizards, Inc.
Copyright © 2000 by by Academic Press
Don'ts and Do's for Software Developers and Web Designers
MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ACADEMIC PRESS IMA Harcourt Science
and Technology Company
SAN FRANCISCO SAN DIEGO NEW YORK BOSTON LONDON SYDNEY TOKYO
Senior Editor Diane D.
Cerra
Director of Production Yonie
& Manufacturing Overton
Senior Production Edward
Editor Wade
Editorial Coordinator Belinda
Breyer
Cover Design Ross
Carron
Design
Text Design & Rebecca
Composition Evans &
Associates
Editorial, Technical, & Cherie
Spot Illustration Plumlee
Copyeditor Ken
DellaPenta
Proofreader Carol
Leyba
Indexer Steve Rath
Printer Courier
Corporation
Designations used by companies to distinguish their products are often claimed as trademarks or
registered trademarks. In all instances where Morgan Kaufmann Publishers is aware of a claim, the
product names appear in initial capital or all capital letters. Readers, however, should contact the
appropriate companies for more complete information regarding trademarks and registration.
ACADEMIC PRESS
A Harcourt Science and Technology Company
525 B Street, Suite 1900, San Diego, CA 92101-4495, USA
- 4 -
http://www.academicpress.com
Academic Press
Harcourt Place, 32 Jamestown Road, London, NW1 7BY, United Kingdom
http://www.hbuk.co.uk/ap/
Morgan Kaufmann Publishers
340 Pine Street, Sixth Floor, San Francisco, CA 94104-3205, USA
http://www.mkp.com
2000 by Academic Press
All rights reserved
Printed in the United States of America
04 03 02 01 00 5 4 3 2 1
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by
any means—electronic, mechanical, photocopying, or otherwise—without the prior written permission of
the publisher.
Library of Congress Cataloging-in-Publication Data
Johnson, Jeff, Ph.D.
GUI bloopers: don'ts and do's for software developers and Web designers / Jeff Johnson.
p. cm.
Includes bibliographical references and index.
ISBN 1-55860-582-7
Graphical user interfaces (Computer systems)Title.
QA76.9.U83 J63 22000
005.4'37-c21 00-021388
This book is printed on acid-free paper.

Acknowledgments
I could not have written this book without the help and support of many other people.
First of all, I would like to thank my wife and friend, Karen Ande, for giving me her love and support while I
was writing this book, and for putting up with significant reductions in our ability to travel and socialize
together.
I thank my mother-in-law, Dorothy Hadley, for always asking, whenever she called in late 1998 and 1999:
"How's the book going?" I thank my father, Ben Johnson, for helping me to develop an analytic and critical
mind and an ability to express myself in writing.
I am grateful for the willingness of several software developers to usability-test earlier versions of this book
and give me their frank feedback. The ways in which their feedback helped improve this book are
described in the Appendix: How This Book Was Usability Tested. The programmer-testers are Pat
Caruthers, Brent Emerson, Stuart Ferguson, Mairé Howard, and Sandi Spires.
The book was greatly improved by the comments and suggestions from several reviewers: Stuart Card,
Tom Dayton, Jonathan Grudin, Deborah Mayhew, Bonnie Nardi, Jakob Nielsen, Terry Roberts, and Terry
Winograd.
The book also was helped immeasurably by the care, oversight, excellent lunches, layout and organization
advice, legal advice, excellent lunches, logistical support, nurturing, and excellent lunches provided by the
staff at Morgan Kaufmann Publishers, especially Diane Cerra, Belinda Breyer, Edward Wade, and Marilyn
- 5 -
Alan, and copyeditor Ken DellaPenta, and illustrator Cherie Plumlee. And did I mention those excellent
lunches?
Many of the ideas in Chapter 7, Responsiveness Bloopers, had their origins in a conference paper and
presentation that I co-authored with Dave Duis [Duis and Johnson, 1990], while I was a researcher at
Hewlett-Packard Laboratories and he was a student intern. I am grateful for the ideas and prototyping
work Dave contributed at that time. Dave Duis's MIT Master's thesis [1990] was also based on the same
paper and presentation, and so shares some ideas with Chapter 7. Another source of insights and ideas
for that section came from conversations with Stuart Card of Xerox Palo Alto Research Center. I am
grateful for his willingness to chat about the issue of responsiveness.
Regarding the Fork in the Tale war story (Chapter 10): I am grateful for the opportunity to work with the
creative designers and developers at Advance Reality, especially film director and game designer Rob Lay
and lead programmer Ken Carson. Thanks also to the graphic artists at 415 Productions and McMacken
Graphics, to staff members at AnyRiver who contributed ideas to the user interface, especially Chuck
Clanton and Stewart Bonn, and to several anonymous people who reviewed the version of the story I
presented at the ACM CHI'98 conference.
Finally, I would like to thank my clients and former employers. Without them, this book would not have
been possible… or necessary.

Introduction
Why is this book needed?
Throughout the software industry, software engineers develop user interfaces with little—sometimes no—
support and guidance from professional user interface designers. For example, some software is
developed by individual freelance programmers who lack training in designing user interfaces or access to
people who have such training, and then is sold to a company that markets it. Even when software is
developed by sizable organizations, there may be no developers who have user interface expertise. Some
companies do have user interface professionals, but not enough of them to cover all the development
projects needing user interface design skills.
The marketplace of software products, software-controlled appliances, and online services is therefore full
of programs designed entirely by people who, though they are professional programmers, are user
interface amateurs. Such software is a drag on the success of the entire industry.
As a user interface consultant, I am often called in late in the development process to review or test
software that was developed by people who have little user interface design experience. Such software is
typically full of design errors. Many of these errors are extremely common, occurring over and over in
projects across companies and even within companies.
A programmer at a client company once told me, "You're our lint for Uls," referring to a Unix utility program
that checks C programs for common programmer errors. To a large exent, that's a pretty fair description of
how many client companies want to use me: as a filter against user interface design errors.
To reduce the incidence of common errors and my need to police my clients' user interfaces, I have tried
advising programmers to read one or more books on designing and evaluating user interfaces that have
come out of the Human-Computer Interaction (HCI) community, such as Shneiderman [1987], Nielsen
[1993], Weinshenk et al. [1997], and Bickford [1997]. Such advice usually goes unheeded because most
such books are (1) too academic for programmers, or (2) written for experienced user interface
professionals.
Even the few programmers who read the recommended books and understand the general design
guidelines continue to make many of the same common design errors. It seems that the problem is that
the guidelines in these books are too abstract. It is too easy for a programmer to rationalize violations of
abstract guidelines: "Yeah, I understand the rule, but this situation is different. It's a special case that isn't
covered in the rules." Or they might say: "I may be bending the rule, but it's for a good reason."
Another problem is that, as one GUI programmer I know said: "Most programmers believe they are UI
experts." After all, programmers use computers more than most people do, and so are exposed to more
user interfaces. They assume that that, coupled with the fact that they may have designed some user
interfaces, makes them user interface designers.
Because of these two problems, I have found, when working with developers while consulting for client
companies, that it helps to point out the errors they have made and explain why the errors are errors.
- 6 -
Similarly, when training developers in an attempt to reduce the likelihood of future design errors, I have
found that it helps to focus on common design errors and work from those to design rules. In other words,
show GUI developers the mistakes they often make, and provide rules for avoiding those mistakes. It is
also important to provide some of the principles underlying the design rules so that developers can
generalize beyond specific examples.
This experience suggested that a book focused on design errors and how to avoid them might be more
effective than many previous user interface design books have been, or at least would be a useful
complement to such books. Accordingly, this book is structured as design guidelines in reverse: here's a
common error; here's how to avoid it.
Not all of the errors that hurt the usability of products and services are made by programmers
implementing user interfaces. Many software development organizations commit errors at the
management level that negatively affect the user interfaces of the products and services they develop.
Furthermore, these management errors are in many ways more important than specific GUI design errors
because they affect more projects and are harder to diagnose and correct. I therefore wanted to describe
those sorts of errors as well and warn developers away from them. That is the reason for Chapter 8,
Management Bloopers.
The main goal of this book is to help GUI developers and designers become better at catching their own
design mistakes and—even better—at avoiding them altogether.
I sometimes think it would be wonderful if the real world had error dialog boxes. They would pop up out of
thin air in front of your face whenever you made a mistake. Real-world error dialog boxes would be a great
way to train software developers and development managers to recognize when they have committed, or
are about to commit, a blooper. (Some software developers and managers I know would get a lot of them!)
Since there are no error dialog boxes in the real world, we need to program them into developers' heads.
Hopefully, this book will help with some of that programming.

What is a GUI blooper?
This book describes "bloopers" (that is, mistakes) that software developers frequently make when
designing graphical user interfaces (also known as GUIs). The bloopers in this book do not cover all of the
mistakes GUI designers could make, or even all of the mistakes I have seen. Believe me, in over two
decades of working as a user interface professional, I've seen some design mistakes that were simply
amazing—true "howlers," as some of my colleagues call them.
To get into this book, it wasn't enough for a design mistake to be a howler. It also had to be common.
There is little value in warning software developers away from very rare or application-specific mistakes,
no matter how horrible the errors may be. On the other hand, there is great value in warning developers
away from errors that they—at least statistically speaking—are likely to make.
Furthermore, I selected most of the bloopers long before finding examples of them. What I am referring to
as "bloopers" are not just specific examples of design errors I have seen in software. The bloopers are
- 7 -
mistakes that developers make over and over and over again. The examples only serve to illustrate the
bloopers—to make them more concrete.
Therefore, this book is not simply a collection of user interface "outtakes"—embarrassing mistakes
software developers have made. My purpose is not to provide a parade of user interface howlers that
embarrass the perpetrators and cause readers to laugh, shake their heads, and wonder how any designer
could be so stupid. My purpose is to help GUI designers and developers learn to produce better GUIs.
The bloopers in this book are described verbally and, where possible, illustrated using screen images
captured from real products and online services, made-up screen images, and anecdotes from my
experience. With each blooper is the design rule that developers should follow to avoid the blooper. As
with the bloopers, each design rule is illustrated, where possible, with examples, both real and made-up.
To show clearly whether a screen image is an example of a design error or a correct design, I have
marked most of them with symbols for "bad example" and "good example." Bad examples—examples of
bloopers—are marked using a "thumbs down" hand symbol. Good examples—examples of correct
design—are marked using a "thumbs up" hand symbol (see symbols shown in the margin to the left of this
paragraph). Screen images that are neutral are unmarked.
The bloopers in this book are classified into seven categories: GUI component, layout and appearance,
textual, interaction, Web, responsiveness, and management. GUI component bloopers correspond to
erroneous decisions about how to use components provided in a user interface toolkit. Layout and
appearance bloopers are errors in arranging and presenting GUI components. Textual bloopers are
mistakes in how text is used in user interfaces, not graphical problems involving text, such as poor choice
of fonts, but problems in what the text says. Interaction bloopers are violations of general user interface
design principles, independent of which user interface toolkit is used. Web bloopers are problems that are
specific to Web sites and Web-based applications. Responsiveness bloopers are aspects of a product's or
service's design that interfere with user work pace. Management bloopers are management-level
problems that affect the usability and usefulness of software and electronic appliances.

How were the bloopers compiled?
The bloopers in this book represent a sampling from over two decades of personal experience designing,
critiquing, and testing user interfaces for software products, especially my experience since 1996, when I
began working as a user interface consultant. They were compiled mainly from user interface critiques,
usability test reports, design guidelines documents, and talks I have prepared for employers and
consulting clients. A few were suggested to me by colleagues.
The examples of bloopers come from a variety of sources. Very few of the examples that actually identify
a product or a software company come from my consulting clients. In most cases, I worked for clients
under nondisclosure agreements that prevent me from revealing details of what was developed, even for
software that never made it to the market. Therefore, in most of the anecdotal stories in this book, the
names of companies and specific products are altered or withheld. For the same reason, the screen
images exemplifying bloopers come mainly from commercially available software and online services
developed by companies other than my consulting clients, that is, from software and Web sites I have
used. On the other hand, I did obtain permission in a few cases to use real names and screen images
when discussing client software.
A few examples of bloopers in this book are from the Interface Hall of Shame
(www.iarchitect.com/mshame.htm), a large collection of GUI design errors compiled by Brian Hayes of
Isys Information Architects, Inc., a user interface consulting firm. The site presents examples—found by
Mr. Hayes or by visitors to the site—of poor user interface design in commercially available products and
services.[1] Some of the examples on exhibit at the Interface Hall of Shame provided good illustrations for
bloopers I wanted to discuss, so, with Isys Information Architects' kind permission, I have included them.
Finally, some of the screen images that illustrate bloopers in this book were made up—created specifically
for this book in order to depict certain bloopers clearly.
Although they were not sources of bloopers or examples of bloopers in this book, three other impressive
catalogues of design errors deserve mention:
(cid:131) Designing Visual Interfaces, a book on software graphic design by Kevin Mullet and
Darrell Sano [1995]. For each of the design issues covered in their book (for example, "elegance and
simplicitiy," "scale, contrast, and proportion," "organization and visual structure"), Mullet and Sano
present not only principles and examples of good design, but also common design errors.
- 8 -
(cid:131) Uselt.com, a Web site created and maintained by Jakob Nielsen, a Web design
expert and commentator on Web trends. Useit.com lists Nielsen's top ten Web design errors in
addition to providing other useful Web design advice. Nielsen has recently written a book on the
same topic [Nielsen, 1999d].
(cid:131) WebPagesThatSuck.com, a Web site compiled by Web designer Vincent Flanders
that uses examples of bad Web site design to teach good Web site design. Corresponding to the
Web site (or at least to a snapshot of it at one point in time) is an excellent book, Web Pages That
Suck, by Flanders and Willis [1998].
The main impact of these error collections on this book was to convince me that their authors had already
covered their respective territory pretty thoroughly and well. Mullet and Sano didn't leave much that
needed to be said about graphic design bloopers. Similarly, Web design bloopers had already been well
covered by Nielsen and by Flanders and Willis. Therefore, I steered clear of topics they had discussed,
and focused on design problems I had seen that they, to my knowledge, had not covered.
Chapter 8, Management Bloopers, was influenced by three books about management-level problems that
contribute to poor usability in computerbased products and services:
(cid:131) The Trouble with Computers, by Tom Landauer [1995]
(cid:131) The Invisible Computer, by Don Norman [1999]
(cid:131) The Inmates Are Running the Asylum, by Alan Cooper [1999]
These three books are not systematic collections of bloopers. Their main purpose is to offer in-depth
analysis of the reasons for the software industry's tendency to turn out products and services that mystify
and annoy people and hamper productivity. However, these books do include examples of the types of
user-hostile design that can result from software development organizations and processes that are
focused on technology rather than on user requirements.
[1]I encourage readers who have not visited the Interface Hall of Shame to do so. Some readers may even
have favorite design howlers to contribute to the Hall of Shame.

Who should read GUI Bloopers?
The main intended audience for this book is working programmers who develop software or Web sites
with little or no guidance and feedback from user interface professionals. For such programmers, this book
is intended to serve both as a tool for self-education and as a reference. It is intended to supplement—not
replace—user interface design guidelines for specific GUI platforms.
A second target audience is managers of software development teams. It is primarily for their benefit that
the book includes a chapter on management bloopers.
A third target audience is user interface designers, especially those who are just entering the profession.
For them, this book supplements the standard references and textbooks on user interface design and
evaluation by warning against common design errors and by providing practical examples.

How is this book organized?
This book has 10 chapters: First Principles, GUI Component Bloopers, Layout and Appearance Bloopers,
Textual Bloopers, Interaction Bloopers, Web Bloopers, Responsiveness Bloopers, Management Bloopers,
Software Reviews, and War Stories.
Chapter 1 First Principles, provides a basis for understanding both the bloopers and the design rules for
how to avoid bloopers.
The seven bloopers chapters describe and illustrate the common mistakes software developers and their
managers make, when designing software and Web sites, that result in user-hostile software, online
services, and electronic appliances.
Chapter 9, Software Reviews, reviews two software products in detail, describing the bloopers they
contain as well as other, less common design errors. It also provides suggestions for how the bloopers
could have been avoided.
The last chapter, War Stories of a User Interface Consultant, describes in detail some experiences that I
have had as a consultant that provide insight into (1) why software developers commit user interface
design bloopers and (2) how to overcome bloopers.
- 9 -
How should you use this book?
As stated above, this book is intended for three categories of readers—GUI programmers, software
development managers, and new user interface professionals. These three different types of readers
will be able to get different information out of this book.
GUI programmers will probably want to jump right into the very specific bloopers: GUI component,
layout and appearance, textual, and Web. They can either start with Chapter 1, First Principles,
before reading about the bloopers, or they can go back and read the principles as they arise in the
design rules for avoiding bloopers. After those chapters, I would recommend that programmers read
the chapters on interaction and responsiveness bloopers, and then the software reviews.
Programmers can consider the management bloopers, war stories, and appendix to be
"extracurricular"—to be read if they have time or interest.
For software managers, the chapter on management bloopers is obviously the most important.
Following that in order of importance for managers are textual bloopers, responsiveness bloopers,
war stories, software reviews, and interaction bloopers. Chapter 1 First Principles, may be of interest
to managers who have a background or interest in user interface design and human-computer
interaction. Development managers can probably skip the chapters on GUI component, appearance
and layout, and Web bloopers completely. They can just tell their programmers and designers to
"read those sections and do what Johnson says." :-)
Budding user interface professionals should definitely start by reading Chapter 1, First Principles. I
suggest they then skim the chapters on GUI component, layout and appearance, and textual
bloopers mainly to familiarize themselves with what is in them; they can revisit specific bloopers in
these chapters later on an as-needed basis. On the other hand, the chapters on interaction,
responsiveness, and management bloopers are highly recommended for new user interface
professionals. For people who will be designing Web sites or Web applications, the chapter on Web
bloopers is important, but others can skip it. The final two chapters, Software Reviews and War
Stories, will provide newcomers to the user interface field with a glimpse of what experienced
professionals do. Finally, some user interface professionals may be interested in reading the
Appendix to see how this book was improved through usability testing.
Table I.1 summarizes these recommendations.
Table I.1: Recommended reading by type of reader
GUI New UI Development
programmers professionals managers
(First Principles) First Principles Management
Bloopers
GUI Component GUI Component Textual
Bloopers Bloopers (skim) Bloopers
Layout and Layout and Responsiveness
Appearance Appearance Bloopers
Bloopers Bloopers (skim)
Textual Textual Software
Bloopers Bloopers (skim) Reviews
(Web Bloopers) Interaction War Stories
Bloopers
Interaction Responsiveness Interaction
Bloopers Bloopers Bloopers
Responsiveness Management (First Principles)
Bloopers Bloopers

Software (Web Bloopers)
Reviews

(Management Software
Bloopers) Reviews

(War Stories) War Stories
- 10 -