zlacker

>>jakela+(OP)
Personally I would even speed up these animations. 300ms is too high. I prefer animations that are almost imperceptible. You might even only notice them if you take them away.

Anything longer than that I consider too slow.

>>prisen+Tn
I used to go for 250ms, now I go for 200ms. I find that about the sweet spot for UI transitions where it helps you to understand what’s changing and how and why. And if it doesn’t meet those criteria, don’t transition it.

200ms is also nice and short to write in CSS, .2s. I contemplated shorter, but I found that by 150ms a transition can start to feel like it’s a mistake, a brief rendering glitch, especially if the first few frames of the animation are dropped, as can be common (.2s is already down to only ~10 intermediate frames). It’s too short to get the benefits of an animating transition, but too long to be or look or feel instant.

>>chrism+Sv
I think if the animation "helps you understand what's changing and why", sometimes that's a sign that the change could be redesigned - moved to a different part of the screen, for example - so that it becomes clearer without needing to be animated.

For example, if pressing a "Save" button makes a "Save successful" toast appear on top of the screen, it's tempting to animate it in, so that the user notices it. But it's better to replace the button text with "Saved" and gray it out, which achieves the same goal and feels great without any animation.

>>cousin+Ox
With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!). But even then, I find a little bit of animation that moves the "saved" text away from the button to indicate where it's come from can be really helpful for intuitively connecting the two interactions. The animation should be fast (100-150ms max, often as low as 75ms), and subtle (just a slight step to the side), but it gives the user more of a feeling about what's happening.

>>MrJohz+AY1
> With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!).

There is no problem with the button changing states as long as it only happens after the current document state was successfully saved and becomes active again when you make changes to the document. That way the button doesn't represent the outcome of some action but the sate of the document - unsaved changes = button enabled, no unsaved changes = button disabled.