September 7, 2004
Why is it, 10 years after the publication of Alan Cooper's seminal About Face, applications still regularly present this dialog to me?
Cooper said it best on page 136:
It is possible to argue that users have come to expect this behavior; that its absence would cause experienced users to fret that changes were being mistakenly discarded when the program ends. This rationale is like saying that a beaten dog expects to be beaten again, so we should beat it to make it happy. The time to make our programs better is now.
It never ceases to amaze me how little real progress is made in the area of UI. In this era of 300gb hard drives, I should never be explicitly prompted for much of anything. Save it all, and recall the stuff I need. Don't ask me for permission, just do it, and let me take it back later if I need to. Of course this is harder to program, but so what?
When presented with a database application for the first time, many users ask: "But how do I save?" Imagine that. An application that saves your work automatically. Revolutionary!
Posted by Jeff Atwood
I actually use this "feature" when I need to copy/paste/rearrange some text in documents (to copy to another document/email) without saving them. So just get what you want, modify the document, and when prompted, answer No. :)
Document versioning is too time taking to implement... and then there's the document modified flag in the C++ document view architecture that prompts the user when the document is modified.
Shannon, that's your stockholm syndrome talking. The saving should happen automatically-- saving your work should be the default, not throwing away your work! How insane is that?
In other words, it should be like a magic, transparent version of source control. All changes are versioned for you without you ever once being nagged by an annoying dialog. Sure, it's a bigger technical hurdle, but what the heck are we using these 3+ghz CPUs and 300+gb hard drives for anyway if not to make our lives easier?
I think this is something that WinFS was supposed to do, too.. treating the filesystem like a transactional database.
What you're describing is the 90/10 rule. 10 percent of the time you have a legitimate reason to lose your work-- but why make the rest of us suffer the other 90 percent of the time?
If you are willing to deal with the dialog for this extraordinary circumstance, certainly you'd be just as willing to do a "File, Revert To Previous Version". The unusual circumstance should take a little extra work. The usual-- hey, just save my changes automatically-- should not..
The main problem with saving automatically on closing (or at any time) is how you achieve it. If you are working with a fixed file format that doesn't support version information (most, including plain text), then it can only be achieved by having a separate file with this information.
However, any separate file that contains parts of the original document could pose a security risk when dealing with sensitive data. This would have to be handled with extreme care.
Also, I close documents that I have changed without saving often.. I see no reason why I should have to reopen them to restore them to their original state. It's the sort of thing that I would forget to do.. potentially causing me great embarrassment.
Sorry for commenting on an old post, but I couldn't leave this alone.
We have to step back and look at the larger audience of most applications. The simple fact is that the vast majority of computer users are more like our moms than coders. Jeff is absolutely right. If 90% the user population just wants everything recorded 90% of the time (I suspect in this case the precentages are higher) then it does the vast majority of your users a disservice to impose an extra dialog box on them.
The problem is cumulative. It may not seam like that big of a deal to have one little dialog box like this. When you perpetuate this philosophy you end up with applications that become burdened with decisions that don't match what the users are trying to accomplish. When that happens, user get frustrated. And snyone in retail knows that frustrating your audience is a great way to make them go away.
So maybe this will work itself out economically. Those who continue to build software burdened with decisions that don't match user needs will simply lose business over time as more and more people come to expect a better user interface.
It gets worse: turning on a Siemens mobile phone results in "Are you sure you want to turn the phone on?"
well I sort of think that people should be able to back out of anything until the very last second. I often find myself press ctrl+s out of habit, then realize wait... I don't want to save this (for some reason). perhaps I want to keep it how it was, and not how I just changed it. for automatic saving, a record of all the changes made would sort of be necessary, as you say.
and of course (as I'm sure others mentioned), it's harder to program this, and takes up more space.
but that's just rambling. my main point was that people, when using computers, expect to be able to cancel anything until it's absolutely too late.
Where do you save it? Do you add another file every save, keep updating old saves even when most people don't always want everything saved? Where on the disk do you save it? Do you present the user with a request for a location every time they run the program. The problem I've seen most people face is not "have I saved that?" but "where did I save that" . So always present people with that dialogue at least ensures people know they have saved and WHERE they have saved. Then I'm sure you'll argue that we shouldn't have hierarchical data storage but then thats under the OS control and not the program writers control. Exiting a program doesn't mean you want it saved, you are presuming users when you should be teaching and explaining to users. Does the average user have 300Gb?
I think having a separate commit (save) process is the best way to handle document editing in some situations, but not in others. The metaphor is that there is an actual paper document somewhere, you are making a copy of it, making edits to this copy (while the original stays the same), and then committing these changes to the original. In some circumstances, I don't think you want the original, official document to be in a condition where it is incomplete (the state where you have made some edits, but are not finished). This is true with shared documents, where you don't want another user grabbing your document that you are only half done editing; that user wants the last completely edited document, not some copy of the document where a sentence is half completed. However, when you are the only one using the document, I think that auto-save would be a nice feature. There is no "commit" phase, as whatever is currently displayed on your screen IS the official document, and you are changing it.
It is like source control with programming. It would be a nightmare if changes to the source were committed whenever you made an edit (the "official" source in the source control could easily be in an uncompilable state), but this would only be a nightmare if there are other users that need to be able to access the source control. If there are no other users, and you are just using source control as a kind of backup and revision tracker, then autocommit may not be a bad thing (although the "revision tracking" would get slightly more complicated!).
Amazingly, IntelliJ IDEA has actually done autosave for years!
What's the status on this in Visual Studio? Eclipse?
Save, more than just committing a set of changes to non-volatile storage, is an expression of intent: it means here is a set of consistent changes that I want to export and/or revisit. I make an argument to that effect on my blog, here: http://it-arcana.blogspot.com/2008/10/on-auto-save.html
"harder to program" means much more expensive. More expensive means fewer people will do it.
It seems pretty obvious to me why auto-save is not available in most applications.
This can be said about UI in general. Most users are overly tolerant of bad UI. Therefore, little money goes toward improving UI.
I think that "ask user if they want to save when they close a changed document" is my favorite feature ever. It has saved (no pun intended) my butt many times when I have forgotten to save and/or didn't mean to close the window. I love that feature and I rely on it.
But when I open a text file and systematically cut each line[paragraph|section] from the file and paste into a second file/interface, I like and expect that I can close the text file and get the dialog you show above and simply click "no" and everything will be just as before.
Not sure which syndrome is talking, but my personalities took a vote and the majority say they love that feature.
(BTW, the autosaving feature of OneNote is the best thing since sliced bread, but it is a totally different model, the program never really closes, so it must continuously save)
Have you ever clicked the Cancel button when shown that dialog? I have. Usually because I didn't realize there was a change or because I didn't mean to close the program. In both scenarios (the first is due to a very common problem in too many programs, the second is all my fault), I am glad I have my seatbelt on.
Until the first scenario is no longer a problem, I think we need that dialog. Otherwise, too many documents would be silently changed and saved.