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

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

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.