There is a behavioral impact to the Save button. We are conditioned to think that the changes we make in a file do not apply until we hit 'Save', so it's okay to just close a file if you do not intend to 'commit' those changes.
Auto-save for recovery purposes is one thing, but when completely replacing the 'Commit when I tell you' to 'Save everything in real time' can have unintended consequences.
I keep getting caught by this on Google Docs. I whip in, accidentally change something while scrolling or copying and pasting, then close the doc. Bingo, I've lost information, sometimes entire paragraphs. What a pain. I should have the option to persist my changes when and how I want to.
Good point, but it's linear. It mixes accidental changes with intentional all in one stack. I don't want to have to undo good stuff just to get back to the stuff I lost. Visual stacks, comparison of versions, all of these are helpful... but at the end of the day, the tool should let me decide what version and changes I want to persist, and which I don't.
And that's why we can't just delete the save button. We need to rethink the way users "commit" as you say. Apple's versioning is an interesting take, but its UI is too hidden IMO and they didn't get the "Save-as" feature right, which still applies in a world without save.
My favorite UI would be a mixture of Apple's Lion logic and Google wave: Give me a prominent time slider, give me snapshots each time I hit the save button (which are basically just special markings on the slider) and let me use the slider to easily revert to any state. It gets more complicated with multiple users who commit asynchronously, which is something I will try to solve in an upcoming project of mine.
Of course a tree would be best. I just wonder whether can be presented in a way that is still intuitive for common users. I'm thinking one could emulate a linear history on top of the tree and just present the tree when desired by the user. Also, it would become very important to figure out what exactly is the most usable level of committing (words? phrases? text blocks?). I'm thinking about a system where a linear edit to one element of the underlying data structure (such as an xml element) is one commit, even if it's a whole story.
Interesting - and I suppose obviously your history can be mapped onto a line with some loss of expressiveness, if you view it strictly as time. As long as the more detailed history is available, I do not object to exposing it that way as well or (necessarily) even primarily; I just wanted to be sure it wasn't being restricted unnecessarily.
Thanks for your input. Yes, this is always one of the hardest things in UI design: Do I optimize for the "power user" (yes that dreaded word again) or the common user? Can I do both without any compromises? Besides possible monetary benefits it would immensely calm my ego as a developer having made something both easy and powerful.
A good example of this principle IMO is Apple Pages and Numbers. They are both succeeding at being powerful/expressive when you need it (Cmd-alt-i) and easy for the other times. It's just a shame that they haven't been updated and still lack some important features like plugins and bibliography.
This no longer applies if you use Mac OS X. Most settings dialogs have no "Apply" button and applications no longer have "Save" buttons. The user expects that things will be committed immediately as you do them.
In fact, there is no "commit". You just do things. And that's the way it should be.
After getting used to that, it's pretty annoying to use Windows, which keeps asking you whether you want to cancel or apply things in every possible situation. Sometimes it even defaults to reverting your changes if you just close the dialog box (like when changing the desktop background image in Win8, for example).
There just needs to be some UX work here indicating the document status. Just like typing a chat message. "blahblah has entered text"-style. Evernote did this early on in their Windows application, we did it with Ubernote - it rocks. Everything should be autosaved+versioned.
I think the save button more or less provides a way to save a version or "mark" one. I don't want to see the button disappear, but rather change into a "mark version" button that allows auto-saving to happen, but gives the user the opportunity to set their own points of reference in a document's history. In software that auto-saves, I often feel a bit disoriented. It makes it harder to jump back to a certain state of a document.
It actually does an auto-save for you, silently in the background. But there would be an uproar if they got rid of the save button entirely - people like to feel in control of their important data.
Wow, I don't say this very often, but tl;dr. Every single argument made in the article has been made elsewhere, but more concise. By the end, I was saying "Yes! I get it already! Enough!"
In summary:
Computers are smart enough to autosave. The save button is an anachronism. We should think about retiring it.
This might make sense in office programs, but I'd hate this for program code at least.
I think saving should not be needed except when you want to send the file to someone. Work already creates temp files which autosave? Part of me likes the idea of saving being option... just making word autorestore without being prompted. However, that would obviously be a significant, and prohibitively confusing, change in workflow for users.
Once you save, you've lost the previous version, especially if the program dies and you lose undo history.
In software development specifically, there's quite few tools that automatically pickup/use files when they're saved... Meaning you'll try to compile or use invalid files.
tldr; don't do this. word already guards against losing changes anyway.
If one's going to get rid of the save button, then the program should sure as well give me feedback about when the last time it's saved. Often times, when I want to close something that autosaves, I'm not sure if now's a good time or not.
When it comes to version control, you do actually want to control when a version is saved, because there's meaning behind the different save points, conveyed to others that might want to fork and merge. Wading through a history of meaningless changes is no one's idea of fun, because the intention of the version isn't conveyed well only through the changeset.
While this article makes some good points about modern design borrowing far too much from the past, I fail to see how this is a pressing issue in software today as the author would like me to believe.
Auto-save for recovery purposes is one thing, but when completely replacing the 'Commit when I tell you' to 'Save everything in real time' can have unintended consequences.