> 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].
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 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.
(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:
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."
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
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.
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)
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.
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.
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!
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.
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.
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.
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.
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.
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