Are button wheels around cursors ineffective?

Question

Because of Fitts' law, it seems that positioning commands at the immediate proximity of the cursor makes it possible to access them relatively fast: probably not as fast as elements in the corners of the screen, but still much faster than buttons which are positioned arbitrary.

Microsoft Office, for example, used that to display a standard menu with controls such as bold or italic buttons or text color selector very close to the cursor, the menu being shown when the application believes that the user may be interested in those commands. Given that the menu appeared when the user doesn't need it and remained hidden when the user needed it, and given that small controls were jammed together in a rectangular-shaped zone, this element was probably not the best example of successful user interaction, but still a partial illustration of Fitts' law.

At the same time, there is an interest of UX community in radial menus, as shown when searching in Google Images for “ux selection wheel” or “ux radial menu.” But the examples of the menus I've seen are more about visual design and much less about user experience: they are just a pretty way to group the elements together, but don't seem to improve the productivity of end users.

What about combining those two ideas, that is using radial menus and positioning those menus around the cursor itself? Actually, the two usages I know where button wheels were combined with the idea of immediate proximity of the cursor are both are very domain-specific:

• Microsoft Productivity Future Vision videos:

  

  It shows a very specific case of tactile interface, and while Fitts' law applies and there is a motion constraint (that is, moving the arm in such position is a difficult and slow task compared to moving just the fingers), it's still different from a cursor (especially because fingers, in this configuration, are much more precise than a cursor which may move too far away from its original position).

• Splinter Cell video game:

  

  This second example concerns a first person shooter, where a cursor has a very specific role of moving rather than pointing at an element. One aspect of that is that direction is much more important than distance: I haven't seen the actual implementation, but I'm pretty sure that if the person looks to the left, the yellow weapon will be selected, and will remain selected no matter how long the person continues to turn left.

Is the “if you move too far away from the original position, you're screwed” aspect of cursor-based button wheels the only reason which prevents this element of user interaction to be used much more than it is used today?

What could be the other caveats which prevent global adoption of this element in desktop applications where the primary interaction is done through a mouse?

---

It looks like this question is on a different subject than Are circular menu / button interfaces intuitive? The linked question is about radial menus as a form of organizing buttons in general (including on tactile devices). Mine is about radial menus positioned specifically around the cursor, in a specific situation of a product where most interaction with it is done with a mouse. I already addressed the aspects discussed in the linked answer in the third paragraph of my question.

Answer 1

Proximity is only half of Fitts' Law. Size is the other half.

While displaying a radial menu around a cursor seems like it solves the proximity problem, the fact is it doesn't make things that much closer.

The standard Windows Start or Mac Apple menu buttons are usually much farther away from the cursor, yet they are much easier and faster to hit than any radial menu. This is because the edges of the screen serve to increase the size of the buttons making them effectively infinitely large in certain dimensions.

Radial menus that function as rings or donuts around the cursor don't adequately address the size problem. Yes, the controls are closer, but they usually aren't much larger than standard buttons, so the gain is minimal.

They also don't appear in the same place every time. There may be the same relative positioning based on the cursor, but the absolute positioning changes based on when the user invokes the menu. Even if the right button is the correct choice it can appear to the left of the users attention and the user has to refocus their attention to the point of interaction.

Radial menus in games solve both proximity and size.

Games with radial menus don't typically have a cursor. You can tell which wedge of the radial menu is selected, but it's a direct selection rather than using an arrow on screen to indirectly select a wedge. This allows each wedge to have an effectively infinite size in the radial direction. As you observed, this makes it easy to make a selection as only the direction of input matters, not the distance.

Game menus also tend to fill the entire screen and appear in the same spot every time. Instead of needing to refocus your attention to a new place, you can keep focused on what you were doing. They are also usually modal, so that you don't need to worry about menu input being turned into game input. In your Splinter Cell example, selecting the left wedge won't move the player's view to the left (unless the player keeps holding down the input after making the selection).

Another advantage that games have is a specialized input device that works especially well with this menu type. Radial menus became more common in games as players became more accustomed to the analog joysticks found on most console controllers. Instead of a mouse that uses absolute positioning on the screen, these joysticks only allow relative input, and always recenter themselves when not in use.

This means that once a player is comfortable with the radial menu system they can enter the mode, flick the joystick in roughly the direction they need, and make a selection extremely quickly. Once they gain a positional memory of where the important options are, this behavior can become almost automatic when needed.

A traditional ring menu around a cursor will likely never reach this level of intuitiveness, but you can get close. Making it a modal and blocking input to the rest of the program will allow you to make the buttons extend infinitely out from the center of the wheel. You will also need an easy to perform action that invokes the radial menu. That will allow the user to see the menu, use muscle and positional memory, and make a rough gesture to select the correct wedge in a short amount of time.

Answer 2

I don't know the specific case of the app you would like to design. But that idea looks like it would work for a group of a few options (about 4 or 5). I think how this would work best is if you have a screen area where a click triggers a circle to pop over the surroundings. However the user would have to hold the mouse in order the well to stay. Then, the slight movement in any direction will trigger the angle that would point to some of the options.

If that's your idea, I think it would be a great way to "hide" a handful of buttons saving them for situations the user doesn't need them. Probably would work best for apps that would make more use of the mouse rather than the keyboard (maybe it would be nice on touchscreens).

Answer 3

Here is a method that addresses this issue. Upon a left-/right click a selection of menu items is displayed in a circular manner around the cursor's current position. Menu items are displayed as callouts and each callout is made up of an 'arm' and a 'bubble'. You select the desired menu item by either selecting the arm or the bubble. This minimises cursor movements to an absolute minimum (move the cursor towards the callout's arm and then left-/right click again).

The implementation is easy if the number of menu items is pre-determined. There is an example on www.peacockmenus.com. It is more tricky if the number of menue items at any level needs to be flexible, as you need a proper algorithm in this case.