AutoAnimate – Add motion to web apps with a single line of code | Hacker News Reader

AutoAnimate – Add motion to web apps with a single line of code

github.com

183 pointsfeross37 comments

Good on them for listening to prefers-reduced-motion [1]. To the folks complaining about motion, consider configuring your operating system to reduce motion -- make your user agent work for you!

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

One might also consider reducing animation time. I did this on my android and it made it feel like a new phone again.

From what I understand of the accessibility issue, reduced motion is about reducing motion, so I don't think that making the motion faster/more visually intense would help those who need the reduced option.

I think this is a different thing from people who just want things to feel faster/snappier, vs those who have an accessibility need.

I really like disabling animations on my phone. Everything is so fast, it's amazing. Reminds me that hardware has improved the the past decade.

Particularly with Android 12, wow. So many animations added, and they run so, so, so slowly. There were a number of rather severe UI glitches for the first few patches, but it's alright nowadays. Beyond 12's other major issues, that is - I highly recommend not upgrading. Maybe 13 will actually fix some of it.

I switched mine to x0.5 (halved). I wish x0.25 was possible, but that was the lowest option and completely turning it off felt a little janky to me.

(If anyone is looking for the option: it's in the developer settings and there are two entries, one for windows and another for general animations.)

I did that a week ago, just stumbled across the option in the accessibility options. Now I wish I had done it many years ago (is it a new option?). There's not a single animation that is better than its own absence.

The worst thing is that it isn't respected by many apps and browsers.

Yeah, generally speaking many things with "momentum" from a touch will still have momentum (probably a good thing) and anything doing custom animation code will be unaffected (not a good thing! use the framework please, app programmers!).

But it does at least get rid of that awful stretch-bounce animation on scroll views basically everywhere. That alone is practically worth it.

Unfortunately, prefers-reduced-motion is fingerprintable even with Javascript disabled:

https://news.ycombinator.com/item?id=30237846

In addition, "reduced motion" is only a partial solution to the problem of unwanted motion. I would much prefer zero motion. In Firefox, it is possible to disable CSS animations globally, by adding the following to both chrome/userContent.css (with the appropriate namespace header) and chrome/userChrome.css in your profile directory:

  *, :before, :after {
    transition: none !important;
    animation-delay: 0ms !important;
    animation-duration: 0ms !important;
  }

This also requires setting toolkit.legacyUserProfileCustomizations.stylesheets to true in about:config

I have been disabling animation in userContent.css (which affects websites) for years with no problems. More recently, I realized I could also disable it in userChrome.css (which affects the Firefox UI). This exposes what appears to be a race condition bug involving tabs. Occasionally, a tab's close button will stop responding, and that tab will also become impossible to drag to new positions. This can be worked around by attempting to drag a different tab, releasing that drag, then immediately dragging the frozen tab to an empty part of the tab bar, which will unfreeze the tab.

I consider this minor annoyance well worth the benefits, which includes disabling animations that would be permitted with prefers-reduced-motion, such as the sliding of the "Find in Page" panel. It is possible that setting an extremely brief animation might avoid the bug without showing visible animation but I have not tested this.

A little bit about how it works (from their docs)[0]:

> AutoAnimate is fundamentally a single function — autoAnimate — that accepts a parent element. Automatic animations will be applied to the parent element and its immediate children. Animations are specifically triggered when one of three events occurs:

> A child is added in the DOM.

> A child is removed in the DOM.

> A child is moved in the DOM.

[0]: https://auto-animate.formkit.com/

In their demo, I can click as fast as I want in the non-animated version, and add/remove elements as fast as I can click.

In the animated one, I have to wait for the animation to finish.

Seems like a poor example of when animation adds value.

Yeah if the use case is “user might need to click several times abruptly” time to NOT animate.

But there are places it works.

Afaik it allows setting the animation duration, which should help a bit

The non-animated version is horrible though. I have a hard time seeing what's happening even when re-ordering just one item so when would speedrunning it ever be useful? I think it's a good example where the trade-off between feedback and speed makes sense.

What kind of real world situation do you imagine mindlessly blasting an add button as quickly as possible? The animation seriously improves the users understanding of what is happening. Throwing that out to support millisecond speed button blasting is bad UX

In examples, when adding an item to the list, I see a brief flash of the target state, then it goes back to the previous state and then an animation happens (mobile safari).

Is there a way for the library to eliminate this “blink”? Or is this behavior unavoidable with current one liner approach?

This is possible to fix but probably not by using Resize/MutationObservers (as the library does) In Framer Motion we use React's layout effect to trigger the <motion.div layout /> animations (which are equivalent to this). The layout effect runs synchronously after DOM mutation and works cross-browser.

https://codesandbox.io/s/framer-motion-reorder-animation-bvi...

I don't trust the implementation of observers, usually in Safari, to reliably recreate this effect. I'm not sure it's even specced.

I’ve seen this on my own device (author of the docs site here) but after a force quit and restart of safari was not able to reproduce.

Would you mind if I asked a few questions?

- does your device have remote debugging enabled on Safari?

- was your phone in low-power mode?

- did you first access the site through a WebKit in-app browser panel before opening it Safari?

- what version of iOS?

- what model of iPhone?

Those are my leading theories for what contributes to the flash happening. If you force quit and restart safari and / or reboot your phone does it work as expected?

> - does your device have remote debugging enabled on Safari?

Do you mean “Web Inspector”? Yes.

> - was your phone in low-power mode?

No.

> - did you first access the site through a WebKit in-app browser panel before opening it Safari?

No.

> - what version of iOS?

15.2

> - what model of iPhone?

13 Pro Max

I did force quit Safari and I no longer see the brief flash of target state when adding items to lists. But I didn’t check if I saw that immediately before doing force quit, sorry. I’ll write if I ever see that again.

I just tried it in a different browser, firefox focus (also ios) and got the blinking; it was slightly different, there seems to be some other issue there too. BUT after force quitting ff focus, the issue is again gone.

I think this could be a decent alternative to Isotope's filter & sort magical layouts:

https://github.com/metafizzy/isotope

It was so popular back in the day but hasn't received any recent updates.

I didn't look into the source code, but I wonder how it handles animations when an element moves in the DOM? How does it know that if I remove and add a new element, that it is in fact the same element that has moved? Probably need to have a unique id attribute?

How much is this compatible with Blazor? (No npm or similar)

this would be awesome unfortunately it does not work for me (Brave browser)

Does not work for me either on Chrome.

If you’re going to use animations, there’s three reasons to do so:

1) it adds meaningful value to the ux (like that sorting example in the link)

2) it’s a micro interaction, like a heart lighting up when you like something, so it adds delight to the ux and I don’t have to wait for it to finish

3) it covers up other jank in the ux, like known slow processing or something

If you insist of animations, make them incredibly fast, otherwise we’re all going to be mad eventually.

It’s ALWAYS better to invest the time you’d have spent on animating shit to instead just make your app faster

The first example on the page is actually decent I think, visually showing the two elements swapping so you see where they moved to, but making it so automatic is going to be an irresistible temptation for many people.

That's a good summary of things to consider.

With that in mind, it seems pretty nice if a library can make simple animations much easier.

The demo shows some promising examples that tend to be common polish on, say, iOS. The simple sorting/delete ListView example is pretty nice compared to the instant changes with zero feedback it's compared to.

Meanwhile, web animations by hand can take quite a bit of thought even for basic things, like fiddling with CSS `transition` and ensuring your component lifecycle sees it through. Always ends up being a bit brittle, like having to duplicate CSS time durations with your JS components.

I'll have to play with it.

I dunno, by default things on the web just jump in and out abruptly. Browsers seem janky by default even when always fast.

I think just a layer of smoothness can help a lot.

I’d argue that the web is almost always janky, no matter how fast or slow.

things work great on 2000$ workstations and laptops, with low to no network latency, in a demo unburdened by the rest of garbage on the website

on a 8 year old device, with 200ms network latency, while the browser performs three hundred TLS handshakes with all the ads and tracking services... not so great

Page transitions on the web are just horrible. There is a reason that most websites these days are going for side sheets and pop up modals while apps still show real full pages.

Apps animate between making it look less janky and they also hold your position when you return while a web app will reload the whole thing including requests when you move back, losing your state and position.

Please don't. Animations should be added where they actually help the user, if you just animate everything you'll just make the user experience slower.

The first thing I do when using a new app or operating system is to disable all animations. I even wrote a Firefox extension just to disable the "smooth seek" of the code search tool OpenGrok because it slows me down so much. I hate animations on user interfaces with a passion.

Imo animations are an accessibility feature for people who can't follow UI updates very quickly and who need the smooth transitions to keep track of what's on the page where. They should be opt-in like high contrast themes.

<marquee> still works, what's the problem?

Sometimes it works.

Blink does not work :(

Easy to restore with two lines of CSS:

    blink { animation: blink 1s steps(1, start) infinite; }
    @keyframes blink { 50% { opacity: 0; }}

Maybe spend a minute looking at what the thing does instead of posting a knee-jerk comment based on the title or some tag line. This library animates immediate child addition/removal/movement of elements you attach it to, not “everything”.

That is wonderful! HN is really on a roll with amazing web tech.

Reply on news.ycombinator.com