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.
Creating a Radial Menu in CSS
61–70 of 80 posts
Re: Creating a Radial Menu in CSS
#62It'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.
Re: Creating a Radial Menu in CSS
#63This 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,…
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 cou…
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
Re: Creating a Radial Menu in CSS
#64Earlier quoted context omitted.
> 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 applic…
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 m…
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.
Copyright (C) 1991 by Don Hopkins.
Originally published in Dr. Dobb's Journal, Dec. 1991, lead cover story, user interface issue.
Re: Creating a Radial Menu in CSS
#65Earlier quoted context omitted.
> 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 applic…
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!!!"
Re: Creating a Radial Menu in CSS
#66Earlier quoted context omitted.
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 cou…
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…
This is exactly what I meant about expert "stage 3" users, in my other comment above (below, wherever).
Re: Creating a Radial Menu in CSS
#67Earlier quoted context omitted.
"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.
Scrolling and paging by dragging and gesturing on an iPad or touchpad.
Re: Creating a Radial Menu in CSS
#68Earlier quoted context omitted.
"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.
Have you ever played "The Sims"?
Re: Creating a Radial Menu in CSS
#69I 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…
This one?
The Design and Implementation of Pie Menus
There're Fast, Easy, and Self-Revealing.
Copyright (C) 1991 by Don Hopkins.
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
Re: Creating a Radial Menu in CSS
#70If 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 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