throbber
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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket