don@brillig.umd.edu (Don Hopkins) (03/28/88)
At the end of this message is a summary of the work-in-progress talk I
gave at the Summer Usenix conference in Phoenix. It was published in
the September/October 1987 issue of ";login:". (My address and phone
number have since changed.)
Jack Callahan and I will be presenting the paper "A Comparative
Analysis of Pie Menu Performance" (by Jack Callahan, Don Hopkins, Mark
Weiser, and Ben Shneiderman) at the CHI '88 conference, May 15-19 in
Washington D.C. The paper describes the experiment that Jack designed
and performed, comparing speed and error rate of pull down menus and
pie menus. (Pie menus won on both counts!)
At CHI '88 (the Conference on Human Factors in Computing Systems),
I'll be giving demonstrations of various types of pie menus,
implemented in object oriented PostScript under the NeWS window
system, during one of the scheduled demo sessions, and also at the
NeWS SIG on Thursday. (I'll send more info about that soon!)
One example menu I'll demonstrate is a two level font selection menu:
The first menu has names of font families in different directions.
(Times-Roman, Courier, Helvetica, etc...) You choose a font family by
moving the cursor into the corresponding wedge and clicking. A font
style submenu pops up:
Times-Roman
\ /
\ /
Bold ^ Italic
/ \
/ \
Bold-Italic
(The ^ is the cursor, which starts out in the menu center.)
Each font style submenu has the same layout, so you only have to
remember two orthogonal sets of directions.
You choose one of the font styles by moving the cursor into the
corresponding wedge. The cursor distance from the menu center
determines the font point size, so that the further out you move, the
bigger the point size you get.
As you move the cursor around the menu (browse), you see dynamic
feedback of the font, style, and point size you get by choosing that
part of the menu: You see the string "<n> point" in the wedge between
menu center and the label of the currently active slice, in the
appropriate font, style, and size.
For example, if you move to the left and up a bit, you'd see something
like:
Times-Roman
\ /
^ \ /
Bold 18 point Italic
/ \
/ \
Bold-Italic
(Of course, the above image barely conveys the actual look and feel of
the menus. ASCII character graphics can hardly do justice to
interaction techniques and images expressed in object oriented
PostScript (with extensions for input, mind you!). I'll post the
source code to my latest version of class PieMenu, as well as some
useful subclasses, to NeWS-makers (aka comp.windows.news) real soon!)
-Don
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Directional Selection is Easy as Pie Menus!
Don Hopkins
University of Maryland
Human Computer Interaction Lab
College Park, MD 20742
(301) 454-1517
Simple Simon popped a Pie Men-
u upon the screen;
With directional selection,
all is peachy keen!
The choices of a Pie Menu are positioned in a circle around the
cursor, instead of in a linear row or column. The choice regions are
shaped like the slices of a pie. The cursor begins in the center of
the menu, in an inactive region that makes no selection. The target
areas are all adjacent to the cursor, but in a different directions.
Cursor direction defines the choice. The distance from the menu
center to the cursor, because it's independent of the direction, may
serve to modify the choice. The further away from the Pie Menu center
the cursor is, the more precise the control of the selection is, as
the Pie slice widens with distance.
With familiar menus, choices can be made without even seeing the menu,
because it's the direction, not the distance, that's important.
"Mousing ahead" with Pie Menus is very easy and reliable. Experienced
users can make selections quickly enough that it is not actually
necessary to display the menu on the screen, if the mouse clicks that
would determine the selection are already in the input queue.
The circular arrangement of Pie Menu items is quite appropriate for
certain tasks, such as inputing hours, minutes, seconds, angles, and
directions. Choices may be placed in intuitive, mnemonic directions,
with opposite choices across from each other, orthogonal pairs at
right angles, and other appropriate arrangements.
Pie menus have been implemented for uwm, a window manager for
X-Windows version 10, for the SunView window system, and for NeWS,
Sun's extensible PostScript window system. Don Hopkins did the uwm
and NeWS implementations, and Mark Weiser did the SunView
implementation.
Jack Callahan has shown Pie Menus to be faster and more reliable than
linear menus, in a controlled experiment using subjects with little or
no mouse experience. Three types of eight-item menu task groupings
were used: Pie tasks (North, NE, East, etc...), linear tasks (First,
Second, Third, etc...), and unclassified tasks (Center, Bold, Italic,
etc...). Subjects were presented menus in both linear and Pie formats,
and told to make a certain selection from each. They were able to make
selections 15% faster, with fewer errors, for all three task
groupings, using Pie Menus. Ben Shneiderman gave advice on the design
of the experiment, and Don Hopkins implemented it in Forth and C,
on top of the X-Windows uwm.
The disadvantage of Pie Menus is that they generally take up more area
on the screen than linear menus. However, the extra area does
participate in the selection. The wedge-shaped choice regions do not
have to end at the edge of the menu window -- they may extend out to
the screen edge, so that the menu window only needs to be big enough
to hold the choice labels.
Proper handling of pop-up Pie Menus near the screen edge is important.
The menu should idealy be centered at the point where the cursor was
when the mouse button was pressed. If the menu must be moved a
certain amount from its ideal location, so that it fits entirely on
the screen, then the cursor should be "warped" by that same amount.
Pie Menus encompass most uses of linear menus, while introducing many
more, because of their extra dimension. They can be used with various
types of input devices, such as mice, touch pads, graphics tablets,
joysticks, light pens, arrow keypads, and eye motion sensors. They
provide a practical, intuitive, efficient way of making selections
that is quick and easy to learn. And best of all, they are not
proprietary, patented, or restricted in any way, so take a look and
feel free!
References:
Pies: Implementation, Evaluation, and Application of Circular Menus
By Don Hopkins, Jack Callahan, and Mark Weiser
(Paper in preparation. Draft available from authors.)
A Comparative Analysis of Pie Menu Performance
By Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman
(Paper in preparation. Draft available from authors.)don@brillig.umd.edu (Don Hopkins) (04/05/88)
In article <1727@homxc.UUCP> lewisd@homxc.UUCP (David Lewis) writes: >In article <5104@sigi.Colorado.EDU>, andreas@sigi.Colorado.EDU (Andreas C. Lemke) writes: >> I've heard of a (new) kind of menus in which items are arranged like a >> pie chart. The menu pops up with the mouse cursor in the center so >> that each item can be reached by moving the mouse in the corresponding >> direction. This supposedly improves performance for skilled users who >> know which item is where. Accessing an item in a regular vertical >> list menu requires more feedback from the eye to tell whether the >> correct item has been reached. >> ... >I've been thinking of writing one of these circular menus for X11R2 since >seeing a taped demonstration of one shown by Ben Schneiderman (of >"Designing the User Interface" fame) on some unspecified system; I think >it was an Apple II or Atari micro. Ben Shneiderman was kind enough to trust me with his camera for a week to make that video tape, which I showed at my talk at the 1987 Usenix Computer Graphics workshop in Cambridge, Massachusetts. The tape demonstrates three implementations of pie menus, running on a Sun 3/50 workstation: My first implementation, square pie menus hacked into the X10 "uwm" window manager; Mark Weiser's SunView pie menus, used in his wonderful game "SDI"; and finally my NeWS pie menus in round windows, written in NeWS's object oriented extended PostScript, as a subclass of LiteMenu. I'll be making a more up-to-date tape for CHI'88, soon. >I was planning to have the outside circular. You're going to have a hard time doing that with X11! Good luck! >There is a small dead spot in the center. Note that this >arrangement allows for two-item selection; for example, which pie >slice you are in could select color, and how far out from the center >you are in could select intensity; or the wedge selects the font and the >distance selects the type size. > Andreas, they exist, but I don't know of any commercial implementation. My implementation of pie menus for NeWS is free and in the public domain. I've just posted the source code for NeWS 1.1 pie menus to the NeWS-makers mailing list (comp.windows.news). (Make sure you get the bug fix I posted subsequently!) Because of the nature of NeWS, you don't have to change applications to use pie menus -- they use whatever is the DefaultMenu at the time they are started. So after you've loaded in piemenu.ps, you'll get pie menus everywhere! > Problems that I am running into: 1) How to fit the label into the box. If you don't confine menu labels to their wedge shaped sectors, the label layout problem is much simpler! You just need to ensure that none of the labels overlap, and that it's visually obvious which sector is associated with which label. The NeWS implementation calculates an inner label radius, inside of which it draws lines to delimit the sectors, and around the outside of which it justifies the labels. The round menu window's radius is just big enough to encompass all of the labels plus a border. Labels are positioned so that (respectively) the labels on the (left/right) side of the menu have their (right/left) edge vertically centered at points on the inner radius, and the very (top/bottom) labels are horizontally centered on their (bottom/top) edge. i.e.: +---B---+ R label L +---T---+ Labels on the (Right/Left/very Bottom/very Top) of the menu are positioned so that point (R/L/B/T) is on the inner radius, in the direction of the center of its sector. The inner label radius is calculated by starting with a minimum radius, and going around the menu checking to see of the bounding boxes of any two adjacent labels overlap. If they do, the radius is pushed out until they don't, and the loop is continued. Once you've checked each pair of neighbors, the inner radius will be big enough so that no labels will overlap. The outer menu window radius is then calculated by finding the distance of the furthest label outer corner from the menu center. >2) How to deal with a menu containing a large number of items. With both pie menus and linear menus, the fewer the items, the easier the menus are to use. With linear menus of many items, the cursor must move further on the average, but the target areas are the same size as with smaller menus. With pie menus of many items, the cursor must move the same distance, but the target areas are smaller. However, the user may trade off cursor movement for target size, by moving the cursor further out, to where the wedge shaped target regions are wider! The active regions can extend out beyond the edge of the menu window, all the way to the screen edge. It's good practice to group items into logically related submenus, to keep the number of items in the menu low. Pie menus work very well for nested menu selection, especially for experienced users. They have a nice kinesthetic feel, and make good use of muscle memory. You remember a path through a tree of nested menus as a series of directions, sort of like navigating from room to room in Zork. Since menu selection is defined by direction, and delimited by mouse clicks, you can rapidly mouse ahead through familiar menus, without having to look at the screen. It feels somewhat like shifting gears with a manual transmission. > Quite coincidentally, my group today interviewed a PhD in Human Factors, >and in discussion of user interaction styles this question came up. >She said that this sort of menu is useful only for certain situations: >where the labels are VERY short; where the labels are clearly attached >to something (example: a,b,c,d,e for a multiple-choice answer); or >for graphic use in choosing color or something similar. They'd >also be useful in a menu with icons. While a pie menu will generally take up more screen real estate than the same linear menu, I find that with the layout scheme described above, one or two word menu items work just fine. If you can plan your menus so that long lines are near the top or bottom of the menu, instead of to the left or right, their outer radius will tend to be smaller. Jack Callahan performed an experiment comparing the selection time and error rates of pie menus and linear menus. The menus had 8 items, and the subjects were novices without any mouse experience. Menu tasks were classified in three categories, by the type of their selection, as pie (N, NE, E...), linear (A, B, C...), and unclassified (Open, Copy, Delete...). Using pie menus, the subjects made selections faster, and with fewer errors, for all three task types. >They're also useful in situations >in which the menu is not ordered (as long as it fits the other requirements); >otherwise, the eye has trouble deciding which pie wedge to scan first. >-- >David B. Lewis {ihnp4,allegra,ulysses,rutgers!mtune}!homxc!lewisd >"New Jersey -- Landfill of Enchantment" There are certain types of task for which a pie menu's circular layout is especially appropriate. They're useful in situations with pairs of complementary menu items, which can be placed in opposite directions, and orthogonal pairs, which can be placed at right angles. As well as the obvious compass rose and clock face, there are other types of groupings that also work well. For example: Wednesday Tuesday \ / Thursday Monday > O < Friday Sunday / \ Saturday Today (I claim that this is an easy-to-remember menu, because it has 8 items [which is an all around symmetric, asthetically pleasing number], and the weekdays are in a natural left to right order. Plus it's always easy to choose today!) -Don