Home Donate/PDF Version Final Score Discuss   Categories:
Dialog boxes

"Confusion and clutter are failures of design, not attributes of information"
- Edward R. Tufte, Envisioning Information.

Let me illustrate a point by showing you just the buttons in an XP dialog box:

In the dialog above, would you know which button to click?

Ok, let's try the same dialog box with X:

save-panther.jpg

Now would you know which button to click? By the way, these screen shots were both taken from Save dialog boxes.

I don't like reading. X's buttons are often all I need to read. XP's I ALWAYS have to read the entire dialog box.

In the above examples, Mac OS X places the strongest visual weight on the safest button, and separates the 'safe' buttons from the 'unsafe' buttons, to reduce the chances of accidental clicks producing undesirable results. Windows XP also places greater visual weight on the safest buttons, but does not separate unsafe buttons from safe buttons.

save-panther-full.jpg Apple's own developer guide to the differences between Windows and Mac OS X explains: "clear dialogs in Mac OS X communicate to the user: 1) what happened, 2) why it happened, and 3) what to do about it. To ensure that consistent format, Mac OS X dialogs tend to use verbs as button titles." Note Apple's usability guidelines do not require verbs for button titles, but rather emphasize the value that they may bring to dialogs.

While we're on the topic of dialog boxes, consider this: any print publisher will tell you that wide blocks of text cause eye strain, because the eye has to navigate back and forth across such a large distance. That's why columns in newspapers and magazines are about 12 words across. Microsoft's dialogs do not adhere to this basic text layout rule, as seen here:

 

Not to mention that it just looks bad. Wrapping the text to three lines would make a big difference. (True, this example is Outlook, which is not included w/XP, but XP is replete with dialogs that don't adhere to publishing guidelines.)

Confusing Dialogs
Frequently I run in to dialogs in XP that I have to read and reread:

Notice how the second sentence does not logically follow from the first sentence. Consider this: if you select No, does that mean that rather playing it in "its own window" that it will play it in the current window? It turns out that if you select Yes, it will play it in a pane attached to the current window, something the dialog did not explain. If you select No, Internet Explorer will launch your default media player and play it in that application.

Defenders of this dialog may say that all you have to do is click the More Info button for clarification. However, a rewrite of this dialog would eliminate the need for a More Info button:

You clicked an audio or video link. You can play this in Internet Explorer or in your media player application.

Do you want to play the item in Internet Explorer?

That's better, however it illustrates the problem of requiring every dialog to use only Yes, No or Cancel as user selections. If you want to play the link in your media player, you have to answer No.

You can have wine or water with your meal.
Would you like Wine? Yes, No, Cancel

Imagine how difficult life would be if human beings could only use Yes or No style questions with each other. True, the kinds of interactions we have with computers is significantly less complex, however the point bears consideration.

The following choices for buttons would have a less negative connotation attached to using your Media Player and would be more logical:

Use Internet Explorer, Use Media Player, Cancel

My redesigned dialog would look like this:

It's shorter, less confusing, and you don't have to read the sentences. The buttons are quite descriptive all by themselves, so that most users wouldn't even need to read the explanation.

Using buttons other than Yes, No and Cancel brings up another issue. What keyboard equivalents should be used for these buttons? This issue in and of itself shouldn't be a reason to abandon verb-based/context sensitive dialogs. The above dialog is vastly more sensible than the original, and most users will click the options with their mouse, as opposed to the small group that will use keyboard equivalents. It's a bad idea to have a dialog that could be more confusing to everybody in order to accommodate a small minority who will navigate the dialog with their keyboard. Button selections could be made here by using the left and right arrow keys, or a letter in each button: perhaps Use Internet Explorer, Use media player, Cancel. One could argue that this would make dialog shortcuts less predictable or logical, but in the original example, how is typing N (for No) a predictable or logical way to play a video or audio link in your media player?

Dialogs stuck behind windows
This dialog got stuck behind the document it pertained to. Here's how: I wanted to capture this dialog so I clicked "Print Screen", opened Paint, Pasted and Saved. Done. Next, I went to the task bar to return to my email. Upon selecting the message, it came up, but it's dialog was behind it! Thankfully, enough of the dialog was visible next to the message that I could click it to bring it to the foreground. If a dialog gets stuck behind the window it pertains to you can't even drag the window out of the way to access the dialog. The only way to get the dialog box back in front is to activate it from the Task bar. I've noticed this with authentication dialog boxes from web sites too, since I'm frequently bouncing back and forth between multiple browser windows and other apps. I've spoken to others who've been the victim of this, and often they don't realize what's going on and force quit the stuck application.

True, the above example uses an application that is not part of XP, but this situation is not application specific, since it's the OS that is at fault by permitting dialogs to fall behind the window they pertain to.

Dialog boxes: OS X: 7, XP: 5

Pick a topic:
© 2003, XvsXP.com. All rights reserved.
Updated all the time.
XvsXP.com is owned and operated by Dan Pouliot.