5 ms·

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 si

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.

cwillu 4y ago
s/one of those/one of the 100% of those/g #edited for clarity
zagrebian 4y ago
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.
- arcbyte 4y ago
  All animations are an issue.
  - zagrebian 4y ago
    Everything can be an issue. There is no one-size-fits-all solution.
- ben_w 4y ago
  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-How-do-I-enable-disable-animations- 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).
  - zagrebian 4y ago
    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.
  - zimpenfish 4y ago
    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...)
  - wruza 4y ago
    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.
- petee 4y ago
  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.
tgsovlerkhgsel 4y ago
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.
- dredmorbius 4y ago
  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.
- Etheryte 4y ago
  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.
- ohgodplsno 4y ago
  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.

cwillu 4y ago

s/one of those/one of the 100% of those/g #edited for clarity

zagrebian 4y ago

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.

arcbyte 4y ago
All animations are an issue.
- zagrebian 4y ago
  Everything can be an issue. There is no one-size-fits-all solution.
ben_w 4y ago
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-How-do-I-enable-disable-animations- 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).
- zagrebian 4y ago
  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.
- zimpenfish 4y ago
  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...)
- wruza 4y ago
  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.
petee 4y ago
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.

tgsovlerkhgsel 4y ago

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.

dredmorbius 4y ago
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.
Etheryte 4y ago
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.
ohgodplsno 4y ago
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.