 |
|
|
|
|
|
| |
<<Previous | 1
| 2 | 3 | 4
| 5 | Next>>
|
| |
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.
|
| |
<<Previous | 1
| 2 | 3 | 4
| 5 | Next>>
|
| |
GUI Articles List
|
| |
|
 |
|
