Busy cursors - why?

Question

Can anyone give me a scenario where they think busy cursors are justified? I feel like they're always a bad idea from a user's perspective. Clarification: by busy cursors, I mean when the user can no longer interact with the application, they can only move their hourglass mouse pointer around and whistle a tune.

Sinless

much better than previous question, interesting to think about. Why? – Cystitis

Jesse, I added an answer to give you a couple of specific examples. – Budbudapest

Answer 1

I think you may well be right: in a decent asynchronous app, you never need to show a busy cursor. The user can always do something even if the big last operation is completing.

That said, sometimes Java apps like Netbeans or Eclipse, or even Visual Studio, hang with no busy cursor and no hope. But in that case, a busy cursor probably wouldn't help much either...but I think you're right: busy cursors are from a non-multithreading era for apps. In Flex apps, for instance, EVERYTHING is automatically event-driven callbacks, so setting a busy cursor would just be meaningless (though possible, of course).

Been

yeah, that's my thinking. I mean, even if it's just change a few user settings or displaying the help-about menu, there's usually something that can be done – Sinless

I respectfully disagree. The point isn't that YOU can do something. The point is that you have to inform the user that his task ("show me data on Q4 sales") is being processed. Sure, you can do something else but the user doesn't care about something else - he cares about his data. – Embattle

@mdbritt: respectfully disagree with your disagreement. What if the user wants to cancel the task? A busy cursor stops them from doing that, so when you enter "show me data on Q4 sales", hit the go button and then realise you wanted Q3 sales, you have to wait... talk about frustrating... – Athwartships

I have to agree with myself and JP and DP: the busy cursor comes from a single-threaded world, I think, where you turn the busy cursor on, do stuff, and then turn it off. Nowadays apps are more easily multithreaded, thanks to language changes. – Been

Daniel, multithreading looks easier nowadays. But it really isn't, and the vast majority of developers don't understand all of the potential problems. – Budbudapest

@RoadWarrior, you may be right: for instance, how many PHP developers worry about maintaining ACID transactions on the DB side? – Been

@DP: If the wait is less than 2 seconds, the user won't care about using cancel. If the wait is more than 2 seconds, then by all means go asynch with a cancel facility. – Budbudapest

RoadWarrior (the @ sign doesn't work on SO): a cancel button is EXACTLY the opposite, in my opinion, of a busy cursor! Of course you need a cancel button, and a status bar or something like that. But the busy cursor just indicates that the app is busy is some mysterious process... I'd prefer to let the OS show the busy cursor and no one else, ever... – Been

Answer 2

In summary, I think that the user should be blocked from doing stuff in your app only when the wait interval is very short (2 seconds or less) and the cognitive overhead of doing multi-threading is likely to result in a less stable app. For more detail, see below.

For an operation lasting less than 0.1 second, you don't usually need to go asynchronous or even show an hourglass.

For an operation lasting between 0.1 and 2 seconds, you usually don't need to go asynchronous. Just switch the cursor to the hourglass, then do the work inline. The visual cue is enough to keep the end-user happy.

If the end-user initiates an operation that is going to take just a couple of seconds, he's in a "focused" mode of thinking in which he's subconsciously waiting for the results of his action, and he hasn’t switched his conscious brain out of that particular focus. So blocking the UI - with a visual indicator that this has happened - is perfectly acceptable for such a short period of time.

For an operation lasting more than 2 seconds, you should usually go asynchronous. But even then, you should provide some sort of progress indicator. People find it difficult to concentrate in the absence of stimulation, and 2 seconds is long enough that the end-user is naturally going to move from conscious ‘focused’ activity to conscious ‘waiting’ activity.

The progress indicator gives them something to occupy them while they are in that waiting mode, and also gives the means of determining when they are going to switch back into their ‘focused’ context. The visual cues give the brain something around which to structure those context switches, without demanding too much conscious thought.

Where it gets messy is where you have an operation that usually completes in X time, but occasionally takes Y, where Y is much greater than X. This can happen for remote actions such as reaching across a network. That's when you might need a combination of the above actions. For example, consider displaying an egg-timer for the first 2 seconds and only then bringing in your progress indicator. This avoids wrenching the end-user from the 'focused' context directly to the 'waiting' context without an intermediate step.

Budbudapest

Answer 3

It's not specifically the busy cursor that is important, but it IS important, absolutely, always to give feedback to the user that something is happening in response to their input. It is important to realize that without a busy cursor, progress bar, throbber, flashing button, swirling baton, dancing clown.. it doesn't matter ANYTHING- if you don't have it, and the computer just sits there doing nothing, the computer looks broken to the user.

immediate feedback for every user action is incredibly important.

Neumeyer

Is it? Shouldn't the user start to get used to apps that work so well that they don't say anything when they are processing? the user goes on the to next thing, and the process... processes. – Been

The user doesn't care whether the computer is processing or not. All they care about is whether the computer seems like its responding to the user's commands, instead of just sitting there like a silent lump. Example: Ejecting a usb key from "My Computer". It actually works, but how can you tell? – Neumeyer

Answer 4

You show a busy cursor when the user can not do anything until the operation is completed - including exiting the application.

I find it interesting that you don't see busy cursors in Web Browsers - perhaps that why people like them so much.

No, wait, I have a better answer. You show a busy cursor when the computer is thinking.

Athwartships

Well, yes, I agree, but I'm looking for a more specific example. – Sinless

My sarcasm seems to be lost here. I usually get a +1 for wit and/or charm. – Athwartships

you don't see them in web apps very much because in IE they are next to impossible to set body-wide. if you set the cursor of the body (in FF, Chrome, etc.) it works fine, but in IE you need to set it on every element which just becomes goofy. – Wilscam

Answer 5

When one hits the Refresh button on a web browser, busy cursor must appear immediately to tell the user to let them know that a page is being loaded.

I think it was Don't Make Me Think that said that the tolerable loading time for human is zero second.

Google says:

Responsive

It's possible to write code that wins every performance test in the world, but that still sends users in a fiery rage when they try to use it. These are the applications that aren't responsive enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to process input.

Superjacent

the page being loaded is quite adequately indicated by the rotating icon on the tab (spinning 'e' logo for example) this is not a busy cursor. Busy cursor's relate to the entire application. I think your answer is ambiguous. – Sinless

On this page, you find some scientific values on response times: useit.com/papers/responsetime.html – Mourning

Answer 6

There are two purposes for it:

1. Indicate for the user that something is happening.
2. Indicate for the user that nothing can't be done right now.

Busy cursor is better signal about the operation than nothing. For longer lasting operations something better should be used. For example browsers is still operational when a page is being retrieved and there is even a button to stop the operation. As the user interface is fully functional, there is no need to use busy cursor. However busy cursor can be used even in this kind of situations in the transition phases like when starting the operation or when stopping it.

Unsettled

but why actually stop the user from doing anything, surely they could be doing something while waiting for whatever is happening... even if it's just editing some configuration settings, or looking at the help-about dialog – Sinless

Because it would conflict with the ongoing operation and so cause bugs. Busy cursor is an easy solution. Other solutions require more work. – Unsettled

If you make all the operations purely functional then any changes to data that would alter the calculations you're doing should be restarted, yes it is more work, but it is important work that really should be done. – Sinless

Answer 7

I try to use them on any action that may take from 0.5 to 3 seconds, for longer actions I think progress indicators with enough information should be used.

Exhume

do you mean typically take 0.5 to 3 seconds, or is the timing of the operation actually bounded? – Athwartships

why not do the work in a background thread allowing the user to continue using the application? – Sinless

@Jesse: If the user it's waiting some output, for sure will be annoyed if he doesn't know what's happening and how more time he will have to wait. – Bathelda

Check this table: sapdesignguild.org/community/design/… – Bathelda

@CMS: busy cursors do not indicate progress. Progress indicators are far more effective than busy cursors. – Athwartships

@Daniel: yeah, busy cursors only indicate "activity" – Bathelda

I have interpreted "busy cursor" to mean that the mouse cursor changed to an hour glass and there is not other indication of what is going on (this is often associated with an application "freezing" - bad). Busy cursors give no context - which bit of the app is busy? Again, bad. – Athwartships

Answer 8

I noticed with Fedora 8 at least that when an app sets the "busy" cursor, the "busy interactive" one is actually displayed. I guess this is because the system is still responsive to mouse input (like dragging the window etc.). As an aside, selecting the "busy interactive" cursor explicitly on linux is tricky: http://www.pixelbeat.org/programming/x_cursors/

Lail

Answer 9

The only thing I believe the busy cursor does is it informs the user that ...

I'm not outright ignoring you, I'm just doing something else that may take awhile

Active

but when is that justified? Why should the user ever be blocked from doing anything? – Sinless

In a perfect world they shouldn't. But software is far from perfect and operations that often cause this type of blocking can often best be solved with a multi-threaded solution which is not easy for even intermediate programmers to get correct. – Active

Answer 10

I would use them only for quick completing things, like say under half a second. If anything takes longer than that then a progress dialog should popup, or a progress bar should appear in the status bar or somewhere else in the interface.

The user should always be able to cancel the action if it is taking too long to complete.

In response to the comment, the busy cursor would only be visible for the half second or so, as once the progress dialog is up it should change to being one of those "half busy" cursors, or just the normal arrow cursor.

You should avoid having a busy cursor up except in extreme circumstances, and if you think you need one, then think again and redesign.

Dublin

When you have a busy cursor, you can't interact with the application, so you can't cancel the thing it's doing. That is the main reason I think they're bad! – Sinless

Okay you revised the question somewhat, so I guess my answer doesn't really fit anymore. – Dublin

Answer 11

While it is absolutely necessary to alert the user that your application is doing something, a busy cursor is only useful for the first few seconds of processing. For a delay of more than about 15-20 seconds, something else must be presented such as a progress bar, status message, message box, whatever. People assume your software has locked up after a minute or so and will try to terminate it. Sometimes, overall visual cues are just as important as a busy cursor.

For example, applications with tabs that do not respond with appropriate highlighting until the operation in the tab completes can be fixed up by updating the tab temporarily until all operations are complete. Sometimes, just a little optimization or refactoring will clean up horrible user interface responsiveness such as this.

Exception

I don't think you understand. Multithreading means that the user should never have to wait a couple of seconds while not being able to do anything, there is always something else they could be doing, for example, looking in the about menu, while their file is loading or whatever. – Sinless

Jesse, users don't care about waiting for just 2 seconds, so you don't need to go asynch (with all the associated complexity) in that case. – Budbudapest

Um, the problem I am referring to is in actual applications that exist. What is missing is a timely signal that the file is being loaded or whatever it was that the user asked for is happening. – Exception

Answer 12

For example, to indicate that you've clicked on a button, even though it's not done processing the event. If there were not some indication, the user might try to click the button again, causing all manner of badness.

Decern

No. 1. The button should be disabled once clicked, and re-enabled when it makes sense to click it again. 2. A busy cursor means the application is busy, so don't do anything. To me, all such work should be done off the main thread allowing you to continue using the application. – Sinless

If possible, that's great, but some actions do not permit any other actions. – Decern

can you give an example? I think the user never wants to be stuck waiting, at the very least they might want to read the help or something. – Sinless

Is there a badge for responding to old comments? ;) For example, in an audio editing program, reversing the current clip would have to finish before any other editing could be done. – Decern

Not that i know of, someone else changed something on this question, and i got notified about it. So I was just looking it at again. Yeah, but you might not be able to edit the current clip, but you'd still want the application to be responsive, so you can, for example, look at help, or perhaps even cancel the operation if it may take a long time. – Sinless