Menu Design

Menus are the primary means of orgamzmg most of an application's features. Because of screen size limitation and visual simplicity, Menus organize components used frequently by users and components used in most application sessions.

There are four types of Menus:

• Pulldown Menus

• TearOff Menus

• Popup Menus

• Option Menus

Pulldown Menus are pulled down from a CascadeButton. CascadeButtons should always be available in the context that they are needed. Menus can also contain CascadeButtons so that Menus can be nested. The MenuBar is a horizontal collection of CascadeButtons.

TearOff Menus are a combination of a TearOffButton and another Menu, usually a Pulldown Menu. A TearOffButton contains a dashed line graphic representing perforations. TearOffButtons must be the first element within a

*

Application Design Principles

Menu. When the TearOffButton is activated, the Menu changes into a DialogBox. A TearOff Menu is useful when you do not want the Menu to disappear after a Menu selection.

Popup Menus are context sensitive, but give no cue to their existence. They are popped up when the user presses BMenu over a component with an from within a selected range of elements.

Option Menus provide a means of selecting from a set of choices while taking up very little space. An Option Menu is popped up from an OptionButton, which is distinguished by a bar graphic on the right side of the button.

Menus are composed of titles, elements, mnemonics, and accelerators. A Menu's title should be unique to avoid confusion. The title should clearly indicate the purpose of the Menu.

• A Pulldown Menu's title is taken from the Label in the CascadeButton.

• A Popup Menu's title should be placed at the top of the Popup Menu and separated from the Menu elements by a Separator.

• An Option Menu's title is usually a Label to the left of the OptionButton, but it can be at the top of the Option Menu itself.

Most basic controls can be Menu elements including Labels, Separators, PushButtons, ToggleButtons, and CascadeButtons. The elements can be identified by either a text label or a graphic. A Menu must be wide enough

*

to accommodate its widest element.

A mnemonic provides a quick way to access Menu elements from the keyboard. While the location cursor is in a Menu or MenuBar, pressing the mnemonic letter of an element activates that element. The MenuBar's and any Option Menu's mnemonics can be used by pressing <Alt> with the mnemonic letter. An element's mnemonic should be the first character of the element's Label. If that character conflicts with another mnemonic in the Menu, another character in the Label should be used. The mnemonic of an element should be underlined in the element's Label. When the appropriate mnemonic letter does not appear in the element's Label, it should appear in parentheses after the Label.

An accelerator provides a way to access Menu elements from the keyboard without posting the Menu. Accelerators are useful to the experienced user for saving time when using frequently used components. You should provide accelerators primarily as a matter of utility, not design conformity.

If a keyboard accelerator exists for a Menu entry, it should appear following the Menu's Label, justified on the same line. The accelerator and the selection should be separated by enough space to make them visually distinct.

You should use the following guidelines when designing Menus and Menu systems:

• Keep Menu structures simple.

• Group like Menu elements together.

• List Menu selections by frequency of use.

• List Menu selections by order of use.

• Separate destructive actions.

• Provide mnemonics and accelerators.

• Use TearOffButtons in frequently used Menus.

6.2.3.1 Keeping Menu Structures Simple

Applications should keep Menu structures simple. One of the primary benefits of Menus is the ease of access to the elements of the Menu. While cascading submenus help the application and the user organize Menu elements, each level of a submenu reduces the ease of access to the Menu elements. Multiple levels of cascading submenus can also quickly create visual clutter. Whenever you consider using a cascading submenu, you should consider using a DialogBox or more Pulldown Menus instead.

Application Design Principles

6.2.3.2 Grouping Like Menu Elements Together

Applications should group Menu elements into logical groups. This helps the user locate specific Menu elements. You should first try to place a new Menu element into the common Menu groups described in Section 6.2.1.5.

If that is not appropriate, you should group new Menu elements according to function, with the more frequently used element appearing first. You should also use Separators between logical groups of elements.

6.2.3.3 Listing Menu Selections by Frequency of Use

As in other client areas, applications should order Menu elements according to the frequency of usage, positioning the most frequently used elements near the top of the Menu.

6.2.3.4 Listing Menu Selections by Order of Use

More important to Menu design than the frequency of use is the order of use.

Applications should order Menu elements according to the order of usage.

For example, the Copy element should be placed before Paste. This helps the user's interactions flow smoothly.

6.2.3.5 Separating Destructive Actions

Applications should separate destructive actions from frequently chosen selections. This is to avoid accidental selection of the destructive element.

Destructive elements, like Delete or Clear, should be placed at the end of a Pulldown Menu and separated from other elements by a Separator.

6.2.3.6 Providing Mnemonics and Accelerators

Applications should provide mnemonics and accelerators to Menu elements.

Try to choose mnemonics and accelerators that are easy to remember by using letters from the element's title. Note that mnemonics and accelerators only add to the utility of your applications. They never detract from the basic ability of a new user.

Applications should provide accelerators for frequently used Menu items.

In general, accelerators should not be assigned for every Menu item in an application. It is preferable to assign accelerators that have some mnemonic value, although accelerators that use function keys are acceptable.

Applications should not use accelerators that are a combination of the modifier <Alt> and letter keys to avoid conflicts with mnemonics. For example, <AU> <E> as an accelerator for Exit conflicts with the use of

<AU> <E> to pull down the Edit Menu since it is the mnemonic for the Edit CascadeButton in the MenuBar.

Similarly, applications that involve text entry should not use accelerators that are combinations of the modifier <Shift> and letter keys to avoid conflict with the text entry commands. Applications that expect field controls to have bindings that include combinations of the modifier <Ctrl>

and letter keys, such as text editors, should also avoid these combinations.

Accelerator bindings that use only one modifier are preferable to bindings that use two or more modifier keys.

6.2.3.7 Using TearOffButtons

Applications should use TearOffButtons in Menus whose elements are used many times in a row. If the semantics of the entries in a Popup Menu depend on where in a component it is popped up, the Menu should not include a TearOffButton, unless context-sensitive entries are disabled when the Menu is torn off. Menu entries in a torn off Menu should be enabled or disabled as appropriate when the state of the application changes.

After a user tears off a Menu, the Menu elements are placed in a DialogBox that is titled with the Menu title, and the Menu is unposted. The TearOffButton should be removed from the DialogBox, but, if it remains, it can be used to close the DialogBox.

Application Design Principles