use the term selection termination to indicate the action that ends the entire menu
`
`In non—hierarchic case, selection confirmation and selection
`selection process.
`termination are combined in the same action.
`
`There are many different types of input events that could be used to signal selection
`confirmation:
`
`' Pen—ap/pen—d0wn
`
`Item entry means selection confirmation occurs the moment the pen
`° Item entry:
`enters an item.
`
`' Boundary crossing: Boundary crossing means that selection confirmation occurs
`
`when the pen crosses the outside border of a menu item.
`
`° Dwelling: Dwelling is the act of keeping the pen pressed and not moving for a
`
`fraction of a second. A user can avoid issuing dwelling events by keeping the pen
`
`moving.
`
`Press—and—wait
`
`is an example of a dwelling event. However, we
`
`distinguish between these two events because press-and-wait signals the entry into
`
`menu mode while dwelling signals selection confirmation.
`
`° Events distinct flom pen movement: This includes things like a button press or an
`
`increase in pressure with a pressure sensing pen.
`
`The type of selection confirmation event used affects other design features:
`
`° mimicking drawing a mark: Since selection from a hierarchy of menu items involves
`
`a series of selection confirmations and we wish to mimic that act of making a mark,
`
`an event for selection confirmation that does not interrupt dragging must be used.
`
`° reselection:
`
`In some cases, a user may desire to change the previewed selection.
`
`For example, a user may accidentally move into the wrong item then want to move
`
`to the correct item. We refer to this process as reselection. Most menu systems
`
`support reselection.
`
`° pairing command and parameters: The command compass allows dragging to
`
`continue after the final selection confirmation. Dragging is then used to indicate
`
`additional parameters to the menu command just selected.
`
`Page 1501 of 1714
`
`

`
`Figure 2.5 shows which selection confirmation methods support these features. Item
`
`entry is not feasible because it does not allow reselection. Boundary crossing,
`
`dwelling and events distinct from pen movements support both reselection and
`
`pairing. We discount ”events distinct from pen movement" because it requires
`
`additional input sensors like pen buttons or a pressure sensing pen.
`
`Figure 2.5 indicates that boundary crossing and dwelling are the only applicable
`
`choices. Boundary crossing is preferable because a visible boundary (i.e., the edge of
`
`a menu) gives precise information as to when selection will occur. This information
`
`is not visible if dwelling is used. Furthermore, waiting for a dwelling to occur slows
`
`interaction. It is also possible to use pen release as a confirmation method if pairing
`
`is not required and the item being selected is the last in a series of selections.
`
`We implemented boundary crossing by having selection confirmation occur when
`
`the user crossed over the outer edge of a menu item.
`
`Specifically, selection
`
`previewing occurred as long as the user stayed within the circle of the menu.
`Selection confirmation occurred when the user moved outside the circle. We
`
`discovered, in practice, that boundary crossing created a problem. As a user moves
`
`away from the center of the menu to confirm an item, the item's sub—menu pops up
`
`when the outer boundary is crossed. Unless a user moves very slowly, one is still
`
`moving when the sub—menu appears. This results in one of the items in the sub-
`
`menu being selected immediately. If the user is moving fast, the boundary point for
`
`the sub—menu may have already been crossed and this results in an erroneous
`
`selection confirmation.
`
`Even if
`
`the boundary point was not crossed,
`
`this
`
`overshooting in the sub—menu causes reselection to be the first action to occur each
`
`time a sub—menu is popped up. This means that users are not rehearsing the
`
`movement of drawing a mark, but are rather making a movement which involves
`
`reselection. This approach was therefore unacceptable.
`
`Page 1502 of 1714
`
`

`
`To solve this problem, we used a hybrid approach which combines boundary
`
`crossing and dwclling. The approach works as follows. As long as the pointer is
`
`within some distance from the center of menu, a dwelling event
`
`is ignored.
`
`Selection preview and reselection are therefore possible without the threat of an
`
`accidental dwelling occurring. Once the boundary is crossed, selection preview and
`
`reselection are still possible but, if the user dwells, the selected item is confirmed
`
`and its sub—menu appears. This allowed users to use coarser movements to make
`
`selections without fear of overshooting and selecting from sub—menus.
`
`Dwelling is also consistent with press-and-wait. In both these activities, keeping the
`
`pen pressed against the display and holding it triggers the display of a menu.
`
`A selection can also be confirmed without dwelling by releasing the pen at any point
`
`in the hierarchy of a menu. This allows any item in the hierarchy to be selected and
`
`also signals selection termination.
`
`2.5.6.
`
`Mark ambiguities
`
`The current design presents a dilemma if we Consider using marks to make
`
`selections from hierarchies of menus. The idea behind using marks for selection is
`
`Selection confirmation event
`
`allows
`
`allows
`
`allows
`
`mimicking
`
`reselection?
`
`pairing?
`
`marking?
`
`events distinct from pen
`movement
`
`yes
`
`yes
`
`yes
`
`(* yes in the non—hierarchic case)
`
`( as long as the pointer is kept moving)
`
`Figure 2.5: Different selection confirmation methods characteristics.
`
`50
`
`Page 1503 of 1714
`
`

`
`that selection will be fast and fluid. This implies that we do not desire or expect a
`
`user to ”include" dwellings when making selections using marks. This would be
`
`unnatural and slow the marking process.
`
`A problem can occur if dwellings are not included when making marks. Consider a
`
`selection from a hierarchy that is two levels deep. Suppose the user makes a straight
`
`line mark. Does the mark correspond to a selection from the parent menu or the
`
`child menu? Figure 2.6 shows the problem.
`
`If dwellings no longer occur we cannot
`
`disambiguate the selection. If we base the interpretation on boundary crossing, then
`
`the mark is unambiguous. Unfortunately, this makes the size of a mark affect its
`
`interpretation (i.e., the marks cannot be scaled).
`
`One solution to this problem is called no category selections.
`
`It is based on the
`
`observation that items which have subitems are generally categories of commands,
`
`not commands themselves, and selecting a category is not a meaningful operation.
`
`For example, when using linear hierarchic menus on the Macintosh, selecting the
`
`”font" category leads to a menu of commands that change the font. Selecting ”font"
`
`by itself (i.e., releasing the mouse button when ”font" is selected) performs no
`
`operation. Therefore we assume that there is no need to select a category. Thus, we
`
`can consider any straight line to be a selection into a submenu (case (b) in Figure
`
`2.6). Note that this permits selection of certain menu items that are embedded in
`
`submenus by drawing a short straight mark. We recommend designers put the
`
`most popular item in a category in this position to promote efficiency.
`
`Page 1504 of 1714
`
`

`
`Figure 2.6.‘ Ambiguity in selecting from a hierarchy of menu items two levels deep
`using a mark. Overlaid grayed menu show possible interpretations.
`In (a),
`the
`interpretation is the selection of item I. However,
`(b) is another interpretation
`according to boundary crossing rules (the selection of item 1.1).
`Interpretation by
`boundary crossing is sensitive to the size ofmarks.
`
`No category selections breaks down when the depth of the hierarchy is greater than
`
`two. Suppose a user makes a ”’\" mark as shown in Figure 2.7 (a). The start of the
`
`mark and the change in direction within the mark indicate two points of menu
`
`selection. However, what indicates selection from the third level of menu? Figure
`
`2.7 shows this problem. Once again, boundary crossing can be applied to derive an
`
`unambiguous set of menu selections but this results in unscalable marks.
`
`There are several solutions to this problem which preserve scaling. The first
`
`solution, referred to as the n0—oping (from the phrase ”no operation”),
`
`is to simply
`
`not permit a series of menu selections that result in a straight line. One way of
`
`doing this involves making the item in the child menu that ”lines up" with the
`
`selection angle of the parent a null operation. This ensures that the beginning of a
`
`selection of a non-null item from a child menu is indicated by a change in angle.
`
`Unfortunately, this ”wastes" a useful sector in a menu.
`
`Page 1505 of 1714
`
`

`
`Figure 2. 7: Possible interpretations of mark when selecting from hierarchies greater
`that two levels deep. The straight line sections of the mark have no artifacts to indicate
`whether the selection at that point is being made from the parent orfrom the child.
`
`A second solution is axis—shzfting. This involves rotating child menus such that no
`
`item appears at the same angle as an item in the parent menu. Figure 2.8 shows an
`
`example of this technique. Axis-shifting involves aligning the boundary between
`
`two items in the child menu with the selection angle of the parent item. This ensures
`
`that the beginning of a selection from child menu is indicated by a change in angle.
`
`Axis-shifting avoids the wasted sectors that occur with no-oping.
`
`This discussion has presented four solutions to hierarchic menu design which are
`
`intended to produce an unambiguous vocabulary of marks. The four solutions are:
`
`boundary crossing, no category selections, no—oping, and axis—shifting. The aspects
`
`of the design that are affected by these solutions are: the ability to select any item
`
`within the hierarchy, the ability to have mark interpretation independent of the size
`
`of a mark, the ability to select leaf items with a single straight line, and the ability to
`
`have all items in a menu active. These aspects may also vary relative to the depth of
`
`the menu. Figure 2.9 summarizes this design space.
`
`A solution can be chosen based on the demands of the menu. If menus are only one
`
`or two levels deep and menu categories do not need to be selected, then no category
`
`selections will work. Boundary crossing and axis-shifting are suitable when
`
`hierarchies are more than two levels deep and category menu items need to be
`
`53
`
`Page 1506 of 1714
`
`

`
`selected. Boundary crossing is also an acceptable solution if category items need to
`
`be selected and mark scaling is not an issue.
`
`Figure 2.8: Axis shifting rotates a child menu such that child menu items do not appear
`on the same angle as the parent menu item. This results in a mark language where
`selection confirmations are indicated by changes in angle. With this scheme marks can
`be drawn at any size.
`
`Page 1507 of 1714
`
`

`
`select any
`
`item?
`
`allows
`
`all items
`
`” straight
`
`active?
`
`lining”
`
`-Yes
`
`no category
`
`No (2)
`
`No (except
`
`Yes
`
`Yes
`
`Yes
`
`selections
`
`in 1 deep
`
`case)
`
`Figure 2.9: Policies that avoid ambiguous interpretation ofmarking menu marks.
`
`2.5.7.
`
`Display methods
`
`There are several design options which concern how menus are displayed:
`
`° Menu trail refers to leaving parent menus displayed as a user descends a hierarchy
`of menu items.
`
`° Menu overlap refers to displaying child menus over the top of parent menus.
`
`These methods become important when backing up in a hierarchy of menus.
`
`2.5.8.
`
`Backing-up the hierarchy
`
`The ability to bacl<—up in a hierarchy of menus is useful for browsing menu items
`
`and correcting mistakes. Backing—up can be one of three types: bacl<—up only to the
`
`parent menu, bacl<—up to any ancestor menu, bacl<—up to any ancestor menu item.
`
`Backing-up can be accomplished in several ways. Pointing to an item can trigger a
`
`bacl<—up to the item, or an explicit action can trigger a bacl<—up (i.e., tapping the pen
`
`triggers a back-up to the parent menu). A combination of these two methods can be
`
`used (i.e., tapping on an item to bacl<—up to it). Lifting the pen is already used to
`
`indicate selection termination, so the bacl<—up technique is restricted to pointing
`
`while the pen is being dragged.
`
`Page 1508 of 1714
`
`

`
`Backing-up brings the roles of menu trail and menu overlap into play. Pointing to
`
`the item in order to back—up to it requires that item be displayed on the screen.
`
`Therefore a menu trail must be provided. However, child menu items may cover up
`
`parent items making it impossible to point to ”covered" items. The design must
`
`ensure that parent items are not covered up.
`
`Design requirements dictate that backing—up in marking menus operates like
`
`backing—up in traditional drag—through hierarchical menus: to back—up to a parent
`
`menu item, a user points to it; the system then closes the currently displayed child
`
`menu and displays the child menu of the parent item. We can adopt this scheme for
`
`marking menus but it reduces the advantage of radial menu selection. Figure 2.10
`
`shows the problem that occurs. A selection from a child menu may result in
`
`pointing to a parent menu item and this causes an unintended back—up. A prototype
`
`implementation of marking menus revealed this to be a real problem. The problem
`
`could be avoided if a user is ”careful", but this tends to slow users down.
`
`Figure 2.10: A problem with the backing up by pointing to a parent item. Is the user
`selecting item a.c or backing up to item b?
`
`To solve this problem, we could restrict marking menus to operate like linear menus
`
`where selection occurs only if the user is pointing inside a menu item. This has two
`
`56
`
`Page 1509 of 1714
`
`

`
`major disadvantages. First, it selection sensitive to the length of strokes, and second,
`
`it massively reduces item size from a sector of the entire screen to the small sector of
`the menu.
`
`The solution is to reduce the size of the back-up targets. This is done by restricting
`
`the back-up targets to the center hole of the parent menus. This drastically reduces
`
`the probability of accidentally pointing to a back—up target.
`
`Furthermore, we
`
`constrain the user to dwell on a center before back—up takes place. This allows the
`
`user to ”pass through” centers without backup occurring. Figure 2.11 shows this
`
`back-up scheme.
`
`This approach has the restriction of only allowing back—up to parent menus.
`
`Backing up to a parent menu and displaying another one of the child menus cannot
`
`be combined in the same operation. Some hierarchic linear menus allow this.
`
`However, this restriction permits fast and unconstrained selection when moving
`
`forward in the hierarchy, while still allowing back-up.
`
`This bacl<—up scheme has several more advantages. First, one can bacl<—up to any
`
`parent menu, grandparent menu, etc. Second, menu overlap can occur just as long
`
`as menu centers do not get covered. Finally, because backing-up actually returns
`
`the cursor to parent menus, rather than redisplaying parent menu at the cursor
`
`location, this reduces the chances of menus ”walking off" the screen (this problem is
`
`further discussed in Section 6.2.3).
`
`Page 1510 of 1714
`
`

`
`In (I) the user moves into
`Figure 2.11: Backing-up in hierarchic marking menus.
`the center of a parent menu and dwells momentarily.
`In (2) the system senses the
`dwelling and backs-up to the parent menu by removing the child of item a. Selection
`may then continue from the parent.
`
`2.5.9.
`
`Aborting selection
`
`Most menu systems have a way of specifying a null selection. Generally this is
`
`accomplished by selecting outside a menu item. As explained previously, marking
`menus allow selection to occur outside the item to make selection easier. To
`
`circumvent this problem, the center hole of a menu is used to indicate no selection.
`
`Lifting the pen within the center hole results in the menu selection being aborted.
`
`A mark may be also be aborted. This involves either lifting the pen before the mark
`
`is complete or turning the mark into an uninterpretable scrawl while drawing it.
`
`2.5.10.
`
`Graphic designs and layout
`
`During everyday use of marking menus we observed some problems with a ”pie"
`
`graphical representation. First, as the number of items in the menu increases and
`
`the length of labels increases, the size of the pie grows rapidly. This creates several
`
`problems. First, having large areas of the screen display and undisplay is visually
`
`annoying.
`
`Second, a large menu occludes too much of the screen.
`
`In many
`
`situations, a menu associated with a graphical object must be popped up over the
`
`58
`
`Page 1511 of 1714
`
`

`
`object. The problem is that displaying the menu completely hides the object. This
`
`results in the context of the selection being lost. Third, large menus take time to
`
`display and undisplay.
`
`In most systems, the image ”underneath ” a menu is saved
`
`before a menu is displayed, and restored when a menu is undisplayed. When a
`
`menu is very large, these operations take considerable amounts of time because
`
`large sections of memory are being copied to and from the display. Also, algorithms
`
`for sizing and laying out labels within the pie of the menu can be quite complex.
`
`This makes the implementation of menu layout procedures complex. Complex
`
`computations may also delay the display of menus.
`
`To solve these problems we designed an alternate graphic layout for marking menus
`
`called ”label"10. Figure 2.12 shows an example. This alternate design has several
`
`advantages over a pie representation. First, it reduces the amount of screen that
`
`changes when a marking menu is displayed and undisplayed, and therefore, it
`
`reduces visual annoyance.
`
`Second,
`
`it occludes less of
`
`the screen than a pie
`
`representation because only the menu center and labels are opaque. Thus more of
`
`the context underneath a menu can be seen. This design also reduces the amount of
`
`memory that must be copied to and from the display, and hence it reduces the
`
`amount of time needed to display a menu.
`
`Another issue of graphical layout is the problem of displaying menus near an edge
`
`or corner of the screen. Pie menu systems deal with this issue by using a technique
`
`called ”cursor warping”. Unfortunately, cursor warping is not suitable for pen-
`
`based systems.
`
`In Chapter 6, we further discuss this issue and describe an
`
`alternative to cursor warping.
`
`Although not shown in Figure 2.12, marking menus have many standard features
`
`found in traditional menus. For example, marking menus allow grayed-out and
`
`checked items. Also, if an item has a submenu, a small circle appears to the right of
`
`the label. The intention is that this circle represents the center hole of the submenu.
`
`We also found it valuable to hide the labels of parent menus, thus reducing screen
`
`clutter. The only portion of a parent menu that is displayed is the center hole (so a
`
`user can point to it to back-up). We have also experimented with transparent menus
`
`10 We acknowledge Mark Tapia for his assistance in designing and implementing the alternate graphical layout
`for marking menus
`
`59
`
`Page 1512 of 1714
`
`

`
`(b)
`
`Figure 2.12.‘ An alternate graphic representation for a radial menu “label Rather
`than displaying “pie” shapes (a), only the labels and center are displayed (b). The
`menu then occludes less of display and can be displayedfaster.
`
`and graying out parent menus but a full discussion of these experiments is beyond
`
`the scope of this dissertation.
`
`2.5.11.
`
`Summary of design
`
`The previous sections described and discussed various design features and options
`
`of marking menus. We now summarize the features and indicate which design
`
`options we elected to use.
`
`Marking menus use discrimination by angle. Selection previewing in menu mode is
`
`supported by dragging the pen into an item, and the item being highlighted.
`
`Selection confirmation is indicated by a combination of boundary crossing and
`
`dwelling. Selection termination is indicated by pen up.
`
`To avoid mark ambiguities, we recommend three possible strategies: no-oping, no
`
`category selections and axis-shifting.
`
`If menus require only a few items, no-oping
`
`may be a suitable solution. If menus are only two levels deep and category selection
`
`is not required, no category selection is a suitable solution.
`
`If menus require many
`
`60
`
`Page 1513 of 1714
`
`

`
`menu items, and are more than two levels deep, axis-shifting must be used.
`
`In
`
`practice, we used no category selection in many situations.
`
`Making a selection in menu mode leaves a menu trail but only the center of parent
`
`menu is displayed. We found in practice this reduces the visual clutter the would be
`
`caused by the display of inactive parent menu items. Menus are allowed to overlap,
`
`but because only the center of parent menu is displayed, this generally does not
`cause visual confusion.
`
`In menu mode, selection can be aborted by terminating the selection while pointing
`
`to the center hole of a menu. In mark mode, selection can be aborted by turning the
`mark into a ”scribble".
`
`If a user dwells while drawing a mark, the system indicates the menu items that
`
`would be selected by the mark by displaying the menus ”along" the mark. The
`
`system then goes into menu mode. This process, called mark confirmation, can be
`
`used to verify the items that are about to be selected by a mark or a portion of a
`mark.
`
`Marking menus can be displayed in either a ”pie" representation or a ”label”
`
`representation. A ”label" representation is suitable when there is a need to
`
`minimize the amount of screen occluded by the display of the menu.
`
`2.6.
`
`SUMMARY
`
`The success of an interaction technique depends not only on its acceptance by users
`
`but also on its acceptance by interface designers and implementors. An ”industrial
`
`strength" interaction technique must not only be effective for a user, but also have
`
`the ability to co-exist with other interaction techniques, other paradigms, and
`
`differing features of the software and hardware. Because of these demands, as in
`
`many other interaction techniques, our motivation and design behind marking
`
`menus is complex. What appears on the surface as a simple interaction technique is
`
`actually based on many different motivations and has many design subtleties and
`details.
`
`In this chapter we defined marking menus and described the various motivations
`
`for developing and evaluating them. These included providing marks for functions
`
`which have no intuitive mark,
`
`supporting unfolding interface paradigms,
`61
`
`Page 1514 of 1714
`
`

`
`simplifying mark recognition, maintaining compatibility with existing interfaces,
`
`and supporting both novice and expert users. We are also motivated to study
`
`marking menus as a way to evaluate the design principles they are based on.
`
`We then outlined the issues involved in evaluating marking menus and proposed an
`
`initial design. The major parameters to be evaluated concern the question of how
`
`much functionality can be loaded on a marking menu. Essentially our research
`
`focus is on establishing the limitations of marking menus so interface designers who
`
`are utilizing marking menus can design accordingly. The remaining chapters
`
`explore the limitations and characteristics of the design.
`
`Page 1515 of 1714
`
`

`
`Chapter 3: An empirical evaluation of
`non-hierarchic marking menus
`
`This chapter addresses basic questions about marking menu design variables: how
`
`many items can marking menus contain; what kinds of input devices can be used in
`
`conjunction with marking menus; how quickly can users learn the associations
`
`between items and marks; how much is performance degraded by not using the
`
`menu;
`
`and whether there is any advantage in using an ink-trail. This chapter
`
`describes an experiment which addresses these questions. The approach is to pose
`
`specific hypotheses about the relationship between important design variables and
`
`performance, and then to test these hypotheses in the context of a controlled
`
`experiment. The results of the experiment are then interpreted to provide answers
`
`to the basic questions posed above.
`
`In this experiment we limit our investigation to non-hierarchic marking menus. We
`
`do this for several reasons. First, this experiment serves as a feasibility test of non-
`
`hierarchic marking menus. If non-hierarchic marking menus prove feasible, then an
`
`investigation of hierarchic marking menus is warranted. Second, we feel that the
`
`characteristics of non-hierarchic marking menus must be understood before we can
`
`begin to investigate hierarchic marking menus. Our findings on non-hierarchic
`
`marking menus can then be used to refine our design and evaluation of hierarchic
`
`marking menus. Third, this experiment addresses many factors. To include the
`
`additional factor of hierarchic structuring would make the experiment too large and
`
`impractical.
`
`To date there is little research applicable to our investigation. Callahan, Hopkins,
`
`Weiser, and Shneiderman (1988) investigated target seek time and error rates for 8-
`
`item pie menus, but concentrated on comparing them to linear menus. In particular
`
`63
`
`Page 1516 of 1714
`
`

`
`they were interested in what kind of information is best represented in pie menu
`format. Section 2.3.1 described their results.
`
`Our experiment focuses on selecting from marking menus using marks. To address
`
`the questions posed at the start of this chapter, the experiment examines the effect
`
`that the number of items in a menu, choice of input device, amount of practice, and
`
`presence or absence of an inl<—trail or menu, has on response time and error rate.
`
`3.1.
`
`THE EXPERIMENT
`
`3.1.1.
`
`Design
`
`In this experiment, we varied the number of items per menu and input device for
`
`three groups of subjects and asked them to select target items as quickly as possible
`
`from a series of simple pie menus. One group selected target items from fully
`
`visible or ”exposed" menus (Exposed group). Since there is little cognitive load
`
`involved in finding the target item from menus which are always present, we felt
`
`that this group would reveal differences in articulation performance due to input
`device and number of items in a menu.
`
`Two other groups selected items from menus which were not visible (”hidden”
`
`menus). In one group, the cursor left an ink-trail during selection (Marking group),
`
`and in the other, it did not (Hidden group). The two hidden menu groups were
`
`intended to uncover cognitive aspects of performance. Hiding the menus would
`
`require the added cognitive load of either remembering the location of the target
`
`item by remembering or mentally constructing the menu, or by remembering the
`
`association between marks and the commands they invoke through repeated
`
`practice. Comparing use of an ink-trail with no ink-trail was intended to reveal the
`
`extent to which supporting the metaphor of marking and providing additional
`
`visual feedback affects performance. The Exposed group provided a baseline to
`
`measure the amount
`TTIEUUS.
`
`that performance degraded when selecting from hidden
`
`3.1.2.
`
`Hypotheses
`
`We formed the following specific hypotheses to address the questions posed at the
`
`start of this chapter:
`
`Page 1517 of 1714
`
`

`
`How much is performance degraded by not using the menu?
`
`Hypothesis 1. Exposed menus will yield faster response times and lower error rates
`
`than the two hidden menu groups. However, performance for the two hidden
`
`groups will be similar to the Exposed group when the number of items per menu is
`
`small. When the number of items is large, there will be greater differences in
`
`performance for hidden versus exposed menus. This prediction is based on the
`
`assumption that the association between marks and items is acquired quickly when
`
`there are very few items. As the number of menu items increases, the association
`
`between marks and items takes longer to acquire, and mentally reconstructing
`menus in order to infer the correct mark becomes more difficult.
`
`How many items can marking menus contain?
`
`Hypothesis 2.
`
`For exposed menus, response time and number of errors will
`
`monotonically increase as the number of items per menu increases. This is because
`
`we assume that performance on exposed menus is mainly limited by the ease of
`
`articulation of menu selection, as opposed to ease of remembering or inferring the
`
`menu layout. We know that performance time and errors monotonically increase as
`
`target size decreases, all else being equal (Fitts, 1954).
`
`Hypothesis 3. For hidden menus (Marking and Hidden groups), response time will
`
`not solely be a function of number of items per menu.
`
`Instead, menu layouts that
`
`are easily inferred or that are familiar will tend to facilitate the cognitive processes
`
`involved. We predict that menus containing eight items can be more easily mentally
`
`represented than those containing seven items, for example. Similarly, a menu
`
`containing twelve items is familiar since it is similar to a clock face, and thus we
`
`predict it is more easily mentally represented than a menu containing eleven items.
`
`What kinds of input devices can be used in conjunction with rnarking menus?
`
`Hypothesis 4. The stylus will outperform the mouse both in terms of response time
`
`and errors. The mouse will outperform the trackball. This prediction is based on
`
`previous work (Mackenzie, Sellen, & Buxton, 1991) comparing these devices in a
`
`Fitts' law task (i.e., a task involving fast, repeated movement between two targets in
`
`one dimension).
`
`Hypothesis 5. Device differences will not interact with hidden or exposed menus,
`
`or the presence or absence of marks. Differences in performance due to device will
`
`65
`
`Page 1518 of 1714
`
`

`
`not depend on whether the menus are hidden or exposed, or whether or not marks
`
`are used. The rationale for this is that we assume performance differences stemming
`
`from different devices are mostly a function of articulation rather than cognition.
`
`We also assume that the articulatory requirements of the task are relatively constant
`
`across groups.
`
`Is there any advantage in using an ink—trail?
`
`Hypothesis 6. Users will make straighter strokes in the Marking group. We based
`
`this prediction on the assumption that visual feedback is provided in the Marking
`
`group and also that hidden menus support the ”marking" metaphor as opposed to
`
`the ”menu selection" metaphor.
`
`How quickly can users learn the associations between items and marks?
`
`Hypothesis 7. Performance on hidden menus (Marking and Hidden groups) will
`
`improve steadily across trials. Performance with exposed menus will remain fairly
`
`constant across trials. This prediction is based on belief that articulation of selection
`
`(or simply executing the response) will not dramatically increase with practice since
`
`it is a very simple action. Performance on hidden menus, however, involves the
`
`additional cognitive process of recalling the location of menu items. We believe this
`
`process will be subject to more dramatic learning effects over time.
`
`3.1.3.
`
`Method
`
`Subjects. Thirty-six right-handed subjects were randomly assigned to one of three
`
`groups (Exposed, Hidden, and Marking groups). All but one had considerable
`
`experience using a mouse. Only one subject had experience using a trackball. None
`
`of the subjects had experience with a stylus.
`
`Equipment. The task was performed on a Macintosh IIX computer. The standard
`Macintosh mouse was used and set to the smallest C2D ratio. The trackball used was
`
`a Kensington Turb0M0use, also set to the smallest C:D ratio. The stylus was a Wacom
`
`tablet and pressure—sensitive stylus (an absolute device). The CD ratio used was
`
`approximately one-to-one.
`
`Task. Subjects used each of three input devices to select target ”slices” from a series
`
`of pie menus as quickly and as accurately as possible. The pies contained either 4, 5,
`
`7, 8, 11, or 12 slices. All pie menus contained numbered segments, always beginning
`
`66
`
`Page 1519 of 1714
`
`

`
`with a ”1" immediately adjacent and to the right of the top segment. The other slices
`
`were labeled in clockwise order with the maximum number at the top (see Figure
`
`3.1 (a)). The diameter of all pie menus was 6.5 Cm., and Geneva 14 point bold font
`was used to label the slices.
`
`(lb)
`
`(0)
`
`Figure 3.]: Selecting item 5from an eight—item pie menu (0) in the Exposed group,
`(b) in the Hidden group, and (C) in the iMar/ting group.
`
`In designing this experiment, a great deal of time was spent discussing what kind of
`
`items should be displayed in the pie menus. Menus in real computer applications
`
`usually contain meaningful items, but the order in which they appear is not easily
`
`inferred.
`
`The numbered menus we used, on the other hand, used ordered,
`
`meaningless labels. We wanted to approximate the case of an expert user who is
`
`familiar with the menu layout. We decided to reduce as much as possible the
`
`learning time associated