UI animations actually do have one valid use: clarifying UI state changes to third parties.

When you're the only person using the computer, UI animations are pure time-wasting anti-features. You obviously know how the UI state changed because you're the one who requested the change. If the UI state changed without your explicit request, that's a bug that needs fixing. But somebody viewing your screen remotely can't see which keys you're pressing, and they don't know what you intend to click on before you've actually clicked it, so to them UI state changes can be surprising. Animations can help them follow what's happening.

Of course, animations should be disabled by default, because most computer use is not performed for an audience, but having the option to enable them is occasionally useful.

▲

bobbylarrybobby 6 days ago | parent [-]

> You obviously know how the UI state changed because you're the one who requested the change.

We must be using different devices because mine often fail to register my intent and in that case the failure to animate is often the only signal I have (that doesn't take more than a few seconds to register)

▲

mrob 6 days ago | parent [-]

I use keyboard and mouse. Unlike touchscreens, these always work reliably.

And if you're using animations as indications of correctly functioning hardware, why not just use useful work as the indication instead?

▲

bobbylarrybobby 6 days ago | parent [-]

Useful work takes longer to do than the animation that indicates the work has been queued.

	▲	mrob 6 days ago \| parent [-]
		None of the animations described in the article are of this type. Opening a text input area or changing desktop should be instant on all modern hardware. If you genuinely have something that can't be accomplished within one frame it's acceptable to display a progress bar, but I don't consider progress bars to be a "UI animations".