|
Pull-Downs
|
|
Don't hide functions under pull-downs.
|
Use buttons and function keys for frequent options. Otherwise,
new and infrequent users must search through the menu bar for the
option they need. (See our GUI design column
on menus.)
|
|
Don't succumb to cryptic labels.
|
Pull-downs tend to use short labels that require interpretation
and training. Buttons can offer more area for clear labels and larger
mouse targets as well!
|
|
Avoid the extra motion required by some pull-downs.
|
Pull-downs require users to pick and then pull down a menu to finally
pick the desired option. The user may need to explore the menu bar
as well. Buttons only need one action: a pick. Buttons save motion!
(Selection by accelerator keys helps, but mistyping is easy with
an Alt or Ctrl key combination.)
|
|
Use pull-downs for system-wide functions that are infrequently
used.
|
Learn them once, use them everywhere. Low frequency use means the
user won't be penalized too much for the extra physical work.
|
|
Solve screen space problems with pull-downs.
|
Use pull-downs when your task consumes the screen space for a major
object like a text edit window (word processing) or large metaphor
(spreadsheet), etc.
|
|
Metaphor
|
|
Reduce training time by using a metaphor.
|
A metaphor mimics a familiar object or task. For example, one system
used a grocery store metaphor to help users first identify screen
items and then save the transaction. Putting an item in a "shopping
cart" identified the items. Going through the "checkout
counter" saved the transaction.
|
|
Don't overreach with a metaphor.
|
Metaphors can break down. If misused, like a trash can on a desktop,
users may be puzzled and require training. If users understand their
job, you may not need any special metaphor!
|
|
Don't be cute.
|
In corporate applications, avoid game-like or cute metaphors. They
distract and may add to training time. Puns are hard to understand
(e.g., an "axe" icon to signify "executing"
the program.)
|
