Chonky Menu Re-Creation | Hacker News Reader

Chonky Menu Re-Creation

nathanmanousos.com

212 pointsccorcos94 comments

> I wasn’t sure what type of math function would work for this

Usually people use "easing functions", which are convenient since they typically have a range and image both in [0.0 .. 1.0] [1] (although sometimes the range is slightly above 1 or below 0 to produce some "effect"). CSS has a cubic-bezier function [2] that can be used to replicate pretty closely all sorts of easing functions.

Functions that look like an "S" when plotted are called "sigmoids", a popular one used in graphics applications is called "Smoothstep" [3].

1: https://easings.net

2: https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...

3: https://en.wikipedia.org/wiki/Smoothstep

Thanks, I briefly tried using an easing curve for this and somehow my brain wasn't playing along. I'll give it another look because, yeah, that does seem like the way to do it.

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 beg to differ. I find [them] faster

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.

> The usability on a laptop goes out the window

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.

Interesting, it's an accessibility feature that is not enabled by default. https://support.apple.com/en-us/HT204609

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}).

That is one example, why I have the impression that MacOS is gowing downhill for advanced users for several releases now.

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.

I fixed the android issues, sorry about that

macOS has both. if you keep dragging after opening the menu, the mouseup will activate the menu item.

It just plain doesn't work on my phone. The menu start closing before I can drag into it.

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.

> 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.

Just because it’s second nature to you does not mean it’s user friendly.

Especially when you can fix it by just keeping the menu open.

If you have to explain how to use it…

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.

I do that, and it's always a fiddly manoeuvre. Far from usable.

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.

Oh I know, what I mean is that you are unfortunately thi minority, judging by the usability of much of modern software.

Well the demo didn't work on my phone, because I just scrolled the page.

(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

I'm on Android Chrome 116 and I scrolled all the way to the bottom and wow that was a responsive component!

Super fast and buttery smooth animation. I'm impressed

Android 13 Chrome 117 here and it did not work for me. Menu popped open on the long press, but moving my thumb up or down resulted in the whole page scrolling. Ditto on Firefox 117. (Is that weird that both my browsers are on the same version number?)

There's some speculation that it's because of "trying to compete in the minds of users who actually think they can compare two totally different software applications by comparing their version numbers."

https://superuser.com/a/303531

I enjoyed this post quite a lot!

Any chance you could add a feed to your blog?

Thanks for the reminder.

Update: it works on Android now

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 queues from a list of tracks.

Nowadays they dialed down on that paradigm (probably because of drag and drop support mostly) but you can still find it in some places (e.g home screen icons)

I find it a bit more awkward than before though because the popping is now time-based ever since Force Touch was dropped at the hardware level.

(Damn how I liked Force Touch, the irony is I realised how much I valued it only ever since it disappeared. The force-touch anywhere on the keyboard to turn the whole screen in a caret moving surface was so much better than today's long-pressing space in subtle but very tangible ways)

Force touch was the single most undiscoverable UX ever invented. Wonder how many iPhone users upgraded their devices multiple times without ever realizing it's a thing.

I've done a lot of work with gestural/interactive motion like this.

One area that people tend to make naive mistakes in motion design is directly driving the playhead with something like drag distance. For instance, if you drag down on the home screen of Android, stop, and hold; you can see the transparency of the homescreen icons and of the Quick Settings tiles are both controlled by how far you've dragged. The opacity of those icons is determined by your arbitrary drag distance, instead of something more meaningful (like which direction the transition will animate when you let go).

One of the nice aspects of this menu is that it's always clear which item is active. You can't drag to an indeterminant state between two items.

The Ux here looks really nice, and I felt like I'd seen it before. It's a bit like a 2020s interpretation of the webOS Wave Launcher. ( https://youtu.be/dcyJLaK4YBI?t=46 if you'd never seen it).

IMHO it seems to me overly complicated. Also it doesn't work on mobile / tablet Android. you can display the menu but once you release the button it dissapear

> 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

I think I fixed the Android issues, can you give it another try?

Can confirm, it works well in Brave on Android. You do have to tap to initialize the line -- and then tap on the line and drag -- in early examples, but the completed example works well.

You can watch a video version of it here: https://www.youtube.com/watch?v=1VgrdLfDozo

Ah sorry, I don't have any Android devices so I haven't tested it on that platform!

As a tangent, it's sad that that mentality is often used when designing actual systems for end users! (not relevant here because this is just a fun project)

Thanks for understanding!

Cool demo!

Re: click and drag: I love those kinds of menus (notably on macOS, the menubar works like this when you drag). It would be better however if you supported click to open as well, as this is what most users would expect.

It looks cool as hell (I particularly love the springy demo I'm a sucker for spring physics in GUIs) but isn't usable in Android Firefox. The drag function doesn't work at all.

Does not work on Android.

Sorry about that, I'll try to fix it. You can watch a video version of the article here: https://www.youtube.com/watch?v=1VgrdLfDozo

The effect where the items expand and move slightly to "try to reach your cursor" – does that fill any practical purpose? Considering that the threshold for the next item is still the same, it doesn't seem like it would help you click things, only fool you into thinking that's what it does.

When you click on an item and move your cursor to the top or bottom of the visible bubble, the mouse instead selects the item next to it. I'd consider an item whose selection box is smaller than the visual outline to be a bug. It's also jarring to have items "running away" from the mouse cursor.

That doesn’t sound like how it’s supposed to work so maybe something is not rendering correctly, or I don’t understand what you are describing exactly.

Side question: is there a recommended method to prototype such UI demos and examples as seen on this page? Some kind of library?

I've seen a number of similar things in the past and wondered if there was a way to quickly test a UI idea using helpful building blocks.

I'm not aware of any easier way to build something like this than what I presented in the article, but I'd be interested to learn if there was. I did create a full-fledged prototyping/animation tool called Flinto.com, but it can't quite do this interaction with all of its details

I absolutely love this UI. Shame we don't see more of it. :) The only thing I'd change is the click and drag part of it. I would just have it pop up on click then wait for the mouse pointer to enter, or fade out after 10s.

This is rad! I tend to find animation and motion design daunting; the step-by-step construction of the menu really helped me understand how something like this can be put together. Thanks for making this!

Thanks for the motivating comment :)

Great write-up! It’s hard to find good “chonky” ui tutorials

Demo runs at like 10 fps or less on this pretty new Apple laptop... And not doing anything heavy in the background either.

I’ve mostly not had issues on desktop, what browser are you using?

It was built in a fairly indecent way, but in my testing it always was responsive so I never optimized it, since it’s just meant as a learning tool.

Very cool. I see it's using Imba and Astro - did you write your own Astro integration for Imba?

It's not a true Astro integration, but Imba works with Vite, and I was able to use that to include Imba code in my Astro site. A real integration would allow for server-side rendering of Imba components, which would be great.

Beautiful

nice!

Did the original iOS version have to use similar math, or would that have been implemented with native iOS components?

took a second to figure out that i had to hold the click.

I’m not sure as I haven’t communicated with the original author, but I think it requires a lot of the same custom work.

What does this mean for accessibility?

runs at about 10 fps on my iPhone

please dont ever add anything like this to a website

It runs pretty smooth on my iPhone, but yes, it is a prototype meant for education, not suitable for production use.

> So, I recklessly replaced all the elements of my menu that needed to animate with SpringLayers and just set the whole thing to re-render sixty times a second. I thought surely this would cause performance issues because I’d be re-calculating a spring value for each property of each animated layer each frame, but I never had an issue (on desktop at least), so given that this is a prototype, I just went with it.

amazing. which tools did you use to build this?

It's all hand-coded web tech (html/css/js), but written in Imba (https://www.imba.io) which is a compile-to-js language that includes a react-like framework.

does not work with a pen tablet

Doesn't work for me on Android. Tried Edge, Crome and FF.

The moment I move my finger the page scrolls and the menu collapses.

Sorry! You can watch a video version of it here: https://www.youtube.com/watch?v=1VgrdLfDozo

I'm a little tickled by your response. You are sending me a video of how a user interface element is supposed to work, because the element is failing its most basic function: actually working.

Are you holding and dragging? Or do you release and try to tap?

The menu works as intended for me on iOS but I don’t use Android.

I tap and hold, then drag without releasing.

On Android the menu disappears a soon as I move my finger on the button even without leaving the button.

Doesn't work on Android unfortunately

No luck on Android here either

Awesome tutorial demonstrating how to build really polished UIs in JavaScript — just requires a little know-how

And iOS as it seems not to work on Chrome on Android.

Looks like the author forgot to stop the page from scrolling while a user drags their finger on a canvas.

This looks great, but it's using 50% of my CPU (i5-3320M) just for a menu and some visual flair. Not worth it.

Yeah, it would certainly need to be (and readily could be) optimized if used in production.

Thanks for the reply.

A quick comment on UX - my laptop is old (see: the aforementioned ancient processor), and these types of menus are extremely inefficient for screen real-estate. On a 1366x768 display, most modern webapps/applications simply need that full screen real estate. They become unusable if you try to split in either direction (which I want to do oh so often, using a tiling window manager). Even when given the full screen resolution, some things are simply unusable.

I think a design like this is at risk of falling into the "always unusable" category for hardware like mine. Of course, I know this is just a demo, and context matters a lot, but I still think it's something worth considering.

If each menu item is 65px in height - on a 1366x768 display, once you account for taskbars, titlebars, browser tab interfaces, menu bars, etc, you'd probably be lucky to have about 500px of vertical real estate left for the main content. So you'd barely be able to shove ~7.5 elements on screen with a list like this. Just food for thought.

Yeah, I totally get what you mean. I was focused on recreating the effects in original menu that this was inspired by, which was meant for mobile, so the context is very different.

If I was making something like this for use in a real desktop/web app, I'd certainly approach it differently.

Feature Policy: Skipping unsupported feature name “accelerometer”. chonky-menu

Feature Policy: Skipping unsupported feature name “autoplay”. chonky-menu

Feature Policy: Skipping unsupported feature name “clipboard-write”. chonky-menu

Feature Policy: Skipping unsupported feature name “encrypted-media”. chonky-menu

Feature Policy: Skipping unsupported feature name “gyroscope”. chonky-menu

Feature Policy: Skipping unsupported feature name “picture-in-picture”. chonky-menu

Is my demo trying to access all that stuff??

Why else would I paste that?

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

http://0x0.st/HOwY.png

Reply on news.ycombinator.com