andreas@sigi.Colorado.EDU (Andreas C. Lemke) (03/28/88)
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.
My idea is that they look something like this:
-----------------
| \item1/ |
| \ / |
|item6 \ / item2|
|-------*-------|
|item5 / \ item3|
| / \ |
| /item4\ |
-----------------
Do pie menus exist? On which system? How are labels arranged? Are
they really better than linear menus? Is it more difficult (slower) for a
*novice* to find an item in such a circular arrangement?
--
..................
... andreas ..:-).
..................bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (03/28/88)
In article <5104@sigi.Colorado.EDU> andreas@sigi.Colorado.EDU (Andreas C. Lemke) writes: >Do pie menus exist? On which system? Yes, on NeWS 1.0, and possibly by now on NeWS 1.1, though I haven't seen them running there yet or heard news of the update being available. Talk to their author, Don Hopkins (don@brillig.umd.edu), who is also NeWS-makers-request. They're quite nifty, indeed. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@cis.ohio-state.edu or ...!cbosgd!osu-cis!bob
klee@daisy.UUCP (Ken Lee) (03/28/88)
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. I seem to remember Apple doing some research into pie menus. Unfortunately, I don't know if this was original and don't have any references. There is an implementation for NeWS. Off hand, I'd think that they'd take much more screen space than traditional popups, so any cognitive advantage would be a trade-off. Ken -- What's the difference between a used car salesman and a computer salesman? The used car salesman knows when he's lying.
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.)lrbartram@watcgl.waterloo.edu (lyn bartram) (03/29/88)
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. >Do pie menus exist? On which system? How are labels arranged? Are >they really better than linear menus? Is it more difficult (slower) for a >*novice* to find an item in such a circular arrangement? I have seen work done using pie menus and variations on such for a while. Ben Schneiderman of the University of Maryland has done work in this field. In our own lab at the University of Waterloo, several applications use hexagonal menus and pie menus - specifically paint programs and 3D modelling applications. From a designer's point of view, they facilitate the provision of nested menu levels: from the user's point of view, they provide a "relative" motor memory demand (direction of menu selection) rather than an "absolute" requirement (location of menu item on screen). This is asserted to have much less cognitive overload ( there are references for this assertion, but i don't have them on hand. )
lewisd@homxc.UUCP (David Lewis) (03/29/88)
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. > My idea is that they look something like this: > ----------------- > | \item1/ | > | \ / | > |item6 \ / item2| > |-------*-------| > |item5 / \ item3| > | / \ | > | /item4\ | > ----------------- > Do pie menus exist? On which system? How are labels arranged? Are > they really better than linear menus? Is it more difficult (slower) for a > *novice* to find an item in such a circular arrangement? > ... andreas ..:-). 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. I was planning to have the outside circular. 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. Problems that I am running into: 1) How to fit the label into the box. 2) How to deal with a menu containing a large number of items. 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. 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"
msc@canth.SGI.COM (Mark Callow) (04/01/88)
In article <8891@tut.cis.ohio-state.edu>, bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > In article <5104@sigi.Colorado.EDU> andreas@sigi.Colorado.EDU (Andreas C. Lemke) writes: > >Do pie menus exist? On which system? > > Yes, on NeWS 1.0, and possibly by now on NeWS 1.1, though I haven't The National Film Board of Canada has an RGBA paint program (whose name I can't remember) written by Terry Higgins that uses pie menus. Terry has put together a beautiful implementation of the idea. He did it before Don Hopkins too. Terry's pie menus are small. They use symbols instead of text. A power user can make a selection simply by making the gesture (pen down, slide in direction of selection, pen) with the bitpad stylus. The menu won't appear if the gesture is completely quickly. His RGBA Paint Program runs on a Silicon Graphics Iris and is very swell indeed. -- From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
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
mwm@mica.berkeley.edu (Mike (I'll think of something yet) Meyer) (10/28/89)
>> > > That's an implementation detail, then. On the Amiga, for instance, the >> > > menus don't go through the layers system: the screen is frozen while the >> > > menu is up, but because it's so fast the screen isn't frozen for very long. >> >> > Dubious advantage. >> >> Well, it's a tradeoff. The biggest overhead in windowing seems to be managing >> the clipping lists rather than actually copying bits around. For something >> that's guaranteed to be short duration (unless you replace your mouse buttons >> with toggle switches :->) it's an OK tradeoff. It's not really an implementation detail. The win on pie menus is that you can make most any selection without being able to see the menu. I've as yet to run into any rectangular menu system (other than pie menus done in a rectangle) of which this was true. The result of this is that the menu selections wind up in the motion domain, not the menu domain. I make a selection without seeing any menus, because I know which way to go (up is paste; right click up opens a window on violet.berkeley.edu, etc). After the selection is made, rendering the menu just annoys me (by flashing it on and then deleting it), and doesn't really tell me anything that completing the action would. If a pie menu system renders menus even if the selection has been made, it's got a major misfeature, if not an outright bug. It sounds like Don may have changed things so that it does the rendering anyway. This is dissapointing. <mike -- Es brillig war. Die schlichte Toven Mike Meyer Wirrten und wimmelten in Waben; mwm@berkeley.edu Und aller-mumsige Burggoven ucbvax!mwm Die mohmem Rath' ausgraben. mwm@ucbjade.BITNET
barnett@crdgw1.crd.ge.com (Bruce Barnett) (11/09/89)
In article <1989Oct28.053358.1517@agate.berkeley.edu>, mwm@mica (Mike (I'll think of something yet) Meyer) writes: >If a pie menu system renders menus even if the selection has been >made, it's got a major misfeature, if not an outright bug. It sounds >like Don may have changed things so that it does the rendering anyway. >This is dissapointing. To quote Don's paper on PSIBER Space: "When you mouse ahead through a pie menu selection quickly enough, the menu is not displayed, and the shape of a pac-man briefly flashes on the screen, with its mouth pointing in the direction of the selected menu item. This "mouse ahead display suppression" speeds up interaction considerably by avoiding unnecessary menu display, and makes it practically impossible for the casual observer to follow what is going on. The flashing pac-man effect gives you some computationally inexpensive feedback of the menu selection, and reas- sures observers that you are racking up lots of points." "This paper will be presented at the 1989 Usenix Monterey Graphics workshop." -- Bruce G. Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett