I inherited a React codebase that was littered with setTimeout() for no apparent reason.

Bad race condition protection or trying to impose a sense of gravitas through loading times?

I think setTimeout() is a bad code smell because it very often introduces race conditions. Fortunately async has reduced the need for it.

Recently worked on an iOS app with the exact same thing, delays inserted on every write which was basically instant as it was writing to SQLite. Client refused to remove it too, you need to pick your battles as a freelancer to get anything done, so I left them there.

If you are lucky it is to give the illusion of the app working hard. If you are unlucky they are "fixing" race conditions.

Wonder how often this is the case. Especially a couple of years ago, in early SPA time, show 1s spinner every page navigation. shudder

Do you work for TurboTax by any chance? :)

No, but I'm aware they do the same thing for psychological reasons. Our road to hell was much less formal (Business: "I like the way it feels").

Perhaps you can reduce the animation time by 5% every month. One day people will have gotten used to the faster behavior. Eventually you can remove it without anyone feeling that something is off.

And brag to management that you made the app 100% faster.

On the opposite side of jarring there are times where an app refresh action works so fast that users think that it's broken since they didn't visually see a change (even though it did refresh and there is nothing new to show).

My solution to that is to simply have a last updated time on the page with precision down to seconds. Just update it to the current time every time there's a response from the server even if it's empty.

You’re thinking way too much like an engineer. Humans aren’t robots. Your solution would work great for a JSON payload, but not well for humans at all.

Your solution adds complexity to the page content with very little, if any, payoff. It requires the user to be aware of the precise time, to be aware of whether a very small region of the page has changed ever so slightly, and does not provide any additional value beyond acting as a poor proxy for whether the user’s attempt to refresh did anything.

A short loading animation is easily visible to the user (we’re great at seeing motion), it’s immediately obvious what it means, and it vanishes as soon as it’s no longer relevant. It communicates exactly the necessary information, no more, no less.

"Wait did the page actually refresh? I better hard refresh just be to safe..."

For this reason the software I work on pops up a subtle (and auto dismissing) little confirmation toast.

I find a small acknowledgement that the thing works is better than just having an arbitrarily long loading indicator.

This is quite a well know pattern for flight ticket aggregators.

A long time ago, I worked on an app that processed a lot of data and the PM wanted to make the user feel that their actions are impactful. So in the specs some loading states needed to appear for at least 1second. Just to make it look the work was "hard"

Junk apps have taught me that a spinner that takes too much time could be an indication of failure though. The user will be inclined to refresh or close the app.

Same, but only if it "looks like" the app expects it to take a short-ish amount of time. If your operation will take more than a few seconds, the app can include text saying "This usually takes a few minutes" (or whatever is appropriate), and I'll know that a long of a delay to expect before I think something's wrong.

> though you may opt for a spinner if a progressive operation is consistently, predictably very short

For greater guidance on this, the Nielsen Norman Group says thusly:

> Use a progress indicator for any action that takes longer than about 1.0 second.

> [A looped loading animation] should be reserved for actions that take between 2-10 seconds. For anything that takes less than 1 second to load, it is distracting to use a looped animation, because users cannot keep up with what happened and might feel anxious about whatever flashed on the screen

> Generally, percent-done progress indicators should be used for longer processes that take 10 or more seconds.

https://www.nngroup.com/articles/progress-indicators/

> Spinner vs progress bar is not short vs long operation, it's non-progressive vs progressive operation…

Spinners are typically used for "indeterminate" operations while progress bars are typically used for "determinate" operations¹.

"Progressive" is a less useful adjective here because indeterminate operations progress too, and it's just that their total duration can't be usefully estimated.

And as you note these aren't hard-and-fast rules, and a spinner is generally a perfectly fine choice for short determinate operations.

¹ Progress bar controls typically have an indeterminate flavor too, and these can be mixed. For example, you'll typically see an indeterminate form of a progress bar until a total duration can be estimated, at which point the progress bar will change to its determinate form.

>Progress bar controls typically have an indeterminate flavor too

Good point - I was simplifying by referring to all progressive animations as "progress bars" and all non-progressive animations as "spinners".

>indeterminate operations progress too

I normally think of "non-progressive" and "indeterminate" as synonymous in this context. If the UI can't tell what fraction of the whole has been completed by any metric (which could even include best guesses based on historical data), I refer to that as non-progressive or indeterminate, interchangeably.

Cool, I figured we were just using different words for the same thing. I learned a lot of this stuff in the "Inside Macintosh" days, so my UX argot tends to align with it. https://developer.apple.com/design/human-interface-guideline...

Even determinate progress bars are challenging because they typically represent a portion of a known measure that doesn't necessarily match with the user's measure of reference. Example: "75%" complete might mean 75 of 100 files updated while the user is thinking "It's taken 15 minutes so 5 minutes longer.

Absolutely! Is there anything more painful than a progress bar that "hangs" at 95% for 30% of the total time?

> So now, even if the operation finishes instantly, we show the animation, wasting the user's time.

I thought it was fairly well accepted that small deliberate UI delays (for things like loading spinners and animations) can in many cases result in a better user experience. Of course, that would depend on how long this animation is that you're talking about.

You're absolutely right, in some cases. It depends on who you are and what kind of software you use. Delays or animations can improve communication between the UI and the user. Or, they can be pointless and frustrating, e.g. if the software's task feels utilitarian, and there's no confusing or hard-to-perceive transition that an animation would help to bridge, and the user knows the animation is functionless.

> They didn't want to skip the progress animation because they liked how it made the app feel like it was doing something, and also if the user got the result instantly, it was "jarring".

Like hard bristle toothbrushes. Hard bristle toothbrushes are not good for your gums. So why do they make them? Because customers like hearing the sound of the toothbrush brushing. They like hearing it do something.

I had this on a project recently, they wanted the spinner to appear for at least 5 seconds even if the operation took less than that. Most of the time it took under 2 seconds - made me so annoyed.

I think the optimal number for a minimum loading animation duration is closer to 0.3 seconds, I can't look up the actual number I use ATM.

A proper UI is not about telling people how the things are done, it's about managing/meeting users' expectations on how the things are done, so it's pretty valid to let the users wait longer if that makes them feel better (not saying there are no better ways), pretty much like a placebo.

I hate software bloat and thrown away milliseconds, but even then I realize that our visual cortex is really good at noticing movement, but hasn't had any experience in the last millions of years with stuff just popping up out of nowhere or teleporting. I know nothing about usability but just from knowing that, and my own experience, I can't dismiss any and all "useless" animations out of hand. There was a time when we couldn't afford them, now it depends.

Maybe this would be a useful way to look at it: if the average disorientation caused by instant change (which also depends on whether the change is predictable, makes other things change position, etc.) takes longer to recover from than the shortest animation/fade you could come up with, have a transition.

(but even then it doesn't hurt to gate all of that behind a global configuration option, IMO, and if you want to be really fancy make it a float, not a boolean)