General Design Guidelines
Menus as the Basis of the Interaction
With few exceptions (see below), the user must be able to call all functions of a task (= application functions) and therefore all functions assigned to function keys from the pull-down menus.
If all application functions are displayed in menus, the user is not required to remember the commands (which is very difficult for some people) but only needs to recognize them (which is a lot easier). This way, the user can use the available system functionality more efficiently.
Functions Not in Menus
There are some exceptions to above mentioned guidelines. The following functions never appear in pull-down menus:
To choose a menu option, the user has to be in the menu bar.
These basic interaction functions are used very frequently and, as a result, are learned fast. They would therefore use up space in the menu without actually being needed. In addition, the functions can be more directly be initiated by the user. With graphical user interfaces, these functions are therefore controlled by interaction mechanisms which allow a more direct and quicker execution (for example scroll bars, scroll arrows in the
Choosing Menu Options to Execute Functions
The function selection via menus follows the object/action approach: First, the user has to specify the object class or transaction class, and then the corresponding action (see
Object-Oriented User Interface).The object to be processed is generally in the menu bar and the actions that can be performed on it are on the first level of the pull-down menu.
If the object is in the pull-down menu, you can write the action on the same level directly behind the object but only for few actions. If the action explicitly results from the context of the object selection, you can omit the specification of an action.
Depth vs. Width of Menu Structures
The total quantity of functions for a menu bar option should be arranged on as few menu levels as possible.
You should use a deep, tree-like structure only if this helps to make the business logic of the application more transparent. This also supports the user in choosing alternatives. However, grouping related functions generally results in a quicker interaction and a better distinction with regard to the contents of options displayed in parallel. Furthermore, menus with a flat hierarchy speed up interaction if the user only work with keyboard identification codes.
This guideline is completed and modified by the two following rules. They are to be used together.
Quickly Accessing Frequently Used Functions
If possible, the user should be able to choose the most important and most frequent functions on the first level of the pull-down menu.
In some cases, there will be many options in a menu which then to a certain extent would have to be moved to the second or third level. If there is still space for further options in the menu bar, such a menu can be split into two titles of the menu bar with less options on the first level. For the two new menu titles, you should choose different terms that are typical for the subordinate menu options.
Hiding Rarely Used Functions
Functions that are rarely used or complex functions that are only used by few people, should be "hidden" on a second or third level.
Upper/Lower Case
Menu options can consist of several words which are to be written in lowercase letter, except for the very first letter of the menu title which is always capitalized.
Status of the Menu Bar Options
Menu bar options that contain at least one option in the pull-down menu initiating a function in the current dialog state, are to be displayed as being active (generally black). If, on the other hand, the pull-down menu does not contain an option initiating a function in the current dialog state, the respective menu bar option is to be displayed as being inactive (dimmed, generally gray). The pull-down menu is opened anyway. (see Technical Notes)
When the menu title appears gray, it indicates that all functions of this menu cannot be chosen currently. However, to make the system functionality as transparent as possible and to keep the interaction with the menu bar constant, the user can nevertheless open the pull-down menu upon request. This increases the feeling of controlling the system and therefore its acceptance and reduces the number of interaction rules to be learned.
Consistency of the Menu Bar
The menu bar should be consistant within a task.
All menu bar options of the data screens should also be included on the initial screen. This avoids any inconsistency caused by the initial screen having an additional, unclear status between application level menu and task level menu.
Status of the Pull-Down Options
If a pull-down option is displayed as being inactive, the function is neither displayed as function key nor as a pushbutton.
The inactive display signals that the user is not required to open the subordinate levels of the pull-down menu because none of its functions can currently be selected. However, to make system functionality as transparent as possible and to keep the interaction with the pull-down menu constant, the user should nevertheless be able to open the pull-down menu upon request.
Consistency of the Pull-Down Menus
Functions, that cannot be chosen in individual dialog states of a task, are to be displayed as being inactive and are not to be hidden, regardless of the user authorization.
As far as possible, the pull-down menus should have the same options within a task. This also applies to the entire application, if possible.
Dimming functions the user cannot choose because a particular authorization is required, is to enable communication between users with different authorizations. Furthermore, changing an authorization does not require to change the menu.