To indicate that the application is doing something, throbbers are often displayed. Are there certain type of events that one should or shouldn't display one? Obviously long events which the user must wait till complete are a good application, but is there more to this? Also, i Is there a recommended amount of time of a given event when one should or shouldn't display one? Thanks

2 Answers 2


Throbbers are also known as 'spinners' or 'loading indicators'.

Throbbers can be used to indicate progress on long actions/waits which meet some or preferably all of these characteristics:

  1. The action/wait is blocking user flow. That is, it's difficult or impossible for the user to proceed with the flow she is on without waiting.

    • e.g. The user asked a question and the answer is being retrieved from a server
    • e.g. The user scrolled to the bottom of a Facebook or Pinterest feed and new content is being loaded.
    • If the wait is non blocking (eg your app is loading some podcasts in the background) then throbbers often aren't the right solution because the animation draws user attention away from the flow.
  2. The action is long enough that a user may feel anxious if there is no indication of progress (aka did it hang?). For short actions or waits having a short-lived throbber is not a great idea because it can confuse users.

  3. It's difficult or impossible to indicate exact progress. If it's possible to indicate progress (eg percentage complete) then progress bars or widgets are more appropriately communicative and less likely to frustrate users.

It is relative. If you have a very responsive application then maybe as short as 1 second. Anything over 10 seconds would be a long event to most users.

In programming terms it is a long running task. An event is what triggers the task.

The problem with a long running task is often the application just does not know how long. It is typically a task that depends on an external resource. You need to deal with that gracefully.

There are two type of long running events:

  • cancelable
  • uncancelable

On a cancelable task the user is presented with both a busy indicator (e.g. throbber) and a way (button) to cancel out. If all the buttons simple go dead with a busy indicator and the user has no way to cancel out but to kill the application that is a poor UX. Another problem with kill is the application does not (typically) release the external resource. Ideally you can display a progress indicator but unfortunately many long running tasks don't progress metrics.

Long running tasks can be preformed asynchronously and leave the application hot (buttons enabled) but if the users moves on to other tasks (buttons) and later the result from that button 3 buttons ago is displayed it confuses the user.

If it is resource that is going to respond in 10 seconds or less or not at all then you don't need a cancel - just a simple busy indicator. If you don't get a response give the user a message "resource X is not available".

What I typically do is delay the busy indicator by 1 second. If the task takes more then 1 second then it is likely to take more than 2 seconds.

And a simple message in a text box can also be a valid busy indicator. For example if the results from a search are returned to text a box then fill the text box with "search running" while the search in running. I think this leads to better flow than a spinner.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.