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 -