Time to kill “Save”?
We’ve been doing it for the last 30 years – clicking Save. Everyone is used to it – you work for a while, you press Save. You work some more, you press Save again. Things crash, you lose your work since your last Save. Or you can open the Auto-Save backup document, which is really just the computer doing a Save for you. It’s one of those things that we all take for granted, but is it time to kill “Save”? Or at least Explicit Save. By Explicit Save I mean that the user has to actually do something to say “save my work”. In an Implicit Save model, work is just remembered for you. You can find Implicit Save scattered through various operating systems. For example, System Preferences on the Mac.
Apple System Preferences use Implicit Save
When you make changes to this screen, you don’t have to click a Save button. They just happen. Implicit Save is actually pretty common on the small scale. Lots of popup windows don’t require an explicit Save step. But we don’t see it much beyond that.
I can hear you now thinking: but what if you make a mistake? In System Preferences that’s not a big deal, but what if you’re typing on your word processor and you accidentally delete whole sections of the document? Well, that’s why we have Undo, right? By now, our systems for Undo have become quite sophisticated – most applications let the user Undo – and Redo – multiple actions. (Ironically the “Undo” history for Microsoft Office products is erased when you Save.) Photoshop lets you see your Undo History and you can jump back through several levels of Undo just by clicking on an item in History list – and it will remember up to 1,000 Undo steps. That’s impressive. (Of course once you close your document, the History is lost.)
Photoshop's History
What if we had Implicit Save and infinite Undo/Redo? What if you could open a word processing document and along with the current state of the document you had Undo all the way back to its original, blank state?
Problem: that would take up a lot of disk space, wouldn’t it?
Disk space is cheap, so I don’t think that’s an issue, except for perhaps video editing. When you’re thinking about Powerpoint slides, spreadsheets and Word processing the amount of space needed to save a complete document history is really not a big deal.
Problem: What if someone really wants to make a copy of something?
I think that’s easy enough – you keep Save As, or perhaps call it Copy. It would let you make a duplicate of a thing (and its complete History) any time you want.
Problem: Navigating through Undo History is too hard. Who wants to keep clicking Control-Z over and over again to get back to something they did last Tuesday?
Ah now that’s an interesting design problem. I love interesting design problems. Let’s dig on this a little. Photoshop has its History list (as we saw above) but it can be really hard to figure out exactly where to jump to in a long history. It’s easy to remember the commands over the last few minutes of work. But if this list were days or weeks old, how could you ever make any sense of it? Obviously merely listing the Undo history only works for recent changes, or once you’ve oriented yourself in your work.
Apple's Time Machine
Apple’s Time Machine gives us a clue for another way to look at Undo. The Time Machine saves complete snapshots of documents (and Address Book entries, Photos, and more). The user can scroll over the timeline on the right and go back to a specific point in that document’s history and retrieve it. So what if you were working in your Word Processor and you had a timeline – and at any point you could “scrub” through the history of that document, go back to some earlier state and look at it – make a copy of it, copy text from it, or even revert to it.
Problem: What if you don’t want the history there?
We would have a way to erase the history – there are lots of good reasons (especially once you give a document to someone else) that you wouldn’t want to share the Undo History. Perhaps you’re sharing a document with a large audience at a conference, or a resignation letter to your boss. Plenty of good examples when you’d want to dump the Undo History.
Problem: People are used to saving
Well, yes, they are. More is the pity. Just because that’s how we’ve always done it doesn’t mean that’s always how it should be done.
Try this: work for a day and think about how it would be if all your work was being saved for you all the time. You’d never have to remember to press Save again. You’d never lose work again. You could go back to old ideas. You could open a document that you worked on last year, scrub through its history and see the whole thing being written – in essence, reproducing your own thought processes. How cool would that be?
I’m curious: I seem to remember that either the Xerox Star or the Apple Lisa that had implicit Save. Do you remember which one? Do you see other problems with Implicit Save that I haven’t mentioned? Do you think it’s time we started seeing Implicit Save and Infinite Undo in the digital things that we create? Are there applications out there that have Implicit Save & Infinite Undo – have you used them and do they work well?
| Category: Musings | 9 comments » |
January 30th, 2010 at 12:04 pm
Great thoughts. I think Jef Raskin was a big proponent of this idea in his book (The Humane Interface) and I’d check it out for more historical examples.
Another modern example that does this is Adobe’s Acrobat.com apps (e.g. Buzzword). They still have a save button there for those who want it for reassurance, but it’s not necessary to press it.
January 31st, 2010 at 2:04 pm
Google Docs saves your changes as you make them. (You can explicitly save too if you want.) It also has “Make a copy” instead of “Save as”. It reminds me of some of the ideas that Alan Cooper (et al) put forward for reforming the way files are handled in About Face 3.
And Google Wave has something very similar to the “scrubbing” that you suggest.
January 31st, 2010 at 3:37 pm
Yes, Google Docs does have implicit Save. But, they also have a Save button, so I spend most of my time being paranoid that I need to save and not being sure how often it does save. I really don’t like mixing both Implicit and Explicit Save in the same UI – I think it’s a hack.
While it’s nice to see someone making an effort in this direction (especially Google, which is very influential), I wouldn’t say that this is a big leap forward. I don’t really believe that implicit save is going to be very well received by users without a new and thorough look at Undo and History. The problem is that implicit save CAN save things you don’t want kept. So the Undo system has to be very good at helping you to get back to wherever you want to be – even if it was yesterday.
February 1st, 2010 at 12:51 am
Save is actually an important expression of the user’s intent. As such, there’s an important aspect which we should “save”.
Save indicates that this is a point in the evolution of a work that possesses a degree of consistency, or is otherwise of interest. Perhaps it’s merely the last edit of the day — indeed, that indication is entirely redundant, as that can be deduced by inspection.
But it can also be the edit that marks the completion of a subtask, or a a milestone. These are the save actions worth saving. (“Save As…” also plays a role, allowing one to assign a name to a particular milepost.)
So the “hey, I don’t want to lose my work” aspect of Save can be lost, and good riddance. By doing so, yet retaining the option, we make the explicit intentional saves more valuable.
In programming, these correspond to checkins of the source code. And certain checkins are elevated,through “tagging”, to indicate a special status — perhaps a release, or perhaps merely to mark the begin and end of a largish task.
Likewise, text documents have their own milestones — this is the version I sent to Joe Collaborator for review, this is the version that Bill Boss signed his approval, this is the version that has the changes requested by Larry the Legal Eagle, to reflect the contract terms for this client. And this one is the one that went out as the proposal.
But there’s another aspect you’re entirely missing. The history of a document is not always linear. Sometimes, they branch. Sometimes, we may start from that version BEFORE Larry’s modifications, and rework it for another client.
This problem is well-known in software development, but it is something that business people also do all the time. The one document becomes many, but they share a history. And sometimes, changes in one need to be brought over to a “sibling” version of the document.
Currently, when we do Save As, the document forgets its history, and forgets its identity — its roots, if you will.
That’s not now Wave works, and it’s not how it should work for any document, in my opinion. Except when you explicitly want to strip all that away, as when offering a document for external use — turning in the homework, or submitting the bid, or publishing the final documentation.
But imagine the literary depths to be mined, were a great author’s edit history to be available. Not only could you instantly debunk most literary critics (who have rather an excess of bunk, as a rule) — you would have an instant creative writing class.
February 1st, 2010 at 4:46 am
Absolutely! They have hidden Save away in a menu now (“Save and close”) and they also have an “Autosaved at ” thing. And experience has taught me that their autosave can be trusted (though I was paranoid too in the beginning).
And experimenting with it now, I see that it saves undos — you can close a document, reopen it and it remembers your undo history (though I have no idea how far back it goes).
This is a good first step, but unless this kind of functionality gets implemented in a similar way by all application makers, it could get confusing…
I think most people, most of the time _don’t_ use close-without-saving as a way of backing out of changes (though this is just my opinion). And once people realize that explicit save is no longer an option, they will adapt their behavior accordingly (e.g., use Undo instead).
One complication I can see is this: how does it work (and how _should_ it work) when multiple users collaborate on a document? Can I only see my own undo history? Or can others see it too? What happens when I type something that is then corrected by a collaborator? What happens when I click undo then?
Maybe we need to find a way to surface this information and to make it more transparent…
February 1st, 2010 at 3:09 pm
Oops — I just noticed the inconsistencies between Google Docs and Google spreadsheet. Docs has an explicit save button; spreadsheet doesn’t. (I was referring to spreadsheet’s interface earlier.)
February 1st, 2010 at 3:38 pm
Bob – I completely understand the argument you’re making, but my feeling is that this notion of the user identifying “milestones” is a red herring.
The vast majority of writers and documents will rely on a “how was it when I last left it” system that is currently supported by a final explicit Save and close of the document. I think we completely agree there.
In fact, in an implicit Save model the software would Save the “last left it” AND the software could also look through the document’s History to recover the document at multiple points – in effect, doing multiple Save As commands all day long.
If the writer stops working on Monday and doesn’t pick it up again until Wednesday, our historical view of the “timeline” for the document can reflect that, and since it was a natural stopping point it’s likely that that will be an interesting moment in the History of the document. But the writer doesn’t have to create that Milestone, or that interesting moment. The software observes it, based on the writer’s behavior.
But there are those moments when the writer really wants to say “You know, this is an interesting point in my work on this document.” For example, he’s written the first draft of a report and wants to send it around to collect some comments. He needs to keep “draft1″ in a particular state so that he can go back to it and see where it was when he sent it around.
In both the implicit and explicit world, the right thing to do is to do a Save As (well, in the implicit save world this would be more like “make a copy”). There’s no need to build in an entire SCCS (Source Code Control System) into a document – writers today already readily understand the notion of doing a “Save as”. The new saved as document can copy over the history, but it no longer changes (unless of course the writer starts editing IT). Instead, the writer continues his work on his original document.
BUT in the Implicit Save system, the software can now note points where the writer does a Save As as a part of the History of the document he continues to work on.
An example would be useful. So the writer can see, through the History, that he was writing a document “report.doc” on Tuesday. He did a Save As command and made a copy of his work in “report-draft.doc”.
The writer could use History to “go back to the point where I did a Save As” and look at “report.doc” at that moment – which would, in effect, reconstruct the document at that state… or he could open “report-draft.doc” in the file system, assuming that it’s still there.
This history also shows other interesting moments where the writer did NOT do an explicit Save As. For example, if he worked continuously on the document all morning and then took a 2 hour break, it could mark that gap in time. If he picked it up again in the evening and worked for another hour, it could mark the time for that work as well. Now, in addition to the explicit Save As moment, the software has found other places that the writer might want to “jump back to”. Other interesting moments might occur when large amounts of information are deleted from or added to the document. There are many possibilities, none of which require the writer to do anything at all.
I guess that crux is that I agree that there are many interesting milestones, but I don’t think that we need to ask the user to explicitly identify them at all. We can spot the milestones for him, and he can use “Save As” to naturally create them.
In fact, in my experience as a writer I often fail to identify interesting milestones that have passed. I will find that I wish I had kept a copy of a document as it was a few days earlier when I shared it with a few people. Fortunately, I can use Time Machine to recover that information now, but I’d much rather have that built into the document.
As for collaboration, I haven’t forgotten about it at all… But I don’t see how any of this breaks down when you add another six authors, or even if you need to merge work from multiple sources.
February 2nd, 2010 at 1:48 am
Interestingly, the new iPad interface guidelines address this issue as follows:
“Ask People to Save Only When Necessary
People should have confidence that their work is always preserved unless they explicitly cancel or delete it. If your application helps people create and edit documents, make sure they do not have to take an explicit save action.”
And also:
“Downplay File-Handling Operations
Although iPad applications can allow people to create and manipulate files and share them with a computer (when the device is docked), this does not mean that people should have a sense of the file system on iPad.”
February 2nd, 2010 at 11:09 am
Thanks, Martin. I’ve been hoping that implicit save would make its way into the mainstream for many years, and I thought that the iPad was a promising place for it to debut. When I saw that the iPad is avoiding using the file system entirely, I was hopeful but your quote from the Human Interface Guidelines definitely cheers me even more. Unfortunately, it doesn’t look like they’ve tackled any kind of comprehensive history (yet) in the iWork applications (at least from what little I’ve been able to see). We’ll know more in approximately 60 days.