Those of use who routinely use SSH know how sheerly infuriating it is when the agent asks you if you want to trust a host key and will you please enter “yes” or “no” (not “y” or “n”, mind you) to confirm your choice. Yet, none of us would like to change that because, in the end, it is for our good.
SSH knows it’s annoying. It know it forces us to go out of our ways, think about a word and type it on our keyboard to interact with the program. But, by doing so, it also knows that it forces us to have a meaningful interaction with our machine: even the less experienced of users will realize, by doing so, that he provides an answer to a specific question.
The question SSH asks is relatively cryptic (Do you want to trust a specific host key?) but dismissing it without thought is impossible. Modern dialogs, on any interface, come with a default “OK” button that one can systematically trigger by pressing return or enter on our keyboards. It’s easy, tempting and a seemingly quick solution.
But maybe it is too simple? After all, in many cases, security revolves around a couple dialogs that all sport the same shiny, pulsating/underlined/colored “OK” button that we all want to click on to just regain control of our machines. Look at the extents to which Apple has gone when you enable FileVault on a Mac: there are two dialogs, both magnificently breaking the Aqua guidelines by piling up colored text, bold lines, buttons and warnings in just about every direction. Why? Because these are required to shock users and get them to think.
Maybe a simply text field, along with the instruction “Please type Yes or No in the box below to confirm or cancel your choice” would do wonders. It certainly would be “new” enough for users to think and feel like they’re about to make a big decision but it would keep dialogs clean and to the point.
I’ve always wondered how the community felt on this topic. Am I the only one thinking text dialogs have their advantages?
Yes, they are
Apple addresses this in their Human Interface Guidelines by suggesting developers avoid "Yes/No" type dialogs and instead using descriptive verbs for button labels. By doing this the user is forced, at least a little more, to read and comprehend what they are clicking.
From the section on push buttons ( http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGControls/chapter_18_section_2.html ):
----------------------------------------------------
Button names should be verbs that describe the action performed—Save, Close, Print, Delete, and so on. If a button acts on a single setting, label the button as specifically as possible; “Choose Picture…,” for example, is more helpful than “Choose…” Because most buttons initiate an immediate action, it shouldn’t be necessary to use “now” (Scan Now, for example) in the label. Don’t use push buttons to indicate a state such as On or Off (where it would be more appropriate to use checkboxes).
----------------------------------------------------
I really like this convention. As far as I'm concerned, the "OK" button is a relic.
Dialogs are often designed and used poorly
The first problem is (as another poster said) that the dialogs are not well-designed in a way that would call attention to them. The Yes/No/OK buttons are always the same and in the same place, and there is no text that 'sticks out' or calls attention to itself. As a result, all dialogs *look* the same, whether or not they're saying "Process Complete" or "Are you really sure you want to delete core system files?"
And yes, I've known people to click Yes in the latter case simply because they didn't realize this dialog was asking them something different than the last 30 dialogs they saw when they tried to delete a file, and then watch their computer go boom.
The other problem is that dialogs are overused. They should only be used in cases where your attention is absolutely needed, yet like the "Process Complete" example, many programs pop up a message dialog with an "OK" button when some simple UI indicator on the screen could do as well. (i.e. having a progress dialog instead) As a result, again, people lose sight of the importance of such dialogs, and they lose their worth.
I think developers need to take UI design more seriously in general and consider the ramifications of what look, on the surface, to be rather mundane choices.
Yes, they are
Hi!
First of all, thank you very much for sharing your feelings with us!
Yes, the "OK" button is definitely a relic and the Apple guidelines, if followed closely, should be a step in the right direction. Unfortunately, many applications following these guidelines and using verbs prefer verbs carrying the meaning of "continuing" such as "Proceed", "Continue", "Accept", instead of using more specific buttons like "Install", "Download", "Activate" that would be more likely to raise questions in the mind of the user -- at least, in my humble opinion...
FJ
Dialogs are often designed and used poorly
Hi!
I entirely agree that, with dialogs being too often the same or similar looking, users are not provided with enough clues regarding the seriousness of what they agree to or refuse.
Maybe color-coding dialogs, like one tags log entries would be a help?
FJ
Dialogs are often designed and used poorly
The only thing about color-coding the whole dialog is that you'd want to use strong colors to indicate urgency (like red), which might affect the readability of the dialog.
Taking another note from the Apple HIGs, you could create a brief summary of the dialog text and make it large and in bold at the top of the dialog. Like "Delete System Files?" so that you can be sure the user will read that, which *should* get their attention to read the longer description of the problem. This text could be in red, etc., or maybe have some icon which conveys urgency.
While I'm often the first one proclaiming that developers should follow the conventions of the platform they're running on, I do think in this case Windows and Linux particularly could use an overhaul in their standard dialog design.
Wouldn't help
Requiring the user to type, rather than click, and answer wouldn't help. The only thing it might force them to read is, "Please type Yes or No in the box below to confirm or cancel your choice," but not the text above it that explains to them WHAT is is that they are confirming or canceling.
Instead of instinctively clicking "Yes" (in poorly designed dialog boxes that feature such a box, such as seen in a good percentage of Windows software), users would just as instinctively type Y-E-S-return (just as you probably do at that SSL prompt).
As said below, Apple's HIG suggests a better solution. Not just by the use of verb buttons, but with a brief, bold sentence with critical information that the user is likely to read, as well as additional text, in normal weight, that provides additional, but not critical, details.
Here's another idea
Here's the example I've seen so many times. The user is going to delete something, so we ask them: "Are you sure you want to Delete this?" But since 99% the answer is yes and it's a real nuisance for them to have to hit the "Delete" button, we'll make it the default. So we've created a generic dialog to warn the user and if they screw up, it's now their fault. Problem solved.
Of course, when the user sees these dialog boxes popping up all over the place, they get a conditioned response: "Dialog pops up, hit Enter, dialog goes away." The reward is that the job is accomplished. So your warning is basically useless because you've conditioned your user to ignore it.
But rather than trying to come up with creative ways to get your user to notice the dialog, here's a better solution: Just do it.
Under the Edit menu is this handy thing called Undo which is supposed to undo the last task. Once you support undo, it's amazing how much of the conditioning you can get rid of. The Mac frameworks I've used--MacApp, PowerPlant, Cocoa--have had an undo facility. There's really no excuse not to use it.
If Undo is too difficult for some reason, though, consider putting your destructive commands someplace else. The trashcan is a good example. Move all the things you want to delete into a trash can and then empty the trash.
This way, when you really do need to put up an "Are you sure?" dialog, that alone will be shocking enough to get the user's attention.
As for the dialog itself, I think one of the best ways to get the user involved is to give them information. My favorite example of this--and an Apple screw up, in my opinion--is the Empty Trash dialog in Mac OS 9 versus Mac OS X. When you emptied the trash in Mac OS 9, you got a dialog saying something to the effect of "You are about to delete 17 items taking up 267K of disk space. Are you sure?" Mac OS X just says "Are you sure?" and warns you that you can't undo it. Because of the information in this dialog, I was more likely to read it (and it did save my life once or twice. "The trash contains 300MB? What the hell is in there? Oh my God! How'd that get in there!?")
I think there's a happy median in giving the user information to get their attention. Give the user too little info, they'll ignore it because it's not important (eg, "Are you sure you want to delete all the selected files?") Conversely, giving the user too much information will cause them to not read it (eg, "Here's a list of the 549,873 files that will be deleted. Are you sure you want to get rid of all of them?") Finding that happy median isn't easy but it will allow you to get your dialog noticed by the user--and for the right reasons!
Here's another idea
Under the Edit menu is this handy thing called Undo...
While, in general I agree this is the best way to handle it, there are situations where it doesn't work. See the ssh example. If you just 'did it' you could be turning the keys to your computer over to someone. Not something you can undo.
The other major problem with undo in almost all applications is that all of that wonderful undo history just goes bye-bye in one very common case: closing the file. That, personally, is something I would really love to see addressed.
Yes, they are
That's all very well, and Apple's guidelines on writing good dialogs are very thorough. You can read them at http://tinyurl.com/dwq2f
However they're not always consistent about this. In the section about button text for alerts they say: "Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete." However right about that is a picture of the Trash emptying confirmation dialog which uses Cancel and OK. Pathetic!
Even worse is the use of 'Yes' and 'No' for button labels. This is utterly meaningless, as what will happen depends on how the question is phrased. Madness! And Apple do it themselves, for instance in Mail's 'Erase Junk Mail' dialog.