For the last few months I’ve been sneaking the odd hour or two to hack on a little project which I’m recruiting a few elite hackers for. This is fittsmenu’ it is a pie menu widget written on top of gobject and gtk. This is however a pie menu with a twist quite literally.
Click to see the video (ogg theora)
You can download the source code: fittsmenu-0.1.tar.gz Hack on it, and enjoy… It is of course very very early, and needs a few minor glitches fixed properly. I need to add a proper destructor to the GtkWidget and figure out a few other bits of widget weirdness. There’s also a bug in the slice width calculation which has been driving me quite mad.
For the time being the makefiles aren’t finished because I’m about to mess around quite heavily with that stuff to prepare fittsmenu to come out of the closet and into its libsexier outfit.
So build it by;
tar -xvzf fittsmenu-0.1.tar.gz
cd fittsmenu-0.1
./configure
make
cd fittsmenu
./fittsmenu
Yes thats right, libsexier… The idea with libsexier is to add yet another widget library to gtk in the same vein as libsexy’s sterling work has. The difference between libsexier and libsexy is that all of the libsexier widgets will be cairo rendered custom widgets rather than composite widgets. The idea is to make them highly interactive visually appealing widgets with some extra blingyness. Currently I have plans for the following widgets other than fittsmenu
- Dock menu – a gtk menu derivative using the integral scale function of the OSX dock
- Smooth scrolling line graph, to consolidate some of the duplicated effort in a themable way (gnome-system-monitor, gnome-power-manager for example)
- Other graphs and charts pie, bar etc…
- Icon hint widget, a popup widget which simply takes an icon at x,y position and scales it up or down while fading it out. This is similar to the OSX application launch animation.
- A few other surprises I’d like to keep that way for now…
UPDATES
- With thanks to Rob Taylor of codethink there is now a gitrepo of libsexier and the autotools stuff is getting fixed up.
- Forgot to mention that tooltips/icon labels will be shown when hovering over the icons in the centre of menu when bug 43706 is fixed.
- As a few people have pointed out, fittsmenu isn’t always an ideal replacement for every context menu, however it is something that drawing applications could benefit from, other situations could also benefit however it is all about getting the situation right rather than just blinging everything up for the sake of it. If anyone wants to chat with me about implementing fittsmenu in their app (Inkscape guys I’m looking at you) then please get in contact via email.
#1 by Bob on August 7th, 2007
Nice and smooth, keep up the good work. Very promising.
#2 by Alex Graveley on August 7th, 2007
Doesn’t having the menu items change location based on mouse movement defeat one of the main implications of Fitt’s law? Namely that predictable locations are much faster to reach than dynamic ones (especially once muscle memory kicks in)?
#3 by Karl Lattimer on August 7th, 2007
The predictability aspect is still there, in that the menu always opens in the same configuration, the counter rotation is there to decrease distance and therefore the time to the next target if the user changes their mind on moves slightly one way or the other, or even dramatically, therefore it still conforms to fitts law.
Its pretty much a circlular dock menu in that respect. Also the counter rotation helps with using the pie menu near screen edges.
#4 by Andrew Sayman on August 7th, 2007
I tend to agree with Alex on this one. While it may or may not conform to Fitt’s law, it is harder to navigate when the location of the icons changes. By changing the location if I happen to move radially, I can’t accurately lock on to my next target.
For example, if I however to an icon in the bottom left, and then realize I need the icon in the top left, the top left icon will change locations if I try to move immediately to it. While the rotation may decrease the literal distance between my mouse and the desired icon, it increases the amount of time I must spend overall by requiring radial motion locked to the chosen rotation speed rather than simply moving to the new icon.
I suspect you’ll see this distortion if, rather than browsing the pie menu, you decide to jump between two icons that are one or two apart. Doing that accurately and quickly seems like a chore.
#5 by Kevin on August 7th, 2007
This menu would be awesome in GIMP. The menu could replace the toolbox and just appear centered around the mouse cursor via some keyboard accelerator. Just imagine if the pie slices take up a larger percentage of space the more a tool is used after several editing sessions. SWEET!!!
#6 by Alex Graveley on August 7th, 2007
@Karl: That’s interesting. Can you point me at some of the UI research you are basing your comment on? My understanding of Fitts seems to contradict what you’re saying.
#7 by Karl Lattimer on August 8th, 2007
@Alex: I’ve based the design on my own research regarding pie menus, but just to clarify some of the implications of fitts law.
“It describes untrained movements, not movements that are executed after months or years of practice”
“Pie menu items typically are selected faster and have a lower error rate than linear menu items, for two reasons: because pie menu items are all the same, small distance from the centre of the menu;”
– good ol wikipedia
Also reducing the law to the simplest description, the time to a target is a function of the size and distance to the target.
In the same way Apple exploit the changing distance (and size) in the dock menu, I have exploited this in fittsmenu.
You seem to be bringing up the same argument as mentioned in number 4 of this analysis of the OSX dock
http://www.asktog.com/columns/044top10docksucks.html
and although I agree with it in some respects, I also disagree believing that something visually stimulating is preferable to something which is proven to cause RSI. For instance fittsmenu is appropriate in situations like the one mentioned by Kevin, where designers are having to make repetitive dramatic movements to acquire the target of the toolbox to change tools.
#8 by Chris Cunningham on August 8th, 2007
Alex, Fitts’s Law doesn’t say anything about positioning or muscle memory. All it does is link time to hit a widget with size and distance. If the widget is getting closer and it stays the same size, Fitts says you’ll hit it faster.
Karl: this looks Awesome! Also, this grey-on-white editbox text is unreadable. Any chance of using gold ol’ black-on-white?
– Chris
#9 by Karl Lattimer on August 8th, 2007
@Chris: Thanks for adding to the fitts menu debate! funnily enough I don’t comment often on my own blog but point taken. I noticed it myself last night and was going to fix it anyway, the theme just came this way (which is totally no excuse).
#10 by Hylke on August 8th, 2007
Very nice! I hope more applications will use radial menu’s when it’s complete. Very handy in graphical drawing applications.
#11 by toshok on August 8th, 2007
Alex may have been slightly off by saying it was fitt’s law that your menu violates, but he’s right in that the spirit of that line of thought is indeed violated. Fitt’s law only holds when objects are stationary and the user must move to them, so saying your menu upholds it isn’t quite right either.
There’s also the derivation of Fitt’s law (mentioned on that same wikipedia entry): Accot-Zhai steering law, which draws a parallel between navigating through cascading menus on a display and travelling through a tunnel.
it has a wonderful passage here:
” \frac{ds}{dT} = \frac{W(s)}{b}
which says that the instantaneous speed of the user is proportional to the width of the tunnel. This makes intuitive sense if we consider the analogous task of driving a car down a road: the wider the road, the faster we can drive and still stay on the road, even if there are curves in the road.”
Like the passage says, it makes intuitive sense. I would argue that it also makes intuitive sense that the instantaneous speed of the user is inversely proportional to the amount the tunnel moves. Sure, they may have less distance to travel with the mouse, but that doesn’t mean it’ll be any faster (or easier) to hit their desired target.
#12 by Karl Lattimer on August 9th, 2007
@toshok, after reading quite a bit of research on the subject of fitts’ law with moving targets I found two over all implications of using moving targets in a menu.
1, If the moving target is moving randomly or in a predictable way but away from the cursor, the time to acquire the target becomes erratic and the index of ease goes up dramatically. (Chasing cats)
2, If the moving target is moving toward the cursor the time to acquire the target decreases as long as the user is conscious of direction and the target they are reaching for. (reunited with a lover)
Don’t you think that if moving and scaling targets were a problem apple would have never used the dock? In all seriousness I think their interaction experts would have made it a big no no.
Your analogy isn’t even similar also, if you were to apply the analogy, the truth of it is that you are decreasing the length of the road. However this isn’t anything to do with steering, as the menu movement is in an arc (optimal movement of the wrist, least strain). Accot-Zhai steering law only really applies to cascading menus, where CORNERS are involved.
#13 by Alex Graveley on August 10th, 2007
In thinking a little more about this… I bet the menu would be less disorienting and faster if instead of rotating towards the user’s direction of movement, if the pie wedges stayed in the same position, but the angle and the radius of each piece were to increase proportionally to “how selected” it was.
This would very closely mirror the interaction of the OSX Dock, where approaching a target causes it, as well as closeby targets to grow larger and wider, in proportion to distance from the pointer.
Plus I think it would look wicked, a smoothly animated egg-like oval look as you extended deeper into a target. It’d also keep targets a bit more static so you could learn their positions. And the increased size would make it easier to see if you’re currently pointing to the right item.
Oh, and I’d make the pie pieces extend all the way to the center, or perhaps within just a few pixels of it. The utility of a pie menu is lessened if you have to travel ~20 pixels before you hit your first target (which is more than the height of at least one traditional menu item).
Something novel you might explore is to make the pie incomplete, taking up only the lower right 3/4 of a circle (in the case of right-handed pointers). Having the upper left 1/4 be open space would make it easier to dismiss an inadvertently opened pie menu.
Just food for thought
#14 by macat on August 11th, 2007
Beautiful! Grat.
#15 by Thilo Pfennig on August 11th, 2007
This looks very much like the ideas we had on GNOME Life wiki:
http://live.gnome.org/ScratchPad/CircularMenus
Maybe there is a chance that the ideas are combined? Would like to see this happen. BTW: I think that this is especially useful for children, people with disabilities and mbile devices where people dont use a keyboard.
#16 by toshok on August 11th, 2007
@Karl: at no point does the steering law say that it only works for corners – in its generalized form (again from the wikipedia page):
“In general, the path may have a complicated curvilinear shape (such as a spiral) with variable thickness W(s).
Simpler paths allow for mathematical simplifications of the general form of the law.”
so while a simpler form might be permissible in the case of constant width, the same law holds for all cases. In fact I’d argue that since youre pie shapes represent a tunnel with non-constant widths, they’d behave even less well for picking.
On the topic of apple’s dock, I don’t think it’s the *best* interaction approach, for a number of reasons. But one thing is certain – the effectively one dimensional scanning it provides seems far superior to the two dimensional scanning required for the rotating pie menu, especially considering there’s no root configuration in the pie menu (except when it’s first brought up.) That is – if I move the mouse out of the dock for some reason, everything is still where it was when I brought up the dock. The same is not true for the pie menu.
What happens if your attention is diverted while scanning the menu/dock? you turn to talk to a coworker or the phone rings. Say for argument’s sake you hit your mouse so the pointer is nowhere near the menu/dock.
When your focus returns to the screen, with a dock:
1) Locate your mouse pointer (wiggle mouse a bit, or use a cool compiz-like water effect, whatever)
2) Move mouse to the desired dock item location, which is always the same place.
With the pie menu:
1) Locate mouse pointer as above
2) Scan current pie menu configuration, since there’s no guarantee where things are
3) Move mouse to desired menu item
I’m not saying pie menus are bad – there’s plenty of literature that says they’re a good thing. All I’m saying is the rotating is bad. A rotating pie menu is *not* the same as (or anywhere near to) apple’s dock. Nor does it have all (or even many, I’d argue) of the benefits of pie menus.
Alex’s idea, with the menu items growing as the mouse approaches them (and presumably also shrinking the pies further away from the mouse) seems like a much better approach in terms of interaction, while simultaneously yielding cooler animation effects than simple rotation.
#17 by Octavian Ghergheli on March 8th, 2008
Yes, indeed, Alex is right, the dynamic locations have a slower approach..and this is important regarding muscle memory. Interresting topic.
#18 by çocuk oyunları on June 28th, 2008
that is beautiful thanks for
#19 by liam lattimer on November 14th, 2008
hi uncle karl just gonna say hi and hows it doing im fine still not in school but will be soon hopefully