Menus
General Design Guidelines | R/3 Menus - Overview of the Levels | Menus at the Application Level | Menus at the Task Level
In the early computer times users had to issue text-based commands to the computer. These commands had parameters and lots of options and were usually rather cryptic. Users had to remember these commands which was very difficult (and still is). Menus provide users with a list of the available commands or options. The user can select the wanted command from a list and has only to recognize the command. This is much easier than having to remember it. Menus help in particular beginners and casual users to exploit the available system functionality.
That is not the whole story, however. Menus may require a lot of screen space when they list all available commands. If the list of commands is long users have to search for the commands. This may take quite a long time. There are even more problems: What can be done if the list of commands is longer than would fit on the screen? Should users scroll the menu list in this case? Where should the "real" information go when the menu occupies the screen?
One solution to these problems is the now common pull-down menu. There are lots of variants of them, but the basic principle is always the same: The functions are grouped under some - hopefully - descriptive label. Only the group names are displayed on the screen, for example at the upper border of the screen or of the application window. The functions themselves are arranged in submenus that are usually hidden.
To access a function, the user selects the group where he or she assumes the function should be. A menu pops up, and the user selects the desired function from the list of menu items. Sometimes menus are organized in even deeper levels. Then the user has to open cascading menus, maybe over several levels. This way the pull-down menu forms a hierarchical structure that comprises most or all application functions.
This leads us to some of the problems of pull-down menus:
- Functions may be buried deeply in the tree-like menu structure and difficult to find.
- Users may not know where to search for a function.
- Users may be "lost in function space": The space of available function offers lots of opportunities, but the users do not know which steps actually to take; they have no guidance from the system.
You can take some preventive measures to overcome these problems:
- Look for descriptive labels that the users understand if you group functions.
- Consider where you put functions. Ask other people, whether they would look for a function at the location where you placed it.
- Do not bury functions too deeply. They may never be found and they are cumbersome to access. Put only seldom-used functions into cascading menus.
- Do not make lists of action menus too long to avoid excessive search. Though the magical number 7 may often be too small, 25, for example, may be far too large.
- Place functions in standard locations. Users will look for the functions in these locations, because other applications provide them there, too.
Today we recommend the use of pushbuttons to offer functions which are appropriate for the task the user is currently performing. This helps in many cases to provide only slim menus while focussing on the functions which are relevant to the course of user action.
Source: SAP R/3 Style Guide