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

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

Ah, I think I considered the article to be a supposed improvement to CSS animations - in which case both exponential smoothing and px/s transitions would be independent improvements.

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

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?

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.

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

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

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

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.

i.e ease-in

that's ease-out

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!

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.

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

In this case, not necessarily. It's obviously designed to animate in a particular way. Why? Is it just for kicks, or is there a reason for it to animate as it's moving? Is it going to bounce back half-way through because the system realized you're not allowed to turn that thing on for example? I don't know, so I would wait for it to finish.

I admire the dedication to do this, but I find it superfluous when designing something I need to actually use. Great for a game, not so great for a page of checkbox thingies I need to set to the right values to make something else work correctly. I don't really want it to animate well, I want it to work fast and to be obvious what it does and how it works. It doesn't have to be pretty, unless being pretty helps make it more clear what's what.

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

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.

Well, stuff like this used to be encoded in HIGs (Human Interface Guidelines). The GNOME HIG, back in the day, had the parent's recommendation, as well as the rationale for it: so that the feedback is immediate, and the user can then visually see the effect that that option has.

Gating it on a submit forces a user who is looking for something & not finding it into a "try one thing, submit, evaluate, open settings, undo that, try different thing, submit…" loop, which is a lot longer.

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?

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

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

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

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

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.

and Firefox on Linux.

Seconded (Firefox on Linux), it worked fine with the toggles but once it came to the map-based examples it stopped. Never saw a map scroll, and continuing down the page started to blank out the (assumed to be) maps, so I closed the tab.

Very nice-looking page, but perhaps a smidgen over-engineered for what it wanted to show? :)

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.

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?

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

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

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.

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

Same on my browser and system: Safari on iOS.

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.

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

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

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?

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.

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

> what does toggle "left" and "right" really mean?

Nothing, because that's not the point of the article.

It's weird to me that this is such a big point here.

In an actual UI, you will have labels or indicators telling you what the toggle means and what the options are - "Safety door unlatched" vs "Control motors engaged". That's a toggle between two choices and having it a toggle like that would be safer than checkboxes.

Otherwise your checkbox without labels is equally bad UX because what does "on" and "off" mean for an unlabeled checkbox? I could give enough examples from work how vaguely labeled checkboxes like "remote authentication" are terrible UX.

> that's not the point of the article.

Of course not. The post you're replying to explicitly said the discussion was off-topic. That means it's not discussing the point of the article.

> In an actual UI, you will have labels or indicators telling you what the toggle means and what the options are

If it only were that way, we wouldn't complain. But it's not.

> checkbox without labels is equally bad UX

Of course, I agree. But nobody asked for that.

Your post ignores the things that were said and replies to things that were not said.

For toggling between mutually exclusive choices please use radio buttons. Checkboxes, and less obvious variants, are for enabling/disabling clearly labeled options that are not mutually exclusive.

That used to be Interaction Design 101 back in the olden days, ie. 1990s.

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.

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?

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

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

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

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)

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.

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

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.

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

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

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

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

Off-topic, but this made me chuckle. My current progress into learning instruments and music is greatly helped by the fact of knowing a few musicians who understand my problems better than I do because they had those problems 15 years ago, haha.

>This is trying to communicate animation curves.

It's trying to communicate how to, among other things, apply animation curves to UI, just read it: "I use it for ... moving UI elements," "Speaking of UI, say"

I know it's easier to discuss generic things re. some Terra Design Incognita after erasing all of these specific details, but they do exist in the text even if you try to ignore context!

> In the vast majority of instances, these things are done well so they help your eye adjust but don't stick out as animations.

You're substituting assumption for knowledge (they aren't and they do, and I know my experience better than whatever you can imagine about someone else) and an answer to a specific question for yet another generalization. Is Apple part of the vast majority? Check my other comment re. how the fundamental slider flaws appear in that impeccably unnoticeable design

> Most novices can't distinguish poor

And here you go again, incapable of demonstrating the value of a supposedly good general concept to address a general challenge in a case of a slider, instead veering off into an assessment of some generic group that's not present in this conversation.

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.

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.

If Microsoft Teams were made in Windows Forms, it would not have the fancy look it has now, and it would be a lot faster. "The reason" is complicated.

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

We don't use Teams because it is fancy, or smooth or appealing.

We use Teams because the company that pays our salary tells us to use Teams. End of story.

And I would definitely trade opacity and fancy buttons for a client that loads and runs fast.

Unfortunately, you can't, because it isn't the opacity and fancy buttons making it slow in the first place. It's still a false dichotomy.

>Especially to more casual consumer or to business heads to make the purchases.

I covered that yes. Your company isn't made of people who will objectively measure the best product for the employees.

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

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

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.

The problem is that you don't know if ``on`` mapped to what you think it does.

https://i.imgur.com/cflIbUv.png

for example. Light grey is disabled. Light blue is enabled. It's not accessible. It's not obvious. It's not great for colour blind people. It's probably in this case a deliberate dark pattern. The only case where a toggle is ok is if the word for the each state is to the left and right of the toggle.

https://i.imgur.com/skPP5Cu.png

I agree, for on/off a checkbox would work better

Somtimes. Checkboxes work for "yes" or "no", but they're not idiomatic for other "a" vs "b" selections.

A checkbox should always have a label which should always be a question. The checkbox should be a tick not a cross. Then there is not ambiguity.

Toggle switches should have two labels to the left AND right which are binary enumerations.

yes (O----) no

vanilla (----O) chocolate

off(O----) on

The problem is that designers with their bias towards animation and colors get it wrong. They do things like

Turn on? (O----)

And then toggle the color of the background between two different pastel shades which is aesthetically pleasing to the eye but delivers you halfway towards a reactor pile meltdown when the operator gets it wrong.

Bad design != Design. UI design is a communication medium, like technical writing. Within a weekend of fiddling, damn near anyone can operate the tools to assemble interfaces, but that does not mean they are interface designers. Failing to use color to appropriately communicate actions or state and thoughtlessly applied labeling are the actions of graphic designers trying to make things look pretty, or developers do to make things look 'designed.' That happens all the time and is no more an indictment of UI design than wordpress sites running janky homespun themes made from copy-and-pasted tutorial code are an indictment of web development.

> Failing to use color to appropriate communicate actions or state ....

No no no and no again!

Do not use color to to communicate actions or state unless that color can be used to statically differentiate between another color that is present in the UI at the same point in time. This is why syntax highlighting in code editors works because there is a state boundary between a word in one color and a word in another. It is why colors for toggle sliders indicating off and on do not work. What color is 'off' or 'go' or 'enable' or 'disable' or 'allow'. An animation of any type does not help and only adds CPU overhead and UI slowdown.

Animations can be useful only if they assist in disambiguating a transition between states. For example transfer of an item to a different position in a list. If the item animates across the screen the eye is guided to the new position. A toggle slider does not have this issue and should transfer to the new state immediately and the most important design question is how to interpret the current state of the toggle not the animation between the two state.

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.

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

Some animations can be essential for user experience. One of them is demoed in the page: the page scroll animation.

If you've ever looked at a wall of text or other high entropy information displayed on the screen, especially if it was on a shared screen so the image is all you can see with no hints about the scroll direction, keeping up with the motion can be nigh impossible. You have the whole image jumping up and down several lines or even a full page at a time and you spend all your brain power trying to find an "anchor" reference point to realize what that movement was, instead of focusing on the content.

In such cases even the most subtle of animations that tells me how the image moved is a treasure.

The vast majority of scrolling is done for the benefit of the person initiating it. It's a good point that you might want an optional animation mode for the the benefit of spectators, but it should be disabled by default. My short term memory lasts more than one second, so I don't need to be reminded that I just scrolled down after I scroll down.

User testing disagrees. Most people find an instantly refreshing screen of text to be quite dazzling. Developers look at screens of text all day long-- they're much more tolerant to those sorts of transitions than most people are, and basing defaults on their usage styles is one of the reason most people find FOSS interfaces completely awful.

Most users only see animated scrolling at work (not genuine "smooth scrolling" tied to continuous touchscreen or touchpad input, which is unobjectionable, but playback of canned animations following completed input events). They have an obvious incentive to like it: they're getting paid for doing nothing.

> They have an obvious incentive to like it: they're getting paid for doing nothing.

Oh good lord: what an incredibly patronizing sentiment. If design makes an interface slower for its users to use, it's a bad design. What developers-- used to looking at entirely text-based interfaces and command lines-- expect in interface feedback is much different from what others expect from it. If it's a tool for which developers are a core group of users, it should communicate using their expected set of visual signals.

It's an major confounding factor in all productivity studies, and IMO underappreciated because UI researchers generally don't want to get involved in politics. Social status depends more on relative wealth than absolute wealth. When the owning class takes approximately 100% of the generated wealth from improvements, the direct effects of improved productivity only hurt the worker. (They gain indirectly, because improved productivity helps society as a whole, but the marginal gain to the worker from any individual improvement is always small, so there's a tragedy of the commons here and the incentive is always to resist improvements.)

What an astonishingly bizarre non sequitur. Are you implying that someone's socioeconomic status affects how they perceive animations in interfaces?

Yes. I believe professionals are less tolerant of time-wasting UIs, in part because they stand to gain a larger proportion of the wealth produced by productivity improvements. If a faster UI just means you do more work while your boss gets richer, why would you want one?

> They have an obvious incentive to like it: they're getting paid for doing nothing.

My friend, this is weapon's grade ignorance, and this is a very, very charitable characterization. Your big idea is that people want these continuous transitions because they can waste a few minutes per day looking at them and be paid for it?

Any person working together with someone else on large documents and their endless reviews, and definitely anyone who often has to follow documents on a shared screen knows the benefits of transition between states. Something that allows the eyes and brain to track the motion. Objects in real life don't jump between locations instantly so nothing about people is trained to follow such instant transitions. The fewer the cues about how things moved, the harder it is to follow.

The users' fingers don't jump between locations instantly. That already provides the motion cue. UI animations are additional motion added after the natural motion has already completed.

And I already agreed that animation can be beneficial to spectators, who don't have access to the natural motion cue, but that's a small fraction of total use.

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

a) Ok so you disable mouseovers on all interface elements to indicate whether or not you're going to hit a click target, indicators of where windows are moving when you drag them and click indicator animations to show that you clicked on it, the minute amount of fadeout during the click animation on a number pad so you can enter values quickly while still seeing what keys you pressed, indicators for where something minimizes to or maximizes from, progress bars, blinking cursors, notifications... sure thing. If you think most UI animations are even remotely comparable to game UI animations, we're definitely not talking about the same animations

> 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'm not talking about internal corporate usability studies. Ideally, you should probably google something before you try explaining a field to a professional that works in that field.

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

Firstly, judging whether or not software is usable by looking at the handful of people that already use it and built it is like polling people to see if the dinner they cooked themselves last night should win a cooking competition. If the goal of your software is only to serve the people that wrote it, then it doesn't matter. But the vast majority of open-source software is made for other people to use, too which is why they post it publicly on the internet. I've contributed probably 10k hours of coding time to FOSS projects, all of which had the specific goal of serving people outside of the small pool of maintainers.

Secondly, you accuse me of treating developers like they're special but then say that design which doesn't focus on developers' workflows is coding to the lowest common denominator. Gotcha.

Thirdly, the entire point of the discipline of interface design is breaking the idea that there is an average user. How do we accomplish that? By not letting people make unilateral decisions about design based on their assumptions and folk wisdom, consult existing data that influences how we proceed, and test our assumptions on the people who actually use the software. If you're saying that developers unilaterally making design decisions are more open to different usage styles than a designer that is specifically looking at people's usage, I'm not really sure how to address that.

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

But when you move a switch like the ones demonstrated here in the real world, you have the haptic feedback of moving the pin physically, of it "snapping" into place. And that's how you know that your switch toggling was successful.

The "digital switch" does not have that. You usually don't even "move" it, as in "move the finger over the screen", but you just touch it. And your finger obscures the UI component in the moment you touch it, without any haptic feedback (except for your finger hitting the screen somewhere, but that does not necessarily mean that the switch has toggled). The animation replaces this missing haptic feedback, by your eyes seeing the switch moving, when you remove your finger after touching the screen.

I agree more with James K on this, but see your point too. Maybe this should be abstracted away such that each person can set their own preference which would be applied across all websites. Similarly how some of them respect your theme (dark vs light), they could be made to respect the animations, so that all toggles behave the same way (fast animation / smooth animation / instant).

I would choose instant thou.

Or use a checkbox and stop trying to make toggles a thing, since they just don't translate to digital as well.

I don't know about your switches, but mine definitely do need to pass through the intervening space between states.

That's not an argument for slow transitions, but some transition is realistic.

The transition is already there, on the actual switch (or the deformation of the fingertip with touchscreens). The animation is a second transition played after the first one is already complete. That is not realistic.

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?

> Actually I think you should re-read my comment.

Ok, done. Still didn't see anything beyond assertions based on nothing but your own preference, and countering things I said without any support.

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

Of course I didn't say I was the world expert in button animation, but I'm far beyond the age where I feel compelled to pretend random developers' uninformed opinions on design are as useful as mine. Lots of developers get really mad when people point out that that their software development expertise doesn't make them experts in all other fields, but that's a you problem.

> I'm far beyond the age where I feel compelled to pretend random developers' uninformed opinions on design are as useful as mine.

Yet your opinions are also uninformed. Or you've done precious little to convince people otherwise. Perhaps you should make arguments instead of just saying you have experience and it makes you correct. Does acting conceited often convince people of your perspectives? No? Then why do it? Surely telling me your thoughts would be much more convincing than simply asserting that you've had them.

> and countering things I said without any support

You are the one claiming to have numerical evidence to support your conclusions and failing to provide it. I think it is unreasonable to expect me to give that which you cannot.

> You are the one claiming to have numerical evidence to support your conclusions and failing to provide it. I think it is unreasonable to expect me to give that which you cannot.

That appropriately applied animations are a valuable part of interface usability is not controversial. A four second google search will confirm that and I'm not going to do that for you just because you refuse to look. Anyone dismissing the idea out-of-hand based on their own preferences and assumptions has the burden of proof.

> Yet your opinions are also uninformed. Or you've done precious little to convince people otherwise. Perhaps you should make arguments instead of just saying you have experience and it makes you correct. Does acting conceited often convince people of your perspectives? No? Then why do it? Surely telling me your thoughts would be much more convincing than simply asserting that you've had them.

Yes. How conceited of me to not scramble to go grab citations for a bunch of people in a completely different field asserting that they know more about design than designers. Surely if you stumbled upon a bunch of designers making sweeping, arrogant, unsupported declarations about software development and the incompetence of developers, you'd trip over yourself to gather any evidence they demanded to prove your point when you corrected them on their foundational misgivings. Surely you wouldn't just tell them to go google it for themselves.

"Am I out of touch with the current state of design? No: it's the designers who are wrong."

> appropriately applied animations

Appropriately applied anything is good. I am disputing whether this is an appropriate application.

> How conceited of me to not scramble to go grab citations

This what not conceited. There is nothing wrong with not having the numbers for something, you should just try to avoid claiming you do if you can't actually find any. The conceited bit was your general attitude. Writing many lines of text about how much experience you have, how everyone else is stupid and has worthless opinions, etc.

> Surely if you stumbled upon a bunch of designers making sweeping, arrogant, unsupported declarations about software development and the incompetence of developers

I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on developers doing the same thing. If the people making these claims were incorrect about something, I would simply explain why that is rather than saying "I have a bunch of experience that you don't have and there are some studies that prove your silly little feelings wrong. Your opinions are worthless compared to mine." The reason I wouldn't say this is because it's conceited and it doesn't convince anyone of anything.

> "Am I out of touch with the current state of design? No: it's the designers who are wrong."

I am more concerned with what users think than I am with the current trends in design. Anyone can be a designer, that doesn't mean they know what they're talking about.

> Appropriately applied anything is good. I am disputing whether this is an appropriate application.

Ok, explain why this animation is not an appropriate application of this animation in a technical demonstration of this animation.

> I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on developers doing the same thing.

Copout.

> If the people making these claims were incorrect about something, I would simply explain why that is rather than saying "I have a bunch of experience that you don't have and there are some studies that prove your silly little feelings wrong. Your opinions are worthless compared to mine." The reason I wouldn't say this is because it's conceited and it doesn't convince anyone of anything.

Read the comment I wrote initially, where I explained, at length, why the comment I responded to was not correct.

> I am more concerned with what users think than I am with the current trends in design. Anyone can be a designer, that doesn't mean they know what they're talking about.

Yes, anybody can be an anything, and luckily we've got gobs of Dunning-Kreuger mountaineers in the software business to assess their competence.

> Read the comment I wrote initially

This is why I call you conceited – the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said. You seem so confused by the fact that I have read it, and I find it to be unconvincing. You suggest that these switches exist primarily to look pretty, when as I understand it, their main purpose is to communicate that checking them has an immediate effect rather than only after form submission. I don't see them being used like that as much as I just see them jammed in random places, and even when they are I have to wonder if it would make more sense for the UI they are a part of to be made into a form. You dismiss the issue with state identification by saying they could represent "a binary choice between any number of things". The idea that a switch can have more states than just on or off is confusing to me, and that still doesn't help with the issue of determining their state unless you label both sides which is a waste in comparison to the simple checkbox, which draws on the user's existing knowledge from filling in forms on pen-and-paper.

> Copout

I'm sorry that I don't have the opinions you want me to have so that I'm wrong.

>>> Appropriately applied anything is good. I am disputing whether this is an appropriate application.

>> Ok, explain why this animation is not an appropriate application of this animation in a technical demonstration of this animation.

Thought so.

> the only reason people can disagree with you is because they are stupid or because they haven't actually read what you said.

What I initially said is based in common industry practice and backed up by papers from academia, independent usability organizations like the Nielsen Norman group, and plenty of other independent entities. It's not secret-- lots of info is a quick google search away. It's nuanced. Lots of the info is in literature about accessibility-specific topics like designing for people with cognitive problems of various stripes, low vision, photosensitive epilepsy and similar conditions, motion sickness, and all sort of other less common neurological considerations. The default state of UI design is not adding anything unless it adds something specific and justifiable and doesn't kill any other sort of accessibility. Lots of interfaces violate those rules. Lots of interfaces are not designed by UI designers. Pointing to bad practices in those interfaces isn't an indictment of UI design or any of the practices that UI designers have. Your refusal to acknowledge all of this doesn't oblige me to gather empirical evidence to defend it.

I also wouldn't go gather a list of citations to defend the concept of OO programming to a crowd of non-or-slightly-technical designers subconsciously influenced by groupthink and a few clojure evangelists they'd worked with, citing code they saw in shitty wordpress plugins and ignorantly insisting OOP was the problem. Right, surely it would have been good code otherwise.

In this comment section, literally zero of the very critical people, you included, has responded with anything aside from some combination of personal preference, developer folk wisdom, and off-base assumptions, all buttressed with mistaken confidence. If you refuse to correct that with all of the info at your fingertips, that's your problem, not mine.

> I'm sorry that I don't havee the opinions you want me to have so that I'm wrong.

Ok let's break this down. A copout is avoiding responsibility for something, and in rhetoric, it's when you avoid addressing a direct point with nonspecific challenges to the premise, or by changing the premise to something that will still let you be right.

For example, "Surely if you stumbled upon a bunch of designers making sweeping, arrogant, unsupported declarations about software development and the incompetence of developers, you'd trip over yourself to gather any evidence they demanded to prove your point when you corrected them on their foundational misgivings. Surely you wouldn't just tell them to go google it for themselves."

This is a very cut-and-dried statement. Here's your verbatim response:

"I would likely agree with them. Most software is quite bad, and most of it isn't designed much better. When I say a lot of designers are wasting time on this stuff, I base this on developers doing the same thing."

Rather than addressing the clear premise of how you'd respond to sweeping, arrogant, and unsupported criticism by arrogant laypeople, you change the premise to one where those designers are making criticisms you agree with. It completely avoids the obvious point, which is that you obviously wouldn't feel the need to cite your arguments in the face of baseless criticism from laypeople.

Go ahead and protect your ego by pretending I disregarded your legitimate response. Limber yourself up for some sort of 5 layer deep mental gymnastics about my being the one that was really changing the premise, or the like. But you're clearly not interested in honestly evaluating the veracity of anything you're saying, so I'm done here.

Most professionals get irritated when randos that think they're experts make a bunch of BS criticism of their professional practices. But developers are unique in that they get equally rankled by implications that knowing how to code doesn't give them expertise in everybody else's fields, too.

> Rather than addressing the clear premise of how you'd respond to sweeping, arrogant, and unsupported criticism by arrogant laypeople

Except I did address that in the next sentence[1]. Maybe you should read my comments before you write all this and accuse me of not reading yours.

> Thought so.

> The default state of UI design is not adding anything unless it adds something specific and justifiable and doesn't kill any other sort of accessibility

I did actually explain why it is not appropriate (that it communicates something specific which is contradictory to the way I often see it used). I'll add that it feels much worse than the native form widgets in websites where I often see it used, and it can degrade usability by being a non-standard input method. I also should point out that the null hypothesis doesn't need explaining. You've said yourself that the default state is not adding something, i.e. assume it is not appropriate until there is evidence to the contrary. The burden of proof is on you, and that is why I didn't deem that sentence worthy of specific reply.

> In this comment section, literally zero of the very critical people, you included, has responded with anything aside from some combination of personal preference

I don't control the actions of other people. That said, I did as you asked yesterday and looked it up, and the only study I could find said users didn't like toggles[2][3]. Wherever toggles are compared to binary non-toggle options, the other options are preferred though there is a degree of subjectivity to it. The only reason I didn't post it is because I assumed you were already familiar with the literature on the matter.

> Your refusal to acknowledge all of this doesn't oblige me to gather empirical evidence to defend it.

If it is as easy as you claim, it would be a lot less effort than writing all this and it would actually convince me you are correct (which I assume is your objective but it may not be). That seems like a much better option than calling me egotistical and stupid.

[1] "If the people making these claims were incorrect about something, I would simply explain why that is rather than saying "I have a bunch of experience that you don't have and there are some studies that prove your silly little feelings wrong. Your opinions are worthless compared to mine."" - James K (2024)

[2] Plaisant, C., & Wallace, D. (1990). Touchscreen toggle switches: Push or slide? Design issues and usability study (CS-TR-2557, CAR-TR-521). University of Maryland.

[3] Alyaa Al-Jasim and Pietro Murano. 2023. Designing User Interface Toggles for Usability. J. User Exper. 18, 4 (August 2023), 175–199.

Those would be great citations of we were talking about that. This entire conversation and the article it's responding to are discussing UI animation and not the merit of any given UI widget. You're obviously just going to just keep claiming that whatever you kicked the ball into is the goal, so I'm washing my hands of this pedantic mess. Enjoy.

The fact that users prefer a non-animated widget to an animated one seems exceedingly relevant my statement that users prefer widgets that react instantly over animated ones. I would even call it a strengthened goal. If you accept this conclusion, then I have shown more than I needed to prove.

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

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.

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

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

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.

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.

> you said you didn't notice a difference when it went away?

No, I said no difference "other than everything being suddenly faster". I'd say about 1-5% of animations are actually useful but I still wouldn't miss most of them.

> There's a lot of data out there that says otherwise

I would love to see that data. Not sure what your opinion on Gimp's UI design or its popularity has to do with the value of animations, or lack thereof.

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.

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

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)

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.

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.

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?

If you were colorblind that could be harder to answer (plus, it seems like a lot of designs have color "themes"). Checkbox is probably best.

lets ask someone who's colorblind

Red green colorblind checking in. In the case of a toggle, left is off, right is on. Up is on, down is off. Red tends to have less chroma, so dark is off, light is on if there aren't any other cues.

While that seems to be more common by a fairly large factor, in a quick search of images of toggle buttons there were at least two examples of left being on already in the top 10 for me.

I also found a few that had both variants in the same image, and a few examples where from the image alone I couldn't tell if my life depended on it whether they are in the left or right position, and what that means because there's no shading or geometrical hint as to which part is meant to be the actual toggle.

I wish you were right and that this was consistent, and when I read it I did that image search because I hoped you were and that I somehow just hadn't realist. But sadly it's not consistent.

That said, the same image search also demonstrated people managing to mess up the equivalent of a checkbox too (by changing the label, so it's not clear if it needs to be "ticked" to disable the state currently indicated by the label) so it's clear the problem isn't just checkbox vs. toggle.

>>Up is on, down is off

That depends on where you are from, in some regions light switches are on when up and in other places they are off when up

I am profusely colorblind, and it's infuriating when people only use colors to indicate something.

Please for the love of god give me a checkbox over a red/green slider toggle. Shapes, please, shapes.

I'm colorblind too but I don't pretend that it's a big deal, because it's not even a daily occurrence where I'm completely stumped by color and am blocked from doing something. Yeah, charts and graphs can be annoying sometimes, but I don't expect 90% of the world to bend around me because my sight is sub par. I loathe colorblind people who act like it's a disability. It's a slight inconvenience sometimes.

Adding extra differentiators also helps people with other kinds of vision problems. The benefits of accessibility often go beyond the initial target audience.

300 million people with some form of color blindness, and for a minority of those it's much worse than others. It's great your vision doesn't affect you most days, I hope you live a happy life.

For me, it's pretty annoying having to screenshot applications every few days, to be able to drag it into a color picker to be able to see what is actually on the screen.

It's pretty annoying being in a Zoom call, in a tense customer call trying to debug something, and then having to screenshot a Grafana dashboard and drag it into a photo editor on the fly to understand what a customer is telling me - or have to divert the already tense conversation to 'sorry can you tell me what I'm looking at, my vision is fucked?'

It's pretty annoying always being that inconvenience-to-others person asking for a link to the google slides, because I can't tell what is being shown on that pie chart.

And I get it, I'm in a minority of minorities here. And it's not like 'wow colorblindness has ruined my life now I can't cook or clean myself!' - so I understand where you are coming from with 'it's not a real disability'

But like, I'm not asking for you to go and construct a concrete pathway up a mountain here.

I'm just asking that maybe when you are quickly adding 'a slider that indicates on/off using nothing other than color' to your shitty web app, that maybe you could just go with a checkbox instead? Or keep the slider and all the colors, but just add `on` and `off` labels to it too? Or add a hover text that says it's 'enabled'? Or at least steal Apple's slider colors instead of coming up with your own low-contrast ones?

And yeah, I get it - we live in a world of 'omg wow I got glasses for christmas and now I can finally see color through my tears again!!!' social media garbage content. I just want to be able to know what a button is going to do when I click it.

But, making UIs tuned for colorblind people make it easier also for others - colors should be distinguishable easily.

Depends on what it’s controlling. The tune of my car? Red = performance, green = eco-mode.

The valve on a pipe? Red means “stop” (off) and green means “go” (on).

What about a heater? Does red mean hot? Or stopped?

Sibling comments cover colorblind users, but those concerns also apply to most e-ink users as well.

In fact red and green are generally not used for flow in a pipe because they have specific meaning for electrical equipment - green denotes an open circuit and red an energized one. This can be extremely confusing with something like an MOV so convention us to avoid red and green on valve position, pipe fill, etc.

Am I wrong in thinking that checkboxes/tickboxes/whatever-one-calls-them are ubiquitously understandable across cultures from both an interpretation and interaction perspective? If so, it wouldn’t be the first time I’ve made this assumption/mistake so I’d be happy to hear about it!

If not (and I am right in thinking these are globally understood), then there’s a clear advantage of the checkbox over the switch in that it doesn’t depend on any color recognition to convey the current state. This is a huge win - I have definitely encountered UI controls where the current state was not at all apparent.

I happen to use an iPhone, and haven’t personally had any issues interpreting the “switch” state nor the checkbox, but what if you’re color blind or from a culture where the color doesn’t necessarily mean what you think it does?

Edit: clarify intent

Checkboxes also have a fundamental dependency on the label to assist them with their affordance: a label for a checkbox should almost always be in the form of a yes/no question: “are you hungry? [ ]”

The “checked” box is an affirmative, empty is a negative. A checkbox without a label is useless because it has no context.

But I constantly see checkboxs without the question label. Think back to all those control panels and settings windows youve seen where the label for a checkbox is something like “animations [ ]”. Does that mean they are on by default? Does checking the checkbox switch them on or off?

Now compare with this “animations? [ ]” checking the checkbox has now become an answer to a question

> But I constantly see checkboxs without the question label.

Properly so.

Imagine every real-world appliance power toggle was labelled "Power?".

Real world appliances dont use checkboxes to power toggle

Checkbox is nearest in equivalence.

Not color choice, but existence of color. Some people have trouble distinguishing between red and green.

Black and white is easy - checkbox is understandable quicker than a toggle.

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

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

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

The shadow is around flat piece of paper of zero height, levitating off the background, casting shadow 360 degrees all around. No physical lighting set up could produce this effect.

Exactly. "Environmental cue" my ass :)

Isn't that the effect you get when you have a large diffuse light source directly above?

Not with a "flat piece of paper of zero height"

If you have a diffuse light source, let's say 8dp, directly above the component and the component is also 8dp above the background, then it'll look right for one component.

To account for the lack of parallex effect in the shadow when there are multiple components, you will then need a telephoto lens zoomed through the light source from a huge distance. I think we'll need a ring light.

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.

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

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

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

Completely agree. And in 99% of cases, an instant indicator is enough and you don't need an animation.

The few places where animation makes sense are places where it is natural. For example, smooth scrolling and scroll acceleration in touch interfaces have to be animated to work, and they actually improve usability by allowing the user to work less.

I think most modern user interfaces are designed to look great for people who aren't actually using them, i.e. in demos and in stores where you pick up a phone to look at. In that case flat UIs with smooth transitions and shadows will, to the naive eye, look way more polished than UIs with proper contrast and no animations. This is also the reason that TVs come with ridiculous default settings for sharpening, contrast and frame interpolation, not because it actually is better, but because it looks better in the store and therefore sells better.

But UIs that you use every day shouldn't look great, they should allow you to get actions done as quickly as you can think of them, and effectively serve as an extension of your thought process.

Feedback affects latency when working fast. Feedback is in the critical path because the user can't look away until they've confirmed they made their input correctly. To do otherwise risks desynchronizing their mental state from the computer's state.

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

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.

I don't know about you but I probably wouldn't notice if my light switch suddenly moved to the opposite position instantly instead of in 50ms or something.

And animations wouldn't be quite as annoying if they actually were that fast.

You might not consciously observe how your light switch transitions to the opposite position, but I’d argue that most people still have an immediate and intuitive understanding of how both end-states of a light switch are related to them applying physical force onto the switch.

The toggle transition is supposed to resemble this notion, and aims to allow the user to build up an analogous mental model of cause and effect.

To me, this sounds like a valid and worthwhile idea in general. That animations are not always appropriate or fitting, or that they sometimes are laggy and sluggish, is a different story.

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?"

100ms is more than enough to break the joyful feeling of the computer becoming part of my own body, like a hand tool or a bicycle. Humans are adapted to tool use, and don't need to consciously think of the position of tools they're using. But this effect only works if the tool moves like an ordinary physical object. If you move a pencil, it just moves. It doesn't move and then move again because a designer wanted to play an additional animation after your movement. Until we have direct neural interfaces, all UI animation playback is unrealistic, because it's adding to the physical movement of your fingers, not replacing it.

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

In the real world, toggle switches cannot jump instantly from one state to another but on a computer they can because of completely different mechanics.

Either we want to resemble the real world or we don't or it depends on what is currently fashionable.

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

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

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

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.

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.

>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

This is a problem if using "tri-state" checkboxes. Don't. They're confusing.

It is not a realistic problem for two-state checkboxes.

I'm from nordic country, and yes, I too have seen the "checkmark" to indicate mistake on school work as listed on the Wikipedia page and attributed to Sweden and Finland. I've however also seen that on my son's school work in the UK. And I've seen it used for correct. And for just "I've checked this".

It is not culturally consistent, and usually appears to be more indicative of a personal marking style.

And almost only in that kind of context.

Outside of that context, a checkmark is still mostly used as a positive confirmation across the Nordic countries too. You may want to make sure that the wording of the label does not give room for thinking you can tick it to answer "no", but that equally applies for a checkmark.

To make sure I wasn't overlooking some difference between Norway (where I grew up) and Sweden, I just checked aftonbladet.se - one of Swedens largest newspaper, and their signup page for example uses checkmarks to positively indicate the presence of features in their Swedish ad copy.

On a form it certainly is consistently meant to indicate "selected", just as an "x" is, in those countries as well unless the form explicitly says otherwise or indicates you can use both.

The only confusion arises if both are valid states because you've used a tri-state checkbox. So don't. They're confusing everywhere.

Maybe it's not universal, but the use of checkmarks outside boxes to indicate "wrong" in some contexts is entirely irrelevant to the interpretation of checkmarks in boxes on a form where the options are not-marked vs marked.

Sure, if you are designing a UI where you are displaying corrections to something, don't display a checkmark - probably irrespective of whether you include a box - without some additional indicator of whether it means right or wrong.

That’s a very fascinating detail that I never knew about! Thank you for sharing and the detailed explanation.

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.

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

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

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.

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.

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.

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.

Checkboxes can usually be toggled by clicking/tapping on the label. That may not resolve all criticism, but I'm just saying.

True. Ideally you put some "event received" indication across the whole trigger area, e.g. that little Android ripple animation. Certainly does not hurt to do the same (whole area clickable, and with visual feedback) even when your designer insisted on fashionable slider-toggles.

Subtle things like that greatly reduce the mental background load for the user, but that's impossible to quantify. Chances are you don't consciously notice when it's missing even when in theory you are fully aware of the concept.

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

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?

Microsoft's Android RDP client does this, the biggest issue is that it's not expected behaviour.

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

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.

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.

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.

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

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

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

Controlling a computer at maximum speed inevitably means occasional fumbled inputs. If I don't detect these, my mental state will desynchronize from the computer's state, resulting in confusion and potential data loss. Therefore I can't look away from the checkbox until I confirm it changed state. Any animation slows down this confirmation, so it wastes my time.

Professional StarCraft players take about 200ms per action, which is about the reaction time of the human visual system. If you set your time constant to that (1/e in 200ms, which would be an extremely sluggish UI) then your UI elements will have moved by 15% in 33ms. A more reasonable response (1/e in 50ms) will have moved by 50% in 33ms. My personal favorite curve is just "move 50% per frame."

I'd love to see what your day looks like if you've optimized it to require professional Counter Strike reflexes to activate toggles.

That 200ms is the natural human delay. A "reasonable" 50ms animation is in addition to that, so it's equivalent to making the user 25% slower. It's similar to moderate alcohol intoxication.

I personally use 72Hz keyboard autorepeat, which requires both low latency and predictable latency to use effectively.

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

It's delaying the feedback I use to know if I clicked correctly.

You know that as soon as you see the first frame of movement

That's a very small change that's a lot harder to see.

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

They are literally covered by my finger, I can't even see them.

Are they though? I usually use dev mode on my phone to turn off most animations because I find them needlessly distracting instead of satisfying. If I can't disable it, at least let me speed it up

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.

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

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