I had a co-worker recommend that I set the cursor to an hourglass (probably the progress cursor as described here) while an operation completes, in a C# dialog. The operation can take a few seconds to a few minutes and is cancelable. There is also a timer showing how much time has elapsed. This program only runs on Windows.

But I haven't seen a wait/busy/hourglass cursor in quite some time, in either a desktop application or a webpage (although operating systems definitely use them, both Windows and OSX). I've seen a couple fragments from google searches about busy cursors being hated by UI designers but not a lot.

I'm pretty sure it's not a good idea for my specific case, but assuming that an application is otherwise responsive and well-behaved, is there a best practice regarding busy/hourglass cursors? Are they even helpful, or is it always better to have an explicit progress indicator in the form/page/window and omit the busy/hourglass cursor entirely so as not to confused the user?

  • I like it when applications use domain-specific busy cursors/animations e.g. an animation of virus scanning in anti-viruses. What does your operation do? Commented Aug 29, 2013 at 18:02
  • It queries a web service, changes the search button to a cancel button, and starts a timer. I'm sure we could come up with an animation appropriate to the data, but it's client software and they would never want to pay for it.
    – Chris
    Commented Aug 29, 2013 at 20:42
  • best practice: use the platform-specific one, if there is one. (I still have fond memories of walking dino.) On Windows the system default is hourglass until XP, spinny since Vista.
    – peterchen
    Commented Aug 30, 2013 at 7:49
  • 2
    “busy cursors being hated” – They are hated because waiting for something is always being hated :P
    – poke
    Commented Aug 30, 2013 at 11:39
  • 1
    @Jop In many cases I would agree with you, but the answer in this case is complicated and not relevant to this discussion.
    – Chris
    Commented Sep 3, 2013 at 15:04

6 Answers 6


The "busy" cursor and "background busy" cursor are frequent sights in Windows.

enter image description here enter image description here

You say, "...I haven't seen a wait/busy/hourglass cursor in quite some time." I believe this is because you have grown accustomed to them and no longer notice. Open Microsoft Word (2010), click on the "File" ribbon and click "save." You will see the "busy" cursor flash a few times. If you actually save a large document, you'll see that cursor again. This behavior exists in Adobe products, Microsoft products, IDEs, Open Source software and a large variety of software. These cursors are still there and still useful. These are not "operating system" using them, but applications. These application developers had to intentionally put the cursor in place; either by virtue of API or explicitly.

These are not only used by the OS, but also by any application. The icons serve an important purpose. In the case of the "busy" cursor, it indicates the the application/program will not accept input. In the case of the "background busy" cursor, it is an indicator the the application/program is in the process of performing an action, but that it will still accept input. The latter is useful to hint that the system may change while the user is interacting with the UI.

I believe these are still "relevant" and should be considered as part of any Windows or desktop design. This allows the user to continue to interact with the other applications and know that your application is "working." It conveys to the user something more meaningful than an unresponsive UI. This works two-fold: 1) The progress or "busy" indicator is seen only to apply to the area with mouse hover focus, 2) because the cursor is no longer a pointer, it reduces the users' expectation to use the cursor in the affected area.

If you are questioning the value of progress indicators in general: Is it bad UX to omit a progress indicator?

  • I'm sorry but this doesn't really answer the question. I don't see how hourglass cursors aid in "[interaction] with other applications", and it is pretty obvious that an hourglass means a program is working. I don't see how comparing cursors to an unresponsive UI is relevant - they are not mutually exclusive.
    – Chris
    Commented Aug 29, 2013 at 17:40
  • @Chris, I've expanded my answer. If this still doesn't answer your question, consider revising your question to clarify what you are looking for.
    – mawcsco
    Commented Aug 29, 2013 at 17:59
  • I have updated my question. I think you may be right, though, that I have just stopped noticing them. Office does indeed use them. I tried a few other programs, and quite a few of those did as well. Not all, though, and I don't personally think the others suffered for it.
    – Chris
    Commented Aug 29, 2013 at 19:39
  • You will get a "busy" cursor if an application thread locks too, or goes not-responding. But if you have isolated the work thread from the UI thread, you should not see this. Commented Aug 29, 2013 at 23:17

I think you and your co-worker are examples of those folks in the User Interface Conservatism versus Liberalism article.

It's battle between liberal designer (you) and conservative designer (co-worker).

What I really like in this article is:

The problem with UI liberalism is not that it necessarily makes for bad interfaces. On the contrary, there are some very good interfaces that provide new and innovative ways of interacting with virtual tools. And the problem with UI liberalism is not even that it’s easier to create a bad interface, though that is certainly true, since a UI conservative can create a decent interface merely by slavishly following the rules and relying on standard controls.

  • While this is interesting, it doesn't answer the question. Commented Sep 3, 2013 at 22:45
  • @BrianOrtiz, I meant the hourglass is an recognizible (conservative) time-consuming indicator on the Windows platform, so it could be quick and satisfactiry enough. Commented Sep 4, 2013 at 7:28

The best practice is for your application interface to remain responsive, even if it is currently performing an operation (though this doesn't mean the user can actually do anything, other than possibly canceling the operation). Pretty much every development platform will have guidelines to this effect.

The most common reason to encounter the hourglass cursor is that the current application is frozen (either permanently, or temporarily because its engineer failed to keep the UI responsive during expensive operations).

As such, the hourglass is associated with applications being stuck or broken, rather than being busy. As it is difficult for users to differentiate between a broken application and a busy application, I recommend indicating that an application is busy in some other manner (e.g., a progress bar or an in-dialog hourglass).

  • I was close to start writing the same. @Chris, try to do everything asynchronously and provide a simple way to see the progress. Nowadays with so many cores every CPU has it is almost a crime to show busy cursor or block a user in any other way. Commented Aug 29, 2013 at 19:05
  • Well, ignoring the fact that not every task is CPU-bound, there is always an arms race between hardware and software. That's no less true today than yesterday, and I don't think the busy cursor will ever be entirely irrelevant.
    – Chris
    Commented Aug 29, 2013 at 19:41

The Windows Guidelines for using these:

The following table shows pointers that users see when performing an action that takes longer than a couple of seconds to complete.
Busy pointer: Used to wait for a window to become responsive.
Working in background pointer: Used to point, click, press, or select while a task completes in the background.

Display the busy pointer when users have to wait more than one second for an action to complete. Note that the busy pointer has no hot spot, so users can't click anything while it is displayed.

Display the working in background pointer when users have to wait more than one second for an action to complete, but the program is responsive and there is no other visual feedback that the action isn't complete.

Don't combine activity pointers with progress bars or progress animations.

That pretty much sums up why you sometimes need to use these cursors and why you don't see them that much anymore.

It's usually clearer to have a progress bar of some kind. If you have one of those, don't use the hourglass cursor. Use the hourglass cursor if you don't otherwise communicate about something that's busy and might affect the application's performance. Use the busy pointer only when the application can't be used until the operation is complete.

In your case: don't use one. In most other cases: there are much clearer ways of communicating something is busy so avoid using the cursors. They are however still relevant for situations where they're the only option. And for locked/unresponsive applications.


I am not a designer, but anyway, I would say what I feel personally. I guess, i have learnt a bit about Design/UX although most of my work is coding.

As mawcsco said, and I agree with him, that you don't longer see them, because you are accustomed with it. In such a situation, the hour-glass doesn't really help in anyway, since no one notices it, or at-least regular users don't.

Coming to hour-glass versus a simple spinner (colored/rainbow), it's a choice left to the designers. Something that looks good with their application, should work fine. But, hour-glasses are old. They probably give a better meaning to the animation, than the simple spinners. In the old days, the hour-glass gave a sense of time to the end-user. If we were to use a simple spinner, may be the meaning wouldn't have been more clear to the end-user.

And I agree with you about having

"explicit progress indicator in the form/page/window and omit the busy/hourglass cursor entirely"

Animating cursors are actually annoying. Sometimes, I shake up the mouse hard, in the hope that the hour-glass/spinner falls off :D


I would say: think about your users. If waiting, even for a few seconds, will they think nothing is happening and try to click on buttons again? If so, what will happen if they do? Generally you want to provide good feedback to the user, to assure them they are on the right track.

I develop windows apps as well as some web stuff, and I generally prefer a wait cursor / splash screen, even if the process will only take a couple of seconds. Keep in mind that if a process only takes micro-seconds, then a flashing of a cursor might actually confuse someone "What was that? Was I supposed to see that?".

Like you said, if you have a responsive application, with good feedback, such as progress bars and so on. you may not need a cursor.

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.