Should a "loading" text or spinner stay a minimum time on screen?

Question

In an app I'm building the user can click a button to load more content, which might take 1 second or up to X seconds (when X seconds passed I show a timeout error message). There is a "Loading" text (at the moment, it might end up being a spinner) that appears once the button is clicked and disappears when the content is loaded.

My idea is to show the loading state as soon as the user clicks. If the content arrives "too fast" the loading will appear for a very short time, so the user will know something was shown but won't be able to realize what it was (and look strange).

On one hand the content should arrive as soon as possible, but on the other hand, it might be strange to show some information without a minimum time (2 seconds maybe?) to assimilate it.

Any ideas of what is the correct way to go?

I am not looking for specific solutions on how to implement a loading state, @Majo0od provided a very useful link in the comments. I am looking for rationale and/or any relevant case or information if there is.

Answer 1

In this situation, the solution Facebook uses is great if you can do it. A "skeleton" of the page is immediately shown and then the actual content fills in the skeleton when it's available. The skeleton boxes are animated to show progress.

• If the page loads quickly, the skeleton is very quickly replaced by the actual content, and the user might not even notice the difference if the skeleton is close to the same size. It does not suffer from "flicker" or a jolting experience by immediately hiding a progress indicator
• If the page takes awhile to load, the skeleton shows the user what they can expect and is animated to show that work is being done in the background.

Here's a blog post breaking down how to achieve a similar effect. I know you weren't asking for implementation details, but this shows the effect in action: http://cloudcannon.com/deconstructions/2014/11/15/facebook-content-placeholder-deconstruction.html

Answer 2

Based on Jakob Nielson's research, I'd say 1 - 9 seconds is an acceptable time if you add a spinner and the minimum is 1 second.

See this article, Website Response Times:

The 3 response-time limits are the same today as when I wrote about them in 1993 (based on 40-year-old research by human factors pioneers):

• 0.1 seconds gives the feeling of instantaneous response — that is, the outcome feels like it was caused by the user, not the computer;
• 1 second keeps the user's flow of thought seamless. Users can sense a delay, and thus know the computer is generating the outcome, but they still feel in control of the overall experience and that they're moving freely rather than waiting on the computer. This degree of responsiveness is needed for good navigation.
• 10 seconds keeps the user's attention.

A 10-second delay will often make users leave a site immediately.

Another aspect you should consider is you should make a difference if you also have progress bars in the website. Please see this article for references, Progress Bars vs. Spinners: When to Use Which:

Spinners don’t tell users how long the process will take to load. If you use it for long processes, they’ll end up wondering if something went wrong with the app. The lack of feedback creates uncertainty which makes users assume the worst. They’ll assume that it’ll take a long time to load which discourages them from waiting. Impatience will set in and they may hit the back button or exit out of the app.

Answer 3

If this is really a problem (and I'm not sure that it is) then the easiest solution is to animate the removal of the loading spinner AFTER the content has loaded.

This way (let's talk hypothetically), if the content loaded in 0.05 seconds, the loading spinner is arguably only on long enough to be presented, not begin spinning, but the removal process could take a full second.

The removal animation can be a blend of fade and shrink, fade and move off, or anything else that provides enough screen time for the user to recognise the spinner. It should also convey the loading spinner is no longer needed, nor operational, and that the content is loaded and ready.

It should be clear the user need not wait for the complete removal of the loading spinner to interact with the content.

Why I don't think it's a concern:

If you use (and you should) a commonly recognisable spinner, even a tiny glimpse of it will provide enough information for the viewer to know what they've seen, and ignore it if the content loads super fast.

Answer 4

My usual approach for handling operations of unpredictable duration is to do the exact opposite of what you're suggesting: rather than forcing the "loading" indicator to stay onscreen longer than it needs to, instead delay showing the indicator itself by some (fairly short) duration.

This avoids the problem of the indicator flickering on and off so quickly that it looks like a mistake:

• If the operation completes quickly, then you can show the results immediately and cancel the display of the "loading" indicator before it ever appears.
• If the operation takes a long time, then the indicator will appear on schedule, before the user has enough time to really notice that it was delayed.

The exact duration for delaying the spinner depends to some extent on the task being performed, and what the user's expectation is of how long it's going to take, but it should be short enough that the user doesn't have time to think "maybe my click didn't register" and try again. (Though if need be, you can mitigate that by pairing the loading spinner with some more subtle, non-persistent indicator that the click was received.)

This is most useful when displaying data that may or may not already be in browser cache: i.e. if the browser has the data already it can display it right away; if it doesn't then it has to wait for a server roundtrip -- meaning you'll have some responses that are very very fast, some that are relatively slow, and very little in between.

A simple way to implement this on the web is to stuff all the "deferred display" logic into the CSS As far as the DOM is concerned, you just show the spinner when the request is made, and remove it when the request is complete, very simple, no timing logic necessary. CSS animation can be used to keep the spinner invisible until you're certain the user needs to see it, such as:

@keyframes delayVisibility {
  0%   { opacity:0; }
  99%  { opacity:0; }
  100% { opacity:1; }
}
.spinner {
  animation: delayVisibility linear 1s; /* exaggerated; 1s is too long */
}

Answer 5

It's difficult, if you don't know in advance how long the operation will take. One solution to that (I've not read the article pointed at by @MajoOod, so I might be repeating what's said there) is to allocate and label a space in the UI for a progress indicator. Then, if the operation doesn't take enough time for the viewer to really see the progress indicator turn on and off, the permanent label on the space will tell the viewer what just happened. You could even change the label to include how much time the most recent operation took, e.g., "File loaded in 0.05 seconds".

Answer 6

The solution to your problem could be found in the Material Design Motion Guidelines.

The Motion Duration & Speed postulate specifies that:

When elements move between positions or states, the movement should be fast enough that it doesn't cause waiting, but slow enough that the transition can be understood. Keep transitions short as users will see them frequently.

And this sounds appropriate. Technically, the user won't be bothered about another, say 300ms, of his time wasted in watching the loader complete the transition.

Animations are incorporated in websites and application in order to avail a natural flow within the website/application's environment. In case the animation is killed abruptly in its course, just because the content loaded in a smaller fraction of the second than that of the animation, the primary purpose of the loader to serve feedback and a smooth transition is defeated.

Hence I guess, completing the transition of the loader would be the right choice to make, provided, the loader's reaction time is fast enough that it doesn't cause waiting, but slow enough that the transition can be understood.

Answer 7

This article from Viget suggests letting a loading animation finish its cycle rather than stop partway (and gives code for that functionality).

Answer 8

Any ideas of what is the correct way to go?

The general idea is to let user understand what's going on, on the display without braking native expectations, especially when interaction is involved in the process.

So, what you want to do is to apply the loading indicator(text/animation/icon/etc) next to the loading button(you don't want to use loading in the center of the screen, for example), but with careful attention to a) what Kartik Iyer said about slow enough and b) what Madalina Taina said about " < 1 sec" and " > 1 sec".

It's extremely important to understand who is it for you doing. If you do it for some technological geek kids who involved in modern tech. 24/7 for all of their entire life or for an elder generation who's getting hard time using PC with keyboard and mouse.