The scenario is all too common: An application brings up a dialog box while you are typing, and you hit the space key before you even realize what's happening. The dialog is gone and you have no clue what it said.

This is a fundamental problem with dialog box design. How do we solve it?

One possibility: Firefox brings up a confirmation dialog when installing add-ons but disables the OK button for 3 seconds. This prevents accidental confirmation (and forces you to read the warning), but in general I don't think it's a good idea to force the user to wait.

  • 2
    If he'd wait 500ms seconds before accepting OK, I think that would be ok. But there are times (e.g. deleting files or other repetitive tasks) where I intentionally confirm rather quickly.
    – giraff
    Commented Aug 15, 2011 at 15:18
  • 1
    Firefox's delay isn't about usability, it's about security. Certain sneaky webpages would ask get the user to click on a particular spot on the screen, and trigger the installation dialog at just the right time so the user would accidentally click the install button. Commented Aug 17, 2011 at 13:14
  • @Mike Weller: True, but the usability is a side effect. Commented Aug 17, 2011 at 14:20

7 Answers 7


Edited: The focus shouldn't be on the button by default. That way, Spacebar (or enter) wouldn't dismiss it. This also depends on how important the modal is. Does it need to block the screen? Could it be a notification inline?

Great articles on Modal dialogs and similar problems:

  1. http://humanized.com/weblog/2006/09/11/monolog_boxes_and_transparent_messages/
  2. http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

Additionally, if it is really important, you should make the user THINK before clicking OK. Example I made a while back.

  • 5
    Can you summarise the contents of those links (to prevent linkrot)?
    – Rahul
    Commented Aug 15, 2011 at 16:07
  • 2) was an very interesting article, but could you please explain its relation to this question?
    – giraff
    Commented Aug 15, 2011 at 16:50
  • Just curious--if the user has no mouse, which key should they use to indicate confirmation if not Enter or Space? Commented Aug 15, 2011 at 18:42
  • Emddudley: Good point, I edited. Rahul, I should...time, time time. Giraff, the first one is about how many modals shouldnt exist in the first place. The second one is a dissertation on modals with best practices.
    – Glen Lipka
    Commented Aug 15, 2011 at 22:07

Just don't display the dialog box whilst the user is in the middle of typing - they're busy anyway.

If the dialog box is something to do with what they're typing, then a more discrete notification might be better anyway precisely because they are busy and are trying to get a train of thought out.

It shouldn't be too difficult to detect when the user is typing away and only popup a dialog when there's a lull in the typing.

There's going to be exceptions to this - there always is!

[Popup dialogs should be avoided as a first rule anyway. Not that they're not necessary sometimes, but just give a thought as to whether it can be done a better way.]

  • 1
    Sometimes other applications will pop up a dialog and steal the focus from whichever application you're typing in. It's probably something designers shouldn't do, but it happens. Commented Aug 15, 2011 at 18:41
  • @emddudley yes quite. Are you looking for a solution that you can control from your application, because I'm looking at it from the bigger picture - eg it might be part of the OS framework. Commented Aug 15, 2011 at 18:52

While the design of the dialog box may have some issues. You need to question why is the dialog box being used. If it is informational, it is obviously interrupting the users normal workflow and should probably be eliminated and the message should be logged and stored somewhere else. If it is something where there is an action associated with it, an undo function should be provided.


A background task should not be interrupting what the user is doing right now. Does the user absolutely have to stop what they are typing and address this issue now? Almost never, unless the computer is about to catch fire. It can put up a dialog, but the dialog shouldn't take focus.

If the dialog has to take focus (because maybe the computer is going to catch fire) then there shouldn't be any kind of accidental input, keyboard or mouse, that should make the dialog go away. Have a null field receive input until the user explicitly switches focus.


The problem is that asynchronous input focus changes are fundamentally a broken design; they're subject to highly user-visible race conditions. While ugly and dated, "dialog boxes" are at least usable for synchronous prompts (direct responses to an action the user just initiated, as long as there's no perceptible delay). But when an asynchronous even needs a response from the user, the question and response buttons should appear in a dedicated part of the application UI (think of the "plugin blocked" or "cookie blocked" notification mechanisms in Chrome or Firefox) and require a click on the interface element or special key combination (that would not otherwise be meaningful) in order to give a response.


Perhaps this is one time where animation would actually help.

Imagine this:

  1. The dialog box comes up in an instant with no animation and no buttons. The user ought to be able to view and read the message as quickly as possible.
  2. After 500ms, the OK / Cancel buttons fade in.
  3. After another 500ms, the OK button is automatically set to focus if they haven't yet clicked anything.

You could certainly adjust those times if needed. But I think something like that would prevent most accidents, without being too slow and annoying.

  • 1
    You're assuming the user is looking at the screen while they type - there are a lot of people who type by watching the keyboard. Most people in fact; touch typists are the minority.
    – Bevan
    Commented Aug 16, 2011 at 21:49
  • @Bevan - That's a good point. Of course if the screen dims and a dialog box comes up, it may still grab their attention from their peripheral vision. But still, I suppose you could consider not setting the focus on any button at all. Commented Aug 16, 2011 at 23:17

In three words :

Dont' steal focus.

Much can be also be said of intrusive dialogs jumping to the foreground whereas they should calmly appear at their place, in the background.

And many dialogs should not appear at all.

[ No, I don't want to update Camino now, not more than yesterday, not more than the day before yesterday… ]

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.