How would you handle users who don't read dialog boxes? [closed]

Answer 1

Lots of good advice above. I just want to add to the book recommendations - Joel Splosky's "User Interface Design for Programmers" book is worth reading:

http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941/ref=pd_bbs_sr_4?ie=UTF8&s=books&qid=1222233643&sr=8-4

Answer 2

First of all, stupid should hurt, but usually it doesn't so...

The next best thing is including an icon that tries to convey the severity of the issue. Some percentage of those who won't read might change their habit if the dialog's icon seems ominous. Some percentage won't read it regardless.

Answer 3

I try to design applications to be robust in the face of accidents -- either slips (inadvertent operations, such as clicking in the wrong place) or mistakes (cognitive errors, such as clicking Ok vs. Cancel on a dialog). Some ways to do this are:

1. infinite (or at least multi-step) undo / redo
2. integrate documentation with the interface, via dynamic tooltips and other context-sensitive means of communication (One paper that is particularly relevant is about 'Surprise, Explain, Reward' (direct link: SER) -- using typical psychological responses to unexpected behavior to inform users)
3. Incorporate the state of the system into said documentation (use the current user's data as examples, and make the documentation concrete by using data that they can see right now)
4. Expect user error. If there's a chance that someone will try to write to a:\ when there isn't a disk in place, then implement a time-out so the system can fail gracefully, and prompt for another location. Save the data in memory until it's secure on disk, etc.

This boils down to two core things: (1) Program defensively, and (2) Keep the user as well informed as you can. If the system's interface is easy to use, and behaves according to their expectations then they are more likely to know which button to click when an annoying dialog appears.

I also try very, very hard to avoid anything modal, so users can ignore most dialogs I have to use, at least for a while (and when they really need to pay attention to them, they have enough information to know what to do with it).

It's impossible to make a system completely fool-proof, but I've found that the above techniques go a long way in the right direction. (and they have been incorporated in the systems used to develop Surprise Explain Reward and other tools that have been vetted by extensive user studies.)

Answer 4

If you must use a dialog, put descriptive captions on the buttons within the dialog.

For example, instead of OK and Cancel buttons, have them say "Send Invoice" and "Go Back", or whatever is appropriate in the context of your dialog.

That way, the text is right under their cursor and they have a good chance of understanding.

Mac OS X does this most of the time. Here's an example image.

Edit:

This is a better image, and I found it at the Apple Human Interface Guideline site, which is a great reference, and very readable. This document on that site is all about Dialogs.

Answer 5

Wrong question. "How would you handle users" starts at the wrong end.

The correct question is "Given that dialogs distract users from the task at hand, what better alternatives exist?".

When working to achieve a goal or finish a task, we can distinguish three situations:

(1) The application comes to the conclusion that there is no action it can take which will make the user achieve the goal. Pop up a message, with one button to dismiss it. You don't care if the reader understands it, since the outcome doesn't matter anyway.

(2) There is only one action that you can take, or the alternatives are irrelevant to the user. Don't bother him at all.

(3) There are two or more ways of achieving the goal. Let the user choose between these. Do not formulate this as a yes/no question. (Vista offers this as a common dialog, to replace the message box.) If at all possible, do not make this an irreversible choice.

The exception to this rule is the situation where the user would expect a yes/no question. But really, if that is the case, then why isn't the question part of the normal workflow? Dialog boxes are outside the normal workflow.

Answer 6

One suggestion:

1. Don't use dialog boxes. Especially modal, OK/Cancel dialog boxes.

Sometimes that is hard... how do you handle opening a file? Sometimes it's easy... do you really need to warn the user that they are about to overwrite a file? Chances are, if I'm blindly clicking "OK", I'm not going heed any warnings whatsoever.