Menus are the primary means of organizing 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 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 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 associated Popup Menu. Popup Menus should only be used to provide shortcuts, since new users of an application may not realize or remember that they exist. Even within a single control, such as a Canvas, the contents of a Popup Menu can depend on the position within the control, or the state of the elements at that position, such as whether the Menu is popped up 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.
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 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:
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.
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 MenuBar. 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.
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.
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.
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.
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 and letter keys to avoid
conflicts with mnemonics. For example,
[E] as an accelerator for Exit
conflicts with the use of
[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 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
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.
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.