CS302: Software Engineering

Guidelines for Defining the Menu Structure and Dialogue Flow 

The interface structure includes design of a menu structure and design of dialogue flow within the menu structure. Both designs are based on the PDFD and process hierarchy diagram developed during IE analysis. 

First, the menu structure is developed. Recall that the menu structure is a structured diagram translating process alternatives into a hierarchy of options for the automated application. The task hierarchy is analyzed to define the individual processing screens required to perform whole activities, and to identify the other processes and activities in the hierarchy which must be selected to get to the processing screens.

Let's walk through the development of the sample menu structure shown in Figure 10-7. The related process hierarchy diagram is shown as Figure 10-52 with the individual processing screens, selection alternatives, and hierarchy levels identified. For each level in the hierarchy, we identify a level of menu processing. Using simple bracket structures to translate from the top to the bottom of the hierarchy, we first define the options for the first level menu (see Figure 10-53). Next, the menu options for the first process level of the hierarchy are shown in Figure 10-54. Finally, the remaining detailed processes are added to the diagram (see Figure 10-55). 

If, for any reason, the hierarchy or lower-level processes are in doubt, review the proposed menu structure with the users before proceeding. If the process hierarchy diagram is accepted as correctly mirroring the desired functions in the application, proceed to the next step, defining the movements between menu items.

FIGURE 10-43 Request Processing Action Diagram Constructs

FIGURE 10-44 Open Rental Action Diagram Constructs       FIGURE 10-45 Video Returns Action Diagram Constructs

Traditionally, applications were constrained to moving top-to-bottom-to-top with no deviation. Anyone who uses such an interface for long knows it is irritating to wait for some menu that is unwanted and to enter choices purely for system design reasons. The decisions should relate to application requirements as much as possible. For instance, security access control requirements can be partially met by restricting movement to functions as part of dialogue flow. The decisions about legal movement should be made by the users based on recommendations by the designers; although frequently, dialogue flow decisions are made by the SEs. In general, if the users are functional experts, an open design that allows free movement should be used. If users are novices or not computer literate, a more restrictive design should be used to minimize the amount of their potential confusion. 

Figure 10-56 shows types of arrows used to depict movement between levels of a menu structure. In a small diagram, with less than ten screens, only single-headed arrows are used, and at least two arrows are drawn for each entry: one entering and one leaving (Figure lO-56a). In a large diagram, with over ten screens, the triple-headed arrows can be added to the diagrams to depict call-return processing (Figures lO-56b and lO-56c).

FIGURE 10-46 Late Fee Action Diagram Constructs      FIGURE 10-47 New Rentals Action Diagram Constructs

An example of restricted screen movement that might be designed for novice users is shown in Figure lO-57a. In the diagram, all movement is to or from a menu. The diagram in Figure lO-57b shows that any level of upper menu might be reached from the lower levels. This speeds processing through menus and is preferred to the design shown in Figure lO-57a which only allows a process to return to the menu level from which it was activated. Restrictive dialogue flow (Figure lO-57a) is the type of design that is most likely to waste user time and become annoying. 

Experts and frequent users usually are provided more alternatives for interscreen movement because they become proficient with the application. Unrestricted screen movement is desirable for these users. An example of unrestricted movement in screen design is shown in Figure lO-57c. In the example, the user begins at the main menu and may move down the hierarchy in the same manner as a novice, or may move directly to a process screen, at the user's option. Unrestricted movement requires the design and implementation of a command language or sophisticated menu selection structure that is consistent with the basic novice menu selections, but adds the expert mode.

FIGURE 10-48 Payments, File Update and Printing Action Diagram Constructs

Unrestricted movement can be costly and error-prone, which are the main reasons why it is not prevalent. The added cost is due to increased access control structure that must accompany an open movement design. The added errors are from a need to provide a specific location on the screen for entry of the expert's direct screen requests. Each request must be checked for access control and legality, plus the current context (i.e., screen and memory information) might need to be saved for return processing.

FIGURE 10-49 ABC Consolidated Action Diagram

FIGURE 10-50 ABC Action Diagram with Consolidated Open Rental Processing

Upon completion, the menu structure and dialogue flow diagrams are given to the human interface designers to use in developing the screen interface (see Chapter 14). The dialogue flow diagram is also used by designers in developing program specifications. Before we move on, note that even though the menu structure is identified, the human interface may or may not be structured exactly as defined in the menu structure diagram. The human interface designers use the menu structure information to understand the dependencies and relationships between business functions, entities, and processes; they may alter the structure to fit the actual human interface technique used. If a traditional menu interface is designed, it could follow the menu structure diagram.

ABC Video Example Menu Structure and Dialogue Flow 

The menu structure is derived from the process hierarchy diagram in Figure 10-58 (reprint of Figure 9-26). First, the activities from the decomposition form the main menu options (see Figure 10-59). The processes are used to develop submenu options. Then, the lowest level of processing completes the simple structure (Figure 10-60).

Notice that all Rent/Return processing is expressed in the first menu option even though we have many subprocesses in the hierarchy. Rental/return has many subprocesses performed as part of the hierarchy diagram. Unlike the other subprocesses, rental/return does not have individual menus and screens for each subprocess. Rather, rental/return requires a complex, multifunction screen with data from several relations and processing that varies by portion of the screen. The subprocesses for rental/ return, then, describe actions on portions of the screen. You cannot tell from the decomposition diagram that rental/return has this requirement; rather, you know from application requirements (and experience) what type of screen(s) are needed. An incorrect rendering of the menu structure, such as the one in Figure 10-61, would look weird and should make you feel uncomfortable about its correctness. 

Second, notice that we do not indicate access rights for any of the processing options on the diagram. The security access definition is superimposed on the menu structure by the interface designers to double-check the design thinking of the process designers. If there is an inconsistency, the two groups reconcile the problems. 

Next we develop a dialogue flow diagram from the menu structure diagram. The rows of the dialogue flow diagram correspond to the entries in the menu structure (Figure 10-62). Rows are entered by level of the hierarchy by convention.

FIGURE 10-51   ABC Action Diagram with Data Entities and Attributes

We need to decide how much flexibility to give users, keeping in mind the security access requirements and the users' computer and functional skills. Users are mostly novices with little computer experience. The average job tenure is less than six months. Data and function access for clerks are unrestricted for customer, video, and open rentals add, change, and retrieve functions. Other options are more restricted in terms of which user class can perform each function.

First we define the options. We could define flexible movement between those options only, and restrict movement to other options through the hierarchy. Top-down hierarchic access is possible. We could allow hierarchic access combined with flexible 'expert' mode movement throughout the hierarchy, constrained by access restrictions. 

For each option, ask the following questions. Does Vic have a preference? Which best fits the user profile? Which is the cleanest implementation, least likely to cause testing and user problems?

FIGURE 10-52 Example of Process Hierarchy Diagram

Vic, in this case, has no preference. Having never used computers, he has no background that allows him to make a decision. He says, "Do whatever is best for us. I let that up to you. But I would like to see whatever you decide before it is final." This statement implies interface prototyping, which should always be done to allow users to see the screens while they are easily changed.

Most of Vic's employees work there for 1 Y2 years and have little or no computer experience. Therefore, screen processing that is least confusing to new users should be preferred. Usually, novices prefer hierarchic menus, providing the number of levels do not become a source of confusion. Also, the simplest implementation is always preferred; that is, the hierarchic menu option. 

Based on the answers to the questions, we should design a restrictive, hierarchic flow. As Figure 10-63 shows, this design is simple and easy to understand. The dialogue flow and screens should be prototyped and reviewed with Vic at the earliest possible time to check that he does not want an expert mode of operation.

FIGURE 10-53 First-Level Menu Structure

You might question whether the movement from rent/return to customer add and video add should be on the dialogue flow diagram. This is a reasonable concern since the process of rent/return does allow adding of both customers and videos within its process. The issue is resolved by local custom. In general, given the option, such flexibility should be shown on the diagram for clarity and completeness. Sometimes, local convention or a specific CASE tool requirement do not allow such completeness.