Hacker News new | ask | show | jobs
by Etheryte 1338 days ago
I seriously believe this is one of those issues where the browser should enforce the user's preference over what websites want. Rather than try and get every site worldwide to implement this consistently, having the browser disable animations based on the OS-wide configuration would be an easy win for everyone.
3 comments

It's almost impossible to reliably distinguish animations required for a web site to work properly from animations and changes that can and should be disabled.

For example, try to distinguish (from "definitely should be blocked" to "definitely can't be blocked without breaking things"):

- An ad mascot hopping up or down telling you to click it

- A loading spinner spinning

- A progress bar

- Information you're waiting for being loaded once some process completes

You could disable all CSS animations and GIFs, but that will kill the loading spinner and risks that the next ad mascot will be written in JavaScript. And it will still not stop one of the biggest offenders in terms of blinking, ads that are being replaced by a new ad every 30 seconds.

I disagree completely. When implemented by the browser itself, it's straightforward to ensure all the relevant events are still fired without presenting the actual animation to the user. As for the list you brought up, a loading spinner spinning and the like is exactly what should be disabled. These are not interactions that are necessary for the site to function and they bring harm to some users.
If it moves spontaneously, it's unnecessary animation.

It is necessary for things to move only if:

- they are objects being dragged by the mouse (or finger in the case of touch input).

- they are the content of an animated image or video being played. (User preference needed there: auto-play or not.)

How does that address "Information you're waiting for being loaded once some process completes"?

Do you want to delay the entire page until absolutely everything is loaded?

Maybe you want some clever code checking that you only go from blank to filled, and you'd better have the size ready up-front?

What it would likely mean is that animations would get stuck in their starting state so you'd see no content. And no one would bother fixing it for the 0.001% of users who turned this setting on so customer support would advise you to turn animations back on.
If web developers would use the actual browser APIs instead of hacking around everything (manually setting the position of items at every frame cool cool cool), this setting would be respected.

See how it works in the Android world: anything that uses Animation, AnimationSet, ObjectAnimator, Compose animations, etc, all respect the system setting of animation speed (from 0 to 3x). As a developer, as long as you use the proper API, it'll work.

So, no, your ad mascot should be written with those APIs, and not using them should bring a massive performance cost that makes you think for a second or two about whether you're doing it right.

Spinners are a total antipattern. If loading is interrupted by an error, the spinner just keeps spinning. And there's no need to display progress every millisecond, 0.1 Hz should be enough.
> If loading is interrupted by an error, the spinner just keeps spinning.

Only if written incompetently.

Or if you disable javascript the spinner remains despite the content being complete under it. Fucking web devs!
How about just drop most of the frames? Let them animate and show users how it’s going every once in a while
My principle mobile driver is an e-ink device.

Whilst it's possible to support animation (and in fact does support video playback, at greatly-reduced image quality), at the higher-quality display modes most appropriate for text, all animation at < 1--2 s framerate, and virtually all animation outside actual paginated navigation (scrolling is possible, but ... unpleasant), really should die.

The prevalence of animations and video on the present web (the device supports web browsing, it's an Android tablet with an e-ink display) makes for an exceedingly unpleasant experience.

>that the next ad mascot will be written in JavaScript

The horror....

This would mean a) it will still animate regardless of setting b) there's a high chance it will spike your CPU load because your CPU cycles don't cost the authors of the ad money.
It has tangential costs, because a site which is slow or drains battery will lose at least some users or SERP positions and a site owner will take measures to rebalance that. All this already works through various metrics.
Haven't seen that work in practice...
> that the next ad mascot will be written in JavaScript

That's quite literally true already: https://nextjs.org/conf

s/one of those/one of the 100% of those/g #edited for clarity
Not all animations are an issue. Disabling all animations would be too much. That’s why the website needs to decide for each animation if it should be affected by prefers-reduced-motion. The browser cannot make this decision¹.

1. Maybe in 100 years, when we have powerful AI that and reliably identify problematic animation.

Counterpoint: iOS has this flag, Duolingo FAQ says this is the only way to turn off animations on iOS: https://support.duolingo.com/hc/en-us/articles/360058189572-...

Unfortunately, Duolingo ignores this flag for many animations, and more than half of the screens are still animated.

I find the animations Duolingo uses to be obnoxious distractions, and I want them to be actually disabled when I tell it this. I also want this kind of thing to be switchable on a per-app level, so that I have a way to override the (I assume) opinion of the art department or the marketing person that thinks these animations are engaging or fun without having to also disable the non-obnoxious animations my other apps have.

(Mind you, at this point I'm thinking Duolingo has been a lost cause for the last few years; although the courses seem to still be improving, the UX has been getting worse faster).

Speaking of iOS, Arc - whilst being a handy location/places tracker - has some of the worst UX I've ever seen. Doing almost anything involves swoops and fades and shifts - and this is with "Reduce Motion" turned on. If I suffered from motion sickness, I'd delete the app because it would knock me sideways every time.

(eg. to confirm an unconfirmed item, you tap on a coloured bar which then swoops a new pane from the right, shifts it up, zooms the map, and occasionally does a little blink refresh of the map. And you frequently get 4-5 of these a day, each one doing its little UI dance. God help you if you need to convert 10+ mis-identified transport segments to a single bus...)

Browsers could have a separate preference for disabling animations more strongly. But that would be different from the “reduce animations” accessibility preference. Those are two different preferences with different use-cases. You can’t merge them.
I have tried this iOS flag a few times, and every time it induced sickness instantly. It doesn’t reduce animations, it replaces them with nauseous fade in-out effect sometimes even in supported apps.

Turned it on to make phone/ui fast and instant, found out it just doesn’t. Idk what people with vision problems need, but personally I need animations (either fade or motion) to not exceed ~100ms.

Developers can't make that decision either - given the ability to override animations will end up with all the things still animated because "we know best"

A better option is to respect the user, and if your site really can't run without animation, then just show an error stating that...Which shouldn't be a problem considering how many websites refuse to work just because you are using a chromium alternative that is realistically supported but just isnt Chrome itself.

All animations are an issue.
Everything can be an issue. There is no one-size-fits-all solution.