5 ms·

> For example, while moving horizontally to a sub-menu, you can easily cross the width of a single line since it's not easy to move your mouse absolutely steady

> For example, while moving horizontally to a sub-menu, you can easily cross the width of a single line since it's not easy to move your mouse absolutely steady horizontally (in pro graphic apps you'd usually hold a Shift for that), so instead of moving to a sub-menu, you switch to another item. In a Pie menu that's much harder since as you move further the menu's area increases, so the tolerance is higher This is why properly implemented context menus don't strictly require you to move in a straight line. Implementations vary; I just tried it with the firefox context menu on linux and found that, once the submenu was open, I could move the cursor quickly to the submenu on any path, even taking a diagonal line to the most extreme options in it. I have also seen implementations where you had a ever widening path you could take as the cursor moved closer to the submenu, making the active area of the currently selected parent item trapezoidal.

eviks 3y ago
What implementation allows you to move diagonally? What if you slow down or move diagonally to another top menu instead of a submenu, do you know have to wait a bit before selection changes? This is tricky dynamic guesswork, and isn't great UI even with the visual height increases guiding you, in pie menus you see beforehand all the borders, so it's more explicit and predictable
- setr 3y ago
  I’m pretty the submenu has a timeout before it considers non-hovering to be a close-submenu action
  - eviks 3y ago
    Yep, that's the (lesser in my opinion) issue - it adds lag to othe submenus. Also the diagional move (at least in how Chrome does it) selects other items on hover, so you have visual noise while moving your mouse That's what I mean by "tricky dynamic guesswork isn't great UI"
    - aidenn0 3y ago
      It does not add lag to the submenus when I just tested on Firefox. I have two add-ons that install submenus to the context menu, and if I move off of one and click the other one, the submenu immediately opens. Same for non-submenus (I can click to activate). It does, necessarily, add lag if I want the submenu to open on hover, but I suppose I've used enough UIs where submenus don't open on hover that clicking is muscle memory for me.
      - eviks 3y ago
        > I've used enough UIs where submenus don't open on hover that clicking is muscle memory for me. yeah, that's one of those UI busywork fails, but that's also a workaround to lag With a pie menu you could have it activate if you move your mouse far enough from the center (so that there is no way to do so in a wrong sector because the sector area is at that distance is large enough to make it easy to avoid such errors), so no clicks and less precision required
pimlottc 3y ago
This behavior is sometimes called “hysteresis” in UI circles: https://www.mackido.com/Interface/hysteresis.html https://www.mackido.com/Interface/hysteresis.html
DonHopkins 3y 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://news.ycombinator.com/item?id=32961306 https://news.ycombinator.com/item?id=32961306 https://archive.org/details/applehumaninterf00appl https://archive.org/details/applehumaninterf00appl https://andymatuschak.org/files/papers/Apple%20Human%20Interface%20Guidelines%201987.pdf 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_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 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 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 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”.

eviks 3y ago

What implementation allows you to move diagonally? What if you slow down or move diagonally to another top menu instead of a submenu, do you know have to wait a bit before selection changes? This is tricky dynamic guesswork, and isn't great UI even with the visual height increases guiding you, in pie menus you see beforehand all the borders, so it's more explicit and predictable

setr 3y ago
I’m pretty the submenu has a timeout before it considers non-hovering to be a close-submenu action
- eviks 3y ago
  Yep, that's the (lesser in my opinion) issue - it adds lag to othe submenus. Also the diagional move (at least in how Chrome does it) selects other items on hover, so you have visual noise while moving your mouse That's what I mean by "tricky dynamic guesswork isn't great UI"
  - aidenn0 3y ago
    It does not add lag to the submenus when I just tested on Firefox. I have two add-ons that install submenus to the context menu, and if I move off of one and click the other one, the submenu immediately opens. Same for non-submenus (I can click to activate). It does, necessarily, add lag if I want the submenu to open on hover, but I suppose I've used enough UIs where submenus don't open on hover that clicking is muscle memory for me.
    - eviks 3y ago
      > I've used enough UIs where submenus don't open on hover that clicking is muscle memory for me. yeah, that's one of those UI busywork fails, but that's also a workaround to lag With a pie menu you could have it activate if you move your mouse far enough from the center (so that there is no way to do so in a wrong sector because the sector area is at that distance is large enough to make it easy to avoid such errors), so no clicks and less precision required

pimlottc 3y ago

This behavior is sometimes called “hysteresis” in UI circles: https://www.mackido.com/Interface/hysteresis.html https://www.mackido.com/Interface/hysteresis.html

DonHopkins 3y 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://news.ycombinator.com/item?id=32961306 https://news.ycombinator.com/item?id=32961306 https://archive.org/details/applehumaninterf00appl https://archive.org/details/applehumaninterf00appl https://andymatuschak.org/files/papers/Apple%20Human%20Interface%20Guidelines%201987.pdf 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_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 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 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 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”.