Which is better approach and why.
views:
90answers:
6
+3
A:
You should seek out the UI guidelines for the platform you are developing on (search for "human interface guidelines" or "look and feel design guidelines"). If they exist, you should follow them so your app is likely to conform to the user's expectations. For example, Apple has specific guidelines for what to do in this situation on Mac OS X.
The typical advice for this particular scenario is not to have "Yes" or "No" buttons, but buttons that describe the action they perform. For example, you can display a message box like: "Document a.txt has been modified. Save changes?" with the buttons "Save", "Exit without saving", and "Cancel". This makes it clear to the user what each button will do.
You can find [Microsoft's UX guidelines here](http://msdn.microsoft.com/en-us/library/aa511258.aspx) (it's a 46 MB PDF).
josh3736
2010-06-25 01:32:09
+7
A:
Instead of a yes/no question, use a question with custom buttons:
The file blah.txt has been modified. Would you like to save or discard it?
+------+ +---------+ +--------+
| Save | | Discard | | Cancel |
+------+ +---------+ +--------+
Greg Hewgill
2010-06-25 01:11:44
+1; this is the appropriate way to pose the question. The buttons are where most users expect them to be and do what users would expect them to do.
josh3736
2010-06-25 01:22:41
And more importantly, the Cancel button gives the user a way out if they don't actually want to quit.
Matthew Iselin
2010-06-25 01:24:56
The destuctive action is placed in the middle... that is asking for trouble! ( [my solution](http://stackoverflow.com/questions/3114917/on-close-msgboxdo-you-want-to-save-or-msgboxdo-you-want-to-quit-w-o-savin/3114968#3114968) )
alexanderpas
2010-06-25 01:29:48
+2
A:
Your application should, as one of its primary goals, NEVER lose user's data. One way to accomplish that is saving regularly the work the user has done without user intervention.
That's the paradigm most people are used to in real life. When people write in a notebook they don't expect the paper to ask "Do you want me to actually commit these changes to paper?", they expect the changes to be permanent unless they choose explicitly to throw them away.
So, I wouldn't even ask that question, implement a robust undo functionality, and merely ask (maybe at the beginning of the work session) for a new save file name if it's a new work, saving continuously and upon exit.
These ideas come from the very enlightening Why Software Sucks... And What You Can Do About It.
Vinko Vrsalovic
2010-06-25 01:16:46
I strongly disagree - in most other applications (at least on Windows and Mac), "Yes" **saves** the work. You'll find you have very grumpy users if you switch the meaning of Yes and No on them.
josh3736
2010-06-25 01:20:23
@josh3736: That might be true, but the fundamental problem is having to ask a question. This whole "save? Yes/No" paradigm is flawed. I'll remove that sentece because it seems to distract from the main message
Vinko Vrsalovic
2010-06-25 01:22:23
Fair enough, even though I'm not sold on your main point either. I think Word has a good model. It saves to scratch files (in case it or the computer crashes), but if you're dissatisfied with the changes you've made, just close and discard. You could argue to continually save and allow the user to revert to a previous save, but I think that goes against the mental model most people have when it comes to editing files. (How many would know you *can* revert?)
josh3736
2010-06-25 01:26:38
@Vinko: It might be "flawed" (and I agree with you on that)... but most users expect specific behaviour. Changing it in this case will leave them wondering if their work actually did save or if it somehow got lost. Or it'll leave them annoyed because all they did was "bump" the exit button :)
Matthew Iselin
2010-06-25 01:27:26
@josh3736: That model you mention this approach would be against was created in the first place due to software not adapting to the people, but the other way around. It's not there because it's intuitive or the natural way, @Matthew: The argument about user expectations is mute. While true, those expectations are there only because everybody does it the wrong way, not because the model is better. If implemented properly (there are a few tools out there that do it now) users will not notice.
Vinko Vrsalovic
2010-06-25 03:08:07
It's important to note this is the way to ask on a Mac; having the buttons in this order on Windows would be out of place. See @.yahoo.co.jpaqwsykcj3aulh3h1k0cy6nzs3isj's answer.
josh3736
2010-06-25 01:29:50
Not only on a Mac, but on (at least) ubuntu also.The way it is usually asked on windows is the worst way (read [the blogpost by Jeff Atwood](http://www.codinghorror.com/blog/2010/03/the-opposite-of-fitts-law.html) ) as the discard button is in the center!
alexanderpas
2010-06-26 16:57:58
+1
A:
Something else I personally think is important is setting focus to whichever button is the equivalent to cancel. I think a lot of users get accustomed to these kind of prompts and just hit enter without even reading what is on the dialog. When they do this I think in most situations it's better to play it safe and cancel than to commit something.
Steve Sheldon
2010-06-25 02:11:50
A:
I hate being asked if I want to save, personally. If I needed to I probably did. If I've forgotten then most programs I use have an auto-save feature.
The idea about seeking out UI guidelines is good, but I agree with the person who suggested minimal user intervention. His analogy about writing on paper hit the nail on the head. Many programs come with some sort of version control these days.
daedalus0x1a4
2010-06-25 02:35:27