Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 16 down vote favorite
4

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.

share|improve this question
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 Aug 15 '11 at 15:18
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. – Mike Weller Aug 17 '11 at 13:14
@Mike Weller: True, but the usability is a side effect. – M. Dudley Aug 17 '11 at 14:20

6 Answers

up vote 5 down vote accepted

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.

share|improve this answer
3  
Can you summarise the contents of those links (to prevent linkrot)? – Rahul♦ Aug 15 '11 at 16:07
2) was an very interesting article, but could you please explain its relation to this question? – giraff Aug 15 '11 at 16:50
Just curious--if the user has no mouse, which key should they use to indicate confirmation if not Enter or Space? – M. Dudley Aug 15 '11 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 Aug 15 '11 at 22:07
up vote 6 down vote

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.]

share|improve this answer
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. – M. Dudley Aug 15 '11 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. – Roger Attrill Aug 15 '11 at 18:52
up vote 2 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 0 down vote

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.

share|improve this answer
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 Aug 16 '11 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. – Steve Wortham Aug 16 '11 at 23:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.