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


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

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