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.

  • You might find this useful: nngroup.com/articles/progress-indicators – Majo0od Feb 6 '17 at 13:15
  • Definitely! Good luck! – Majo0od Feb 6 '17 at 14:06
  • As a fellow app developer I can tell you as long as you are animating things in and out instead of just removing them then the looks strange part will rarely, if ever, be an issue. Good luck! – Albert Renshaw Feb 9 '17 at 7:34
  • @AlbertRenshaw Thanks for the suggestion. I guess then the answer would be yes, and then try to accomplish it fading in/out things. – Alvaro Feb 9 '17 at 9:02
  • So to speak, the above problem only occurs when the loader is placed directly at the center of the containing div. It would never hinder the user's flow if the loader is either placed like in stackexchange's editor (right next to submit button) or top of the div like chrome. – ikartik90 Feb 9 '17 at 14:36

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

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.

enter image description here

  • 1
    Thanks, very interesting. I am not sure if the conclusion from article would be: if it is not possible to make the wait instantaneous (knowing it beforehand), then go for at least one second. – Alvaro Feb 10 '17 at 10:56
  • @Alvaro In fact, "Normally, response times should be as fast as possible, but it is also possible for the computer to react so fast that the user cannot keep up with the feedback. ", so a spinner can be a good thing. If you use a loader or a spinner, then the time should be between 1-4 seconds. If the operations are complex and is needed more time, use a progress bar... This is what I understood. – Madalina Taina Feb 10 '17 at 13:34

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.

  • Thanks for the answer. Actually it makes me realize I might need the spinner even if I include the text. – Alvaro Feb 6 '17 at 15:39
  • 1
    100% agreed. As a user I want the content... if it loads faster than expected that's awesome, that's a win! The fact that I might have to wait in the first place is the bug. I HATE the useless slow Facebook experience where I stare at fake lines while I wait for stuff to load... so that I can show/share the post that was already cached in my timeline. Grrrrr! – scunliffe Feb 11 '17 at 16:58

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 */
}
  • 1
    Your suggestion violates the immediate feedback principal, which is fairly pivotal. What's more, you only really differ the problem - the loader may still flicker after the initial throttle. – Izhaki Feb 7 '17 at 13:57
  • re immediate feedback: yes, that's why I suggested keeping the delay very short, as well as suggesting "pairing the loading spinner with some more subtle, non-persistent indicator that the click was received" – Daniel Beck Feb 7 '17 at 20:13
  • re loader may still flicker: yes, that's why I said "This is most useful when displaying data that may or may not already be in browser cache... you'll have some responses that are very very fast, some that are relatively slow, and very little in between" -- in practice it's not too difficult to time the delay to fall in that middle area, after the synchronous responses would have returned but before the asynchronous ones are likely to. – Daniel Beck Feb 7 '17 at 20:14

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

  • Thanks for the answer and the suggestion. The question is still there, should I force the label to be there for a minimum amount of time, even if it the content was received (but not shown) already? – Alvaro Feb 6 '17 at 14:35
  • I mightn't understand your question. I would treat the label as permanent ("progress") or if you change it to reflect the time of the last operation, let it stand until the content that was the subject of the operation has been displayed / stored / eaten / disposed of, then fade the label back to its permanent state. Is that at all responsive to your question? – MMacD Feb 6 '17 at 14:46

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.

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

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.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.