Save Should Die
I quite like Reg Braithwaite’s recent post Show, Don’t Tell. It’s a worthwhile read on that phenomenon we’ve all experienced in which we spend breaths and breaths trying to tell someone something to no avail, only to show them out of frustration and be met with a “oh, yeah, I get it”.
More interesting to me though is the comments on that post regarding the venerable “Save” command.
I am of the opinion that “Save” as a concept, as a modality, is deeply anachronistic and whose demise is being heralded, appropriately enough, by the web. As I type this WordPress is dutifully saving my words across the internet, from Vancouver into a database in Toronto, every couple of minutes. It works so well I often forget it’s working at all. And it’s doing so because there’s no file-based save available to WordPress. Yet the vast majority of desktop apps can’t accomplish this amazingly useful feature at all, despite having measurably more capability than my lowly web browser does.
The closest any desktop app that I use comes is TextMate, which has a preference to allow it to save all unsaved documents when I switch context away from TextMate (from editing code to viewing in a browser, for instance). That’s an amazingly handy feature - don’t use TextMate without it - but alas it’s only about 70% of the way to realizing its full potential.
Reg, in the comments on his post, hints that version control of today should be the save of tomorrow*. I love that idea. I hope he expands on that - I smell a rant…. Let’s get rid of “naming” documents and simply tag them instead. Get rid of the “Save” icon and simply store the deltas of all documents that changed on my machine since n seconds ago - and certainly don’t bother me with the details of it!
Apple’s TimeMachine comes pretty close to accomplishing this but its granularity isn’t quite fine enough. However, imagine TM with a per-file view in which, instead of viewing the history of an entire directory, you just browsed the content history of a single file? Right there, in the Finder. Historical timeline scrubbing of a document’s contents from within the document itself perhaps?
In this day, in the land of terabyte drives, let’s just save it all and never again gasp in fear and wonder “did I save?”
* I realize some people, most notably in the Linux world, have been doing this to varying degrees of limited success for years but using CVS or Svn (home dir in git anyone?) seem like a square peg/round hole solution - again, maybe 70% of what it should be.
Mark responded on 12 May 2008 at 7:59 pm #
This paridigm is used in the AlphaSmart writing devices by Rennaissance Learning. These are basically keyboards with a few megs of flash and monochrome calculator-like LCD. Whatever you type is saved; it’s just like writing, no saving, no opening a file.
Andy responded on 12 May 2008 at 11:18 pm #
>However, imagine TM with a per-file view in which, instead of viewing the history of an entire directory, you just browsed the content history of a single file? Right there, in the Finder. Historical timeline scrubbing of a document’s contents from within the document itself perhaps?
Revision control per-file is sooooo old-style revision control. Who uses CVS anymore?
Kilian responded on 13 May 2008 at 4:52 am #
Well, this is for me the typical thinking of people who do mainly developement of more or less text. You have a point as long as you stay in your paradigm, but once you start generalising “what good is for me, must be valid for everyone” you get it totally wrong. This might work for programmers or any other more or less text based editing (see your WordPress analogy).
Also your argument for saving everything because we have terabyte drives is only valid if you talk about your mostly text based files, because they don’t take much space. Try do work with uncompressed HD video and terabytes are peanuts.
As a designer I very often open a huge Photoshop document, just to make some changes, just for export, of which I don’t need or want to keep the original files with the changes. In that case I open the document, make the changes, export it to the final format and don’t save the PSD file. I’d be getting nuts if the system would automatically save that data, because I’d have to dig into TimeMachine and get the previous version back again. It would also be an enormous waste of space, because Photoshop files can grow huge.
Even worse with audio editing (as long as you do it non-destructive, you’re just shoving markers around, so no damage done) sometimes you need to edit an audio file directly (destructively), then I only want to save when I really am sure that’s the change I want, because some audio editors cannot use the undo command beyond the last save. And here, too it often happens that I just want to do a quick edit and export the result maybe directly as MP3, I don’t want to keep the original with those changes. Auto saving would always result in more work and wasted disk space.
Collin VanDyck responded on 13 May 2008 at 5:03 am #
It’s a funny thing to think about, certainly. There is a part of me that resists the idea of no save buttons anywhere. When I try to examine the cause of the resistance, I can’t find any good reason and I have to assume it’s just a side effect of having grown up in an era where there were clear divisions between volatile and persisted data.
chris responded on 13 May 2008 at 7:48 am #
@Killian: Large file formats are indeed a, if I may, “trickier” case than text files but not very much. Your thinking is - to borrow your phrase - typical thinking of people who don’t understand how modern version control and file systems work. But no worries: just as TM allows one to exclude directories from backup we could create an option for you to exclude files by type, application, directory, size… whatever floats your boat mate. This is fantasy software - you can have any feature you want!
chris responded on 13 May 2008 at 9:05 am #
@Andy: I’m open to new-school thoughts - share ‘em. (What can I say? I’m still stuck in Svn).