This blog post is a hands-on experiment. If you have Firefox 3, before you read any further, please go to this page and try out the demo.

(Unfortunately, the demo will only work in Firefox 3.0 and later, because it uses some cutting-edge features of the Canvas object that aren’t supported in Internet Explorer, Safari, or older versions of Firefox. I believe strongly in presenting web content in a cross-browser compatible way, but sometimes for feature demos, requiring Firefox is unavoidable. This is Mozilla labs, after all.)

Anyway, the demo presented two different styles of pop-up menus and asked you to repeatedly select the same menu item.

Which menu style made the task easier? Why do you think that was?

A Brief History of Pie Menus

Pie menus are nothing new. Don Hopkins has been evangelizing them for decades. Mozilla has experimented with pie menus before, although (as far as I know) the experimentation hasn’t led to any core browser features.

Also, here’s Radial Context, an extension that replaces the Firefox context menu with a pie menu; unfortunately, it’s no longer actively maintained and is only compatible with Firefox versions 2.0 and older.

[UPDATE: Here is an updated version of the Radial Context extension that works with Firefox 3.]

Do you know of any good pie menu implementations for leading browsers? If so, please leave a link in the comments. For example, I know that Opera has mouse gestures, but does it have pie menus?

Fitts’ Law

The reason why pie menus are good has to do with Fitts’ Law, one of the most reliable theories in all of HCI, which has been empirically verified time and time again. Sadly, a lot of people who do UI design, even professionals, don’t know about this simple and useful formula:

where:

• T is the time taken to move a pointing device to a target. It’s a function of:
• a and b are constants, which depend on the hardware and the individual person using it, so they’re generally outside the control of UI designers.
• D is the distance from the starting point to the center of the target.
• W is the width of the target, in the direction of motion.

In other words: bigger things are easier to hit than smaller things, and closer things easier to hit than those farther away. (No duh, Sherlock!)

In a pie menu, Dis very low, because the pie slices are all adjacent to the starting point. And W (the width of the target) is correspondingly large, since each pie slice occupies the largest possible area. (In some implementations, the pie slice area effectively extends all the way to the edge of the screen, making W very large indeed.) Therefore Fitts’ Law predicts that the time to aquire the target in a pie menu should be minimal.

Habituable Mouse Gestures

But that’s not all. Besides Fitts’ Law, pie menus are good because of the habits they teach.

What are you doing with your hands when you select from a menu? You’re making a mouse gesture while holding down the mouse button.
We usually think of the menu that you see on the screen as a UI element, but here’s a different way to think about it: the mouse gesture IS the command. The menu on the screen is just visual feedback to help you find the right mouse gesture.

With a traditional list-style menu, the mouse gesture consists of moving downward by a certain distance. Choosing a different item means moving a different distance downward.

With a pie menu, the gesture consists of moving a certain direction. Choosing a different item means moving a different direction.

Gestures that vary by direction of movement are easier to distinguish, kinesthetically, than gestures that vary only by distance of movement. That means that the gestures involved in selecting from a pie menu are easier to perform without looking. And it’s always easier to form a habit around a UI interaction when it can be performed without looking.

A good user-interface is one that naturally teaches the user effective habits. And pie menus are an effortless way of learning efficient mouse gestures.

Pie Menus in Ubiquity

For a UI widget with so many advantages, pie menus are sorely underused. They’re used in computer games (The Sims being the best-selling current example), and they’re used in (shameless plug) Songza — click on the title of a song to see a pie menu.

But pie menus are conspicuously absent from most popular UI libraries and toolkits. They’re not in the Human Interface Guidelines of Mac, Windows, Gnome and KDE. Many UI designers don’t even know they exist. Sure, round things are a little harder to program than square things, since they tend to involve polar coordinate math, but it’s not that much extra effort.

I’m particularly interested in the possibility of using pie menus to replace the Ubiquity context menu. (Wait, Ubiquity has a context menu?) Yes, it does, but it’s not well-documented or widely-used. It’s also not very useful, since it’s currently a big, unweidly, unsorted, list of random commands which may or may not be applicable. It would be cool if right-clicking on some selected text — or an image or link, for that matter — resulted in a menu like this:

Not a Panacea

Just replacing a rectangular context menu with a pie menu doesn’t magically make everything better, though. In fact, it introduces a new set of problems that need to be solved.

One of the problems that we’d immediately face is the large number of Ubiquity commands available. At my count, there are no fewer than twenty built-in Ubiquity commands which can take arbitrary text for one or more of their arguments. That means that when we bring up a Ubiquity context menu on a text selection, we start at a baseline of twenty commands, before adding in third-party command subscriptions or specialized commands that can act on the particular data-type of the selection.

Even if we increase the specificity of commands and aggressively filter non-applicable commands out of the context menu, we’re still looking at a large and ever-growing set of commands.

Time for another demo. Try out the pie menu on this page in order to understand the usability problems that arise when there are too many items in a pie menu. (Basically, when the wedges get too small, you lose the benefit of being able to select one without looking at it.)

One approach to this problem is to allow a hierarchy of pie menus. For example, if we took the previous illustration as a starting point, then if the user mouses over the “Add to…” pie wedge, they might see a new subsidiary pie menu pop up with the list of “Add to…” subcommands. Like this:

(I don’t have an interactive demo for this yet, unfortunately. It involves a lot more programming than I wanted to do for this blog post.)

I think hierarchical pie menus will be a big step forward. But another problem still remains. To understand what it is, here is the third and last interactive demo. Give it a try.

Annoying, isn’t it?

If the number of items in the pie menu can change, then a given item will not always be in the same place. And if it’s not always in the same place, then you have to visually double-check the menu every time you use it. That means the habit-forming benefits of pie menus are lost.

And here’s the rub: the number of items in the Ubiquity context menu is guaranteed to change. Not only does the list of applicable commands vary depending on the type of content you have selected, but the total number of commands that Ubiquity knows can grow without bound as the user subscribes to third-party commands. There’s simply no way of fixing the number of items in the context menu.

I don’t have a good solution to this yet. I have some vague ideas about keeping the most-used items in the main pie menu, which has a fixed number of slices (perhaps eight?), while shunting the variable number of lesser-used commands off to a variable number of hierarchical sub-menus. But it’s very much an open question. As always, I would love to hear any suggestions and feedback you have.