I just saw this lecture by Spolsky, where he questions the need for choices and confirmation dialogs. At some point he has a MacOS settings window and he mentions that "now some are getting rid of the OK button". The window indeed has no OK (or cancel) button. Changing a setting makes it change, when you're done configuring, you close that window, period.

Being a long time Windows user and a recent Mac owner, the difference is noticeable at first. I looked for the OK button for a while, only to find out, quite naturally and painlessly, that there was none. I expressed satisfaction and went on my merry way.

However, I'm curious to know if this UI design pattern would succeed in the Windows-based world. Granted that if Microsoft brought it out with say Windows-8 (fat chance, I know), people would get used to it eventually. But is there some experience out there of such an approach, of changing the "confirmation paradigm" on a platform where it's so prevalent? Did it leave users (especially the non-technical ones) confused, frustrated, scared, or happy?

TL;DR: Remove OK/cancel confirmation, what happens?


Mac GUI for appearance settings.

alt text

7 Answers 7


I find a nice middle ground is when some text is temporarily displayed (not in a pop-up) saying "your change has been successfully saved" or something similar to Google Doc's auto-saving

  • Very good point. Definitely better than a modal window proclaiming "Hey, I just did something!!"
    – MPelletier
    Commented Nov 25, 2010 at 17:13

If there's no OK/Cancel, there better be Undo.


You said so yourself : you looked for the OK button for a while. Users should find things right away.

  • 5
    By that standard you could never improve a really bad system that at least one user has been trained to use. Commented Nov 25, 2010 at 16:04
  • @Niphra: Yes, but I'm a developer. I'm wondering if non-technical people will feel alienated.
    – MPelletier
    Commented Nov 25, 2010 at 16:06
  • @Niphra: Oh, I'm re-reading your answer differently now. Yes, users should find things right away, but they are looking for an arguably superfluous step. Does that still apply?
    – MPelletier
    Commented Nov 25, 2010 at 16:08
  • 1
    @Thomas: the question specifically stated we weren't talking about a widely used app ("Granted that if Microsoft brought it out with say Windows-8 (fat chance, I know), people would get used to it eventually"). You can change users' habits when you build the software they will use everyday, otherwise it will annoy them. Commented Nov 25, 2010 at 16:35
  • 1
    "Elegance and familiarity are orthogonal" -- Rich Hickey Commented Nov 26, 2010 at 10:25

The thing is, that works very well with technically proficient, confident users. However, I think you'd run into a world of hurt with non-proficient users who frequently, say, mis-click, or change a setting other than the one they intend, and suchlike - especially if the dialog that you just closed without a confirmation is hard to find for non-proficient users.

Less "are you sure?" dialogs would be great for me - but it would kill my mother.


But is there some experience out there of such an approach, of changing the "confirmation paradigm" on a platform where it's so prevalent?

Introducing a total change of paradigm in an established environment and for just a routine operation would stall a great number of users.

Did it leave users (especially the non-technical ones) confused, frustrated, scared, or happy?

If the change does not address a known problem, but just introduces something different "to try it out", then this change will likely invoke all of the mentioned emotions except for happiness.

For me this sort of dialogs is one thing that I strongly dislike. Why? Because it's not immediately clear how it works. You have to learn and adopt this way of thinking. Meaning it's not good for inexperienced users.

Look at the meaning of the word "dialog". It's the two-way communication between the machine and the user in this case. The natural way would be:

U: Change the setting
M: I changed it (text message or something)


U: Change the setting
U: Click the save button
M: Indicates reaction (message, dialog disappearance, page refresh)

How the Mac dialog spins off:

U: Change the setting
M: ..... (silence)

The user is perplexed. Did it work or not? Unknown. The user checks the things out. Dialog didn't happen.


The role of the confirmation dialog is for the user to CONFIRM that the changes he made are the ones that he intended to and he didn't changed something unintentionally.

If a world with no OK buttons you must ensure that either:

The user makes always the right choices [yeah, right]


  1. The changes are not irreversible
  2. The undo operation is simple
  3. Once a change is done without confirmation from the user, the user is aware of its effects - in a short after. You don't want the user to find out that the change he made unintentionally, 6 weeks ago, had unwanted effects

So, in conclusion, I don't think that confirmation dialogs prevents user from taking the wrong decision or doing something unintentionally but at least it offers another layer of protection for the end user. However, for a user with a lot of experience, this might be annoying.

  • Obviously there's degrees here. For example, you absolutely want your "Delete all tables, files, and settings irrevocably" option to have a solid confirmation. Yet cosmetic changes, or ones easy to rollback, could be done silently, even if there's no direct undo for some.
    – MPelletier
    Commented Nov 26, 2010 at 1:30

I don't like it and would miss the OK/cancel buttons for many dialogs. As others have pointed out, it becomes more forgivable if you can undo the changes, but therein lies the problem.

You don't necessarily want your undo system to capture changes to, say, application preferences. Otherwise that gets goofy when you hit ctrl-z or cmd-z to try to undo a change you made inside the application's world or canvas or whatever only to undo changes to the application's system preferences when you were trying to undo a brush stroke or text change, e.g.

And it's typically in those application preferences/settings/options where you tend to find these OK/cancel dialogs. So I really think they're fine as they are, at least for cases where it makes no sense to store an undo entry for the changes you make in that dialog.

A practical improvement if you ask me is to make it so changing whatever is inside the dialog gives you an interactive preview so that you don't have to hit "OK" before you can even see the changes. But that doesn't require getting rid of the OK and especially the "Cancel" button which lets you discard the changes if you don't want to keep them.

I also think there's a bit of a craze to make everything non-modal these days, and maybe some dialogs are definitely better if they're non-modal. That said, I don't find it makes sense to allow an application to have 7 non-modal file dialogs open at once. Often the non-modality comes at the cost of making it more difficult to rapidly open and close that dialog (ex: being able to close it with escape key and restore the focus back to whatever had focus before), so I still like modal dialogs here and there in cases where it doesn't really benefit the user much to be able to open a boatload of the same type of dialog.

I worked in a team where they thought everything modal was bad and foul and something to be made non-modal, so after a great deal of work, we ended up with an application where you could, indeed, open like 7 "open file" dialogs at once. And I only found the workflow more awkward and cumbersome than ever before where I could no longer just hit ctrl+o, navigate to a file, and hit enter to select it and open it or escape to close back out and restore the application control focus to whatever it was on before. With the non-modal file dialog, it also didn't close when you selected the file(s) to open. It would stay open, so you had to close it with a separate step. That encouraged this very cluttery UI with way more non-modal windows and dialogs open at once than you were actually interested in unless you manually closed them to manually clean up the UI all the time. With the previous modal design, the UI would automatically stay clean since the dialogs would close themselves after you selected the file(s) to open, e.g.

Imagine if Starcraft had a non-modal design. Then instead of this:

enter image description here

You might have a screen with 800 icons on it in docked panels, representing all the possible options you could perform in the entire game with 99% of them being grayed out and disabled and not making any sense in any particular context. The super rapid workflow of Starcraft is possible because it favors this kind of context-sensitive modal sort of design where you have to select a unit, click an icon (ex: "build"), then you get something like a modal pane/matrix showing what things you can build with that unit with buttons to cancel and go back and so forth. It's a "one step at a time" modal mindset and it's due to the simplifying nature of that modal design that there are Korean players who can perform like 300+ actions per minute.

If you ask me, applications should be more modal and contextually driven like this focusing on one thing at a time, not many things at once, if we want to allow users to work really, really quickly.

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.