When do you use the ‘OK’ button and when do you use ‘Close’? Does one imply something that the other does not? Since changes to the current dialog aren’t saved until you click the ‘OK’ button in the OK/Cancel button methodology, does the same hold true for a single OK button?

What about the ‘Close’ button? Are changes not saved until you click ‘Close’ or have changes been constantly saved the whole time?

What’s worse is when you start considering the red x button in the title bar. If the dialog only has a close button, you can reasonably assume that it does the same thing as the ‘Close’ button. But what about when it has an ‘OK’ button? Does the red x act as the missing ‘Cancel’ button, or is the red x just another ‘OK’ button then?

What a mess.

Let’s start by reviewing some examples. Here’s a dialog that lists the restricted sites in IE:

You can add and remove URLs to and from the list. Easy enough. You presumably click ‘Close’ and then the list starts being used by IE. Presumably. I could test it to make sure, but that’s the point. I don’t know for sure.

Next, let’s look at the dialog I used as the OK dialog example:

This dialog is pretty similar to the one we just reviewed. You can add and remove URLs to and from the list, but in this case you also specify if they should be allowed or blocked. Still not that hard. However, in this case you click ‘OK’ when you’re done. Since I’m an experienced Windows user, I know that my changes aren’t saved until I click ‘OK’. However, usually there’s a ‘Cancel’ next to it. Hm… I’m a little confused, but I’m still thinking that my changes aren’t saved until I click ‘OK’.

So in the first example, I (the user) had to guess what the ‘Close’ button did and in the second example I assumed what it did. However, in both I didn’t know for sure.

We never want users to have to guess how our dialogs work. It should be blatantly obvious. If that’s difficult or even impossible to do, at the very least make the dialogs in your application behave and look consistent. That’s the number one thing I preach to others and try to do myself.

But back to the point at hand…

Here’s a third example. In this dialog, you can import, export and completely remove certificates from your system:

If you the user are not familiar with how certificates work, you may assume that you can import, remove, import, import, import all you want and nothing actually happens until you click that ‘Close’ button. Oh, how mistaken you would be. After you click the ‘Import’ button and finish importing a certificate, it’s on your system, baby. IE isn’t waiting for you to click that ‘Close’ button. It doesn’t care. That certificate is imported.

So now we have two dialogs that don’t save changes until you finish your work, and one dialog that saves changes the whole time…

…and they’re not sticking to any convention.

The first and third dialogs use a ‘Close’ button and the second dialog uses an ‘OK’ button. So here is what I propose to you: You should always use ‘Close’ when there’s no option to cancel. ‘Close’ simply means that: close the dialog in it’s current state. Don’t revert anything. Don’t make any other changes. I’m satisfied with how things look in the dialog right now. Clicking the red x isn’t a secret cancel shortcut. It just closes the dialog as well.

It may still be a little unclear if the dialog uses an immediate commit model where saving is done immediately throughout interaction with the dialog or if it uses a delayed commit model only when you click the ‘Close’ button, but now there’s at least one less thing the users have to deal with. Maybe we can tackle that problem in the future.

But anyway, all that is just my opinion…

…when do you use ‘OK’ and when do you use ‘Close’?