Comment by DonHopkins
3 years ago
That astonishingly clever technique was invented by Bruce "Tog" Tognazzini and described in the first edition of the Apple's 1987 Human Interface Guidelines (page 87, "drag delay").
https://andymatuschak.org/files/papers/Apple%20Human%20Inter...
>Two delay values enable submenus to function smoothly, without jarring distractions to the user. The submenu delay is the length of time before a submenu appears as the user drags the pointer through a hierarchical menu item. It prevents flashing caused by rapid appearance-disappearance of submenus. The drag delay allows the user to drag diagonally from the submenu title into the submenu, briefly crossing part of the main menu, without the submenu disappearing (which would ordinarily happen when the pointer was dragged into another main menu item). This is illustrated in Figure 3-42.
Implementations certainly do vary, but the point is that it's essentially a weird magical non-standardized behavior that isn't intuitively obvious to users why or how or when it's happening. It's extremely difficult to implement correctly (there's not even a definition of what correct means), and requires a whole lot of user testing and empirical measurements and iterative adjustments to get right (which nobody does any more, not even Apple like they did in the old days of Tog). Many gui toolkits don't support it, and most roll-yer-own web based menu systems don't. So users can't expect it to work, and they're lucky when it works well.
Pie menus geometrically avoid this problem by popping up sub-menus centered on the cursor with each item in a different direction, so no magic invisible submenu tracking kludges are necessary. Don't violate the Principle of Least Astonishment!
https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
I think it's important for users to intuitively understand how the computer is going to interpret their gesture, without astonishment, and for the computer to provide high fidelity unambiguous instantaneous feedback of how it will interpret any gesture.
I like how Ben Shneiderman defined "Direct Manipulation" as involving "continuous representation of objects of interest together with rapid, reversible, and incremental actions and feedback".
https://en.wikipedia.org/wiki/Direct_manipulation_interface
>In computer science, human–computer interaction, and interaction design, direct manipulation is an approach to interfaces which involves continuous representation of objects of interest together with rapid, reversible, and incremental actions and feedback. As opposed to other interaction styles, for example, the command language, the intention of direct manipulation is to allow a user to manipulate objects presented to them, using actions that correspond at least loosely to manipulation of physical objects. An example of direct manipulation is resizing a graphical shape, such as a rectangle, by dragging its corners or edges with a mouse.
Those ideals also apply to pie menus. Pie menus should strive to provide as much direct feedback as possible, via tracking callbacks, previewing the reversible effect of the currently selected item (possibly even using the distance as a parameter), so you can easily use them without ever popping up the menu.
For both novice and expert users, the directly obvious geometric way pie menus track and respond to input is more intuitively comprehensible, predictable, reliable, and most importantly REVERSIBLE than traditional gesture recognition (like Palm Graffiti, or StrokePlus.net) or "magical" kludges like the submenu hack.
With pie menus there's a sharp crisp line between every possible gesture, that you can see on the screen.
But with a gesture / handwriting recognition system, you wonder where is the dividing line between "u" and "v"? The neural net (or whatever) is a black box to the user (and even the programmer). Some gestures are too close together. And most gestures are useless syntax errors. And there's no way to cancel or change a gesture once you've started. And there's no way to learn the possible gestures.
But with complex magical invisible submenu hacks, you wonder if it's based on how long you pause, how fast you move, where you move, what is the shape, why can't I see it, how does it change, what if you pause, what if my computer is lagging, what if I go back, what if I didn't want the submenu, how do I make it go away, why can't I select the item I want, what do I do?
But with pie menus, if you make a mistake or it doesn't behave like you expect, you can at least see and understand what went wrong (you were on the wrong side of the line) and change it (move back into the slice you meant to select). No fuzzy gray area or no-man's-land or magic hand waving. And the further out you move, the more "leverage" and precision you have.
The area and shape of each item target area should not be limited or defined by the font height and the width of the longest label. It should be maximized, not limited, to encompass the entire screen, all the way out to the edges, like the slices of a pie menu. If you move far enough, it's practically impossible to make a mistake, as the target gets wider and wider, so you can even use pie menus during an earthquake or car chase.
Speed Racer - Button Tutorial:
https://www.youtube.com/watch?v=9AjJd5xE3b0&t=2s
Consider how pie menus completely saturate "Gesture Space" with meaningful obvious gestures, instead of useless syntax errors and dangerous ambiguities and gray areas:
https://donhopkins.medium.com/gesture-space-842e3cdc7102
>The space of all possible gestures, between touching the screen / pressing the button, moving along an arbitrary path (or not, in the case of a tap), and lifting your finger / releasing the button. It gets a lot more complex with multi touch gestures, but it’s the same basic idea, just multiple gestures in parallel.
>I think it’s important to trigger pie menus on a mouse click (and control them by the instantaneous direction between clicks, but NOT the path taken, in order to allow re-selection and browsing), and to center them on the exact position of the mouse click. The user should have a crisp consistent mental model of how pie menus work (which is NOT the case for gesture recognition). Pie menus should completely cover all possible “gesture space” with well defined behavior (by basing the selection on the angle between clicks, and not the path taken). In contrast, gesture recognition does NOT cover all gesture space (because most gestures are syntax errors, and gestures should be far apart and distinct in gesture space to prevent errors), and they do not allow in-flight re-selection, and they are not “self revealing” like pie menus.
>Pie menus are more predictable, reliable, forgiving, simpler and easier to learn than gesture recognition, because it’s impossible to make a syntax error, always possible to recover from a mistaken direction before releasing the button, they “self reveal” their directions by popping up a window with labels, and they “train” you to mouse ahead by “rehearsal”.
Thank you so much for the detailed and thoughtful response!
Do you know if anybody has done research into discoverability on linear v. pie menus? I ask because other people in the thread have asserted the subjective belief that scanning a linear list is faster than scanning in a circle, which is also my experience. Possibly because of the software I grew up using[1], I use a menu almost exclusively for operations that I use rarely enough to not know where they are; if I know the path to find it in the menu, I probably know the shortcut for it.
1: Think lots of cardboard templates that fit over the "F" keys
You can remember the 2d position easier than a shortcut (partially because there is less precision needed, "roughly at the bottom of a file menu" is good enough), so there will definitely be more menus you roughly remember the position of without remembering the shortcuts.
I've experimented with incrementally revealing more information about menu items as you browse the menu, including short labels and longer descriptions, hiding or shrinking unselected items so they're not as distracting and cluttered, showing the description of only the selected item, and also bringing the selected item and label and description to the cursor, because that's where the user is looking, so it's easier to read.
Menus have a title and description that's initially displayed in the center of the menu when no item is selected. Items have an icon (a 3d object), a label, and a description. Disabled items have a description explaining WHY it's disabled. This video demonstrates them (the code is 11 years old so the web demo probably won't not work, but the code might still work with some minor tweaks):
Unity3D Pie Menu Demo
https://www.youtube.com/watch?v=sMN1LQ7qx9g
I've made a general purpose pie menu component in C# for Unity3D, which supports text items, image items, and 3d object items too!
I will make it available as free open source software on the Unity3D app store!
Here's a silly demo, showing a set of SimCity pie menus:
http://www.donhopkins.com/home/PieMenuDemo/PieMenuDemo.html
(If you don't have the Unity3D browser plug-in installed, it should show you a link to install it.)
They have a full set of useful notifiers so you can tightly integrate them with your application to give rich feedback during tracking (for example, modifying the 3D menu items, or previewing the effect of the menu item and distance parameter in real time, making them more like "direct manipulation").
For example, to show how you can implement feedback like The Sims pie menus with the head in the center that looks at the selected item, I've made a 3d object in the pie menu center with the webcam texture on it, so YOUR head is in the center of the menu, looking at the selected item! (That's why the demo asks for permission to use the webcam.)
The pie menu and each item has a title as well as a description. One feature I've added is the ability not only to disable an item, but also to provide an explanation of why the item is disabled! (PacMan in the demo is disabled, for example.) I wish other menus and widgets would do that -- it's frustrating when you can find an item you want, but can't figure out why it's disabled!
Another nice thing about them is that you can either configure algorithmically with an API, or with JSON data (which makes it easy to make dynamic data driven menus downloaded from a server or database), or construct them in the Unity3D editor out of objects (which makes it easier for artists to design them)!
I've made a custom Unity3D editor that lets you edit the properties, drag and drop textures and objects, edit and rearrange the items, and has some convenience commands, so you can place the 3D item objects in a circle in the 3D world, and call a command that figures out which item is in which direction by their position, and tidies them up. (That is much easier than arranging their order in a linear list of items.)
I'm going to play around with more in-world editing features, to make them easier for artists to design them.
Source code:
http://www.donhopkins.com/home/PieMenuDemo/PieMenuDemo.zip
Transcript excerpt (proofread):
[...]
This is a pie menu with eight items for SimCity, for selecting an editing tool.
Now you pop a menu up and you see in the center, right next to your cursor where you're looking, the menu title and the menu description, and then you see all the labels of the items.
The neat thing about pie menus is that every item is very close to your cursor, the target area is right next to you, and they're in a different direction, and they're very big area, so they're very fast to select from, especially when you learn them.
Now if I move towards a item, it brings it to my cursor here, and it hides all the other labels, and it shows the item description, and I can browse around the menu and read the different descriptions.
It's bringing these to my where my eyes are looking at the cursor, instead of forcing me to to move my eyes around a lot.
Now one thing is that you could disable a menu item, but it also tells you why the items disabled.
So pac-man was misbehaving, and I'm not going to even go into it. You don't want to know. So he's been disabled. Don't worry.
Now there's menus, and sub menus, for example, here we can click up a submenu.
And we get, you know, these extra items.
Notice how it won't let the labels go off the screen.
It shrinks and hides all the other things, so you can concentrate on what you're going to select.
I don't know if you've noticed, but there's this head in the middle of the menu that's looking around the menu items, kind of like in The Sims.
Now this is to demonstrate the kind of things you can do by having notifiers, that react to tracking, that modify objects in the world to show you like what's going to happen before you selected it, or just, you know, give you some interesting feedback.
Now I'm not actually moving my head around, it's just twisting this 3d object with my face on it.
That's accomplished with some notifiers, and you can also react to things, change these 3d objects in interesting ways.
[...]
A minor thing: strokeplus type gestures are partially reversible / cancelable via garbage - I usually do a few random movements if I feel the gesture start is wrong to guarantee that recognition fails. Think there is also a more direct cancellation mechanism, but garbage always worked
However, the bigger flaw vs the pie menu is the lack of those icons showing you the list of the possibilities, so learning is indeed very limited, so you only usually use just a few frequent gestures