MenusGeneral 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:
You can take some preventive measures to overcome these problems:
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 |