A few years ago the idea of menu selection simply meant that at some point
in the program a list of options would be presented and the user would select a
number or letter corresponding to the option desired. Today, menus take on a
much wider range of form and diversity of application. Although the concept
is much the same, the appearance and the power of menu selection has changed as
exemplified by systems such as SmallTalk (Goldberg & Robson, 1979; Tesler,
1981), ZOG (McCraken & Akscyn 1984; Robertson, McCraken, & Newell,
1981), and a host of commercially available software that spans the whole gamut
of applications and user audience.
In this chapter menu structure, physical format, and response requirements will be discussed. Menu structure refers to the branching capability of the menu. Menu structure determines the extent to which the current selection affects subsequent options. We will see that some highly constrained menus serve a purpose in determining the proper sequence of transactions between the user and the system. On the other hand, users often wish to or need to jump to another activity. Menu selection systems in the past have been criticized because they have not allowed the user to escape from a particular menu path in order to complete some other task and then return to the previous point in the menu. A few systems are beginning to allow the user to perform tasks according to the user's plan of action rather than a constrained path of options. These menus allow the user nearly unlimited control over program flow to jump to any location desired.
The physical format of the menu may either facilitate the user or retard performance depending on how well it conveys information. The format should highlight the options and organize them in a meaningful way to help in visual search; it should help to set the context of where the user is in the flow of control through the menu structure; and it should aid the user in the decision process.
Finally, the user must have some means of indicating his choice. Menu selection systems vary widely in this respect. The response may be a number; a letter; a string of characters; a special function key; the positioning of a cursor using sequence of arrow keys, a mouse, a trackball, or a joystick; or via a touch screen or light pen. The system must clearly indicate how the user is to make a selection. Responding to menu items may be dissociated from the main task (e.g., using a mouse to make selections in a word processing application where the main task is keyboard entry) or it may be integrated with the task (e.g., using a touch screen to indicate moves in a chess playing program).
In the following sections various attributes and aspects of different types of menu systems will be discussed. The intent of this chapter is to lay out all of the possibilities for designing a menu selection system before considering the cognitive processes by which users navigate through these systems.
2.1 Menu Structures
The user's cognitive structure of a task embodies a set of expectations about what happens when and what leads to what. We will see that menu structure should be consonant with the user's cognitive structure. There should be a graceful guidance of activities that meshes with the user's expectations. For example in a financial transaction, if the system asks "Would you like to (1) deposit funds or (2) withdraw funds?" and the customer chooses the first option, he then expects to be asked something like, "Would you like to deposit to your (1) checking account or (2) savings account?" Program flow conforms to the user's schema of the task. On the other hand, it would unnerve the customer to be asked at this particular point,"Would you like to rent a safety deposit box (yes or no)?"
Menu structures embody the flow of the control given to the user in a task. The formal structure of a menu system can be defined using the concepts of set theory, abstract algebra or state-action graphs as has been done by Arthur (1984) and others. However, from the perspective of the user, it is more important to identify the general types of menu structures and the sense in which they control program flow. These are the single, sequential linear, simultaneous, hierarchical, cyclical/acyclical, and event menus.
2.1.1 Single Menus. Menu selection in its simplest form is a single menu frame that is presented to the user in order to elicit input. Single menus conceptually involve a one-shot choice rather than a series of choices. The user views this selection in isolation from other aspects of the task. For example, in a game program a menu might be presented as follows: "Select level of difficulty: (1) easy, (2) moderate, (3) hard." The user need only consider the immediate consequences of his choice and need not factor in other choices. Although a program may include a number other single menu choice points ( such as "Play another game (Y/N)?"), the user does not perceive these menus as forming a series of choices.
Even in its simplicity, the single menu involves an iterative cycle in which (a) the menu frame is presented; (b) a procedure is executed to get the user's selection; (c) an error checking routine is called to determine if the the input is valid; and (d) if it is valid, a parameter is set or a procedure is executed as specified by the input or (e) if it is not valid, an error message is generated and program control returns to b. The cycle for the single menu is shown in the shaded box in Figure 2.1.
When one menu frame naturally leads to another or when a set of menus are clustered together, the user begins to perceive a series of choices. This series defines a path going from one menu frame to another.
2.1.2 Sequential Linear Menus. Linear menus have only one path. Menu frames are presented in a preset order for parameter specification or for data entry. In essence all flow of control is determined by the system. The path of a linear menu system may extend from 2 to n levels and incorporates an iteration of single menu frames as shown in the whole diagram of Figure 2.1. The system is initialized to the first menu frame in the series; it presents a single menu, and advances to succeeding menu frames until it reaches the terminal node. Figure 2.2 shows such a menu applied to a questionnaire.
The two main problems with linear menus are that (a) the user may need to go back and change an answer in a previous menu and (b) the user may want to answer the questions in a different order than preset by the system. Solutions to the first problem can be handled using an undo command that jumps back to a specified frame; but in general, it is rather awkward and confusing for the novice user to control movement along an extended linear path.
2.1.3 Simultaneous Menus. Simultaneous menus solve the problems caused by preset orders of menu frames. All menu options are available simultaneously. The user can enter the responses in any order as one could in filling out a form. These menus are, in fact, a form fill-in method with the restriction that items are selected rather typed into fields. Questions may be skipped and returned to later or simply left blank. Figure 2.3 gives an example of the simultaneous menu in setting parameters of a terminal communications program.
The problem with the simultaneous menu is that for a large number of options, it may not be possible to display all of the choice sets on one screen and some mechanism must be used to scroll or page to other parts. An additional technical problem, is that response input must define both the menu number and option number. When keyboard input is required, it is rather tedious to enter both such as "12A" for option A of menu 12. On the other hand, using direct selection with a mouse or light pen, the cursor location identifies both the menu and the option simultaneously.
Although simultaneous menus are appealing in many applications, sometimes the preset order of the linear menu is preferred. This is particularly true when there are underlying relationships or interactions among the options. When the interactions are strong in that they make other options inappropriate, the menu system should have a hierarchical structure that reflects these relationships. For example, if one frame asks, "Do you own a personal computer?" and the user indicates, "no," then it is not appropriate to ask, "Which of the following computers do you own?" More complex menu structures allow branching to maintain a natural series of questions.
2.1.4 Hierarchical Menus. The hierarchical structure of a menu results in the increasing stepwise refinement of choice. In data base search, it may be the specification of categories, subcategories, and so on. In parameter specification and data entry, it is the selection of options, suboptions, and so on.
The hierarchical menu can be represented as an inverted tree structure leading to more and more branches. Hierarchical menus may be either symmetric or asymmetric as shown in Figure 2.4. Symmetric menus vary only in depth and breadth. Depth is defined as the number of levels that one must traverse to reach the terminal node. Breadth is defined as the number of alternatives at each level. The structure of symmetric menus can be defined by a series of numbers indicating the number of alternatives at each level. For example, the menu structure in shown in the top panel of Figure 2.4 is indicated by 3x3. On the other hand, a 4x2x8 menu would have 4 alternatives at the first level, 2 at the next level, and 8 at the last level, resulting in 64 terminal nodes. In general, symmetric menus with a constant breadth of k alternatives at n levels will have kn terminal nodes.
Symmetric menu structures are rare in real world system owing to the asymmetric nature of categories and subcategories. However, they are used quite often in empirical research on menu selection because the number of alternatives at each level and the length of all possible paths are constant across the tree. When this is the case, it is easy to vary depth and breadth and evaluate their effect on performance. Furthermore, symmetric menus have the advantage that users can expect the same number of alternatives at each level and the same number of levels. Sometimes this constancy is important in routine tasks. It sets a simple pattern of response on the part of the user who is often anticipating the next transaction with the system.
Asymmetric menus, however, are the rule in most practical applications. The number of alternatives varies throughout the structure and the length of paths to terminal nodes is not necessarily constant. Although menus do not have a constant depth and breadth, they may be described statistically by their average depth and breadth. The amount of variability in the structure may be assessed by the standard deviations of depth and breadth. The definitions of the average and standard deviation for depth and breadth, however, are not straightforward. One could look at the average path length for all possible paths and the average number of alternatives across all frames; however, this does not take into account the actual utilization of the menu. If a user visits all terminal nodes with equal frequency, he experiences a different average depth than if he makes all choices with equal probability. Consequently, a weighting scheme needs to be applied in assessing average depth and breadth. For average depth, we may use (a) equal weighting of all possible paths, (b) weighting by probability of path given equal choice probability, and (c) weighting by probability of path given observed choice probabilities. The equations for the weighted average and weighted standard deviation for depth are:
Avg. D = [[Sigma]] wini / [[Sigma]] wi (1)
_________________________
Sd. D = [[radical]]( [[Sigma]] wi ( ni - Avg. D )2 / [[Sigma]] wi ), (2)
where ni is the number of nodes visited for path i and wi is the weight for path i. Table 2.1 gives an example of the weights and computations for the asymmetric menu shown in Figure 2.5.
For breadth, one may use either (a) an equal weighting of the number of alternatives across all nodes or (b) a weighting by the frequency of times the node is visited. In the second case, these frequencies may be determined by (a) equal path frequency, (b) equal choice probability, or (c) observed choice probabilities. The equations for weighted average and weighted standard deviation of breadth are:
Avg. B = [[Sigma]] wj kj / [[Sigma]] wj; (3)
_________________________
Sd. B = [[radical]] ( [[Sigma]] wj ( kj - Avg. B )2 / [[Sigma]] wj ), (4)
where kj is the number of alternatives at node j and wj is the weight for node j. Table 2.2 gives an example of these weights and computations for the asymmetric menu in Figure 2.5.
Table 2.1
Measures of Depth in Asymmetric Menus
___________________________________________________________________
Probability Weights __________
Path Depth Equal Path Equal Choice Observed Choice*
1 1 1/11 1/2 .8000
2 2 1/11 1/6 .1200
3 3 1/11 1/12 .0100
4 3 1/11 1/12 .0100
5 3 1/11 1/24 .0120
6 3 1/11 1/24 .0180
7 3 1/11 1/24 .0240
8 4 1/11 1/96 .0015
9 4 1/11 1/96 .0015
10 4 1/11 1/96 .0015
11 4 1/11 1/96 .0015
Average 3.09 1.87 1.29
Standard Deviation .90 .97 .62
____________________________________________________________________
* Calculated from the hypothetical choice probabilities shown in Figure 2.5.
Table 2.2
Measures of Breadth in Asymmetric Menus
_______________________________________________________________________________
Weighting __
Frame Breadth Equal Frame Equal Path Equal Choice Observed Choice*
1 2 1 11 1 1.000
2 3 1 10 1/2 .200
3 2 1 2 1/6 .020
4 4 1 7 1/6 .060
5 4 1 4 1/24 .006
Average 3.00 2.94 2.49 2.26
Standard Deviation 1.00 .85 .69 .54
____________________________________________________________________________
* Calculated from the hypothetical choice probabilities shown in Figure 2.5.
Hierarchical menus have the virtue of allowing the user to branch as a part of the flow of control. No such branching is allowed in linear menus. However, the order of branching and structure of the branching in the hierarchy is preset. The flow of control is one-way, top down. The disadvantage is that the hierarchical order may not fit the user's conception of the task flow of control. It is often the case that users unfamiliar with the menu need to back up the tree, change a previous selection, or start over again. The user may not consider answering questions in the order that the hierarchy dictates or the user may not know what suboptions the system will offer given the selection of a particular choice. The first problem is that of cognitive representation. The second is the problem of uncertainty. It will be shown in subsequent chapters that menus should be designed so that (a) their hierarchical structure is consistent with user expectations and (b) they reduce as much as possible the uncertainty of choice. In an effort to alleviate these problems, most hierarchical menu systems provide options or commands that allow the user to move to the previous frame or to return to the main menu. Although these are considered as solutions to the problem, they are often cumbersome to the user.
2.1.5 Connected Graph Menu Structures. The most general of the sequential menus is the connected graph network. A connected graph is a set of nodes connected by arches such that all nodes are directly or indirectly linked. Movement through the structure of menu frames need not be restricted to a hierarchical tree but may include links from any node to another in the network. Technically, hierarchical trees that allow the user to move to the previous node or to jump to the top of the tree are also connected graphs. However, in the present discussion, we will use the term "connected graph" to denote a menu system that does not embody the central idea of a hierarchy but rather that of a network of connected nodes. Consequently, from the the users perspective there is no sense of top-down traversal of the menu. Instead, it is a question of determining the path from Node A to Node B that accomplishes the task at hand. Network menus convey the idea of a geographical map of a road system. One may want to find the fastest (or shortest) route from Point A to Point B or one may want to select the route between the two points that passes through Points C, D, and E as well.
Figure 2.6 shows several examples of connected graphs. These structures may be cyclical if they either allow or require multiple passes along the same path to accomplish a function or acyclical of they do not. For example, Graphs A and B are cyclical; Graph C is acyclical; and Graph D is for the most part acyclical but contains a cyclical part. Connected graphs may also be characterized as symmetric or asymmetric. For example, Graphs A, B, and C are symmetric and Graph D is asymmetric.
Connected graphs like the hierarchical graphs vary in terms of the number of menu frames, average number of alternatives, and length of path. Estimates depend on how the values are weighted. As before they may be given equal weights or weights that depend on menu use and probability of paths. A major difference between connect graphs and hierarchical menus is that in connected graphs there may be multiple paths between two nodes. Menus vary in terms of connectivity, that is, extent to which nodes are linked by multiple paths.
The connected graph is generally used to provide the user with a full sense of control over the flow of actions. These systems are found most often as menu replacements of command languages for operating systems and application programs. For the control of program flow, the connected graph is typically sequential. The options open to the user are limited to the number of paths leading from the current node. While this is limitation is helpful in providing focus for the user, it may also prove frustrating when there is a need to perform a concurrent task unrelated to the current location in the graph or a need to break the current flow of control and jump out of the graph to select some new entry point. Event trapping menus allow for this level of control are are described in the next section.
2.1.6 Event Trapping Menus. Event trapping menus provide in essence a set of simultaneous menus superimposed on a sequential hierarchical or connected graph menu system and may be activated at any point in a task. Typically, these menus appear as special function keys or as pull-down or pop-up lists of options. In the case of special function keys, the user selects a menu or item in a menu by pressing a specially denoted key. In the case of pull-down or pop-up menus a cursor is placed on the menu label and the items are revealed. Figure 2.7 shows such a system with a menu bar at the top of the screen and one of the lists pulled down.
Event trapping menus may be characterized by the number of special function keys or the number of items in pull-down menus. Furthermore, the selection of an item generally serves one of three functions: (a) It may immediately change a parameter in the current environment or perform some function without leaving the current environment. For example, in a word processing program one may select the option to left and right justify the text. Once the selection has been made, the user continues where he left off. (b) It may call a subroutine that momentarily takes the user out of the current environment to perform some function and then returns to the previous environment. For example, in a file management application, the user may be scrolling through file entries and desires to change the format. He would select from the menu bar the option to format and then enter an environment that allowed redefinition of the format. Upon completion, he would automatically return to the previous environment. (c) Finally, it may exit the current environment and move to a totally new environment. For example, the user may select "quit" to return to the operating system or select among other application programs. Event trapping menu systems vary in term of the number and mix of these three types of items. The greater the flexibility and complexity of a system, the greater the number of event trapping options.
Event trapping menus provide an ever present background of control over the system state and parameters while the user is working on a foreground task. The menus are constantly available and help to establish a sense of context while things are changing in the foreground. The menu bar may change from one application program to another, but typically there is some degree of communality between the event trapping menus and some degree of distinctiveness that helps to remind the user where he is. However, if the meaning of special function keys and the particular items in pull-down menus vary greatly or change without warning, the user may experience loss of position or disorientation and make habitual errors. We will see in the next section how the user must be kept informed of the current state of the system in terms of information conveyed to the user by the menu frame.
2.2 Menu Frames
The menu frame consists of the context, the stem, the leaves, and the response instructions. Needless to say, menu selection systems vary drastically in terms of what information is presented, the amount of information, and the format of the frame. The design of a particular system must take into consideration how much information the user needs to work meaningfully with the system. In general, one would expect that users who are unfamiliar with the menu need more information. As users become more and more experienced, verbose descriptions may be replaced with short mnemonic reminders. In the following sections variables pertaining to the amount and type of information in the menu will be discussed.
2.2.1 Context Information. The context provides feedback that tells the user where he is in the process, what the past choices and outcomes were, and possibly how much further it is to the terminal node. Context information is extremely important in complex menus where the user may experience a subjective loss of position and associated disorientation. The user may not recall how far down the tree he or she has come, or how successful past choices have been in getting closer to the goal, or how many more choices must be made before reaching to the goal. It is too often the case that halfway through a search, the user asks, "Now what was it that I was looking for?" Human memory, being what it is, needs assistance.
At a minimum, the frame should provide information that the user is accessing the right function. In a bank transaction, if the customer has selected his checking account, then all further choices (balance, withdraw, deposit) should be clearly in the context of the checking account. This feedback provides the user constant assurance that he is on the right track. On the other side, context information should not be overly verbose. If it is, it obscures the current choice and may add to the confusion.
Context may be established by various methods of linkage between successive menu frames as illustrated in Figure 2.8. The most fundamental linkage is merely the temporal sequence of one frame following the selection of an option in a previous frame. Temporal sequence implies a cause-effect relationship; however, it does not indicate the nature of the relationship between one frame and the next. The context established by temporal linkage decays with time and may need to be maintained by other methods of linkage.
Verbal linkage may be accomplished by using the previously selected option as the title for the next menu frame. The title may be cumulative as one goes further along a path. For example, in a video text service the title of a menu frame may be "News: New York Times: World News: India: Today" indicating the path to the current set of options which may be a list of stories.
Spatial linkage may be accomplished by graphic methods that preserve temporal linkage and enhance verbal linkage. In the bottom panel of Figure 2.8, the user selected the second option. A link is shown by displaying the next menu frame in a window overlapping the previous frame. The complete path down a menu tree may be shown as a series of overlapping frames in a single view. Linking information such as this can provide the user with a sense of progress and distance from the start to the goal.
2.2.2 Stem Information. The stem provides the label for the current set of choices. It may be merely the beginning of a question: "Would you like to ...?" or it may be the label of the alternative selected in the previous frame. For example, if the user were asked what communication parameter he wished to change and he selected "baud rate," the stem might be "Select baud rate:" The stem may be merely the current choice or it may include a record of all choices in the path up to the present choice. In nested hierarchical menus, the stem information may increase with each choice. Selections may include a trace of the whole path down to the current point. For example, along the lines of the Dewey Decimal System a stem in an information retrieval system might be: History|U.S.|Civil War|Economic|Impact on?|.
However, in generating stem information, there is a trade-off between specificity and clutter. When one could easily get lost in the maze of choices, cumulative stem information is essential. In other cases, however, the user may not need to see all of the stem information. Only that which is likely to be lost from short term memory and that is crucial to specifying the current choice must be displayed.
Stem information should provide the novice user with a rationale for why this choice is being made and what it's impact will be on subsequent processes. For the set of choices "Gothic, Roman, Modern," a stem such as "Select one of the following:" is devoid of information. The novice user does not know what they refer to or what the choice will affect. On the other hand, a stem such as "Set the type font to one of following for printing document:" provides that information. Research in cognitive psychology shows an enormous impact of providing a meaningful title on a person's interpretation and understanding of subsequent information (Bransford & Johnson, 1972). Similar results have been found for the effect of pictures (Butterfield).
2.2.3 Leaf Information. The leaves are the alternatives available to the user. Leaf information can vary from a brief listing of response options (e.g., "/A/T/S/Q/H/") to single words or phrases (e.g., "A--Author; T--Tile; S--Subject; Q--Quit; H--Help") or to a complete description (e.g., "A--Search for a book by author's name; T--Search for a book by it's title; S--Search for a book by the subject; Q--Quit searching and return to beginning; H--Request detailed help on searching for a book"). Leaf information is rarely complete in the sense of telling the user precisely what will happen if a particular selection is made. This is particularly true in nested hierarchical menus where the user would like to know what options will be available following a particular choice. Some systems provide the user with the ability to look ahead prior to committing to a choice. For example, some systems allow the user to move a scroll bar over an alternative and at the same time the next level of choices are displayed.
A number of guidelines have been suggested for the wording of leaf information. Alternatives should be unambiguous, mutually exhaustive, exhaustive, and nonoverlapping. The wording of alternatives should emphasize the critical features of their differences rather than similarity. Furthermore, it has been suggested that alternatives should be brief noun phrases (Shneiderman, 1986). Most of these guidelines have yet to be validated by empirical research.
The list of alternatives appearing in the menu frame may not necessarily be exhaustive. Many systems include constant alternatives that are not explicitly listed. Constant alternatives may be commands such as "move to the previous menu," "jump to the top," "help," or "quit." Generally, systems that include unlisted options include an option to display the full set of choices. This may be a question mark or "help." Generally, however, the command to list unlisted alternatives is also unlisted. One would expect that hidden alternatives are less likely to be used by novices.
2.2.4 Response Information. Finally, response instructions tell the user how to indicate the choice. For example, it may say "Enter the number of your selection and press the return key," or simply "Press key" when special function keys are labeled. Explicit instructions are often needed for first time users of the system. With experience, users gain a sense of what is expected of them by the system. Overly verbose instructions generally confuse the user or are simply not read. Instructions for response procedures which are different from the usual mode of interaction need to highlight those differences. For example, a response may be recognized and processed by the system (a) immediately after a single key is pressed, (b) only when terminated by pressing the return key, or (c) only when terminated by pressing a special "send" key. If users habitually terminate lines with a return key, errors and confusion may occur if a different type of response is required.
Response information may also include feedback or verification that a particular alternative was activated or is about to be activated. Systems vary from providing no feedback, to a single auditory beep that some response was recorded, to confirmation of the response in an input field or by highlighting the selected alternative.
2.2.5 Information Format. In early alphanumeric applications of menus, information was presented sequentially in the following order: context, stem, leaf, response. The three panels of Figure 2.9 show variations of this format. Systems have varied the degree to which the menu is organized on separate lines. Some systems have run all of the menu together in prose form (top panel of Figure 2.9); others have grouped information on one line (middle panel of Figure 2.9); and others have used multiple lines to list the options in an outline form (bottom panel of Figure 2.9). The number of possible layouts is unlimited; however, it is obvious that some layouts are to be preferred over others. The prose layout, for example, is particularly bad because the user cannot easily scan the list of items.
With the advent of graphics and screen based systems, other methods of displaying information have been used. Context is often given by the background on which the menu appears. A pop-up window or pull-down menu appears over the work at hand; thereby retaining a sense of position. The stem and leaf information in these systems remains much the same except that options may be graphically displayed using icons. Often the stem information may be implicit rather than expressly stated. It is expected that the layout of such information will greatly affect the user's ability to comprehend the functioning of the system.
2.3 Response Mode
The method of response selection is an important one and varies substantively among systems. We will see later that there are a number of cognitive implications regarding the response mode. Some response modes require a mapping of the alternative to a code and the manual entry of that code. Other systems require a manual pointing to the alternative. Some allow for verification of the response before activating it and others don't. The sections that follow discuss these and other variables as they pertain to the major forms of response input.
2.3.1 Standard Keyboard Input. Keyboard input requires the user to identify the alternative he wishes to select and then determine the appropriate keystrokes to make that selection. Menus may use (a) sequentially numbered alternatives, (b) nonsequentially numbered alternatives, (c) alphabetically labeled alternatives, (d) randomly labeled alternatives, or (e) mnemonically labeled alternatives.
The keyboard response may or may not require a terminating character such as the return key or send key. If it does, it provides the user with the opportunity to verify that he has entered the correct label. If it does not, the response requires one less keystroke. The trade-off is between speed of operation and cost of errors. If errors can easily and quickly be corrected without confusing the user and if speed is of the essence, then self terminating responses are called for. For novice users, response verification is important; however, confusion and frustration can arise when the user does not know that he must press the return key to continue.
Standard keyboard input requires some familiarity with the layout of the keys. Performance is facilitated, if the user knows how to type and does not have to search for the keys. Number keys have the advantage of being sequentially placed along the top row of keys or on a separate numeric keypad. Multiple character abbreviations are the most difficult for the nontypist.
2.3.2 Special Function Keys. Special function keys are used in many systems instead of standard keyboard input. The keys may only be labeled sequentially (e.g., "F1", "F2", "F3", ...) or they may be meaningfully labeled with words or phrases (e.g., "NEXT PAGE", "FORMAT", "QUIT", ...). If the keys are not meaningfully labeled, then the user must identify the item to be selected on the screen, note the number of the function key, and then locate the function key on the keyboard. With practice the user will remember the function of the keys and not have to refer to the information key information on the screen. When the keys are meaningfully labeled, the user needs only to locate the key on the keyborad.
The problem with special function keys is that for complex systems hundreds of such keys may be required. In some CAD/CAM systems large keyboard are used for selection of items. Similarly, a number of fast food restaurants use registers with the entire menu on a special keyboard for fast input. Large keyboards require a great deal of familiarity with the location of items to reduce search time. In other cases, where one does not have the luxury of a large keyboard, special function keys are used repeatedly for different functions or for only high frequency or event trapping alternatives. For example, a system may have a "HELP" key available for online information, and a "RESTART" key to start the search over again. Alternatives that are not listed on the screen but that are constantly available to the user can be wisely implemented with the use of special function keys.
2.3.3 Virtual Keypads. A number of menu selection systems have attempted to circumvent the problem of keyboard input and large response keypads by the use of screen pointing devices or by the use of automatic labeling of keys. One solution focuses on the screen as a direct input device, the other focuses on the keypad as an indicator of options.
When the options are listed on the screen, it seems natural to be able to point at or touch the desired item. The screen becomes in essence the keypad. Direct selection may be accomplished using a light pen or a touch screen. The use of a light pen requires that the user pick up the pen and direct its sensor at the desired item and press a select button. The touch screen is less encumbering and merely requires that the user physically touch the item on the screen. The advantage of a touch screen is the simplicity of selection. Among the disadvantages is the problem that the finger can obscure the item, the accuracy of pointing may be low, and the user may experience arm fatigue after long periods of interaction.
Indirect pointing methods may be used to select items on virtual keypads as well. Indirect pointing is done by the movement of a cursor across the items in the menu. The cursor may be directed by a continuous analog input device such as a mouse, a trackball, or a joystick. Alternatively, the cursor may be placed by discrete presses of arrow keys or a space bar. With continuous movement of the cursor, the user must be able to select the target item by placing the cursor into a spatial field and pressing a select button. Generally, visual feedback is required such that the item turns reverse video when the cursor is on that item. When the cursor is not on an item and the select button is pressed, generally no action is taken. The advantage of continuous input devices is that users can rapidly move the cursor to the target in a continuous move. The disadvantage is that good eye-hand coordination and hand steadiness is required and the user may miss the target. The user must grab the input device, find the current location of the cursor, locate the target, plot a trajectory from the Point A to Point B, verify when the cursor is on target, and then press the select button.
With discrete input devices, a number of keystrokes may be required to move the cursor to the desired item. The advantage, however, is that most systems jump the cursor from item to item so that the cursor is always on a target and never on an undefined choice. Arrow keys can be used to move up or down a vertical list or move to the left or right in a horizontal list. Arrow key selection requires the user to locate the arrow keys, find the current the position of the cursor (or highlighted alternative), locate the target, press direction keys until the cursor is on target, and then press the select button.
A disadvantage in many cases in using the screen as the input device is that the menu options obscure or disrupt the process of work. A virtual keypad that automatically labels keys depending on the current set of options, solves this problem. The keypad in essence becomes an output device listing the current menu frame. The active alternatives are indicated by LCD or LED displays on or next to the keys. This solution is analogous to having a separate window or second screen for menu selection.
2.4 Summary
A survey of menu systems indicates that they differ along a number of factors and characteristics. In this chapter menus were characterized by (a) the structure of the menu tree, (b) type and amount of information presented in the menu frame, and (c) the mode of response selection. The many factors that go into designing a menu system define a space of all possible systems. The ideal system must blend the right levels of factors and attributes to maximize user performance and satisfaction. The solution, however, is highly dependent on the particular task and the need for control. In the next chapter we will consider the types of tasks and the control functions of menu selection.
In this chapter menu structure, physical format, and response requirements will be discussed. Menu structure refers to the branching capability of the menu. Menu structure determines the extent to which the current selection affects subsequent options. We will see that some highly constrained menus serve a purpose in determining the proper sequence of transactions between the user and the system. On the other hand, users often wish to or need to jump to another activity. Menu selection systems in the past have been criticized because they have not allowed the user to escape from a particular menu path in order to complete some other task and then return to the previous point in the menu. A few systems are beginning to allow the user to perform tasks according to the user's plan of action rather than a constrained path of options. These menus allow the user nearly unlimited control over program flow to jump to any location desired.
The physical format of the menu may either facilitate the user or retard performance depending on how well it conveys information. The format should highlight the options and organize them in a meaningful way to help in visual search; it should help to set the context of where the user is in the flow of control through the menu structure; and it should aid the user in the decision process.
Finally, the user must have some means of indicating his choice. Menu selection systems vary widely in this respect. The response may be a number; a letter; a string of characters; a special function key; the positioning of a cursor using sequence of arrow keys, a mouse, a trackball, or a joystick; or via a touch screen or light pen. The system must clearly indicate how the user is to make a selection. Responding to menu items may be dissociated from the main task (e.g., using a mouse to make selections in a word processing application where the main task is keyboard entry) or it may be integrated with the task (e.g., using a touch screen to indicate moves in a chess playing program).
In the following sections various attributes and aspects of different types of menu systems will be discussed. The intent of this chapter is to lay out all of the possibilities for designing a menu selection system before considering the cognitive processes by which users navigate through these systems.
2.1 Menu Structures
The user's cognitive structure of a task embodies a set of expectations about what happens when and what leads to what. We will see that menu structure should be consonant with the user's cognitive structure. There should be a graceful guidance of activities that meshes with the user's expectations. For example in a financial transaction, if the system asks "Would you like to (1) deposit funds or (2) withdraw funds?" and the customer chooses the first option, he then expects to be asked something like, "Would you like to deposit to your (1) checking account or (2) savings account?" Program flow conforms to the user's schema of the task. On the other hand, it would unnerve the customer to be asked at this particular point,"Would you like to rent a safety deposit box (yes or no)?"
Menu structures embody the flow of the control given to the user in a task. The formal structure of a menu system can be defined using the concepts of set theory, abstract algebra or state-action graphs as has been done by Arthur (1984) and others. However, from the perspective of the user, it is more important to identify the general types of menu structures and the sense in which they control program flow. These are the single, sequential linear, simultaneous, hierarchical, cyclical/acyclical, and event menus.
2.1.1 Single Menus. Menu selection in its simplest form is a single menu frame that is presented to the user in order to elicit input. Single menus conceptually involve a one-shot choice rather than a series of choices. The user views this selection in isolation from other aspects of the task. For example, in a game program a menu might be presented as follows: "Select level of difficulty: (1) easy, (2) moderate, (3) hard." The user need only consider the immediate consequences of his choice and need not factor in other choices. Although a program may include a number other single menu choice points ( such as "Play another game (Y/N)?"), the user does not perceive these menus as forming a series of choices.
Even in its simplicity, the single menu involves an iterative cycle in which (a) the menu frame is presented; (b) a procedure is executed to get the user's selection; (c) an error checking routine is called to determine if the the input is valid; and (d) if it is valid, a parameter is set or a procedure is executed as specified by the input or (e) if it is not valid, an error message is generated and program control returns to b. The cycle for the single menu is shown in the shaded box in Figure 2.1.
When one menu frame naturally leads to another or when a set of menus are clustered together, the user begins to perceive a series of choices. This series defines a path going from one menu frame to another.
2.1.2 Sequential Linear Menus. Linear menus have only one path. Menu frames are presented in a preset order for parameter specification or for data entry. In essence all flow of control is determined by the system. The path of a linear menu system may extend from 2 to n levels and incorporates an iteration of single menu frames as shown in the whole diagram of Figure 2.1. The system is initialized to the first menu frame in the series; it presents a single menu, and advances to succeeding menu frames until it reaches the terminal node. Figure 2.2 shows such a menu applied to a questionnaire.
The two main problems with linear menus are that (a) the user may need to go back and change an answer in a previous menu and (b) the user may want to answer the questions in a different order than preset by the system. Solutions to the first problem can be handled using an undo command that jumps back to a specified frame; but in general, it is rather awkward and confusing for the novice user to control movement along an extended linear path.
2.1.3 Simultaneous Menus. Simultaneous menus solve the problems caused by preset orders of menu frames. All menu options are available simultaneously. The user can enter the responses in any order as one could in filling out a form. These menus are, in fact, a form fill-in method with the restriction that items are selected rather typed into fields. Questions may be skipped and returned to later or simply left blank. Figure 2.3 gives an example of the simultaneous menu in setting parameters of a terminal communications program.
The problem with the simultaneous menu is that for a large number of options, it may not be possible to display all of the choice sets on one screen and some mechanism must be used to scroll or page to other parts. An additional technical problem, is that response input must define both the menu number and option number. When keyboard input is required, it is rather tedious to enter both such as "12A" for option A of menu 12. On the other hand, using direct selection with a mouse or light pen, the cursor location identifies both the menu and the option simultaneously.
Although simultaneous menus are appealing in many applications, sometimes the preset order of the linear menu is preferred. This is particularly true when there are underlying relationships or interactions among the options. When the interactions are strong in that they make other options inappropriate, the menu system should have a hierarchical structure that reflects these relationships. For example, if one frame asks, "Do you own a personal computer?" and the user indicates, "no," then it is not appropriate to ask, "Which of the following computers do you own?" More complex menu structures allow branching to maintain a natural series of questions.
2.1.4 Hierarchical Menus. The hierarchical structure of a menu results in the increasing stepwise refinement of choice. In data base search, it may be the specification of categories, subcategories, and so on. In parameter specification and data entry, it is the selection of options, suboptions, and so on.
The hierarchical menu can be represented as an inverted tree structure leading to more and more branches. Hierarchical menus may be either symmetric or asymmetric as shown in Figure 2.4. Symmetric menus vary only in depth and breadth. Depth is defined as the number of levels that one must traverse to reach the terminal node. Breadth is defined as the number of alternatives at each level. The structure of symmetric menus can be defined by a series of numbers indicating the number of alternatives at each level. For example, the menu structure in shown in the top panel of Figure 2.4 is indicated by 3x3. On the other hand, a 4x2x8 menu would have 4 alternatives at the first level, 2 at the next level, and 8 at the last level, resulting in 64 terminal nodes. In general, symmetric menus with a constant breadth of k alternatives at n levels will have kn terminal nodes.
Symmetric menu structures are rare in real world system owing to the asymmetric nature of categories and subcategories. However, they are used quite often in empirical research on menu selection because the number of alternatives at each level and the length of all possible paths are constant across the tree. When this is the case, it is easy to vary depth and breadth and evaluate their effect on performance. Furthermore, symmetric menus have the advantage that users can expect the same number of alternatives at each level and the same number of levels. Sometimes this constancy is important in routine tasks. It sets a simple pattern of response on the part of the user who is often anticipating the next transaction with the system.
Asymmetric menus, however, are the rule in most practical applications. The number of alternatives varies throughout the structure and the length of paths to terminal nodes is not necessarily constant. Although menus do not have a constant depth and breadth, they may be described statistically by their average depth and breadth. The amount of variability in the structure may be assessed by the standard deviations of depth and breadth. The definitions of the average and standard deviation for depth and breadth, however, are not straightforward. One could look at the average path length for all possible paths and the average number of alternatives across all frames; however, this does not take into account the actual utilization of the menu. If a user visits all terminal nodes with equal frequency, he experiences a different average depth than if he makes all choices with equal probability. Consequently, a weighting scheme needs to be applied in assessing average depth and breadth. For average depth, we may use (a) equal weighting of all possible paths, (b) weighting by probability of path given equal choice probability, and (c) weighting by probability of path given observed choice probabilities. The equations for the weighted average and weighted standard deviation for depth are:
Avg. D = [[Sigma]] wini / [[Sigma]] wi (1)
_________________________
Sd. D = [[radical]]( [[Sigma]] wi ( ni - Avg. D )2 / [[Sigma]] wi ), (2)
where ni is the number of nodes visited for path i and wi is the weight for path i. Table 2.1 gives an example of the weights and computations for the asymmetric menu shown in Figure 2.5.
For breadth, one may use either (a) an equal weighting of the number of alternatives across all nodes or (b) a weighting by the frequency of times the node is visited. In the second case, these frequencies may be determined by (a) equal path frequency, (b) equal choice probability, or (c) observed choice probabilities. The equations for weighted average and weighted standard deviation of breadth are:
Avg. B = [[Sigma]] wj kj / [[Sigma]] wj; (3)
_________________________
Sd. B = [[radical]] ( [[Sigma]] wj ( kj - Avg. B )2 / [[Sigma]] wj ), (4)
where kj is the number of alternatives at node j and wj is the weight for node j. Table 2.2 gives an example of these weights and computations for the asymmetric menu in Figure 2.5.
Table 2.1
Measures of Depth in Asymmetric Menus
___________________________________________________________________
Probability Weights __________
Path Depth Equal Path Equal Choice Observed Choice*
1 1 1/11 1/2 .8000
2 2 1/11 1/6 .1200
3 3 1/11 1/12 .0100
4 3 1/11 1/12 .0100
5 3 1/11 1/24 .0120
6 3 1/11 1/24 .0180
7 3 1/11 1/24 .0240
8 4 1/11 1/96 .0015
9 4 1/11 1/96 .0015
10 4 1/11 1/96 .0015
11 4 1/11 1/96 .0015
Average 3.09 1.87 1.29
Standard Deviation .90 .97 .62
____________________________________________________________________
* Calculated from the hypothetical choice probabilities shown in Figure 2.5.
Table 2.2
Measures of Breadth in Asymmetric Menus
_______________________________________________________________________________
Weighting __
Frame Breadth Equal Frame Equal Path Equal Choice Observed Choice*
1 2 1 11 1 1.000
2 3 1 10 1/2 .200
3 2 1 2 1/6 .020
4 4 1 7 1/6 .060
5 4 1 4 1/24 .006
Average 3.00 2.94 2.49 2.26
Standard Deviation 1.00 .85 .69 .54
____________________________________________________________________________
* Calculated from the hypothetical choice probabilities shown in Figure 2.5.
Hierarchical menus have the virtue of allowing the user to branch as a part of the flow of control. No such branching is allowed in linear menus. However, the order of branching and structure of the branching in the hierarchy is preset. The flow of control is one-way, top down. The disadvantage is that the hierarchical order may not fit the user's conception of the task flow of control. It is often the case that users unfamiliar with the menu need to back up the tree, change a previous selection, or start over again. The user may not consider answering questions in the order that the hierarchy dictates or the user may not know what suboptions the system will offer given the selection of a particular choice. The first problem is that of cognitive representation. The second is the problem of uncertainty. It will be shown in subsequent chapters that menus should be designed so that (a) their hierarchical structure is consistent with user expectations and (b) they reduce as much as possible the uncertainty of choice. In an effort to alleviate these problems, most hierarchical menu systems provide options or commands that allow the user to move to the previous frame or to return to the main menu. Although these are considered as solutions to the problem, they are often cumbersome to the user.
2.1.5 Connected Graph Menu Structures. The most general of the sequential menus is the connected graph network. A connected graph is a set of nodes connected by arches such that all nodes are directly or indirectly linked. Movement through the structure of menu frames need not be restricted to a hierarchical tree but may include links from any node to another in the network. Technically, hierarchical trees that allow the user to move to the previous node or to jump to the top of the tree are also connected graphs. However, in the present discussion, we will use the term "connected graph" to denote a menu system that does not embody the central idea of a hierarchy but rather that of a network of connected nodes. Consequently, from the the users perspective there is no sense of top-down traversal of the menu. Instead, it is a question of determining the path from Node A to Node B that accomplishes the task at hand. Network menus convey the idea of a geographical map of a road system. One may want to find the fastest (or shortest) route from Point A to Point B or one may want to select the route between the two points that passes through Points C, D, and E as well.
Figure 2.6 shows several examples of connected graphs. These structures may be cyclical if they either allow or require multiple passes along the same path to accomplish a function or acyclical of they do not. For example, Graphs A and B are cyclical; Graph C is acyclical; and Graph D is for the most part acyclical but contains a cyclical part. Connected graphs may also be characterized as symmetric or asymmetric. For example, Graphs A, B, and C are symmetric and Graph D is asymmetric.
Connected graphs like the hierarchical graphs vary in terms of the number of menu frames, average number of alternatives, and length of path. Estimates depend on how the values are weighted. As before they may be given equal weights or weights that depend on menu use and probability of paths. A major difference between connect graphs and hierarchical menus is that in connected graphs there may be multiple paths between two nodes. Menus vary in terms of connectivity, that is, extent to which nodes are linked by multiple paths.
The connected graph is generally used to provide the user with a full sense of control over the flow of actions. These systems are found most often as menu replacements of command languages for operating systems and application programs. For the control of program flow, the connected graph is typically sequential. The options open to the user are limited to the number of paths leading from the current node. While this is limitation is helpful in providing focus for the user, it may also prove frustrating when there is a need to perform a concurrent task unrelated to the current location in the graph or a need to break the current flow of control and jump out of the graph to select some new entry point. Event trapping menus allow for this level of control are are described in the next section.
2.1.6 Event Trapping Menus. Event trapping menus provide in essence a set of simultaneous menus superimposed on a sequential hierarchical or connected graph menu system and may be activated at any point in a task. Typically, these menus appear as special function keys or as pull-down or pop-up lists of options. In the case of special function keys, the user selects a menu or item in a menu by pressing a specially denoted key. In the case of pull-down or pop-up menus a cursor is placed on the menu label and the items are revealed. Figure 2.7 shows such a system with a menu bar at the top of the screen and one of the lists pulled down.
Event trapping menus may be characterized by the number of special function keys or the number of items in pull-down menus. Furthermore, the selection of an item generally serves one of three functions: (a) It may immediately change a parameter in the current environment or perform some function without leaving the current environment. For example, in a word processing program one may select the option to left and right justify the text. Once the selection has been made, the user continues where he left off. (b) It may call a subroutine that momentarily takes the user out of the current environment to perform some function and then returns to the previous environment. For example, in a file management application, the user may be scrolling through file entries and desires to change the format. He would select from the menu bar the option to format and then enter an environment that allowed redefinition of the format. Upon completion, he would automatically return to the previous environment. (c) Finally, it may exit the current environment and move to a totally new environment. For example, the user may select "quit" to return to the operating system or select among other application programs. Event trapping menu systems vary in term of the number and mix of these three types of items. The greater the flexibility and complexity of a system, the greater the number of event trapping options.
Event trapping menus provide an ever present background of control over the system state and parameters while the user is working on a foreground task. The menus are constantly available and help to establish a sense of context while things are changing in the foreground. The menu bar may change from one application program to another, but typically there is some degree of communality between the event trapping menus and some degree of distinctiveness that helps to remind the user where he is. However, if the meaning of special function keys and the particular items in pull-down menus vary greatly or change without warning, the user may experience loss of position or disorientation and make habitual errors. We will see in the next section how the user must be kept informed of the current state of the system in terms of information conveyed to the user by the menu frame.
2.2 Menu Frames
The menu frame consists of the context, the stem, the leaves, and the response instructions. Needless to say, menu selection systems vary drastically in terms of what information is presented, the amount of information, and the format of the frame. The design of a particular system must take into consideration how much information the user needs to work meaningfully with the system. In general, one would expect that users who are unfamiliar with the menu need more information. As users become more and more experienced, verbose descriptions may be replaced with short mnemonic reminders. In the following sections variables pertaining to the amount and type of information in the menu will be discussed.
2.2.1 Context Information. The context provides feedback that tells the user where he is in the process, what the past choices and outcomes were, and possibly how much further it is to the terminal node. Context information is extremely important in complex menus where the user may experience a subjective loss of position and associated disorientation. The user may not recall how far down the tree he or she has come, or how successful past choices have been in getting closer to the goal, or how many more choices must be made before reaching to the goal. It is too often the case that halfway through a search, the user asks, "Now what was it that I was looking for?" Human memory, being what it is, needs assistance.
At a minimum, the frame should provide information that the user is accessing the right function. In a bank transaction, if the customer has selected his checking account, then all further choices (balance, withdraw, deposit) should be clearly in the context of the checking account. This feedback provides the user constant assurance that he is on the right track. On the other side, context information should not be overly verbose. If it is, it obscures the current choice and may add to the confusion.
Context may be established by various methods of linkage between successive menu frames as illustrated in Figure 2.8. The most fundamental linkage is merely the temporal sequence of one frame following the selection of an option in a previous frame. Temporal sequence implies a cause-effect relationship; however, it does not indicate the nature of the relationship between one frame and the next. The context established by temporal linkage decays with time and may need to be maintained by other methods of linkage.
Verbal linkage may be accomplished by using the previously selected option as the title for the next menu frame. The title may be cumulative as one goes further along a path. For example, in a video text service the title of a menu frame may be "News: New York Times: World News: India: Today" indicating the path to the current set of options which may be a list of stories.
Spatial linkage may be accomplished by graphic methods that preserve temporal linkage and enhance verbal linkage. In the bottom panel of Figure 2.8, the user selected the second option. A link is shown by displaying the next menu frame in a window overlapping the previous frame. The complete path down a menu tree may be shown as a series of overlapping frames in a single view. Linking information such as this can provide the user with a sense of progress and distance from the start to the goal.
2.2.2 Stem Information. The stem provides the label for the current set of choices. It may be merely the beginning of a question: "Would you like to ...?" or it may be the label of the alternative selected in the previous frame. For example, if the user were asked what communication parameter he wished to change and he selected "baud rate," the stem might be "Select baud rate:" The stem may be merely the current choice or it may include a record of all choices in the path up to the present choice. In nested hierarchical menus, the stem information may increase with each choice. Selections may include a trace of the whole path down to the current point. For example, along the lines of the Dewey Decimal System a stem in an information retrieval system might be: History|U.S.|Civil War|Economic|Impact on?|.
However, in generating stem information, there is a trade-off between specificity and clutter. When one could easily get lost in the maze of choices, cumulative stem information is essential. In other cases, however, the user may not need to see all of the stem information. Only that which is likely to be lost from short term memory and that is crucial to specifying the current choice must be displayed.
Stem information should provide the novice user with a rationale for why this choice is being made and what it's impact will be on subsequent processes. For the set of choices "Gothic, Roman, Modern," a stem such as "Select one of the following:" is devoid of information. The novice user does not know what they refer to or what the choice will affect. On the other hand, a stem such as "Set the type font to one of following for printing document:" provides that information. Research in cognitive psychology shows an enormous impact of providing a meaningful title on a person's interpretation and understanding of subsequent information (Bransford & Johnson, 1972). Similar results have been found for the effect of pictures (Butterfield).
2.2.3 Leaf Information. The leaves are the alternatives available to the user. Leaf information can vary from a brief listing of response options (e.g., "/A/T/S/Q/H/") to single words or phrases (e.g., "A--Author; T--Tile; S--Subject; Q--Quit; H--Help") or to a complete description (e.g., "A--Search for a book by author's name; T--Search for a book by it's title; S--Search for a book by the subject; Q--Quit searching and return to beginning; H--Request detailed help on searching for a book"). Leaf information is rarely complete in the sense of telling the user precisely what will happen if a particular selection is made. This is particularly true in nested hierarchical menus where the user would like to know what options will be available following a particular choice. Some systems provide the user with the ability to look ahead prior to committing to a choice. For example, some systems allow the user to move a scroll bar over an alternative and at the same time the next level of choices are displayed.
A number of guidelines have been suggested for the wording of leaf information. Alternatives should be unambiguous, mutually exhaustive, exhaustive, and nonoverlapping. The wording of alternatives should emphasize the critical features of their differences rather than similarity. Furthermore, it has been suggested that alternatives should be brief noun phrases (Shneiderman, 1986). Most of these guidelines have yet to be validated by empirical research.
The list of alternatives appearing in the menu frame may not necessarily be exhaustive. Many systems include constant alternatives that are not explicitly listed. Constant alternatives may be commands such as "move to the previous menu," "jump to the top," "help," or "quit." Generally, systems that include unlisted options include an option to display the full set of choices. This may be a question mark or "help." Generally, however, the command to list unlisted alternatives is also unlisted. One would expect that hidden alternatives are less likely to be used by novices.
2.2.4 Response Information. Finally, response instructions tell the user how to indicate the choice. For example, it may say "Enter the number of your selection and press the return key," or simply "Press key" when special function keys are labeled. Explicit instructions are often needed for first time users of the system. With experience, users gain a sense of what is expected of them by the system. Overly verbose instructions generally confuse the user or are simply not read. Instructions for response procedures which are different from the usual mode of interaction need to highlight those differences. For example, a response may be recognized and processed by the system (a) immediately after a single key is pressed, (b) only when terminated by pressing the return key, or (c) only when terminated by pressing a special "send" key. If users habitually terminate lines with a return key, errors and confusion may occur if a different type of response is required.
Response information may also include feedback or verification that a particular alternative was activated or is about to be activated. Systems vary from providing no feedback, to a single auditory beep that some response was recorded, to confirmation of the response in an input field or by highlighting the selected alternative.
2.2.5 Information Format. In early alphanumeric applications of menus, information was presented sequentially in the following order: context, stem, leaf, response. The three panels of Figure 2.9 show variations of this format. Systems have varied the degree to which the menu is organized on separate lines. Some systems have run all of the menu together in prose form (top panel of Figure 2.9); others have grouped information on one line (middle panel of Figure 2.9); and others have used multiple lines to list the options in an outline form (bottom panel of Figure 2.9). The number of possible layouts is unlimited; however, it is obvious that some layouts are to be preferred over others. The prose layout, for example, is particularly bad because the user cannot easily scan the list of items.
With the advent of graphics and screen based systems, other methods of displaying information have been used. Context is often given by the background on which the menu appears. A pop-up window or pull-down menu appears over the work at hand; thereby retaining a sense of position. The stem and leaf information in these systems remains much the same except that options may be graphically displayed using icons. Often the stem information may be implicit rather than expressly stated. It is expected that the layout of such information will greatly affect the user's ability to comprehend the functioning of the system.
2.3 Response Mode
The method of response selection is an important one and varies substantively among systems. We will see later that there are a number of cognitive implications regarding the response mode. Some response modes require a mapping of the alternative to a code and the manual entry of that code. Other systems require a manual pointing to the alternative. Some allow for verification of the response before activating it and others don't. The sections that follow discuss these and other variables as they pertain to the major forms of response input.
2.3.1 Standard Keyboard Input. Keyboard input requires the user to identify the alternative he wishes to select and then determine the appropriate keystrokes to make that selection. Menus may use (a) sequentially numbered alternatives, (b) nonsequentially numbered alternatives, (c) alphabetically labeled alternatives, (d) randomly labeled alternatives, or (e) mnemonically labeled alternatives.
The keyboard response may or may not require a terminating character such as the return key or send key. If it does, it provides the user with the opportunity to verify that he has entered the correct label. If it does not, the response requires one less keystroke. The trade-off is between speed of operation and cost of errors. If errors can easily and quickly be corrected without confusing the user and if speed is of the essence, then self terminating responses are called for. For novice users, response verification is important; however, confusion and frustration can arise when the user does not know that he must press the return key to continue.
Standard keyboard input requires some familiarity with the layout of the keys. Performance is facilitated, if the user knows how to type and does not have to search for the keys. Number keys have the advantage of being sequentially placed along the top row of keys or on a separate numeric keypad. Multiple character abbreviations are the most difficult for the nontypist.
2.3.2 Special Function Keys. Special function keys are used in many systems instead of standard keyboard input. The keys may only be labeled sequentially (e.g., "F1", "F2", "F3", ...) or they may be meaningfully labeled with words or phrases (e.g., "NEXT PAGE", "FORMAT", "QUIT", ...). If the keys are not meaningfully labeled, then the user must identify the item to be selected on the screen, note the number of the function key, and then locate the function key on the keyboard. With practice the user will remember the function of the keys and not have to refer to the information key information on the screen. When the keys are meaningfully labeled, the user needs only to locate the key on the keyborad.
The problem with special function keys is that for complex systems hundreds of such keys may be required. In some CAD/CAM systems large keyboard are used for selection of items. Similarly, a number of fast food restaurants use registers with the entire menu on a special keyboard for fast input. Large keyboards require a great deal of familiarity with the location of items to reduce search time. In other cases, where one does not have the luxury of a large keyboard, special function keys are used repeatedly for different functions or for only high frequency or event trapping alternatives. For example, a system may have a "HELP" key available for online information, and a "RESTART" key to start the search over again. Alternatives that are not listed on the screen but that are constantly available to the user can be wisely implemented with the use of special function keys.
2.3.3 Virtual Keypads. A number of menu selection systems have attempted to circumvent the problem of keyboard input and large response keypads by the use of screen pointing devices or by the use of automatic labeling of keys. One solution focuses on the screen as a direct input device, the other focuses on the keypad as an indicator of options.
When the options are listed on the screen, it seems natural to be able to point at or touch the desired item. The screen becomes in essence the keypad. Direct selection may be accomplished using a light pen or a touch screen. The use of a light pen requires that the user pick up the pen and direct its sensor at the desired item and press a select button. The touch screen is less encumbering and merely requires that the user physically touch the item on the screen. The advantage of a touch screen is the simplicity of selection. Among the disadvantages is the problem that the finger can obscure the item, the accuracy of pointing may be low, and the user may experience arm fatigue after long periods of interaction.
Indirect pointing methods may be used to select items on virtual keypads as well. Indirect pointing is done by the movement of a cursor across the items in the menu. The cursor may be directed by a continuous analog input device such as a mouse, a trackball, or a joystick. Alternatively, the cursor may be placed by discrete presses of arrow keys or a space bar. With continuous movement of the cursor, the user must be able to select the target item by placing the cursor into a spatial field and pressing a select button. Generally, visual feedback is required such that the item turns reverse video when the cursor is on that item. When the cursor is not on an item and the select button is pressed, generally no action is taken. The advantage of continuous input devices is that users can rapidly move the cursor to the target in a continuous move. The disadvantage is that good eye-hand coordination and hand steadiness is required and the user may miss the target. The user must grab the input device, find the current location of the cursor, locate the target, plot a trajectory from the Point A to Point B, verify when the cursor is on target, and then press the select button.
With discrete input devices, a number of keystrokes may be required to move the cursor to the desired item. The advantage, however, is that most systems jump the cursor from item to item so that the cursor is always on a target and never on an undefined choice. Arrow keys can be used to move up or down a vertical list or move to the left or right in a horizontal list. Arrow key selection requires the user to locate the arrow keys, find the current the position of the cursor (or highlighted alternative), locate the target, press direction keys until the cursor is on target, and then press the select button.
A disadvantage in many cases in using the screen as the input device is that the menu options obscure or disrupt the process of work. A virtual keypad that automatically labels keys depending on the current set of options, solves this problem. The keypad in essence becomes an output device listing the current menu frame. The active alternatives are indicated by LCD or LED displays on or next to the keys. This solution is analogous to having a separate window or second screen for menu selection.
2.4 Summary
A survey of menu systems indicates that they differ along a number of factors and characteristics. In this chapter menus were characterized by (a) the structure of the menu tree, (b) type and amount of information presented in the menu frame, and (c) the mode of response selection. The many factors that go into designing a menu system define a space of all possible systems. The ideal system must blend the right levels of factors and attributes to maximize user performance and satisfaction. The solution, however, is highly dependent on the particular task and the need for control. In the next chapter we will consider the types of tasks and the control functions of menu selection.
No comments:
Post a Comment