6 ms·

Spinner vs progress bar is not short vs long operation, it's non-progressive vs progressive operation (though you may opt for a spinner if a progressive operati

Spinner vs progress bar is not short vs long operation, it's non-progressive vs progressive operation (though you may opt for a spinner if a progressive operation is consistently, predictably very short). In the software world, designers need to be engineers (or work very closely with engineers, very early in the process). We recently had designers give us a nice looking progressive indicator for a non-progressive operation that happened to take a somewhat predictable amount of time. Business loved the look and visual feedback. Then we got use cases where the operation could be instantaneous. 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". So now, even if the operation finishes instantly, we show the animation, wasting the user's time.

a-r-t 4y ago
Do you work for TurboTax by any chance? :)
- happytoexplain 4y ago
  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").
  - geysersam 4y ago
    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.
    - franky47 4y ago
      And brag to management that you made the app 100% faster.
geysersam 4y ago
Wonder how often this is the case. Especially a couple of years ago, in early SPA time, show 1s spinner every page navigation. shudder
caradine 4y ago
I inherited a React codebase that was littered with setTimeout() for no apparent reason.
- bmelton 4y ago
  Bad race condition protection or trying to impose a sense of gravitas through loading times?
  - robocat 4y ago
    I think setTimeout() is a bad code smell because it very often introduces race conditions. Fortunately async has reduced the need for it.
- jamil7 4y ago
  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.
  - deleted 4y ago
    [deleted]
- kevincox 4y ago
  If you are lucky it is to give the illusion of the app working hard. If you are unlucky they are "fixing" race conditions.
psygn89 4y ago
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).
- Arrath 4y ago
  "Wait did the page actually refresh? I better hard refresh just be to safe..."
- ziml77 4y ago
  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.
  - deleted 4y ago
    [deleted]
- charrondev 4y ago
  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.
- deleted 4y ago
  [deleted]
simonmales 4y ago
This is quite a well know pattern for flight ticket aggregators.
deleted 4y ago
[deleted]
elboru 4y ago
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.
- mort96 4y ago
  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.
lelandfe 4y ago
> 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 spake 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/ https://www.nngroup.com/articles/progress-indicators/
CharlesW 4y ago
> 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.
- happytoexplain 4y ago
  >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.
  - CharlesW 4y ago
    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-guidelines/components/status/progress-indicators/ https://developer.apple.com/design/human-interface-guideline...
- wintogreen74 4y ago
  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.
tshaddox 4y ago
> 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.
- happytoexplain 4y ago
  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.
jonnybgood 4y ago
> 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.
simonbarker87 4y ago
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.
- antifa 4y ago
  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.
merlinran 4y ago
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.
howaboutnope 4y ago
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)

a-r-t 4y ago

Do you work for TurboTax by any chance? :)

happytoexplain 4y ago
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").
- geysersam 4y ago
  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.
  - franky47 4y ago
    And brag to management that you made the app 100% faster.

geysersam 4y ago

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

caradine 4y ago

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

bmelton 4y ago
Bad race condition protection or trying to impose a sense of gravitas through loading times?
- robocat 4y ago
  I think setTimeout() is a bad code smell because it very often introduces race conditions. Fortunately async has reduced the need for it.
jamil7 4y ago
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.
- deleted 4y ago
  [deleted]
kevincox 4y ago
If you are lucky it is to give the illusion of the app working hard. If you are unlucky they are "fixing" race conditions.

psygn89 4y ago

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).

Arrath 4y ago
"Wait did the page actually refresh? I better hard refresh just be to safe..."
ziml77 4y ago
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.
- deleted 4y ago
  [deleted]
charrondev 4y ago
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.
deleted 4y ago
[deleted]

simonmales 4y ago

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

deleted 4y ago

[deleted]

elboru 4y ago

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.

mort96 4y ago
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.

lelandfe 4y ago

> 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 spake 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/ https://www.nngroup.com/articles/progress-indicators/

CharlesW 4y ago

> 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.

happytoexplain 4y ago
>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.
- CharlesW 4y ago
  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-guidelines/components/status/progress-indicators/ https://developer.apple.com/design/human-interface-guideline...
wintogreen74 4y ago
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.

tshaddox 4y ago

> 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.

happytoexplain 4y ago
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.

jonnybgood 4y ago

> 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.

simonbarker87 4y ago

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.

antifa 4y ago
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.

merlinran 4y ago

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.

howaboutnope 4y ago

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)