A great example of bad dialog box design – Part 2.

July 3, 2007

Douglas Karr pointed out that I should put my money where my mouth is and explain how it should be redesigned. Having given it some thought, I’ve realised this is a particularly tricky dialog box – the problem does not exist just at the level of the dialog box but more widely, for example:

The keychain: what the hell is it? To a naive user this is a hairy concept.

The security of your computer: What caused the application to update? Was the source trustworthy?

The repercussions: what does the decision actually mean? What’s the worst that can happen? How can I recover from making the wrong decision?

I’ve also just realised that this has been blogged about elsewhere, with some great comment discussions. Read more here, here and here.

My working “solution” is shown here. It’s still fairly wrong but at least it’s more clearly worded and the button labels actually correspond to the question.

I pinged you on it because I think you were a little premature in your criticism for a couple reasons:
1. The Keychain is thoroughly explained the first time you have the opportunity to utilize it in OSX, so users actually do understand the terminology and would not abruptly come across this without a clue of what to do. The dialog window in question, could have been worded better – but an OSX user (especially one that’s updating their applications) should understand what the dialogue is stating.
2. There really is no deny. Since the previous application is already in the Keychain, you must answer the question ‘once’ or ‘always’. If you don’t want it in the Keychain, you can open the Keychain and delete that application from it. The keychain isn’t quite the same as a Windows Password reminder, it’s much more accessible.

“1. The Keychain is thoroughly explained the first time you have the opportunity to utilize it in OSX, so users actually do understand the terminology”

It’s a terrible idea to assume that the user knows. Quite possibly he didn’t read your “thorough terminological explanation” because his attitude is “what do I care, I want it to just work”. The Mac philosophy actually encourages that kind of thinking.

Or maybe the explanation was half a year ago and he just simply forgot.

“2. There really is no deny. […] you can open the Keychain and delete that application from it. The keychain isnâ€™t quite the same as a Windows Password reminder, itâ€™s much more accessible.”

No, the deny button is the point of the whole thing. From what I understand, the dialog is designed for the following situation: I’m evil and replaced your Safari with a malicious program. I managed to do this without your noticing. You start “Safari”, thinking it’s the legitimate thing. Then it tries to access your keychain to silently email everything to me.

In this situation the dialog is important. The idea is that the user goes “whoa, I didn’t consciously update that app, this is fraud”. The “deny” button is the point of the whole dialog.

Hendrik

July 4, 2007

My take on how to fix the dialog: Get rid of it.

1. If I develop a Mac application, I have to specify a URL somewhere in the app’s metadata. It points to a file on my website which lists all the app’s versions.
2. When my app is installed and first uses Keychain, Keychain stores the URL.
3. When my app is updated and Keychain would normally show the dialog, it instead checks the URL, which tells whether the new version is legitimate (could be identified with MD5 sums). Note that it looks at the URL of the old program, which we assume as legitimate.
4. If legitimate, Keychain updates without asking.

More technical effort, and not fleshed out, but less problems for the user. (Didn’t Apple have that philosophy in some distant past? Nowadays it seems to be “appearance is everything”. Which is of course a better philosophy as far as marketing and cult-building is concerned.)