Below are just some considerations that can provide you with food for thought. Unfortunately, I did not understand the context of your question. For example, from whose perspective is the question referring to, the end-user's or the programmer's?
Note: Remember, not all programs have a graphical user interface. Not all programs operate as Windows does. Some program utitlize menus that are actually permanent fixtures on the screen (i.e., not l drop-down or pop-up/context menus).
____________________________________
Menu-driven program refers to program whose user interface interface. employs menus.. The antithesis of a menu-driven program is a command-driven ( or function-driven) program. Menu-driven programs are interactive, as opposed to command-driven programs. Command-driven applications (i.e., DOS prompt) are well suited for doing batch processing, log writing and viewing, and low-level systems analysis and testing.
Menu-driven means relying heavily on menus and providing the user with total control over the manner in which the program operates.
In a menu driven program, the user is given a set of choices of things to do (the menu) and then is asked to select a menu item. The driver then calls an appropriate function to perform the task selected by the menu item. A switch or If statement seems a natural one for handling the selection from the menu.
___________________________________________________________________________
ADVANTAGES
___________________________________________________________________________
Most end-users are quite familiar with using menus to issue commands to a program.
___________________________________________________________________________
Menu's are a convenient way to bundle related common commands, i.e., under a single main menu. This allows a programmer to create a separate module for each type of menu functionality.
Menu-driven programs are especially good for mobile devices, due to therr small user interface and input/access controls.
___________________________________________________________________________
A large program should be developed incrementally, i.e. in small steps. The overall program logic consisting of major sub-tasks is designed first without the need to know the details of how these sub-tasks will be performed. Menu driven programs are particularly well suited for incremental development. Once the main logic is written, ``dummy'' functions (sometimes called stubs) can be written for each task which may do nothing but print a debug message to the screen. Then each sub-task is implemented and tested one at a time. Only after some of the basic sub-tasks are implemented and tested, should others be implemented.
At any given time during program development, many sub-task functions may not yet be implemented. For example, we may first implement only get data, print data, and help ( help is easy to implement; it just prints the menu). Other sub-tasks may be delayed for later implementation These stub-procedures (place-holders) are in skeleton form and can be modified as needed without changing the main program logic. In programming languages like C or C++, it should be noted that the linker will require that all functions used in the driver be defined. The stubs satisfy the linker without having to write the complete function until later.
___________________________________________________________________________
A menu needs to be useable. Let's take the example of database program. A menu is, in effect, a conceptual mold of what is happening to the database. In this respect, the menu system needs to be easily understood. It needs to be represented as a complete system that is neither overtly complex nor monotonous for the end user.
___________________________________________________________________________
A menu-driven program is normally easier to use than a command-driven program, particularly for those not particularly well expeirenced in computer usage.
___________________________________________________________________________
Almost all programs on the market have standard features which include menu-driven interfaces.
___________________________________________________________________________
As a rule, menu-driven systems are easier for the inexperienced user to learn, whereas, command-driven systems do not slow down experienced users who already know the necessary choices. Most new users cannot remember commands like "T/B4/BN4/C5/E5:C5/D5:B4/C5;". In a non-Windows environment, experienced users may not want to wait while the program printss a menu of familiar choices. This situation occurs where the menu choices are displayed as an actual list, and not as a Windows drop-down menu. Although most programs use only either a menu-driven or a command-driven approach, the best ones provide menus for new users, and let experienced users avoid the menus once they have learned the necessary commands.
___________________________________________________________________________
DISADVANTAGES?
___________________________________________________________________________
Because menu-driven programs usually have redundant ways of doing things, you may have to do extra coding, i.e., synchronize the menu items' states with that of their counter-parts on the toolbar or context menu. You must also show, hide, disable, check, uncheck the menu items where appropriate. Some menu items are dynamically created, i.e., recently view documents. This requires additional coding.
___________________________________________________________________________
If the programmer does not take care—or is overly ambitious—a menu can easily become too cluttered if an abundance of selections is available for the user. Furthermore, depending upon the size and resolution of the display, if the menu is an in-place one (versus a drop-down menu), it could occupy too much screen space, hindering the area available for actual program display. This situation can especially arise in a non-Windows program. On the other hand, putting too few items on a menu will bring about unnecessary delays switching between menus, further causing the work to be both repetitive and tedious.
Menus can end up having too many commands or sub-menus or sub-sub-menus
___________________________________________________________________________
When does the product functionality stop and the preference of the user begin? In the interest of making a menu functional, the user needs to be comfortable with the options that are available. What the project calls for, and what the user wants,can be two different agendas. In designing a menu, it must be both functionable from a programming standpoint and easy to navigate for the end user.
___________________________________________________________________________
Even among menu-driven systems, there can be important differences.Some programs require that you first move a highlight bar onto your chosen command in the list by either pressing the cursor control keys or moving the mouse. Such programs let you press a key (typically the
or key) or push a utton on the mouse to initiate the command only when the correct command is highlighted.
Other programs let you press just the first letter of the command you want reardless of which choice is highlighted, and without having to press anything else. that approach to menu-drive system saves keystrokes; and, in the long run, it can increase the user's speed in command entry considerably.
One way to speed up command entry is by storing commonly used commands in macros, which are abbreviated keystroke sequence that substitute longer text strings in their place. By assigning a lengthy command string to a macro, you can then type the shorter macro each time you want to use the longer command string.
___________________________________________________________________________