Creating a Radial Menu in CSS | Hacker News Reader

Creating a Radial Menu in CSS

stackoverflow.com

331 pointsmsvan79 comments

As another commenter here notes, this is in fact a “radial menu.”

Terminology is important. Language loses power when we use words incorrectly, so please: Do not call this a “tooltip.” Tooltips are only ever displayed on hover (and disappear when the mouse leaves the described object — originally, the tool for which the tip was needed!)

This is also known as a radial menu, and has some great properties that make it better (faster) than a normal context menu.

You should be able to select an item from the menu in a single fast (distance insensitive) mouse gesture. Click down on the star, drag in the direction of an option, and release the mouse to select it. This way you can choose an option without having to stop after a certain distance of dragging, and you can memorize the different directions of frequently used commands.

This demo doesn't implement that behavior yet though - so while it looks cool this version is still missing the big benefit of this type of ui.

I think you'd find a majority of users would be confused by this, as cool as it sounds, the first time around. I cannot think of a single instance of a popular web application that uses a click and hold mechanic of any kind (not to be confused with dragging and dropping). People are used to clicking, not holding, meaning they might never see the required secondary action of moving the mouse over a new button.

You could of course add some kind of time delay, but then they would simply be clicking a second time to interact, and this defeats the entire purpose of the click and hold mechanic.

This is not to say I don't think you could train users to get used to this mechanic, but from a first-time user perspective, this still falls under "bad UX" in my book.

"I cannot think of a single instance of a popular web application that uses a click and hold mechanic of any kind."

* Scrollbar thumbs, Drag and drop (gmail attachments, google map streetview guy), Drag to reposition, Rubber band selection (everywhere)

* Drag blue dotas to modify text selection (iOS)

Drag and drop implies you're dragging one thing to another and then releasing. This is not the same as clicking, holding, and having something else you then have to move your cursor to appearing.

I should have been more specific. I cannot think of a single instance of a popular web application or site that uses a click and hold mechanic to navigate or edit.

Drop-down menus.

Dropdown menus are typically 'mouse-over and move mouse', not 'click-and-drag'

Combobox, then. They stay open once you click so you don't have to drag, but I've seen many users do the "click-and-drag" with it anyway.

The original mac menus: click, hold, drag mouse to option you want, release mouse. Still works like that now, but the Windows-style click-release-move-click works too.

Context menus are frequently touch-and-hold on touch devices.

Scrolling and paging by dragging and gesturing on an iPad or touchpad.

Have you ever played "The Sims"?

>I think you'd find a majority of users would be confused by this, as cool as it sounds, the first time around.

It doesn't matter if they are confused "the first time around" as long as they can do their job better and faster the second and nth time around.

That's how UI progresses -- not just by self-evident things, but also by people learning new idioms.

>I cannot think of a single instance of a popular web application that uses a click and hold mechanic of any kind.

The "kudos" button on Subtle is "hover and hold". I'm sure there are others.

This is completely subjective, but I'd prefer to design interactions around what I know my users are already comfortable with. My goal is to enable my users to get to their end goal with the least amount of friction as possible.

Why would I train a user to learn something new when the method in the OP achieves the exact same result, without a learning curve?

All I can see improving with the click, hold, and release method is enhanced "cool factor".

>This is completely subjective, but I'd prefer to design interactions around what I know my users are already comfortable with. My goal is to enable my users to get to their end goal with the least amount of friction as possible.

Well, there's a compromise, though, between:

(a) "designing interactions around what I know my users are already comfortable with"

(b) "enabling users to get to their end goal with the least amount of friction as possible"

in all cases where an initial unfamiliarity with a new idiom lowers the friction for hundreds of subsequent uses.

As a crude example, consider "undo" in a painting application. Say the user wants to erase all he did up to this point. We could let the artists work the way they are "already familiar with" (paint on top to cover their mistakes, or use some eraser tool to delete the whole thing part by part).

But by having them learn the concept of "undo", they could achieve the same effect faster. And even better if the learned the concept of "history" (jumping to arbitrary undo states).

(Now in those cases, all the above options can also be present at all times -- so the users don't have to give up one for another. But there are other cases where this is not the case, and you have to decide upon the better but new way to design a control vs the old, clunkier, but familiar).

May I remind you that, once upon a time, all menus were click-and-hold?

(Okok, I'm not actually sure about either mac or xerox.)

Thought experiments aren't as reliable as controlled experiments for objectively measuring the speed and efficacy of user interfaces, and interviewing actual users for discovering subjective preferences.

We performed a controlled experiment in 1988 that compared eight item pie menus to linear menus, which showed that pie menus were significantly faster and had lower error rates than linear menus.

Users didn't have a problem with them in 1988, and probably won't now: "The most mouse naive users, while finding linear menus easier, tended to be better at pie menus and commented that with practice, they would probably be superior and in fact prefer the pie menus because of their speed and minimization of hand movement with the mouse. Not surprisingly, therefore, most of those preferring linear menus did not have a strong preference on the scaled subjective questionnaire."

An Empirical Comparison of Pie vs. Linear Menus

Jack Callahan, Don Hopkins, Mark Weiser () and Ben Shneiderman.

Computer Science Department University of Maryland College Park, Maryland 20742

() Computer Science Laboratory, Xerox PARC, Palo Alto, Calif. 94303.

Presented at ACM CHI'88 Conference, Washington DC, 1988.

http://www.donhopkins.com/drupal/node/100

The Design and Implementation of Pie Menus -- Dr. Dobb's Journal, Dec. 1991

There're Fast, Easy, and Self-Revealing.

Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue.

http://www.donhopkins.com/drupal/node/98

for an OS maybe. But one of the many rules of web UI is that "the user shouldn't have to learn a new UI by visiting your website"

And the corollary of that rule: "I want a pony too!!!"

More like a guideline.

If the new UI has great workflow benefits, then a user can learn it and use -- and it could be a competitive advantage in its favor.

The android camera app has this type of menu, you hold and then swipe to get the option that you want. (On the Nexus 4 at least)

As long as it is discoverable and doesn't interfere with other actions, it's perfectly fine. Also have in mind that "click & hold" is the ubiquitous swipe in touch interfaces.

Example: the iOS keyboard. You can touch+swipe a key to type an accented letter in a single gesture.

The camera app on the nexus 4 has the mechanic where you need to hold down and get a radial menu. It took me a while to figure it out at first.

You can just show the menu on mousedown and activate the choice on mouseup. This supports both the case where the user first clicks the menu button and then the choice element and the one where the user holds down the mouse button over the menu element and releases it over the choice element.

Maya (the 3D animation software) has had a radial menu with a gesture feature for as long as I can remember (4.0 I think). The beauty of it is that you can just use the menu slowly, or as you get familiar with the movements of your mouse (or stylus), just draw the movements and be done with it in a matter of seconds.

I've seen a friend of mine working on a detail model 7 years ago and he wasn't even thinking what he was doing. Just naturally drawing the path to the option he wanted (and god, the maya marking menu is damn full of options and context sensitive even) and boom, job done.

The ux for a Radial Menu (or also called a Pie Menu) is incredibly intuitive and allows for beginner and power user usage.

This is exactly what I meant about expert "stage 3" users, in my other comment above (below, wherever).

Typically, pie menus support both "click up, point, click down" browsing and "press down, drag, release" gestures.

Pie menus can support "click up" tracking compatibly with "press/drag/release" tracking, even allowing users to switch between both modes when browsing submenus.

This is important for supporting both novice and expert users, learnability, rehearsal and muscle memory.

You can divide the pie menu learning curve into three stages:

1) The first stage is how a new user typically uses it when they don't know the directions: click it up, look at the menu items, decide what you want, point at it, click it down. It requires lots of time, visual feedback, and mental attention, but it transparently trains you for later stages.

2) Then there's an intermediate state where the user knows the direction, presses down, moves, then looks at the screen, waits for the menu to draw and give some feedback that they've selected the right item, then finally releases the button to conform, or moves to correct the selection. It requires much less time, but still requires some visual attention and waiting for feedback before confirming the selection. But it reinforces previous learning, and builds muscle memory and confidence.

3) The final stage is when the user remembers the direction both mentally in "neural memory" and physically in "muscle memory", so they can just quickly flick in the correct direction and go on to their next task immediately, without looking at the menu or waiting for feedback. This requires the least amount of time and is the most fluid and satisfying way to use pie menus.

Carefully designed pie menus can seamlessly support all three stages, and both modes of interaction (click up, or press/drag/release). That enables users to smoothly escalate from one stage to the next.

There are several properties that dovetail together to make pie menus easier to learn:

1) Pie menus bridge between menus and gestures with a smooth learning curve.

Features that support expert users shouldn't get in the way of novice users: If you don't use pie menus very often, you can still use them easily without spending time or memory to learn your way around them. But using them in "novice mode" is rehearsal for using them in "expert mode", while they aren't any harder for novices to use because of that.

Features that support inexperienced users and learning, like fancy graphics to present menu on the screen, animate theatrical feedback and help illustrate and explain the selection, should not get in the way of the more efficient ways of using them as gestures.

To contrast: Drop down menus that display keyboard shortcuts suffer from increased size and cluttering, and using drop down menus with the mouse is not rehearsal for using drop down menus via keyboard shortcuts.

2) Pie menus are "self revealing": they show users the available options and their corresponding direction, so they are easy for new users to discover, use and learn.

To contrast: Normal invisible gesture recognition is not "self revealing", since they usually do not have a way for the user to discover what gestures are available and how to make them. Some gesture recognition systems have "help dialogs" that show and explain each available gesture, but stopping what you're doing to look at a help dialog to discover and learn the gestures is not the same thing as just using the gestures to get your work done, learning them while you're using them, without spending extra time on training.

3) Pie menus seamlessly support rehearsal. Stage 1 gestures are rehearsal for stage 2 gestures are rehearsal for stage 3 gestures.

Clicking up menus at stage 1 is rehearsal for stage 2, because it shows you the options and their directions, and lets your leisurely browse the menu at your own pace without stressfully holding down the mouse button.

At stage 1, it can incrementally reveal more information about the menu and items, while previewing and explaining the effects of the selection. Once you mentally remember the directions of the items you want, you smoothly advance to stage 2 without even noticing it.

Gesturing into menus and waiting for confirmation at stage 2 is rehearsal for stage 3, once you have enough physical muscle memory and confidence to quickly use gestures without looking at the screen or waiting for feedback.

Showing live in-world feedback, like previewing the effects of the current selection in real time during menu tracking, is an effective form of direct transparent feedback that reduces the need for indirect cluttered feedback with words and icons. This works well when using the distance as a parameter to the selection, so you can "pull out" sub-items (like colors) or linear parameters (like font size), and release the button when you're happy with what you see.

Both novice and expert users benefit from that kind of "direct manipulation" feedback, since it's better to keep your attention focused on the thing you're interacting with, not the menu.

Pie menus can be carefully designed to make learning the item directions easier, by exploiting the natural directional, opposite, orthogonal, linear relationships between items. For example: twelve items for a clock face of hours, astrological signs, months, etc; or eight items for compass directions, orthogonal pairs of opposite pairs that can be combined along diagonals (like good/evil, lawful/chaotic), etc.

A humaine user interface will explain why any menu items are disabled, and make it easy for you to do whatever is required to enabled them, instead of just graying them out and not telling you what's wrong when you try to select them.

Here's a demo of pie menus for Unity3D, that shows some of these ideas: http://www.youtube.com/watch?v=sMN1LQ7qx9g

If you don't need all that glitz, here's a jQuery plug-in: http://zikes.github.io/circle-menu/

The best (semi)circular menus I've seen recently are in the iD editor for OpenStreetMap: http://ideditor.com/

The reason of the post is not the circular menu itself but the fact that it's entirely made in CSS. I think this is really impressive.

I'm genuinely curious: why is that exciting? I don't know a huge amount about the web stack.

Usually JavaScript would be used to create the flyout menu effect like you see in the Dabblet. But since it's done in CSS3 any browsers which support those standard properties can work - no need for any JS code. It's just a neat workaround and very impressive IMO.

Do more browsers currently support JS or CSS3? (eg up to jquery 1.9 or similar) Not sure I've seen the stats on that as of yet and I'm curious.

Do any browsers with any real marketshare (even a tenth of a percent) not support JavaScript? I can't think of any examples although I've never had any reason to dive too deep into browser compatibility specifics for my projects.

Even if they do it can be turned off pretty easy. CSS wouldn't be affected in that way (I would think).

All mainstream browsers support JS and CSS, the question is how recent and what specific features. "CSS3" really means a whole ton of features and support varies.

Your typical "CSS3 demo" on HN will work well on Opera, Firefox, Chrome, Safari. It should work on IE10, has a 50/50 chance of working on IE9, and probably won't work on IE8 and below.

Check out http://caniuse.com/ to see which features are supported on each browser.

One other thing to mention is that users might turn off JavaScript support and screenreaders will have issues with some things JavaScript apps do. It was much more of an issue 5-10 years ago than it is today though.

As already mentioned it's just darn impressive, but there is also the big benefit of implementing stuff in css (when possible) over js that it generally performance much better, since all the animations are offloaded to the browsers rendering engine, rather than implemented in javascript. It usually gives a more robust and smooth result.

I agree -- it's some really elegant and powerful CSS code, which is a great example of what you can do with modern CSS, but I don't think it's meant to be about the actual interaction design, or meant to say that you should do everything in CSS and not use JavaScript.

As a practical matter, you need JavaScript to achieve the best usability, reusability, flexibility, etc. But it should serve as an example to JavaScript widget designers how much you can do in CSS.

It's an interesting and difficult problem designing a JavaScript pie menu component that let you easily and deeply customize it in CSS.

The radial menu in the stackoverflow article has some really elegant and concentrated CSS code, and I learned a lot by looking at it. I didn't realize you could do that kind of stuff!

The tradeoff of using pure CSS and very little JavaScript is that it's not a flexible, reusable, data driven component, that lets you plug in your own graphics, content and behavior.

I think it's a great idea to offload as much of the graphics and feedback to CSS as possible, but I don't see any practical reason for avoiding JavaScript and using pure CSS.

Anyway, as a rule of thumb, people who use modern browsers with JavaScript turned off do it because they like to whine about how persecuted they are, and I would never presume to begrudge them that opportunity.

The nature of user interface design is that when the rubber hits the road, there will always be millions of specific little tweaks you have to do to make things easier for the user and integrate with the application, and you can only do so much in CSS before you hit a wall and have to use JavaScript.

Of course it's great for the JavaScript code to leverage CSS as much as possible to make the menus graphically rich and easily customizable, and many of the CSS techniques of this particular example with a fixed menu could be applied to a more general purpose JavaScript widget.

But what it boils down to is that you really need the power and generality of JavaScript to support more sophisticated tracking, feedback, data driven menus with dynamic layout, application specific presentation and tracking feedback, etc.

Then you can get on to the harder problem like making it easy to design, build and measure pie menus that are most efficient and easy for users to remember, learn and use. And that depends a lot on the environment and the tools that you are using.

For example, these pie menus for Unity3D leverage the Unity editor and 3D object manipulation tools, and they have ways to tightly integrate your own application, content, graphics, animation and feedback: http://www.youtube.com/watch?v=sMN1LQ7qx9g

I love pie menus. The stock Android Browser's hidden "quick controls" are incredible and by far the fastest way to use a mobile web browser. You slide your thumb in off the side of the screen and then in the same motion move to the action you're looking for and simply release to activate. It's not obvious unless you show the user it's there but once you have it you don't want to go back.

link for the curious: http://www.droid-life.com/2012/02/07/tip-browser-quick-contr...

The stock camera app in Jelly Bean also has a particularly good implementation of a radial menu.

I remember an article in Dr. Dobbs hailing pie menus as the future of user interfaces. It was the early 90's. I have always thought they were a great idea.

Currently Microsoft Office One Note uses them.

Here's a list of references for pie menus (the Dr. Dobbs article is cited):

http://www.cs.cornell.edu/boom/2001sp/bronevetsky/Circle%20M...

In fairness to Dr. Dobbs, they also hailed hypertext as the future about that time, and that one they nailed.

1993's Secret of Mana was well known for its ring menu. I don't think radial menus are practical with mice, they fit controllers and console games better (where interacting with menus is slower).

Agreed, I think that radial menus are only really good for touch screens.

Gosh I really miss Super Nintendo

Every circular menu implementation i've seen still suffers from low command "density", lack of space for text, difficult to use sub-menus, maintaining predictable ordering, and, with touch UIs, commands hidden by the user's own finger.

I really want them, but squares are easier to work with.

One of the selling points has been that they may be used gesturaly, rather than requiring explicit point and click positioning - ie they could be similar to keyboard input in the form of touch typing rather than relying on hand eye coordination.

This one?

The Design and Implementation of Pie Menus

There're Fast, Easy, and Self-Revealing.

Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue.

http://www.donhopkins.com/drupal/node/98

More stuff at:

Home > topics > Software > Pie Menus http://www.donhopkins.com/drupal/taxonomy_menu/4/49/14

And here are some pie menus for Unity3D: http://www.youtube.com/watch?v=sMN1LQ7qx9g

And this explains the pie menus and visual programming in The Sims: http://www.DonHopkins.com/home/movies/TheSimsPieMenus.mov

That is the one. Thank you. It made me miss the dead tree Dr. Dobbs.

Dr. Dobbs was wonderful, and I really looked forward to it every month. Ray Valdez wrote a good contract that said I retained the copyright, so I could republish it myself later, which was nice thing for him to do without me even thinking to ask.

And Creative Computing was a great computer magazine, too!

What struck me as I reread the article was that it had been through a rigorous editorial process. No cruft. That clarity is why it stuck with me twenty years on.

It always seemed wrong to throw magazines away, at least so long as they were packed up early as I prepared to move. About 1997 my computer magazines were not. After the books had been boxed, I'd had enough heavy lifting. Now few articles get read twice. Somewhere in a box in Orlando though there may still be a copy of Deskview X.

I made a similar tool for quickly navigating between tabs in Chrome:

http://www.appsforartists.com/get_app/chrome_marking_menu/?s...

Very impressive how close the answerer gets to the questioners mock up. Good job that man!

And yet, I bet the designer will still come back and say the curve isn't right, or the bar isn't think enough.

I think that's some impressive CSS.

And it works smoothly on my mobile. I'm impressed.

Why so much negativity? This post is months old—the designer never came back and complained, the answerer is a woman, not a man. :)

A little negativity maybe, but not "so much".

More of a joke at the expense of designers that like everything pixel perfect.

Interestingly, 'that man' is apparently a woman: http://stackoverflow.com/users/1397351/ana

Oh yeah, so it is.

Didn't think to check. Doesn't make any difference to me, man or women. It's good work.

No offence intended.

Anyone find the "Anna, marry me?" comment to be a tad sexist? /ducks

Yes. Not to mention the one commenter that "would like to stalk" her. Flagged that one.

Great demo. Not to nitpick, but the original poster's question was about a 3 item menu. It would be nice if the CSS allowed arbitrary number of elements. Right now, deleting one of the 5 links seems to break the design. Seems like something SASS could handle.

I'm not a webdev, but the code says:

  /* 
  * rotate each slice at the right angle = (A/2)° + (k - (n+1)/2)*A°
  * where A is the angle of 1 slice (30° in this case)
  * k is the number of the slice (in {1,2,3,4,5} here)
  * and n is the number of slices (5 in this case)
  * formula works for odd number of slices (n odd)
  * for even number of slices (n even) the rotation angle is (k - n/2)*A°
  * 
  * after rotating, skew on Y by 90°-A°; here A° = the angle for 1 slice = 30° 
  */

So there's a calculation to be done. I guess there are various ways to get around that.

...so SASS?

SASS could help you generate the required CSS, but you would still need some kind of customized markup, dynamic call to a SASS function, or JavaScript if you wanted to support a truly arbitrary/dynamic/database-driven number of buttons.

A number of different static CSS files even - static5.css

Or a serverside script in your favourite language - static.css?slices=5

shouldn't this be calc()[0] work?

[0] https://developer.mozilla.org/en-US/docs/CSS/calc

That's getting nice right there -- slick CSS implementation and a sweet design.

Having authored a jQuery Radial Menu plugin[1], I'll add that I have seen significant interest in the interface/plugin from a ton of folks over the years, but few real world implementations that have engaged me beyond first glance.

Personally I find the interface best utilized in situations where I'd rather not divert my attention and am performing similar tasks frequently - like in some games. When it comes to getting _creative_ with the UI component as a developer, though, I've found it tough to do _really_ well. It gets gimmick-y quickly. Path's QuadCurveMenu has been the best implementation of any type of circular menu that I've seen. Summly had a radial menu as well, but I didn't find it particularly useful - just fun to play with.

For anyone interested, here are some examples using the radmenu plugin: http://tikku.com/jquery-radmenu-plugin#radmenu_tutorial_4. Also, my site opens up with a radial menu: http://www.tikku.com.

Would love to hear thoughts from any other folks that have actually experimented with the radial menu interface?

[1]http://plugins.jquery.com/radmenu/

It's amazing the economic value Ana created by posting this. It's gorgeous, and every single web designer can (and where appropriate, should) now use this to make themselves look SO much better.

I wonder if the people who have posted the flagship answers on Stack Overflow know what heroes they are.

WebPie is a JavaScript version of the same: http://www.markusfisch.de/

It's smoother and more responsive than the jQuery plugin mentioned in this thread.

And, of course, the site above has the incomparable PieDock for Linux/BSD.

Whooaaa I just realized, unless I'm mistaken, this isn't actually a functional menu. If you add actual href's to the menu items, they don't take you anywhere because as soon as they're clicked the focus is removed, so the href does nothing.

My friend created this: http://permalightnyc.com/experiments/radial-menu

For some reason on my computer that it renders like this: http://i.imgur.com/ycKsaim.png

It would so much more valuable if you also included browser and version!

lol. Pardon me. Chrome Version 26.0.1410.65 (up to date)

This is amazing.

But it makes me think about how much easier it would have been to make that in Flash 10 years ago. Sigh.

It's a variant of the "pie menu".

FWIW, it breaks if you use Tab to cycle through the links.

Unfortunately, CSS does not support a "has", "contains", or "parent" selector, which would be required to support this.

    .button:focus + .tip, .tip.open, .tip:has(a:focus)

One line of jQuery should solve:

    $('.tip a').focus(function(){ $('.tip').addClass('open'); }).blur(function(){ $('.tip').removeClass('open'); });

looks nice.. thanks for sharing

Really cool!

Reply on news.ycombinator.com