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.
|
 |
|
Review-Date: 9/11/2007 Rating: 5 Summary: Excellent Reference for Designers & Developers
If you are a designer who has to explain to developers what they are doing wrong, get this book (or maybe the next edition, out soon). I loved this book for how well it explained every bad interface design blooper I had ever seen at that point & helped me understand why developers created many of these problems. It helped me explain to developers why there were better solutions & how to design them. It also contains an excellent introduction to user–centered design. It‘s a very well organized and valuable reference for interface designers & a great gift for any open–minded developer interested in good UI design. I‘m looking forward to his next edition.
Review-Date: 9/6/2006 Rating: 5 Summary: Great book to get started on UI design
This was my first book on user interface design, and it was a great choice. It gives good information on principles and also provides specific usable information for how to use controls, etc. I found the organization of the book easy to use and enjoyed reading it.
Review-Date: 9/27/2005 Rating: 4 Summary: Good book, still useful
The author of this book does a very good job of describing and illustrating common GUI design mistakes. He has categorized the problems in broad topics such as "GUI Component Bloopers" and "Interaction Bloopers", then gives concrete examples of the bloopers that occur within each broad topic. The individual bloopers are well illustrated, and examples of better approaches are given.
Even though the applications used in the book are from the nineties, they are still very applicable, since the advice given frequently transcends the tools used to build the screens. It is applicable to web applications as well.
I read through this book once, and now use it as a reference.
Review-Date: 7/25/2005 Rating: 1 Summary: Too old
Don‘t buy this book, it refers to applications written in early ‘90. Today it is completely a different story.
Review-Date: 7/8/2005 Rating: 5 Summary: Excellent text for my GUI programming class
I am a professor of computer science who offers a two–semester, senior capstone project experience in GUI programming. I have taught this course using a variety of languages and tools, and I have always found that the programming gets in the way of the principles. I have long sought a book that focuses just on the principles and around which I could sequence my lectures. GUI Bloopers fits that requirement like a glove. I use this as the primary text in my classes and supplement it with various books that supply the information needed to implement actual programs in Java and Swing. (We look at .NET, too, but the main programming environment at this time is Java.)
Contrary to some other reviewers, I find GUI Bloopers very enjoyable to read. In addition, I find that it is not at all too elementary for my students, even the first few chapters. It‘s amazing how many senior computer science majors don‘t really understand, for example, the difference between radio buttons and checkboxes, even though they use them all the time. One can‘t take such understanding for granted. Familiarity with a component is not the same as true knowledge of how that component is intended to be used and what users expect to happen when they interact with it. Johnson‘s constant reminders to test user interfaces on real users, and his discussion of the various levels of usability testing in simple terms, are invaluable lessons. The illustrations and tales from the author‘s consulting practice bring the principles down to earth and drive home their points effectively.
I highly recommend GUI Bloopers as a college text.
Review-Date: 10/20/2004 Rating: 5 Summary: An essential for GUI designers
Provides clear direction for the design of usable GUI‘s in an approachable manner. A great beginner‘s guide and a valuable reference for the seasoned GUI designer or HCI specialist.
Review-Date: 10/6/2004 Rating: 5 Summary: A designer–to–programmer dictionary
This design book was the only one that made sense to my programmers. As a web designer, I‘ve found it sometimes difficult to communicate the reasoning for specs to the programmers I work with. This book spoke to them in a way that none of my designer–centric books did.
Recommended for anyone who isn‘t a designer who wants to make more usabable interfaces, yet still a great resource for designers in general, web or software.
Review-Date: 8/18/2004 Rating: 2 Summary: Too ‘black&white‘ – try Spolsky for a more realistic view.
I agree with "A Reader" that the layout and organisation is bad.
The first chapter or so describes some very basic GUI problems – eg. confusing checkboxes with radio buttons. Maybe if you‘re a beginner or haven‘t used PCs much then this might be new to you, but to most programmers this is long–worded revision.
The bulk of the rest of the book describes wider problems. Generally valid, although everything is painted as black and white when reality is shades of grey – especially when GUI design advances and MS (& probably Apple) recommendations directly violate a number of points.
So with shades of grey it is easy for a cocky programmer to abandon the whole lot ‘throwing the baby out with the bath water‘ as it were.
It would also be good if the author didn‘t keep telling us that he was a highly paid user interface consultant – this accentuates his approach as being a bit one sided, unlike the more realistic Spolsky.
Also recommend Spolsky‘s "User Interface Design for Programmers". This takes a much more overall/philosophical approach which should be more appropriate for experienced programmers.
He also has a more realistic view of management and testing; and the book is a far easier read.
Review-Date: 7/7/2004 Rating: 4 Summary: Good pratical advice
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 be bloopers. Again and again he refers to his reviews of client software. He rarely refers to his user studies or other research. This makes me question if some of his bloopers are really bloopers or just his opinion.
Review-Date: 11/21/2003 Rating: 5 Summary: How it helped me
I read this book knowing really nothing about gui design. It is a very methodical book and was extremely helpful to me. I even took the time to make a checklist of things to look out for and then applied the concepts to my designs. The result is that on every software demo we give of our product developed using the checklist, we get the same comments: "Wow! This is really easy to use/learn!" nuf said.
|
|
