Theta Menus Proposal and Pie Menu Designs - May 1986

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 persuing:

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.

Subject: circular menus
Date: Mon, 19 May 86 09:49:51 -0500
From: Mark Weiser <>

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 ("hjjkhj").

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

Date: Sun, 18 May 86 21:50:27 EDT
From: Don Hopkins <>
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 certian 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 occured, 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 certian 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 overlayed, offset in the direction of the item, by a certian 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 pallete. 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 whatever.

Incorporate audio feedback for the blind.

Date: Mon, 19 May 86 09:53:00 edt
From: (Mark Weiser)
Subject: theta-menus

I think they should have a maximum radius, outside of which nothing is selected. You can still return radii of selection within the max radius, but this allows easier user deselection.

Date: Mon, 19 May 86 12:26:59 EDT
From: Don Hopkins <>
Subject: theta-menus

Other uses...

-Knob metaphore. Use anywhere you'd have a knob that you'd turn like a knob. Possibly you could have a knob. Move where you want it to point.

-Inputting vectors.

A good first step would be to implement it under the X window system. (3 more exams to go ...)


Date: Thu, 29 May 86 18:05:59 EDT
From: Ben Shneiderman <>
Subject: theta menus

I finally got around to reading your preliminary ideas about theta menus and like the idea very much. I do not know of anything 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

Date: Wed, 24 Sep 86 15:26:52 EDT
From: (Mark Weiser)
Subject: thoughts on locating pies.

Pies are easy to locate in polar coordinates, as easy as squares are in rectangular coordinates. Just two or three comparisons, or maybe even a hash, can point to the right pie. You used something like this initially, when you were still computing arctan's, correct? And you dropped it because arctan's were too expensive.

Why not look the arctan's up in a table? It can't have more than 1152 entries, or around 4k bytes or less, which is tiny.

Another option might be to invent some kind of crazy hash function which is likely, but not guaranteed, to go directly from rectangular to the index of the appropriate pie. I don't have one right off hand...

Date: Wed, 24 Sep 86 15:36:31 EDT
From: (Mark Weiser)
Subject: kind of a hash

Take the pi-relative coordinates of the cursor. These are x and y values between -1152 and +1152. Normalize by adding 1152 to each, divide x by y, (giving an integer between 1 and 2304), and then divide that by 100. The result is a hash between 0 and 23 to give a first approximation of which pi is being pointed to.

Date: Fri, 26 Sep 86 06:25:26 EDT
From: Don Hopkins <>
Subject: why 4 quadrants + slope?

More bullshit terminology:
Pie Menus are built up of Slices.

Assuming 0 <= angle < 360 points from the menu center to the mouse, the mouse's quadrant is (angle div 90), and the slope is tan(angle mod 90). So the angle is 90 * quadrant + arctan(slope). The slope is more convenient for tracking the mouse when you know its x and y offset from the menu center. You look at the directions of the offsets to get the quadrant, and get the slope by dividing. The angle in degrees is useful when setting up the menu and drawing the selections. When the menu is initialized, the slices' angles (both boundaries, and the center) should be recorded, as well as the slope and quadrant calculated for the boundaries (the previous boundary should have already been calculated for all but the first slice, so don't recalculate it unless you just want to waste time). All that information should be easily and inexpensivly available.

You could have static pie menus: a region of the screen has a picture of the menu, and mousing down and up in it invokes the slice associated with the angle between a mouse down and mouse up events, without popping anything up.

Another way you might define the slice selected is: the slice in the direction of the last mouse movement (or maybe some function of the last n movements). Perhaps I should hack that up and see how it feels. It does not have some of the advantages the other definition has, such as finer control as you move out further. You do however change the slice selected immediatly after you change the mouse direction, instead of when you get move into its wedge. It might be useful for certain things. (Possibly static pie menus.)

The Macintosh, just to name one example, has mouse sensative turds along the top of the screen, which invoke pull down menus. PieMenus must by able to elegantly handle menus that are invoked by mousing near the edge of the screen... More thought has to be done on that. Warping to the menu center, wherever that is after the menu has been forced onto the screen, seem to be the best solution. I wallowed all through the X sources in search of the mouse warping bug that I described, but can't find it. It may be my uwm code that's the problem, but it seems OK upon close inspection. Maybe a good rewriting would do it some good.

When the mouse has moved in a complete circle in either direction, the menu being displayed could change. So you could "wind" the menu in either direction by "cranking" the mouse around in a circle (not necessarily around the menu center). You consider a circle to have been completed when theta (the direction from the mouse's previous to its current point) crosses zero-crossing-theta, the value of theta just after the last zero crossing of delta-theta (the angle formed between the last two points the mouse was tracked at and its current point). The direction of the circle is determined by the sign of delta-theta (since the last zero crossing). I can see how the algorithm could be frobbed to ignore circles with a curvature (delta-theta) above a certain number by resetting zero-crossing-theta when abs(delta-theta) is greater than some threshold (as well as when it crosses zero), or to be more tolerant of wishy-washy circles and random noise by defining delta-theta as some function of the last n points, or to reset zero-crossing theta when length of the last n mouse movements is below a threshold.


Date: Fri, 26 Sep 86 11:47:51 EDT
From: (Mark Weiser)
Subject: Re: why 4 quadrants + slope?

I don't understand the winding business.

Date: Fri, 26 Sep 86 17:19:42 EDT
From: Don Hopkins <>
Subject: winding business

Winding is a method to move between menus. Effectivly, when you move the mouse in a complete circle during menu selections, the menu changes. (In polar coordinates, the circle is perpindicular to all the rest of the slices.) Note that by the definition I gave, the circle you move the mouse in does not have to have the menu center inside of it. Possibly it could be defined such that it changed the menu when you were at the part of the circle in some specific direction (i.e. up, or in the direction of the 0th menu item). Upon putting some more thought into it, it seems somewhat complex, though. I am not sure how useful it would be. It might be simpler of it were defined as circles around the center of the menu. Perhaps that's something I should wait until all I have to do it write a couple of lines of PostScript to try out. It could be used to give you "stacks" of pie menus, like the stacks of pulldown menus provided by XMenu. I.E., a menu would have panes, which you choose by winding through the menu, and the panes have slices, which are choosen with a mouse up even. I am starting a cleaner rewrite that emulates the XMenu interface and incorperates some new ideas. I don't want to use too much of that code, though. It's gross and disgusting and very pulldown oriented.

One thing that's easy and useful to implement: when you add a slice to a menu, you give it a size parameter. When the menu is computed, all the slice sizes are added up, and each slice is made 360*size/total degrees of arc in size. So if they're all the same number, they will all be the same size. If you give each in 100*percentage of pie, and the total is 100, it will do the right thing. If you give them all in degrees of arc, and the total is 360, it will do the right thing.

I'm also implementing inactive slices, which can't be choosen. (i.e. return NO_SELECTION when choosen.)

You may look in brillig:~don/piemenu to see what I did on this last night. There are still several functions I'd like to add and change. Next step is to drink lots of tea and pour all the code in.


Date: Fri, 26 Sep 86 22:29:40 EDT
From: (Mark Weiser)
Subject: winding

I agree with you that it is not clear that winding is the right way to stack pies. Stacking is after all an alternative to what sun calls 'walking menus', and they are handled just fine in pies (in fact that is supposed to be one of pie's big wins).

Date: Wed, 1 Oct 86 19:01:52 EDT
From: Don Hopkins <>
Subject: Pie menu plans

There are a few things I want to get working:

1) A PostScript version of layered PieMenus, along with the mouse tracking and selection code.

2) A complete rewrite of pie menus in C, that does layered menus, with an interface that parallels XMenu, that can be plugged into various programs, like Emacs, and programs that use XMenu. (How about XTrek with PieMenus?) It would be based on some of the code I have in uwm, plus what I did in PostScript.

3) A version of uwm that uses the above package. It means ripping out all the code I put in and replacing it with calls to the layered PieMenu package. This should probably be done in cooperation with whatever Mike Gancarz (uwm's author) is doing with uwm. He said that the menu code was going to undergo lots of changes in the next version. Should I send him a copy of what I have now, and maybe the specs for what I'm working on?

I think these things would be best done more or less in the order listed. (Or rather in quazi-parallel, prioritized so that they get finished in that order.) I want to implement layered PieMenus in PostScript first because it much easier to prototype in than C. I don't have to worry about nearly as much irrelivant crap, and once I have the algorythms worked out, I can translate it all to C and have it working the way I want it. So I can have plus pretty printed PostScript menus, and uwm as it is now, for the SUG meeting. And the source code for the PostScript menus can be plugged into SunDew at some point.

Where does the paper fit into all of this though? Well, I think I should write an abstract or something pretty soon. I'd like to play around with layered menus a bit before sitting down and writing an outline for the paper. Does that sound right? At what point should I start scooping together the blobs of ideas I have collected and start sorting them out? Maybe I should sit down with Ben Shneiderman and talk about doing tests of humans and other life forms. Also, isn't it a good idea to have lots of references? Can you point me at things to read that are pertinant and would make good references?


Date: Fri, 3 Oct 86 10:37:57 EDT
From: Don Hopkins <>
Subject: New X

I installed a new version of X on ballast. It's got some fancier xterm programs, some nifty demos, and some bug fixes in the X server. One of the ones most of interest is mouse warping: it WORKS now! I changed puwm (what I seem to be calling the pie menu uwm now) so that Does The Right Thing near the edge of the screen. It's enormously easier to show than describe, but in a nutshell, it warps the mouse to the middle of the menu (which may have been moved to fit on the screen near the edge) plus any movement that has taken place since the mouse event and the mapping of the menu window. It feels SO much better. The problem with the mouse near the edge of the screen was really bugging me, and it works RIGHT now!

Date: Sat, 18 Oct 86 00:54:25 EDT
From: Don Hopkins <>
Subject: pie scroll bars

the bigger the radius, the more you scroll.

Date: Thu, 4 Sep 86 13:37:53 EDT
From: Don Hopkins <>
Subject: Independant Study

Can I stop by today, or tomorrow before 10:00am, to pick up the frobbie I need to get independant study credit for theta menus? BTW, Mitch Bradley suggested the name "Pie Menus". That name also has trigonometric connotations, but it sounds appetizing, instead of Greek. Plus lots of bad puns and disgustingly cute examples come to mind.


Date: Thu, 30 Oct 86 12:15:53 EST
From: Don Hopkins <>
Subject: pies, etc.

Yes, the definitions, problems, and solutions are notes for the paper. Is that the kind of stuff that should go into the paper? Do you think it's at the right level of detail? i.e., besides the fact that the English needs to be smoothed out a bit, how are the definitions? I am under the impression that it's good to give those sorts of defintions of what one is talking about. Are the problems I encountered pertinant? i.e., I tried to write about the problems that I had with just writing what I first thought would work, and my solutions to those problems that made pie menus behave in the way I thought "correct." Is it clear why those things were problems, and how my solutions solved them, and that they were reasonable solutions? I should give you a test drive, so you can tell me if they really work the way what I wrote made you think they work, and if that's really how they should work. To me, at this point, they feel like they finally do just the right thing. There are still a few rough corners in the implementation, and the internals are putrid, but the algorythm is down and the behavior correct. There are bells and whistles I want to have, such as saving the image of the menu so it only has to be drawn the first time, saving the bits on the screen under where the menu is drawn, and using arbitrary bitmaps for labels as well as (and in addition to) text, a more interesting way of highlighting, and lines radiating from the center delimiting the slices.


Date: Fri, 31 Oct 86 03:13:15 EST
From: Don Hopkins <>
Subject: getting more information out of your mouse

When traversing menus, after selecting a submenu with a mouse button down, move, mouse button up sequence, why require choices from the next menu to be choosen with the same button and key combination as the last menu? Why not use this information? Upon releasing the button to choose from the first menu, a preliminary menu could pop up, layered, maybe, with each layer corresponding to the menu you will invoke with with the correspinding key. (with the left key outside, and right most in the center, maybe.) You could then see where you could go from there, press the appropriate button for the appropriate catagory, and know which direction to move off into, before you did it. Abort by clicking down and up without moving, as usual. Shift keys could provide additional information, serving as adjectives. This is a way to layer the pie menus as deep as you have mouse buttons, without consuming the radius information, so it can still be used to modify the selection, also. It might be slick to not bother drawing the unlayered submenu after getting the mouse down event to choose a submenu if it looks like you're going to make a quick choice, i.e. if the mouse down event occurs in a different place than the last mouse up, and the mouse is traveling in the direction between the last mouse up and the this mouse down. In that case it could wait a small ammount of time for a mouse up event, while the mouse was traveling in the appropriate direction, and if no mouse up is received in that time, or the direction changes, then draw the single layer pie menu corresponding to the mouse button pressed down, at the location of that mouse down event. Can you say "M-x electric-pie-menu-mode"?


Date: Tue, 13 Jan 87 02:24:10 EST
From: Don Hopkins <>
Subject: Remember that strange idea I was trying to find words for
Cc:, unipress!

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


Date: Tue, 13 Jan 87 09:36:29 EST
From: (Mark Weiser)
Subject: dmu & dumdu

Are the two techniques just as applicable to normal menus, and just as compatible with each other, or is there something about pies that makes them work especially well?

Date: Tue, 13 Jan 87 14:06:31 EST
From: Don Hopkins <>
Subject: dmu & dumdu

They work with normal pull down menus, also. Provided you're not doing things like having one of the selections of the pulldown menu automatically selected by having the menu appear with the cursor over it. As long as the initial position of the menu is such that the mouse is over a region in which a mouse up would be a no-op.


Date: Thu, 5 Feb 87 02:43:58 est
From: rutgers!unipress! (Mike Gallaher)
To: rutgers!umcp-cs!
Subject: pi menu phase

It just occurred to me that you could use a pie menu to vary the phase of some waveform, from 0 to n*360 degrees. If you beat that against anonther phase of the same waveform, it would come into easily "hearable" phases at n*2 equally spaced radials, making it very easy to tune the value by ear. If you had a ray from the menu origin extend through the cursor to the edge of the screen, it would also make neat light saber noises as you waved it around.


Date: Thu, 5 Feb 87 13:23:21 EST
From: Ben Shneiderman <>
Subject: apple

Well I had a good time out at Apple tellin gthem 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 aprompt review). What do you guys think?

-- Ben

Date: Tue, 2 Dec 86 01:35:53 EST
From: (Don Hopkins)
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.

Date: Wed, 14 Jan 87 03:21:03 EST
From: Don Hopkins <>
To: unipress!, unipress!,,
Subject: An example of how a Pie Menu can encode spatial relationships

          Money  |  Arms
     Ayatollah --*-- President
       Hostages  |  Contras


Date: Tue, 4 Aug 87 16:57:46 EST
From: Don Hopkins <>
Subject: round menus

Terry Higgins
National Film Board of Canada
Pastel graphics editor used pie menus
Ran on SGI workstations.

Newsgroups:,, comp.sys.mac, comp.sys.amiga, comp.cog-eng
From: (Don Hopkins)
Date: 13 Jan 89 06:58:11 GMT

Subject: Re: What are menus?

Using linear pull down menus is like having to climb ladders to get where you're going. There's a more natural metaphore for round pie menus, though. I think of pie menus as rooms with doors leading off in different directions. Navigating a tree of nested pie menus is like running around a building or an adventure game. You can learn how to get to a certian selection, by remembering a spatial path from room to room. Then you just move the mouse along that path, clicking through each door, and you're there.

From: oxy! (Jeffrey George Bennington)
Date: 17 Jan 89 04:16:36 PST

Don -

That's probably the best real-world analogy for the pull-down menus I've heard as of yet. Any parallels with a "desk" are abstract, non-tangible metaphors, if you ask me. (That was put rather strangly, but it is rather late right now, please bear with me!)


From: (Rajiv Sarathy)
Date: Wed, 18-Jan-89 12:52:19 EST

Actually, this has been done by XEROX. It's called ROOMS, I think. I've never actually seen it, but the guy who wrote it (I forget his name) was up here, at the U of Toronto to give a talk on it. He showed some 35mm slides and it looks pretty cool.

From what I understand, it's available only on the Interlisp machine as of a few months ago with plans on porting it to SUN workstations (and now maybe even NeXT?).

It is almost exactly what Don wants to see in menus. You go from room to room, where each room has a different "desktop". Actually, each room has a different environment: different wallpaper, even!

When you want to take stuff from your graphics room to your wordprocessing room, you hold down a certain key.

To move from room to room, you click on the appropriate door. Each room leads to zero or more rooms, and a "backdoor" to get you back to the room where you came from.

The system can also create a map, I think, showing all the rooms and how they're connected.

It's much more impressive and natural than the Mac desktop, and probably even nextstep (I've never used nextstep, only seen a demo at the university's computer shop).


From: (Don Hopkins)
Date: 20 Jan 89 23:47:33 GMT

I've heard about Rooms, and I like the idea a lot. But what I'm talking about is pie menus. i.e. not full screen desktop layouts, but circular pop-up menus, as a metaphore for rooms. I think that the two metaphores are well matched and could be combined synergistically.

In the pie menu "room" metaphore, a "room" is a menu, and a "door" is a menu item.

You point to an object on the screen and click to pop up a pie menu of items relating to that object.

The pie menu pops up with the cursor in the middle of the room, with the doors arranged in a circle around the cursor, all leading off in different directions.

You go through a door by moving the cursor in its direction and clicking. Going through a door either completes the selection, causing some action to be performed on the object, or leads you to another room, popping up another pie submenu.

The important difference between pop-up pie menus and pull-down linear menus is that pie menus are based on direction, and linear menus are based on distance. With pie menus, the cursor motion necessary to make a selection is always small, and the area of the wedge shaped selection targets is large. You can indicate a direction without looking at the screen, and you get more and more angular precision as you move the cursor out further. Furthermore, they're non-proprietary, so nobody will sue you for implementing them!

Here are a couple of references to work we've done with pie menus. If you use the NeWS window system, I'd be glad to send you my public domain implementation of pie menus, and a window manager designed to use them efficiently, written in object oriented PostScript.


Directional Selection is Easy as Pie Menus!
By Don Hopkins
;login: The USENIX Association Newsletter
Volume 12, Number 5; September/October 1987; Page 31
Summary of the Work-in-Progress talk given at the 1987 Summer Usenix Conference in Phoenix.

A Comparative Analysis of Pie Menu Performance
By Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman
Proc. CHI'88 conference, Washington D.C.: available from ACM, NY.

From: (Don Hopkins)
Date: 13 Jan 89 08:03:49 GMT

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

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 certianly like to hear about other peoples' experiences with menu description languages.