At what point does a user lose trust in a Busy Spinner?

Question

The first scenario is an action that could take roughly 2–5 seconds to execute once the user has pressed a button. A Busy Spinner will be displayed in the button until the process has been completed.

After the action is complete feedback is displayed to the user.

The second scenario is an action that can take a couple of minutes to complete. In this scenario I don't believe it's appropriate to simply display a Busy Spinner in the button. I think that a user would start to question if any progress is being made. So instead, a dialog will be displayed:

By displaying a dialog—along with the text, I believe that the user has more confidence that the action is being carried out.

My question is—how long is too long for a simple Busy Spinner? Around what estimated time frame should I begin to introduce a dialog which mentions how long the action will roughly take?

Answer 1

Jakob Nielsen wrote an article called Response times - 3 important limits.

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]. He wrote this in 1993:

• 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
• 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

In 2014 he updated his guidance with this:

• 0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column — if so, users would feel that they are sorting the table. (As opposed to feeling that they are ordering the computer to do the sorting for them.)
• 1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users'actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
• 10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.

Answer 2

Imagine you and I are talking to each other in the street. You've asked me if I have the time and with barely any hesitation I look at my watch and tell you. You don't give it a second thought. You then ask my if I can tell you directions to a decent coffee shop. Some options may occur:

1. I instantly start reeling off a set of instructions

2. I appear to be contemplating something - it might be that I'm considering the best coffee shop bearing in mind the current location, or I'm trying to work out the best directions for walking.

3. I say I don't know, but I'm meeting someone next who knows, and I can text you the answer in a few minutes.

4. I stand there not really doing anything, almost as if I hadn't heard you.

Your expectations might be for option 1 or 2. You realise that if I indicate option 2 that this may take a moment and you're prepared for a small wait, but it definitely helps if I let you know that I'm first considering a few really good coffee shops before picking one and then providing the instructions.

Option 3 lets you get on with your life and get notified soon. You don't get an answer right away, but it's beyond helpful, and you're grateful for not having to wait.

Option 4 though is thoroughly disconcerting. If I continue to stand there not giving any further clue that I'm considering an answer, you're going to prompt me with things like 'any coffee shop will do' or 'if there's no coffee shop near here, that's fine', or 'forget it, I'll just wander round!'.

It's the same with computers - it's still part of a conversation between you and the computer. You may not expect an answer to something complex within a tenth of a second. You do expect some clue that the request is being considered usefully. You expect some indication of the type of response within a second or so, and you get disconcerted if you don't have any of that feedback within a few seconds. And if the total wait is longer than a few seconds, you like to know what's being considered - am I considering a couple of local coffee shops or am I calculating directions from London to a great little indie coffee outlet in Seattle.

Answer 3

Scott Klemmer's rule of thumb is:

Answer shorter than a second: No feedback

Answer between 1 and 5 seconds: BusySpinner

Answer longer than 5 seconds: Progress bar

10 seconds is a long time. You should bring feedback to the user before he/she naturally loses interest in what your software is doing and become frustrated that your software wasted his/her time.

Answer 4

According to this article from NNGroup based on cognitive psychology studies:

• after 1 second the user might start to lose his flow of thought about the current process.
• after 10 seconds the user will most probably switch his attention on other task

We don't want to risk the user switching its attention to something else, so we should display the dialog before those 10 seconds. Also, the studies are 25+ years old so the computers have gotten much faster and users expect everything to load faster.

That is why I suggest a threshold around 3 seconds where the dialog with the delay information should be displayed.

Basically, the more information you give the user while loading the higher the chance is she is not going to abandon the process. Try to display:

• use progress bar
• explain why it is taking time to load
• show approximate time of loading

Answer 5

Ten seconds and after that I start thinking "this is not working" and I worry in about my credit card being or not being processed or being processed twice if I have to do this again.

It is good to change the message after 10-15 seconds to "it is still loading, no need to worry" or any other positively reassuring message.

Just an example is sending an email on gmail without letting the attachment to preupload. The message changes from "sending" to "it's still working".

Please note there needs to be some kind off response from the server to confirm that the process is still running or report an error to a user.

Answer 6

Sorry you're all quoting old research. Google has updated this.

125ms the user expects a response of some kind like a loading icon showing up after click.

250ms user starts to notice the action is happening.

500ms the user expects to be updated on response.

1s the user expects the content to be loaded.

10s I give up.

Slide 12: https://docs.google.com/presentation/d/13AJe2Ip4etqA8qylrva7bEgu1_hAvsq_VQiVOAxwdcI/mobilepresent?slide=id.g1e697bbb_0_7

https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en

Answer 7

Apart from all the excellent answers submitted here, I want to add that, the expectations of a user on low-bandwidth internet connection (yes, they do exist!) are entirely different than that of a user on high-speed fibre-optic connection.

Answer 8

A programming challenge arises when one doesn't know (in advance) the length of time the task is likely to take, either because the task itself varies or because it could be run on different speed processors. Ideally we want to make our code independent of both task size and hardware / OS limitations, and perform consistently in all / nearly all situations.

If we show a progress bar, (or even a spinner) it could just flicker on the screen and disappear immediately, which is disconcerting UX in my opinion.

A less than ideal solution to this (sometimes implemented) is to simply decide that the user will wait some length of time no matter how fast the task is completed... e.g. 1 second + task time, that way the spinner / progress bar does at least remain visible for some time.

I believe a slightly better solution is to add the fixed delay only when the time taken has already exceeded 1 second causing the spinner or progress bar to be shown. That way if the delay gets added, it's proportionately much less compared to the time the user is already required to wait.