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