LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

High Performance Computing Linux Financial Markets
4/19/2010
New York City
Flagg Management

Informix User Conf.
4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

IBM brings Rational tools into the cloud
Fifteen Rational products for managing, developing and testing on clouds are now available...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

If You Build It, Will They Use It?


By Alan Zeichick
May 15, 2000 — 
Have you ever tried to use a piece of software that has all the right features but is simply too annoying, frustrating or inconsistent to use? Been turned off by typos on an online vendor's Web site? Been angered when you've read error messages that say, "Your application has crashed, and all work has been lost," and been forced to press "OK"? I sure have, and so has Jeff Johnson, author of "GUI Bloopers." I often give such software or Web sites negative reviews-but Johnson has done something more: He has developed a very informative book that should help you and your team avoid these and other common user-interface design and implementation errors.

Johnson's approach is a good one: He has abstracted his vast collection of user-interface gaffes into a series of design principles, many of which are presented with either real illustrations from shipping software products or live Web sites, or from fabricated examples that make his points clearly.

The primary audience for the "GUI Bloopers," says Johnson, is the working developer creating applications without the assistance of a professional UI designer; the secondary audience is the software development manager. I would recommend managers as the primary audience; very few developers are competent enough to create compelling user interfaces without management oversight. After all, interface design is not a technology issue: Even when software tools include GUI builders and wizards, that's no guarantee that the results will be optimal.

The book divides the bloopers into eight broad categories. Some are extremely basic: In the section called "First Principles," Johnson urges developers to focus on the function of the application first and determine its interface presentation later, and to remember that old-time adage that the screen belongs to the users (i.e., the application should not move the cursor or its windows) and the like. There's no excuse for forgetting the basics.

More concrete guidance is given to coders in the next few sections, which cover the design of components such as menus, check boxes and radio buttons, as well as the layout of windows and dialog boxes. Blooper 1, found on page 62, urges developers to avoid dynamic menus. The functions under "File," "Edit" and "View" should never change within an application; an inappropriate command should be grayed out, not removed from the display. Forgetting to put in keyboard shortcuts, or using nonstandard shortcuts (Ctrl-S is a de facto standard for saving a file, Ctrl-P for printing), is another no-no.

The author spends a lot of verbiage reminding readers of the correct way to use check boxes (for single on/off choices) and radio buttons (when exactly one choice out of a field of multiple options is permitted). Granted, many applications misuse the basic GUI widget set, but Johnson appears to be bogged down with that particular detail. He similarly is dismayed by the abuse of noneditable text fields, actions that happen on mouse-down rather than mouse-up, and arbitrary lengths of input fields.

Johnson also dislikes the use of technical jargon (he calls it "speaking geek") in command and error messages. What should an end user make of an error message that says "type mismatch," or a request for a user to "authenticate" his session, or references to "strings" and "exceptions." Ambiguity is another problem: The developers of an application know the difference between its "find" and "search" features, but would the ordinary application user? Probably not.

Those UI bloopers, though annoying, won't impair a worker's efficiency. That's not necessarily the case with Johnson's sections on interactivity and responsiveness bloopers. For example, Blooper 46 covers the common practice of overwhelming users with decisions and details-if there are too many options on a menu or dialog box, the user won't know which to use and what their effects might be.

That is particularly evident when important and minor options are presented without any emphasis that helps the user decide what to study and what to ignore. The advice Johnson offers: Label options clearly, group related features together, use "Advanced" settings boxes for less-frequently-used choices, and make important controls larger.

One short chapter in "GUI Bloopers" is devoted to Web bloopers and, frankly, it only hits the tip of the iceberg. Yes, he's right, the "Back" button should always take browsers back to where they were before-too many sites trap users inside their menus. Yes, search engines generally are pretty bad. Yes, many pages are too large and poorly organized. Yes, designers often

use the wrong Web graphical widget. But if you are primarily looking for Web-site design advice, check out Johnson's recommended Vincent Flanders'www.webpagesthat suck.comor Jakob Nielsen'swww.useit.com.

Chapter 8 focuses on what Johnson calls "management bloopers." In it, he berates organizations for placing user-interface design too low on the development priority list, not understanding what user-interface professionals do, and failing to either do enough user testing or to follow up on the results of such tests. He's right: When it comes to the creation of in-house applications, few development managers that I've spoken with give much consideration to fine-tuning the interface design. UI decisions are too often made by the developers on-the-fly, perhaps with suggestions coming from a single line-of-business manager. It's no wonder that end users are frequently unhappy with their applications, or worse, find them so difficult to use that their efficiency is impaired.

"GUI Bloopers" is a fine book, good both for developers to use when they are building their applications and for the managers and testers to study when they are evaluating their applications. Johnson's collection of bloopers will raise awareness of what can go wrong with an application-and his related set of design principles should help developers avoid those mistakes. Strongly recommended.

"GUI Bloopers." Jeff Johnson. Morgan Kaufmann, 2000. Trade paper, 559 pages. $44.95.


Share this link: http://www.sdtimes.com/link/24957
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading