Make sure the buttons match the question


When your program displays a dialog box with buttons, please make the buttons match the text. Consider this dialog, which appears after you install patches from Windows Update:

It asks a yes/no question, but the options are “OK” and “Cancel”. Either the buttons should be changed to “Yes” and “No”, or the text of the message should be changed to match the OK/Cancel buttons. In the latter case, the text could go something like, “Windows Update will restart your computer. If you want to restart later, or close other programs first, click Cancel, and then restart your computer manually.”

Comments (34)
  1. Mike Dunn says:

    And while we’re on the subject, when you write your own dialog for messages like this, NEVER put Cancel on the left and OK on the right. This is Windows, don’t write your UI like it’s a Mac.</vent>

  2. Florian W. says:

    But I won’t hate you, if you put something like "Reboot" and "Leave installation pending" into your buttons (I’m german, so I think there are better words for this).

    And yes, there is a nice (german) text about good communication:
    http://www.kommdesign.de/galerie/kommunik/deus_ex_machina.htm

  3. In this case, the text will have to be updated to match the buttons, because script code running in IE can’t (that I know of) be used to generate a message box with any other set of buttons.

    On that note, I’m always very particular about which buttons to use, how to word the text, which icon is the clearest visual cue for the situation, and the last very important point, the default button. I always remember to select the appropriate default button, so users who just hit Enter or Space to get rid of the dialog without actually reading it won’t get burned.

  4. Howard Jones says:

    Chris: presumably Raymond knocked up a fake example… I’d like to think there’s no way of getting the IE scripting environment to restart Windows! :-)

  5. Howard Jones says:

    Chris: presumably Raymond knocked up a fake example… I’d like to think there’s no way of getting the IE scripting environment to restart Windows! :-)

  6. Howard Jones says:

    Chris: presumably Raymond knocked up a fake example… I’d like to think there’s no way of getting the IE scripting environment to restart Windows! :-)

  7. Jeroen-bart Engelen says:

    It’s not a cooked up example. WindowsUpdate can truly do this. It’s just no JavaScript/VBScript, but it’s an Active-X object.
    And on subject, I’d like to make the buttons even more clear. Not just "Yes" and "No", but how about: "Yes, reboot" and "No, reboot later". Or something along those lines. That way there is no question as to what each button does.

  8. Jeroen-bart Engelen says:

    It’s not a cooked up example. WindowsUpdate can truly do this. It’s just no JavaScript/VBScript, but it’s an Active-X object.
    And on subject, I’d like to make the buttons even more clear. Not just "Yes" and "No", but how about: "Yes, reboot" and "No, reboot later". Or something along those lines. That way there is no question as to what each button does.

  9. For maximum clarity, the options should always be labelled with verbs, e.g. "Save" or "Don’t save", "Reboot now" or "Reboot later". This removes any possibility of confusion (questions like "OK to cancel?" with possible answers of "OK" and "Cancel" are no longer possible), and means if you’re can infer the question without reading it, reducing the amount of time taken to do the task.

  10. For maximum clarity, the options should always be labelled with verbs, e.g. "Save" or "Don’t save", "Reboot now" or "Reboot later". This removes any possibility of confusion (questions like "OK to cancel?" with possible answers of "OK" and "Cancel" are no longer possible), and means if you’re can infer the question without reading it, reducing the amount of time taken to do the task.

  11. There’s something wrong with comments, which is presumably why everyone is posting twice. If you get an error, don’t hit back and press "Add" again: hit back, reload, bask in the warm glow of your wisdom, and chalk it up to experience.

  12. Serge Wautier says:

    I completely agree with comments about better button labels. The only problem is that you can’t customize message box buttons. You have to roll your own dialog. OK for a couple of critical messages. But if your application contains lots of warnings and questions (as any large application does), that amounts to a lot of work…

  13. Brian Luft says:

    You can customize the buttons on a MessageBox by using a local Windows CBT hook and intercepting the MessageBox’s HWND from the window activation notice. Perhaps Raymond could do an article on that?

  14. Brad Corob says:

    I disagree with the labelling of "Reboot Now" and "Reboot Later." Pushing a button implies an action… something will happen as a result of you pushing this button. Pushing a Reboot Later button implies that you are causing the computer to reboot later. Perhaps a clearer example would be "Reboot Now" and "Don’t Reboot" since this text more closely matches the actual action of the buttons. Of course the text of the dialog should still say something to the effect of "A reboot is required to complete this operation. Would you like to reboot now?"
    While I’m on the subject… consider the situation where I do choose Reboot Now and I have an unsaved Word document open. Windows sends a shutdown message to Word, Word realizes I haven’t saved my document and puts up the standard "Do you want to save changes? [Yes] [No] [Cancel]" While I’m deciding that, Windows gets impatient and assumes the app has hung, causing the countdown box (the one that has only ONE button – "End Now") to show up and all of the sudden I only have 20 seconds to pick a name and a location for my file. Not a pleasant experience at all.

  15. Timwi says:

    While I agree with what most people said (use clear words, esp. verbs, etc.), I strongly disagree with the wording "Restart Later". This has always erked me. It is very unclear what that button would actually do; it could be taken to mean that the computer will automatically restart some time later when you don’t expect it. A better wording would be "Don’t restart" or "Don’t restart now".

  16. Timwi says:

    Re Brad:

    "Windows gets impatient and assumes the app has hung […] and all of the sudden I only have 20 seconds to pick a name and a location for my file."

    That’s not actually true; when the 20 seconds are over, Windows doesn’t force the program to quit; instead, the user is given the chance to cancel the shut-down process then. It is also possible to cancel the shut-down process by clicking "Cancel" in the Word dialog you mentioned.

    However, I agree with you that the 20 seconds countdown is bad design for because it gives the *impression* of allowing the user only 20 seconds to save their file. It’s also bad design to only have the "End Now" button; often enough I’ve just pressed Enter to get rid of the message, and suddenly my Word document was gone.

  17. MilesArcher says:

    I think it’s worse to have long buttons full of text instead of Yes/No or Ok/Cancel. The only acceptable reason for this is for something with possibly disaterous consequences. And then, put a "do you really want to reformat your hardisk?" message after accepting it. If I spend the time reading the text, I shouldn’t be forced to figure out which button to push. it should be obvious.

    Last think I want to see (in english) is german style NounsBunchedTogetherwithVerbs in a dialog box.

  18. Howard Jones says:

    Chris: presumably Raymond knocked up a fake example… I’d like to think there’s no way of getting the IE scripting environment to restart Windows! :-)

  19. RE: Howard Jones

    No, Raymond did not cook up that example, that’s really what WindowsUpdate does (I’ve never tried to find out how, nor do I care). I wasn’t referring to a script being able to reboot the computer, I was referring to a script’s inability to choose any other buttons besides OK and Cancel.

  20. Dave says:

    The question asked is much more important and can be changed simply (am I wrong?). Thus, asking right question is the only way to get the right answer.

    I remember a question asked during installation of an open source operating system, askin something like "Do you have a non-usb mouse attached to this computer?". This question is not that complex, but someone may stuck answering such questions, especially when question deals with rebooting the system.

    There are few more examples on Windows. When you want to remove some folders, Windows says "Access is denied. Check write protect blah blah.." and an OK button smiles at the bottom of dialog. This is not confusing, but this is driving me crazy; so which process is locking that folder, or do I have a chance to delete that folder somehow? This popup is definetely meaningless.

  21. Peter Torr says:

    The really annoying thing about that "End Now…" dialog is that it is Always On Top and centred on the screen, so it always covers the "Do you want to save?" dialog in whatever app you were working on.

    Another HUGE pet peeve is that you have (eg) a Notepad window open with unsaved text, and it is minimsed. You get a modal "Do you want to save changes to (Untitiled)?" and there’s no way to check if the contents of the text file are useful or not — your only choice is to hit Cancel (which aborts the reboot), restore the window, figure out if you want to keep it or not, then re-initiate the reboot.

    Argh!!!

  22. Raymond Chen says:

    Imagine what trouble you could get into if the "End Now…" dialog weren’t Always on Top: It could get stuck behind the program you’re trying to close (and which isn’t responding because it’s hung). And imagine if the hung program were itself marked Always on Top. Yes, it’s annoying, but "annoying" is better than "wedged".

  23. John Topley says:

    I think that the text on the buttons should be limited to one word if possible. Users don’t read text. See http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

  24. James says:

    The text originally suggested to match the OK/Cancel buttons is way too long. As John Topley said, users don’t read. Even worse, the more text there is, the more daunting it looks, and users will be even less likely to read it.

    Making the buttons self-descriptive really is the only good solution.

    I suppose if I didn’t have any control over the button names (e.g. a JavaScript alert), I might consider:

    "OK: Reboot now
    Cancel: Don’t reboot"

    instead of using complete English sentences.

  25. Centaur says:

    There is a chapter in MSDN dedicated to message boxes and what buttons they should have. What is worth noting, it says:
    ===
    When you include Cancel as a command button in a message box, remember that to users, Cancel implies restoring the state of the process or task that started the message. If you use Cancel to interrupt a process and the state cannot be restored, use Stop instead.
    ===
    Since, from the user’s point of view, the task that started the message was the installation of patches, this hypothetical user may be under impression that the patch will be uninstalled if he/she clicks Cancel.

    Was it possible to use a full-fledged dialog box here, like the one used in modern installers, showing two radio buttons will full-text captions “Yes, restart the computer now” and “No, I will restart later”?

  26. pUnk says:

    Reminds me of a presentation I once watched at Apple… The presenter was using PowerPoint and somehow got out of the "slide show" mode during the talk and then got a modal dialog for starting the slides again with buttons labeled "Restart" and "Cancel". This person then hesitated a few moments over the "Restart" button, presumably because, in MacOS you get a very similar dialog when restarting the machine!

  27. JF says:

    What about every dialog having only "OK" and "Cancel" but every option selected via the appropriate radio box? This would allow for the dialog’s ok and cancel functions to remain consistent, while allowing an assortment of messages. The only problem is that it would require more reading, and users do so hate reading :)

  28. Centaur says:

    On a totally unrelated note: That screenshot ought to be a banner :) It so /affords/ pushing Cancel.

  29. "Imagine what trouble you could get into if the ‘End Now…’ dialog weren’t Always on Top: It could get stuck behind the program you’re trying to close (and which isn’t responding because it’s hung). And imagine if the hung program were itself marked Always on Top. Yes, it’s annoying, but ‘annoying’ is better than ‘wedged’."

    Sure, it has to make that message topmost. But there’s no reason it has to be so stupid to put the message *right on top* of the application’s modal message.

    It would be so easy to look at what window is currently topmost and simply avoid having the "End now…" window cover that window.

  30. Scott says:

    Could you go over and talk to the dialog designers on the Visual Studio team and tell them to change their "Do you want to debug this?" dialog. You have to hit "Cancel" to start the debugger. It’s awkwardly worded.

  31. Raymond,

    You missed something else. The icon on the dialog should not be a question mark. Go read the WIndows UI Guidelines on MSDN.

  32. Robert Cassidy says:

    Wow, a lot of you guys aren’t familiar with Mac human interface guidelines. Way back in 1984 Apple mandated that affirmative buttons restate the action that will take place and the no action button be labelled as ‘Cancel’.

    The whole point of this was the acknowledgment almost 20 years ago that users don’t read the text, or that a large number of users can’t carry comprehension from a paragraph forward to the buttons. If nothing else, the button should state the action for the user.

    On the Mac, you should almost never see Yes/No, or OK/Cancel. In the example above, you should always use Reboot/Cancel or Debug/Cancel or whatever. The reason for putting cancel on the left is that we read left to right – the safe option should always come first.

    I’m not sure why MS opted to develop the convention of all dialogs being Yes/No, Ok/Cancel and putting the safe option on the right. Perhaps it was differentiation, but I have yet to understand why they perpetuate this. It’s terrible practice and I see people hit the wrong button all the time, particularly when the dialog text is stated in the negative form which happens from time to time.

    The problem with the radio button dialogs is that ‘Ok’ changes meaning depending on the radio button. It’s strange to need upwards for 4 buttons (A, B, Ok, Cancel) to select at most 3 options (A, B, Cancel).

Comments are closed.