THE DESIGN AND IMPLEMENTATION OF PIE MENUS
They're fast, easy, and self-revealing
Don Hopkins
Don is a software engineer for SunSoft and can be contacted at 88 Mercy Street, Mountain View, CA 94041.
Although the computer screen is two-dimensional, today most users of windowing environments control their systems with a one-dimensional list of choices -- the standard pull-down or drop-down menus such as those found on Microsoft Windows, Presentation Manager, or the Macintosh.
This article describes an alternative user-interface technique I call "pie" menus, which is two-dimensional, circular, and in many ways easier to use and faster than conventional linear menus. Pie menus also work well with alternative pointing devices such as those found in stylus or pen-based systems. I developed pie menus at the University of Maryland in 1986 and have been studying and improving them over the last five years.
During that time, pie menus have been implemented by myself and my colleagues on four different platforms: X10 for the uwm window manager, SunView, NeWS for the Lite Toolkit, and Open Windows for THE NeWS Toolkit. Fellow researchers have conducted both comparison tests between pie menus and linear menus, and also tests with different kinds of pointing devices, including mice, pens, and trackballs.
Included with this article are relevant code excerpts from the most recent NeWS implementation, written in Sun's object-oriented PostScript dialect.
Pie Menus Properties
In their two-dimensional form, pie menus are round menus containing menu items positioned around the cursor--as opposed to the rows or columns of traditional linear menus. The menu item target regions are shaped like the slices of a pie, and the cursor starts out in the center, in a small inactive region. The active regions are all adjacent to the cursor, but each in a different direction. You select from a pie menu by clicking the mouse or tapping the stylus, and then pointing in a particular direction.
Although there are multiple kinds of pie menus, the most common implementation uses the relative direction of the pointing device to determine the selection--as compared with the absolute positioning required by linear menus. The wedge-shaped slices of the pie, adjacent to the cursor but in different directions, correspond to the menu selections. Visually, feedback is provided to the user in the form highlighting the wedge-shaped slices of the pie. In the center of the pie, where the cursor starts out, is an inactive region.
When a pie menu pops up, it is centered at the location of the click that invoked it: where the mouse button was pressed (or the screen was touched, or the pen was tapped). The center of the pie is inactive, so clicking again without moving dismisses the menu and selects nothing. The circular layout minimizes the motion required to make a selection. As the cursor moves into the wider area of a slice, you gain leverage, and your control of direction improves. To exploit this property, the active target areas can extend out to the edges of the screen, so you can move the cursor as far as required to select precisely the intended item.
You can move into a slice to select it, or move around the menu, reselecting another slice. As you browse around before choosing, the slice in the direction of the cursor is highlighted, to show what will happen if you click (or, if you have the button down, what will happen if you release it). When the cursor is in the center, none of the items are highlighted, because that region is inactive.
Pie menus can work with a variety of pointing devices--not just mice, but also pens, trackballs, touchscreens, and (if you'll pardon the hand waving) data gloves. The look and feel should, of course, be adapted to fit the qualities and constraints of the particular device. For example, in the case of the data glove, the two-dimensional circle of a pie could become a three-dimensional sphere, and the wedges could become cones in space.
In all cases, a goal of pie menus is to provide a smooth, reliable gestural style of interaction for novices and experts.
Pie Menu Advantages
Pie menus are faster and more reliable than linear menus, because pointing at a slice requires very little cursor motion, and the large area and wedge shape make them easy targets.
For the novice, pie menus are easy because they are a self-revealing gestural interface: They show what you can do and direct you how to do it. By clicking and popping up a pie menu, looking at the labels, moving the cursor in the desired direction, then clicking to make a selection, you learn the menu and practice the gesture to "mark ahead" ("mouse ahead" in the case of a mouse, "wave ahead" in the case of a dataglove). With a little practice, it becomes quite easy to mark ahead even through nested pie menus.
For the expert, they're efficient because -- without even looking -- you can move in any direction, and mark ahead so fast that the menu doesn't even pop up. Only when used more slowly like a traditional menu, does a pie menu pop up on the screen, to reveal the available selections.
Most importantly, novices soon become experts, because every time you select from a pie menu, you practice the motion to mark ahead, so you naturally learn to do it by feel! As Jaron Lanier of VPL Research has remarked, "The mind may forget, but the body remembers." Pie menus take advantage of the body's ability to remember muscle motion and direction, even when the mind has forgotten the corresponding symbolic labels.
By moving further from the pie menu center, a more accurate selection is assured. This feature facilitates mark ahead. Our experience has been that the expert pie menu user can easily mark ahead on an eight-item menu. Linear menus don't have this property, so it is difficult to mark ahead more than two items.
This property is especially important in mobile computing applications and other situations where the input data stream is noisy because of factors such as hand jitter, pen skipping, mouse slipping, or vehicular motion (not to mention tectonic activity).
There are particular applications, such as entering compass directions, time, angular degrees, and spatially related commands, which work particularly well with pie menus. However, as we'll see further on, pies win over linear menus even for ordinary tasks.
Pie Menu Flavors
There are many possible flavors or variants of pie menus. One obvious variation is to use semicircular pie ("fan") menus at the edge of the screen.
Secondly, although the usual form of pie menus is to use only the directional angle in determining a selection, there is a variant of pie menus which offers two parameters of choice with a single user action. In this case, both the direction and the distance between the two points are used as parameters to the selection. The ability to specify two input parameters at once can be used in situations where the input space is two-dimensional.
For example, in a graphics or word processing applications, a dual-parameter pie menu will allow you to specify both the size and style of a typographic font in one gesture. The direction selects the font style from a set of styles, and the distance selects the font size from the range of sizes. An increased distance from the center corresponds to an increase in the size of the font. Visual feedback can be provided to the user by making a text sample swell or shrink dynamically as the pointer is moved to and fro. Direction and distance can be continuous or discrete, as appropriate.
A minor variation in the use of pie menus is whether you click-and-drag as the menu pops up, or whether two clicks are required: one to make the menu appear, another to make the selection. In fact, it's possible to support both.
Other variants include scrolling spiral pies, rings, pies within square windows, and continuous circular fields. These variants are discussed in a later section.
Pie Menu Implementations
As mentioned earlier, several pie menu implementations exist, including: X10, SunView, and two NeWS implementations (using different toolkits).
I first attempted to implement pie menus in June 1986 on a Sun 3/160 running the X10 window system by adding them to the "uwm" window manager. The user could define nested menus in a ".uwmrc" file and bind them to mouse buttons. The default menu layout was specified by an initial angle and a radius that you could override in any menu in which labels overlapped. The pop-up menu was rectangular, large enough to hold the labels, and had a title at the top.
Then I linked the window manager into Mitch Bradley's Sun Forth, to make a Forth-extensible window manager with pie menus. I used this interactively programmable system to experiment with pie menu tracking and window management techniques, and to administer and collect data for Jack Callahan's experiment comparing pie menus with linear menus.
In January 1987, while snowed in at home, Mark Weiser implemented pie menus for the SunView window system. They are featured in his reknowned "SDI" game, the source code for which is available free of charge.
I implemented pie menus in round windows for the Lite Toolkit in NeWS 1.0 in May 1987. The Lite Toolkit is implemented in Sun's object-oriented PostScript dialect, and pie menus are built on top of the abstract menu class, so they have the same application interface as linear menus. Therefore, pie menus can transparently replace the default menu class, turning every menu in the system into a pie, without having to modify other parts of the system or applications.
Because of the equivalence in semantics between pie menus and linear menus, pies can replace linear menus in systems in which menu processing can be revectored. Both the Macintosh and Microsoft Windows come to mind as possible candidates for pie menu implementations. Of course, for best results, the application's menu items should be arranged with a circular layout in mind.
My most recent implementation of pie menus runs under the NeWS Toolkit, the most modern object-oriented toolkit for NeWS, shipped with Open Windows, Version 3. The pie menu source code and several special-purpose classes, as well as sample applications using pie menus are all available for no charge.
Usability Testing
Over the years, there have been a number of research projects studying the human factors aspects of pie menus.
Jack Callahan's study compares the seek time and error rates in pies versus linear menus. There is a hypothesis known as Fitts's law, which states that the "seek time" required to point the cursor at a target depends on the target's area and distance. The wedge-shaped slices of a pie menu are all large and close to the cursor, so Fitts's law predicts good times for pie menus. In comparison, the rectangular target areas of a traditional linear menu are small, and each is placed at a different distance from the starting location.
Callahan's controlled experiment supports the result predicted by Fitts's law. Three types of eight-item menu task groupings were used: Pie tasks (North, NE, East, and so on), linear tasks (First, Second, Third, and so on), and unclassified tasks (Center, Bold, Italic, and so on). Subjects with little or no mouse experience were presented menus in both linear and pie formats, and told to make a certain selection from each. Those subjects using pie menus were able to make selections significantly faster and with fewer errors for all three task groupings.
The fewer the items, the faster and more reliable pie menus are, because of their bigger slices. But other factors contribute to their efficiency. Pies with an even number of items are symmetric, so the directional angles are convenient to remember and articulate. Certain numbers of items work well with various metaphors, such a clock, an on/off switch, or a compass. Eight-item pies are optimal for many tasks: They're symmetric, evenly divisible along vertical, horizontal, and diagonal axes, and have distinct, well-known directions.
Gordon Kurtenbach carried out an experiment comparing pie menus with different visual feedback styles, numbers of slices, and input devices. One interesting result was that menus with an even number of items were generally better than those with odd numbers. Also, menus with eight items were especially fast and easy to learn, because of their primary and secondary compass directions. Another result of Kurtenbach's experiment was that, with regard to speed and accuracy, pens were better than mice, and mice were better than trackballs.
The "Eight Days a Week" menu shown in Figure 2 is a contrived example of eight-item symmetry: It has seven items for the days of the week, plus one for today. Monday is on the left, going around counterclockwise to Friday on the right. Wednesday is at the bottom, in the middle of the week, and the weekend floats above on the diagonals. Today is at the top, so it's always an easy choice. THE NeWS Toolkit code that creates this pie menu is shown in Listing One (page 94).
Pie Menu Disadvantages
The main disadvantage of pie menus is that when they pop up, they can take a lot of screen space due to their circular layout. Long item labels can make them very large, while short labels or small icons make them more compact and take up less screen space.
The layout algorithm should have three goals: to minimize the menu size, to prevent menu labels from overlapping, and to clearly associate labels with their directions. It's not necessary to confine each label to the interior of its slice--that could result in enormous menus. In a naive implementation, you might use text labels rotated around the center of the pie. But rotated text turns out not to work well, because it exaggerates "jaggies." This is hard to read without rotating your head, and doesn't even satisfy the goal of minimizing menu size.
One successful layout policy I've implemented justifies each label edge within its slice, at an inner radius big enough that no two adjacent labels overlap. To delimit the target areas, short lines are drawn between the slices, inside the circle of labels, like cuts in a pie crust.
One solution to the problem of pie menus with too many items is to divide up large menus into smaller, logically related submenus. Nested pies work quite well, and you can mark ahead quickly through several levels. You remember the route through the menus in the same way you remember how to drive to a friend's house: by going down familiar roads and making the correct turn at each intersection.
Another alternative is to use a scrolling pie menu that encompasses many items in a spiral but only displays a fixed number of them at once. By winding the cursor around the menu center, you can scroll through all the items, like walking up or down a spiral staircase.
Other Design Considerations
When you mark ahead quickly to select from a familiar pie, it can be annoying if the menu pops up after you've already finished the selection, and then pops down, causing the screen to repaint and slowing down interaction. If you don't need to see the menu, it shouldn't show itself. When you mark ahead, interaction is much quicker if the menu display is preempted while the cursor is in motion, so you never have to stop and wait for the computer to catch up. If you click up a menu when the cursor is at rest, it should pop up immediately, but if you press and move, the menu should not display until you sit still. If you mark ahead, selecting with a smooth continuous motion, the menu should not display at all. However, it's quite helpful to give some type of feedback, such as displaying the selected label on an overlay near the cursor, or previewing the effect of the selection.
When you pop up a pie menu near the edge of the screen, the menu may have to be moved by a certain offset in order to fit completely on the screen, otherwise you couldn't see or select all the items. But it would be quite unexpected were the menu to slip out from under the click, leaving the cursor pointing at the wrong slice. So whenever the menu is displayed on the screen, and it must be moved in order to fit, it is important to"warp" the cursor by the same offset, relative to its position at the time the menu is displayed. If you mark ahead so quickly that the menu display is preempted, the cursor shouldn't be warped. Pen- and touchscreen-based pie menus can't warp your pen or finger, so pie menus along the screen edge could pop up as semicircular fans. Note that cursor warping is also an issue that linear menus should address.
Ideally, pie menu designers should arrange the labels and submenus in directions that reflect spatial associations and relationships between them, making it easy to remember the directions. Complementary items can be opposite each other, and orthogonal pairs at right angles.
It's difficult to mark ahead into a pie menu whose items are not always in the same direction, because if the number of items changes, and they move around, you never know in which directions to expect them. Pie menus are better for selecting from a constant set of items, such as a list of commands, and best when the items are thoughtfully arranged to exploit the circular layout.
Sample Pie Menu
The pie menu shown in Figure 3 is an example of one that I added to the NeWS environment. Clicking on the window frame pops up this menu of window-management commands, designed to take advantage of mark ahead. Because this menu is so commonly used, you can learn to use it quickly, and save a lot of time. At the left of the figure is the top-level menu with commonly used commands and logically related submenus. The Grab item has been selected, popping up a graphical submenu of corners and edges. The icon for the bottom edge is highlighted, but has not yet been selected. Clicking in that slice allows you to grab and stretch the edge of the window frame.
Figure 4 shows as second example, a color wheel that allows you to set the brightness, and to select a color from a continuous range of hues and saturations. The code (written in object-oriented Postscript) that implements this color wheel is shown in Listing Two (page 94). The hue varies smoothly around the color wheel with direction, and the saturation varies smoothly with distance, with pure colors in the center fading to gray around the edge. Outside the pale perimeter is a continuous band of grays from white to black, that looks like the shadow inside a paint can, and functions as a circular brightness dial. Dipping into this gray border sets the brightness of the whole wheel. You may select any shade of gray around the border, or move back into the paint can, to select a color at the current brightness. As you move around, the cursor shows the true color selected, and because the cursor is displayed even before the menu is popped up, you can mark ahead and select a color without popping up the menu!
Conclusion
Pie menus are easy to learn, fast to use, and provide a gestural style of interaction that suits both novices and experts. And this is one user interface that's on the house, so enjoy!
References
Card, Stuart. "User Perceptual Mechanisms in the Search of Computer Command Menus." Proceedings of the ACM (March, 1982).
Hopkins, D., J. Callahan, and M. Weiser. "Pies: Implementation, Evaluation, and Application of Circular Menus." University of Maryland Computer Science Department Technical Report, 1988.
Perlman, Gary. "Making the Right Choices with Menus." Interact '84, First IFIP International Conference on Human Computer Interaction, Amsterdam, 1984.
Shneiderman, Ben. Designing the User Interface. Reading, Mass.: Addison-Wesley, 1987.
Momenta's Command Compass A Pie Menu by any Other Name
One implementation of a pie menu was recently announced by Momenta Corporation, a Silicon Valley startup developing a "pentop" computer. (A "pentop" PC supports both keyboard and pen input.) The Momenta Computer is a dual-mode system that can run standard MS-DOS programs or programs written for the "Momenta Environment," a Smalltalk/V-based environment that supports the pen. Central to the Momenta Environment is a system-wide pie menu the company refers to as the "Command Compass."
The Command Compass operates consistently across all Momenta Environment applications (notepad, spreadsheet, sketchpad, and so on) by allowing users to manipulate (move, copy, cut, paste, and so on) text or graphical objects that have previously been defined. Some operations can therefore be performed in a single stroke. As Figure 1 illustrates, for instance, you can quickly move a block of text by defining it, calling up the Command Compass, moving the stylus through the "move" wedge and on to the "move-to" position, and releasing the pen.
The figure shows that Momenta's menus are a visually faithful implementation of pie menus as described in this article. If Momenta succeeds in its endeavor, pie menus will join pull-down and linear menus as mainstream user-interface components.
--editors
_THE DESIGN AND IMPLEMENTATION OF PIE MENUS_ by Don Hopkins[LISTING ONE]
<a name="027c_0011">
% Code to implement the "8 Days a Week" Pie Menu
% by Don Hopkins
/pie framebuffer /new ClassPieMenu send def
[ (Today)
(Sunday)
(Monday) (Tuesday) (Wednesday) (Thursday) (Friday)
(Saturday)
] /setitemlist pie send
90 /setinitialangle pie send
false /setclockwise pie send
/can framebuffer /new ClassPieMenuCanvas send def
pie /setpiemenu can send
/minsize {100 100} /installmethod can send
/win can framebuffer /new ClassBaseWindow send def
/new ClassEventMgr send /activate win send
/place win send /map win send
<a name="027c_0012">
<a name="027c_0013">[LISTING TWO]<a name="027c_0013">
/Layout { % - => -
PieGSave self setcanvas
/LayoutInit self send
/LayoutValidateItems self send
/LayoutItemRadius self send
/LayoutOuterRadius self send
grestore
} def
/LayoutInit { % - => -
% Deflate the menu.
/Radius 0 def
% Figure the slice width.
/SliceWidth 360 /itemcount self send 1 max div def
% Point the initial slice in the initial angle.
/ThisAngle InitialAngle store
} def
/LayoutValidateItems { % - => -
% Loop through the items, validating each one.
ItemList {
begin % item
% Measure the item.
/DisplayItem load DisplayItemSize
/ItemHeight exch def
/ItemWidth exch def
% Remember the angle and the direction.
/Angle ThisAngle def
/DX Angle cos def
/DY Angle sin def
% Figure the offset from the tip of the inner radius
% spoke to the lower left item corner, according to
% the direction of the item.
%
% Items at the very top (bottom) are centered on their
% bottom (top) edge. Items to the left (right) are
% centered on their right (left) edge.
%
DX abs .05 lt { % tippy top or bippy bottom
% Offset to the North or South edge of the item.
/XOffset ItemWidth -.5 mul def
/YOffset
DY 0 lt {ItemHeight neg} {0} ifelse
def
} { % left or right
% Offset to the East or West edge of the item.
/XOffset
DX 0 lt {ItemWidth neg} {0} ifelse
def
/YOffset ItemHeight -.5 mul def
} ifelse
% Twist around to the next item.
/ThisAngle
ThisAngle SliceWidth
Clockwise? {sub} {add} ifelse
NormalAngle
store
end % item
} forall
} def
/LayoutItemRadius { % - => -
% Figure the inner item radius, at least enough to prevent
% the items from overlapping.
/ItemRadius RadiusMin def
/itemcount self send 3 gt { % No sweat if 3 or less.
% Check each item against its next neighbor.
0 1 /itemcount self send 1 sub {
/I exch def
/NextI I 1 add /itemcount self send mod def
% See if these two items overlap.
% If they do, keep pushing the item radius out
% by RadiusStep until they don't.
{ I /CalcRect self send
NextI /CalcRect self send
rectsoverlap not {exit} if % They don't overlap!
% They overlap. Push them out a notch and try again.
/ItemRadius ItemRadius RadiusStep add def
} loop
} for
% Now that we've gone around once checking each pair,
% none of them overlap any more!
} if
% Add in some more space to be nice.
/ItemRadius ItemRadius RadiusExtra add def
} def
/LayoutOuterRadius { % - => -
% Now we need to calculate the outer radius, based on the radius
% of the farthest item corner. During the loop, Radius actually
% holds the square of the radius, since we're comparing it against
% squared item corner radii anyway.
/Radius ItemRadius dup mul def
ItemList {
begin % item
% Remember the location to center the item edge.
/x DX ItemRadius mul def
/y DY ItemRadius mul def
% Remember the location of the item's SouthWest corner.
/ItemX x XOffset add round def
/ItemY y YOffset add round def
% Figure the distance of the item's farthest corner.
% This is easy 'cause we can fold all the items into
% the NorthEast quadrant and get the same result.
DX abs .05 lt { % tippy top or bippy bottom
% (|x|,|y|) is South edge: radius^2 of NorthEast corner
x abs ItemWidth .5 mul add dup mul
y abs ItemHeight add dup mul add
} { % left or right
% (|x|,|y|) is West edge: radius^2 of NorthEast corner
x abs ItemWidth add dup mul
y abs ItemHeight .5 mul add dup mul add
} ifelse
% Remember the maximum corner radius seen so far.
Radius max /Radius exch store
end % item
} forall
% Take the square root and add some extra space.
/Radius
Radius sqrt Gap add Border add ceiling cvi
store % Whew, we're done! Time to party!
} def
Copyright © 1991, Dr. Dobb's Journal
