I scrolled straight to the bottom to try it out. I kept tapping the button and it’d appear for a split second and disappear. It took me a few tries to realize that it’s not a button and requires tap-and-drag (I’m on mobile). I suspect I’m not the only one that would have this issue. I haven’t seen this kind of “non-button button” before. Is this a common UX choice?
iOS has that ever since Force Touch. You could peek and either abort by releasing or pop it into existence as an overlay by pressing further until first haptic feedback (second one would navigate to instead of overlay), then move through menu entries and select an entry by releasing without lifting the finger. It was super quick to use and I really enjoyed it, especially in Music.app e.g to quickly build listening qu…
Chonky Menu Re-Creation
81–90 of 97 posts
Re: Chonky Menu Re-Creation
#82Earlier quoted context omitted.
I don't know, maybe by mistake? I looked into it, it is the YouTube embed on the page that is triggering that, I suppose any YouTube embed will cause that.
I changed it to use lite-youtube-embed which doesn't request that stuff until after the user clicks to play the video
Re: Chonky Menu Re-Creation
#83This 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 ra…
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
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.
Re: Chonky Menu Re-Creation
#84Earlier quoted context omitted.
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…
Re: Chonky Menu Re-Creation
#85(op here) Sorry this doesn't work on Android, I don't have any Android devices so I haven't tested it there, I think there are some differences in the way pointer events are handled that are messing it up. If it doesn't work for you, please have a look at the video where I demonstrate and talk through everything: https://www.youtube.com/watch?v=1VgrdLfDozo
Any chance you could add a feed to your blog?
Re: Chonky Menu Re-Creation
#86Earlier quoted context omitted.
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.
Re: Chonky Menu Re-Creation
#87This 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 ra…
And even if it'd have worked I don't appreciate UI elements where I'm forced to obscure the choices I'm picking between.
Re: Chonky Menu Re-Creation
#88This 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 ra…
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.
Re: Chonky Menu Re-Creation
#89Very cool. I see it's using Imba and Astro - did you write your own Astro integration for Imba?
Re: Chonky Menu Re-Creation
#90Earlier quoted context omitted.
> you can display the menu but once you release the button it dissapear If you look at the inspiration from twitter (linked at the top of the post) you'll see that is by design.
For me it doesn't work on Chrome android. As soon as I want to select something and move my finger slightly, the menu disappears, although I am still with my finger on the button