Paul McAleer

Saving Grace

Paul McAleer

I gave Google a gentle jab recently over its use of a floppy disk to denote saving a file in Google Docs. I do realize that the floppy, while no longer in use, still denotes the act of saving files for a lot of users. I began considering what the alternatives could be and it is certainly not an easy communication problem to solve.

Before we tackle that concept, though, we should first ask if most consumer software needs to provide a user-facing save facility at all.

Saving harkens back to Olde Tyme Computing where one needed to manually save a file lest a computer lock up, reboot randomly, or otherwise take one’s work with it. Since we’re getting well past that point in modern times, saving helps answer two questions: “Is your work at a good stopping point?” and “Where do you want to put this thing you’re working on?” As with many other mechanisms there are a lot of other questions and considerations which come into play (the file and folder construct, naming a file, opening and closing) but these are the two key drivers based on my experience.

The Stopping Point

Whether users are conscious of it or not, they’re creating mini-project plans in their heads when they’re creating documents. There’s a starting point, an ending point, and milestones along the way. These points might all be passed in one sitting or they might not but there’s usually some point at which a document is “done.” Saving gives users the opportunity to define their breakpoints (milestones) and endpoints. While software abstracts this project plan away, it’s possible to go even further.

Consider removing an explicit save command. What is left in its place? Likely something along the lines of a history viewer, showing all of the major and minor changes over time for a given document. Such an interface could be really geeky in a time display sort of way, highlighting “more important” and “less important” changes depending upon criteria appropriate for the program. (Add in three paragraphs to a five paragraph paper and that could be major; take out six words in a 6,000 word document and it could be minor.) Analytics and learning are sophisticated enough to help guide users into understanding what work they’ve done. Alternately, users could note major and minor changes to help the process along. All of this work would be optional; people might just want to compare last Tuesday’s work to today’s, for example.

The frequency of saving in this model would be handled by the OS and not the user. iOS encourages developers to save documents every 2 seconds. This seems reasonable.

An alternative to a timeline view, and one which may be a little less radical, is undo and redo which works all the way back to the point of document creation. This would work best for a document with a relatively small number of changes, but would fall down when that number became really large. There are also conceptual issues that would make Doc Brown nervous: if one works with a file and “undoes” work to the point of four weeks ago, and then makes changes, does the “redo” history go away? Or does it split into an alternate timeline? Meaty issues which suggest why today’s save action is usually destructive, but the ability to always have every revision of a file available is a remarkable one. The “deep undo” metaphor could be a way to implement it.

Where Does It Go?

I’m a proponent of removing the file/folder abstract in most computing environments so, to me, the question of “where” a document goes is outmoded. A document is “in” the app. There is no separation between the app and the document when it comes to work.

If a user wants to work with words, she uses the word processor. If she wants to mail a photo, she uses either the mail app or the photo app. Some tasks may overlap between apps, but they tend to be communication-driven (mailing, posting to Facebook, testing, etc.) and could be integrated into both apps.

One thing to keep in mind is that files and folders still exist, but they are essentially tools for programmers and not end users. It’s a bug that users weren’t given a feasible alternative to document storage until relatively recently. While this “app as document store” model is still emerging, it removes a deep burden.

If the concept of saving is removed, then the question of where a file “goes” is also removed. It lives in the app.

How We’ll Get There

These are large-scale changes, to be sure. The concept of saving files is ingrained in our computing culture, built on a history of unreliable OSes and media.

Apple is trying to just up and change it. Apps for the new Mac App Store need to save files automatically and silently - much like iOS. It makes sense for iOS, a relatively new OS, to run with this convention. It’s not out of the question for Mac OS, either, nor is it absurd to think that Chrome OS could pick it up. 

What about Windows? Given its seasoned users I think Microsoft should take a more gradual, less radical approach. The “deep undo” concept is an option, as is beginning to deemphasize the act of saving: keep it around but begin to give it less and less prominence in the UI, supplanted by some sort of history viewer.

Computing devices are starting to become very diverse but many of the latest and greatest devices do away with old conventions. If we truly want user experience to move forward, we should be giving users a hand every step of the way. The concept of saving files as it stands today is outmoded and awkward, so let’s make it reliable, easier, and better.