Free Resources

Managing Your Defense Against GUI's from Hell (continued)

STRATEGY ONE: THROW OFF THE BURDEN OF WINDOWS
	Sixth, the rep re-entered the customer ID. And seventh, the rep entered an entire new order while typing "No charge" to signify a warranty replacement. We improved the navigation by putting an option for "See customer's warrantees" on the order screen. This brought up the customer's purchase history directly from the order window, saving thought time and reducing errors. Re-order was only a mouseclick away.
Reduce Visual Work	In the mail-order example, users viewed a scrolled list of purchases for the customer. In the old system, users had to check the purchase dates to establish the warranty period for each item. In the new system, items within warranty were color coded for easy recognition. But this was only part of the cryptocrunch. We also made sure that the gray-value shading was different, too, since about 8% of males have some form of color blindness. (Only about .5% of females are so afflicted). To make it easier to scan across the columns in the purchase history list, we also put a blank line every 5 lines. This provided a "ruler" to guide the eye left to right, preventing scanning errors. By the way, we left-aligned field labels to reduce clutter. The VIMM model presented a few rules of thumb that you can learn to reduce user work. More will appear in future articles. Next find our two top defense strategies against GUI cryptodesign.
	Be wary of using the "windows" of your GUI environment. Research (and practice) show that end-users can easily spend too much time re-sizing, re-positioning, and selecting windows. The design terminology, "free form windows," sounds acceptable. But know that the resulting "window thrashing" can make your new GUI application slower than its mainframe equivalent! This is not speculation. It really happened. Users in the credit card company example above rejected the initial launch of their $10 million GUI system because it slowed them down with too many windows. They were getting paid on a piece basis for handling calls and they hated to take a salary cut, even in exchange for color, mice, and "freedom". For great examples of window thrashing check out the UIs for CompuServe and America OnLine!
CRYPTOWINDOWS SNEAK ATTACK	Here's how cryptodesign creates such problems. First, many developers and product managers who design for a windows environment feel it's politically correct to use plentiful "windows." Finding multitudenous windows in development tools used for designing windows reinforces this assumption for many folks. Ironically, free form windows actually works well for development tools. You can pile up the windows when designing them; but as a computer expert you don't mind. You need free-form windows to juxtapose the various screens for cut-and-paste. Plus you can make visual comparisons between any two windows. Problems arise because cryptodesign suggests that what's good for the developer is good for the end-user. (It's probably not true.) However, we find that only 10% of corporate and shrinkwrapped software benefit from such free-form windows. This is because free-form windows translates as "lack of structure" in the minds of your end-users. Why burden users with the designer's failure to find structure in their UI architecture?
CHECK USER'S NEED FOR "FREE FORM WINDOWS"	Here's how soul design solves the problem. Learn a lot about the user's task flow. Find opportunities to simplify navigation with techniques that automatically close one work area while opening another one. For example, Microsoft has strongly promoted the "tab" and "folder" metaphor in Microsoft Office dialog boxes. OS/2 has adopted the "notebook" metaphor. Both metaphors solve a window thrashing problem within the lower level dialogs of the application. The high level UI architecture orients the user to navigating the application. It generally should be the very first screen they get. How do we reduce window thrashing for the high level UI architecture? For certain task flows, we have placed buttons across the top of the screen, much like tabs. The button row stays up throughout the application, reminding users of their task options. The lower portion of the screen "swaps out" one task for another when the user selects a different button. One button is always "on", even upon opening the application. We call it the "context switch". We don't use the context switch for everything (that would be cryptodesign). First, we interview users and find out what they do.
Top