This is great -- all the way up to the point where you have to hold and drag. The usability on a laptop goes out the window as you realize you can't accelerate past the edge of your touchpad. Getting to the top item in the menu -- maybe even the most important item -- is extremely hard. You rapidly become limited to the number of items you can have in this menu.
Tap-or-swipe-to-open, and tap-or-swipe-to-close have rapidly engrained themselves as the easiest to understand for users. I'd love to see this demo with that in mind.
Yeah the hold and drag interaction model sure looks fancy but isn't very ergonomic. On mobile, you're fighting to stretch to the top item, with a mouse it's very unintuitive, and with a trackpad forget about it. Tap to open makes more sense in every scenario. It's an accessibility nightmare
> Yeah the hold and drag interaction model sure looks fancy but isn't very ergonomic.
I beg to differ. I find hold-and-drag menus faster to interact with when using a mouse, trackback or a touchpad. But it is possible to support it, while not requiring it. On button down the system enters a state where one of three things can happen.
1. The button is released. Then the menu should togle open and wait for another click and relase to select an entry.
2. The pointer moves more than a threshold. Then the hold-and-drag behavior is initiated.
3. 50ms or similar pass and the hold-and-drag behavior in initiated.
The last case is to avoid flickering in case somebody has a slow click and release cycle.
This or similar behavior used to be (still is) default behavior of many desktop UI toolkits.
I think you’re measuring a different dimension than I am. I’m talking about ergonomics and accessibility, not speed. Stretching several inches up a screen in a single gesture breaks most fundamental UI design guidelines. It’s hard for people to pull off quickly and accurately.
Not to mention the fact that it doesn’t allow for longer lists so just isn’t useful in general, unless the menu is toggled open to be scrollable.
On a non-Apple trackpad, I'm sure. Apple / macOS has had "3 finger drag" for a good few years now.
With it, there's no clicking involved: you put 3 fingers on your trackpad and move them and it's a drag operation. There's even a timeout / grace period before the drag is actually "committed".
You can also flick any one of your 3 fingers and it will drag + move your cursor with inertia.
And before they introduced 3 finger drag, there was always a timeout when doing tap + drag to account for running into the physical edge of your trackpad.
Having said all that, yeah I agree this isn't a great interaction on non-mobile devices.
For some reason Apple puts the most basic stuff behind an accessibility option. For example, tab to next button in a system dialog is disabled by default.
And, because it’s not enabled by default any more, the implementation has regressed in various situations: I don’t use macOS normally, but I did briefly around six months ago, and I immediately found several bugs in keyboard navigation within the System Preferences app, such as where some fields weren’t accessible that way, or where Shift+Tab wasn’t the opposite of Tab (e.g. {1} ⇥ {2} ⇥ {3} ⇧⇥ {1}, rather than ending on {2}).
The original menu was built for mobile, where this isn't much of an issue, my re-creation is a bit weird because I primarily interact with it on desktop, but I followed the same ideas as the original.
For a desktop-specific version of this, I'd definitely allow it to persist open after a single click. Maybe I'll add that.
The drag doesn't work on my android phone - it just closes. And I'd argue the usability is worse on a phone, where how you're holding the phone, and screen size affects basic usability to start with, and small screen size makes it more important to be able to lift my fingers to see what I'm choosing from.
> The usability on a laptop goes out the window as you realize you can't accelerate past the edge of your touchpad. Getting to the top item in the menu -- maybe even the most important item -- is extremely hard. You rapidly become limited to the number of items you can have in this menu.
Not really. Put a second finger at the bottom of the touchpad, then release the first finger (without dragging while both fingers are down). Poof, you just got yourself a whole touchpad's worth of additional height.
They've worked like this forever, and since I pretty much only use a touchpad, movement like this is pretty second-nature for me.
The simple version would be "finger crawling", like you're dragging a piece of paper. I think it is intuitive, it just seems to need more explicit instruction for people nowadays who never really did arts and crafts as kids, and built their understanding on new non-physical conventions instead (like three-finger gestures as in the other reply - I find those weird, not at all intuitive, and sometimes difficult to do because my fingers are different lengths - drag is mostly fine since I can just move my whole hand, but other gestures not so much).
Not sure what "finger crawling" is, but surely the point still applies that touchpad is not a table, and you quickly run out of space to drag stuff with your finger.
> Put a second finger at the bottom of the touchpad
Why would you use a second finger when your thumb is already hanging out there at the bottom of the trackpad? :)
How I drag things on a trackpad (or a trackpoint for that matter) hasn't changed since the 90s. There isn't literally a button there under my thumb any more, but it makes no difference. I don't really follow the comments that this is unintuitive; most computer interaction is learned rather than intuited, and this interaction has simply not changed. Perhaps other ways of dragging were added, but they were always inferior.
As always, "designers" are optimising for what looks cool and fancy subjectively to them, rather than optimising for usability. In their defence, the latter is much harder :)
If you look at my other work you'll see that I'm like the polar opposite of a designer that does things that look cool and fancy rather than optimizing for usability.
This was meant as a study in how to do certain types of fluid animations.
Tap-or-swipe-to-open, and tap-or-swipe-to-close have rapidly engrained themselves as the easiest to understand for users. I'd love to see this demo with that in mind.