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
GUI stands for graphical user interface. Bloopers are incredibly dumb designs created over the past ten years such as error messages, unreadable fonts, hidden functionality, installation nightmares, back buttons that don't go back, and untimely feedback. Highlighting those and other (82 total) examples of bad design, Johnson, president and primary consultant at UI a Wizards Inc., believes software designers should design from the user's point of view. Readers will find his chapter on good design principles useful; recommended for university and large public libraries.
Copyright 2000 Reed Business Information, Inc.
Overall I liked this book. It has many practical guidelines, that you can apply immediately. My only problem was there were many trivial bloopers and many bloopers which may not... Read morePublished on July 7 2004 by James B. Pogue
I read this book knowing really nothing about gui design. It is a very methodical book and was extremely helpful to me. Read morePublished on Nov. 21 2003 by Eric Ibsen
I've been a developer over the paste 13 years so I am, as one said, the main target for cryptichism (from the author's point of view) in this book. Read morePublished on May 26 2002 by Julio Nobre
This book is an essential read for anyone developing GUI applications. The style of writing and the huge number of examples is very well suited to the GUI software developer. Read morePublished on April 3 2002 by eoin
This book is well worth reading. It has hundreds of useful ideas.
For usability issues Steve Krugs "Don't make me think" I still consider the best. Read more
Since reading this, I've run across several UI bloopers on a project and was able to speak with authority about them. As the book predicts, the programmer resisted fixing them. Read morePublished on Jan. 9 2002 by Dan Keller
After completing only 2 GUI projects, I wish that I had read this book first. I would have saved hundreds of work hours. Read morePublished on Nov. 15 2001 by Clyde
I would recommend to read this book to all UI developers, especially to those who never did UI programming before (I mean who been assigned to do UI programming without previous UI... Read morePublished on July 23 2001 by Serge Shimanovsky