Not just ordinary people. I see the same behavior daily on older tech people, who fail to notice the (ever shrinking) browser loading indicator.

Honestly, it seems like Safari is the only browser that still cares to show a visible loading indicator, that takes up the whole address bar in a bright blue color, last time I checked.

Chrome and Firefox seem bent on a war to see who can infuriate their users the most, by removing one of the most important pieces of feedback on which the web experience is based.

As a result, we (the devs) need to add a ton of server-side checks to discard the multiple clicks that users invariably make, because they can't see that their first click went through.

Some times I'd like to know what the browser people smoke.

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.

Not to get further off topic, but: Huh? "Full stop" just means "end of message". It's an amusing leftover from telegraph technologies that people sometimes use for emphasis, but it doesn't have a literal meaning more than just "end of message".

On mobile, this is more difficult - the user's finger is obscuring whatever button they hit from view, so I kind of understand the "ripple" after the button is released (and ostensibly the user's finger has moved away, thus allowing them to actually see the ripple).

Still, unnecessary delay is infuriating on desktop apps. I agree feedback is important, but I don't accept the premise that latency is required to provide feedback.

However, if I've performed a destructive action, that is perhaps only reversible temporarily, then I absolutely don't mind being briefly interrupted to see a "trash" animation.