Totally Agree. ;) The simple ratio: Tell your users what is going to happen after his or her action. This minimizes misunderstandings and frustrations.
I totally disagree; the OSX box is even more confusing. The problem is that you are performing two actions at the same time. First is closing the file and second is saving he file. For the box to be clear both issues have to be clear.
TextEdit:
Save - Clearly this saves the document
Cancel - I think this cancels the save, but does it close the file too? Not sure.
Don't Save - Ok "Don't Save", but then what? Does this close the document or is it the same as Cancel? Wait, I'm not 100% sure what cancel does.
The WordPad message is a little clunky because you have to read what the box in order to know you are saving. However, once you read the box Yes/No is very clear, cancel still leaves a bit to be desired.
If you really want to be clear the buttons should say:
Save,
Abandon changes,
Go Back
The key is consistency, in OS X cancel always reverses the last action without side effects. I find the OS X way much more clear. Microsoft agrees, see Windows Vista.
There are a lot of things in a UI that are Verbs. But there are also lots of things that are Tools. Tools seem to be devices that are used for certain verbs, or a single verbs. If there are plural verbs, these should go together in a way that makes sense. (Example: a file selection dialog that lets you navigate folders and create new folders.)
Are Tools valid? Are they over used? Are they used enough?
The Apple Dialog has the same information repeated FOUR times.
#1 Do you want to save the changes you made in the document "test doc"
#2 Your changes will be lost if you don't save them.
#3 Don't Save
#4 Save
FOUR times I am told what I'm doing, "Saving". Yeah, each iteration has a little more information added to it. "Saving what document?" "Saving is important why?" "What is the alternative to saving?" Thanks for the slowly unfolding tutorial there...
Okay. Listen, the MSFT dialog works like this. It's a boolean. It's very short and simple: The answer is "yes" or "no". The user gets used to this yes/no format.
Save? yes/no
Print? yes/no [<-- doesn't really exist]
Restore settings? yes/no
The consistency of this reduces one's need to actually read-and-process-and-understand what are extremely simple questions inherently.
The problem is that users typically read as little as is necessary to figure out what to do next--and very often, not even that much. Since the Windows dialog must be read entirely to be understood, it's more likely to be misinterpreted. E.g., a user may accidentally press "close," see the dialog, and think, "No, I didn't mean to close"... and then lose all their work.
The Mac dialog has a lot of text, yes, but it requires less reading to be understood, which, empirically, is what seems to matter most.
If you watch people use your software, one thing you notice right away is that many of them don't read ANY text. When a dialog shows up, they go straight to the buttons and click whichever one seems right--even if they don't know what the dialog is asking! It sounds crazy, but it's what people do.
The user doesn't press save in #1 -- the user exits the app. If the user pressed save, they would be met with a save dialog, which is something completely different.
What the article discusses is a dialog the user didn't expect. Something pops up and they have to figure out what it is. Now you can make the user read the message, or you can make the window scannable by sticking actions on button labels. Reading the buttons is much faster than reading the sentence above. Sure, you're gonna save like 2 seconds of the user's time, but these 2 seconds are going to be multiplied by thousands in the course of the user using the app or OS. Little touches like this help make a good product.
Your approach forces the user to always read the full text message and then select yes/no, merely out of fear of redundancy.
The Apple approach focuses on the action targets first, which 99% of users will go to (i.e. after they've done it the first time). The verbose message is only there as a point of clarity.
When you get into user-interaction design, you learn that redundancy is important. You don't put something in one place and make them look for it. You put it where they'd naturally look.
For example, if you go to a large store, masking tape won't be only in one place because people are seeking different "core" uses. So the same brand/package of tape will be found in the hardware section, the painting section, the crafts section, and school supplies.
The fallacy with Boolean yes/no buttons for every dialog window is that if the user doesn't read the message, they may not get the results they expected. For example, you try to print, and the computer freezes and wants to shut down. You think you're printing, so you hit "yes" and shut down the computer instead. A slightly ridiculous example, but you get the point...
23 comments
[ 1.6 ms ] story [ 61.7 ms ] threadGet Vista, it sucks less than XP unless your hardware isn't supported.
Verb Adjective Noun
"Enter New Customers" better than "Custs"
"Pay All Bills" better than "Accts Payable"
"Download Changed SKUs" better than "SKU Update"
You get the idea.
Not just for buttons, but for everything, even the stuff the user never sees.
So simple, yet so elusive.
TextEdit: Save - Clearly this saves the document Cancel - I think this cancels the save, but does it close the file too? Not sure. Don't Save - Ok "Don't Save", but then what? Does this close the document or is it the same as Cancel? Wait, I'm not 100% sure what cancel does.
The WordPad message is a little clunky because you have to read what the box in order to know you are saving. However, once you read the box Yes/No is very clear, cancel still leaves a bit to be desired.
If you really want to be clear the buttons should say: Save, Abandon changes, Go Back
Obviously, it "cancels" - eg puts things back into the state before you clicked 'quit'.
'don't save' quits, but does not save. You did click on 'quit' after all.
Personally I think that's pretty clear.
"Do you want save the changes you made to the document "Test Doc" before quitting?
Quit without Saving / Don't Quit / Save and Quit"
Are Tools valid? Are they over used? Are they used enough?
http://developer.apple.com/documentation/UserExperience/Conc...
The Apple Dialog has the same information repeated FOUR times.
#1 Do you want to save the changes you made in the document "test doc"
#2 Your changes will be lost if you don't save them.
#3 Don't Save
#4 Save
FOUR times I am told what I'm doing, "Saving". Yeah, each iteration has a little more information added to it. "Saving what document?" "Saving is important why?" "What is the alternative to saving?" Thanks for the slowly unfolding tutorial there...
Okay. Listen, the MSFT dialog works like this. It's a boolean. It's very short and simple: The answer is "yes" or "no". The user gets used to this yes/no format.
Save? yes/no
Print? yes/no [<-- doesn't really exist]
Restore settings? yes/no
The consistency of this reduces one's need to actually read-and-process-and-understand what are extremely simple questions inherently.
Exactly. The Windows dialog is very, very short. The apple dialog is a miniature tutorial on the purpose and consequences of this thing called "save".
If you watch people use your software, one thing you notice right away is that many of them don't read ANY text. When a dialog shows up, they go straight to the buttons and click whichever one seems right--even if they don't know what the dialog is asking! It sounds crazy, but it's what people do.
#1 User presses "Save".
#2 Is met with "Yes/no".
#3 Presses "yes".
Where am I confused? I'm getting downmodded by the mac-bots as usual, but the purposeless verbosity remains purposeless as far as I can see...
What the article discusses is a dialog the user didn't expect. Something pops up and they have to figure out what it is. Now you can make the user read the message, or you can make the window scannable by sticking actions on button labels. Reading the buttons is much faster than reading the sentence above. Sure, you're gonna save like 2 seconds of the user's time, but these 2 seconds are going to be multiplied by thousands in the course of the user using the app or OS. Little touches like this help make a good product.
The Apple approach focuses on the action targets first, which 99% of users will go to (i.e. after they've done it the first time). The verbose message is only there as a point of clarity.
When you get into user-interaction design, you learn that redundancy is important. You don't put something in one place and make them look for it. You put it where they'd naturally look.
For example, if you go to a large store, masking tape won't be only in one place because people are seeking different "core" uses. So the same brand/package of tape will be found in the hardware section, the painting section, the crafts section, and school supplies.
The fallacy with Boolean yes/no buttons for every dialog window is that if the user doesn't read the message, they may not get the results they expected. For example, you try to print, and the computer freezes and wants to shut down. You think you're printing, so you hit "yes" and shut down the computer instead. A slightly ridiculous example, but you get the point...