How to tell the users about a unpredictably long process?

Question

I create a website where a user needs to to fill in a form. After that the form starts to call an API with this input.

Unfortunately the API response is very slow and sometimes user has to wait about one minute.

I have read from UX Movement that if the user needs to wait so long it is better to use a progress bar instead of a spinner.

I cannot predict how long the api call will last. Therefore, an accurate display of the progress is difficult.

Do you have any experience or ideas how to handle this?

Answer 1

There is a difference between a spinner and a progress indicator:

• a spinner only communicates the wait,

• a progress indicator (be it a progress bar or any other form going from 0 to 100%) communicates wait and progress.

To communicate progress, exactness it is necessary. This is why those installation progress bars, stopping at 99% are so frustrating. Therefore, showing a progress bar in a situation when it is not possible to say when the process will finish is a bad idea.

To make the waiting less painful for the User, though, and give them some information about the process in the background, you can apply some or both of the following:

• make the process run in background of User actions - to do this, you can show a progress indicator somewhere in, for example, the top right corner of the screen while not stopping the user from the other actions that they can perform in the system.

• communicate the approximate wait - this is just saying something like "This usually takes up to a minute." - it will still give your User some understanding about how long they need to wait for it to finish.

• if the action results in displaying some items to the user, you can present placeholders that will fill with data once the operation finishes. This is something that you can see, for example, when visiting LinkedIn.

EDIT:

• another thing you could consider, would be combining some of these – for example by showing a system busy indicator (e.g. spinner) supported by an information that "It usually takes up to 30 seconds." and then, if the operation takes longer, allowing User to choose between waiting longer or getting back to the results list after the operation has finished. Similar pattern is used e.g. in Chrome when a tab is not responding for some time, as far as I remember.

Answer 2

For a wait as long as that, I would be reluctant to ask the user to wait at all.

Consider showing them a result such as "Thank you, your form submission has been accepted and is being processed, you will be notified by [method of notification] once processing is complete. This is usually within [x] minutes"

Now they can leave the form, or page, or whatever they are on, and get on with whatever they want to do. When the processing is complete, send them a notification (email, SMS, IM, whatever you feel is appropriate) and provide them a link to click and resume where they left off.

This way they are not wasting their valuable time sitting looking at a page wondering how long it is going to take. They won't feel like there is anything they can do to speed it up (why users think submitting again or refreshing will somehow help will always be beyond me!) so they will be more likely to simply accept it and move on with another task until the notification appears.

If the users are already identified by this point, also consider a message at the start of the form, if a user revisits the page while their submission is still being processed, informing them of the status (even if it is rather vague, as I assume since you cannot provide an accurate progress bar, you don't have much detail on the status)

Answer 3

If the progress takes longer than a few seconds, you should think about the user-experience. You cannot expect the user to stare at a progress bar for one minute - the user will do something else in the time, while a long progress operation finishes in the background.

If you show a progress bar it has to be accurate (so waiting time can be inferred by the user) - if you cannot provide accurate feedback of progress better use a spinner and a text with the expected loading time.

Most importantly: Provide an option for the user to re-engage once the operation is complete. This can be a desktop notification, a sound or a tab-bar flashing/change of favicon and tab-title in the browser to signal completion.

Your request is being processed, usually takes about 2 minutes.

Please do not close this window.

You will be informed via notification when the progress completes.

Answer 4

Besides all mentioned above, I would suggest adding intermediary updates, e.g.

• Loading...
• Still loading...
• Yet still loading...

If the text changes it'll give a clue to the user that process is not hanged.

---

Depending on your app personality messages can be humorous or formal.

Humorous

• Why not make a cup of tea?...
• Or coffee?...
• Or even hot chocolate?...

One thing to be aware of: in case of error there is no place for humor.

Formal

• Searching for a free database connection...
• Contacting database...
• Submitting data to database...
• ...

An example of formal: Photoshop loading window (reading brushes)

Edited with suggestions of Klaws and John U

Answer 5

If you can't make the wait informative, at least make it entertaining.

For example, on a certain web site Bill Shatner makes some funny faces and hand gestures while a notoriously slow system is interrogated. You may not be the best person to build that humor, but perhaps you can consult with your business image or marketing team and ask them to suggest "while you wait" content for your user.

Don't be tempted to put distracting information in this gap. The primary content should be informative or humorous. Informative information might be a video tour of the system just provisioned. Humorous might be a carousel of employee's dogs. Marketing people might be tempted to put ads for related products: don't let them, or at least argue such ads should be small.

Answer 6

Assuming one minute is as fast as your process is going to get, and this is a critical component, I would consider coordinating with Engineering to modify the approach so it no longer takes place in a long-running API call.

Here's a high-level approach to a user experience similar to what you might see on something like Dominos Pizza's order tracker:

1. Modify the current API so that it adds a message to a queue, then responds immediately.
2. The UX immediately displays a progress bar at 0%, then waits for notifications.
3. A background worker process picks up the message and begins processing.
4. Modify the processor logic by adding status updates at various milestones.
5. Send these status updates back to the user through push notifications, updating the progress bar.
6. When the UI receives the last update, confirming that the process is complete, move the user along to their next view.

Answer 7

Which bug report would you prefer reading:

• The spinner just keeps spinning.
• Progress is temporarily stuck at 78 %.
• The app takes very long to perform the "Rectifying delta wave" stage, ten times longer than the estimate of the one minute given.

Yes, the latter may not be something the user understands, but nonetheless this is the information you as the developer will need in order to improve performance or fix bugs. So unless the action should finish quicker than the initialization routine for a progress indicator, please do provide sufficient information for the user to known whether it's worth their time to wait or to multi-task somewhere else for a while. And don't entirely block the device unless you absolutely have to.

Answer 8

The most important thing is to explicitly inform users that the loading can take some time (around a minute) and show progress indicator. In my opinion, it doesn't matter that much whether it would be a spinner or progress bar as long as is showing that it's working on the task.

There is a problem with the progress bar when you cannot offer a accurate representation in long periods of loading. Imagine that the progress bar stuck on 40% for considerable time. Users will start thinking that the site has stopped loading while in reality it is not. In this case users are likely to abandon the process and you definitely want to avoid that.

Another good idea is to show animation or a picture while they wait. This way their attention will be kept at the page. Of course this depends on your type of application.

Answer 9

There are many issues with a long wait, mainly:

• how can the user differentiate between a situation in which the website failed them compared to the website just being slow?
• what are the consequences, for the user, of losing their connection? having their browser crash?
• what are the consequences, for the user, of re-submitting the form?

However, attempting to address these issues with text can surprisingly backfire. Whenever I see a website that makes me wait with a text the likes of:

Do NOT refresh this page, your payment could be processed twice!

I get really worried, and generally avoid returning to the website:

How confident should I be in a website's payment handling if they can accidentally charge a customer twice? Well, not confident at all!

---

The key issue is that this is NOT just about making a user wait, it's about assuring the user that:

• their request is being addressed,
• their request will not be lost,
• they can at any time resume the handling of their request.

If your user is logged in, you can simply store the request in their profile inside the website database. If the user is not logged in, you can generate a globally unique ID and store it in a cookie or local storage on the user's browser.

In either case, from the UI point of view you need to:

• show to the user that their request was acknowledged and registered (even if not processed yet),
• allow the user to check on their latest requests, at the very least those that were completed since the previous time they connected, so they can resume their task.

Both steps can be accomplished by having a "history"/"recent requests" box visible to the user, and adding their current request to the box to acknowledge it's been made. A little icon that differentiates the "step" at which the request (draft, submitted, in progress, completed/cancelled) is a cherry on top.

This will go a long way to assuage a user's fear or insecurities from the wait itself.

---

And now, and only then, do we address how to best make the user wait.

The first question is:

Is the user actively waiting, or can the user be notified asynchronously?

If the latter, then just tell the user they will be notified. I'll assume that they wish to proceed immediately.

In this case, as mentioned, I encourage you to display a progress bar rather than a spinning wheel, to convey the idea that progress is made:

• the duration of the progress bar should be a rough estimate of your 90th/95th percentile for the API call; it's much better to complete early than get stuck at 99% (keyword: stuck),
• if possible, steps should be displayed atop the progress bar ("Step 1/5: X", "Step 2/5: Y", ...),
• do not wing it, only display steps if you can check with the API at which step the processing is.

Whether you allow the user to work on another request in the mean-time or not is up to you and depends on the usage.

Also, displaying ads and gags while the user waits may not necessarily be taken positively; angry impatient users have little humour and little patience for your attempts at making money.

Answer 10

I recommend a status graphic of either penguins or lemmings walking of a cliff and piling up at the bottom.

This will give the user an idea of how much time has passed (number of dead penguins) and how much time is left (space left in the pit).

The user will know that the process has failed/hanged, when there is no more penguins, or no space for them to move forward.

This is superior to a percentage of status bar as the user does not know how many penguins will fit in the pit. (Much like guessing jelly bean count in a jar) The user will thus have no expectations for you to fail to achieve.

Unlike a spinning wheel, etc, this gives feed back and does not make the user think that nothing is happening. People believe that long spinners are a sign of lag. This belief comes from decades of Microsoft Hour-Glass and Apple infinite color wheel experience.

Also this visual will give your user a much needed brake from the boredom of day to day app/web usage.

Answer 11

I have read that if the user needs to wait so long it is better to use a progress bar instead of a spinner

Yes, but that's the effect, not the reason:

Progress bar is for when you can measure how the process is progressing (!). Something among the lines of "when X happens it usually means we're about halfway done so set the progress to 50%".

Spinner is for when you don't know how long will the process take. You don't know if you're almost done or just beginning so you keep it spinning and "it'll be done when it's done".

The "don't know" often comes from "don't care, because it's so short anyway", and that's how the article author came to his/her conclusion. But it's clear that the author made hidden (and false!) assumption that all operations (and especially the long ones) are measurable. Bottom line: there is a connotation "short = spinner, long = progress" but it's merely a coincidental one, not some fundamental rule.

I cannot predict how long the api call will last. Therefore, an accurate display of the progress is difficult.

That's why we've invented spinners in the first place!

There is also a thing called "indeterminate progressbar". But it's doesn't carry meaning any different than spinner. It's purpose is to be visually coherent with regular progressbars, so you can use same dialogs, graphic and layouts with both types of operations.

The "redesign your flow" was stated already, no need of repeating that, because the best spinner/progress bar is the one that's never needed.

Answer 12

Keep the user informed

If you know the approximate or maximum times it'll take, those can be used as progress markers as well. Some kind of animation or divertesment during the wait can make it slightly less painful. If you can get "partial" steps informing the user when those happen can also break the monotony.

Even if you're not getting any info back from the API, let the user know every 15 seconds or so that your service hasn't broken and is still waiting is good.

Better yet, if after the expected maximum duration has elapsed you let the user know of any alternative method of submission (retrieval?) of the info that will help too...

It's been two minutes, something has probably gone wrong, this usually doesn't take quite that long! contact name@email

Answer 13

The goal here is to keep the user informed at all times without introducing more information to them than necessary. A user whose request is processed fast needn't know about average wait times, and a user who has been waiting for 5 minutes does not need to know that the process usually takes a minute.

Here is one suggestion which would achieve this - have a progress bar capped at 1 minutes with text below it. Initially the text would convey "working on it", then after about 10-15 seconds have elapsed you update it to "this usually takes not more than a minute", and after a minute has elapsed and the progress bar is full, you could replace the message by a reason on why it might be taking long and what user can do about it. Something like "We use the x API, and they seem to be responding slowly at the moment." followed by an advice on what they could do like "We'll send you a notification once this completes", or "Please try again later" might be good.

Again, you can still customize your message as time elapses even after a minute. If you know that 95% of user requests are satisfied within 1 minute, 30 seconds then saying "We use the x API, and they seem to be responding slowly at the moment. Hang on for a while" and changing "Hang on for a while" to some other message after 1 minute, 30 seconds.

Answer 14

All this talk about different presentation styles is beside your core concern here:
Your users are supplying information on a website form which contacts the remote server.

If there is a long wait, then it seems to me that your largest concern here is that the user will think the connection has hung. So it will take an indeterminate amount of time, probably 1 minute but anywhere from 30 seconds to 5 minutes depending on server load? Have a message saying so, sure.
That message should have a small animated component — a simple Cylon eye will be adequate — so as to initially catch attention: the user needs to know that this message is not simply a static blurb which can be perused whenever.

The major concern here is to keep the user informed that the connection to the server hasn't been lost, or that the server-side script hasn't frozen or crashed. And, to do so in a way which doesn't require them to begin pulling up diagnostics or whatever.
You can't cheat this, because if your users will use the system more than once, they need to know that the information provided to them is reliable.
You should probably use the same methods by which you are keeping the HTTPS session open — i.e. a client-side script which pings so as to prevent time–out.

A simple message with a blinking indicator, saying something to the effect of

Status: processing . . .

would probably be best for your situation. There you could show various other messages, also:

Status: connection lost!

But, it needs one more thing: How do your users know whether the client-side script is responsive? Depends on what you are using, but I recommend that you write something which shows the local time. That way, if it hangs, they can compare that clock to another.
Don't rely on being quirky with the mouse cursor or the like, because some users will block scripts from being able to do so.

Answer 15

Have the progress bar start out fast, then get slower and slower. Use a formula such as 100-100/([time in seconds]/30+1) so it will take an infinitely long for the progress bar to go to 100% with time=29 being 50%, time=60 being 67%, time=300 being 91%