How would you feel if you were waiting in line at the store and stood in the same spot for a long time? You would probably get frustrated and move on. Users find themselves in this situation when same they see a spinner on their screen a few seconds too long.
Spinners Are Not For Long Load Times
Spinners don’t tell users how long the process will take to load. If you use it for long load times, 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 users may hit the back button or exit out of the app.
The 4-Second Rule
If you want users to stay on your app, don’t use spinners for processes that take longer than 4 seconds to load. A research study has found that the tolerable wait time for users is 4 seconds. This finding means that their behavioral intentions begin to change after 4 seconds.
When to Display a Spinner
Users expect an app’s response time to be immediate. Immediate response time is less than 1 second. If they don’t get any visual feedback after a second, they start to worry.
If you have a process that takes longer than a second, you should display a spinner. Doing this lets users know that the app is loading, which eases their worries.
Progress Bars Make Long Load Times Tolerable
If a process takes longer than 4 seconds to load, you should use a progress bar. Users are more willing to tolerate a long wait time if they see a progress bar.
A progress bar sets a clear expectation of the load time. The linear visual cue allows them to see progress, which encourages them to wait. A spinner wouldn’t show them how much progress they’re making. Users wouldn’t know if their action is processing and would have no incentive to wait.
How to Display a Progress Bar
A progress bar needs to show users how much progress the system is making. Your bar should animate from left to right at a gradual and consistent pace. If the animation pauses for too long, users will think it’s stuck and won’t wait.
You should also add a numeric estimation to your progress bar. If the process is under a minute, display the percent done or the number of items loaded. Inform them what activity the app is doing as it loads.
If loading takes over a minute, you should give users an estimated time remaining. This information lets them know that they can expect a longer than usual wait time. Displaying the number of minutes allows them to leave and come back to their screen.
Don’t Go Spinner Crazy
Many designers have a habit of using spinners for every process. But when you use spinners for long load times, you create user frustration. Avoid this by using progress bars when needed.
Progress bars make longer load times tolerable. Users don’t mind waiting if they know the app is doing work for them. But if it’s taking longer than expected, they need visual feedback. Not knowing what they’re waiting for makes them impatient and leave.
Book
Affiliate
Although I complete agree with the idea I think spinners also serve another purpose. In many occasions the task completion progress is not known or very hard to know (e.g. a slow query is running in the database) in which case there’s no data to feed the progress bar. That’s why a lot of developers resort to the quick and dirty spinner instead of showing real progress.
In this case is an indeterminate progress bar style any better?https://material.google.com/components/progress-activity.html#progress-activity-types-of-indicators
It probably makes me thing it’s a longer progress than a normal spinner, just because it’s closer visually, and isn’t quite as anxiety inducing.
Another thing I’ve seen Google do in particular is flash up a notification when things are taking longer than normal with some help text on how to resolve the situation or ask the user to try again later, perhaps saving any state if possible.
Hey Anthony, I see your point, but since both spinner and progress bar usually appear when something is loading, we have to consider the speed of the data connection as well. It is pretty much impossible to predict how long a certain action will take for individual users because, what takes only a second on a super-fast cable connection might take way longer on a crappy mobile connection.
I am agree with Daniel. In most of the cases its depend on the speed of data connection. I would recommend if you want to use the spinner then use the percentage along with it. that will help user to understand better that how much time it is going to take.
Great post, I think I agree with Kyriakos that the likelihood of you being able to calculate the progress is often remote.
I’ll definitely keep a note of the timings though, very useful.
Regarding how to display the progress bar I’d like to add that it depends on how accurately the time can be estimated. A progress bar that jumps back and forth between 4 hours and 32 minutes simply because the speed of the connection varies is less helpful than one that says 43%, even if it takes an hour in total. Unless the estimated time is accurate within a +-50% tolerance or so I’d say showing the percentage is better.