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.
I cannot predict how long the api call will lastshould indicate the definitive answer.