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:
- The user has noticed there is a delay
- 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)