My favourite animation trick: exponential smoothing (2023) | Hacker News Reader

My favourite animation trick: exponential smoothing (2023)

lisyarus.github.io

675 pointsatan2378 comments

I don't see much discussion here of the crucial point, which is that this isn't just another easing curve or smoothstep() between 0 and 1, it's a stateless method that handles pretty much any inputs in a regular way. That's really useful!

If you've used CSS transitions you'll have encountered the problem this solves. Okay, my duration is 400ms -- but why 400? Shouldn't it depend on how far it has to move?

As others have noted, exponential smoothing has a different problem, that it asymptotically approaches but never quite reaches its destination. The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

When using a similar method for inertial scrolling, I've found it useful to add a (pseudo-)friction term. This offsets the exponential, and effectively works as a minimum speed. Here it is in Desmos: https://www.desmos.com/calculator/98ufbuzxhj

> As others have noted, exponential smoothing has a different problem, that it asymptotically approaches but never quite reaches its destination. The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

This is off the cuff, but you might be able to fix this as follows: Interpret exponential smoothing as a ODE on the distance to the target. Call that distance D. Then exponential smoothing is the Euler update for dD/dt=-C*D. (the constant C>0 being a speed parameter) The issue you bring up is basically the fact that the solutions to the ODE are D(t)=A*exp(-C*t), which is asymptotic to zero as t->oo, but never reaches zero. Now, the fix is to replace the ODE with one that goes to zero in finite time. e.g. dD/dt=-C*sqrt(D). (Solutions are half-quadratic. i.e. they are quadratic for a bit then stay zero once you hit zero.) The Euler update for this is stateless like you wanted.

> The obvious fix is to stop animating when the step gets below some threshold, but that's inelegant.

Why? It's simple, easy to implement and validate, and provides the desired visual impact. Seems perfectly elegant to me.

> If you've used CSS transitions you'll have encountered the problem this solves. Okay, my duration is 400ms -- but why 400? Shouldn't it depend on how far it has to move?

It seems to me that the "speed" parameter in the exponential function has the same issue, does it not?

If you use the version somebody else here mentioned, “move 90% of the way to the destination in 80ms”, does that make more sense? (I think it’s equivalent, just a change of units.)

But can't you then also change the units on the linear animations? "move 40px/s until you reach the destination"

I don't think there's any way to do that in pure CSS (which is what I was comparing to). You can specify transition duration, but not speed.

As a game developer, I find eased tweens with a preset duration better for most UI use cases. However, this other type of animation is extremely useful when you want to smooth a movement that is continuous/unpredictable, with no definite start/end point. Think for example a tile being dragged-dropped on a grid, snapping to the grid as the player moves the mouse, or indeed, the article's example of moving a camera around.

For these cases, the exponential lerp trick is very useful, and not universally known. There are many games (some of mine included!) that use the less correct linear lerp and run into trouble with their animations feeling completely off once somebody runs the game on a 240 Hz monitor, or anything different from the 60fps that used to be standard.

For this reason, I appreciate the article. It's usually hard to access this type of hyper-specific knowledge, as it is most often passed as an "apprentice-style" oral tradition from the senior people on a team to the more junior members.

I like this although I'm going to stick my neck out and say the author is objectively wrong that sqrt is better than cubic for a toggle switch, and that cubic is in fact the better choice for this situation simply because of the way real life toggle switches generally work.

Think about the breaker switches on the electrical consumer unit on your house, or the kind of switches you often find on analog synths or other audio gear, generally stuff that's going for a particular aesthetic. I have a small Hughes & Kettner guitar amp that has two of these switches that are very satisfying to use[0].

When you use these kinds of switches in real life there's some initial resistance, and then they suddenly snap into the new position because of the way they're spring loaded. This is more closely modelled by the cubic function than it is by either the sqrt or the exponential smoothing function.

Other than that absolute nitpick, I really enjoyed the piece. It well illustrates how animation can enhance a user experience when done well (with, for example, an appropriate easing function) or alternatively detract from it and be quite jarring if not implemented thoughtfully (thinking particularly of the linear interpolation examples).

[0] This does somewhat depend on the type of toggle switch, although even the variety that you find on something like a Minimoog (this isn't some sort of gear flex, by the way - I don't own one of these!) exhibit this "resist then snap to the new position" behaviour that makes them so enjoyable to flick.

Intuitively I too preferred the feel of the cubic function. A mechanical toggle will have some inertia, and I guess that’s what we’re seeing with the cubic approach.

I think the crucial difference is that in real life the toggle starts moving when you start applying force, and snaps at some point. In UI, you've already felt the click on your mouse, so personally I'd expect the UI toggle to snap right away.

I continue to marvel at how often simple non linear tricks add some joy to interactions online. Or, in the case of colour perception are fundamental to understanding why two colours may not be perceptibly different enough to some people.

The odd thing is that humans do not always understand acceleration. Don't run away from a fire uphill, in a belief it travels as fast (semi constant) across level ground: fire accelerates up hills.

Kids rapidly learn the rate of movement across ground for a thrown ball but not always just how fast it will be moving under gravity when it smacks into your hands.

It's fascinating that easing, which is what this article mostly boils down to, is something that each new generation seems to need to (re)discover on their own. I remember being fascinated by Yugo Nakamura's experimental websites back in the late 90s because they were some of the first that I'd seen that had an organic feel due to liberal use of easing. https://www.youtube.com/watch?v=NLt7Gwnt3WY

I remember sitting on the front row of a conference where Yugo was presenting and watching all the other Flash experts lose their minds as he ran through his demos.

Seeing him present those demos/techniques in person would have been an amazing experience. Is there video of that presentation online anywhere? I'd love to know the background of how he developed his programming techniques and visual style.

For some reason this makes me want a toggle that:

* Moves slowly to about 75% of the way there while you hold the touch/click

* Snaps the rest of the way on release

I’m not sure what this could mean in terms of UX though. Maybe the setting is actually applied or saved at the end.

Or it could be part of an “are you sure?” dialogue. The setting is applied as you hold, but you can hit escape to undo before it snaps into place.

https://jsfiddle.net/u1vybhqg/

  input:checked + .slider:active:before {
    transform: translateX(8px);
    transition: 1s;
  }
  
  input:not(:checked) + .slider:active:before {
    transform: translateX(18px);
    transition: 1s;
  }

This, but set closer to 200 or 100 ms (and for me, swapping the translate 8 and 18 so that the switch barely moves on mouseDown, because that's damn close to a real switch's behavior). This seems like it could be a good compromise to all of the people complaining about lag and others who understand that the visual system is powerful and movement is a huge part of that. Also, it's relatively simple as far as CSS animations go!

I have seen a lot of (eldery) people try to slide the toggle but then nothing happens.

So while your at it: also make it possible to slide the toggle. Or just use checkboxes.

I also did this in the beginning with these new-style sliders that are really just checkboxes. Because they look different, I assumed they were different. (I was probably like 17 when these things became fashionable, not quite elderly just yet and also deeply into technology in general.) I also did it because it wasn't quite clear which direction was "on", so I tried to make it go in a specific direction. They did work, though, also on swiping, so that didn't help the learning process either.

Anyway, point is: potentially more of an "it's new to me" thing than an "elderly" thing.

Love this article. I wrote basically the exact same technique almost 10 years ago. At the time I called it `lazy-easy` and still use it today. Sometimes you just want some nice smooth animation without all the state management: https://www.hailpixel.com/articles/lazy-animation-with-lazy-...

Really great write up. The demos seems to work fine in Chrome, but on Firefox they freeze up and cause they page to stop rendering completely as you scroll.

Yeah, I had the same issue and came to the comments to find out it it was just me.

This is actually a really good approach and a good proof of concept for an animation / easing technique. Reminds me a lot of Flickity:

https://metafizzy.co/blog/initial-demos/

https://metafizzy.co/blog/math-time-resting-position/

https://metafizzy.co/blog/particle-to-slider/

https://metafizzy.co/blog/flickity-begins/

Especially this demo: https://codepen.io/desandro/pen/myXdej

This technique isn't just useful for switches. Nor will you use a <canvas> element for a switch. Nor will you have 20 parallel requestAnimationFrame loops running on the entire site. Or intentionally broken elements. The site also doesn't have optimizations where the rendering stops once the delta is too small — or probably dozens more of small tweaks that could make this production ready.

The comments here show that people either haven't read the article and are making assumptions, or can't see the forest for the trees. Or are just simply so biased and cynical that they need to share their (unprofessional) opinion in order to appear smart.

Since when has HN turned into Reddit?

In this case a lot of people are unable to read the article because it hangs most non-chromium browsers about a third of the way down the page.

Loaded fine for me on Firefox. What are you using?

Firefox

> Since when has HN turned into Reddit?

Read at least the last paragraph of https://news.ycombinator.com/newsguidelines.html

I wasn't aware of that fine print, but in light of that, let me rephrase it:

Certain topics on HN can induce commenting behaviour among seasoned HN users often attributed to Reddit users, including, but not limited to:

- being contrarian without fully reading, understanding or contextualizing the article or comment in question

- weaponizing downvotes

- being overly cynical, lowering the overall quality of the discussion

- repeating, or tersely acknowledging what has been said by most upvoted comments in order to gain more upvotes

There are indeed sometimes less than stellar comments, and some topics are more prone than others, those things are true. Yes people comment without reading sometimes, and yes people are contrarian sometimes. Sturgeon’s law apples independently to any group or site, regardless of the average quality there. But, it is clear the average quality on HN is much higher and not very comparable to Reddit.

That said, it’s not a good idea to make assumptions about behavior or why voting is happening, it lowers the overall quality of the discussion to state those assumptions or complain about comments, and it generally doesn’t work here to tersely acknowledge something to get upvotes. I don’t know what weaponizing downvotes means, but I haven’t seen much downvoting here that can’t be explained by comments being either wrong about something or rude about something.

In my experience, it does often help to patiently respond to contrarians without negative judgement and explain how and why you value good animation tricks, and what problems they solve. That will probably earn you upvotes much faster trying to repeat or agree with another comment.

> Since when has HN turned into Reddit?

That has been happening for a while, but people are not talking about it because it's explicitly against hn guidelines. Gee, I wonder why.

The cynicism doesn't seem that fair in this case.

Re HN becoming like Reddit..

Perhaps there is a generic 'cynical feeling' in the air with technology, with feelings of distrust about the intentions of governments and corporations over their use of the profound technology that is appearing, and how this is being constructed with the intention to constrain and manage the individual, rather than enabling greater freedom.

I think maybe more that the users of this website, which is designed in a way that is intensely functional compared to other similar sites, just prefer less “useless” design features.

Emotional design (https://en.wikipedia.org/wiki/Emotional_Design) as it's finest form, there's a lot to tell behind a tiny little animation.

Interesting that you got the idea to dive into animating a switch :)

Maybe you could help the user to better distinguish the ON/OFF states by also colorizing the whole switch element, not only that "disc" (as it is done in Vuetify.js, for example, using the "color" prop: https://vuetifyjs.com/en/components/switches/

A generalized version of this is Hooke's Law, also known as the spring function. It works well for UI animation because it maintains velocity as the target x changes, instead of stopping/restarting like an eased tween would.

I wonder if there is some cultural preference for this.

Looking at the map example, I find the cubic smoothing way “calmer”. The exponential one feels a bit hectic and I am wondering if it’s an American thing. It’s got a “wheez” quality that is annoying to me, but that reminds me of hyper cartoons like powerpuff girls.

It’s still all very subtle…

This takes me back to old days of Flash programming and the infamous Robert Penner easing functions.

http://robertpenner.com/easing/penner_easing_as1.txt

Glad someone mentioned the Penner functions, that was a godsend in my early flash days.

I've used this for decades. The sweet spot for ui components seems to be moving 90% of the way to the target every 80 milliseconds.

Reminds me of that famous paradox.

Zeno's dichotomy paradox [1]. To travel a certain distance, you must cross half the distance. Then you must cross half of the remaining distance (one fourth). Then half again, and so on.

[1] https://en.wikipedia.org/wiki/Zeno's_paradoxes

That's a great rule of thumb, I'll remember that one!

i.e ease-in

that's ease-out

What you want is the switch to follow a potential function like this:

     .-------.
  \_/         \_/

The two low energy states are the on/off positions.

Next, we want there to be some friction.

Lastly, we imagine the switch being moved by a mechanism that moves linearly, and is connected to the switch by an invisible spring or rubber band.

As the motion begins, the invisible linkage spring compresses and the switch moves only a little. Then it snaps out of the potential valley and moves across the plateau. Finally it snaps into the other valley, with a bit of overshoot.

I think this was fun but I really hate those switch things - I find it confusing to know which position is on and which is off. Which colour is the "on" colour? A checkbox might be ugly but I do understand it at a glance.

A lot of these don’t seem to work on my iPhone and Firefox.

Touch input in JS is a bit of a mess. You have to explicitly disable a lot of “helpful” default behaviour to make it work well, like auto-zooming on double tap or selecting on long press.

CSS animations are much lighter on battery and computing resources than JavaScript and potentially smoother too. Something to take into consideration.

From the title I somehow expected Planck taper window which comes up in partition of unity.

The property of this is that you won’t find any discontinuity in any degree of derivatives. Ie it is smooth in the mathematical sense. If you want to make changes from a constant function (such as not moving at all) to something else (start moving), then this smoothness is a nice property.

The resource I come back to often for animation curves:

https://easings.net/

No example from the ultimate, infinitely differentiable tanh(tan(x))-like family? How disappointing.

everything old is new agin, dozens of this exact article in the flash era.

We lost a lot of collective wisdom when flash died IMO

Not really, the openframeworks/processing/thi-ng umbrealla crowd never forgets.

Animations like this give me a mildly nauseous feeling like a strobe light at an unsettling rate. The instant toggle does not.

The animations are becoming.. violently choppy/vibrating over time and then my browser crashes, bad algorithm?

Yeh got the same problem on firefox, had to kill it.

Great write up, love how much detail it goes into, and the interactive examples really help illustrate the points

You only need to smooth on approach. Something like `transition: left 200ms ease-out` in CSS should have you covered most of the time. Alternatively, you can build any kind of interpolation by replacing the `ease-out` function with the `cubic-bezier(...steps)` keyword: https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...

> Yes I’ve made a whole procedural map generator & renderer just for this example, and I have zero regrets.

You can be salty about excessive use of animations in modern UI all day long, but you have to respect that level of commitment.

You can also do quadratic smoothing without additional state, by moving towards the target with a speed proportional to the square root of the distance. Unlike exponential smoothing, this will actually reach the target.

This is just proportional control. https://en.wikipedia.org/wiki/Proportional_control

Yep. It is also known as exponential smoothing in other contexts.

I wish the author had linked to the wikis for either of those things up front so people who had heard of it already (and know why you probably don't want to use it for your UI) could move on.

The differential equations seem to show that this is a closed form implementation of a P (as in PID) controller. So the animation could be implemented without a call to exponential for small enough dt.

Never animate position. One of the number one reasons for jank on the web.

>However, this still looks a bit clumsy due to having a constant speed

Does it? Looks much better to me, and preferred to waiting for a animation to be given more time to speedup while looking "smooth" (they seldom seem to be given the same time as instant or linear animations, do they? For some reason we have to be forced to enjoy them in half time).

In fact I'd take the "instant toggle" in a heartbeat too. Real life toggles don't "exponentially smooth" from one side to the other either.

I hate animations like that because they are intentionally slowing down the UI. I already clicked it, why are you spending several milliseconds to update your state?

Animations, or anything else really, should only be used to improve things. Ask what the problem is, not what cool solution I should implement. It's ok to go to town if the page is artistic, like your blog, but if I'm filling out a form? Get your art out of here.

Beauty is often worth a little extra time. I'd rather walk a beautiful trail than a paved sidewalk beside 6 lanes of fast traffic.

It's cool to choose the tools that appeal to your values. It's not cool to advocate for paving the planet in your quest for single-minded efficiency.

> I'd rather walk a beautiful trail than a paved sidewalk beside 6 lanes of fast traffic.

But would you still prefer it if alternative paved sidewalk is 5 times shorter AND you need to walk between same two points of interest multiple times per day, everyday?

>Beauty is often worth a little extra time. I'd rather walk a beautiful trail than a paved sidewalk beside 6 lanes of fast traffic

Beauty can be expressed with the toggle's design, with the window decoration, with the colors, with the wallpaper, choice of font, and so on.

No need to be expressed with an animation.

If your car did a little "song and dance" everytime you started it up that you had to wait to be able to drive it off, it would get annoying really fast.

Nobody's waiting on a checkbox to finish filling on before moving onto the next.

Just because the switch takes time to move doesn't mean the new state doesn't take effect. I would expect the state to change immediately then the animation runs.

The only problem with instant transitions is that sometimes you may not notice what changed. I would like to see a UI built around instant transitions but with subtle animations that happen after to emphasize the change. Like the new content shines, or does a tiny bit of grow/shrink, but not in a way that prevents interaction. There's nothing I hate more than waiting for long transition animations (looking at you, macOS fullscreen button)

We've solved this problem already without animations.

You just highlight the data that has changed and have an "Apply" button to save those changes.

Toggle buttons are supposed to have an instant effect. It's an anti pattern to gate the effect on a submit.

According to who? It's a restyled checkbox.

https://www.andy.works/words/the-most-satisfying-checkbox

On mobile Safari, I get a translucent gray square showing the hit target over the toggle whenever I touch it. That removes any subtlety the different animations may show

Author writes about useful easing concept, happens to use UI element purely for illustrative purposes, HN comment section turns into a 100+ comment jihad over animations in GUIs. Nothing substantial is discussed.

So many people allergic to design and equating bad design with all design. Studies? Experts? What could they know? These guys have opinions on modern software and designers to throw under the bus for them.

I can't down vote this so I'll reply to say that there is still value to be found amongst the noise and complaints, even in this thead. I found iainmerrick's comment insightful and worthy. A place to discuss the value of animations is of value some of time too. There are lots of other threads to participate in.

Just go with the instant toggle instead of wasting time making the UI worse by making users wait for pointless animations.

Who is stuck waiting for a toggle or checkbox to finish animating? It's not blocking anything.

The user is. You usually wait for visual confirmation before you determine that the action you performed was indeed performed.

The user isn't actually blocked from doing anything, a box is ticking, it's not a whole-screen state transition where you have to wait for things to settle before moving on. The box doesn't have to settle before you can recognize "oh, good, it accepted my input."

I like those little animations, you do not, that's fine because there is a simple solution for it:

Just respect prefers-reduced-motion when implementing animations and everyone is happy.

PID Controllers for animations

My thought too, or just a P controller.

In relation to the formulas near the end of the article, I find it tragic that even in 2024 they are still PNG images.

It’s funny how emotional discussions about UI choices are.

I liked the article and its demonstrations because I learnt something.

Personally, I switch off animations whenever possible, preferring snappy action over flashy effects. But they have their use, for example in the rubber band effect which would be quite jarring without motion smoothing.

Is it just me, or does a little square flash around the toggle. I am on FF Focus. It totally derails the exploration of the smoothing variants.

Similar experience in Safari on IOS

Me too. Orion on iOS. So the border radius has a light leak?

hmm, could be my old FF (or hidpi) but many of the examples just dont work. Jittery scrolling on the landscape, and circles that start teleporting back and forth on the sliders, and one that vanishes to the left. To me that just highlights another reason to keep it simple... checkbox?

I appreciate the effort that goes into animation like this, but I always have to wonder, especially in the context of the web if it's worth all of the additional code and development time for such a minor detail. Do our users even notice?

During my day job as a frontend developer, I have to cope with this quite often. When you raise a point with the manager that we could be fixing real bugs instead re-doing a non-essential, very subjective thing the designer came up with, they usually reply that they trust the designer as a professional and they know better - the developers don't have a choice.

I think it comes down to personal preference. I prefer instant and snappy interfaces with as minimal latency as possible. Please provide me with an option to disable all animations and I'm likely fine with your interface.

The instantaneous one is best.

Can this be done in pure CSS?

CSS has its own easing function customization shorthand notation. So you could just use that. https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...

Can probably try playing around with cubic-bezier, but not too sure.

Something like this: https://easings.net/#easeOutExpo

`transition-timing-function: ease-in-out`

This reminds me of Medium spending months to change the underline beneath a descender: https://medium.design/crafting-link-underlines-on-medium-7c0...

This isn’t like ease-in-out at all. It resembles ease-out a little.

An I the only one upset this is done by (excessive) JS usage?

It would be my deepest displeasure to bring a button toggle animation to production that requires more than CSS.

Quick example I found:

https://hudecz.medium.com/how-to-create-a-pure-css-toggle-bu...

Easing/Smoothing is possible with transition-timing-function.

https://www.w3schools.com/cssref/css3_pr_transition-timing-f....

Buttons are just examples because it's easy to understand. The point of the article is the math.

Of course CSS could do it with less JS, but this would have been a totally different post.

Instead of the wall of text and equations, it would have been helpful to plot the easing functions.

I don't like this kind of smoothing at all. It feels slow to me. Please just toggle without animations instead. And yes, I know these examples have been slowed down.

The first toggle button on the page is the nicest to use IMO.

The animations are unfortunately broken on Mobile Safari :(

it's funny, the thing that got me to understand calculus initially in class was seeing the graphs, somehow my brain immediatly "got" the difference between acceleration and movement and the shapes of those formulas... these days I think it might be a type of kinesthetic synesthesia! helps immensely since I work in animation and always had an easy time figuring out just the right math for procedural animation :)

I noticed halfway through this article I was just clicking away furiously. Is this a clever ruse by $MEGA_INPUT_DEV_MFG to wear out my mouse clicker quicker..?

You never get there with exponential smoothing. It takes infinite time to asymptotically approach the goal.

Also, that page uses 100% of the CPU in Firefox.

The bottom half of the page doesn't even show in FF on MacOS for me... just white...

Text selection also doesn't seem to work... is it all Canvas maybe?

Also FF on MacOS, and same issue. Seems like a hang

Firefox on Android, too.

Doesn't load with mobile browser bur if you change to 'desktop site' option it loads... but is very jittery and loads slow, a few visual bugs aswell.

and Firefox on Linux.

Perhaps it's worth filing a bug report if this works on other browsers but not FF.

Reported it here: https://github.com/webcompat/web-bugs/issues/134506

Example of form over function.

If the site doesn't even load, does it matter what function you use for the toggle in the settings page?

It's nice, but it's not nice enough to warrant going beyond transition: all and timing cubic-bezier in css. Maybe if browsers ever add native support without having to add extra overhead.

For me the final few animations do some funky things... flickering, phasing out of bounds...

Can reproduce. Almost like it's intentional...

Same issue. Android FF just won't handle this "basic modern website". Probably 5+MB of js being loaded in.

Nice job, but it’s math, not some magic trick. I would like to see the animation functions graphed to describe how the numbers change relative to time.

My favorite is to take the difference between current pos and target pos then move the thing in steps of half that (rounding up).

This is very cool, the camera over world example really highlights the difference

Yes, but this seems to be convoluting two distinct problems.

one is how to handle user inputs to a camera/world with inertia while moving whith a lot more variables to set for a certain desired feel, (why no long taps/mousedown to speed up the movement).

While the button is just easing a fixed animation between two states with no intermediate input.

Also what happens to the binary state of the app if the animation can be reversed before reaching final state, this is opening a can of worms for no obvious reason.

So this is why my computers feel the same as they did 25 years ago.

thanks for sharing. this must've taken a lot of experimenting.

I love blogs like this. reminds me of 2005.

In a lot of ways we're just now reclaiming the good parts of the flash-dominated web. Fair bit of bad collectively as we're relearning, but things are trending in an interesting direction.

I’m pretty much fine with the linear one

Standard easing has one advantage being frame rate independent. Spring functions need some extra care to prevent things from... exploding.

Have you tried using a tick box?

They don't serve the same purpose. A toggle switch has an immediate result, such as switching the website between light mode and dark mode. A checkbox is part of a form, and indicates a boolean choice that will only be taken into account once you submit the form.

How do you enter text then? Do you re-implement the text box because input text is part of a form?

Check boxes work just fine without a form btw: https://stackoverflow.com/a/50012963

I'm not saying you CANNOT use a checkbox outside of a form. I'm saying they gradually became different UX widgets that serve different purposes.

You can use pretty much any widget to store a boolean state. A select? It works. Radio buttons? Works. Checkbox? Of course. Typing "1" or "0" in a text input limited to integers between 0 and 1 inclusive? Why not. But semantics matter, and so does the principle of least surprise. Nowadays users expect an immediate result when toggling a toggle button. Not as much when they toggle a checkbox.

No, users put up with whatever is thrown their way. Glitchy menus, pages that take forever to load, unresponsive timelines, you name it. I don't think a check box would be as controversial as you believe.

Why all the complex formulas?

This (for example) performs exponential smoothing:

  new += (target - old) / 4;

That's it!

(The exponentially smoothed animation looks weird to me, in any case.)

I remember seeing how much better was iPhone than Android, having slick continuous sliders instead of old-hat binary switches.

Imagine my disappointment when I found that the iPhone slider for mute didn't smoothly slide the sound volume to silence, as per the visual effect, but snapped it to zero just like the Android switch.

;)

Linear is perfect.

All of this work for buttons that toggle on a mouse/finger DOWN. How irritating that there is no intermediate state on the mouse DOWN and the toggle on the mouse/finger UP.

Because it allows you to /cancel/ the action.. click, 'oops don't want that' drag mouse/finger out and release. No action taken. User is in control. Amazing.

It's a toy example, not a polished UI. You can trigger this technique any way you like.

See also: CSS transition-timing-function: cubic-bezier

https://cubic-bezier.com/

>Again, this begs us to add some animation.

No, no it doesn't. Not at all.

It's a MAP. It's there explicitly to display information, If I'm moving the map such a distance that an instant effect might not rely the information that place X is above place Y then yes, maybe an animation is in order, since that gives me more information, but every single iteration after the first one is worse, way worse, and the last one is one of the worst of them, feels like trying to drag your feet through mud.

Whatever is on the second half of that article keeps completely freezing up Firefox for me.

Some of example animations are buggy -

https://i.imgur.com/hQyh05s.gif

https://i.imgur.com/So6KsMt.gif

The author addresses this: "See this jittering after the animation completes?"

This is explained literally in the next sentence of the article.

First one is, my bad.

The second one is clearly a bug though.

Same on my browser and system: Safari on iOS.

Your site crashes whole Firefox on Linux.

Works just fine here; also Firefox on Linux.

> Animations are not just a fancy visual thing, they help the user understand what’s going on. Instead of teleporting the toggle indicator to its new position, let’s move it smoothly

Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing.

Like in this case, what exactly is "going on" that requires this visual delay? It looks worse vs the original instant response, why does the user need to care about intermediate movement of this binary toggle?

Then this is the fanciness that detracts from solving the major flaw of these sliders: you can't easily tell whether it's off or on

> Like in this case, what exactly is "going on" that requires this visual delay?

Nothing. It's a technical demonstration. The delay is also overemphasized to make the difference more apparent.

> The this is the fanciness that detracts from solving the major flaw of these sliders: you can't easily tell whether it's off or on

That's because they don't represent anything. Toggles don't always represent on or off, either-- they could represent a binary choice between any number of things.

> Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing. > It looks worse vs the original instant response, why does the user need to care about intermediate movement of this binary toggle?

Putting aside the functionality that animations can add, because others have addressed it, even "feel" does matter to most users. Many people would choose soft-close cabinets over regular spring loaded hinges even if noise wasn't a concern. You'd never see them in a commercial kitchen, though-- people just move too fast and that extra bit just gets in the way. It would be rather absurd for someone in a professional kitchen to assume home cooks have the same requirements and use cases for cabinets that line cooks do. Similarly, people who spend most of their days doing technical things using technical tools made by and for technical people interpret interfaces differently than most people. To developers, UIs are a little part of an application to expose the functionality to users, and the less distance between the application and the user, the better. But more often than not, that approach yields results far more useful to someone with a working mental model of how software operates under the hood. To most people,the UI is the application, and the application is an appliance. Having smooth interactions that 'feel' nice to use are much more desirable.

As someone with a good amount of professional experience both as a developer and a designer, I'm consistently surprised by how quick so many developers are to assume their personal usage habits, osmosis-gained knowledge from projects, and folk wisdom about design trumps the expertise of seasoned credentialed professionals in the field. The reason most end-user-facing FOSS projects (that don't have foundation-funded UI teams like Blender or Mozilla) are used almost exclusively by other developers is because non-technical users usually find the experience unpalatable at best, and unusable at worst.

> Similarly, people who spend most of their days doing technical things using technical tools made by and for technical people interpret interfaces differently than most people.

Most "non-technical" people use computers, especially desktops, in a professional setting. Navigating those UIs is part of their jobs and they will spent hours upon hours doing so.

Pretty animations may make a good first impressions but they get old and annoying very fast. It is a huge mistake in UI design to only optimize for smooth on-boarding of new users and not for long term productivity.

> The reason most end-user-facing FOSS projects (that don't have foundation-funded UI teams like Blender or Mozilla

Blender has great UI because they are dog-fooding their own software through blender studio. Meaning because they are the users and develop UI based on their own needs, contradicting your theory.

Firefox UI has gotten significantly WORSE over time and the browser is becoming irrelevant based on market share. Now that is not all the fault of the UI but it is still worth noting that the height of firefox popularity was when it had a very power-user friendly UI that all that fancy "UI experts" would hate. Maybe they should replace the "foundation-funded" UI team.

As for commercial software, modern UI is so bad that many "non-technical" users actively hate using computers and feel absolutely powerless when errors occur. Modern UI is actively user-hostile.

Several years ago, the number one complaint you could read on this forum on Firefox was that Chrome felt snappier.

Firefox is irrelevant today because the supposedly highly sophisticated users decided based on feel.

Smooth animation performance was a major point of iOS over Android for years.

I see plenty of evidence of sophisticated users deciding based on the factors you dismiss.

Smooth animations > janky animations, always, but that's not the issue here -- the issue is whether something that doesn't need to be animated should be animated.

I prefer programs I perceive as "snappier" -- and to me, a part of "snappiness" is choosing not to animate things unnecessarily.

> Most "non-technical" people use computers, especially desktops, in a professional setting. Navigating those UIs is part of their jobs and they will spent hours upon hours doing so.

Yes, but they still reason about those interfaces totally differently. This isn't a quantitative difference in competence, it's a qualitative difference in approach.

> Pretty animations may make a good first impressions but they get old and annoying very fast. It is a huge mistake in UI design to only optimize for smooth on-boarding of new users and not for long term productivity.

Animations that stick out as 'being animated' are rarely desirable. I assure you that you don't notice most of the animations you benefit from in your usage.

> The reason most end-user-facing FOSS projects (that don't have foundation-funded UI teams like Blender or Mozilla

> Blender has great UI because they are dog-fooding their own software through blender studio. Meaning because they are the users and develop UI based on their own needs, contradicting your theory.

Do you have any actual evidence for the assertion that Blender's UI designers don't actually drive the usability of the software?

> Firefox UI has gotten significantly WORSE over time and the browser is becoming irrelevant based on market share. Now that is not all the fault of the UI but it is still worth noting that the height of firefox popularity was when it had a very power-user friendly UI that all that fancy "UI experts" would hate. Maybe they should replace the "foundation-funded" UI team.

You're substituting your opinion for fact. Mozilla's design team publishes a lot of stuff. If you think it's wrong, there's lots of specifics available for you to counter.

> As for commercial software, modern UI is so bad that many "non-technical" users actively hate using computers and feel absolutely powerless when errors occur. Modern UI is actively user-hostile.

This is a common trope among developers who think their feelings about interface design carry more weight than the research that actually tests these things. It holds about as much weight as any other feelings vs facts argument.

> I assure you that you don't notice most of the animations you benefit from in your usage.

I assure you, I do notice them. I am disabling them everywhere I can. I disable them in my Desktop Environment, I disable them on my Android smartphone. I am way more productive without them.

Now, I don't hate animations per se. On the contrary as I dabble in game dev I find them crucial to "juice up" a game. They have their place but that is not productivity software that people are forced to use daily. They are for play not work.

> This is a common trope among developers who think their feelings about interface design carry more weight than the research that actually tests these things. It holds about as much weight as any other feelings vs facts argument.

Many open source devs are users of their software. You are making a false dichotomy where developer are some special creatures with totally different needs. I like what I like. There is no such thing as an "average user". People have different needs. Making software for the lowest common denominator will create UI that will be miserable for everyone to use.

Now I am willing to listen to actual academic studies about UI design and productivity but your acting like some corporate internal studies are actually legit science is silly. We all know this things are are more drive by corporate politics.

I think parents reaction might be due the amount of shit software with pretty UIs. In the last 10 years it really feels like software has leaned towards form over function. I personally miss, simple, snappy Windows NT type UIs that were a megabyte and didn't contain a gig of custom icons or hit the GPU to like fade a window or something.

I think most people would trade opacity and fancy buttons for MS Teams to be able to load in under a minute.

Microsoft teams doesn't load slowly because of the animations, you can turn all of them off if you mess around with the settings and your windows registry enough. It loads slowly because MS have a huge incentive to keep adding features and almost no incentive to optimise it because the software is almost always purchased by large institutions, half of whom have vendor lock in already, and imposed on the people who actually use it day to day, who have no power to change it.

> It loads slowly because MS have a huge incentive to keep adding telemetry and ads and almost no incentive to optimise it

Fixed that for you.

>I think most people would trade opacity and fancy buttons for MS Teams to be able to load in under a minute.

It's a paradox. If you don't make it look fancy, smooth, and appealing, you lose out to those that do. Even if you have a better product, that doesn't mean you can sell it on merits of being more technically efficient. Especially to more casual consumer or to business heads to make the purchases.

besides, the minute loading times aren't because it's caching all those animations and assets. That's a different division with different problems. Probably a mix of security checks, inefficient networking, and _maybe_ some choice in framework like Electron as a distant 3-5th (not that Teams uses Election).

That's a fictitious trade, though. Opacity and fancy buttons are computationally very cheap, and they aren't the reason for Teams's poor performance.

I still love a nicely designed Winforms UI in 2024.

No weird colours or anything. Just mostly standard controls, unless it's necessary to create a custom one.

Most developers look at old interfaces through rose colored glasses. If you separate nostalgia from what most people find usable, they just don't hold up.

>As someone with a good amount of professional experience both as a developer and a designer, I'm consistently surprised by how quick so many developers are to assume their personal usage habits, osmosis-gained knowledge from projects, and folk wisdom about design trumps the expertise of seasoned credentialed professionals in the field.

Exactly! Too many people think that their personal preference is the best. Sometimes, the best solution is to have plain HTML where the user chooses their favorite font and size, like in the early Netscape era. However, that's not always the case.

> even "feel" does matter to most users

And I think most users would prefer software that does stuff instantly. Attaching little animations to everything is just silly and distracting. It only happens because someone had nothing better to do but still had to look busy. These things almost universally degrade the interface and I've yet to see the actual benefit of them, aside from the fact that they draw attention to themselves and make people think "someone put some work into that". When you think about it, that is the opposite of good interface design. A good interface is one you do not notice – it puts as little as possible between user and machine.

Almost no Apple interactions are without animation. It's actually hard to find something that's NOT animated on Android AND iPhone. For most users, the iPhone is one of the gold standards for "good feel".

Some people like the unrealistic jumping of no animation, which is totally fine. Some people want it to "feel like a computer" not how things actually behave in the real world. It's taste. Animations that are too long or too noticeable are bad taste. But animations themselves are not bad.

Switches in the real world tend to snap almost instantly from one end to the other. That is the defining feature of switches – that they don't have a slow transition between the states. This animation stuff isn't realistic, and even if it was that isn't an argument for it.

There are not many animations on iOS nor MacOS. What they are is movement that corresponds to the users movements. Like opening exposé with the touchpad on MacOS is not an animation, the windows follows the movement of your fingers. Likewise scrolling is not an animation, because it follows the users movements.

And I think most users would prefer software that does stuff instantly

Hmm, users certainly prefer software that's fast, but I don't know about "instantly".

Feedback is important. A button that gently clicks so you know it took effect is better than a touch sensor with no feedback. Animations can serve the same purpose as that click. (And of course they can be overdone, just like a button can be overly stiff or loud.)

> And I think most users would prefer software that does stuff instantly

User research feels differently, but with numbers.

> These things almost universally degrade the interface and I've yet to see the actual benefit of them

See my point about technical people and their usage perspectives.

> When you think about it, that is the opposite of good interface design.

Having been a professional software designer, I assure you I've thought about this. And explored it, researched it, tested it, prototyped it, interviewed people about it, built it, rebuilt it, and then did it all over again to improve it. Re-read the last paragraph in my comment.

> A good interface is one you do not notice – it puts as little as possible between user and machine.

On second thought, re-read the whole comment.

Actually I think you should re-read my comment. I'd also love to actually see the research you're talking about here.

> I assure you I've thought about this. And explored it, researched it, tested it, prototyped it, interviewed people about it, built it, rebuilt it, and then did it all over again to improve it.

Oh, sorry, I didn't realise I was talking to the world expert on button animations. So do users prefer quadratic or exponential smoothing on their switches?

> A good interface is one you do not notice

A good animation is one you do not notice. Subtlety that succeeds in loading off its feedback payload in your brain without exposing the transmission mechanism to the conscious level of perception.

Chances are you are only complaining about the subset of animations that failed to stay under that threshold. Yes, slow, elaborate animations are bad.

I agree. I don't have any issue with animations that I don't notice. So why bother with them? It seems like the best way to avoid me noticing something is not to put it there to begin with.

Same here, and couldn't agree more. Except that I'm not surprised.

The thing is, developers with this pov have often been exposed to really shitty UIs where there's poor design aesthetics, matched with no understanding of the user's problems, coupled with fancy effects, that end up getting in the way and breaking in subtle ways - and ultimately don't represent what the developer is trying to do.

People have a varying level of being exposed to such UIs, but professional developers, esp. dealing with enterprise portals and internal systems have been really burnt by this.

> poor design aesthetics

Sorry to be nitpicky-- I largely agree with your comment-- but I always must point out that interface design is a communication medium, not an aesthetic medium. Like technical writing, it's a communication medium even if there are some secondary aesthetic considerations.

> I'm consistently surprised by how quick so many developers are to assume their personal usage habits

To be fair, developers coming from math and CS backgrounds may not have had any HCI/UX/design training. For those who have, "You are not the user" [1] was drilled in as a foundational concept.

[1] https://www.nngroup.com/articles/false-consensus/

Most frontend developers also don't have much - if any - HCI/UX/design training. My experience is that a lot of people who should have had that instead see design as "above" that in a way that is worse by far by showing active disdain for user feedback. Often, in fact, by dismissing input from a user perspective from developers with a "oh, but you're not typical users". Which is on one hand usually fair, but on the other hand dismissing that they also are users, and often there is no such thing as a "typical" user.

If one segment of your users reports something as a problem, you need to at least try to understand why and whether it is possible to reconcile with what your other users want, or whether in fact your other users also would agree but just haven't been vocal about it.

Your point has truth in it of course, but the main theme gp was pointing out is the hubris of people, often in our field, to think that they know better than someone specialised on a given field.

Are you conflating “hubris” with “reasoning”? Or are you saying that appealing to authority is a good thing?

Is any evaluation of any field you’re not an expert in hubris? Or is it possible to use basic logic to identify contradictions in the assertions made by experts outside your field?

When has the switch been toggled though and how can I know in each implementation?

1. Is it when I pushed the toggle, regardless of when animation finishes? 2. Is it when the animation finishes

This is necessary when flipping many toggles on one page and it needs to be done many times over. In case there's no animation, it simple and clear. In case there's animation you need the know is it case 1 or 2. If it's case 2 it will additionally slow you down as you now need to wait until all animations lengths * number of switches toggled has finished.

Binary toggles are everywhere in web UX. They are almost always used where a simple dropdown menu with WORDS indicating the chosen state would be better. However designers hate that because then they can't write fancy animations on creamy toggle widgets.

A dropdown with the words enabled/disabled indicating the state will always be better than a toggle with some subtle animation and colour signalling the state.

Why is it better to use a dropdown? A drop down doesn't show me all of the options until I click on it; so I have to perform an action to see what my options are, rather than having them presented in front of me.

They're fine if there's going to be loads of options such as country name, but if its left handed or right handed, I just want to see a toggle/radio button that lets me switch and makes it clear which state its currently in.

Do you have any support for anything you've said that isn't based entirely on your own assumptions and feelings about designers?

> A dropdown with the words enabled/disabled indicating the state will always be better than a toggle with some subtle animation and colour signalling the state.

Oh yeah way better except for not being able to see all of your options or even how many options there are without interacting with it, at least double the number of keystrokes to operate, more cognitive load to parse and operate, not being idiomatic for the interaction, etc. etc. etc. There are lots of uses that dropdowns work better for, but saying they're simply better is asinine.

> I'm consistently surprised by how quick so many developers are to assume their personal usage habits, osmosis-gained knowledge from projects, and folk wisdom about design trumps the expertise of seasoned credentialed professionals in the field

Spot on. Devs have on average extreme levels of confidence in unrepresentative opinions (space bar heating) and think UI is beneath them.

> FOSS projects (that don't have foundation-funded UI teams like Blender or Mozilla) are used almost exclusively by other developers

Nobody is better at pissing away hard labor like devs. There are these amazing OSS projects with 10ks of man hours invested, that won’t let designers near their cluttered prototype ui, if any. Designers are meme-famous as working for free - harnessing their power in FOSS would be akin to convincing a child to eat ice cream. Yet they’re unable to.

Note this is not only UI, but general theory of mind skills. How many times have you read a README on GitHub where it’s written like the most over-cryptic nonsense, despite being quite general and straight forward projects under the hood? My working theory is UI skills and “explaining things” are fruits from the same tree. Most devs don’t practice it, so they get deep into curse of knowledge territory. Even the smart have blindspots, maybe especially them.

> the expertise of seasoned credentialed professionals in the field

Given how bad UIs in general have become, some scepticism over that expertise is warranted.

To be clear, UIs weren’t all great across the board 20 years ago. But there was a general agreement between UI experts and power users on how a good UI with standard desktop controls should look like and behave, whereas now it’s a mess and there are significant disagreements.

> But there was a general agreement between UI experts and power users on how a good UI with standard desktop controls should look like and behave, whereas now it’s a mess and there are significant disagreements.

Details?

> It's a technical demonstration

So? The justification is still substantive. What would change in a real slider that turns real setting on/off?

> delay is also overemphasized

That's only true for those slowed down by a factor of 8. Otherwise it's not, I see the exact same issue in real-world sliders on web sites and in apps.

> Toggles don't always represent on or off, either

But they mostly do, add they do in this case ("turned_on"). The other use cases would have different issues like the choice of colors (green is for on)

Then you overly general description forgets to prove that slower and more confusing control (which some generic non-tech users try to actually slide by holding a mouse button and moving the mouse instead of clicking) is actually preferable because it "feels" nice to them

Also, these > seasoned credentialed professionals in the field.

are the same people who put these garbage sliders in the OS settings menus (as well as maintaining many other common decades-old UI bugs), so color me unimpressed by their credentialed osmosis degrading user experience at scale (poor FOSS designs notwithstanding)

> So? The justification is still substantive. What would change in a real slider that turns real setting on/off?

No it's not. Whether or not a design accomplishes its goals is exclusively based on what it's trying to communicate. This is trying to communicate animation curves.

> That's only true for those slowed down by a factor of 8. Otherwise it's not, I see the exact same issue in real-world sliders on web sites and in apps.

What you notice in apps is probably noticeable because it was done poorly. In the vast majority of instances, these things are done well so they help your eye adjust but don't stick out as animations.

> But they mostly do, add they do in this case ("turned_on"). The other use cases would have different issues like the choice of colors (green is for on) Then you overly general description forgets to prove that slower and more confusing control (which some generic non-tech users try to actually slide by holding a mouse button and moving the mouse instead of clicking) is actually preferable because it "feels" nice to them

You're substituting assumption for knowledge.

> Also, these > seasoned credentialed professionals in the field. are the same people who put these garbage sliders in the OS settings menus (as well as maintaining many other common decades-old UI bugs), so color me unimpressed by their credentialed osmosis degrading user experience at scale (poor FOSS designs notwithstanding)

Most novices can't distinguish poor practice from poor practitioners from poor general concepts.

I feel like UI has changed to aim purely at the new user, at the expense of long term users. Its only focus is to be understandable as soon as possible, but cuts out everything that allowed to do things better once you understood it more in depth, as the depth isn't there. All that remains accessible are the black boxes that can be easily understood by someone new.

Computer UIs need animations for the same reason they need shadows, gradients, and momentum: because these are aspects of the physical world that we already know how to interpert, so can be used "for free" to aid our understanding of the UI. Not using animations would likely be more taxing on our visual processing because nothing in the world moves discontinuously, so that would be a new thing to learn when using a computer. The primary reasons not to use an animation should be technical: you can't have it run in a short enough time and still look good, not drop frames, conserve battery life, etc.

> Computer UIs need animations for the same reason they need shadows, gradients, and momentum:

The thing about design principles is that the designer picks the one that justifies their decision, which is more like fashion than anything.

For example: Windows 8 swept away shadow, and semi-transparent material in the name of flat design, making it resemble Windows 2.0. Windows 10 brought back shadow. Windows 11 brought back Semi-transparent material and also rounded corners buttons from Windows 2.0.

Gradients have been banished and missing for a decade, but I am waiting for a come-back.

> because these are aspects of the physical world that we already know how to interpert, so can be used "for free" to aid our understanding of the UI.

The above could also apply to more than just shadows, gradients, and momentum.

Skeuomorphic icons help users understand functions but we have shape & outlines resembling hieroglyphs. I doubt we are getting skeuomorphic icons back ever because font icons are just too awesome for designers.

Most real world buttons are elevated off the surface to let us know it is pressable, but digital buttons now just have a white or colored pill shape around it. I can't recall the last time I saw a pill shaped button in the real world.

> Most real world buttons are elevated off the surface to let us know it is pressable, but digital buttons now just have a white or colored pill shape around it. I can't recall the last time I saw a pill shaped button in the real world.

Well not really, real world buttons are elevated off the surface because of the practicalities of producing buttons and attaching them to a surface, some of the material has to be above the surface and some below for it to clamp on. Buttons are also usually produced as separate components and thus tend to be round or square because it's more mechanically simple and suits the most use cases, labels can be put around the button.

Computers have completely different mechanics, all buttons can be a bespoke size and shape, and they're inherently not tactile, the pill shape is just the easiest way to allow a button with variable width for variable font sized text, because it's easier to put the text on the button itself digitally than irl.

Got any research to back up that claim? I always go to the developer settings and turn off all animations on my Android phones, and it makes a monumental difference in usability, exclusively for the better. I did it on my moms phone as well, and she instantly felt it got faster, so this is not just because I am a technical person.

Some UI designers think animations are good, but they are not. They are a clutch that designers who don't know how to design good UIs rely on to indicate what is going on. We have never had faster computers than we do now, but we are collectively spending thousands of hours a day waiting for pointless animations to finish.

> Some UI designers think animations are good, but they are not

Imho animations are not a problem in cases where they do not affect latency. For example a visual click feedback to tell the user that it was registered & is being processed makes sense, especially for situations where the task may take a while. For example Mac OS' "eject drive" button would benefit from this, it has zero visual click feedback while ejecting the drive can take a whole minute for some reason. Yet at the same time Apple simply refuses to remove the 1 second long workspace switch animation even if blocked in the accessibility settings, they only swap the swiping animation with a fading animation.

The problem is that often designers simply don't put any thought into it other than "make it smooth and look nice".

In cases where the animation affects latency between user input and reaction to it there is no animation speed that's fast enough. It will always feel like wading through a swamp.

Thank you for this. I didnt know I wanted disabled animations until I tried it just now.

I would always do that on my previous (slower) Android phones, but it's NOT because they added to the usability, just that they slowed down the interaction significantly when the GPU etc. were not capable enough. On my latest Pixel, I don't do that anymore and just enjoy the animations because they don't slow down my daily interactions anymore. So your point does not actually convey that Animations are useless. They just have a toll on performance, yes. They always will. (I work in an industry where we spend a lot of time perfecting 3D geometry animations, because our users prefer it).

Wow just did what you suggested and indeed it feels much faster. I was sceptical at first but this is actually better.

>Computer UIs need animations for the same reason they need shadows, gradients, and momentum: because these are aspects of the physical world that we already know how to interpert, so can be used "for free" to aid our understanding of the UI

More like "for the same reason a fish needs a bicycle".

>Not using animations would likely be more taxing on our visual processing

And yet, Windows 2000 era UI was far more intuitive, consistent, and self-discoverable than today's animated, shadowed, gradient-filled, blurry transulcent, momentum-having flat crap.

Isn't shadowed and flat sort of the opposite of each other?

Amazingly, not in 2024.

They put shadows on otherwise flat layers - for gratuitous effect, but also to get back some separation after they've flattenned everything.

This appealing fallacy is part of the reason, but way too broad in general (and is also not reflected in the flat design land of today, but even before that almost nothing was really skeumorphically close to reality), so let's try to apply it to this specific case: you usually click on a slider, not drag it. So in this case, there is nothing "physical" on the user's intuition side that corresponds to the slider sliding. But that's exactly my question - what's the point of emphasizing the sliding? And taken your physical connection into account, the UI element should become a button

And if you expect users to slide, then the slider should reflect the speed of your mouse like a physical control commongly would, not that of some random algorithm, no?

> what's the point of emphasizing the sliding?

Because the “knob” changes position. Like in the real world, objects can’t disappear in one place, and then instantly appear in another. Animating a UI state change in terms of a move transition can help people to understand how both end-states are logically connected to each other. The animation resembles the mechanics of the slider knob being a “perpetual entity” that can move between two positions, rather than the slider control as a whole being some sort of static icon that is instantly swapped out for another static icon once I click on it.

Whether or not animations are necessary might still be arguable. I suppose it depends on the complexity of the UI control, on personal preference, and certainly also on the general level of technical familiarity of the end-user.

Well, some constructs need animation, but others can work out just fine without animation. When typing, I want the characters to show right away, and instead of using a switch, I could use a checkmark that I wouldn't mind getting checked too fast assuming that the context isn't full of checkmarks.

I think that we have tools in the UX toolbox that are less reliant on animations than others, but yeah, if you can get animations to be neat, yet fast it's great unless battery life is also a big concern.

TBH, animations only began to be acceptable to me once I got a high refresh rate screen and a fast computer, before that I knew they were speed bumps for my old hardware and maybe hated them a bit more than they deserved.

Im not sure I agree with this, and its quite a common argument for animations in UIs. The fundamental weakness in this argument is that animations are not interactive. They have a beginning, middle and end. Any attempt to interact with the UI during this sequence would disrupt the animation. This is why animation makes UIs feel slow; clicking the widgets requires a period of time to transition from state A to state B via animation. The irony is that this is used to indicate a transition, to emulate what happens “in the real world sliders dont teleport to the next state”, but this often always misses the fact that I didnt slide the slider to its new state: i clicked a mouse button. That is an immediate state transition. So all animations like the above do is slow the feedback of the state transition in a misguided attempt to emulate a real world slider when i never interacted with the UI in any way that resembles a slider.

This is why we design animations in immediate actions to be below 100ms, any more than that and we start to feel "computer's reaction is slow maybe it's doing some calculations in the background?"

Try to disable/reduce animations in your OS via accessibility settings, you will see that you really don’t lose much.

Then a toogle button is a bad example. It's a replacement for checkbox and adds ambivalence that the checkbox doesn't have.

Can you tell me which position of the toggle means on? Purple or green.

the color choice is the problem, not the toggle.

If you had red or green, which one is on?

I have a different definition of what a "need" is.

On a touch sreen, chances are the finger obscures the state change, or much of it. When you are not super focused ("I don't trust this thing!"), it's easy to miss the difference between before and after states. The animation serves as a low-threshold confirmation that the pixels are not just decoration and that the touch event has actually been registered.

Requiring the user to mentally diff before and after states would be like a sailor only confirming captain's orders when explicitly asked "did you understand me?" instead of an unsolicited aye.

Where the "on-state not as clear as with a checkbox" critique gets a resounding comeback is when slider-looking on/off states are introduced only because of fashion, but in a process where the language used in animations (e.g. screen mockup bitmaps) is completely unaware of animations and therefore they only happen if toolkit sliders match exactly. Yeah, don't ask...

Or you could just use a checkbox

Preferably both. Make it a checkbox for clarity, and animate it for input feedback.

Tends do get completely obscured and you're back to mental diffing. I know, I know, nothing a bigger checkbox could not solve, but they look weird when you only make them bigger horizontally.

> On a touch sreen, chances are the finger obscures the state change, or much of it.

Here's how I deal with that, in my app: https://imgur.com/a/6uQnuox

It's accompanied by haptics.

Why can't phones have mouse pointers? Drag anywhere on the screen (ideally not where the pointer is) to grab the pointer. Do some kind of multitouch thing like tapping with a second finger to click. Then you can see what's under the mouse instead of constantly prodding your fat finger into the object of interest. I guess that would be too slow, or something? Not simple enough?

It could only ever be good for some interactions, e.g. it would be terrible for when the screen is just three large buttons for super quick access. Mode switching would surely be awkward.

I think I remember some map apps experimenting in that direction, but I consider the locusmaps "magnifying glass" undisputed king of that hill (touch interaction for maps).

Hmm, I must admit I had never thought of this idea by card_zero: why not drive a mouse pointer using touch at a distance? Does anyone with experience in this know why it wouldn't work, or whether it has been tried?

I'm working on a Git GUI for myself, in which one of my top priorities is making it more understandable than Git's own UI.

I usually dislike animations. I used to disable transitions whereever possible, as they made the UIs feel sluggish. And I still do.

But working on the project made me for the first time really appreciate in practice how much amimations help with understanding. I paid a high price in complexity to add transitions whenever the state of the visual graph changes, and suddenly it was really obvious what was happening. Commits and whole branches were sliding into their new position, and I would go "a-ha! I see" instead of "wtf just happened, what am I looking at now?".

EDIT: Fair warning, it's heavily WIP https://gitlab.com/indigane/visual-git

I think this is the trick. Animations as a visual tool for teaching the outcomes of complex behaviors are a very valid usage of animation. There’s that one site that pops up on here occasionally with the fabulous educational topics and tons of animations to relate concepts that I think really drives that point home.

Minimizing animations are nice for showing you where things “went” when you minimize them. But apart from that, most other UI annimations are just eye candy.

I miss old school checkboxes for UI toggles. They're crisp and clear and don't entice bored people to animate them.

Me too, agree with you and GP. And I can't keep wondering why this opinion is so unpopular. Today's UIs are bloated with unnecessary animations (which adds latency). But worse than animations is that UIs are horribly inconsistent; took me a while to figure out those toggles should be clicked, not dragged; or: what is even clickable, how do I scroll, ...? I could go on forever, and probably so can you.

Why do only old nerds complain about this, when today's UIs are so "easy" that every toddler can use the smartphone? Are we just living in the past, getting old; are we the problem, why is our opinion unpopular?

> why is our opinion unpopular?

I think other people do feel a vague sense of anxiety using modern software from not quite knowing what all the interaction patterns are. When you click that hamburger menu on the website, what will it do, exactly? But most people from outside the software world just blame themselves for “not being very good with computers”.

The problem is that it’s not fashionable any more amongst designers to use built in controls. Everyone wants to think of themselves like Apple, and build their own beautiful design language. Even if it’s just for their own website or app. And it sort of makes sense given modern apps end up needing to be built for the web, iphone, iPad, Android, and the desktop. It makes sense to tie all of those pieces of software together with a cohesive visual language and style.

UI has become the domain of marketing and branding.

I'm old now, and I won't dismiss that the new stuff is aesthetically nice. It's also not that hard to use. But I just don't like the visual polish more than I like the clarity and responsiveness of the old UI elements.

I just don't care if my computing experience is beautiful. I care if it's snappy, productive, and reliable.

> I just don't like the visual polish more than I like the clarity and responsiveness of the old UI elements.

Agree, that sums my opinion well.

And much software doesn't even look like they preferred eye candy over clarity; it rather looks like they forgot about clarity completely.

I mostly find the way the opinion presented in this thread by many people exhausting.

You're doing it there too: You're throwing every bad point of every bad UI you ever encountered into a bucket and throw all of that at this article by concluding "Animations in UI are terrible and just bloat everywhere". That's very close to a strawman.

I have worked and AB-tested in UIs for games and such dealing with just that and I would much rather say: Bad UIs are bad, yes. And animations don't help bad UI not being bad. But if you have a good, understandable UI, adding animations smartly - without impeding the user and in subtle fashion - on top of that UI... that can increase the overall aesthetics of the UI a lot and make the UI much more pleasing to use.

I agree with that; animations can be OK, but when I have a configuration setting, I usually disable them because input latency drives me crazy.

My post replied to "checkboxes vs UI toggles", and replying to that aspect was my main point. That's slightly off-topic, of course. It has to do with animations only because checkboxes wouldn't really benefit from animation, whereas toggles are an obscure visual representation for the same control, and adding animation is a feeble attempt to make it somewhat less obscure, even though it doesn't even try to address the main problem: what does toggle "left" and "right" really mean?

I believe checkbox not benefting from animation is a good thing: it's so clear and obvious that you don't need to animate it.

I’m quietly obsessed with the idea of rebuilding a lot of modern user interfaces just using classic controls that we’ve had since the 90s. Checkboxes, radio buttons, labels and text input elements. I don’t know if it would be as good as what we have now, but there would be something so relaxing about all of my applications looking like they’re part of the same world.

Back in the days, you had a UI toolkit, and everybody would use those native controls; they looked and felt the same in all application, and you had a central place where you could customize the look. Now every application/website has customized controls for everything; everything looks and works differently. (And don't even get me started with websites implementing their own scrollbars with JavaScript. Uh!)

Custom list control: do Home/End buttons work? How to select multiple items, does Shift-Cursorkeys work? Does Ctrl-Click work? Of course not.

Custom text control: does Ctrl-Left/Right for word jumping work? Does Ctrl-Up/Down for paragraph jumping work? Can I select everything with Ctrl-A or does it select the whole website? Can I select everything from cursor until the end with Ctrl-Shift-End work? Does Copy/Paste work at all? (I have never figured out why Copy/Paste in Teams simply doesn't work. Apparently I'm the only one with this problem.)

Custom dropdown control: does Alt-Down work? Can I scroll the list with the usual keys?

If (web) developers would just use standard controls, everything would work the same, and they wouldn't have to reimplement all the basic things from scratch (or not at all). Web devs could write forms that work without megabytes of JavaScript.

Hamburger menus. Those horrible things didn't need to exist even in old times with small monitors and 640x480 (or less) - but now they exist everywhere on my 32" 4K monitor for no reason.

I beg to differ. Quick search shows that people animate checkboxes too:

https://stackoverflow.com/questions/44876144/how-to-style-th...

Checkboxes and switches serve different functions and shouldn't be used interchangeably: https://www.nngroup.com/articles/toggle-switch-guidelines/

This is a rationalization after the fact. Checkboxes used to be used in contexts where they are effective immediately too, and nobody was confused by that. The real reason switches were introduced was to be able to line them up on the right side in iPhone OS Settings, whereas checkboxes would have to be on the left side, costing too much extra margin space on the then-small iPhone screen.

Did you read the linked article? I think toggle switches are a superior metaphor for controls that move a system between two states. Checkboxes are superior for opt-in items that can be skipped over.

Consider the “kitchen lights” illustration here: https://learn.microsoft.com/en-us/windows/apps/design/contro...

Do you really think a checkbox has the right affordances for this action?

> the major flaw of these sliders: you can't easily tell whether it's off or on

That's the whole point. That's why the primary use of sliders on desktop is opt-out of something no user really wants.

This is often combined with scroll windows with some sliders offscreen and invisible scroll bars.

> It looks worse vs the original instant response

I think that’s an unpopular opinion. The instant response looks janky, exponential smoothing looks well polished as long as it’s not too slow.

Disagree - the instant response was alert and immediately observable and didn't take valuable time away from a limited mortal life.

Its like saying a web-page that loads and displays instantly is "janky" versus a web-page with a busy symbol that makes you pause and wait.

If you had 20 of these toggles to check, you would prefer your "janky" version anytime.

It didn't improve it for me. I don't want a switch animation that looks (like the designer thought) a physical switch might move. I want a widget to indicate and change some option.

It's not a great type of widget for that anyway, as others said. But either way the animation adds nothing except time the designer could have used to think about a better interface.

The snappy "instant" and simple UIs for Windows 95/2000 era were the best, IMO. It might take a bit to get used to non-animated updates it if you have never experienced it before and seem a bit janky, but it doesn't take long and at least for me feels much nicer.

Quarter of a century of "UX experts" and useless animations and transparency and complicating things has resulted in an objectively worse experience. It's slow, clunky, inconsistent, constantly changing, and doesn't even look good. The technical parts of the drawing, scaling, font rendering, color management, etc are much better of course, but not the overall experience.

UI design was of huge importance to the industry (Apple and Microsoft) when GUIs were first coming in, many people were still getting into the world of computers, and many of those who were using them were not comfortable with them. Improving the experience could be worth a fortune in new market. That's why usability, intuitiveness, and consistency were priorities and it was taken seriously as a discipline, there was research, and changes were made with (at least in part) quantitative data and study.

That field of UI design has basically died in the industry now. At least, it is much smaller and less impactful than it was. Most of it seems to have shifted to getting people to look at and interact with things that they otherwise would not have. I guess shiny new things would help with that, maybe that explains the baffling direction things have gone in.

EDIT: BTW., don't take this as criticism of the linked post. Back when I did a bit of graphics programming I loved tinkering around to make things visually pleasing and behave in interesting ways. The post is fun and interesting, and presented in a way that itself is a nice experience and must have taken a lot of work. And I don't think the author was passing it off as an end to end guideline for a user interface design. And I do accept that a lot of people do like more visually interesting and diverse interfaces. They're wrong, of course, but entitled to their opinion (/s)

Here's one practical benefit: the UI should make it obvious that your click did successfully register, and an animation does that because it's eye-catching.

But the other side of the coin is that, because it is eye-catching, animation can be distracting or annoying.

Adding animation to your UI is like adding salt to your cooking: it's going to be pretty bland without it, but you can also ruin things by going overboard.

Most people that complain about these things don't even realize how much of it is integrated into their daily lives and workflows because it's too natural to notice. You don't need experience to see when someone's done a shitty job, though; just like any other tool, inexperienced people often see poor outcomes as an indictment of a technique, tool, or approach when the practitioner is to blame.

I think that's a bit of an exaggeration. Yes, animations are useful sometimes, but in at least 90% of cases they make the experience worse. If animations were so important and integrated everywhere then why didn't I notice any change when enabling "reduce animations" on all my devices, other than everything being suddenly faster?

> inexperienced people often see poor outcomes as an indictment of a technique, tool, or approach when the practitioner is to blame.

Or they simply realized that so many practitioners are to blame that the distinction barely matters anymore.

> Yes, animations are useful sometimes, but in at least 90% of cases they make the experience worse. If animations were so important and integrated everywhere then why didn't I notice any change when enabling "reduce animations" on all my devices, other than everything being suddenly faster?

You're confidently saying it makes the experience worse but you said you didn't notice a difference when it went away? There's a lot of data out there that says otherwise. Once again, developers use of interfaces differs from regular users as much as professional cooks use of kitchen equipment differs from home cooks. It's very different.

> Or they simply realized that so many practitioners are to blame that the distinction barely matters anymore.

Sorry, no. Most shitty software design is done by developers that assemble interfaces based on their whim, most of the rest are done by developers trying to mimic what they think a designer might do (which most developers mistake for design,) and the small remainder are from either incompetent designers or genuine misfires.

Ask any group of professional photographers how many have tried Gimp in an attempt to avoid Adobe's fees-- almost all of them will say they have. Ask how many actually use it? I'd be shocked to find a single one. Aside from the substandard graphic design tools for things like typography (which are totally reasonably not a focus for the project, especially when Inkscape is solid there,) Gimp is a competent photo editor. Who uses Gimp? Developers that need a photo editor. Developers making software that other developers like to use is not an indicator that they know how to make software that's tolerable for other people.

Great UI goal, though what's catching is the change in visual state and colors, which also happens without extra animation, or you can add an extra highlight of the changed item to emphasize the change if state, so this doesn't address the specific issue

Animation should enhance and enrich the UI, not make it "look fancy". Apple gets this perfectly. The squeeze animation on iOS's volume bar is a great example. Providing feedback to the user in response to an action, in a manner that is expected and makes sense, can massively increase UX.

Apple is missing a few bites from its perfection:

They use these sliders, realize they could be ambiguous, so add an accessibility setting for the on/off labels.

Then they have these fancy animations where holding a slider even elongates the button "providing feedback", but this is just wasted since your finger is covering the button, and fingers have no eyes!

But still, it's a slider, so you'd expect that if you slide your finger over it, it will move. Not so fast, this only works if your started sliding from the slider, not from a side outside it (which would still work in the "real" world.). But if you start at the slider, then there is no point in sliding, there is simply not enough width for that!

Also if slider's button is to the left and you swipe from right to left, the sliders moves right! Take that, immediate fedback in the opposite direction, massive UX boost in a manner that's unexpected and doesn't make sense! (because it's not a real slider, just a check box of a different form)

Exactly, to the OP of parent comment, this talk is a great overview of exactly this point: https://developer.apple.com/videos/play/wwdc2018/803

I think the map example is better. Without the animation, you have to figure out visually how far the map moved.

Contrary to what some of the replies imply (that a smooth animation is always better than a discrete one), I have a solid example where animation definitely harms the UX.

One of the language apps (either Hemingway or grammarly) had this issue stepping through search results. As you moved, it would change the colour of the matching text, but slowly and subtly, via animation. That makes it much, much harder to actually spot where, in a wall of text, the match actually is. An instant change is far more visible.

“Accessibility > Reduce animations” is the magic trick to make modern UIs feel snappier and less distracting. I wish web UIs would respect it.

I was wondering if they even could. The answer is yes: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

My first thought was that the OS accessibility settings must not be available to websites without a permission toggle because the ad industry is just going to weaponize it and use it against people.

I use this on iOS and it still leaves a lot of animations that could be sped up.

The animation clarifies the change. A user, heck even I could be confused by an instantaneous touch toggle. Why? Because my finger covers it during the press, so I would not see the change happen - if my mindset was "change that setting", I might rapidly tap it again, thinking the press didn't register. Such confusion does not occur with a (fast) animated transition.

The map example is much more important. With animation, your eyes and brain recognizes a single image sliding around, giving you automatic positional awareness. Without, you eyes and brain recognize a slideshow of independent images, and makes recognizing and navigating the map a conscious effort. By no means an impossible effort, but an entirely unnecessary one detrimental to the user experience.

At the same time, navigation UIs that react as navigation-less updates also tend to have the double-whammy of bad UX in the form of blocking and discarding user input during updates.

Bad UIs are not bad because animations are bad, they're bad because they were made poorly.

>> The animation clarifies the change

Isn't that a problem that UI designes (sorry for generalisation) created by themself? Let's stick to the toggle element. It replaces the classic checkbox.

A "checked checkbox" leaves no doubt. A toggle box does.

>A "checked checkbox" leaves no doubt.

It's absolutely not that simple. I actually think that the toggle design is _very_ clever, explicitly because it sidesteps a lot of cultural baggage that comes with existing symbols, and creates its own, fairly unambiguous one.

Do you use "checkmark" to indicate that a choice is selected? In some cultures that indicates "wrong" answer.

https://en.wikipedia.org/wiki/Check_mark

Sure, just use "x" then, right?

In _different_ cultures, that one indicates "no, I do not agree".

https://en.wikipedia.org/wiki/X_mark

few things in the world are perceived as instantaneous, except maybe lightning. until recently people were not used to interacting with instantaneous objects. even a checkbox, in its original incarnation with pen and paper, would take a second to be filled. as long as the animation is interruptible, and the underlying change happens quickly (whatever the toggle is controlling) then animating the transition is usually better. I really like that their animation is interruptible.

Not really. A toggle is inspired by (and associated with) real-life knobs. When you imagine the manual gears in old cars, then when you move then knob it often moves non-linear in terms of visuals (because of the angle).

That being said, those toggles are imho the wrong choice. Checkboxes (that actually have a check-mark) are nicer because they show a clear "yes" and "no" so I don't have to guess which position means what when it comes to a toggle.

Before css animations landed I was utterly convinced animations could help the brain track relationship between items between views, but it turns out mentally it's not really that useful. To the point that I started missing win31 era pivot table like UIs.

There's still some case of adding a few short animations (microinteractions in todays parlance) to give a bit of polish and indicate concurrency or liveness.

On mobile your finger is often obscuring the button you press and an animation is necessary feedback. This is especially important for things that are not booleans, for example a button to increase a value and you end up in "wait, did I change it to 5 now or was it 5 before with my press not registering?" (actual example from yesterday in a famous D&D helper app).

If the animation is so slow that it is still visible after your finger isn't obscuring the button anymore, I'd argue it has to be really slow and is not snappy anymore. It also doesn't behave like anything physical, because physical buttons/sliders only move while you're touching them.

The gold standard used to be to make buttons large enough so they are never fully obscured (for toggles, the label can be included to be part of the button) and to highlight them when pressed and remove the highlight when released. (Like keys on a virtual keyboard mostly still behave.) That way, you have a clear indication of when you press something, and it coincides with what your finger is doing, and doesn’t lag behind.

Surely this only happens because someone wasn't looking at the screen while they were making the input. They could just as easily miss whatever animation is attached to the number changing. The real solution here is to provide some kind of haptic feedback (phone vibration) or to play a sound.

Big disagree on that. Sound and haptic feedback are clearly inferior solutions to the obvious one: an animation.

Can you back up this opinion with any kind of coherent argument? Because the problem is "people can't see the screen" so I feel like displaying something on the screen might not solve it. By contrast, you would definitely know if the phone buzzed when you clicked a button. Anyone who's ever used one of the iPhones with fake home buttons on them can attest to this fact.

While in small doses it's a bit nice to affirm to the user they didn't blink while the state changed, it adds significant complexity. Nearly every one of the animations in that website flicker and the map rendering actually has a bug where it doesn't stop jittering back and forth very visibly indefinitely. Definitely makes me not want to implement stuff like this.

You were so close to reading the part where it explains why that's happening and how to fix it.

Why do absolutely all of them flicker?

The jittering was an anti demo i think

Remember that time when the ios calculator was messing up with simple arithmetic due to the animations?

> Unfortunately it is, just a fancy thing that too often makes it worse or just focuses on the wrong thing.

For UI elements that try to replicate the physical world, such as toggles, switches, even some buttons, I find it that the animation makes the UI easier for the brain to understand.

I don't want to be a party breaker, and the article is nicely written, but why are these animations pervasive these days? When I click a button in the real world, it changes the state instantaneously. It gives me an instantaneous feedback. Imagine you click the mouse button, and it slowly goes down and up.

UI is becoming an art, but most people use computers to get their jobs done. And, to be honest, I still prefer checkboxes.

> When I click a button in the real world, it changes the state instantaneously. It gives me an instantaneous feedback. Imagine you click the mouse button, and it slowly goes down and up.

Physical buttons have measurable response times, along with momentum and bounce. They're pretty quick, but get more noticeable as things get bigger.

https://en.wikipedia.org/wiki/Switch#Contact_bounce

The technique becomes even more powerful with additional degrees of freedom, like when moving the map from the article. It feels a lot better to have your view animate smoothly than jump around discontinuously.

The virtual buttons are controlled by physical buttons. My mouse button already "animates" because it physically moves when I click it (and it's optical, so no contact bounce). I don't need another animation playing after the physical movement finishes. That's just annoying time wasting.

This in insightful, IMO. When attaching animation to action, if the animation doesn’t match the action, then there’s a disconnect that can be frustrating or annoying, even when the delay is a small fraction of a second. Physical light switches feel “instantaneous” because there is no added delay perceivable beyond how fast my fingers go. It does seem like some designers are sometimes so proud of their animations they run them too slowly. I do value designs that animate so quickly and smoothly that you don’t notice them until you look for it, and I feel like the article does lean in that direction. The map scrolling one feels pretty good, for example.

I think the animations are more satisfying on touchscreens, where you don't have a mouse.

It's non-blocking. If those milliseconds are critical, you can be doing other stuff.

How is it wasting time? It's not like you have to wait for the animation to complete

As the article says, and it seems like what a lot of designers feel as well: “Adding some animation to it would be cool!”

I’m with you though. Most animation in UI is superfluous and annoying, if not down right rage inducing (like when the animation blocks input).

A good example of an animation that I don’t dislike is the window minimize animation on macOS where the window gets “sucked” into the Dock. It’s useful because it relates a “where” that I can keep in my head. I click a button, where’d my window go? Down there, I just saw it get sucked down into the Dock.

Also some of these sliders are tri-state. When you touch it, it moves 3/4 way, becomes washed out, meaning "making the change, please wait", and either goes all the way & becomes green, or returns to its place and shows an error.

Animations are tools. Use wisely, they inform and entertain. Use too much, they become boring.

The animations are useful when you can't easily see the instantaneous change, but I'm with you on the slowed feedback. I think the best feedback would be for the slider to move instantly, but with a fading motion blur effect. So if you're hard of seeing, or blink, or whatever and miss the change in state initially, there is still an animation playing that you can see to know that something changed, but at the same time the button is already at its new state, so you don't have to wait if you are paying attention.

Or we can go back to normal checkboxes and radio buttons where the on/off state is obvious and no animation is necessary to help people see when they change state.

> I click a button in the real world, it changes the state instantaneously.

Actually it does not. Flick switches have travel, click buttons have depth. Electronic buttons have lag, bigger systems have startup time (hence the blinkenlights).

My dishwasher starts in ~3 seconds after I press start. The button travel is so much that I'm never sure whether it registered the press or not until I hear the water pump start pulling water from the pipe.

> It gives me an instantaneous feedback.

It's just because you're touching a button, and feeling the pressure on your fingertip. Nothing is in an "instant" in the world.

Let's just call miming physical switch travel and movement what it is: skeuomorphic animation

And just like its design counterpoint, while some may enjoy the aesthetic, it's actually superfluous and we've mostly moved on.

I get it, it's visual, it's easy to show one's boss domain knowledge; it doesn't do anything for accessibility and the feel (dependable repeatable ui workflow).

UI animation is largely intended to hide delays when loading dynamic content but its pervasiveness means it is more likely to contribute to delays when loading dynamic content.

https://addons.mozilla.org/en-US/firefox/addon/disable-trans...

One I often find funny/annoying is an icon next to items on a game menu that has a smooth movement (sometimes paired with a partial fade-out!) - this makes quickly selecting a option a few steps away so much slower and error-prone.

The 8x slow-down argument is so naive, it's bad. Perception and interpretation change with speed. Listen to a song you slowed down. It becomes something entirely different. Compare https://youtu.be/r2ozuCXpVJY?t=70 and https://www.youtube.com/watch?v=QspuCt1FM9M&list=PL19J-0p1Ir...

If you can't see the difference at normal speed, there is no difference.

Reply on news.ycombinator.com