I'm replacing all loaders (spinners) in the app I'm working on, because I need another solution which won't be tied so much with waiting. When people see loader they're frustrating, because loader indicates that they need to wait, so instead of loader I'm going to display pre-loading skeleton screens as Luke Wróblewski recommended and as e.g. Facebook uses (print screen). A skeleton screen is essentially a blank version of a page into which information is gradually loaded. This creates the sense that things are happening immediately as information is incrementally displayed on the screen.

In this case user has a connection with network but the connection is bad e.g. 2g or the time of servers respond is longer than usual.

My question:

  1. What to do when content isn't displayed for a longer time (e.g. more than 5 or 10 sec)? Whether the pre-loading skeleton screen should be displayed all the time until the content will arrive or should be replaced by something else e.g. additional information - "we're sorry that it takes so much to load the content, check your network".

enter image description here


6 Answers 6


You (literally) can’t make the user wait

There is no “magic message” that will keep users from putting their phones back in their pockets when they aren’t getting the info they want. Literally, they will not wait.

Granted, network connectivity or “Lie-Fi” conditions are often beyond your control. The user may recognize this as well — but that will only make some of them more patient, some of the time.

Display something fast

You need to get something users want onto their screens, absolutely as quickly as possible.

This is the number one thing your team needs to accomplish to improve the user experience, and keep from losing users.

There are any number of best practices for dealing with poor connectivity. Here are two common ones:

Make sure your system is optimized to minimize delay

It is quite possible your development team does not understand how urgent it is to get data to the user quickly. There are probably several things that could be done on a technical level that would get a little info to the user’s device more quickly.

You might have to push back against the business as well. If the business requires a particular piece of data on the screen “at page load time” that is slowing down the process by a few seconds, you’ll need to show them how that requirement is causing harm. That slower data can be “filled in” on the page as it becomes available.

Utilize cached content

You didn’t mention the type of content you are displaying. If yesterday’s content may be of any use to them, display that (probably — along with a message that the app is trying to fetch new data). For example, yesterday’s weather forecast is better than a blank screen.

Yes, dynamic progress indicators can help

The cold hard truth is asking your user to wait 20 seconds for your app to respond is probably not going to work, unless the user absolutely needs to complete the task (for example, if they are legally compelled to do so). That said, your inclination to provide information to the user is correct.

Progress Indicators should appear when the user faces a significant delay

“Significant” may be shorter than you think:

Nielson Norman Group provides the following blunt conclusion: “Progress Indicators Make a Slow System Less Insufferable” and the following guideline:

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

I find this a good general guideline for providing feedback that that application is working, while avoiding annoying “flicker” on the screen. If, under ideal conditions, the data transfer could be complete in less than a second, a progress bar flashing up for an instance would just be annoying. When a second has gone by without a response from the server, we know 2 things:

  1. The user has noticed there is a delay
  2. It’s quite possible this delay will last several more seconds

So now we put up a message stating the connection is slower than expected, but we still expect it to complete. Sometimes the connection will complete in 1.01 seconds (causing the error message to flash up and then disappear) but that will be rare.

Progress Indicators should provide true, clear information

If you want your “please wait we are trying to connect” message to be at all effective over the long term, your app will need to be honest with the user. Do not leave the “trying to connect” message up forever — it should be replaced with timeout or connection failure messages, when appropriate.

True and actionable information is called for: if there was a server error, admit it in the error message — and provide a support contact if you can. Only lead the user to believe the problem is with their connectivity when you have a reason to believe that is the case.

Adding more messages

In your specific case, you (unfortunately) have a monolithic, synchronous request to get all the data. If this download can take more than a second, you might add an additional message, e.g., “Successfully connected to server. Downloading data…”

The same rule apply: avoid messages flashing across the screen for split seconds; provide enough feedback that the user can tell “the gears are still turning” on the app (and promptly telling the users when the app has stopped working)

  • I agree that all technical issues should be covered, in this particular case there is no way to cache content I need to connect with the server to get the most fresh data. Unfortunately I'm not able to load content async, so I can only avoid the spinner, replace it with a skeleton screen and rethink if there is a need to display additional message if skeleton is longer on the screen than expected. Commented Dec 27, 2016 at 13:34
  • 1
    What does “I'm not able to load content async" mean? A technical constraint? Reliance on an external system that does not provide? A rigid requirement? Any of those are easier to solve than building a better downasaur.
    – Tim Grant
    Commented Dec 27, 2016 at 14:39
  • Asynchronous loading isn't available at the moment cause all the data is being downloaded in the one request, so this is a technical restraint. Commented Dec 27, 2016 at 14:54
  • 1
    Sounds like it is time to fix the API so that you can download the data in chunks that makes sense. Forcing the user to wait vs showing them some data now doesn't seem to make sense.
    – scunliffe
    Commented Dec 27, 2016 at 18:00
  • Regarding to the last point on your list - I'm wondering after what exactly time additional message about "downloading data" should be displayed? Commented Dec 29, 2016 at 9:45

First of all you need to identify why nothing is happening even after say x seconds. simply showing user that his network might be slow (since you have mentioned facebook's example screen here) without knowing that will be very wrong.

  • If the users network is slow then you can follow the facebook's
    approach, also you can give user a reconnect button which will
    try to re-establish the connection.
  • If your app is failing for some reason then be honest and show a 'something really went wrong, please try again' screen.
  • Good point, on the second screen I don't know what is wrong, so I shouldn't blame user for a bad connection, on the third screen I already know if the connection is bad or the server is down. Commented Dec 27, 2016 at 13:22
  • Yes of course you are right.
    – prazor9
    Commented Dec 27, 2016 at 13:37

As others said, your priority would be to get the data as fast as possible to users. Even then if the problem persists because of slow internet connections, I can suggest you the following

  1. Indicate them to switch to a better connectivity
  2. Give them something to read while loading so that it would take their mind off from waiting(Some interesting facts related to your app is based on)
  3. Show a progress bar instead of spinners. The most frustrating thing about spinners is people don't know how long they need to wait(how much i need to wait more?, am I even receiving the data? etc.). Progress bars gives a sense of how long its gonna take so the mind can be somewhat relieved of the 'unknown' time required.


Based on your comment for progressabar,

Well then you can give abstract messages of what steps your app is trying to perform. For example,

Establishing connection...(1/5) Authenticating...(2/5) Requesting data...(3/5) Receiving data...(4/5) Ready to go...(5/5)

This is just an example as I have no idea of what your app does. But you can add abstract messages too if you like.

Also check out this question about distracting user if you cannot improve loading time.

  • Regarding to the third point: progress bar is better when you know how long does it take to load data or render the website in this case I don't have such data. Commented Dec 29, 2016 at 9:15

Building on this pre-loading skeleton screens, we can show the explanation of the fields that are coming up. So that we can engage the user in understanding(reading) what's coming up.


Instead of (or in addition to) resolving the symptoms, I'd recommend attacking the problem.

Why is it taking so long to load? There should be no issue getting basic text content to the user in under a second.... with placeholders to backfill with image/video content as needed.

Are your DB queries as optimized as they can be? Are the tables you're searching against properly indexed? Etc.

Are you returning the data to the client in the most optimal way? Eg minimal JSON vs. bloated XML?

Are you fetching/returning only the data you need?... not re-using another API call because it was "handy" even though it brings back unrelated data?

Are you properly caching resources on the client... only fetching data that is out of date?

If you are trying to overcome network issues, have you distributed your static/catchable content on a geographical diverse CDN to distribute the load and reduce bottlenecks?

Can you lazy-load secondary content before you need it so that it is ready when your user gets to where they need it?

Sorry if any of this seems harsh or condescending... it isn't meant to be, but I'm often amazed how many developers/designers try to solve the visual issue of a stalled UI vs fix the code so that there is no delay to overcome.

  • 1
    I agree withe the idea, a lot of backend work has been already done. In my question I'm concentrating on the least common use case - what to do when content hasn't been yet loaded, there're only placeholders visible , seconds are passing and the user should get some information about what is happening. Commented Dec 29, 2016 at 9:18

The process is more or less like this:

1. "You are sending a request" (interaction)
    - There are difficulties sending the request (message)
    x The request couldn't be send (message)

2. "We received your request and we are sending the information"
    - There are a difficulties receiving the information (message)
    x The information couldn't be received (message)

3. "You received the information" (interaction)

Always considering the phrasing and trying not to make the user responsible:

  • Let the user know in which point of the process he is, either with interactions/responses or explicit messages.
  • Give the user information of the possible reasons why it might not be working correctly/failing.
  • Let him know what he can do to fix the problem, if it is in his hand.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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