| 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. |
| 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.) |
| Top |