What are the advantages of menu-driven system?

Answer 1

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.