Response to my post about pie menus was overwhelming! There were way too many comments for me to reply to each one individually, so instead I’ll respond to the general ideas in follow-up posts.
I’ve put up a new and improved pie menu demo that solves some of the usability problems with the previous version. Although, given the shape, perhaps “Grid Menu” might be a more descriptive name for this new style.
This version solves the following problems that people pointed out in the previous version:
- It’s difficult to lay out text in pie wedges: this version uses squares. It’s still the case that every item is just a short movement in a unique direction from the starting point, so the benefits of the circular menu are still preserved.
- The number of items can grow without bound, but usability suffers with more than eight choices: this version can handle hierachical sub-menus (and sub-sub-menus). Try mousing over the item in the bottom-right of the menu to see this in action.
- Some items are unreachable if the pie menu is invoked near the edge of the screen: this version pushes the menu grid inward from the edge so that all items stay visible.
- Many people aren’t used to holding the mouse button down while navigating the menu: this version respects click-move-click style interaction in addition to click-drag-release style interaction.
I’ve also added the names and icons of some actual Ubiquity commands, just to make the demo look more like what you might see in an upcoming version of Ubiquity — if we decide to include it.
Still a problem: if the original menu is invoked too close to the bottom-right of the area, there is sometimes not room for the sub-menu or sub-sub-menu. I’ll need to come up with a smarter positioning algorithm in order to deal with this problem.
You can try out new demo here.
Not The User's Fault 
November 9, 2008 at 7:34 am
Is it too much to ask to make it work in Gecko 1.8 browsers?
November 9, 2008 at 8:04 am
Now, this look a lot better 🙂
November 9, 2008 at 9:21 am
Great and simple. However, is Canvas the right solution? How about customization or theming?
November 9, 2008 at 9:41 am
Hi Jono,
Interesting to see how you’ve taken the pie menu and adapted it. Agreed, it solves a few issues from before. I know it’s only a quick mock up, but if I could make a few comments:
– Right-clicking still activates the menu, which might be a problem if you wanted to actually perform an action on an underlying object (save, copy link, etc) – and that action wasn’t part of Ubiquity
– If you’ve activated the menu, but then move your mouse outside the menu (say you’re trying to click something else on the screen, for example), there is still an item selected
– I like how you’ve done the sub-menu implementation, it works quite done nicely besides the positioning problem as you mentioned; if it was to be implemented, maybe the item(s) with sub-menus could be highlighted a bit more – emphasise the ellipsis, or put a small graphic, I don’t know
I have to admit, I’m liking where you are going with this though.
Cheers
November 9, 2008 at 10:14 am
Nice! A suggestion after playing with this very briefly: it might make sense to make the area outside the actual square that selects an item not rectangular. Currently the area you must stay in to select an item straight up/down/left/right is much smaller than the area you must hit for the items at the corners, making the non-corner items harder to hit if you are moving the mouse pointer much further than the menu grid size (which is a reasonable thing to do when you know in what direction the item is).
This is especially noticable if I try to hit blindly (say) “Amazon” (which is the directly up menu from the bottom right menu. Currently if I drift just a little to the right I get “Youtube” instead (top right from the bottom right menu), and if I drift a little to the left I close the submenu and get a completely different item. This would work better (I think) if once you are outside the visual grid the (invisible) division between action areas follows the circular menu approach again (I hope you can figure out what I’m trying to say here, I really should draw a picture or something, it would be much easier to understand).
November 9, 2008 at 10:17 am
That’s freaky timing – just earlier today I was thinking “Hmm, what if it was a grid…”.
Not sure if I like the idea of some items in a sub-menu being 2 squares over (regardless of where on the screen it opens). Feels like it breaks one of the basic reasons for having that type of menu.
I assume a sub-sub-menu would be shown by hovering over an item in the sub-menu? If so, the screen is going to become cluttered very quickly. I’d like to see how it feels when opening a sub-menu hides the parent menu. Or perhaps reduces the parent menu’s opacity to 50% and hides the grandparent menu.
However, I’m not sure how that will interact with hovering to immediately open sub-menus. Most sub-menus elsewhere have a delay before opening (hover-intent).
November 9, 2008 at 11:57 am
With the sub-menu, why not make the the other menus slide out the way so that it appears under your cursor on a default item.
So if you choose ‘ Search…’ that menu then slides out the way, and the search sub-menu appears around the mouse pointer.
November 9, 2008 at 5:02 pm
I like the grid menu! I wouldn’t be able to keep more than 8 functions clear in my head anyways.
However, the submenu is not very happy:
1) Being punted around by the edge of the screen moves the physical pop-up location of the sub-menu, such that some mouse gestures are not the same if you click near the edge
2) Requires you to move not just in a direction but also a certain distance in the submenu (Amazon and Youtube are both horizontal)
3) Requires you to pause over “Search…” so that you don’t accidentally choose a random submenu item. (A result of #1 and #2)
Hence, I definitely have to Look to see which submenu item I’m choosing.
Echoing the comments above, how about:
1) Having the submenu appear as a grid centered over wherever the mouse is. (That way, even if you wander very far afield of the original grid, it will show up as long as you went in the right direction)
2) Have the submenu squares blocked out in such a way that choosing something requires switching direction. (So the bottom-right corner of the search submenu should be blank, or even a “return to main grid” option)
3) Distinguish between main grid menu and submenu. (Make one translucent, a diff. color, smaller, etc)
November 9, 2008 at 5:17 pm
I gotta say, I think you broke it.
A grid menu require much larger mouse movements than a pie … and it makes some (corner) items harder to select with a short gesture, and some (non corner) items harder to select with a long gesture!
On top of that, your point 3 means that the same “gesture” that I use to open the MAP, normally, suddenly opens “EMAIL” if I click too close to the left edge. That’s unforgivable in this sort of UI (especially since your concept of “edge” is limited by your control, instead of the screen or even the browser, so the user won’t know ahead of time when this is going to happen). You can ONLY move the menu if you can also move the mouse.
I think the first one was better. Have you looked at what EasyGestures did? http://easygestures.mozdev.org/ I’m a big fan of pie menus, but I have to say that their UI still stands out as one of the best implementations I’ve seen in a general-use (non game) environment.
They use icons to solve the problem of placing text, and then show the text in pop-out-panels if the user delays selecting (you could have an option to show it all the time, but I think the way they show it, off the sides, is excellent).
Another thing they do well (although they only have ONE of them) is submenus (at least, I think I got this idea from them) … the menu should show up with the mouse centered, and should have NO menu item which can be selected by continuing to move in the same direction. Then, if the user does keep moving their mouse in that direction, the menu can just move to keep the mouse in the center, and sub menu items can be selected by changing the direction of the mouse movement: Thus, selecting an item from the submenu can be a gesture which involves a “turn”. (ie: downright,upleft or downleft, left).
November 9, 2008 at 8:55 pm
Moving the sub-menu to different positions when close to the edge of the screen changes the gesture of the command.
November 9, 2008 at 9:22 pm
I like the radial context menu better because now, with the Grid Menu, you have items that are farther away (the corners). This Grid menu kind of defeats the whole original purpose of the Radial Menu.
November 10, 2008 at 12:25 am
As long as selection works (almost) the same way as for the radial menu once the mouse is outside the grid and the menu is not too huge (how huge is too huge will obviously depend on your monitor/mouse combo, so it might be nice if this was configurable) I don’t think this grid menu is harder to use.
When you are actually aiming for inside an item then both in the grid menu and in the previous round one all items are the same size, and in the grid menu they are still close to the same distance from the center (starting position of the cursor). I do not think the corner icons are harder to hit when you are actually aiming for inside the grid (sure, you pass over a non-corner item on the way there, but that’s not really an issue).
When you are aiming for a direction this menu currently has problems. When going for a direction you will in practice move the mouse further than necessary (say at *least* twice the radius of the (empty) inner item) to make sure you actually go far enough. With the original radial menu going much further than the radius of the menu was no problem. With this new one it is, because the area for the corner boxes is much larger than the area for the non-corner boxes. That is fixable. For the toplevel menu it is also not actually a huge deal in practice, I think, since moving sufficiently straight up/down/left/right is still doable (try radialcontext to see what I mean: in practice its up/down/left/right main actions work without you accidentally opening the submenus mapped to the diagonals often).
What does not really work for me currently (but that is possibly just because I’m used to radialcontext and would have to change my habits for this grid menu) is using a gesture to select an item from a submenu. With radialcontext that works nicely by moving quite a bit in the direction opening the submenu, then quite a bit in the direction of the action you want to select. Because of the way the radialcontext menu follows the mouse how large the individual moves are does not matter as long as they are quite a bit larger than the menu radius.
In this new grid menu I cannot do this blindly unless I memorize the *distance* between the starting point and the center of the child menu (the “google” item in this example). If I overshoot the google item moving straight up will give me youtube instead of amazon. The other non-corner items are similarly unreachable. Making the division line between items “radial” instead of “grid” once you’re outside the visible grid would help here, but I would still have to move up quite a lot once I am past “google”. radialcontext makes this easier because of how the menu follows the mouse cursor, so you never have to move the mouse very far to change the selected item.
Again, that’s just comparing it to radialcontext, which I am used to. Perhaps this grid menu does work once you are used to it.
November 10, 2008 at 3:32 am
Next time you come down to the University of Toronto, we should meet up with some of the founders of marking menus. There’s been some neat research on how people can habituate on gestures… it akin to skill learning, like writing. People do still write don’t they? 😉
November 10, 2008 at 7:15 am
Do you believe in accessibility? I am having great difficulty reading your site because of the narrow column of text. With my minimum font size (required so I can actually see the internet) I get about 5 words per line. Can you change #content from 400px to something like 30-40ems? that would give a reasonable line length regardless of font size.
November 11, 2008 at 8:28 am
Great Solution! I think, that sub-menu should provide a way to display correctly in a corner. I think, that we don’t need see options from previous menu, so we can display option from sub menu above a parent menu. The search button should appears in the same position as in parent menu(for ex. in the center of sub-menu, in the right corner if mouse is in the right corner). The menu name(ex. search) should have fixed position, so we can scroll the rest of items.
The best think is to show a patch above a menu and submenus, so we can simple navigate and know our position in some situations.
March 26, 2012 at 4:47 pm
[…] kicked off the lightning talks by presenting his explorations in the land of pie menus. This was followed by a presentation by Alex Peake on his new […]