Slashdot Log In
Pie-Menus in Mozilla
Posted by
Hemos
on Thu Aug 22, 2002 11:34 PM
from the get-the-new-features-on dept.
from the get-the-new-features-on dept.
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!!!"
This discussion has been archived.
No new comments can be posted.
Pie-Menus in Mozilla
|
Log In/Create an Account
| Top
| 373 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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
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
The Problem with Pie Menus (Score:5, Funny)
Maybe with ice cream on the side...
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:The Problem with Pie Menus (Score:4, Funny)
Options list (Score:4, Funny)
Select one from the following (thinking of the Sims, but we'll call GeekSims(TM)
- Order Pizza
- Fall asleep at computer desk
- /. another site into oblivion.
- Get the geek community to ping -f M$
Any other options are welcome.
Re:wow (Score:5, Insightful)
I can't really say that I find pie menus to be revolutionary or fantasically useful, but they are a million times better than the eight point font text links that I have to click on all the time. Luckily, Mozilla grabbed a Konqueror feature that allows you to override the minimum font size on a page. Right now, I have it set really high, but it's still a pain in the ass.
One day, you too will have bad eyesight, even if it takes another 20-30 years for you to experience the annoyances that I'm facing. I don't think you'll really appreciate alternative user interfaces until then. I know I didn't, back when I could sit down at my computer without wearing glasses.
Anyways, if we can dumb down user interfaces enough so that everything is self-evident, it will help more people get involved with computers. My six year old nephew gets confused rather easily when he sees too many options available to him. If he could browse the web as easily as he reads a book, I bet he'd be taking high school courses by the time he was ten.
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]
Re:helpful animation (Score:5, Funny)
Here my favorite "pie menu" animation
Great!!! (Score:4, Interesting)
It is EMENSELY powerful when you combine it with tabs. Using it to close tabs and surf back and forth through tabs is a breeze and really saves on the mouse wrist gemnastics.
This is a great tool! Thanks mozilla!
Derek
Re:Great!!! (Score:5, Funny)
The spelling fairy floats toward you and you wince as she whacks you over the head with her wand... but suddenly you realize how to spell "gymnastics."
The spelling fairy floats off into the distance, singing.
Gee thanks (Score:5, Insightful)
Slashdot really needs to start hosting its own mirrors for stories.
Excellent! (Score:4, Funny)
Pie menu advantages (Score:5, Interesting)
More info here [catalog.com].
Re:Pie menu advantages (Score:4, Interesting)
If you can't do it with your eyes shut, it isn't muscle memory. I have fantastic keyboard muscle memory, but even then it's clearly not distance memory. On a keyboard, I remember the hand positions -- because the base of my hand doesn't move as I touchtype, each key makes my finger curl to a different degree. When hitting keys that require me to move my hands -- function keys, for instance -- I have a great difficulty doing it without looking. After repetition, I can remember a small number of distances -- to the backspace key, for instance -- but it is very limited and requires constant reinforcement.
This all is true of mouse movements as well -- muscle memory for distance just sucks. How often do you make a mistake that you move your mouse in the wrong direction? The only time I've had that problem is with the iMac mice that were easy to hold sideways. How often do you move the mouse the wrong distance? I do that many times each day -- I went to edit this last sentence, and moved my mouse about two pixels below the text box, requiring a correction. Hell, I probably make those mistakes on at least 10% of my mousing -- though I suspect it's closer to 80%, when you consider that almost all mousing involves a large movement to the general area (which is inaccurate), and then a series of smaller corrections until you are within the target area.
UWM (Score:3)
I don't know if anyone remembers UWM [sourceforge.net] which was (and still is) a cool X window manager that uses pie menus instead of pop-ups.
:)
It doesn't seem to be in active development, but it is a rather minimal window manager so I doubt you'll have any problems using it.
It has some nice looking borders too.
Hmm...gives me memories. Downloading...
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
Gestures without the mystery (Score:5, Interesting)
That's a great way of putting it.
Which kind of input mechanism would you rather use for a touch screen control of a car: pie menus or graffiti?
I have never been very happy with gestures (like grafitti, or Black and White), because it's not easy for the user to predict how the computer is going to react.
But the pure directional model of pie menus is very easy to understand, work with and predict. It also implies that you can correct your selection "in flight" because it's based on the direction, instead of the path of the gesture. When you start making a gesture and mess up, there's no telling how the computer is going to interpret it, and no way to back out.
Gestures are great for some things, for example handwriting recognition and continuous analog input like musical direction. But pie menus are much more predictable for discrete selections, and useful where you don't want to make so many mistakes.
-Don
It's all about the usability... (Score:3, Interesting)
Also, pie menus will be advantageous because, unlike keyboard shortcuts, they will be displayed whenever called upon. Further, arrangements such as piemenu-Left to go back, piemenu-Right to go forward, are intuitive.
Overall, this is a development in UI design that I'd like to see used more. I first saw it used in the extra software supplied with a Genius wheel mouse.
NWN! (Score:5, Interesting)
That brings up another good point, which is that from what I've seen none of the radial menu implementations (Moz's or his javascript ones) implement hotkeys, which for a lot of users (read: me) immensely improves speed. I didn't like NWN's radial menus at all, especially since they have a 9th zone in the middle, which is the 'close menu' or 'go back' function. That meant that you had to move the mouse a significant ways towards each icon, eliminating a lot of the speed gain. Then I found out that the keys on the Number Pad were hotkeys for each of the 8 directions (with 5 being a hotkey for the center zone, and 0 being a hotkey to popup the radial for your character.) After that I loved them. Need your familiar? 0-4-1. Need rapid shot mode? 0-3-7-3. That saved all my quickslots for spells, potions, and other life-saving bits. I played most of that game with my right hand on the mouse and my left moving between asdf and the number pad.
Of course, I have no idea whether I'll ever find a 'real' use for being able to 10-key with the wrong hand, but you never know. :)
I can do this with lynx (Score:5, Funny)
<select name="pie">
<option value="Apple" selected>
<option value="Cherry">
<option value="Blueberry">
</select>
Mmm, blueberry.
Why Pie Menus Can Work (Score:5, Insightful)
One of the biggest advantages to pie menus is that you can learn the motions, and perform those actions automatically without visual feedback. This is very hard to achieve with drop-down menus.
However, in a large number of applications this is not particularly useful. I don't think pie menus are very useful when learning the application -- with a menu of items, it is fairly easy to scan through the descriptions. They are listed, top to bottom, and this is how we are used to reading (not top-left-right-bottom). It's also easy to skim a large number of menu items by dragging the mouse through the menubar. The only payoff for pie menus is later when you have memorized the action.
In most applications you won't have a chance to memorize the action. Most menu actions will only be performed very sporatically -- the user might only use the application once a week, or they might use a wide variety of actions which are too large to fit on a pie menu. My (wild) guess is the user has to use the particular action at least two times a day on average to learn the motions ("muscle memory").
One exception might be a word processor or a spreadsheet -- there's lots of repetitive tasks. However, in these situations keyboard shortcuts are superior -- the user is already using the keyboard, and moving from the keyboard to do gestures will not help them.
The other big exception is the browser and games. People have mentioned games already -- they are novel interfaces, and you are already expected to learn a lot of new rules to play any game, adding the pie menu interface isn't a difficult. With the obsessiveness of gaming, and the need to simplify oft-repeated actions, pie menus are a perfect fit.
Then there's browsers: when using a browser, there are a small set of actions that are repeated over and over (back, forward, close, etc). People also use a browser for long periods -- hours each day -- so they have time to learn even fairly complex actions. Lastly, they usually browse with the mouse, not the keyboard. Just like mouse scroll wheels are a useful alternative to the keyboard shortcuts (the arrow and page up/down keys), gestures can be a useful alternative to other keyboard shortcuts (Ctrl-Left, etc).
The other area where pie menus would seem very useful would be visual editing environments -- things like Photoshop or Blender -- where you are working largely with the mouse, and do so for long enough periods that you could build muscle memory for your most often used actions.
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
More pie meun demo movies (Score:5, Interesting)
Streaming: Pie Menu Tab Window Demo [lushcreations.tv].
Download: Pie Menu Tab Window Demo [lushcreations.tv].
Here are some earlier demos of tab windows and pie menus in UniPress Emacs and HyperTIES at the University of Maryland HCIL.
Streaming: NeMACS (NeWS Emacs) Demo [lushcreations.tv]
Download: NeMACS (NeWS Emacs) Demo [lushcreations.tv]
This is a HyperTIES demo, showing embeded graphical links with pop-up images.
Streaming: HyperTIES Demo [lushcreations.tv]
Download: HyperTIES Demo [lushcreations.tv]
Here's just the pie menus from "All The Widgets", CHI'90 Special Isssue #57 ACM SIGGRAPH Video Review. Tape produced and narrated by Brad Meyers.
Streaming: Just The Pie Menus from All The Widgets [lushcreations.tv]
Download: Just The Pie Menus from All The Widgets [lushcreations.tv]
-Don