Pie Menu Timeline

Timeline of pie menu development by Don Hopkins.

** 1968–12–09: The Mother of All Demos

— Doug Engelbart (1968)

The Mother of All Demos, presented by Douglas Engelbart (1968)



Augmenting Human Intellect. A Conceptual Framework by Doug Engelbart.

Web site:

Discussions about Engelbart from Hacker News.


Valerie Landau interviewed by Martin Wasserman: Doug Engelbart’s advice to a young software developer.


A: I think — I wanted to say one thing that Doug told me many years
ago. And this is really for the software developers out there. Once,
this was in the 90’s. And I said, Doug, Doug, I’m just started to get
involved with software development, and we have this really cool tool
we’re working on. Do you have any advice, about … for a young
software developer. He looked at me and said:

“Yes. Make sure that whatever you do is very modular. Make everything
as module as possible. Because you know that some of your ideas are
going to endure, and some are not. The problem is you don’t know which
one will, and which one won’t. So you want to be able to separate the
pieces so that those pieces can carry on and move forward.”

Engelbart Explains Binary Text Input.

Douglas Engelbart explains to
co-inventor, Valerie Landau, and some blogger how binary can be used
for text input.


Engelbart: Think about if you took each finger, and wrote a one on
this one, a two on this one, a four on this one, and a sixteen on this
one. And every combination would lead clear up to sixty three.

And so writing here like this the alphabet: A… B… C… D. E. F. G,

Engelbart Using HandWriter.

Douglas Engelbart demonstrates early
prototype of The HandWriter with Valerie Landau.


Q: So whose ideas was the glove?

Engelbart: I invented actually a separate keyset with the five keys,
and her idea, you can make a glove to do that.

Q: And what’s the advantage of using a five key chording system?

Engelbart: Well, when you’re doing things with the mouse, you can be
in parallel, doing things that take character input.

And then the system we had, it actually gave you commands with
characters, too.

Like you had a D and a W, and it says, “you want to delete a word”,
and pick on which word, and click, it goes. M W would be move a word.

Click on this one, click on that one, that one could move over there.
Replace character, replace word, transpose words.

All those things you could do with your left hand giving commands, and
right hand doing it.

iChord: Clips from video of Eric Matsuno & Valerie Landau showing
their new iPhone app to Douglas Engelbart. To Douglas C Engelbart and
Bill English, and to Karen Engelbart, Roberta English and Mary
Coppernoll. Present in spirit but not in molecules were: Evan Schaffer
and Dr. Robert Stephenson.


So we’re going to be able to be configurable for whoever’s hand. […]
Go ahead and give it a try: so swiping it down puts it in the history,
and swiping it left takes the last …

Tap Wearable Keyboared and Mouse

I just ran across a new device called “Tap”, a wearable tap glove that
functions as both a bluetooth keyboard and mouse!

Web site:

** 1969: Wiseman’s PIXIE paper

PIXIE: A New Approach to Graphical Man-Machine Communication

Wiseman, N.E., Lemke, H.U. & Hiles, J.O. (1969) PIXIE: A New Approach to Graphical Man-Machine Communication, Proceedings of 1969 CAD Conference Southampton, IEEE Conference Publication 51, 463–471.

Contents of Page 466–467:

The control lightbuttons which are used frequently within a mode to carry out a sequence of operations. These buttons are displayed around the tracking cross and move about with it so that the user’s hand is always close to these buttons when he needs them. To avoid clustering a large number of control buttons around the tracking cross, it is arranged that only buttons for those actions which are legal at any given time are displayed and also that the user may select different sets of legal buttons by pointing at one of them (which acts as a sort of rotating switch for the rest).


Wiseman’s Notes on Radial Menus in PIXIE

Control lightbuttons:
These vary according to the command mode currently selected. In drawing mode they are:
S: Start to draw under horizontal-vertical constraints from the + position
L: Start to draw rubber band line at current + position
F: Finish drawing at the current + position
W, X, Y…: Select a symbol from the catalogue of defined symbols and attach to the drawing at the current + Position


History of Pie Menus


** 1984: Lynn Bartram at University of Waterloo

From: Lyn Bartram at watcgl
To: Don Hopkins
Date: 29 March 1988
Subject: Re: pie menus

Don Hopkins writes:

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.)

Two things:
 1. I’d like to get copies of both papers, please!

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.

2. In our lab we have been using pie menus since 1984. Currently,
 several applications make use of a variant of such, hexagonal
 menus. I agree with your stated disadvantage above, but there
 is an upside to it: the menu can be used not only for
 selection but also for manipulation of the selected object/tool.
 One example comes from one of our current Paint programs, which
 uses hexagonal menus. After selection of an option, the user
 also has to set the degree of that operation — ie, after the
 user selects “size” or “opacity” of a region, (s)he must
 determine how how much alteration is desired. A clearer example
 is that of colour attributes: “hue”, “saturation” and “value”
 have continual rather than binary values! Thus, when the user
 moves the cursor to any of these {leaves?options?slices?} on the
 menu, the {see above} highlights to indicate selection, and the
 user can then “stir” the cursor in a clockwise direction to
 increase or a counter-clockwise direction to decrease the attribute
 value. The nice thing about this is that it seems extremely
 intuitive: a “whole” operation conceptually rather than two
 discrete activities, all taking place on a menu. Thus menus can
 be used nicely for more than just the binary approach to
 “select/deselect”. At that point, screen real estate turns
 multifunctional and is probably less taxing on the user. (sorry,
 i tried but could not resist that pun! )

The choice of hexagonal menus was slightly arbitrary, as our
 Paint authors liked the “look” — one could, of course, have
 octagonal or other menus, but like pie menus, the problem then
 becomes one of how many choices go on a menu before it gets
 humongous? ( which is , of course, a whole other question. )


** 1986–02–21: Became an Honorary Weisarian

From: Mark Weiser
To: Don Hopkins, Marks-People
Date: 21 February 1986 at 05:54:25 CET
Subject: don

I’d like to add Don to the marks-people mailing list, as an honorary
weiserian. Ok?

** 1986–04–18: Contacted Mitch Bradley about his Sun FORTH system

To: Mitch Bradley at Sun
From: Don Hopkins
Subject: Forth for the Sun

Mike Gallaher tells me that you have a neat Forth system
you’ve written for the Sun that does studly things like frobbing the
ethernet board and other useful diagnostics.

It sounds like it could be very useful, and probably more gratifying
that I would care to publicly admit, being a high intensity Forth

I work for the University of Maryland Computer Science Department,
where we have piles and piles of Suns, and are expecting more.

MG said your Forth was on the Sun Users’ Group tape. I’ve been
prodding people who are supposed to be able to do something about
getting the tape, for months and months to no avail. (“It’s been
ordered” for as long as I’ve been prodding…)

The U of Md. is a member of the Sun Users Group, as far as I can tell.
I’m interested in becoming a member myself, if I can survive whatever
financial setback there may be and still keep eating regularly.

But what I’m most interested in is the Forth system. What can you tell
me about it? Is source available? Doesn’t it run standalone? How does
it deal with the Unix file system? Is there documentation? What’s
written for it, what are you planning on writing for it, and what
would you like to see written for it? And what other things are there
on the Sun Users’ Group tape that I could mention to others who are
not as into Forth as myself, to entice them into action?

Thanks a lot in advance …


** 1986–04–13: “Theta Menus” Idea

Came up with the idea of “Theta Menus” while discussing Emacs user
interface design with Mike Gallaher.

On April 13, 1986, Mike Gallaher and I were brainstorming about Emacs
and user interface design, and we came up with the following idea,
which seemed worth writing down and pursuing, and this is what I wrote
describing the idea:

Clicking some sequence, say, double-right, lays down a help
 diagram showing what each direction of the mouse does. Moving
 outside the diagram exits this mode and removes the diagram. While
 in that mode, single clicks on the mouse keys cycle through the
 menu when the cursor is in the neutral area. Clicking while cursor
 is in one of the item’s sectors selects that item.
menu is laid out so that all choices are initially equidistant
 from the cursor, so only direction is needed to choose one. The
 diagram stays as long as the button is held, while the cursor
 moves within it. The selection is indicated by the sector in which
 the cursor lies when the mouse button is released.
The output of the selection is the direction, perhaps
 — — — — — —
mouse menu for inputting numbers from circular scale (say, degrees).
time: press left to set hour hand, middle to set minute hand.

I described the idea to Mark Weiser, my undergraduate advisor at
the University of Maryland, and he encouraged me to write it up,
implement the idea, and empirically evaluate it.

** 1986–05–18: Email from Don Hopkins to Mark Weiser about Theta Menus

From: Don Hopkins
To: Mark Weiser
Subject: Theta Menus

Here are some preliminary notes and ideas…

Theta Menus

Menu selection is based on the angle between the mouse down
event and the mouse up event. The radius should not have any
bearing on which menu item is selected, and could even be used
as an argument to the item.

The advantage is that if the user is familiar with the menu,
no visual feedback is required to select an item. Just the
direction has to be known. There is no need to slow the mouse
down and “park” in in a small rectangle as with conventional
pull down menus. If the user is familiar with the menu, then
no visual attention at all is necessary. Thus you can be
looking at something in one window while traversing menus in
another. Pull down menus require that you move in the same
direction every time you choose them (thus discarding theta),
and depend on how far you move the mouse (depending on the
radius instead). With pull down menus, there is no advantage
to having fewer menu items, because you need just as precise
control to choose each item.

A mouse down event should pop up a menu of n items, such that
each item maps to a certain range of degrees, or sector, and
the sum of the sector widths is 360 degrees. It might be nice
to make some sectors wider than others, so that they are
easier to choose. There should be a way to specify where
around the circle the first one starts.

When the mouse down event happens, a menu, whose center is
where the event occurred, should pop up, showing sectors and
the item they select. As the mouse is subsequently moved
around, the item whose sector contains the angle between the
menu center and the current mouse location should be
highlighted. When the mouse up event happens, the current
highlighted item should be chosen.

There might be a safe zone around the menu center, of a
certain radius, in which no sectors are highlighted. If the
mouse up event happens here, no items are chosen. Mousing
down, then up without moving would simply show the menu
without choosing anything. Alternately, one of the other mouse
buttons could abort the selection. (The latter has the
advantage that no visual feedback is required.)

As the mouse is moved further away from the center of the
menu, the user has more precise control over which item is
selected, because when the radius is greater, motion has less
effect upon the radius.

Some items could be submenus, which would be overlaid, offset
in the direction of the item, by a certain radius. You could
then see the path you used to get to a menu. There could be a
way to take a step back to the previous menu, and make another
selection from it.


Choosing between n items, each item having a sector of 360/n degrees.

Setting the time of an analog clock. Use one button to set the
minute hand, and the other to set the hour hand. Move in the
direction you want it pointing.

Choosing from a color palette. The menu is a circle of colors.
Move in the direction of the color you want.

Answering yes or no questions. Up for yes, down for no.

Scrolling the screen. The radius could supply an argument for
how far to scroll. Compare to scroll bars: You do not have to
stop looking at what you’re scrolling to aim the mouse at a
scroll bar.

Choosing percentages. Right for 25%, down for 50%, etc.

Specifying a direction (and distance) to move in a game or

Incorporate audio feedback for the blind.

** 1986–05–19: Email from Mark Weiser to HCIL about Theta Menus

From: Mark Weiser
To: HCIL, Ben Shneiderman, Don Hopkins
Subject: Theta Menus

A student of mine is thinking of building circular popup menus
into the Sun window system. Here is his description of them.

Note particularly what happens if you follow a menu tree using
these menus — you get a shape on the screen which represents
the path you followed. Experts remember long paths by muscle
memory (“zig-zag-zig-zig-zag”) instead of symbolically

I don’t know of anything similar. Anyone else? Other comments?


** 1986–05–29: Email form Ben Shneiderman to HCIL about Theta Menus

From: Ben Shneiderman
To: HCIL, Don Hopkins, Mark Weiser

I finally got around to reading your preliminary ideas about
theta menus and like the idea very much. I do not know of
anything similar…you are on to something. You should build a
few and try them out as improvements to existing strategies,
then conduct an evaluation to get the data.

There are many potential refinements…e.g. the further you go
in the direction the bigger the effect.

I think popup circles will be esthetically pleasing.

Go to it and show it to me when you have one built.

Good luck…Ben

** 1986–06–01: X10 Theta Menus Prototype

X10 proof of concept theta menu test.
Written in C for the X10 window system.
Pops up and tracks a theta menu containing the items passed in as command line arguments.

The first X10 theta menu proof of concept prototype, written in C on a
Sun 3/160. Convinced Professor Mark Weiser that I should divert my
time from system administration to researching user interfaces.

Source code:

** 1986–06–21: X10 Theta Menu Window Manager

X10 Theta Menu Window Manager.
Based on X10 “uwm” window manager, for Sun Workstation.

Gesture Ahead
Display Pre-Emption
User Defined Menus
Window Management
Program Launching

Theta menu extension to X10 uwm “ultrix window manager”. There was no
toolkit for X10 at the time, so I extended the X10 “uwm” window
manager to implement theta menus as well as its normal pop up linear
menus. You could define your own trees of nested menus, and bind
them to window management commands, run programs, etc. You could
specify that any menu was linear or theta, and it supported nested
menus, mouse ahead, display suppression, and carefully addressed the
screen edge boundary condition and mouse warping problems (which is
tricky with an asynchronous protocol like X).

From: Don Hopkins
To: Mike Gallaher at UniPress
Date: 21 June 1986
Subject: [Re: does anybody know what the following are…]

I fixed gralm. It’s regrinding the host tables now. Theta menus are
now running under the X uwm window manager! Shortly I can send you a
tar file.

What I want to do now is make it so that you can specify that a menu
be pull-down or theta, with a variable you can set in your .uwmrc file
controlling the type of unspecified menus.

I added a variable called menutheta that you can specify in your
.uwmrc file that controls the size of the menu.

Also, at this point, it does trig, i.e. t = atan2(x, y), whenever you
move the mouse, normalizing it such that 0 <= t < 1, and multiplying
by the number of items to get the item number. I will fix this by
dividing the menu into 4 quadrants, and calculating the boundaries in
terms of quadrant and slope in that quadrant upon initializing the

Each item will have a quadrant and slope field for one of its edges,
and when you move the mouse, you just figure out its quadrant and
slope by looking at the signs of x and y, and dividing. Then you look
through the linked list of selections for the one it falls in.

This eliminates all the trig except for setting up the menu. What I
have already runs quite well on a sun-2, and roars on a Sun-3. I’ve
set up some useful menus and tried them out and they’re very easy to
use. Next step is making it smart about not overlapping item names.


X10 Theta Menu Window Manager

Demonstration of X10 Window Management Theta Menus implemented as an
extension to the “uwm” window manager, incorporating the Sun Forth
extension language. Research performed by Don Hopkins under the
direction of Mark Weiser. Programmed in Sun Forth implemented by Mitch
Bradley. Developed and demonstrated by Don Hopkins.


Methodology of Window Management

Web site:

X10 Pie Menu Window Manager Source Code

Source code:

** 1986–08–03: Heard about Gosling’s SunDew window system (later called NeWS).

SunDew: Yet Another Window Server?

This is short report on SunDew a prototype window system built by James
Gosling of Sun Microsystems. Monday, 23 June Scott Nettles and I attended
BASS, Bay Area Systems Seminar where Gosling talked about SunDew. This
document stems from my notes, conversations with Scott, and communications
with Gosling.


Mitch Bradley mentions SunDew

From: Mitch Bradley at Sun
To: Don Hopkins
Date: 28 July 1986
Subject: Storage allocator and stuff

Thanks for the code. I’ll try it out within the next few days as time permits.

You can stay with us for 2 or 3 nights if that would help. My wife and I have a spare bedroom in our house.

Gosling knows where my office is. I’m usually in from 9:30 or 10:00 onwards. My leaving time is rather variable.

I haven’t done much with X, because I’ve been doing some stuff with Gosling’s new PostScript-based window system, SunDew. You’ll see when you get here. X pales in comparison to SunDew.

I’d be happy for you to do any Forth interfaces that interest you. I haven’t been doing much with Forth/Unix stuff lately, because I’ve been working on the Atari ST Forth.


Methodology of Window Management: 5. SunDew — A Distributed and Extensible Window System, by James Gosling

SunDew is a distributed, extensible window system that is currently being developed at SUN. It has arisen out of an effort to step back and examine various window system issues without the usual product development constraints. It should really be viewed as speculative research into the right way to build a window system. We started out by looking at a number of window systems and clients of window systems, and came up with a set of goals. From those goals, and a little bit of inspiration, we came up with a design.


NeWS: The Network extensible Window System

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

  • used PostScript code instead of JavaScript for programming.
  • used PostScript graphics instead of DHTML and CSS for rendering.
  • used PostScript data instead of XML and JSON for data representation.


** 1986–09: “Pie Menus” Term

September 1986: Mitch Bradley at Sun suggested the name “Pie Menus” instead of “Theta Menus”.

** 1986–09: PostScript Pretty Pie Menu Printer for LaserWriter

PostScript Pretty Pie Menu Printer for LaserWriter

Wrote PostScript code to print pie menus on an Apple LaserWriter.
After implementing ugly pie menus in X10, I experimented with many
different graphical styles, using PostScript. But all I had was the
Apple LaserWriter in the terminal room. I wrote my own object
oriented system using nested dictionaries to represent nested two
dimensional pie menus, with multiple rings of graphical items. This
foreshadowed my work programming NeWS, with Owen Densmore’s object
oriented PostScript system. By the time I read Owen’s Usenet
Graphics Conference paper, with its one page listing of class.ps, I
had already been working on the same problem myself on the
LaserWriter to print nested graphics with inherited characteristics,
so I was quite excited to get NeWS and make interactive pie menus on
the screen instead of drawing them on paper.

TODO: illustrations

** 1986–09: “fuwm” FORTH programmable X10 pie menu window manager.

September 1986: Developed a FORTH pie menu window manager for X10 on Sun Workstation.

Based on X10 “piewm” and Mitch Bradley’s Forthmacs 68k FORTH system.
FORTH Scripting
Tossing and Bouncing Windows

** 1986–10–15: Jack Callahan decides to perform pie menu experiment.

From: Mark Weiser
To: Jack Callahan, Don Hopkins
Date: 15 October 1986
Subject: pie menus experiments

Jack, I am glad you decided to do a pi menu experiment. I did not
read your experimental protocol carefully, but I think it is basically
good. I will read it again tomorrow. Experiments are necessary
to establish the efficacy of pi menus. If you get your data in time
we, you, Don, and I, will have a super pi menu paper.

** 1986–11: Programmed Pie Menu Experiment in FORTH with X10 pie menu window manager.

Used the FORTH pie menu window manager to administer experiments for CHI’88 pie menu paper.

Pie Menu Experiment

Demo of the experiment performed by Jack Callahan to evaluate the
effectiveness of pie menus versus linear menus. Research performed by
Jack Callahan under the direction of Ben Shneiderman, and Don Hopkins
under the direction of Mark Weiser. Programmed in Sun Forth
implemented by Mitch Bradley. Developed and demonstrated by Don



I made my first multithreaded programmable pie menu window manager,
by breaking open the inner loop of the C window manager, linking it
into Mitch Bradley’s great 68000 Sun Forth, and writing code in
Forth that could create and pop up menus, track the mouse, and call
into and delegate events to the uwm code.

We used it to administer, time, and record statistics for the
experiment we did, comparing pie menus and linear menus. At one
point, I wrote code that would let you throw a window and it would
bounce around the screen, by starting a Forth thread that pushed it
around. You could have a whole bunch of windows bouncing around the
screen and frantically repainting at once! I can’t believe how well
it performed on a little Sun 3/160, compared to how slow and bloated
computers are today.

This multitasking Forth programmable window manager foreshadowed my
work with NeWS, a window manager programmable in multithreaded
PostScript, another stack based language. Mike Gallaher and I went
to visit Sun, and I read the Red PostScript book on the plane. I met
the likes of Gilmore, Gosling, Rosenthal, Densmore, and Bradley (who
later hired me as a summer intern), and finally saw and promptly
crashed my first NeWS server (then called SunDew).

Source code:

** 1986–11–18: The experiment begins!

Email about the design and execution of the pie menu experiment.


Jack Callahan’s analysis software and data.


** 1986–12–02: Found Wiseman PIXIE reference

From: Don Hopkins
To: Don Hopkins
Date: 2 December 1986
Subject: reference

Principles of Interactive Computer Graphics

Wiseman, N. E., H. U. Lemke, and J. O. Hiles: “PIXIE: A New Approach
to Graphical Man-Machine Communication,” Proc. 1969 CAD Conf.,
Southampton, IEE Confm. Pub. 51, p. 463.

** 1987–01–13: Pie Menu Tracking Design

Notes on pie menu tracking.


dmu -vs- dumdu

From: Don Hopkins
To: Mark Weiser, Mike Gallaher at UniPress
Subject: Remember that strange idea I was trying to find words for

…of being able to choose from a pie menu in either of two ways:

a) click down, move, click up
b) click down, click up, move, click down, click up

After realizing that stroking and sticky menus probably would not go over very well, I came up with:

a) dmu selection
b) dumdu selection

…You can even pronounce them while you’re doing them, sustaining the mmmmm for as long as you’re moving. Here’s how I’d pronounce them:

a) [click down] d [move] mmmmmmmmm [click up] uh
b) [click down] d [click up] uh [move] mmmmmmmmm [click down] d [click up] uh

Both techniques are perfectly compatible with each other, and you can even interchanging between the two freely when traversing nested menus.

And of course, dudu means no selection.

** 1987–01–23: Mark Weiser’s Pie Menu in his “SDI” game for SunView on Sun Workstation

Email about Mark Weiser’s SDI game with pie menus.


Pie Menus in SDI by Mark Weiser

Demonstration of Mark Weiser’s Pie Menus implementation for his
classic game SDI for SunView, written while snowed in at home in 1987.


While snowed in with his Sun workstation at home during January
1987, Mark Weiser implemented pie menus for Sunview. He used the
Sunview pie menus for his classic “SDI” game.


From: Mark Weiser
To: Don Hopkins
Date: Friday, 23 Jan 1987
Subject: pies in sunview

I used the snow to hack pies into sunview. It works now without
walking menus. Will have walking over the weekend.


** 1987–02–05: Shneiderman Tells Apple about Pie Menus

From: Ben Shneiderman
To: Jack Callahan, Don Hopkins, Mark Weiser
Date: 5 February 1987
Subject: apple

Well I had a good time out at Apple telling them about Pie a la Modeless menus and suggesting Apple Pie menus, as part of my talk on direct manipulation user interfaces. Thre were quite a few questions about pie menus, but general approval of the idea, although they deal with pull down rather than popup menus.

They are an interesting bunch of people and are planning some intriguing products.

I hope the experiment paper can be ready for submission next week. I propose the International Journal of Man-Machine Studies (I am an editor, and hope that I can push for a prompt review). What do you guys think?

— Ben

** 1987–02–10: Mark Talked to University of Maryland Patent People

From: Mark Weiser
To: Don Hopkins
Date: 10 February 1987
Subject: patent on pies

I talked to the University patent people, and they are very excited about it.
They are sending me the ‘disclosure’ forms, and they would like a copy of
the apple patent as well. Would you ask Diane to make a couple?

** 1987–02–11: Mark Asked Me to Delay Sending an Abstract to Usenix Because of Patent Application

From: Mark Weiser
To: Don Hopkins
Date: 11 February 1987
Subject: abstract for usenix

Because of the patent application, you should probably NOT send the abstract to Usenix.

** 1987–03–31: Submitted Directional Selection abstract to Usenix Graphics Conference

I decided to send the abstract in regardless of the patent application.

Directional Selection is Easy as Pie Menus!


** 1987–04–24: Filled out Patent Disclosure Form

From: Mark Weiser
To: Don Hopkins
Date: 24 April 1987
Subject: patent policy

copy of the patent policy is on the pile of boxes inside my door.

** 1987–04–27: Sent Pie Menu Paper to CACM

From: Mark Weiser
To: Jack Callahan, Don Hopkins
Date: 27 April 1987
Subject: pie paper is out

The paper has been sent to CACM.

You will get copies of that version in your mailboxes.



** 1987–05: Decided not to Patent Pie Menus

After having a discussion with the University of Maryland Technology
Liaison Officer, I decided to publish papers, source code, and give
talks about pie menus, instead of patenting them.

Explanation: Patenting Pie Menus, in a Nut Shell

From: Don Hopkins
Date: 18 December 1990
Subject: patenting pie menus, in a nut shell

When I was at University of Maryland, I encountered the Office of
Technology Liaison, whose function it was to patent and bring
technology to market.

They approached me about patenting pie menus (menu selection based on
the direction of cursor movement), but I decided not to patent, and I
am glad I made that decision.

They were telling me not to publish or share the code, to keep a lid
on such a basic, simple, useful menu interaction technique, so that
they could investigate its patentability, attempt to patent it, and
ultimately restrict people from using it! The University would only pay
for the patent application if the lawyers decided it could be

There was a company in North Carolina that handled the marketing and
licensing of technology patented at the University of Maryland, and
the way things were set up, any profits from the invention would
*first* go to pay off the lawyer fees, and anything left is divided up
between the marketing company in NC, the office of technology liaison,
the department of the university sponsoring the research, and the

I had absolutely no say in the process, how the technology was
applied, whether its use would be restricted, who it would be licensed
to, how much it would cost, etc! In order for the patent to be
profitable, the NC company would license the technology to other

Those companies would pay for exclusive rights to the technology, and
in turn, those lawyers who are first in line for the profits would
have to actively seek out and prosecute people who were infringing on
the patent.

The natural recourse of the defendant in this case would be to
challenge the patent, and that means that the lawyers then have to
work even longer and harder defending the patent.

And if the defendant could show prior use, or argue that the
technology is un-patentable, then the patent is worthless, everyone’s
wasted lots of money, and nobody wins but the lawyers.


From: Don Hopkins
Date: 19 December 1990
Subject: patenting pie menus, in a nut shell

I’ve published a couple papers about pie menus, and have written some
unpublished ones that I mail to people. Enough time has elapsed since
publication, that the idea is no longer patentable, and I could
challenge anybody else’s pie menu patent. I have widely distributed
the unrestricted source code for NeWS pie menus, and programs (like a
window manager and a PostScript debugger) designed to take advantage
of them.

At CHI’90 I ran into somebody who told me he came up with a similar
idea a while ago, and wanted to implement it, but then he heard of the
work I had done with pie menus and decided not to pursue it because he
thought he might get sued. It was regrettable that he assumed the
worse, and didn’t know I intend for pie menus to be free. The
technological feeding frenzy that’s going on in the industry is even
discouraging the application of ideas that aren’t proprietary!


Pie Menu FUD and Misconceptions

Dispelling the fear, uncertainty, doubt and misconceptions about pie menus.


** 1987–05–29: Implemented first Pie Menus for NeWS

Late Night Hacking

From: Jack Callahan
To: Don Hopkins
Date: 29 May 1987
Subject: pies

I saw the circular pie menus under NeWS that you did last night. Nice. 
Very nice. Tell Mark.

— jack

Pie Menus for NeWS Lite Toolkit

PostScript Drawing
Round Menus
Window Management

NeWS pie menus, written in object oriented PostScript, with the Lite
toolkit. I designed, implemented, used, and re-implemented many
classes and subclasses of pie menus for NeWS 1.0, 1.1, SGI’s 4Sight,
and Grasshopper’s MacNeWS. I developed a nice efficient pie menu
based window manager, as well as “tab windows”, windows with tabs
sticking out of them, that you could use to easily pop up pie menus
and move and organize the windows. I worked on UniPress Emacs,
rewriting the NeWS display driver, and integrating pie menus and tab
windows into it, including an automatic menu compiler that
translated “hypertext” Info trees into corresponding trees of pie
menus bound to emacs commands. This was the first version of emacs
to support multiple windows, so the convenient tab windows and pie
menus helped a lot when you had lots of windows opened.

** 1987–06: How To Choose With Pie Menus

How To Choose with Pie Menus

Early pie menu demo by Don Hopkins, on NeWS 1.0, running on a Sun 3


** 1987–06: Pie Menu Demo: I Am A Robot

I Am A Robot

Early demo of self editing pie menus and text entry pie menus on a Sun
3/50 workstation running the NeWS 1.0 window system, by Don Hopkins.


** 1987–06–11: 1987 Summer Usenix Work In Progress Presentation

Date: Thu, 11 Jun 87
From: Don Hopkins
To: Mark Weiser
Subject: USENIX

I am here, typing on John Gilmore’s sexy little Kaypro. I gave a
talk on Pie Menus. They had Work in Progress sessions, and I had a
bunch of transparencies prepared. It went over very well. I
brought some tapes, and loaded my NeWS stuff onto the machines at
the Sun booth, and they were quite pleased to have the things to
demo. I will be posting the source to NeWS Pie Menus soon, on the
public domain, with no restrictions on distribution, so if the
Technology Liaison Officer is trying to get in touch with me, you
can tell him to get stuffed.


** 1987–08–05: Heard about Terry Higgins Pastel Graphics Editor with Pie Menus

From: Don Hopkins
To: Don Hopkins
Date: 4 August 1987
Subject: round menus

Terry Higgins
National Film Board of Canada

Demonstrated at SIGGRAPH’87.
Used pie menus.
Ran on SGI workstations.
Terry Higgens, National Film Board of Canada.

From: David Forsey at uwcgl
Organization: U. of Waterloo, Ontario
Newsgroups: comp.windows.misc
Date: 3 November 1989
Subject: Re: Help with double-click recognition.

>For people how haven’t seen them in action, Pie Menus allow you to
>select an action by moving the mouse to the proper up/down/left/right
>pie slice. You can select an item without waiting for the menu to appear,
>because you move in a direction that is consistent.
>If you move to a slice, and click again, you can go to the next menu
>before the first one appears. This can be nested so that you can click
>ahead several menus.

Just as a note, the “click-ahead” technique on radial selection menus was used by Terry Higgins at the National Film Board in Montreal. He demo’d production level cel-animation software with these menus at SIGGRAPH’87. I believe Don Hopkins was already working on his pies at that point, though had not yet published. Certainly Ben Shneiderman saw the menus, and talked with Terry at length at that time about the click-ahead scheme.

Once you use ’em, you never go back. Linear menus are just too much of a pain. I don’t even read the menu items any more — 80% of my selections are done through muscle memory, especially when using a scheme where you don’t have to click on a menu item to get to a sub-menu.

Clicking just slows you down, even with click-ahead.

Dave Forsey
Computer Graphics Laboratory
University of Waterloo.

** 1987–08–14: Submitted Usenix Work in Progress talk summary to :login;

Directional Selection is Easy as Pie Menus!

;login: Volume 12, Number 5, September/October 1987

By Don Hopkins
University of Maryland 
Heterogeneous Systems Laboratory 
College Park, MD 20742

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 Sun View 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 ideally 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!


“Pies: Implementation, Evaluation, and Application of Circular Menus,” By Don Hopkins, Jack Callahan, and Mark Weiser (Paper in preparation. Draft available from authors.)


** 1987–09–11: Vaughan Pratt Suggested How to Eliminate Divides During Tracking

I met Vaughan Pratt while I was visiting Sun, and discussed pie menus with him. He suggested a way to eliminate divides during tracking. It’s not an important optimization these days, when we can call atan2, but at the time it was important to optimize mouse tracking code, and floating point division was much more expensive than multiplication.


Vaughn Pratt suggested an improvement to my quadrant-slope
algorithm for pie menu tracking, which eliminates the division
done every time the mouse moves during cursor tracking. You can
eliminate the divide used to calculate the cursor slope, by
multiplying both sides of the slope comparison by the denominator
of the cursor slope. i.e. as before, do the divisions to calculate
the slopes of the slice edges when laying out the menu. But when
tracking the cursor, and comparing its slope with the slice edge
slopes, instead of dividing to get the cursor slope, and comparing
it with the slice edge slopes, you compare the numerator of the
cursor slope with the denominator of the cursor slope times the
slice edge slope.

I put the modification into uwm, and it works fine! I want to fix
the NeWS pie menus to use this scheme, because they’re using atan2
now, and they seem to feel “heavy” when things are going on.
Anyway, atan2 loses if you want to have different sized wedges.

** 1987–09–18: My First Taste of HyperCard

From: Don Hopkins
Subject: Hyper Card
Date: 18 September 1987
To: Owen Densmore at Sun, Robin Schaufler at Sun

Last weekend I went up to New Jersey and Mike Gallaher showed me Hyper
Card on the Macintosh. It’s a graphical version of Hypertext (as in
Xanadu), but using stacks of cards, which can share backgrounds, and
can have text and pictures and mouse sensitive regions on them. You
can write programs that change things on the card, switch to other
cards, run applications, and all kinds of other things. First chance I
get I’m buying a copy of it, so I can get to know it. Have you seen
this and played around with it? From what I saw, it looks like quite a
powerful way to organize and present information!


From: Owen Densmore at Sun
To: Don Hopkins
Date: 18 September 1987
Subject: Re: Hyper Card

Yes, I’ve seen it & think it’s very slick and an interesting way
to get users into programming on their systems. What also struck me
is how easy it would be to do the same thing in NeWS using PostScript
as the interaction language!

I’ve been interested in a programmable “Window Shell” that would work
like the C-shell, but with windows and their clients as elements in the
language. PostScript is clearly the language for the shell. Some
folks here have been working on a C++ NeWS client that transforms
*all* events to message sends. Once this has happened, applications
have defined a semantic interface to themselves that others can use
to drive them. See me about this next time you’re out here.


** 1987–10: Pie Menu Cookbook

Pie Menu Cookbook

Techniques for the Design of Circular Menus
By Don Hopkins, October, 1987.


** 1987–10–08: 4th Usenix Computer Graphics Workshop, Cambridge, Massachusetts, Oct. 1987

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.

** 1987–10–13: Discussed labeling pie menus with Tom Duff

From: Don Hopkins
To: Tom Duff at Bell Labs Research
Date: 13 October 1987
Subject: Labeling pie graphs is NP hard?

Were you the one who mentioned that someone has found labeling pie
graphs to be NP hard, during my pie menu talk at the Usenix Graphics
Workshop? If so, or if you know about it, I’d very much appreciate a
reference to this work, or a pointer to the person who did it. Thanks
a lot.


From: Tom Duff at Bell Labs Research
To: Don Hopkins
Date: 13 October 1987

Chris Van Wyk and one of his students did the work. I’ve only seen an
internal memorandum describing it, and it’s hard to believe that it’s

From: Tom Duff at Bell Labs Research
To: Don Hopkins
Date: 13 October 1987

I found the paper. It’s called `How hard can it be to draw a pie chart?’
by Diane L. Souvaine (Rutgers University) and Christopher J. Van Wyk

It shows that when the order of sectors is not fixed, the problem of
arranging a list of sectors of given size so that each contains a
horizontal line of given length is NP-hard.

From: Don Hopkins
To: Tom Duff at Bell Labs Research
Date: 17 October 1987

Great — thanks for the reference! I’ll get in touch with cvw.

I’ve been thinking about how to do more intelligent pie menu label placement, that minimizes menu size while keeping the labels from overlapping.

As the giant 360 item pie menu shown in my video tape demonstrated, positioning the labels around an inner radius that is a linear function of the number of labels can end up demanding more real estate than Jim Bakker shopping for amusement parks.

(Not that everybody shouldn’t have a screen big enough to display such menus!)

One thing I was thinking of experimenting with was “2 1/2 dimensional dynamics”, where labels are attracted to their places by springs, but are pushed away from each other when they overlap.

This could also be applied to speech balloons, used to annotate a picture.

There would be “uphill” regions of the picture that should not be covered up, and the balloons, which are anchored in place by rubber-band-like pointers, fight it out until none of them overlap.

I think it would be neat to use with graphical hypertext, and other things that need dynamically positioned popup windows that don’t obscure each other.

There’s a lot to be done with arbitrarily shaped windows! (Just leaf through a MAD Magazine!)-Don

** 1987–11–24: Pies Accepted at SIGCHI’88

From: Jack Callahan
To: Don Hopkins
Date: 24 November 1987
Subject: pies accepted at SIGCHI 88

— jack

** 1988–01–24: Joined HCIL to work on HyperTIES with Ben Shneiderman

From: Ben Shneiderman
To: Don Hopkins
Cc: Ben Shneiderman, Catherine Plaisant, William Weiland
Date: 24 January 1988
Subject: hi

Hello Don,

Have you gotten set up yet? I have several possible projects for you to think
about participating in:

1) work with Bill Weiland to make the browser and crude author tool on the SUN3. This seems the obvious place for you to go to work that effectively applies your knowledge, gets you involved in the Hyperties stuff, and produces a big and short term payoff.

2) develop a Hyperties to Postscript processor that take a Hyperties database and produces Postscript files to drive a laser printer to produce a book form of a Hyperties db. This should go from PC or SUN files.

3) tackle the design and implementation of an advanced browser on the SUN and PC … this sounds like a tougher and bigger project.

Let’s chat this week about these possibilities


** 1988–03: How to Choose with Pie Menus

How to Choose with Pie Menus

English 393, Technical Writing Assignment #1
Instructions for Performing a Process
Don Hopkins
March 10, 1988


** 1988–03–12: Send NeWS HyperTIES prototype to Martha Zimet at Sun

From: Don Hopkins
To: Martha Zimet at Sun
Date: 12 March 1988
Subject: NeWS HyperTies

Hi! I’d like to talk with you about what we’re doing with HyperTies
and NeWS — do you have some time for a phone call some time soon?
I’ve written a prototype display front-end in PostScript, that I’d
like to give you a copy of. Can you ftp files off of umd machines?
Spring break has just started, and I will have some time do get lots
of hacking in! I’d like to exchange some ideas so we can coordinate
our efforts. Feel free to call some time over the weekend if you


** 1988–03–20: Published Mousee on NeWS-Makers

Mousee Demo

Demo of Mousee running in the NeWS Window System. Research performed
under the direction of Mark Weiser and Ben Shneiderman. Developed and
demonstrated by Don Hopkins.


** 1988–03–30: Published work-in-progress talk summary on NeWS-makers.

From: Don Hopkins
To: NeWS-makers
Date: 30 March 1988
Subject: Re: pie menus

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:

          \       /
\ /
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


\ /
^ \ /
Bold 18 point 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!)


** 1988–04–09: Developed HyperTIES NeWS Front End in PostScript

From: Don Hopkins
To: William Weiland, Catherine Plaisant
Date: 9 April 1988
Subject: NeWS front end

I’ve implemented a window with space for a control panel at the bottom
and appropriate methods for handling it (no scroll bars), taught the
formatter about .startcontrols and .endcontrols, and made classes of
control buttons, so now you can describe the control panel as a
storyboard file. (This seems to me to be a good idea.) I’ve also given
the formatter a good working over, and it’s a lot nicer now. It will
not run off the bottom of the page any more. It makes sure there’s
room before putting anything down. It handles the line height
correctly now. (i.e. before, if you were in a tall font, then did a
newline, then switch to a short font, the new line would be as tall as
the font you were in at the start of the line, even though there are
no words in that font on the line. Now the line will only be as tall
as the tallest text or displayable actually drawn on it. It will put a
piece of text or graphics onto the next line if it won’t fit on the
current line, unless the cursor is at the beginning of the line (so no
unnecessary blank lines). It will put it on the next page if it won’t
fit on the current page, unless the cursor is at the top of the page
(so no unnecessary blank pages). While it’s laying out the stuff and
building the display list, it draws rectangles on the page to show
where it’s at. (i.e. the bounding box of the last line it completed)
When it finishes each page, it erase the rectangles and draws the
stuff it just layed down. It handles damage to the pages correctly
now, by repainting them, so it’s not necessary to retain the images of
obscured canvases. (They will be repainted from their display list
when exposed.) So it should run OK in color, but that still needs to
be tested. When you format a multi-page document, you see the first
page being layed out (rectangles), and when it’s done, it’s painted
and the touchables become active. At the same time, the rest of the
pages are being formatted underneath the first page on top. You can
flip through the pages and touch the touchables while the formatting
is going on. (No callbacks to the client can happen till it’s done
formatting, though.)

Do you want me to write a real storyboard parser? I’m still using
Forth right now.

Some more things I still need to do: Magic back and next buttons that
disappear when they’re not applicable. Title and page number in the
frame label. The formatter should aggregate adjacent strings on a
line into one.


** 1988–04–10: Proposal to investigate interaction techniques and display styles appropriate for the application of pie menus to window management.

Technical Writing Class Assignment

Proposal to investigate interaction techniques and display 
 styles appropriate for the application of pie menus to
 window management.


To the members of my technical writing class. Including an extensive bibliography. Bibliography includes:

Wiseman, N. E., Lenke, H. V., & Hiles, J. O. (1969). PIXIE: A New
 Approach to Graphical Man-Machine Communication. In
 Proceedings of the 1969 CAD Conference, Southampton IEEE
 Conference Publication 51, pp. 463.

** 1988–04–19: Started implementing NeatWindow.

From: Don Hopkins
To: David Rosenthal at Sun
Date: 19 April 1988
Subject: Stateless window server?

I see… What I am interested in is making objects that can write
themselves into files to be loaded in again later. Objects that are
alive and editable in the server, that can freeze dry themselves to
disk. I’d also like to be able to write out “dumb,” un-editable,
lighter weight versions of an object, too, i.e. just a raster image,
instead of all the data that generated the display.

I am working on a paper for my technical writing class, about applying
pie menus to window management. I’ve implemented a prototype class
NeatWindow, with a FrameMenu that demonstrates certain pie menuances.

I’d be glad to send you the code to try out if you’d like! Something
I’m supposed to do for my technical writing class is to interview
someone about my research, so if you’ve got some time, I’d really like
to talk with you about their design.


** 1988–05–04: Developed NeWS HyperTIES Browser Formatter with FORTH Markup Language Interpreter.

HyperTIES Browser
 Following Links
 Showing Definitions
 Flipping Pages
 User Defined Menus
 Font Selection
 Embedded Graphical Menus

HyperTIES Architecture Diagram

HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. This diagram shows the architecture of the HyperTIES authoring tool (built with UniPress’s Gosling Emacs text editor, written in MockLisp) and browser (built with the NeWS window system, written in PostScript, C and Forth). The tabbed windows and pie menu reusable components were developed by Don Hopkins, who also developed the NeWS Emacs (NeMACS) and HyperTIES user interfaces.



From: Don Hopkins
To: Martha Zimet at Sun
Date: 4 May 1988
Subject: NeWS HyperTIES

NeWS HyperTIES is coming along really well! The NeWS front end
consists of a bunch of PostScript Objects: a special Window class with
a control panel, a definition window, and a stack of pages, Disp
objects that compile display lists, various kinds of Touchable target
objects, and a bit of glue to stick it all together. There is a CPS
interface to the front end, and a formatter written in C, which uses
that interface. I’ve written a prototype storyboard compiler in
Forth, that drives the formatter. Right now it’s using a prototype
index manager, but I’m just about to plug in the real index manager.
Once I get that working, I’m going to feed it the Space Telescope
demo, then I should have something coherent and useful that I can send
you. I just glued Steve Isaac’s text canvas to an item, and plugged it
right in, so now you can have scrolling selectable text in a
storyboard! (As well as scroll bars, sliders, spinning earths, and
other items!) NeWS is **FUN**!!!

How do you like the pie menu window manager? Can you use it without
looking yet? I’ll send you the paper about it as soon as it’s
finished. (It’s for my Technical Writing class.)


From: Heather Rose at Sun
To: Don Hopkins
Date: 6 January 1989
Subject: NeWS HyperTIES


You mentioned your HyperTIES database used to store code, bug fixes, author
 information, etc. How do you like it? Is it easy to use? Can you find
 things/add things easily? How do you think it compares to other databases,
 most notoriously SQL based or an expert-system?


From: Don Hopkins
To: Heather Rose at Sun
Date: 26 January 1989
Subject: NeWS HyperTIES

The HyperTIES database mechanism is pretty simple: You give it a key
(the title or synonym of an article), and it returns a file (and an
offset in some cases). Each article can have a list of synonyms. The
key matching is case insensitive, and any number of white spaces will
match. The database mechanism is the subject of ongoing research. We
could plug in other database mechanisms (like NSE), and put some
smarts into it (like lookup based on the path you’ve followed, etc…)
The stuff in the database is text, using a simple markup language.
There are also auxiliary files describing pictures and targets,
containing a class, a name, and class-specific data (i.e. PostScript
code in most cases). The HyperTIES interpreter reads in the text of a
storyboard file (the textual description of a HyperTIES article) and
invokes the formatter to display it on the screen. The author makes
the storyboard in an ordinary text editor, and puts ~tildes~ around
words that are ~links~ (like so). The text between the tildes names
the title or synonym of another article. So it’s very easy to make
links. Each storyboard has fields giving the article’s title,
synonyms, definition, and contents. The definition and contents
fields can have commands in them that change the formatting
characteristics (font, style, size, margins, etc) [i.e. .font courier
.size 23 .left-margin 20], put down pictures [i.e. .picture Founders],
overlay special embedded menu targets on top of the pictures [i.e.
.target <Bill Joy’s Head> <Bill Joy>], and other stuff. There are
special targets that can perform magic when you click on them (execute
arbitrary PostScript code, fork unix processes, stuff commands into
the HyperTIES interpreter, etc.) Normal targets display the definition
of what they refer to the first time you click them, and bring you to
that article on the second click. (The definitions are nice to be able
to look at if you don’t know where a link leads, and want to know what
it is before following it. Articles can also just have definitions,
and no contents.) The markup language supports macros, so you can
build your own special formatting commands for your particular

If you’ll be at Usenix in San Diego, I’ll be glad to show you
HyperTIES first hand! (I’ll be staying with John Gilmore, so you can
leave a message with him at the hotel.) Otherwise, Magi Bollock
(magi@sun.com) has a copy of a prototype version of HyperTIES, that
you can ask her to see. (The prototype interpreter is written in
Forth (Mitch Bradley’s Sun Forth — he’s Sun’s resident Forth guru [I
worked with him summer before last!]). Now it’s written in C, and the
markup language is much more syntactically pleasing (though not as
drastically extensible!).

We’re still developing NeWS HyperTIES. We’re waiting for the delivery
of a Sun-4/110C that Sun donated to us almost 3/4 of a year ago…
It’s hard to get much work done in NeWS on a 3/50!


** 1988–05–11: Published NeatWin Pie Menu Window Manager on NeWS-makers.

NeatWin Pie Menu Window Manager for NeWS Lite Toolkit

From: Don Hopkins
To: NeWS-Makers
Date: Wed, 11 May 1988
Subject: class NeatWindow

Here is a window class with window management menus designed to
work well with pie menus. You should of course have piemenu.ps
loaded up before running this. Just psh it into your environment,
and the DefaultWindow will be set up so that the next window you
get will be a NeatWindow! Fire up a clock or something, pop up the
frame menu, and play around! I am not including any instructions
right now, because I would like to hear what you think of it after
trying to figure out what the menus do on your own. (heh heh heh
 — the code is free but you gotta be a guinea pig!) This is
experimental, so I’ll be coming out with a more refined version
later. If you’d care to answer the following questions after
playing around with the NeatWindow menus, I’d really appreciate

- Which functions were obvious by their direction, or their

- How would you change the labels to make their meanings clearer?

- Why do you think the selections are arranged the way they are?

- What mnemonic tricks can you think of to remember the selection

- After using them for a while, which selections do you find
 yourself mousing into without looking at the menu?



** 1988–05–14: Presented CHI ’88 Pie Menu Paper

An Empirical Comparison of Pie vs. Linear Menus

Jack Callahan, Don Hopkins, Mark Weiser (*) and Ben Shneiderman.
Computer Science Department University of Maryland College Park, Maryland 20742
(*) Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303.
Presented at ACM CHI’88 Conference, Washington DC, 1988.


** 1988–05–24: Asked Tony Hoeber at Sun about Pie Menus for OPEN LOOK.

From: Don Hopkins
To: Tony Hoeber at Sun
Date: 24 May 1988
Subject: Open Look

Hi! That was a very interesting demo of Open Look you gave at CHI’88!
I had wanted to chat with you a lot more than I got a chance to…
Neal Groundwater at Sun DC pointed me at your email address. Can you
tell me where to sign up to get the scoop on Open Look? I’d love to
see whatever drafts and documentation are available! I’m interested in
discussing how pie menus could be incorporated into Open Look. What
kinds of comments would you be interested in hearing? I’ve just
finished writing a paper about pie menu design, that I can send you.
I can also send you another couple of papers about the subject, some
screen dumps, and/or the source to pie menus for NeWS. I’ll be out
there for Usenix in a couple of weeks, so maybe we can get together
then. I will bring a tape of neat window system stuff with me. Hope to
hear from you soon!


From: Don Hopkins
To: Karen Lusardi at Sun
Date: 2 June 1988
Subject: OPEN LOOK specs

Hi! I’ve been in touch with Tony Hoeber, who told me that you’re the
person who can give me the scoop on OPEN LOOK. I’d love to get a copy
of the specs, whenever they come out.

I’m interested in incorporating pie menus into OPEN LOOK. Pie menus
are circular menus, whose selection regions are shaped like the slices
of a pie. Jack Callahan and I presented a paper at CHI ’88, describing
an experiment comparing them with traditional linear menus. We have
shown them to be faster and more accurate than linear menus, because
of the decreased cursor motion and increased target size. Every
selection is adjacent to the cursor (which starts out in an inactive
region in the menu center), but in a different direction, and the
wedge shaped selection regions are wider, further away from the menu
center! I’ve been researching the subject, and I’ve implemented pie
menus for NeWS, in object oriented PostScript. I’ve written a couple
of papers on the subject, that I can give you copies of if you’d like.

I just sent the PostScript code for NeWS pie menus, and a paper about
pie menu design, to Tony Hoeber, so that he can take a look and feel
free! I’ll be out in your area for Usenix in a couple of weeks, and
I’ll be visiting Sun some time during the following week of Usenix. If
you’re interested in getting copies of the papers or seeing a demo,
I’d be glad to schedule a visit.


** 1988–06–01: Jakob Nielsen CHI’88 Trip Report


Some new stuff was presented such as the pie menus studied by
Callahan, Hopkins, Weiser, and Shneiderman from the University of
Maryland. When used as pop-up menus, pies have the advantage that any
menu item can be selected by equally small movements of the mouse and
the study did indeed show that users performed about 15% faster using
a pie menu than using a linear menu. Pie menus also have some
potential disadvantages, especially when used with many menu items or
in cases that call for hierarchical pop-ups.

** 1988–08–02: HyperTIES Space Telescope Demo Runs

From: Don Hopkins
To: Brian Raymor at Sun
Date: 2 August 1988
Subject: HyperTIES

Thanks for referencing my work! I’m really glad I got the chance to
demonstrate it to you and Neal, and at SIGCHI too! (I just can’t
describe to you how exhilarating it was to have a Sun in the hotel
room! Just the thing for those times when hand waving just isn’t

HyperTIES has been coming along very well — it now run the the Space
Telescope demo, a hypertext database about the Hubble Space Telescope,
and we’re working on the documentation in hypertext. This summer, I’m
working at UniPress, on NeMACS — Emacs as a NeWS development
environment! I’ll be back for school at the end of August, and will be
working more with HyperTIES.

I got an “Experts Agree!” T-shirt on July 4th! I hardly got to use it
before the old man announced he was resigning! But if you scan in a
picture of that pig, I’d still love a copy of the bits!


** 1988–08–04: NCR Sponsors Like HyperTies

From: Jim King at NCR
To: Don Hopkins
Date: 4 August 1988
Subject: Hyperties, NeWS, images


How you doin’? Have evaluated Hyperties and made quite a few demo’s
of the system. People are quite impressed. I look forward to the UMD
team advancing further on some of the ideas we talked about.

What I need to know (if you have a free moment) is what is the process
to scan an image, transfer it to the SUN (format), and use what display
processes to get the image out on the screen? I used a DEST scanner,
scanned a page, saved in TIFF format, FTP’d it to the SUN, and tried to
display. It didn’t work. Should the file be in binary not ASCII (obviously
yes)? Should the file be in TIFF format for the SUN? What process do I use
to show the image (showimage under NeWS)? Can I use the bit-mapped editor on
the file once it is on the SUN? Can I colorize the image?

Thanks for any help.

Jim King

Hope the summer’s work is going well!

** 1988–06: Developed Emacs 2.20 with Pie Menus at UniPress Software

Worked with Mike Gallaher on the UniPress Emacs NeWS window system
interface. Rewrote the multi-window display driver for NeWS.
Implemented a popup menu interface, a menu compiler, a text selection
interface, tab windows, and pie menus, including custom font and color
selection pie menus. Ported the Emacs NeWS interface to the 4Sight
window system on the Silicon Graphics Iris 4D.

TODO: illustration

** 1988–08–21: Pie menus for 4Sight NeWS for SGI Workstation.

I wrote a special subclass of pie menus for the SGI 4Sight version
of NeWS, since 4Sight did not support popup windows with
“SaveBehind”, because it couldn’t read pixels back from the screen
efficiently. Instead, its own special SGI style NeWS menus popped up
in the hardware overlay plane! So I put the necessary hooks into the
core pie menu class, so I could write a subclass for the SGI that
popped them up in the overlay plane. The only problem was with the
rainbow color wheel pie menu, because you could only have black,
white, and one other color in the overlay. So I made a special
instance variable just to override the overlay behavior, which the
color wheel menu set, so it could pop up in the color framebuffer,
but still know enough about the overlay plane to punch a hole in the
overlay so the other menus did not appear to overlap it!

** 1988–08–21: Tabbed Windows for NeWS Lite Toolkit and Emacs

Pop up pie menus on tabs.

Originally implemented for multi-window UniPress Emacs.

Later factored them out into a general purpose window manager class that you could use around all NeWS windows.

% {4} 21-Aug-88 Don Hopkins (don) at pink
% Made TabEmacsWindow class.
% Made it work under 4Sight (SGI NeWS 1.1).
% Put in discrete transformations and truncations in the hopes of
% achieving true resolution independence and wiping out font turds
% forever. (Fat chance!)
% Added control panel support.

TODO: Illustration

** 1988–08–28: Published Pie Menus, Pull-Out Pies, NeatWin, and Pseudo-Scientific Visualizer on NeWS-makers.

From: Don Hopkins
To: NeWS-makers
Date: 28 August 1988
Subject: Fresh Pie Menu Source Code & The Pseudo-Scientific Visualizer

The following 5 files contain the PostScript source code that runs
under NeWS 1.1, and SGI’s 4Sight 1.1. It should work just fine with
Grasshopper’s MacNews, too.

If you are using a Sun or a Mac or anything else, use “psh” to load
the files piemenu.ps, pullout.ps, neatwin.ps, and visualize.ps, in
that order.

You only need sgipie.ps if you’re running 4Sight 1.1 on a Silicon
Graphics Iris. In that case, load the files piemenu.ps, sgipie.ps,
pullout.ps, neatwin.ps, and visualize.ps, in that order.

Here is a short description of the 5 files:

 A few bug fixes since last posting.
 Root no longer stops repainting after piemenu.ps is run from a menu.
 If /DontSetDefaultMenu is defined in systemdict, then loading
 piemenu.ps will not set DefaultMenu to PieMenu.

 Initial posting.
 A subclass of PieMenu that runs in the overlay plane of the
 SGI Iris 4D, under 4Sight version 1.1 (Silicon Graphic’s
 port of NeWS 1.1). Only load this if you’re running 4Sight.

 Initial posting.
 A subclass of PieMenu that uses cursor distance from the
 menu center to specify an argument to the menu selection.
 Each menu key has an array of possible arguments, from which
 the cursor distance selects the argument value. The values in
 the arrays are “Things” (cf. litemenu.ps & colordemo) that are
 painted in the menu center as feedback.

 A few bug fixes since last posting.
 Now shares one set of global frame menus between all windows.
 Hacked so “spin” won’t mess up the global frame menu.
 If DontSetDefaultWindow is defined in systemdict, then loading
 neatwin.ps will not set DefaultWindow to NeatWindow.

 A program for the Pseudo-Scientific Visualization of live
 PostScript data structures in the NeWS server. Demonstrates
 the use of class PulloutPieMenu. The Pseudo-Scientific
 Visualizer is the class browser for the other half of your

Feel free to redistribute any of this code! (And you can make as many
backup copies of it as you want, as long as you print out and burn any
old versions! :-)


** 1988–09: Published UniPress Emacs 2.20 with Pie Menus and Tabbed Windows (NeMACS)

UniPress Emacs for NeWS Lite Toolkit
Compiled Info trees into user defined pie menus
Record pie menu selections in macros
Font selection and color pull-out pie menus
Tabbed Windows

From: Don Hopkins
To: Robin Schaufler at Sun
Date: 9 September 1988

I am back in Maryland, and I will write up a position statement this
weekend! I’m forwarding your message to Jim Hendler, a professor here
who’s worked on a rapid prototyping system using Lisp, for TI. He
knows other people who could talk about rapid prototyping with Lisp,

Sorry about dropping out of sight for a while — I was working full
tilt to polish off NeMACS before I had to go back to school. There are
lots of neat window system features, which I could flame about for
days, that are actually solid and polished! Nobody will be complaining
that we were afraid to let them at the mouse and the keyboard! Here is
a stream of thought synopsis: A menu compiler, so people can describe
menus without touching PostScript or MLisp; menu keys sending
function key sequences, that can be described and rebound; a pull-out
color/brightness pie menu, that (if you’re on a color display) pops up
a pull-out saturation/hue color wheel pie menu; a whole set of
pull-out font style/size pie menus; text selection, with rubber banding in
the server; multiple (up to 256) emacs frames, using a class of “tab”
window with a title tab sticking out the right side, like a notebook or
phone directory — you can have a whole bunch of frames open and
overlapping so that you can see each one of the tabs, and just click
on a tab to bring the frame to the top; a prototype control panel
compiler, that creates scroll bars, buttons, and other items, and
puts them in the borders of emacs frames. It all runs on SGI 4Sight,
as well! UniPress will be sending a tape to Sun soon!

We are going to be using NeMACS to build authoring tools for
HyperTIES. (It’s funny how all these things seem to fit together so
well! Almost like they were meant to! ;-)

SUG is sending me to the SUG meeting in New Mexico, to talk about
NeWS! Any chance you’ll be there? It’s the Friday before the Balloon
Fiesta, and I’ll be staying the weekend looking for balloon rides!


From: Don Hopkins
To: NeWS-makers
Date: 13 January 1989
Subject: Menu description languages

Dan “yes that is my real name” Smith writes:

As long as I’m writing: I’d like to see menuing systems more like the
Info reader in Gnu Emacs — there are some situations where it makes
sense to have a menu item in two or more places; also, the users should
be able to redefine their menus. I’m not talking about specific systems,
just a general direction that I know I’d find more convenient to use.

I did something along those lines for the UniPress’s Emacs NeWS
interface (NeMACS). I wrote a menu compiler that lets you create
popup menus for NeWS by describing them in Emacs INFO nodes. Each 
node describes one menu. Each selection is specified by one line of text.
Submenus are represented as links to other INFO nodes. Menu selections
are pseudo-links that describe the action of a menu item. Actions
include things like calling a PostScript function, typing in a string,
calling an Emacs functions, popping up a message, etc. The menu
compiler translates the info nodes into PostScript code for NeWS, and
MLisp code that interfaces them to Emacs. The PostScript is loaded
into NeWS to define popup menus that run independantly in the window

The menu description language has the same syntax as INFO menus, so a
selection that invokes a submenu is also an INFO link to the node
describing that submenu, and a selection that invokes an action is
just a link to a fake node whose name is the action. The menu compiler
traverses the tree of nodes, so the tree of popup menus it creates
reflects the structure of the INFO nodes. Users can edit the info
nodes, and recompile and reload them on the fly to customize their
menus. They can make popup menus for NeWS and interface them to Emacs
without ever having to touch or even look at the PostScript and MLisp
code produced by the compiler.

I wrote it while I was working for UniPress on the Emacs NeWS
interface, last summer, and it comes with Emacs version 2.20. Yes,
it’s a supported commercial product, but no, this isn’t a commercial
for it. I’d certainly like to hear about other peoples’ experiences
with menu description languages.


** 1989–09: Developed HyperTies Authoring Tool with UniPress Emacs

HyperTies Authoring Tool
 UniPress Emacs
 Tabbed Windows

Designing to Facilitate Browsing: a Look Back at the HyperTIES Workstation Browser.

By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, and William Weiland.
Hypermedia, V3 #2, 1991


HCIL Demo — HyperTIES Browsing

Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the
University of Maryland Human Computer Interaction Lab.


Hypertext Research: The Development of HyperTIES


HCIL Demo — HyperTIES Authoring with UniPress Emacs on NeWS

Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins,
at the University of Maryland Human Computer Interaction Lab.



From: Don Hopkins
To: Ben Shneiderman, William Weiland, Marja-Riitta Koivunen, Catherine Plaisant, Rodrigo Botofogo
Date: 19 February 1989
Subject: HyperTIES authoring in Emacs

Last night, I put together a bit of MLisp code that lets you browse
HyperTIES databases in Emacs.

It displays each storyboard in a tab window, as fully editable text.

I wrote a storyboard editing mode, which is automatically invoked when
you visit a file ending with “.st0”, and knows about the syntax of the
markup language.

You just visit the master-index file, and emacs can look entries up in

You can click the mouse button on a ~link~ and it will pop up a new
frame (a tab window) editing the storyboard it points to.

It splits the frame into two subwindows, the top for the definition,
and the bottom for the article, and it displays the article’s title in
the tab sticking out to the right.

You can have lots and lots of authoring frames open at once, or
iconified, and when you click on a link to something already on the
screen, it opens up and the frame comes to the top.

There’s a command to create a new article, which sets up a prototype
storyboard in a new frame.

I’m planning on making commands for adding synonyms, and incrementally
updating the master-index file as you add new articles and synonyms.

It would be easy to write some general purpose storyboard authoring
tools that follow the links around and edit the storyboards

I plan to integrate this with the graphical authoring tools, as well.

And it’ll be very easy to create a menu driven interface for this
using the menu compiler I wrote last summer.


** 1988–09–30: Demonstrated NeWS Pie Menus, HyperTIES, NeMACS, etc at Sun User Group Southwest Regional Conference in Albuquerque

From: Don Hopkins
To: John Gage at Sun, Josh Siegel at LANL
Date: 14 September 1988
Subject: equipment

I will need a Sun-3 to run the HyperTIES browser (which uses Mitch
Bradley’s 68000 Forth system), a color display for UniPress NeMACS and
the Pseudo Scientific Visualizer, and as much real memory as possible
for NeWS. (It would be great if there were enough memory to be able to
load all this stuff in at once and run it without p-p-p-paging!) As
for disk space, HyperTIES takes up 3 meg or so, and a fully built
NeMACS with all the documentation and databases takes up 24 meg.

Here’s a manic stream-of-thought synopsis of some of the stuff I’ve
been working on, that I can demonstrate at SUG: (how soon do you need
a coherent synopsis?)

HyperTIES: a hypermedia browser that runs under NeWS. It displays
articles of formatted text and graphics with embedded menu button
targets, linking to other articles. Targets are overlaid on top of
words in the text and parts of pictures. They highlight when the mouse
moves into them. There are various forms of highlighting, such as
inverting, popup magnification, and animation. It can also layout
Items such as sliders, buttons, scroll bars, scrolling text canvases,
etc. I can show the Hubble Space Telescope database, with an annotated
diagram with popup links to exploded views of various subsystems, and
the demo database with the miscellaneous rabbit, scroll bar madness,
undulating earth, inflatable founder heads, etc.

NeMACS: Gosling Emacs firmly embedded in NeWS. A menu compiler, so
people can describe menus without touching PostScript or MLisp; menu
keys sending function key sequences, that can be described and
rebound; a pull-out color/brightness pie menu, that (if you’re on a
color display) pops up a pull-out saturation/hue color wheel pie menu;
a whole set of pull-out font style/size pie menus; text selection,
with rubber banding in the server; multiple (up to 256) emacs frames,
using a class of “tab” window with a title tab sticking out the right
side, like a notebook or phone directory — you can have a whole bunch
of frames open and overlapping so that you can see each one of the
tabs, and just click on a tab to bring the frame to the top; a
prototype control panel compiler, that creates scroll bars, buttons,
and other items, and puts them in the borders of emacs frames. Meat
and potatoes NeWS application with lots of chocolate syrup. Showcase
of NeWS ideology. Runs under SGI 4Sight, too!

The Pseudo Scientific Visualizer: NeWS data structure browser for the
other half of your brain. Floral recursion in pretty colors. Point and
click interface under development. Debugger interface imminent.
Definite fish oil material!

Will there be a time and a place to let people try out NeWS first hand
for themselves? After reading the reviews of Xposition, I want to
make sure not to create the impression that we’re afraid to let people
beat up on our software. This stuff really works!!

Oh yeah — how about a heavy duty mouse, too?! ;-)


From: Don Hopkins
To: Josh Siegel at LANL
Date: 29 September 1988
Subject: equipment

I’ve got to tear off to the airport! Here’s a short abstract. I will
see you soon!

Building User Interfaces in NeWS

Don Hopkins
 University of Maryland
 Human Computer Interaction Lab

The NeWS window system is a multitasking, interactive PostScript
programming environment. It’s a network based, extensible window
server. It’s also a whole lot of fun! PostScript is a high level,
device independent, industry standard page description language. 
NeWS has extensions to PostScript, that make it a powerful platform
for building window systems. NeWS uses an object oriented programming
package, providing a Smalltalk-like class mechanism. The 
user interface toolkit is a set of classes that can be easily
customized. NeWS has a modular look and feel.

HyperTIES is a hypermedia browser for the NeWS window system, under
development at the Human Computer Interaction Lab, at the University
of Maryland, that takes advantage of many of the unique features of

The UniPress Emacs text editor is a powerful NeWS programming
environment. It supports multiple frames, text selection, menus,
control panels, and many other window system features.

Pie menus are menus with their choices positioned in a circle around
the menu center. In NeWS, pie menus are displayed in round windows.
Many types of pie menus will be demonstrated.

** 1988–10–25: Gave pie menu demos to Steve Jobs and Bill Joy at Educom.

On October 25, 1988, I gave Steve Jobs a demo of pie menus, NeWS,
UniPress Emacs and HyperTIES at the Educom conference in Washington
DC. His reaction was to jump up and down, point at the screen, and
yell “That sucks! That sucks! Wow, that’s neat! That sucks!”

I tried explaining how we’d performed an experiment proving pie menus
were faster than linear menus, but he insisted the liner menus in NeXT
Step were the best possible menus ever.

But who was I to rain on his parade, two weeks after the first release
of NeXT Step 0.8? (Up to that time, it was the most hyped piece of
vaporware ever, and doubters were wearing t-shirts saying “NeVR
Step”!) Even after he went back to Apple, Steve Jobs never took a bite
of Apple Pie Menus, the forbidden fruit. There’s no accounting for

** 1988–11–02: Heard back from CACM about pie menu paper.

From: Mark Weiser at PARC
To: Don Hopkins
Cc: Jack Callahan
Date: 2 November 1988
Subject: Re: Job Posting

Finally heard from the CACM. They like the pie menus paper (a year and
half later!), but would like a more or less minor rewrite to (a)
deemphasize the experiment, (b) make the thing more a feature article
rather than a “research contribution”. That all seems fine to me. Ok with

Do you even remember this long ago paper we submitted:-)


The unpublished paper we submitted to CACM:

Unfortunately we never resubmitted a revised version the paper for
publication, so it remained unpublished. But it’s available online.

In the year and a half since we submitted the original version, so
much had happened with pie menus, window management, pull-out menus,
tabbed windows, NeWS, Emacs, HyperTIES, PSIBER, etc, that I thought it
needed to be rewritten from scratch.

Pies: Implementation, Evaluation, and Applications of Circular Menus
Don Hopkins, Jack Callahan, Mark Weiser


Old Pie Paper Directory

Here is my old piepaper directory, with many notes, outlines,
references, articles and other material about pie menus, upon which
I’ve base subsequent papers and articles. It includes Jack Callahan’s
experimental data for the CHI’88 paper and his data parsing and
analysis software.


Pie Paper Comments

The is the text of the paper submitted to CACM, with my comments and
notes about changes and additions:


** 1989–01–21: Started work on PSIBER Space Deck visual PostScript programming environment with pie menus

I wanted to use PostScript to implement a visual data browsing, editing, programming, and debugging interface to itself. Since PostScript is homoiconic (like Lisp), its data is equivalent to its code, so a data browser and editor is also a code browser and editor!

This was the beginning of a long evolution from:

dataitem.ps => spike.ps => pspike.ps => cyber.ps => litecyber.ps => psiber

** 1989–03–07: SoftMenu User Editable Pie Menus for NeWS Lite Toolkit

For NeWS, I implemented a “SoftMenu” editable subclass of pie menus
(that also could mix into linear menus), that enabled the user to
edit, cut and paste menu items. But it was quite dangerous because
you could really confuse things by pasting emacs commands into the
terminal emulator, etc.

From: Don Hopkins
To: NeWS-makers
Date: 7 March 1989
Subject: soft menus

% Menus that can be changed while they’re popped up.
% Don Hopkins
% Instructions:
% This file defines a subclass of DefaultMenu called SoftMenu, which
% it then installs as DefaultMenu.
% It allows you to cut & paste menu keys around dynamically from menu
% to menu, using the PointButton. (The left mouse button on a Sun.)
% This should work with most menu classes. (hopefully…) Just don’t
% load it in on top of itself.
% While making a selection from a menu:
% PointButton
% Copy the highlighted menu item to PrimarySelection.
% (i.e. like “copy” on the Mac)
% Shift PointButton
% “Insert” the menu item from PrimarySelection before the
% highlighted item. If no items are highlighted, it’s appended
% to the end of the menu.
% Control PointButton
% “Delete” the highlighted menu item.
% Meta PointButton
% “Edit” the highlighted menu item. (Coming soon. Suggestions?)
% To make a new menu item, you can select a string or array
% subinterval which will push a menu key and an action on the stack
% when executed, and insert it into a menu. Note that everything is
% executed in the context of the menu you’re inserting into.
% It’s your responsibility to avoid circularities!
% If you select a (dict,key) pointer in cyberspace, and insert it
% into a menu, the key name will be the menu key and the value
% “dict key get” will be the action.
% Examples: (just select the following and paste them:)

** 1989–04–21: Precision Pie Menu

Precision Pie Demo

Demo of the precision pie menu. Research performed by Don Hopkins
under the direction of Mark Weiser and Ben Shneiderman. Developed and
demonstrated by Don Hopkins.


** 1989–04–22: The scoop on GoodNeWS !!!

From: Hugh Daniel
To: Citydesk, Don Hopkins, Grasshopper, Roger Gregory, Dug Scoular, James Gosling
Date: 21 April 1989
Subject: The scoop on GoodNeWS !!!

I just talked to Doug Scoular at the Truing Institute about the
public domaining of GoodNews. He is working on the makefiles for the
tape as I write this!

They are going to send two tapes of GoodNeWS to the US, one to UUNET
and the other to Grasshopper. I don’t know the wording of any licences
they have on the tape, but they are trying to put the tape into the
full Public Access Domain, if not the Public Domain its self.

The tape should be FTP’able from UUNET and brillig soon after it
gets here. I will put a copy on hoptoad for downloading to Sun when
ours gets here.

Now, what is GoodNeWS? GoodNeWS was a Macintosh Look/Work alike, with a HyperCard, a MacDraw and other goodies that ran as a unique window
manager under NeWS. It was the look & feel, but implemented via NeWS
instead of QuickDraw.

The new version of GoodNeWS (1.2) has the Look changed to be closer
to that of OpenLook. GoodNeWS now also works at the same time a
LiteWin, so both window managers can run at the same time. The
hypercard like program now handles multiple windows too. We will have
to wait to see what all they have really done.

One interesting note about Apple. We asked for a copy of GoodNews
back when it had the Macintosh Look & Feel. Turing asked Apple if
they would mind, and Apple never responded. The Turing folks decided
that they would just change the Look instead of waiting forever to see
if Apple was going to yell at them.

In this case at least Apple has gotten what it thinks it wanted.

Let’s hope it’s not to our detriment.

||ugh Daniel

(Dug, please include the postscript source to the manuals online if

** 1989–03–10: Released QuickWin Pie Menu Based Window Manager

From: Don Hopkins
To: NeWS-makers
Date: 10 March 1989
Subject: quickwin.ps: pie menu window manager

This is subclass of LiteWindow, which implements a window manager
designed for pie menus. It’s an improved version of neatwin.ps, which,
among other things, shares the menus between all window instances, and
makes the FrameCanvas and IconCanvases non-retained when they are
unmapped. IconMenu and FrameMenu are one and the same. And the shared
FrameMenu won’t let Spin or Backgammon molest it (it gives them their
own copy of itsself).


** 1989–03–10: Released Pie Menus with “Direct Pac-Manipulation” Feedback

From: Don Hopkins
To: NeWS-makers
Date: 10 March 1989
Subject: Pie menus with “Direct Pac-Manipulation” feedback

This is a new version of pie menus for NeWS, with several bugs fixed,
some defaults changed, and some new features added.

They don’t use retained canvas by default, and they don’t use savebehind
on a monochrome display, since it seems to occasionaly tickle some
server bug and leave turds on the screen.

Now pie menus support mouse ahead display supression based on mouse
motion (instead of a timeout like before), and “Direct Pac-Manipulation”
feedback. If you press the menu button down, without moving the mouse,
the menu should pop up almost immediatly. If you’re moving the mouse
around, the menu display is supressed until you stop moving or make a
selection. If you “mouse ahead”, and make a selection quickly before the
menu is displayed, then you will see a pac-man blink onto the screen
where the menu would have been and chomp the slice you selected. You
can tell you’re getting the hang of it and really racking up them points
when you can make the pac-man blink all the way through several levels
of nested menus! But other people can look at the screen and see what
menu selections you’re making, so if you’d rather that your menu
selections be invisible and mysterious, you can set the class variable
/Wocka to false. If you can tolerate it, you can increate /WockaTime to
get a slower pac-man.

(PS: Lawyers, please note, this uses a non-profit, non-denominational,
generic pac-man, whose green card is on file. All disclaimers in the
universe apply, but are not listed here due to space limitations.
“moveto”, “arc”, and “closepath” are trademarks of Adobe. ;-)


From: Don Hopkins
To: Mark Weiser at Xerox, Ben Shneiderman, Jack Callahan, Ken Norman
Date: 2 March 1989
Subject: latest pie menu metaphor ;-)

User interface metaphores can be useful when they relate to familiar
tasks and take advantage of pre-existing skills and knowledge. With
this in mind …

The latest pie menu metaphor:
 Direct Pac-Manipulation


From: Bruce Barnett at GE
To: Don Hopkins
Date: 13 March 1989
Subject: Re: new pacman pie menus

I really think you ought to modify the code to count ‘pacmans’.

When you create 100 of them, a window pop’s up and lists’s you name
under the top ten all-time scores!!!!

Great job!

 Bruce G. Barnett

From: Don Hopkins
To: Mike Meyer at Berkeley
Date: 28 October 1989
Subject: annoying you

I hope the pie menu pac-man feedback Bruce was taking about doesn’t
annoy you *too* much, but if it does, there’s a flag that turns it
off. Instead of mapping the menu when you mouse ahead, it quickly
flashs a circle up on the overlay plane, in the shape the menu would
have been, with a bite out of it, the size of the selected wedge.
Looks just like a pac-man pointing in the direction of the selection.
(I didn’t *mean* for it to look like a pac-man. That’s just how it
turned out. Believe me, I used to *hate* pac-men.) It’s much cheaper
than mapping the menu canvas and drawing it, since it uses the overlay
plane (using xor, or an actual plane if NeWS supports it (like the SGI
Iris’s NeWS)). With the pac-man feedback on the overlay, menu
selections are not totally invisible, so it’s easier to convince other
people looking at the screen that you’re not just pushing the mouse
around and clicking randomly. (I have yet to come up with a utility
that flashes pac-men around on the screen automatically, while I’m
just pushing the mouse around and clicking randomly, so it looks like
I’m getting work done.)


From: Don Hopkins
To: NeWS-makers
Date: 2 June 1987 at 19:33:36 CEST
Subject: Gratuitous icon zoom procedure

Put this in a file called “pacman.ps”, and load it into your NeWS
server with “psh pacman.ps”. This is completely hedonistic, with no
socialy redeeming value whatsoever, so I’m certianly not responsible
for any time you waste watching your icons open and close!


** 1989–03–11: Released NeWS CyberSpace Deck and Pseudo Scientific Visualizer with Pie Menus

From: Don Hopkins
To: NeWS-makers
Date: 11 March 1989
Subject: NeWS CyberSpace Deck (without instruction)

I will post instructions to this soon (I have to catch a flight!), but
as an experiment, try it out and see what you can figure out on your
own, and then when I send instructions, you can tell me what features
were hopelessly obscure. ;-)

Hints: FunctionF10 (Alternate) is “help”. Double click the left button
on things to open them. Shift, Control, and Meta do special stuff.
Press L9 (Find) for completion!


From: Don Hopkins
To: NeWS-makers
Date: 11 March 1989
Subject: NeWS Molecules

This is a new version of the Pseudo-Scientific Visualizer. It
projects hallucinations of a NeWS molecules onto the screen. (These
things don’t really exist, so they’re not prohibited by law.) Once
it’s done virtualizing the hallucination, there is a shudder, a puff
of smoke comes out of the back of the CPU, and then all the little
bits and pieces are made synesthetically mouse sensative!

Composite objects (arrays and dictionaries) highlight when you point
at them, and their printed name is show in the text item at the bottom
of the window. When you click the point (left) button on a highlighted
object, it is selected (in PrimarySelection). When you click the point
button on the background, it highlights *all* mouse sensative objects.
When you click with the adjust button on a highlighted object, it zoom
into that object. Select the menu item “Thing… Top” to get back to
the original object.) When you change something with the menu, it
takes effect immediatly while it’s drawing. If you make changes after
it’s finished painting, you should redraw (menu “paint”) the window to
see them.

If there is an argument to psh, it executes it and grows a molecule
with the resulting object. Otherwise it just installs its class in
systemdict, for later use.


** 1989–03–22: Heard About Pie Menus for HyperCard

From: Andrea Ignatowski at University of Colorado
Organization: University of Colorado, Boulder
Newsgroups: comp.sys.mac, comp.sys.mac.hypercard, comp.sys.mac.programmer
Date: 23 Mar 89
Subject: Pie Menus for HyperCard


An implementation of pie popup menus for HyperCard has been posted to comp.[binaries|sources].mac. Pie menus function much like the “normal” mac popup menus but are circular in format. We are conducting a survey regarding the use of these menus and would appreciate you trying them and sending us your comments (as well as any improvements to the code).

For a description of pie menus and their usage please see the article appearing in the SIGCHI 1988 Conference Proceedings:
 “An Empirical Comparison of Pie Vs. Linear Menus”
by: Jack Callahan, Don Hopkins, Ben Shneiderman, and Mark Weiser

Andrea Ignatowski

** 1989–05–23: Handy Pie Menu Demo

Handy Pie Menu Demo

University of Maryland Human Computer Interaction Lab Handy Pie Menu
Demo. Research performed under the direction of Mark Weiser and Ben
Shneiderman. Pie menus developed and demonstrated by Don Hopkins.


** 1989–07–01: Release Pie Menus for NeWS on NeWS-makers.

From: Don Hopkins
To: NeWS-makers
Date: Wed, 1 Jul 1987
Subject: Pie Menus for NeWS

This is my initial implementation of Pie Menus for NeWS, in
PostScript. The choices of a Pie Menu are positioned in a circle
around the cursor, so that the direction of movement makes the
selection. There is an inactive region in the menu center where the
cursor starts out, and the regions corresponding to the choices are
wedge shaped, like the slices of a pie: each slice is adjacent to the
cursor, but in a different direction. Moving the cursor further out
from the menu center increases the angular precision. Pie Menu
choices may be positioned in intuitivly correct directions, with
opposite choices in opposite directions, and other natural
arrangments. Pie Menus are easy to learn, using “muscle memory”,
because you remember directions, not order. Because you don’t need to
look at the menu to choose a direction, you can mouse ahead dependably
with menus you’re familiar with.

More information about Pie Menus if forthcoming, but right now I want
to get the initial implementation out so that people can use them.
Just load the following file into a NeWS server with psh, and try them
out. They replace the default menu class, so that subsequently made
menus will be Pie Menus. I welcome your questions, comments, and


** 1989–07–22: Wrote The CyberSpace Deck Manual

CyberSpace Deck Manual


** 1989–08–19: First Release of PostScript Interactive Bug Eradication Routines

PSIBER Space Deck Demo

Demo of the NeWS PSIBER Space Deck. Research performed under the
direction of Mark Weiser and Ben Shneiderman. Developed and documented
thanks to the support of John Gilmore and Julia Menapace. Developed
and demonstrated by Don Hopkins. Described in “The Shape of PSIBER
Space: PostScript Interactive Bug Eradication Routines”.


PSIBER Space Deck and PseudoScientific Visualizer for NeWS

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines.
By Don Hopkins. Proc. 1989 Usenix Graphics Conference, Monterey California.

Gave a performance of the PSIBER Space Deck and Pseudo Scientific Visualizer at Empowered, CHI ‘90.

From: Don Hopkins
Date: 19 August 1989
Subject: PostScript Interactive Bug Eradication Routines
To: Cyber-Guinea-Punks

The following 5 messages contain a test release of the PostScript
Interactive Bug Eradication Routines (PSIBER). They have been tested and
run under NeWS 1.1 and X11/NeWS Beta 2 on the Sun, and Grasshopper
MacNeWS 1.1. The file “introduction” contains documentation (the first 
page of which is included in this message).

PSIBER has also been known as the CyberSpace Deck, or PSpike. (I came up
with the latest contrived acronym since AutoDesk trademarked the word

The 5 messages contain a split-up compressed shar file. In an empty
directory, reassemble the messages in order according to their subject
lines, stripping the mail headers. Pass that through uudecode to get the
compressed shar file “cyber.shar.Z”. Uncompress that to get “cyber.shar”.
Unpack that by typing “sh cyber.shar” (after reading it over meticulously
if you don’t trust me! ;-) Look at the “README” file, and load the stuff
into your NeWS server by typing “cyber”. It will read in an awful lot of
PostScript code, and finally let you shape its window. Look at the file
“introduction” for help in navagating around. There are some files in the
directory that contain yet-to-be-documented stuff. There’s quite a bit
more work to be done, but I would really appreciate you trying out what’s
there and sending me impressions and comments. Tell me what doesn’t work,
and what you find to be useful, and any other criticisms or suggestions
that come to mind!


** 1989–10–12: Spiral pies.

From: Don Hopkins
To: John Gage at Sun
Date: 12 October 1989
Subject: spiral pie menus

I /finally/ implemented those spiral pie menus you said would be so neat!
You can have lots of items on the menu, but only 8 of them are displayed,
and you can scroll through the items by spinning the cursor around the
menu. They’re very nice for large menus, because pie menus with lots and
lots of items take up (lots and lots)² of screen space, and limiting
them to 8 displayed items makes quite reasonably sized menus.

I’ll send you the .ps files that implement all this stuff for NeWS
if you like!


** 1989–10–20: Recorded Pie Menu Demos for All The Widgets

Recorded video tape of pie menu demos and wrote credits for All The
Widgets, by Brad Meyers.

Just the Pie Menus from All the Widgets

Pie menu demo excerpts from “All The Widgets” CHI’90 Special Issue #57
ACM SIGGRAPH Video Review. Including Doug Engelbart’s NLS demo and the
credits. Tape produced by and narrated by Brad Meyers. Research
performed under the direction of Mark Weiser and Ben Shneiderman. Pie
menus developed and demonstrated by Don Hopkins.


All The Widgets

Video taped demonstrations of pie menus I designed and
implemented, for “All The Widgets”, a video tape of user interface
techniques produced by Brad Myers for the ACM SIGGRAPH Video
Review (CHI’90 Special Issue #57).

From: Don Hopkins
To: Brad Myers at CMU, Ben Shneiderman
Date: 20 October 1989
Subject: video tape of pie menus

I will make a video tape of pie menus for you by November 1. I’m sorry
I took so long to respond. The tape is now top priority. I just
finished a paper for the Usenix graphics workshop in Monterey, on Nov
16–17, (The Shape of PSIBER Space: PostScript Interactive Bug
Eradication Routines), about a direct manipulation visual PostScript
debugging/programming/environment exploration tool for NeWS. I have to
make a video tape of that for the workshop as well. It makes use of
pie menus, tab windows, snap dragging, dragon dropping, and several
other interesting interaction techniques. I will tape them all in the
format described in the very informative package you sent to me in the

Here’s a list of some of my work that I can tape. There is a bit of
overlap, since some of these things are built around or on top or
along side of others. Which sound most appropriate for your
interaction techniques video?


 A virtual mouse in a window, that tracks the real mouse on the screen.
 It leaves the path wherever the mouse travels, and marks where
 buttons are pressed. The virtual mouse has buttons that highlight
 when the real buttons are down. 
 Very useful for illustrating the use of the mouse while
 demonstration interaction techniques. The latest version also draws
 the locations and outlines of menus (both pie and linear) when
 they’re activated (even if the actual menu display is supressed).

Pie menus:
 The usual stuff: a few items, a lot of items (bad), 8 items
 (good), mnemonic directions, nested menus, browsing a menu
 tree, mouse ahead, display supression (w/ pac-man feedback).

Pull out pie menus:
 Direction specifies one of several pie menu selection slices.
 Distance is an argument to the selection.

Discrete pull out pie menus:
 Distance specifies one of several sub-selections (or arguments) in
 each slice. They encompass 2-dimensional linear menus.

Continuous pull out pie menus:
 Distance into the wedge specifies a number, that you see in the menu
 center, increasing as you move the cursor out.

Font menus:
 Pie menu of font families, with submenus of font styles. The font
 style submenus include samples of the font in normal, bold, italic,
 and bold italic (or whatever styles are available). The pull-out
 selections use the distance to select the point size, giving
 feedback in the menu center of the font (family, style, size)
 selected. When you pull out and in, the font sample in the menu
 center grows and shrinks. (This is /very/ nice using the Folio
 outline fonts in X11/NeWS, once you’ve loaded up the font cache.)

Color menus:
 Pie menu of color properties you can change. Pull out to select
 brightness, then pop up hue/saturation color wheel submenu at that
 brightness. Direction is hue, distance is brightness. You see
 feedback in the menu center, a circle of the selected brightness,
 hue, and saturation.

Spiral pie menus:
 A pie menu with many items can take up a *lot* of screen space
 because of the way it’s layed out. The more items, the harder it is
 to select from any of them. 8 is an optimal number of pie menu items
 to display. Spiral menus can have any number of items, but will
 display at most 8, allowing you to scroll between the others by
 cranking the cursor around the menu center. Arrow symbols are drawn
 to indicate that there are more entries “around the bend”.
 Non-euclidian parallel of scrolling linear menus.

Pie menu selection from the keyboard:
 4 or 8-item pie menus can be used with an arrow or numeric keypad. 
 A simple NeWS utility that maps the keypad to mouse movement
 and button events transparently allows the unmodified pie menu
 implementation to be used without the mouse.

Pie menu window manager:
 A window manager that uses pie menus, designed to take advantage of
 muscle memory. A good demonstration of pie menu design principles,
 in a practical application. I have written a paper about it.

 The NeWS interface to UniPress (Gosling) Emacs. Multiple windows,
 with title tabs sticking off their edges. You can have a whole
 bunch of windows opened at once, overlapping but with all of their
 tabs showing. The lined-up tabs serve as a linear menu of opened
 windows, and as handles on the windows that you can use to bring
 them to the top, move them around, or pop up a window managment
 menu. Lots of pie menus of NeMACS functions (including font and
 color pies).

HyperTIES hypertext browser and authoring tool:
 Runs under NeWS and NeMACS. Multi-window editing of text files of
 a hypertext database, alongside a formatted graphial view in a
 browser window.

PSIBER Space Deck:
 The interactive visual programming environment alluded to above.
 Tab windows viewing mouse sensative PostScript data structures that
 you can open up, edit, copy, and paste. The PostScript process’s
 stack is a spike that you can directly manipulate by dragging
 objects up and down and on and off. Snap dragging of objects spiked
 into the stack. Lots of pie menus. The pseudo-scientific
 visualizer, a fish-eye lense for displaying arbitrarily complex data
 structures, that’s too weird to describe, but uses lots of colors,
 does tricks with the overlay plane, and makes the power supply chirp
 and buzz. Including extra-cheezy pop-up pointing hand annotations.

From: Don Hopkins
To: Brad Myers at CMU, Ben Shneiderman
Date: 3 November 1989
Subject: pie menu video tape!

The tape is done, and I picked up a VHS copy of it at the ITV lab,
which I will express mail to you today. Enclosed is a synopsis of
what’s on the tape. Would you rather have a u-matic tape? It was shot
on u-matic, so we can have them make another high quality copy and
send it to you asap, if you’d like.


Synchronize when I say “Ok”, at time 00:00.
00:00 — Mousee
 Virtual mouse
 Displays mouse movement and button presses in a window
01:00 — Go board menu selection with mousee
 Linear menu and pie menu
 Mousee displays menu outlines
01:35 — Cut
02:22 — Flag waving applications
 Short and long linear menus
 Small and large pie menus
 Scrolling spiral 8-item pie menu
05:43 — Cut
06:30 — Pie menu window manager
11:50 — Mouse ahead
14:42 — Cut
15:03 — Browsing nested pie menus
 NeWS root menu
18:30 — Cut
18:15 — Pull-out color wheel pie menus
 UniPress Emacs
21:22 — Cut
22:35 — HyperTIES embeded menus
 Textual and graphical hypertext links
24:50 — Cut
27:05 — Font selection pie menus
 Pull-out point size
 X11/NeWS outline fonts
30:20 — Cut
32:06 — PSIBER Space Deck
 Direct stack manipulation
 PostScript data types
 Data structure editors
38:18 — Cut
38:35 — Tab windows in UniPress Emacs
 HyperTIES authoring tool
 Pie menu window manager
39:30 — Mouse ahead with pie menu window manager on window tabs
40:10 — Cut
42:20 — PSIBER Space Deck
 ARPANET map made of PostScript dictionaries
44:00 — Pseudo Scientific Visualizer
 X-ray view of mouse sensative nodes
 Pop-up pointing hand annotations
46:40 — PSIBER Space Deck
 Root menu dictionary
48:40 — Pseudo Scientific Visualizer
 Root menu dictionary
 Pop-up pointing hands
52:22 — Cut
53:25 — Precision pie menu
 Exaggerated angular precision
55:10 — Cut
55:35 — Handy pie menus
 Pointing hand cursor
56:15 — Cut

** 1989–11–16: Presented The Shape of PSIBER Space at 1989 Usenix Graphics Conference in Monterey, CA

1989 Usenix Monterey Graphics Conference in Monterey CA

Presented PSIBER paper.


** 1989–11–20: Pie Menus for NDE 1.0 (NeWS Development Environment) for Sun Workstations

Pie menus for the NeWS Development Environment (NDE 1.0), on
OpenWindows 1.0. I wrote pie menus and tab windows from scratch on top
of an early version of this big, new, complex, object oriented
PostScript toolkit for NeWS, written by Sun.

** 1989–12–22: Generic Pie Menu Tracking and Layout Code in C

Source code:

Generic pie menu tracking code (optimized for speed)
Example pie menu layout code (optimized for screen space)
This supports pie menus with any number of items. 
Each item can be of any positive angular width, as long as
all the item widths add up to 360 degrees.
Each item records the quadrant and slope of its leading edge.
A leading edge is a ray going out from the menu center in
the direction given by an item’s (quadrant,slope) pair (see below).
The area of a pie menu item is the wedge between its leading edge, 
and the leading edge of the next menu item.

From: Don Hopkins
Date: 20 December 1989
Subject: Efficient pie menu tracking in C

The old uwm inplementation of pie menus is on top of X10R4 uwm, and
isn’t much use with X11. I have however started to root the pie menu
tracking code out of it, and now I have a nice pie menu tracking
library in C, with several optimizations I’ve developed. I still need
to make a generic layout procedure, but that’s not too hard, and there
are a lot of ways to do it. I will send you the code I have, which has
a main() program that tests it somewhat. It seems to work. In order to
implement real menus, you’ll need a layout function, and you will have
to add appropriate elements to the menu and item structures. This is
just generic code meant to demonstrate efficient pie menu tracking.
Its input is a menu struct and (x, y), and its output is -1, or an
index into the menu struct’s item array, the selected item. It does
not do any trig during tracking, and avoids unnecessary division. The
(unimplemented) layout procedure should, for each leading menu item
edge at angle theta, call calc_quadrand_slope with (int)(cos(theta)*r)
and (int)(sin(theta)*r) to get quadrant, numerator, and denominator,
then divide numerator by denominator to get a (real)slope, and stash
them in the item stucture for use during tracking. Layout only has to
happen every time the menu items change, so there’s no reason to do
trig every time the mouse moves! The current NeWS implementation
calculates the selected item by calling atan every time the mouse
moves, which adds the restriction that every item must be the same
(angular) width. Since PostScript is an interpreted lanugage (and I
am lazy), I felt it was more efficient just to take advantage of the
floating point hardware via the atan primative than to implement
complicated cursor tracking algorithms in PostScript. Now that I have
this clean implementation to base it on (the old uwm code was NOT
clean!), I might try re-implementing the PostScript code using this
algorithm, and see how it compares.


** 1989–12–26: First saw SimCity

From: Don Hopkins
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab, Coll. Pk., MD 20742
Newsgroups: comp.theory.cell-automata
Date: 26 Dec 89
Subject: SimCity
Summary: Urban development simulation where it belongs: in a video game!

I just got a chance to play SimCity! It’s like a drawing program that
lets you build cities, by zoning districts, putting down power plants
and football stadiums, wiring up the power grid, laying down roads and
railroads. The simulation is actually running *while* you’re
constructing it! It acts like cellular automita with very high level
rules — it keeps track of each cell’s population, land value,
pollution, and many other factors, and the rules that govern how the
zones develop are based on the state of neighboring zones, and other
global factors (tax rate, etc). Districts that you’ve zoned don’t come
online and start developing until they’re hooked into the power grid,
by being connected through power line cells or adjacent buildings.
Buildings seem to “feed” off of people brought in by roads and
railroads. Residential zones in busy districts grow into high-rise
apartment buildings. Traffic patterns develop on the roads, and you
can see little cars zooming around based on the population of the
area, and the flow of the roads! Once you build an airport, a
helicoptor flies around the city and reports on heavy traffic,
encouraging you to redesign the roads in that area!

You may wonder what traffic copters have to do with cellular automita. 
You just have to play it yourself to understand.

SimCity is absolutely the most amazing game I’ve seen on the Macintosh
to date! (It’s available on other computers like the Amiga, as well.) 
The graphics and animation are beautiful. I’ll leave it at that — 
mere text cannot do it justice.


From: Don Hopkins
To: gt0852c at Georgia Tech
Date: 1 January 1990
Subject: SimCity

I share your longing for a taste of the Sim City sources! It’s a
fascinating game! I have heard of Empire, and heard people talk about
what fun it is, but I’ve never had a chance to play it myself. I have
been playing around with tinymud (a multi user dungeon that the
players can extend!). Sim City is a very interesting example of a
visual programming language! As I pan over the cities I have created,
I cannot help but thinking of those buildings as software modules and
integrated circuits, mounted on a PC board. And in a sense, they
really are! I would like to have the programming system that Sim City
is built on top of actually embeded in the city, as buildings,
software modules that I can hook up with systems of roads and mass
transit! Not unlike Arachne, a visual programming language that lets
you wire up data flow diagrams between boxes with tits for inputs and
outputs. Think of putting all those factories to work, actually
computing real stuff! A wire frame factory, connected to a 3-d
transformation factory, to a ray tracing factory, then a railroad to
take all the nice new ray traced objects to market in the city (nice
looking buildings, cars, bridges, trains, etc)! A nuclear power plant
to run them all (a remote computing server!).

Sim City has a *wonderful* metaphor! It sure beats the desktop! 
I wonder how far it can be taken?

** 1989–12–30: Proposed Pie Menus for XView

From: Don Hopkins
To: Richard Probst at Sun
Date: 30 December 1989
Subject: XView pie menus

Is anybody at Sun interested in pie menus for XView? My first
implementation of pie menus was in square windows, as an extension to
the X10R4 “uwm” window manager. Since I got the NeWS 1.0 beta release,
I’ve been doing pie menus in PostScript, but recently, I extracted my
C pie menu cursor tracking code from the old X10 “uwm”, and cleaned it
up so it’s not specific to any window system. The tracking code
supports slices of different widths, and does a minimum ammount of
math during tracking (no trig or division, just floating point
multiply and comparison).

Now I am writing some generic pie menu layout code in C, to go with
the generic cursor tracking code. Layout is not as well defined a
problem as cursor tracking of course, so what I’m writing is just an
example layout policy, showing how to set up the data structures used
by the tracking code. (The layout procedure should decide how big and
which way to make the slices, pre-calculate trig functions of the edge
directions for use during tracking, and figure out where to put the
labels, keeping them from overlapping, trying to minimize the size of
the menu, and making it obvious which label is associated with which

I don’t have the time right now to work on pie menus for XView myself
(I’ve made a first cut at it in tNt, though), but I would be glad to
give you my code and any other information that would be helpful! I
would like to correspond with anyone interested in implementing pie
menus for XView, or coming up with a nice Open Look pie menu layout
policy and graphical “look”. (pies with push pins!)


From: Richard Probst
To: Don Hopkins
Date: 5 January 1990
Subject: Re: XView pie menus

Since XView code is now out on the X11R4 distribution, we hope
that people will be inspired to add to it. Pie menus sound like
a neat addition. But I don’t see anyone at Sun with the free
time to work on this feature. If you’d like to contact someone
with questions, try Tom Jacobs (tomj@sun.com). However, unless
you’re able to contribute this as a just-about-working piece,
I think it’s going to have to wait.

— Richard

** 1990–02–11: Tabbed Frames for NDE 1.0 (NeWS Development Environment) for Sun Workstations

Implemented tabbed frames for NDE 1.0, with pie menus.

It was actually possible to manage X11 windows with NeWS tab windows
and pie menus, because the X11 window manager was written in NeWS, and
used the default NDE window frame, which I could customize and
override. NeWS Development Environment (NDE 1.0) was eventually
completely rewritten and renamed “The NeWS Toolkit”.

From: Don Hopkins
To: NeWS-makers
Date: 11 February 1990
Subject: X11/NeWS Tab Frames

This is an implementation of tab frames, on top of the Open Look frame
class in tNt (the NeWS toolkit, aka NDE). It runs under Open Windows
1.0 (aka X11/NeWS).

Instead of having the title at the top of the window, tab frames have
the title in a tab stuck to the window edge, that you can drag around to
any of the four edges by pressing the Adjust (middle) button down over
the title (when the cursor is a + sign) and dragging it to where you
want. Notice that the tab sticks to the end of an edge until you
actually go around the corner. (This is so it’s easy to move it to the
end of an edge.)

Double clicking the Point (left) button on the border or tab “zooms” the
window as usual, except that the window is reshaped so it’s on the left
edge of the screen, full height, with its tab along its right edge, just
below the previous tab. It is convenient to zoom a bunch of windows and
have them all overlapping, but with all of their tabs visible (showing
their titles). You can click the Point (left) button on the tab to bring
the window to the top. It could be smarter about the layout, but this is
just a start.

Also I have added resize controls to the window edges to complement
the Open Look resize corners. These are useful when you want to change
the window height without changing the width, or vice verse. (You’ll
want to do that a lot with tab frames, like when you want to make a
zoomed window shorter.)

Least importantly, I added a fake 3-D look (wooo golly gee) to the
tabs. When a tab frame has the input focus, its tab appears to pop
out (with beveled edges around the window title). Personally I don’t
think 3-D window frames are particularly useful (unless they *really*
*are* 3-D, and fly out at you like the SGI button demo). It would be
poor form to make the window borders thicker and slow down the drawing
for no other reason than fake 3-D. In this implementation, only the
tab of the window which has the input focus (where keyboard input is
directed) is displayed in fake 3-D. This is less distracting than
having *all* the tabs in fake 3-D, and makes it painfully obvious
*which* tab frame has the keyboard focus.

I would appreciate feedback: what kind of automatic window and tab
layout policy would be most convenient, least obnoxious? I am thinking
of implementing snap dragging, to help line up windows and tabs, but for
now the Open Look screen edge snapping works pretty well. One of these
days I will incorporate pie menus into the tab frame window manager (ala

Summer before last, I implemented tab frames under NeWS 1.1 for UniPress
Emacs V2.20, and found them very convenient for editing lots of files at
once (UniPress Emacs supports multiple windows, which can get very
confusing without the help of the tabs). The idea is totally unoriginal,
as useful for window management as it is for address books, so feel free
to implement it for other window systems without fear of being sued. My
code is freely redistributable.

For a demo, put the enclosed code in the file NeWS/tabframe.ps, and type:

% psh NeWS/tabframe.ps
% psh
/demo TabBaseFrame send
/demo TabCommandFrame send

If you are pleased, and want to install tab frames as your default frame
class (so you get them around all your X windows (if you run pswm) as
well as your NeWS windows), put the following into your .startup.ps

UserProfile /OpenLookFrame {
 ClassFrame /DefaultClass { TabFrame } put
} put

 /TabFrame (NeWS/tabframe.ps)
] DefineAutoLoads

There are still a few rough edges (of course the most obvious rough edge
is considered a feature), but I plan on developing this further, so
please tell me about any problems you have, and send me suggestions for
enhancements, top of the head comments, incoherent raving brainstorms,


** 1990–03–15: GoodNeWS & HyperNeWS version 1.3 NOW AVAILABLE!!!!

From: Don Hopkins
To: NeWS-makers
Date: 15 March 1990
Subject: GoodNeWS & HyperNeWS version 1.3 NOW AVAILABLE!!!!

Hurray hurray!!

GoodNeWS and HyperNeWS version 1.3, by Arthur van Hoff of the Turing
Institute, are now available via anonymous ftp, from tumtum.cs.umd.edu
( [Set binary mode, go to the “NeWS” directory, and
retrieve the file “HyperNeWS1.3.RELEASE.tar.Z”. A collection of lots
of other NeWS programs is in the file “news-tape.tar.Z”.]

What is it? Well, as understated by the README file:

“This is GoodNeWS/HyperNeWS for OpenWindows1.0.
HyperNeWS provides a complete user-interface development
environment, which is considerable easier to use
than other offerings.”

Run, don’t walk, to your nearest shell window, fire up an ftp, and get
a copy! It’s too good to describe in detail, but basically, GoodNeWS
is a window system environment for NeWS, and HyperNeWS is HyperCard
done *RIGHT*, with PostScript instead of pixels, and Unix instead of

GoodNeWS includes a wonderful color PostScript drawing editor (which
can now include encapsulated PostScript documents!), utilities to
include plots in GoodNeWS drawings and GoodNeWS drawings in LaTeX
documents, a dvi previewer and dvi to PostScript converter (to print
and view LaTeX documents), a terminal emulator, a load monitor, a
chess position editor (you can paste chess boards into the drawing
editor), and a scrabble game.

You can make HyperNeWS stacks, in arbitrarily shaped windows, with
graphics and buttons and other user interface objects that are
programmable in PostScript. You can cut and paste drawings between the
GoodNeWS drawing editor and HyperNeWS stacks (and there is a new
drawing editor implemented on top of HyperNeWS!), make stacks with
buttons, scroll bars, sliders, scrolling editable text windows, menus,
dials, and more. You can write PostScript scripts for the user
interface objects (stacks, backgrounds, cards, and other stuff), and
there’s even (very importantly) a client side library to HyperNeWS, so
you can interface C, Prolog, and Lisp programs to HyperNeWS stacks!
HyperNeWS is actually a complete toolkit, and you can create user
interfaces using the drawing tool and HyperNeWS stack editing commands
(menus, buttons, sliders, text windows, keyboard accelerators, etc).
There are HyperNeWS stacks with documentation about GoodNeWS and
HyperNeWS, a class browser stack, stacks for editing the
characteristics of various HyperNeWS objects, and a lots of nifty
demos. (Pete’s neck never gets tired!)

Best of all, it’s free! Thanks to everybody at Turing for making it fly!


** 1990–04–03: CHI’90 Empowered Performance

Empowered Pie Menu Performance at CHI’90, and Other Weird Stuff. A
live performance of pie menus, the PSIBER Space Deck and the
Pseudo Scientific Visualizer at the CHI’90 Empowered show. And
other weird stuff inspired by Craig Hubley’s sound advice and
vision that it’s possible to empower every user to play around and
be an artist with their computer.

Performed interactive art on stage at the “Empowered” show at the
CHI’90 conference in Seattle. Gave a colorful whirlwind trip
through the networks in a graphical pie menu driven world I
created with NeWS, integrating the PseudoScientific Visualizer
with the PSIBER Space Deck. See “The Shape of PSIBER Space”.


** 1990–10–23: PizzaTool: How I Ordered My First Pizza Over The Internet

The Story of Sun Microsystems PizzaTool

How I accidentally ordered my first pizza over the internet.


** 1990–11–30: Corresponded with Gordon Kurtenbach about Pie Menus

From: Gordon Kurtenbach at University of Toronto
To: Don Hopkins at Sun
Date: Fri, 30 Nov 1990
Subject: pie menus!!!!

Hi Don. I’m a Ph.D. student at University of Toronto. Bill Buxton is my supervisor. We are interested in doing some experiments with pie menus and developing some novel ways of using them. We are very interested in the fact that you can mouse ahead with them and would like to explore this feature further. Since you are the grand implementor of some hot pie menu stuff I have a couple of questions:

1) is their any public domain code for them?

2) have you published any more papers other than the CHI Washington paper?

Thanks in advance.



From: Don Hopkins at Sun
To: Gordon Kurtenbach at University of Toronto
Date: Fri, 30 Nov 1990
Subject: pie menus!!!!

I’m glad to hear from you! The code I’ve written is freely redistributable without restrictions, and the idea is not patented or proprietary, and I encourage you to experiment with them and find out how to use them best!

I’ll send you some more stuff I’ve written about pie menus, and the code that implements them for NeWS, using the “Lite” toolkit. I have a very very old implementation for X10 on top of uwm, but all of the interesting features are in the NeWS code. I also have a bunch of strange mutant pie menu subclasses I implemented whenever I got weird ideas. NeWS is good that way, the crazier the idea, the more fun it is to implement!

If you want to implement them from scratch, I’d be glad to discuss some mouse tracking strategies I’ve developed! There are some fine points relating to correct *predictable* handling of mouse ahead, menu display supression, popping menus up at the edge of the screen and pointer warping, and other kinds of interactions. With pie menus, the important thing is how you move your hand, not how you move the cursor. Working with Bill Buxton, I’m sure you know what I mean! If you like, give me a call at work at (415) 336–3171, any time. I’m usually here until all hours. There’s too much to say to type it all in!


From: Don Hopkins at Sun
To: Gordon Kurtenbach at University of Toronto
Date: Mon, 10 Dec 1990
Subject: pie menus!!!!

At Sun, I am working on TNT 2.0, an Open Look toolkit written in object oriented PostScript for NeWS. In my spare time, I have implemented pie menus for TNT, and I would like to develop them further. Would you be interested in getting a version of TNT for Open Windows when it becomes available, to evaluate and play with? The feedback we’ve gotten from the people testing the toolkit has been fantastic, and it will be well supported by Sun! If you are into exploratory user interface implementation, rapid prototyping, look & feel customization, interactive object oriented programming, and that kind of stuff, you’ll be in paradise! For example, it would be easy to dynamically modify an abstract class in the system, so that certain interactions with certain components would be timed and logged to a file, to gather data for an experiment.


From: Gordon Kurtenbach at University of Toronto
To: Don Hopkins at Sun
Date: Mon, 10 Dec 1990
Subject: Re: pie menus!!!!

Don: TNT sounds great and yes I would be interested. Can you comment on the accuracy of the timing we could get from it? Here’s what we are investigating. I’m interested in using markings as an input technique. What I mean by markings are gestures with the mouse or stylus that leave an ink trail. Now the problem with markings is that unless you use mnemonic marking symbols it’s hard to remember what strange marking corresponds to what command. You may say well then use mnemonic markings. But the problem is that mnemonic markings may not always exist, may be hard to recognize and may be slow to articulate with mouse or stylus. So my approach has been to use very simple marks such as up, down, left right etc. These marks are easily to articulate and very easy to recognize. Now how do pie menus fit into this? The great things about pie menus is that for non-heirarchical ones selection is a simple gesture and this gesture matches the movement needed to make a simple mark!!! So here’s the way things could work: novice’s mouse down and get the pie menu because they need that amount of support. Its slow but when your a novice you just want to survive not operate at top speed. The the cool thing is that expert can mouse ahead like you’ve talked about but they get an ink trail so they have a better idea what they’ve selected without even bothering to wait for the menu to come up. Essentially the markings are a language of glyphs which are really accelerators. Furthurmore if you make a mark and keep the mouse down at the end of it a pie menu comes up so you can verify that you did the right mark. The idea here is that this will give novices a “smoother” transition to an expert user who has the menu layout memorized and can make selections without needing to look at the menu.

So in support of this stuff we are conducting an experiment to see how number of items in a menu and the layout strategy will affect the ability to articulate the gesture to select and how quickly people learn the layouts of menus and are able to “mouse ahead” which in our world is “use the mark instead of the menu”.

In the future, I hope to try this stuff on hierarchical menus to create richer marking languages. Plus I’m experimenting with other novel menu gadgets where a marking can correspond to the selection movement. Ok, hope this wets your appetite. Thanks for the info.


From: Don Hopkins
To: Gordon Kurtenbach
Date: Mon, 10 Dec 90
Subject: pie menus!!!!

I think TNT can provide you with excellent timing accuracy. Events are location and time stamped, and you can respond to them in the NeWS server where they are happening. There is a global event manager, a light weight PostScript process running in the NeWS server, that provides synchronization, using a centralized “services” architecture. The global event manager catches certain events and passes them off to local event managers, who are responsible for managing objects who asked for certain classes of events. Any event that would change the input distribution, by expressing or revoking interests, or changing the canvas hierarchy, will cause the input queue to be blocked until the changes have been made and it’s safe to continue event distribution. This means that the events get to where they were supposed to, and mouse ahead works very very well, even when the system is loaded and lagging behind. This architecture also saves us a whole lot of time and space (sharing interests and event managers), and makes it much easier to program an object to respond to events (because all the hard stuff is done behind the scenes by the system).


From: Gordon Kurtenbach
To: Don Hopkins
Date: 16 May 2018

Years later I gave a talk at U of Maryland and Ben asked me “I never really understood the difference between marking menus and pie menus”. Thats a totally valid question. I explained that the central idea was that the cursor path through the menu hierarchy needed to be a unique “mark” and I was approaching it as vocabulary of marks mated to a pop-up menu system, etc., not “mousing ahead”. He was cool with that, so I’m happy Ben seem to understand.

Here’s my simplified version of the evolution of “circular menus”:

  • Neuman etc does the first “circular menus” way back when
  • Hopkins etc does the pie menus version
  • Kurtenbach etc later adds the idea of a vocabulary of marks
  • Others build on this with Flow menus, Flower menus, SHARK, etc…

Here’s what happened with the patents:

  • Neuman, Hopkins, and Kurtenbach do research that ends up in the public domain.
  • Kurtenbach and Buxton at Alias/SGI invent the combo of circular menu and linear menu and patent that because the employment contract specifies that employee inventions are owned by the company.
  • Hopkins believes the patents are stopping him from implementing pie menus for 3D Studio Max and accuses us of being bad guys.

The reality is that we were just following SGI corporate patent policy. Now I hate corporations as much the next person, and I can certainly see the why people feel patents are bad. Then, on the other hand, patents were created to keep inventors from being ripped off.

** 1990–12–10: Implemented Pie Menus and Tabbed Windows for TNT 2.0 (The NeWS Toolkit)

NeWS Tab Window Demo

Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0.
Developed and demonstrated by Don Hopkins.


Gesture Ahead
Display Pre-Emption
Light Weight Overlay Feedback
Window Management
Tabbed Windows

Pie menus and tab windows for The NeWS Toolkit. When I graduated, I went to work for Sun on TNT, The NeWS Toolkit, for OpenWindows 2.0. TNT was loosely based on NDE, also written in object oriented PostScript, but it was twice the speed and half the size. Of course, I wrote pie menus and tab windows from scratch again for TNT, and continued to improve on the user interface, this time adding spinning pop-up animation, and air-tight synchronous mouse tracking (which is possible to do with NeWS but not with X11).

** 1991–04: Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab

Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab.

University of Maryland Human Computer Interaction Lab Pie Menu Demos. Introduction by Ben Shneiderman. Research performed under the direction of Mark Weiser and Ben Shneiderman. Pie menus developed and demonstrated by Don Hopkins.


** 1991–08–03: Developed “OWM” X11/NeWS ICCCM Window Manager with Tabs and Pies

NeWS 1.1 was layered on top of PixRects (the graphics library that SunView was built on top of), which gave it the weird limitation that sub-windows could not be positioned above or to the left of their parents (sub-window coordinates were unsigned), which was a huge pain in the ass for making all kinds of user interfaces.

X11/NeWS solved that problem by having a much nicer PostScript graphics renderer and compositor, but it came with its own set of problems, many having to do with being nailed together with a X11 server with a totally different graphics model and approach to life. But there were some really cool things you could do with X11 and NeWS together, like managing X11 windows with NeWS frames (which could have non-rectangular windows like jutting title tabs, round pie menus, panning virtual desktops, rooms, etc).

Another important point is that running the window manager in the same heavy weight Unix process as the window server saves an astronomical number of costly context switches, and results in much smoother user interface with silky local feedback. Plus it’s extensible and customizable and drawn in PostScript.

Here’s a demo of NeWS window frames with tabs and pie menus. We used those to made an ICCCM X11 window manager written in PostScript (that Sun never released) that let you use those tabbed window frames and pie menus and other NeWS components to manage all of your X11 windows (and use them as your default frame for NeWS apps too, of course), seamlessly integrating X11 and NeWS apps together.


Here are some flames and notes I wrote years ago about X11 and NeWS window management — the “OWM” section is about the NeWS X11 window manager. It covers some of the political and technical problems we had integrating X11 and NeWS. Window management is a surprisingly contentious issue! Everybody wants to be on top.


Basically, we didn’t want to put our round NeWS pie menus and pizza windows inside of their rectangular X11 ICCCM window frames, because it would have been better for everyone the other way around.


Josh Siegel wrote this beautiful PostScript tour de force swan song for X11/NeWS, an ICCCM window manager that actually worked quite well, with special window subclasses to support all the OPEN LOOK dialog types and window frame features through their standard X11 ICCCM properties! Check out “ClassX11ManagerMixin”, which is what it sounds like. It’s mixed into FavoriteBaseWindow, which can be redefined to the custom ClassTabBaseWindow supporting tabs and pie menus, shown in the above video, or any other kind of frame you want to wrap around X11 windows:

Source code:

It was a proof of concept, which we wanted to take a lot further by implementing a HyperCard-like user customizable persistent window manager with HyperLook. So users can edit and build their own custom window frames by copying, pasting and configuring scriptable components from object warehouses, edit and extend the user interfaces of running apps, and make high level task-oriented interfaces by composing widgets and apps into “cards”, “backgrounds”, “stacks” and optional network “clients”. But that’s not how things turned out. ;/

** 1991–12: Doctor Dobb’s Journal Cover Article, UI Issue: The Design and Implementation of Pie Menus

DDJ Article
The Design and Implementation of Pie Menus.
By Don Hopkins. Dr. Dobb’s Journal, Dec. 1991. Lead article, user interface issue.

The Design and Implementation of Pie Menus
They’re Fast, Easy, and Self-Revealing.
Originally published in Dr. Dobb’s Journal, Dec. 1991.


** 1992–02: Developed HyperLook for NeWS at the Turing Institute

Integrated TNT Pie Menus.
User Definable Pie Menus.
Created property sheet for defining and customizing trees of pie menus.
Text Editor for Indented Nested Menu Outline.
Use pie menus for HyperLook SimCity.

Talking pie menus in SimCity for HyperLook. I ported SimCity to
Unix, reimplementing the user interface using the HyperLook
environment on NeWS, a product that I was concurrently developing
at the Turing Institute in Glasgow with Arthur van Hoff. SimCity
for HyperLook was a really fun project to work on, but it’s hard
to describe in words, and you really have to see it to believe it.
I used the TNT pie menus for selecting city editing tools, a task
that you do all the time when editing the map. They spoke the name
of the selected tool, so you knew you had the right tool even if
you flicked the mouse so fast that the pie menu wasn’t displayed.

** 1992–02: Developed SimCity for HyperLook on NeWS

First HyperLook for NeWS
Later TCL/Tk for X11
Audio Feedback
Subliminal Gesture Ahead Feedback (aaah!)
Totem Pole Command Palette Legend

SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))

HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!


HyperLook Demo

Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript, running on a SPARCstation 2. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.


** 1992–10: Multi Player SimCity for TCL/Tk on X11

Started porting SimCity to X11 while working for Brad Myers at CMU.

Shaped Windows
Audio Feedback
Multi Player

The TCL/Tk pie menu widget. I accidentally ported the HyperLook. version of SimCity to X11, making it multi player in the process, using the TCL/Tk toolkit, which was the only X11 toolkit that didn’t suck. I needed some fancy looking graphical pie menus, so I made a TCL/Tk pie menu widget, whose window shape could be shrink-wrapped around iconic labels. The source code is available here: tkpie.tar.gz. I recorded an X11 SimCity demo, showing pie menus in action. SimCity for X11 won a “best product of 1992” award from Unix World!

X11 SimCity Demo

Demo of Pie Menus in SimCity for X11. Ported to Unix and demonstrated by Don Hopkins.


Multi Player SimCityNet for X11 on Linux

Demo of the latest optimized Linux version of Multi Player SimCity for X11. Ported to Unix, optimized for Linux and demonstrated by Don Hopkins.


Video Tape Transcript of Toronto Usenix Symposium Keynote Address


Hello, my name is Don Hopkins, and I ported SimCity to Unix on top of X11 using the TCL/Tk toolkit, and also on top of the NeWS window system using HyperLook. Unfortunately I can’t be in Toronto to demonstrate this stuff to you, but fortunately I have some video tapes that you can see that demonstrate the whole system.

** 1992–10: “piewm” for X11

Developed an X11 ICCCM “piewm” pie menu window manger based on
“tvtwm” while working for Brad at CMU.

The “piewm” X11 window manager with pie menus. When I was a
research programmer at CMU, faced with using X11, I realized that
I needed pie menus to help me move my windows around, so I went
shopping around for a reasonable window manager, and since there
weren’t any, I choose the least unreasonable one at the time,
“tvtwm”, and hacked it up with an updated version of the old X10
“uwm” pie menus, and called it “piewm”.

** 1993–04–24: Multi Player SimCity at InterCHI ’93 Interactive Experience

Exhibited Multi Player SimCity at the “Interactive Experience” at
the InterCHI ’93 conference in Amsterdam. Set up a network of two
SGI Indigi, and gave hands on demonstrations of an early version
the collaborative game during the conference.

** 1993–06–15: Gave “Self Revealing Gesture Interfaces” at “New Paradigms for Using Computers” workshop at IBM Almaden Research Center

Presented a talk and led a discussion about “Self Revealing Gesture
Interfaces,” at the “New Paradigms for Using Computers” workshop at
IBM Almaden Research Center, and at Interval Research Corporation.
Video tape available on request.


Don Hopkins and Donald Norman at IBM Almaden’s “New Paradigms for Using Computers” workshop


Talks by Don Hopkins and Donald Norman at IBM Almaden’s “New Paradigms for Using Computers” workshop. Organized and introduced by Ted Selker.

Talks and demonstrations by Don Hopkins and Don Norman.

Norman: “And then when we saw SimCity, we saw how the pop-up menu that they were doing used pie menus, made it very easy to quickly select the various tools we needed to add to the streets and bulldoze out fires, and change the voting laws, etc. Somehow I thought this was a brilliant solution to the wrong problems. Yes it was much easier to now to plug in little segments of city or put wires in or bulldoze out the fires. But why were fires there in the first place? Along the way, we had a nuclear meltdown. He said “Oops! Nuclear meltdown!” and went merrily on his way.”

Hopkins: “Linear menus caused the meltdown. But the round menus put the fires out.”

Norman: “What caused the meltdown?”

Hopkins: “It was the linear menus.”

Norman: “The linear menus?”

Hopkins: “The traditional pull down menus caused the meltdown.”

Norman: “Don’t you think a major cause of the meltdown was having a nuclear power plant in the middle of the city?”


Hopkins: “The good thing about the pie menus is that they make it really easy to build a city really fast without thinking about it.”


Hopkins: “Don’t laugh! I’ve been living in Northern Virginia!”

Norman: “Ok. Isn’t the whole point of SimCity how you think? The whole point of SimCity is that you learn the various complexities of controlling a city.”

** 1994–07–07: Multi Player SimCity at The Electric Carnival at Lollapalooza

Demonstrated Multi Player SimCity, the Midi Zoo, and Bounce visual programming language at the Electric Carnival at Lollapalooza, in Colorado and Mountain View. Sponsored by Paul Allen’s Interval Research Corporation.


** 1995: ScriptX Pie Menus

The ScriptX pie menu. I worked at Kaleida and wrote all kinds of stuff in ScriptX, so of course one of those things was a pie menu. I used it in the DreamScape demo.

** 1995–05–11: DreamScape for ScriptX

1995 Apple World Wide Developers Conference Kaleida Labs ScriptX Demo by Don Hopkins.

Demo by Don Hopkins of DreamScape on Kaleida Labs ScriptX presented at
the 1995 Apple World Wide Developer Conference.


** 1997–07: Scientific American Article: Taking Computers to Task


“It’s time to get angry about the quality of user interfaces,” exclaims Ben Shneiderman, head of the Human-Computer Interaction Laboratory at the University of Maryland.

“The public doesn’t understand what they could have had by now,” agrees Bruce Tognazzini, a designer who helped to develop the original Macintosh interface.

They and others argue that applying human-factors research to existing software technology could make workplace computer systems dramatically more productive, easier to use and cheaper to support.


Four Innovations That (Might) Improve Work: #2: Pie Menus: These arrange command options as sectors in a circle instead of segments on a bar. “They are 30 percent faster and have half the error rates of menu bars,” Shneiderman says.

“We remember angles much better than distances,” explains Ted Selker of the IBM Almaden Research Center in San Jose, Calif. “So pie menus allow you to make choices much more rapidly, relying on muscle memory.”

These arrange command options as sectors in a circle instead of segments on a bar. “They are 30 percent faster and have half the error rates of menu bars,” Shneiderman says.

** 1997–01: The Sims at Maxis

Started working at Maxis on The Sims with Will Wright.

Eventually released in March 2000.

Pie Menus for Controlling Characters
Character’s Head in Menu Center
Transparent Desaturated Feathered Shadow
Linear Overflow Items

The Sims Pie Menus Transcript


The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo Video

This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.


Demo of The Sims Transmogrifier, RugOMatic, ShowNTell, Simplifier and Slice City.

A demonstration of The Sims Transmogrifier, RugOMatic, ShowNTell, Simplifier, and Slice City. By Don Hopkins, Lush Creations.


Dumbold Voting Machine for The Sims


** 1997–07–21: OLE/ActiveX Pie Menus for Windows

Various Window Shapes
Linear Overflow Items
Design Time Editing with Property Sheets
XML Pie Menu Definitions

ActiveX pie menu component. I wrote a pie menu OLE component, now known as ActiveX. With Internet Explorer, you can put it on a web page, and program it in JavaScript or Visual Basic Script. Wheeee.

It has a property sheet that lets you type an indented outline of menu items into a multi line text editor. It’s much simpler to configure a nested tree of menus this way than trying to use some fancy tree editor with lots of buttons and scroll bars and text fields.

ActiveX Pie Menus

Demo of the free ActiveX Pie Menu Control, developed and demonstrated by Don Hopkins.


** 1998–10–13: Xerox PARC “Natural Selection” Pie Menu Talk

Pie menus appealed to Hopkins because they conform to the rule that the user’s attention should not be squandered. […] Hopkins uses pie menus because they take advantage of Fitts’ Law, which relates fast selection speed and low error rate to the pie menus’ large target size and small distance between selections.




** 1999–04–27: Mark Weiser Passed Away


“For thirty years most interface design, and most computer design, has been headed down the path of the “dramatic” machine. Its highest idea is to make a computer so exciting, so wonderful, so interesting, that we never want to be without it. A less-traveled path I call the “invisible”; its highest idea is to make a computer so imbedded, so fitting, so natural, that we use it without even thinking about it.”
-Mark Weiser

The philosopher of Palo Alto


Good tools, in light of Weiser’s legacy, are not just extensions of one’s mind or body. More profoundly, technologies at their best may serve as liaisons, linking each of us to subtleties in the dynamic, singular, living patch of earth we inhabit right now. The apex of Weiser’s prescient ambitions are still ahead of us, unreached. We have hit a point, though, where almost every “next big thing” in tech builds on his early blueprints. With each new app inspired by Pokémon Go and every 9-figure investment in startups like Magic Leap, mobile and wearable interface stand to become a little less like miniaturized desktops and a bit more like a digital looking glass we point toward the world around us.

The Computer for the 21st Century


Vol. 265, №3, SPECIAL ISSUE: Communications, Computers and Networks: How to Work, Play and Thrive in Cyberspace (SEPTEMBER 1991), pp. 94–105

“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.”
-Mark Weiser

The Computer for the 21st Century.

A time lapse doodle summarizing Mark Weiser’s seminal article The Computer for the 21st Century, published in 1991 in Scientific American.


Designing Calm Technology


It seems contradictory to say, in the face of frequent complaints about information overload, that more information could be encalming. It seems almost nonsensical to say that the way to become attuned to more information is to attend to it less. It is these apparently bizarre features that may account for why so few designs properly take into account center and periphery to achieve an increased sense of locatedness. But such designs are crucial. Once we are located in a world, the door is opened to social interactions among shared things in that world. As we learn to design calm technology, we will enrich not only our space of artifacts, but also our opportunities for being with other people. Thus may design of calm technology come to play a central role in a more humanly empowered twenty-first century.

** 2001–05–14: Demonstrated Multi Player SimCityNet with Pie Menus at MIT Media Lab Digital Life Meeting

Invited to the MIT Media Lab Digital Life meeting, during May 14–15, 2001, to give a presentation about “The Technology of Decisions” and a live demonstration of voting in Multi Player SimCityNet. Attended the symposium, participated in discussions, gave a talk and successful demo to the MIT Media Lab corporate sponsors, faculty and students, toured the lab to see their latest research, and met personally with many people working on interesting projects.

** 2001–07–29: JavaScript Pie Menus for Internet Explorer

Internet Explorer ActiveX Behavior Control
Implemented in JavaScript
Only for Internet Explorer
XSLT Transformations

JavaScript Pie Menus

Pie menus for JavaScript on Internet Explorer version 5, configured in XML, rendered with dynamic HTML, by Don Hopkins.


** 2001–12: ConnectedTV for Palm

I’ve developed a Palm application with pie menus for the touch screen: ConnectedTV turns your Palm into a universal IR remote control integrated with a personalized TV guide. It’s designed so you can use it with one hand, without a stylus. You can stroke the buttons with your finger, to invoke different commands in different directions. For example: stroke left and right to page to the previous and next program; stroke up to change the channel to the current program; stroke down to read more about the current program; stroke the ratings button up to add a program to your favorites list; stroke it down to add it to your bad programs filter.

** 2002–07–25: Game Programming GEMS 3: Natural Selection: The Evolution of Pie Menus

Natural Selection: The Evolution of Pie Menus
Don Hopkins
Pages 117–128


** 2003–03–10: OpenLaszlo Pie Menus for Flash, used for SimFaux, and later Micropolis (SimCity)

SimFaux Demo

A demonstration of SimFaux, a simulated interactive parody of Fox News.

Featuring pie menus to control live simulated characters with talking heads and waving hands, video playback, multiple windows, picture in picture, special effects, video mixing, and overlays.

Designed and implemented by Don Hopkins in 2006, written in OpenLaszlo, for the Flash player.


SimFaux 1.0 README

SimFaux is an interactive TV station simulator written in OpenLaszlo, by Don Hopkins, for the Huffington Post Contagious Festival.

It’s an open-ended framework for plugging together keyword tagged multimedia character simulations, video, text, quotes, surveys, interactive games and application.

It’s configured with XML files, so non-programmers can easily add characters, video and other types of content.

It includes tools for validating, processing and compressing the content into appropriate file formats.

SimFaux Interactive Network News Simulation

SimFaux now has WebCam Support and Simulated Internet Chat Room

Open Source SimFaux OpenLaszlo Code Now Available via Subversion

** 2003–08–06: Pie Menus for Controlling Robot Waiter


Stupid Fun Club’s “Servitude” One Minute Movie about Robot Servitude, written by Will Wright. Robot brain and personality simulation programmed by Don Hopkins.



Stupid Fun Club’s “Empathy” One Minute Movie about Robot Empathy,
written by Will Wright. Robot brain and personality simulation
programmed by Don Hopkins.


Software Development Magazine: Inside the Stupid Fun Club


** 2006–09–05: Pet Rock Remote Control with Pie Menus on PocketPC

Pet Rock Remote Control


** 2006–12: Open Sourcing SimCity

Open Sourcing SimCity, by Chaim Gingold

Excerpt from page 289–293 of “Play Design”, a dissertation submitted in partial satisfaction of the requirements for the degree of Doctor in Philosophy in Computer Science by Chaim Gingold.



[67] Pie menus play a critical role in The Sim’s user interface design, dovetailing perfectly with the object and AI architecture. Objects advertise verbs to character AI, so it is natural for the verbs to be arranged in a radial menu about objects. I can’t imagine an alternate design that would have had the same widespread usability, and therefore appeal, without them. It is difficult to imagine The Sims without pie menus.

** 2007–02–22: PyGTK for Python

Pie Menus for OLPC Sugar User Interface, in Python with GTK, Cairo and Pango modules.


Source code:

Tar file with source, demos and icons:

OLPC Sugar Pie Menu Discussion

Excerpts from the discussion on the OLPC Sugar developer discussion
list about pie menus for PyGTK and OLPC Sugar.


Implemented in Python, using GTK toolkit, Cairo graphics, Pango text.
Designed for OLPC Sugar, but usable by any PyGTK application.
Shows menu title and dynamic item description feedback.
Supports pure linear menus.
Supports hybrid linear overflow items.
Supports multiple ringed pie menus.
SimCity tool selection pie menus.

** 2007–11–10: EA has just announced OLPC SimCity!

From: Don Hopkins
Date: 11 November 2007
Subject: Re: SimCity for OLPC — introducing the players

EA has just announced OLPC SimCity!


I recorded a demo and put it up on YouTube, here:


OLPC SimCity Demo

A demonstration of OLPC SimCity running on the One Laptop Per Child
XO-1 laptop.


From: Alan Kay
To: Don Hopkins, OLPC
Date: 9 November 2007
Subject: SimCity for OLPC

Hi Don —

I’m writing to applaud you for your plans to reimplement SimCity for children on the OLPC.

My main complaint about this game has always been the rigidity, and sometimes stupidity, of its assumptions (counter crime with more police stations) and the opaqueness of its mechanism (children can’t find out what its actual assumptions are, see what they look like, or change them to try other systems dynamics).

So I have used SimCity as an example of an anti-ed environment despite all the awards it has won. It’s kind of an air-guitar environment. In the past, I tried to get Maxis to take the actual (great) educational possibilities more seriously, but to no avail.

Going to Python can help a few areas of this, but a better abstraction for the heart of Sim-City would be a way to show its rules/heuristics in a readable and writable form. Both of these could be stylized to put them in the child’s own thinking and doing world. For example, just the simple route of making a drag and drop scripting interface for Etoys allows children to make very readable and writeable scripts and helps the children concentrate on what they are trying to do. A carefully designed object system (that is filtered fro children) can expose the environment so they can really think about it.

I’m not at all suggesting that Etoys be used here, but I am suggesting that some deep design be done to come up with a “behavior modification interface” that allows real creativity on the part of the children. So it is much more than stringing black boxes together or having to deal with fragile procedurals.

I sense that you have some interests in making SimCity really a microworld for children’s learning and exploration from reading your webpage.

Children in 4th — 6th grade can do a lot here if they are given a good UI and tools. So, we could think of part of this project as a “pre-Python” UI.

Scalability and non-scalability of ideas are interesting. Rocky’s Boots is still one of the best ever games that provide profound learning experiences. The extension of this to Robot Odyssey didn’t work because the logic and wires programming didn’t scale well enough — the bang per effort dropped off precipitously. I was Chief Scientist at Atari at that time (Warren Robbinet worked for me) and I worked with TLC to try to get them to realize that something like Logo, or even better, a rule-based robot programming system, was needed. The failure of Robot Odyssey really pained me because I thought that the concept of this game was one of the best ever (still is). But it just needed a much better notion of how the children were going to program the robots. I think the same goes for SimCity.



** 2008–08–12: iLoci on iOS

iPhone app iLoci by Don Hopkins @ Mobile Dev Camp

A talk about iLoci, an iPhone app and server based on the Method of
Loci for constructing a Memory Palace, by Don Hopkins, presented at
Mobile Dev Camp in Amsterdam.


From: Don Hopkins at TomTom
To: Ben Cerveny at Stamen
Date: 28 August 2008
Subject: Hi Ben!

Haven’t heard from you in a while — just some regular pokes!

I just met with Pieter Geelen today, and he gave us the go-ahead to deploy the BitTorrent project I’ve been working on.

Basically I’ve been the one R in the R&D department, and now I’m moving to D! I got one of those pesky iPhones, and signed up for the developer program, signing away all my rights.

I have a great idea for an iPhone application I’m calling “iLoci”, based on some cool software called “DreamScape” that I made with ScriptX at Kaleida years ago, and some new ideas that takes advantage of the iPhone’s unique features.

So I’m teaching myself Objective C and iPhone programming by doing it, have made lots of progress, and now think a useful application is well within striking distance.

It’s somewhere near the intersection of the “Method of Loci”, a “Memory Palace”, iPhoto, notepad, voice recorder, mind map, visual Adventure/MUD map editor, and hypercard.

I’ve got the map editor working very nicely, supporting multi-touch, and letting you make and break links between “loci” by bumping their edges and corners together.

Now I will make a “first person” navigation mode where you go into a locus and flick around the two dimensional map the same way you can flick between photos in iPhoto, but with links in all 8 compass directions, so you can make a two-dimensional map of your photos, with attached names, descriptions, voice recordings, GPS coordinates, URLs, etc.

Here’s some stuff on DreamScape, the interactive multimedia plug-in
framework that I wrote in ScriptX around 1995, which inspired iLoci:

Design Philosophy:


DreamScape design example:

Crazy video of the DreamScape demo I gave at WWDC:

Crazy Video Transcript:

I hope to see you at Picnic! I’m considering buying a ticket, but it does cost a lot, and I will have to take days off from work to attend. Do you think there’s any way I can get in for a discount or free? Right now I’m sitting at the Norderlicht cafe, near the antique crane at NDSM, working on the code. It’s gotten dark and now there is a campfire burning. I’m looking forward to your next visit, so you can be here too!


** 2009–08–14: Micropolis: Constructionist Educational Open Source SimCity

Illustrated and edited transcript of the YouTube video playlist: HAR 2009: Lightning talks Friday. Videos of the talk at the end.


YouTube video playlist: HAR 2009: Lightning Talks: Micropolis: Constructionist Educational Open Source SimCity


Micropolis Online

Micropolis Online (SimCity) Web Demo

A demo of the open source Micropolis Online game (based on the original SimCity Classic source code from Maxis), running on a web server, written in C++ and Python, and displaying in a web browser, written in OpenLaszlo and JavaScript, running in the Flash player. Developed by Don Hopkins.


** 2010–04: Unity3D Pie Menus

Unity3D Pie Menu Demo

I’ve made a general purpose pie menu component in C# for Unity3D,
which supports text items, image items, and 3d object items too!


** 2010–04: MediaGraph on Unity3D

MediaGraph Music Navigation with Pie Menus Prototype developed for Will Wright’s Stupid Fun Club.

This is a demo of a user interface research prototype that I developed for Will Wright at the Stupid Fun Club. It includes pie menus, an editable map of music interconnected with roads, and cellular automata.


** 2012: PieCraft

Crazy Example: PieCraft

One idea I’ve had is to develop a game called “PieCraft”, that has user-editable pie menus that are first-order in-game player craftable artifacts.

World of Warcraft and its rich ecosystem of user interface extensions supports a wide range of player customizable user interfaces, because there are so many different commands, spells, buffs, weapons, armor, etc, and each role of each character of each player requires a totally different set of them in different situations.

The more casual MMPORG “Glitch” had bags that users could arrange in hierarchies and put their items inside, which were surfaced on the user interface as buttons they could press and objects they could drag in and out of the world and other bags. How well you arrange your items in WoW and Glitch had a significant effect on gameplay. PieCraft could take this further, to train players in user interface design literacy (much like “Code Hero” aims to train players in computer programming).

You could find empty or pre-populated pie menus in the world, pick them up and make them your own, and edit them by moving items around, putting them inside of other menus, and modifying them as you leveled up and earned more powerful menu editing skills and resources. The capacity and layout and allowed contents of some menus could be restricted, to constrain the ways you used them, forcing you to figure out which were your most important items, and giving them front row seats so they were easiest to select.

To put further pressure on players to design efficient menus, your menus could be vulnerable to attack from warriors or theft from pickpockets while they were popped up, and only be able to take a limited amount of damage (depending on if they were crafted from wood or diamond).

When hit hard enough, items could break loose and fall on the ground, or a whole slice or menu could break open like a piñata and spill all its items into the world. Then you (and your enemies) would have to scramble to pick up all the pieces!

The sense of urgency and vulnerability while the menu was popped up would compel you to “mouse ahead” to get through the menus quickly, and arrange your most important items so you could find and select them as quickly as possible.

It would reward you for successfully “mousing ahead” swiftly during combat, by avoiding damage from attack and loss from thieves, and awarding power-up points and experience.

** 2013: JavaScript Pie Menus (jQuery)


Source code:

** 2013: Pantomime on Unity3D


** 2016: VR Pie Menus for UnityJS in JavaScript on Unity3D

HyperJaunt 360 Degree Video Player for Google Cardboard with VR Pie Menus.

** 2017: High Fidelity VR Pie Menus

Source code:

** 2018: Canvas Pie Menus for UnityJS in JavaScript on Unity3D

Pie Menus drawn with JavaScript Canvas.

** The Future

Mobile, Multi Device, Ubiquitous Computing

Gesture, Multitouch

Tilt, Shake

Force Feedback



aQuery: Like jQuery for Accessibility