Pie-Menus in Mozilla 373
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!!!"
Re:that useful? (Score:2, Informative)
Re:that useful?-Pie High. (Score:1, Informative)
Always a good place to go from the guy who's been advocating them for years.
Comment removed (Score:3, Informative)
helpful animation (Score:5, Informative)
For those who don't already know what a "pie menu" is, here is a nice animation that may be helpful. [berkeley.edu]
I don't think they were exactly pie menus (Score:2, Informative)
Uhh ok. (Score:5, Informative)
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
optimoz CVS, which has a web interface.
Going surfin,
Jens
RTFFAQ (Score:2, Informative)
Read it and weep, you whining bitches!
Keyboard accelerators, mouse ahead and rehersal (Score:5, Informative)
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 [piemenu.com] have full support for keyboard navigation [piemenu.com], 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 [piemenus.com] don't support keyboard navigation yet. Here's a description of many of the features of the older ActiveX pie menus [piemenus.com], 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
Evolution, not revolution. (Score:1, Informative)
There's no need for a rewrite. So much of the Mozilla interface is done on the fly from scripts - there's not much caching and there's absolutely no compilation of XUL. That'd improve the interface.
Integration issues and component technology (Score:3, Informative)
But it just wasn't tractable to implemented dynamic html rendering in the ActiveX control. It might have been possible to recursively embed an Internet Explorer ActiveX control, but it just wasn't worth going down that road.
Instead I turned the problem inside-out and reimplemented pie menus inside Explorer in JavaScript (as an IE-Windows-only dynamic html behavior component), so they could take full advantage of all of the browser's features, in a well-integrated, memory-efficient way.
Unfortunately, it's unlikely that Microsoft is going to support Dynamic HTML Behavior Components on the Mac version of Internet Explorer, and unlikely but not impossible that Mozilla will support them on any platform. It's a nice way to package and re-use components implemented in scripting languages like JavaScript or VBScript (or any other language).
I'm glad the Mozilla developers have implemented pie menus using their own component technology (Chrome). It would be nice if Mozilla could some day support DHTML components on all platforms (which would give it an advantage over IE), and also nice if IE could support Chrome components on all platforms. One of those scenarios is more likely than the other, though.
The JavaScript pie menus can't shape the window in arbitrary ways like the ActiveX pie menus do, because they're running inside of the browser window, without their own windows. But they're nicely integrated into the html rendering engine, so they can take advantage of all kinds of nice features like transparency, rendering parameterized Flash files, etc.
The pie menu tracking callbacks can change dynamic html properties as well as Flash object parameters, which works well because recent versions of Flash have been integrated with Internet Explorer's HTML renderer instead of being blocked off in its own window. So the browser can draw html content on top of flash content and vice-verce, and JavaScript pie menus can integrate them both.
I don't yet know how to Mozilla pie menus are integrated with the web page and drawing engine, but I trust they've done a good thing, and I'm looking forward to trying them it and learning how it works.
-Don
Re:that useful? (Score:5, Informative)
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:Ok, call me an idiot... (Score:2, Informative)
But you are right, it is a bug and the programmer (who ran out of my room one minute ago to go surfing) knows it.
bye
Martin
Steve Jobs thinks pie menus suck (Score:3, Informative)
He had just finally released the NeXT computer. This was his big debut after such a long wait (remember the "NeVR" t-shirts?). The NeXT Computer had the best user interface in the whole world. All other user interfaces sucked in comparison. And the NeXT didn't have pie menus, therefore pie menus sucked. If you can follow that train of thought outside of the reality distortion field.
I gotta hand it to Jobs. Once he makes a decision, he sticks with it -- you gotta give him that. As far as I know, NeXT in its current incarnation as Mac OS/X still doesn't have pie menus.
-Don
Re:Why Pie Menus Can Work (Score:5, Informative)
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 [lushcreations.tv].
-Don
Re:Steve Jobs thinks pie menus suck (Score:5, Informative)
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 [catalog.com] 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 [catalog.com], which used pie menus of course. Here's a deconstructionist screen snapshot of the SimCity user interface vandalized in edit mode [catalog.com].
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 [piemenu.com] 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 [piemenu.com] looks like a 747 control panel.
-Don
Re:Best implementation of pie menus (Score:3, Informative)
Not a bad implementation, but i'd still like to see something cleaner.. it's a lot of mouse travel to use a pie menu.