The Save Button – A Thing of the Past?

This afternoon I caught a tweet from @afovea which said “Why is a floppy disc icon still indicative of ‘save’ … when was the last time you used a floppy disc?”. He has a very good point, we are stuck with quite a few analogies which have since become a…

This afternoon I caught a tweet from @afovea which said “Why is a floppy disc icon still indicative of ‘save’ … when was the last time you used a floppy disc?”. He has a very good point, we are stuck with quite a few analogies which have since become anachronisms; no longer part of how we physically use hardware or software; even “files” and “folders” are struggling to migrate the generations, splinted by Spotlight and Windows Search. Why is it so hard to think up an alternative? I think one reason is that “saving” itself is an outdated concept that might need re-thinking as we become fully connected, all the time.

One way of thinking of a “save” is the operation you perform when you want to package up a discrete version of something; to snapshot something in time so that it can later be retrieved. In some cases saving is not required, any email/webmail app for example, the save option here is “save as” which outputs what you are looking at into an archived format. This is generally used where forwarding will not suffice and search is lacking (with the exception of Gmail this includes most email clients).

I started to look at the software I regularly use and realised about a half has a “save” button/menu option, I included things like Facebook and Twitter (web) as well as Charles, OpenOffice and Flex Builder (desktop). Almost all software used to have a save button; you’d be editing a document or playing a game and you’d save your document or progress to disk, to hard drive, maybe even to USB. Along with save we had export, another way to get a document or file out of an application in another format. Then came save for web, a more specific version of export which saved a document in a web-friendly format for others to see.


Then something changed. RIAs got serious, and after the shopping carts came fully featured document editors like Buzzword, Google Docs, Photoshop Express. Of course most interaction on the web was —and you could argue still is— not document based, it was/is purely passive. When RIAs brought editing to the browser, they also brought with it the heart of the web, collaboration. Editing and collaboration infects all passive media given time.

In order to allow collaboration, the best of these RIAs adopted a source-control-like document “history”. No discrete files ever exist in reality, just markers for “this is how your document looked two weeks ago, or before Bob edited it 3 seconds ago”. This new arrangement allowed real time collaboration, supported a less committed approach to editing documents, and with everything being on-line, allowed new live elements and interaction between documents previously impossible in desktop software (see the Aviary suite of tools).

So we’re now at a stage where we still have a “save” button in the aforementioned apps, but what is this really for? Is it a legacy mindset support? Is it to satisfy the user that they’ve just labelled a version of a document as “done for now”. Is it because internet connection is still not 100% rock-solid and high-speed so that we can guarantee you are always “synced”; that simply closing or crashing the browser/AIR App/Silverlight OoB App doesn’t result in you losing your recent changes?

But what about… ?

In thinking about this I realised there were still good, legitimate reasons for having the concept of saving, right now. One argument for saving is that it allows someone to edit a document/entity and then abort, losing the changes. This is true on the whole, but an automatic history handles this. Another is the “save as” feature, allowing a copy of a document, a draft, a different version. I concede to this, but I think an updated paradigm for creating document-based apps could circumvent this.

Funnily enough, the AIR application I’m currently working on is document based, but we’ve found there’s no need for a save button. It happens automatically as you edit/navigate the app. Of course I had to build in undo/redo before this was reasonable.

The end of save?

I see the save button going away in most consumer applications as they migrate to more portable, inherently connected RIAs. Perhaps it’ll stick around longer for the pro-apps, the really heavy hitters, but even those in time will go. So what do you think? Is save going away, is it here to stay? How many apps do you use that actually require a save operation? What are you saving? Whatever the answer, for now at least I have to hit “save” so that you can read this post.

2 thoughts on “The Save Button – A Thing of the Past?”

  1. Saving will never “die”, but it looks like it is going into two different directions. On the one hand you have traditional saving combined with automatic syncing like on etc.
    And on the other hand you have new paradigms that make saving irrelevant and even burdensome. Look at Google Wave for an example.

Comments are closed.