Earlier quoted context omitted.
> I also find the ripple effect[1] when pressing things to be infuriating. Just do the action I've asked, don't do this animation and delay the action by half a second. Again, this is somewhat irrational, but it still bothers me. It is not irrational to want your device and the software you use on it to be as high-performance as possible. In my opinion, unless we're talking about a game, software should always avoid…
Yes, and no. While nobody likes excessive animation, it is very important to let the user know their input was received. It's why the cursor changes on mouseover. It's how you know if the app is crashed, or merely processing something you requested. I've seen a million times in UX testing where ordinary people go click... wait... click click click click click because they didn't receive any feedback to an action. At…
I said, "Of course, if an animation is playing while something else is happening, that is acceptable." Yes, play an animation while actual work is happening. That provides the feedback you are describing, which is useful if and when the application cannot respond to user input immediately.
However, my point was that many applications, due to laziness of designers and/or programmers, play an animation and then begin to execute the work requested. The facile argument made by these designers is that the animation is relatively brief—say 300ms—so it's not a "big deal." But I contend that delaying the initiation of requested execution is disrespecting the user's time, regardless of how long the delay is.
To reiterate: beginning the work effort and then concurrently playing an animation is good and should be encouraged. Playing an animation to completion and then beginning the work effort is bad and should be avoided.
The theoretical ideal is to respond in 0ms. If the work takes 50ms, it's best to start the work immediately then start playing an interruptible animation. The user may see a couple frames of the animation. Far worse to play a 300ms animation to completion, then start the 50ms of work.
> I've seen a million times in UX testing where ordinary people go click... wait... click click click click click because they didn't receive any feedback to an action.
Agreed! While doing lengthy operations, play an animation and disable the button. But don't delay beginning the work until after the animation completes, even if that animation is only 300ms.
> In the real world, nothing is ever "full stop." You should purge that phrase from your lexicon.
I said "Disrespecting the user's time is disrespecting the user, full stop."
I stand by the decisiveness of that statement. In my opinion, disrespecting the user's time is equivalent to disrespecting the user. I will retain the phrase in my lexicon, thank you.