Pull-Down Menus: Out of Sight, Out of Mind (continued)

<<Previous | 1 | 2 | 3 | 4 | 5 | Next>>

Solution: Put the options on push buttons. Buttons and menus can handle longer phrases than pull-downs. You get clear communication for casual and new users. You can position the push button on the screen at the place the user needs it, matching the task flow as it goes in a left-right, top-down pattern. If a command appears on several screens, try to design a task flow that allows a consistent position for the buttons.

When using pull-downs, never change menubar names! (Play the slots with a slot machine, not a menubar.) If an option doesn't apply in a particular situation, deactivate it by dimming it rather than "offing" it.

Reduce Memory Work

Issue: Since pull-downs hide options, users must remember to remember they exist! Research demonstrates that users forget rapidly and often fail to search under menu options for ideas!

Solution: Keep your functions visible. (Call us for our inspirational button "If the user can't find it, the function's not there." 1-800-242-4480.) At the same time, hide functions until they are needed. Don't overwhelm the new or casual user with choices not required yet. (Experts can handle them better.) If you're plumb out of screen space, candidates for pull-downs include system-wide functions. Functions used least frequently are your first choice for pull-downs.

Reduce Motor Work

Issue: Using a pull-down menu requires two mouse clicks. One to open the menu, another one to select the option. Furthermore, exploring a set of menubar options requires a lot of "mousing around".

Solution: A push button, or a classical menu option only requires one mouse click and no mousing around.

SOUL DESIGN STRIKES BACK We haven't give up on pull-downs! Here are some ways to set the cryptocritters straight. Let's assume you are designing an application that has no need for the blank page metaphor. Instead, the task has an identifiable task flow with task modules. Here are some options that follow the VIMM model given previously.

Context Switch In Figure 1 we see that buttons make navigational options obvious to the user. This approach guarantees your users will know where they are and how to get there at all times. Yes, we kept some pull-downs for functions that were system-wide as well as infrequent. Note that the screen below the buttons "swaps out" one display for another. This solves the problem of window thrashing and window pile-up that we discussed in last month's column. The user avoids the motor work of selecting "OK" or "Cancel" to close one window prior to opening another. The folder metaphor extends these same benefits to a second level of menu.

By the way, Windows 95 uses a "task bar" similar to the context switch. It's not a bad idea. However, cryptotemptations abound. For example, don't imitate the cascade menu that sprouts off the "Start" button. Cascades are physically hard to use. Microsoft even recommends against them (see page 134 in The Windows Interface Guidelines for Software Design by Microsoft, 1995). Also, keep all the buttons visible and in a fixed sequence (unlike the Win95 taskbar). Users develop a gut-level feel where items show up. Don't disappoint them.

<<Previous | 1 | 2 | 3 | 4 | 5 | Next>>

GUI Articles List