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 one time this was one of Apple's UI priorities — feedback. Unfortunately, Apple has gotten away from a lot of its core UI values without a strong personality to enforce them.
>full stop
In the real world, nothing is ever "full stop." You should purge that phrase from your lexicon.
> 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.
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.
It's not like you can just skip writing those checks even if the browser indicator was more visible, people will still spam click and you still need to handle it correctly.
I don't know about 'older' devs, in my experience just about everyone else except the developer who wrote a particular slow function will spam-click if nothing happens after a little while when clicking on something.
> 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 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.
The RAIL* model for user-perceived performance does a really nice job of distilling rules of thumb for latency into a handful of specific metrics / perf targets.
Seeing as this subthread has already derailed into a discussion of expression, I'll take this opportunity to express my disrespect for the new trend of using the word "disrespect" as a verb.
> In the real world, nothing is ever "full stop." You should purge that phrase from your lexicon.
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".
It is interesting how the phrase's meaning has transformed. Nowadays people generally use it to add emphasis such that the previous statement is an absolute truth with no valid argument to the contrary.
Yep, it's a bit of verbal color to add emphasis to a statement. Much like declaring things that are actually quite ordinary and did not fill you with awe but are otherwise positive as "awesome."
In this context, I took "full stop" to mean "end of discussion." As if to dismiss all dissenting opinions and stifle further discussion.
As for the telegraph use, I'm aware of that. I have a background in amateur radio and in college a crusty old engineer taught me morse code to communicate over the maintenance department's secret building-to-building campus telegraph network.
It sounds strange to hear 'full stop' described as a leftover from telegraph technologies. To me, it's just what I call the dot at the end of a sentence.
In American English, 'period' is used in the same ways (indicating the end of a sentence and, like in the above case, to indicate that a matter is closed for further discussion).
It's the same as ending a statement with "period." As in, "We connect people. Period." said by a Facebook exec to justify their use of dark patterns. It's for emphasis.
Not only that, "period" is the American English word for the very same punctuation mark the other side of the English speaking world calls a "full stop".
Microsoft's UI toolkit in Windows 95/98/2000/ME/NT4/XP did a fine job of letting me know that I clicked on a button, and it added no latency to the interaction.
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.
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 one time this was one of Apple's UI priorities — feedback. Unfortunately, Apple has gotten away from a lot of its core UI values without a strong personality to enforce them.
>full stop
In the real world, nothing is ever "full stop." You should purge that phrase from your lexicon.