How do I create a TaskDialog with a progress bar but no cancel button?

A developer from another group within Microsoft wanted to create a Task­Dialog with a progress bar, but they couldn't figure out how to get rid of the Cancel button.

Reticulating Splines
Contacting Spline Reticulation Server

"Is there a way to remove all the buttons from a Task Dialog?"

Um, users hate it when you give them a window that cannot be closed or cancelled. What should the user do if the reticulation server stops responding? Shut down the computer? (Hey, at least shutting down the computer will actually work.)

"The process usually takes around two seconds, and we time out after ten. In the case of timeout, we replace the progress dialog with a failure dialog with the options Close and Retry. But for this dialog, we just want to show the progress bar so they know that we are doing something. We have not yet finalized the design. One design is to have a Cancel button on the progress dialog; another is to remove the option to Cancel. We're just investigating the possibility of the second option. We haven't committed to it yet."

You should leave the Cancel button enabled, and if the user clicks it, then go straight to the "timed out" dialog. Removing the Cancel button leaves the user trapped in a dialog box with no escape route.

Bonus chatter: By an astonishing coincidence, a few weeks after this email exchange concluded, I happened to encounter the Reticulating Splines dialog, and it got stuck, and there was no Cancel button. The frustrated user who got trapped with a window that could not be closed or cancelled turned out to be me.

Comments (35)
  1. SimonRev says:

    Not to take away from the point of the article which is don't implement a brain dead UI.  But if you are determined to frustrate your users, wouldn't it have been much easier just to implement a trivial dialog with just a progress bar rather than spend hours trying to figure out how to force a task dialog to do your bidding, then burn a tech support incident, wait for a response.

    Now imagining how it went after Raymond responded, I can envision their programmer spelunking around with FindWindow and EnumChildWindows to find the control with the correct ID and calling ShowWindow on it.  This will break in some future version of windows and then Raymond will have to implement a compatibility shim for the software.  So Raymond can look forward to fixing things again in the future.

  2. pete.d says:

    Agree with the philosophy of not showing a dialog that can't be closed.

    But if one doesn't want the Cancel button, why not just include a close button in the caption area?

    Just because the UI has to remain usable, that doesn't mean it has to remain cluttered.

  3. Brian_EE says:

    Does it really matter if there was no cancel button? I mean, really, the cancel button on your dialog just brings me back to this page with the progress bar still stuck at the same location.

  4. AvWuff says:

    Good old SimCity!  Reticulate those splines!

  5. dave says:

    Users also hate it when confronted with a progress bar that does not indicate how much progress is being made.

    Judging by the screen shot showing a chunk of blue in the middle of the space allocated for the bar, this is one of those rotating-pattern things that fails to reassure me that anything other than the pattern-rotating thread is still alive.

  6. jk says:

    @dave yes but usually just showing generic progress is the best you can do as users also hate it when you initially predict 2 mins to completion then constantly recalculate how long till completion.

  7. John says:

    @dave:  Indeterminate progress is better than no progress.

  8. Joe Dietz says:

    Funny, that's pretty much how I feel about not being able to dismiss apps on my win8 slab, particularly the apps that have gotten stuck doing something and I can't re-spawn them (I'm looking at you kindle!).  I guess you are just old fashioned Raymond, its modern to feel trapped.

  9. mike says:

    Visual Studio 2012: Projects loading in the background via a progress dialog that cannot be cancelled. :) Perhaps Raymond can go bonk them on the head for us all!

  10. Dan Bugglin says:

    I have my own Cancel button for programs that don't provide their own… "End Process".

    @dave @jk @john Windows actually cheats and provides progress bars where they don't know how long something will take, at one point.  IIRC it's in service start/stop from the services snap-in.  You'll see the progress bar fill up slowly and then pause near the end and slow down filling A LOT, IIRC.  The dialog winks out as soon as the operation completes, even if the progress bar only just started filling.

  11. Joshua says:

    I've done something like that "No Cancel Button" deliberately. Two basic cases:

    1. The dialog box is monitoring a system process at a higher level privilege. In this case, the user doesn't have permission to alter the operation. The monitor can be closed (button "Exit") but the operation will run in the background.

    2. Cancelling the operation would leave the system in a wedged state for which the only option is to restart it anyway. In this case, I didn't implement cancel at all as there'd be no point. I'm aware of "End Process". If you need to do that, you will need to restart the operation or go get your backups.

  12. Kemp says:

    I wish more companies had someone to tell them this sort of thing. I've encountered so many dialogs where force-killing the application was the only way out when something died (of course, catching an exception that stops the task but still leaving the dialog box up is a WTF in itself). The worst, though, is when there is a cancel button that does nothing or puts you in a situation with even less control. Often this seems to be when it tries to reverse the operation and either 1) that in itself takes a ridiculous amount of time and there is no cancel button on the backing-out or 2) the reason for the initial task failing also causes the backing-out to fail and there's still no cancel button.

  13. SheepNine says:

    The cancel button on the dialog in your blog post doesn't actually cancel the dialog.

  14. Henke37 says:

    Other things that suck: Cancel buttons that doesn't work.

  15. JJJ says:

    I use a C++ IDE (not VS) that likes to hang every once in a while with an animated progress bar that doesn't show real progress and a cancel button.  Clicking cancel does nothing.  Sometimes it makes things worse by locking up the entire UI.  So I guess if you're going to provide a cancel button, make sure it can actually cancel operations in progress.

  16. Adam Rosenfield says:

    The Adobe Flash plug-in installer has a progress bar that guesses (I'm not sure how) the install operation is going to take.  The progress bar smoothly fills up from 0% up to 100% as time goes on.  If the installation finishes before the predicted time, it jumps from wherever it is to 100%.  If the installation takes longer than predicted, it just halts at 99% until it finishes.

    Frankly, I'd rather have the rotating pattern than that, since the total duration can depend on so many unpredictable external factors.

  17. Joshua says:

    @Adam Rosenfield: And I'd rather have one that advances irregularly with the steps than that.

    The Windows XP installation had a "time remaining" that could be considered as a progress bar as it did no time measurement. Shaping that as a progress bar would work surprisingly well.

  18. fred says:

    @Joe Dietz  

    But you can dismiss Win8 apps.

  19. jon says:

    Users hate it when forced to start with the metro start menu rather than the desktop, can we have an option for that please?

  20. Mike says:

    If all they need is a progress bar why have a dialog at all? Why not just have a progress bar in the status area at the bottom of the window for example?

  21. 640k says:

    Cancel button that doesn't work: Hello msdn library!

  22. GregM says:

    "If all they need is a progress bar why have a dialog at all? Why not just have a progress bar in the status area at the bottom of the window for example?"

    According to my users, "It isn't obvious enough.  The dialog in the middle of the main window is much more noticeable."

  23. fred says:

    @jon I think it's time to get over it. Users hate having to learn the difference between the left and right mouse buttons, users hate having to decide between yes and no when a dialog asks if they want to save their document, users hate having to get out of bed in the morning.

    Where I work we've had a custom app for years that launches on startup and presents the users with a grid of the applications that they have access to. Hmm…sounds familiar.

  24. Random832 says:

    @jk "but usually just showing generic progress is the best you can do as users also hate it when you initially predict 2 mins to completion then constantly recalculate how long till completion."

    Well, if you have a concrete measure of progress (like size of file copied), just show that without making a time estimate. Of course, don't take too long figuring out the size. You could show a label showing what you do know, for open-ended tasks (like what file you are on, how many files have been copied so far), but be careful you don't update the label too often or you'll become I/O bound in the GUI.

  25. Destroyer says:

    @The MAZZTer

    Good example, but there is a more common one! Windows explorer green progress bar in the breadcrumb address bar, certainly in Windows Vista and 7… once it gets toward the end of the speed of travel decreases in halves. Before it often reaches the end, the task is completed, and the green bar shoots across filling the address bar, or, it times out and the same thing happens yet with a dialogue box.

    Try putting a scratched DVD in or something or a very large folder with thousands of files in over a slow WAN link etc, you'll soon see it in action.

    I am sure it is not just me that has noticed that in EVERY single movie out there the progress bar to "launch the missiles" or whatever goes smoothly from 0% to 100%, and also makes some sort of beeping or ticking noise along the way as well as when any sort of screen change or text is displayed.

  26. Anonymous Coward says:

    [ Help!                                          [x] ]

    |                                                        |

    | I am trapped in a dialog box factory! |

    |                                                        |

    |                       [    OK    ] [ Cancel ]  |


  27. Evan says:

    @Anonymous Coward

    Maybe if the designer pleading for help was better at dialog design he or she wouldn't be trapped! How am I supposed to know what OK and Cancel do? Does "OK" mean "OK I'll help you" or does it mean "It's OK that you're trapped"?

    Sheesh, I mean this is like UI design 101. If your dialogs have OK/Cancel buttons on them you can probably improve them. :-)

  28. cheong00 says:

    Btw, I think we don't have cancel/close button for some splash screen too. Is that different?

  29. Mike Dimmick says:

    @The MAZZTer: That's a consequence of the Service Control Manager API. The dialog assumes (because it has no prior knowledge) that a service will take 20 seconds to start or stop. Well-written services can (and should) call the SetServiceStatus function, passing a SERVICE_STATUS structure, to inform the SCM (which informs its caller) of how the start or stop action is progressing. It indicates with the dwCheckPoint member how far it has got, and uses the dwWaitTime member to indicate how much longer it is estimated to take.

    The Services snap-in merely reports back what the service is telling the SCM. However, it often has already consumed a large percentage of the progress bar when the service starts to say 'er, that's going to take a bit longer actually…' and can only fill the remaining portion more slowly. Rewinding the progress bar to reflect the new actual progress versus new expected duration is probably *more* confusing than slowing down.

  30. EduardoS says:

    Thinking about it… We really need a kind of time-to-timeout progress bar

  31. Neil says:

    This sounds like something that would appear on the Interface Hall of Shame.

    I remember the Worms 2 progress bar didn't display real progress, just elapsed time, so if scenery generation took too long you would see it wrap around to zero again.

  32. Chris Long says:


    Windows 8 can already do that fairly easily; go to Folder Options, View tab, and check 'Restore previous folder at Windows log-on'.  So long as you have at least one Windows Explorer window open when you shut down, the next startup will show the Start screen and then immediately switch to the Desktop and re-open your Explorer window.  I assume that this would also work if you set any other Desktop application to open on start up in the usual way, though I haven't tried it.

  33. Nick says:

    @Chris Long: Yeah, this totally works with Server Manager in Windows Server 2012, too. But then again, everything's a little different in Windows Server 2012.

  34. David Walker says:

    @jon:  "Users hate it when …"

    Well, SOME users hate it, certainly, and some don't.  Please don't presume to speak for everyone!

  35. 640k says:

    @David: No user likes frozen GUI. Not a single one.

Comments are closed.

Skip to main content