Pie-Menus in Mozilla

pronik writes "The Optimoz project on MozDev had two main development branches. While the first one, Mouse Gestures have been a success, we had to wait for the second, also very promising one: PieMenus. Now the wait is over! First implementation of PieMenus for Mozilla - RadialContext - is available for installation and testing!!!"

Comments

helpful animation

[sc00p18]

For those who don't already know what a "pie menu" is, here is a nice animation that may be helpful.

Uhh ok.

[jeti]

1. I'm the author. And in half an hour I'll
go surfing the atlantic coast of france for
14 days. That's one of the reasons I didn't
announce the project more widely. I can't
give immedeate support.

2. You can find the home page of the project
at www.gamemakers.de/mozilla/radialcontext .
Mozilla users can test the feel of the menu
by just right-clicking. Other users can have
a look at the overview of the functionality.

3. I have implemented the menu so that it can
wander with the mouse. That makes it possible
to move the mouse _exactly_ like you would do
with mouse gestures.

4. I've been using the menu exclusively for
months. It works wonderful once you've gotten
used to it. But the menu seems to be extremely
confusing on first try. I'm still working on that.
Please sit down calmly and try it out for a
minute. Don't give up after 20 seconds. It's
worth it.

6. In case my poor server gets slashdotted:
You can check out the .xpi archive from the
optimoz CVS, which has a web interface.

Going surfin,
Jens

Keyboard accelerators, mouse ahead and rehersal

[SimHacker]

Pie menus are better than linear menus with keyboard accelerators, because when you use a pie menu you're not familiar with, you're actually rehearsing the accelerated action.

Once you know the direction of the pie menu item you want, you can quickly select it without even looking at the screen, by mousing ahead. It's like using a keyboard accelerator, but without moving your hand from the mouse to the keyboard and back. The accelerated action is exactly the same as the unaccelerated action, only faster.

But selecting from a linear menu is not rehearsal for using the keyboard accelerator, because typing on the keyboard is a completely different action than selecting from the menu with the mouse, so you have twice as many actions to learn. To use the keyboard accelerator, you have to learn a completely new command that has nothing to do with the menu, and interrupts the flow of mouse actions.

It takes at least a second to move your hand between the mouse and keyboard and readjust, so it's important to provide keyboard equivalents for commands you'll be using while typing. I'm not suggesting removing keyboard accelerators when adding pie menus. Pie menus have their own built-in accelerators (mousing ahead without looking), that is extremely easy to use if you're already pointing and clicking with the mouse (which is the case with a game like The Sims, that doesn't use the keyboard very much).

Of course there's no reason why you couldn't assign traditional keyboard accelerators to individual pie menu items. The ActiveX pie menus have full support for keyboard navigation, so you can select and navigate and use all their features from the keyboard as well as the mouse.

Four item and eight item pie menus map very nicely to the arrow keys and numeric keypad. The ActiveX pie menus can automatically limit the maximum number of items per pie menu to eight, and let you page up and down through arbitrarily long menus in groups of eight items at a time, with the mouse or keyboard.

The newer JavaScript Pie Menus for Internet Explorer don't support keyboard navigation yet. Here's a description of many of the features of the older ActiveX pie menus, which are fancier but don't integrate with the web page as nicely or support dynamic HTML rendering and XML configuration like the newer Javascript pie menus.

-Don

Re:that useful?

[SimHacker]

Drop down menus can't support mouse-ahead as well as pie menus, because pie menus are based on direction, and you don't have to look at the screen to know reliably which direction you move the mouse.

So you can mouse ahead through a pie menus reliably, because it's the direction, not the distance that matters.

But with drop-down menus, the distance is what matters, and the direction is always the same: down (which suggests that alternative possibilities are being wasted: the other directions). It requires your full visual attention for the hand-eye feedback loop, to position the mouse over the correct target rectangle, merely as tall as the font height.

Selecting one small rectangle below your cursor requires much more attention and precision than selecting one large pie slice, each in a different direction.

Fitts' Law predicted it: the larger and closer the target, the faster and easier it is to hit. The experiments have proven it. But close-minded people are still stubbornly resistant to change, as it has always been and always will be.

-Don

Re:Why Pie Menus Can Work

[SimHacker]

Pie menus are useful in many but certainly not all situations. One major reason they haven't caught on is that most widely available window systems and toolkits don't offer pie menus as a default component, so it's orders of magnitude harder for developers to use pie menus than linear menus. And since most people are understaffed on a tight schedule, they use linear menus instead. I guess you would call that inertia.

Games are naturally one of the best ways to overcome this inertia, because it's acceptable to experiment with new user interface designs. Often, the whole user interface is part of the game, and designed and coded by hand instead of being built out of off-the-shelf components (like MFC or the Mac Toolbox).

The pie menus in The Sims required integrating the 2d overlay gui toolkit for the text labels, with the 3d character animation renderer for the head in the center, with real time image processing effects for the shadow. No off-the-shelf software could have possibly supported that, but it wasn't an issue since the entire user interface was custom designed and coded anyway.

Component software offers a way out of this catch-22 for other more normal applications than games, but it's only starting to catch on, and has its own host of problems and compatibility issues. Nobody can agree on which standards to use, and the standards that aren't obsolete and abandoned just keep changing faster than anyone can keep up.

It's impossible to design the perfect pie menu component for all applications, because every application has its own unique set of demands. But fortunately it's quite easy to code up special purpose custom pie menus for any particular application, since the algorithm is so simple, especially compared to gesture recognition.

But pie menus require the application designer to take a lot more care in arranging the menus, than just dumping a bunch of commands into linear menus. Menus with too many items are a bad idea in general, but pie menus with too many items are horrible. So if you're going to use pie menus with a large number of dynamically generated items, the user should be able to scroll through the menus in groups of 8 or so, instead of being faced with a giant pie menus with lots of extremely thin slices.

Pie menus are quite useful with systems that enable the user to easily customize their own menus. Maya is a great example of an extremely complex system with thousands of commands, that's used in many different specialized ideosynchratic ways by artist for hours on end.

So it's extremely important that the artists and tool developers be able to design and edit their own menus, so their own personal most commonly used commands are close at hand. Each user uses the same tool in extremely different ways, so they need to be able to customize the interface and build their own menus.

However, most users aren't trained in interface design, and it would not immediately occur to them to use an even number of items, or that left, right, up and down are faster to select than the diagonal directions. So it's good if the pie menu editor can automatically (unobtrusively and without animated paperclips) assist the user in designing easy-to-use pie menus.

For example, ActiveX pie menus support features like automatically raising the number of menu items up to 4 or 8 to keep them even, limiting the number of active items to 8 and allowing scrolling, and laying out the items in left-to-right, top-to-bottom reading order instead of circular clockwise or counterclockwise order. There are many other possibly useful features and heuristics to be discovered and implemented.

The most obviously beneficial applications of pie menus are the window manager and the browser, two applications that users struggle with constantly. Anything that can be done to make such commonly used interfaces quicker and easier will add up to a lot of saved effort over time.

In the late 80's, we developed a hypermedia browser and authoring tool named "HyperTies" which used pie menus and tabbed windows, at the University of Maryland Human Computer Interaction Lab, under the direction of Ben Shneiderman.

The authoring tool was based on UniPress Emacs with tabbed windows, implemented in NeWS. Emacs, the NeWS window manager and the HyperTIES browser all used pie menus. The browser had a pie menu with left and right for scrolling to the previous and next pages, up going to the index, and down to the table of contents. The pie menu on links let you get a defintion without following the link, follow the link in the current page, or open it up in another page (to the left or the right).

HyperTIES authors could define their own pie menus with links as well as scripts to control applets written in PostScript. For example, we had a text editor applet and a font selection pie menu that used the distance to smoothly select the font size. (This was years before Java, using Gosling's previous scripting language PostScript in NeWS, and his other previous scriptiong language MockLisp in Emacs).

The NeWS window manager with pie menus and tab windows was quite satisfying to use, so I redesigned and rewrote it several times in different versions of NeWS. Since Sun cancled NeWS it's not available any more. But here's a streaming Quicktime movie of a demo from around 1992, running on a SparcStation 2: Pie Menu Tab Window Demo.

-Don

Re:Steve Jobs thinks pie menus suck

[SimHacker]

Under the NeWS window system that I was demonstrating to Jobs, it was straightforward to replace the global default linear menu class with pie menus, so all applications used pie menus.

The challenge then is designing a pie menu component that doesn't suck, when you throw any old menu at it, without somebody redesigning each menu to work well as a pie.

One possible solution is user-editable menus, like Alias Maya supports. As far as I know, the NeXT and OS/X systems don't support allowing users to edit the user interface and menus at run-time, like HyperCard does for example.

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.

The HyperLook gui environment for NeWS supported fully editable user interfaces with pie menus at run-time, like HyperCard but with PostScript graphics and scripting, and a client/server architecture.

I used HyperLook to port SimCity to Unix, which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode.

Another possible solution is "smart" pie menu layout algorithms, user interface editors and wizards that automatically encourage or assist good user interface design (to whatever extent that is possible without annoying the user).

For example, the ActiveX pie menus can automatically raise the number of items to be even, limit the number of active items to 8, support scrolling, and reading order layout as well as circular layout. And you can optionally enable or disable any of those features through the property sheet. But the downside is that the property sheet looks like a 747 control panel.

-Don