* -*- Mode: outline -*- * Title Pies: Implementation, Evaluation, and Application of Circular Menus[1] Don Hopkins Jack Callahan Mark Weiser[2] Heterogeneous Systems Lab Computer Science Department University of Maryland, College Park ; Probably need my hcil address here. A different address for each author? ____________________ [1]This worked supported in part by a National Science Foundation CER grant, and by the Xerox University Grants Program. [2]Current address: Xerox Palo Alto Research Center, 3333 Coyote Hill Rd., Palo Alto, CA 94304 * Abstract ** Introduction Menus on computer displays are usually a linear row or column of choices. We propose an alternative to linear menus, called the Pie menu. The choices of a Pie menu are positioned in a circle around the menu center. The direc- tion in which the cursor is moved makes the menu selection, and the length of motion is available as a second input. Pie menus encompass most uses of linear menus, while intro- ducing many more. ** Overview *** Implementation - In this paper, we describe our implemen- - tion of Pie menus in the MIT X window system and in the Sun- - View window system. + In this paper, we describe our implementation of Pie menus + in version 10 of the X window system, the SunView window + system, and the NeWS window system. *** Evaluation We also evaluate Pie menus vs. linear menus in a controlled experiment, where we find that computer-naive subjects made selections faster, and with fewer mistakes, using Pie menus. *** Application **** Speculation, Principles, & Examples - Finally, we speculate on - the theoretical advantages of using Pie menus in new appli- - cations (or re-organized old applications). Three examples - of such advantages are: (1) the return of two kinds of - information from every Pie selection (direction and dis- - tance), (2) selection precision increases with distance, and - (3) the existence of natural opposites (left/right, - up/down). ; real-life examples are interspersed with theoretical speculation, ; illustrating it. + Finally, we speculate on the theoretical advantages of + using Pie menus in new applications (or re-organized old + applications), and suggest some design principles and + heuristics by explaining several pie menu applications + that we have been evolving. Some examples of such + applications are: + (1) the return of two kinds of information from every Pie + selection (direction and distance), + (2) selection precision increases with distance, and + (3) the existence of natural opposites (left/right, up/down). + (4) mouse ahead, muscle memory, display supression, + selection without visual attention. ; (Need an explicit term for selection w/out visual attention. Implied ; by display supression, but it should be emphesized.) ; Rearrange and update (1)-(4) so they are in the order they appear. * 1. Introduction ** 1.0. Overview We are proposing a new menu format, which we call Pie menus. We believe Pie menus offer significant advantages over other kinds of menus, and are different enough that to do them justice requires examination from many viewpoints. This paper offers three viewpoints: the implementation of - Pies in two existing window systems (X and SunView), the + Pies in three existing window systems (X, SunView, and NeWS), the evaluation of Pies vs. traditional menus in a controlled experiment, and the potential for Pies over traditional - menus for future applications. We believe the three + menus for present and future applications. We believe the three viewpoints converge to an implementable, efficacious, and exciting idea. Before starting into the viewpoints, the introduction below reviews traditional menus, and introduces Pies. ** 1.1. Traditional Menus When it comes to presenting a list of choices to the user, most computer systems have been limited, largely by the available hardware and software, to a linear format (Figure 1). As a concept, linear menus have the following properties (adapted from Shneiderman[Shneiderman 86]): (1) The selection made from a linear menu is based upon the absolute cursor location within a square coordinate grid within the menu. Usually this grid is one- dimensional (i.e. a list of items) but occasionally it is two-dimensional (and array of items.) (2) The top of a linear menu is usually a dead zone, where no item is selected. (3) If the cursor is outside the menu then (usually) no item is selected. (4) Menus are activated from mouse actions in two formats: pull-down (menu appears at a fixed label on screen) or pop-up (menu appears anywhere within a fixed area, occasionally the whole screen) Even so, many systems have used the two dimensional nature of the computer display to the advantage of certain menu applications. Many flight simulation program, for example, lay out directional headings in a typical compass format (Figure 2). Item placement in menus has been an important research topic for many years. Menu organization is typically divided into three types[Dray et al 81]: alphabetical/numerical, categorical (functional), and random ordering. It is generally agreed that the performance of subjects (i.e. time to seek a target) with different place- ment styles converges with practice[Card 82,Perlman 84]. Further studies [McDonald et al 83,Perlman 84] revealed that a functional placement of items is superior when the task domain is unambiguous to the user whereas an alphabetic organization can be useful in uncertain task descriptions. Schultz and Curran[Schultz and Curran 86] offer more evi- dence that broader, shallower menus are better. All of these studies have concentrated on the linear display for- mat. Most commercial window systems available today make a - general package of linear menu presentation available to the + general purpose linear menu package available to the programmer. Libraries of software of menu display routines are widely used as a default by programmers of many window - systems and applications[Xerox 85,Sun 86]. These libraries + systems and applications[Xerox 85,Sun 86, NeWS ??]. These libraries often have default display mechanisms which could easily accomodate other presentation methods without changing a single line of application code. Pie menus are such an alternative presentation method, one with many advantages and few disadvantages (see section 4). ** 1.2. Pie Menus The Pie menu is a concept which can have many implemen- - tations, two of which are described in a later section. As + tations, three of which are described in a later section. As a concept, Pie menus have the following properties: (1) The selection made from a Pie menu is based upon the angle between the position of the mouse down event (where the menu is centered) and that of a later mouse up event. Sometimes, in some implementations, there may be intervening mouse clicks before the final selecting event. (2) The center of a Pie menu contains a dead zone a few pixels wide. When the cursor is in the dead zone no - selection is made. Normally when a Pie menu first - appears the cursor is warped[3] into the dead zone. + selection is made. When a pie menu is popped up, + its dead zone should be centered on the location of the + mouse click that invoked it, if possible. ; Move this somewhere else... + If the menu must be moved from its ideal position in + order to fit completely on the screen, the cursor + should also be moved by the same offset. (3) Pie menus usually permit selection even when the cursor is outside menu borders. - (4) Pie menus optionally return the distance from the menu - center, as well as the item selected. + (4) Pie menus optionally return an argument based on the + distance from the menu center, as well as the item + that the direction selected. Conceptually Pie menus can parallel linear menus in functionality. Pie menus can be nested, either `layered' or `walking' (Figure 3). Pies can be thought of as simply an ; need a more generic term than walking. cascading? nested? alternative user interface into a common underlying selec- tion process. Notice that Pies have two important differences from normal menus on simple selection tasks: all items are near + ---- to and equidistant from the initial mouse position, and + -- ----------- ---- greater resolution of selection is easily available via greater motion. The last point would have significance in a situation made noisy by any of the following factors: human (hand jitter), electro-mecahnical (mouse jitter), environ- mental (room jitter). By moving the mouse a larger distance from the Pie menu center a more accurate selection is assured. This feature of Pie menus also facilitates `mouse-ahead'. Our experience has been that even an experi- enced and confident menu user will not mouse ahead to a linear menu item more than two or three from the top, while an experienced Pie menu user (one of us[4]) easily mouses ahead to any item on an eight item Pie menu. Pies can easily be used as "pull-down", as well as "pop-up", menus. To keep the menu below the selection only - a partion of a Pie can be used, resulting in a fan-like menu + a portion of a Pie can be used, resulting in a fan-like menu display. Figure 4 shows a pull-down Pie menu. * 2. Implementation - 2. Pie Implementation ** 2.1. Introduction and Problems *** Introduction ; pixie reference ; get paint program reference from Mark Callow ; "Pastel", Terry Higgins, National Film Board of Canada ; get University of Waterloo CGL references from Lyn Bartram, "Paint" ; rewrite this We do not know of Pie menus in any commercial systems. ; UniPress Emacs Imaginative menu formats, however, are inevitable with the latest advances in window management systems[Gosling 85]. + [NeWS ??] ; not true: only NeWS has arbitrarily shaped windows, not PostScript ; in general. - Window imaging systems using technology from laser printing - protocol standards such as Interpress[Xerox 84] and - PostScript[Adobe 85] will make it possible to display arbi- - trarily shaped windows effectively on a bitmapped display. ; add something general about high level imaging models and object ; oriented toolkits [Densmore ??] Circular, elliptical, and other window shapes (floral?) ; wedge, blobs, bubbles, pac-man (ref), ... - menus will be possible to implement easily[5]. There are + menus are be possible to implement easily[5]. There are some obvious advantages to this organization for particular applications: compass directions, time, angular degrees, and spatially related names are some design ideas that work well with Pie menus. However, as the next section shows, Pies win over linear menus even for ordinary tasks. - We have implemented Pies in two different window sys- - tems: X and Sunview. The next subsection discusses details - specific to these implementations. The remainder of this - subsection discusses issues that any implementation will - confront: layout within windows, and menu warping near - screen edges. + We have implemented Pies in three different window systems: + X10, Sunview, and NeWS. The next subsection discusses details + specific to these implementations. The remainder of this + subsection discusses issues that any implementation will + confront: layout within windows, cursor tracking and selection + determination, menu positioning and mouse warping, and the + handling of mouse ahead and display supression. *** Layout within windows There are two kinds of layout problems. The first is that, for small numbers of items, Pies tend to take up more space than linear menus because of the non-uniform space in a Pie selection `slice'. A triangle is hard to fill com- pletely with most text or graphics found in menu items. Both of our implementations used strictly horizontal or vertical letter placement with Pies, but even slanted letters would not fit much better. One could argue that the ; I tried slanted letters and they suck. They're much bigger! ; Icons and graphics (mostly square) work very well. unoccupied space in Pie slices is not wasted, since it par- ticipates in selection, but if screen space is critical it is still annoying. The second layout problem is simply how to arrange text around a Pie menu. Which way should letters travel, or if images are used, where should they be within the circle? Should the radius of the Pie enlarge to make all text and/or pictures fit naturally? - Both of our implementations position the midpoints of + The X10 and SunView implementations position the midpoints of each text item equally around the Pie. For a Pie with m items, the kth item will be positioned with its upper-left coordinates as follows: x=(dsin(O)+d-w) y=(dcos(O)+d-h) where d is the diameter of the Pie menu bounding box, O=2Jmk radians, w and h are the width and height of the kth item, and coordinate (0,0) is the upper-left corner of the Pie box. Using these formulas, the values of x and y must still be limited so that the menu item completely fits in the Pie box, as follows: x=max(0.0,min(d-w+2,max(2.0,x))) y=max(0.0,min(d-h-2,max(2.0,x))) The values of 2.0 keep the Pie items at least 2 pixels away from the box. The Sunview implementation can use rectangu- lar images called `Pixrects' as well as text, and these are positioned exactly as for text. The Sunview implementation attempts to automatically pick a diameter for the Pie box. It uses the heuristic d=3maxDeadZone+1, where max is the largest dimension, either width or height, of any item, and DeadZone is the size of the region at the center of a Pie where nothing is selected (typically 5). This heurestic works well if the items are approximately equal sized, but looks crowded if their is wide variation in size or many items. - And alternative, not - implemented, would be to actually compute the space taken by - each item, and enlarge the Pie until a minimum inter-item - spacing is achieved. The computational cost would not be - very high, and would be incurred only at the time of menu - specification. + The NeWS implementation computes the space taken by + each item, and pushes out the radius of the pie until no + labels overlap. It uses a different label placement + algorithm that justifies the labels around a circle. The + computational cost is not very high, and it's incurred + only at the time of menu layout. ; detail the NeWS layout algorithm *** Cursor tracking and selection determination One of our early concerns was for what we thought would be the high cost of computing selections from mouse posi- tions. While a linear menu can simply compare coordinates, a Pie needs trigonometry. Our first implementation, in X, goes to great length to avoid calling arctan. In retrospect this was unnecessary, since arctan2 on our hardware is fast enough (2.3 milliseconds on a Sun-3 with 68881 FP chip, 6.6 milliseconds on a Sun-2 with software-only FP) that it does not interfere with accurate tracking. A menu is only track- ing selections for a few seconds at a time, and an overhead of 6.6 milliseconds per cursor update still leaves plenty of idle cpu time. ; Describe quadrant/slope algorithm *** Menu positioning amd mouse warping The menu warping problem is common to all popup menu systems, but is particularily acute for Pie menus because of the requirement that the cursor start in the center of the menu. Normally a menu will popup (or pulldown) starting at the position of the cursor when the menu is first activated. However, if the cursor is close to the edge of the screen the menu may not completely fit, and must be displayed in a slightly different screen position. Because of mouse-ahead and other user expectations, if the menu is displayed askew then the cursor must also be moved so that it is in the same position relative to the menu that it would have been had the menu not moved. This automatic moving of cursor and menu near the edge of the screen is called `mouse warping'. Linear menus are normally smaller than Pie menus, and the cursor normally starts near the edge of a linear menu, often at the top edge or the top item. The large size of Pie menus, and the need to move the mouse to the middle of this larger size, make good warping more important for Pies than for linear menus. The most basic warp algorithm, used in our Sunview implementation, is to simply force the menu onto the screen, and then warp the mouse to the middle. Unfortunately, this makes mousing ahead impossible, since all mouse motion before the warp is lost. A better algorithm, which we used for a time in X, looks at the offset between the mouse down event and the current mouse location, and warped the mouse to the center of the (repositioned) menu plus that offset. However, this complicates things if there are more input events pending. The positions associated with pending events are still relative to the unwarped mouse position, and in particular the angle towards the pending mouse up event that specifies the current selection is different after the mouse has been warped. Also, if the last pending event is a mouse down, the angle between that event and the current mouse position changes. *** Mouse ahead and display supression ; Introduce display supression, and describe the rationale for it - Our most sophisticated solution is in our current X + A more sophisticated solution is in our X10 implementation. There, we only put up a menu when there are no pending mouse button events. When there are events pend- ing, they are acted upon without putting up a menu. When there are not, and more are needed to complete a selection, a menu is actually put up. If the menu would not fit com- pletely on the screen, it is moved by the appropriate offset back onto the screen, and the mouse is warped to its current location plus that same offset. Normal tracking then begins. For instance, if at the time the mouse down event is received, the mouse up event that completes the selection is already pending, then there is already enough information to make the selection. It is not appropriate to look at the current mouse position, because the selection has already been completely specified. At this point, putting the menu up serves no purpose but feedback, and slows down interac- tion. The selection can be made and acted upon without even showing a menu, if feedback is not required, or if acting on a selection provides the feedback. ; Describe mouse warping, mouse ahead, and display supression as implemented ; in NeWS. Point out how these features tightly interact to support a ; kinesthetic illusion of directional certianly. *** Figures ____________________________________________________________ Figure 1: A linear menu. ____________________________________________________________ ____________________________________________________________ Figure 2: Flight simulation compass display. ____________________________________________________________ ____________________________________________________________ Figure 3: Nested pies, both `stack-of-cards' and walking. ____________________________________________________________ ____________________________________________________________ Figure 4: A pull-down Pie. ____________________________________________________________ *** Footnotes ____________________ [3]Warping refers to moving the on-screen cursor when the user has not moved the mouse. Proper warping is essential to good menu "feel" when popping up menus near the edge of the screen. See additional discussion in section 2.1. [4]Hopkins. [5]Many of the more fanciful figures in this paper were generated directly from Postscript programs. --------------------- ** 2.2. Implementation Details *** X10 ; Tone this down a bit. Not so much detail about the .uwmrc file. ; The NeWS stuff is more useful and interesting. Our implementation of Pie menus in the Ultrix window - manager uwm of the X Window System (V10r4)[Gettys 86] uses + manager uwm of the X Window System, Version 10, + Release 4 [Gettys 86], uses no new window management techniques, and in fact places the circularly arranged selection items within a rectangular popup window (Figure 5). Adding Pie menus to uwm required writing 500 new lines of code, most of them changes to a single module. The task took one of us (Don Hopkins) about a month of part-time work, some of which was experimenting with display algorithms. At the time Pie menus were first implemented (June 1986) there was not a standard menu package in X. Different applications used their own libraries. Therefore, our implementation was put into one of those applications, `uwm'. Uwm is the most flexible of the X window managers, and is extensively customized for individual users by a spe- cial startup file (`.uwmrc'). Customization can include the specification of new popup menus, and the action to be taken when menu items are selected. ; Most of the following paragraph should probably go. We augmented the language of the .uwmrc file to include new menu specification keywords. There is a global keyword, `piemenus', which when encountered causes menus to default to Pie menus. The new keyword `Pulldownmenus' has the oppo- site effect. There are also new keywords for individual menu specifications: `piemenu' and `pulldownmenu'. `Pulldownmenu' forces the usual uwm menu, `piemenu' the new style, regardless of the global keyword. For Pie menus, the user can also specify the direction and distance of the first item of the menu. By default the first item is put at the `12 o'clock' position, at a distance determined by the `radius' global keyword. The Pie code was integrated into the existing uwm menu code so that no part of uwm except the menu implemenation (and the .uwmrc parser) knew anything about Pies. The result was a very smooth integration, upward compatible with existing use but, by setting one variable, upgradable to make all menus Pies. *** SunView There is now (March 1987) a second implementation of Pie menus, mostly compatible with the normal Sun Microsys- tems menu library, and living in SunView (see Figure 6). This required changing no lines of existing Sun source code, but is itself about 500 new lines of code. Existing modules can use Pie menus by compiling against the new library. Not all features of the Sun menu library have been implemented, just all those that are used by the background menu process, 'suntools'. This implementation took one of us (Mark Weiser) a (snowed-in) weekend. It supports the following features of Sunview menus: nested (walking) menus, images or text for items, and user-procedure callback on selection. It does not support generating menus on-the-fly, or every different Sunview method of menu specification (of which - there are many). It differs from our X implementation in + there are many). It differs from our X10 implementation in having automatic diameter calculation, optional image-based items, and less sophisticated warping. *** NeWS ; Describe NeWS implementation ; Describe how many instance variables, methods, etc... * 3. Evaluation ** 3.1. Hypothesis We performed a controlled experiment to test two hypothesis: that Pie menus decrease the seek time for menu items and that Pie menus are especially useful in menu applications suited for a circular format or diametrically opposed item sets. Only a summary of the experiment is given here--full details will appear elsewhere[Callahan et al '87]. We expected Pie menus to do better primarily because of the decreased distance to the target in Pies when compared to linear menus. The distance to an item in any menu style can be defined as the minimum distance needed to highlight the item as selected. In both menu styles, this is defined by a region rather than a point. This region is typically of greater area than the actual target (Figure 7). Once the cursor has entered the region, the item is highlighted as feedback to the user. Note that the regions may extend beyond the menu window itself. Even with linear menus where the cursor may be placed initially in the middle of the list, the outer item choices suffer from their distance from the initial cursor location. Pie menus, in fact, enjoy a two fold advantage because of their unique design: all items are equidistant, and that distance is in fact quite small when measured as the cursor motion needed to select an item. ** 3.2. Experimental Design The experiment is fairly straightforward and is con- structed in a 2x3 randomized block design [Kirk68] (Table 1). ____________________________________________________________ ___________________________________________________________________ task: | `pie' | `linear' | unclassified | ==================================================================== using pie menus | | | | ___________________________________________________________________ using linear menus| | | | ___________________________________________________________________ Table 1. The 3x2 experimental design. ____________________________________________________________ Each cell is an element of the cross product of menu type and task. A typical Pie task would be a compass because it seems best suited functionally for Pie menus. List of ele- ments, like OPEN/CLOSE and UP/DOWN, whose meanings are anto- nyms are also classified as Pie tasks. Lists, like numbers, letters and ordinals, are best suited for linear menus and are thus classified as linear tasks. Groups of menu items that have no relation to each other fall in the unclassified category. As it turned out, Pies were better for all three groups of menu items. ; zap this: There are a total of 15 menus, a group of 5 for each task type (column). Subjects performed the experiment for all cells in the experiment matrix in random order in accor- dance with a randomized block design [Kirk68]. The subjects saw the same menu four times, twice in each menu format. Each subject therefore saw a total of 60 menus. The target item in each menu varied for the menu type and were balanced in their placement. ; zap this: Subjects were taken from the University of Maryland Psychology Department Subject Pool. 26 subjects performed the experiment in addition to 16 pilot subjects. All sub- jects were undergraduate students with little or no mouse experience. They were rewarded with 1 extra credit point for participating. ** 3.3. Materials ; Shorten this: The experiment was run on a Sun Microsystems Worksta- - tion Model 3/160 running MITs X window system with the uwm + tion Model 3/160 running MITs X window system Version 10 + Release 4 with the uwm window manager modifed for Pie menus. (This modification is described earlier in this paper). To make a selection, the ; Maybe mention Sun Forth prototyping system. user invokes the menu by pressing a mouse button, continues to hold the mouse button down and moves to an item which is then highlighted, and releases the mouse button confirming the selection. A typical sequence of events for the user is shown in Figure 8. The computer posts the target name at the top of the screen, the user invokes the current menu, moves to the target item, and confirms the selection by releasing the mouse button. This sequence, called a task, was repeated 60 times by each subject. Each subject saw 6 sequences of 10 menus each. In each ten menu sequence, the menu type was the same, either Pie or linear, and since there are only 5 menus per task type, each menu appears twice in the sequence. The 10 menus sequences correspond to the cells in the experiment table design. Each subject performed a sequence for all 6 cells and in random order. 60 data points were collected per subject. A total of 26 subjects performed the experiment for a total of 1560 data points. For each task, the time from the first mouse button down to the correct target selection is the seek time for the item. If the user selected the wrong item, this time is included in this interval. The number of errors made as well as the sub-interval times when errors are made is recorded during the experiment by the system. ** 3.4. Results Figure 9 displays the target location by item, plotted against the mean seektime. The mean seektime across target location for Pie menus is fairly constant. As expected for linear menus, the mean seek time increases proportional to the distance of the target from the initial cursor location. There was a slight learning effect for both Pies and linear menus, but Pies were consistently faster. This can be par- tially attributed to the constant item distance advantage of Pie menus, and partially to the small motion necessary to make a Pie selection. ; mention that up and down were the overall fastest and most reliable? Figure 10 plots the number of menus seen against the mean seek time for all menus that appeared at a particular point in the sequence of 60 menus. The region between pie and linear menu seek times seems fairly constant. It may be reasonable to assume that for this configuration of 8 items on a pie menu, linear menu performance will always be slightly slower (about 1.5 seconds). This can be attributed to the constant item distance advantage of pie menus. Figure 11 displays the target location plotted against the number of errors. Pie and linear menus seem to suffer from a similar phenomenon-errors are made more on items half-way down the list. These are the items with the most interaction with neighboring items[Card 82]. The difference between Pies and linear menus, for both errors and times, was very significant (at better than the 0.0001 level, according to SAS ANOVA and Tukey analysis). *** Figures ; Figures as both pie and bar graphs? ; Pull-out pie chart? ____________________________________________________________ Figure 5: A Pie as it appears in X, within rectangle. ____________________________________________________________ ____________________________________________________________ Figure 6: Pie on a Sunview screen. ____________________________________________________________ ____________________________________________________________ Figure 7: Pie menu activation region. ____________________________________________________________ ____________________________________________________________ Figure 8: A typical task session for the Pie experiment. ____________________________________________________________ ____________________________________________________________ Figure 9: Target location (x) vs. seektime (y) in seconds. ____________________________________________________________ ____________________________________________________________ Figure 10: Seektime (y) vs. time menu was seen by subject. ____________________________________________________________ ____________________________________________________________ Figure 11: Target location (x) vs. number of errors (y). ____________________________________________________________ ** 3.5. Discussion of Experimental Results This description of the experiment is greatly abbrevi- ated, and so also is our discussion. See the full paper on the experiment for complete details and discussion[Callahan et al '87]. The most basic limitation of this experiment is that it only addresses menus consisting of 8 items. Secondly, it does not offer an evaluation of the basic disadvantage of Pies, increased usage of screen real estate. There were no nested menus in this experiment. And there is the question raised by the almost even division of subjects between Pie and linear menus in subjective satisfaction. Many claimed it was difficult to home in on a particular item because of the region of activation sensitivity of the Pie menu design. One continuing issue with Pie menus is the limit on the number of items that can be placed in a circular format before the clutter or size of the menu window is impractical for implementation of an application as a Pie menu. Perhaps, like the limiting factors active in linear menus concerning their lengths, Pie menus reach a similar breaking point beyond which other menu styles would be more useful. Additional experiments could determine where, if anywhere, this point is. * 4. Application - 4. Applications and Implications ** 4.1. Implications ; rename or pop this section ; work principles from the pie menu cookbook into here... ; Intersperse explainations of principles with application examples, ; instead of putting them in different sections. *** Introduction - Pie menus are not just another way of showing a menu. - They offer an additional degree of information, the radius - of selection, and open the door to some rather different - interaction styles. In this section we speculate on some - future uses of Pie menus. ; reword the above + Pie menus are not just another way of showing a menu. + They offer two degrees of information, the direction and + the distance, and open the door to some rather different + interaction styles. In this section we suggest principles + and heuristics for designing efficient, easy to use pie + menus, and describe interaction techniques that exploit + their multi-dimensional properties. The discussion is + illustrated with examples of pie menu applications we have + implementated and used. *** Direction Pie menus naturally extend to selecting from hundreds - of linearly items. We have actually used a Pie menu with + of linear items. We have actually used a Pie menu with 360 items to select a value; Figure 12 is an example of an very natural 60 item menu. This enables menus to play the role that must normally be filled by some completely dif- ferent interaction formats, such as graphical sliders. ; mention that both direction and/or distance can be used as a continuous ; input. *** Convenient Directions Pies menus raise the question of a philosophy of con- venient directions. A selection's position relative to other selections is an important factor. A selections could be placed opposite of one that complements it, and 90 (or what- ever) degrees away from ones that are orthogonal to it. (Figure 2 is an example.) There may be other ways to make selection directions easy to remember and use. ; Some menus can be arranged so that the directions of the ; keys are intuitivly or mnemonically related to their ; function. ; week days, ... ; Picture of PostScript object editor menu? (spike) *** Nested pie menus ; (also mention why automatically popping up a submenu when ; the mouse moves out of the round window would be a bad idea): Pie ; submenus should pop up in response to a distinct, directly initiated ; action on part of the user, not as an indirect result of his ; actions, such as having moved the mouse by a certian distance, or ; outside of the menu window (as is the case with "pull right" linear ; menus). The user is not in direct control of when the mouse exits ; the menu window, so that is not a good trigger for submenu popup. ; The user is in direct control of the position of the mouse, but must ; look at the screen to be able to know how far to move the cursor ; towards the the edge of the menu. More importantly, this would ; preclude the use of mouse-ahead and menu display supression with ; nested menus. It is crucial to the feel of pie menus that the user ; be confidant of the location of the center of the menu, relative to ; the mouse position. (That's why all the fuss about mouse warping.) ; [Stress that point as a design principle.] By consistantly invoking ; menus with a kinesthetically explicit click of the mouse, the user ; can always be sure of the starting point from which each step is ; taken. Nested Pie menus tend to leave a trail on the screen - (see Figure 13), and an equivalent kinaesthetic 'trail' in + (see Figure 13), and an equivalent kinesthetic 'trail' in the way the user's arm moves. This could make nested Pie menu selections must easier to remember, using 'muscle memory', than an equivalently nested linear menu. Experts could simply move ahead, while novices could wait to look at each menu. The authors' own experience is that mousing ahead to nested menus is considerably easier with Pies. In ; stronger: considerably easier, and quite reliable with practice - addition to mouse ahead, the good kinaesthesia of Pies means + addition to mouse ahead, the good kinesthesia of Pies means a user can be looking at something in one window while traversing menus in another. ; this makes supporting display supression desirable *** Selecting without looking + Because pie menus are based on direction of relative mouse + movement, they do not require a lot of visual attention to use. An + experienced pie menu user can make selections fairly reliably from a + familiar, reasonably sized menu, without even looking at the display! *** Mouse Ahead + One of the nicest advantages of pie menus is that they work very well + with "mouse ahead". Mouse ahead is when the user gives commands to the + computer with the mouse more quickly than the computer can process, + but instead of ignoring the commands, the computer buffers them, and + processes them all in order. Because it possible to use a pie menu + without seeing it, experienced pie menu users are able to mouse ahead + through several levels of nested menus without waiting for them to be + displayed. ; tie in with display supression? + Experienced users actually tend to start moving the mouse + in the direction of the desired selection before pressing + the button to invoke the menu. An experienced user can + select from a pie menu using muscle memory, by sweeping + the mouse in a certian direction, pressing and releasing + the button along the way. With experience, one can even + make quick selections from several levels of nested pie + menus, "chunking" together the series of selection actions + into a single habitual gesture, remembered as a spatial + path, rather like traveling from room to room, or shifting + gears. *** Display Supression + With mouse ahead display suppression, a menu is not displayed on the + screen if the user mouses ahead through it quickly enough. If the user + completes the selection before the menu can be displayed, it is no + longer necessary for the user to see the menu, if feedback is not + required, or if acting on the selection provides feedback. + Experienced users can learn to "chunk" multiple selection actions into + single gestures that can be performed quickly and automatically + (Buxton, 1986), and can utilize mouse ahead display suppression more + often than a novice user. This feature speeds up interaction + considerably if the user is fast or the system is unresponsive. *** Window Managment Example ; descriptions and pictures from Pie Menu Cookbook ; window management menus *** Distance ; (Point out the reason for (3) [cursor outside menu border]): ; so that the user may increase the angular precision by moving out further, ; and so it's not necessary to look at the screen to make a selection. + It's useful to move out far when mousing ahead, to ensure an + accurate selection. Some window systems, such as X10, + provide "mouse acceleration," which magnifies the cursor + motion when the mouse moves quickly. Because this feature + increases the distance but not the direction of + movement, it works synergistically with pie menus, although + it's actually detrimental to the use of linear menus. ; precision pie menu illustration and explaination ; (distance gives exagerated accuracy) *** Distance as an Argument A Pie menu can return both direction and distance information about a selection. A number of applications ; each continuous or discrete could take advantage of this; generally anything which can use two dimensions of input. A few examples are: (1) Specifying direction and distance in a flight simula- tor. (2) Simultaneously selecting a font style (direction) and size (distance). (3) Simultaneously selecting a window type and size. + (4) Selecting a color and brightness; selecting a hue and + saturation. ; etc... Show examples. ; descriptions and pictures from emacs style menus ; (distance is an argument) ; color/brightness hue/saturation menus, ; font style/size menus *** Figures ____________________________________________________________ Figure 12: Sixty item pie. ____________________________________________________________ ____________________________________________________________ Figure 13: Trails of nested pies. ____________________________________________________________ * 5. Conclusions Pies are seem to be an exciting new development in menu design. Against their single major disadvantage of increased screen real-estate, they offer the following advantages: (1) More information returned (item and radius). (2) Much less mouse motion necessary. (3) All items are nearby and equidistant. (4) Variable (and increased) precision of selections. + (4.5) They don't requires visual attention to use. ; reword & renumber ; move to implications? (5) Selecting a Pie menu item is twice as fast as selecting a linear-menu item (experimentally measured). (6) Selecting a Pie menu item results in one-fourth as many errors as selecting a linear-menu item (experimentally measured). (7) Compatible with existing programming interfaces to menu systems. (8) Relatively easy to implement. * Acknowledgements Ben Shneiderman provided advice on experimental design. Linda Weldon helped with statistics. Glenn Pearson and John Chin were generally helpful with menus and experiments. + Mike Gallaher + Mitch Bradley * References ** Hopkins, Don + "A Pie Menu Cookbook" ** Hopkins, Don + Usenix WIP summary, "Directional Selection is Easy as Pie Menus!" ** Sun Microsystems [NeWS ??] + NeWS manual ** Densmore, Owen + "Object Oriented Programming in NeWS" ** Buxton, Bill + ...muscle memory, chunking, phrasing, kinesthetics, ... ** Callahan et al '87. Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman, "Experiments with Pie Menus," in prepara- tion, (). ; CHI '88 proceedings ** Card 82. Stuart K. Card, "User perceptual mechanisms in the search of computer command menus," Proc. Human Factors in Computer Systems, pp. 190-196. (March 1982). ** Xerox 84. Xerox Corporation, Interpress Electronic Printing Stan- dard, Xerox Corporation, Stamford, Conn. (1984). ** Dray et al 81. S. M. Dray, W. G. Ogden, and R. E. Vestewig, "Measuring performance with a menu-selection human computer inter- face," Proc. Human Factors Society, 25th Annual Meet- ing, pp. 746-748 (1981). ** Gettys 86. James Gettys, "Problems Implementing Window Systems in UNIX," Proceedings of the 1986 Winter Usenix Technical Conference, pp. 89-103 (January, 1986). ** Gosling 85. James Gosling, "SunDew - A Distributed and Extensible Window System," pp. 47-57 in Methodology of Window Management, ed. F.R.A. Hopgood,Springer-Verlag (1985). (SunDew has now gone commercial under the name NeWS.) ** McDonald et al 83. James E. McDonald, Jim D. Stone, and Linda S. Liebelt, "Searching for items in menus: The effects of organiza- tion and type of target," Proc. Human Factors Society, 27th Annual Meeting, pp. 834-837. (1983). ** Sun 86. Sun Microsystems, SunView Programmer's Guide (Revision A of 19)September 1986. ** Perlman 84. Gary Perlman, "Making the right choices with menus," INTERACT '84, First IFIP International Conference on Human Computer Interaction, pp. 291-295 North-Holland, (September 1984). ** Shneiderman 86. Ben Shneiderman, Designing the User Interface, Addison-Wesley Publishing Company (1986). ** Adobe 85. Adobe Systems, Postscript Language Reference Manual, Addison-Wesley (1985). ** Xerox 85. XeroxCorporation, Mesa Programmers Manual and ViewPoint Programmers Manual, Xerox Corporation, Palo Alto, Cali- fornia (1985). ** Schultz and Curran 86. E. Eugene Schultz Jr. and Patrick S. Curran, "Menu Structure and Ordering of Menu Selections: Independent or Interactive Effects?," SIGCHI Bulletin Vol. 18(2)(October 1986). (summary from poster session of CHI '86)