Over at Branch.com, there’s a great discussion going on about Redesigning the Save Icon. A few interaction design experts are all weighing in on the topic. Some ideas are awesome, and some aren’t much better than what we have now. The reason for the discussion? My daughter is now two years old. She’ll never see a floppy disk in real life. Kids that were born in the late 90’s have probably never seen one either (or at least used one). Apple released an iMac in 1998 without a floppy disk. By 2007, only 2% of computers sold still contained a floppy drive.

Sure, even kids who’ve never seen a floppy disk know what the save icon is for. They understand that when you click it (or touch it… from now one, I’m just saying press it), your computer will save your work. But as we get further from the days when floppy disks were actually a thing, the association becomes weaker. That’s the issue with skeuomorphic icons, no matter what their purpose. Eventually those items are no longer relevant. That means boxes, folders, vices, zippers or file cabinets are not really viable alternatives to the floppy disk.

The other issue arises when it’s no longer your computer saving your work, or the entire save paradigm changes as we move more toward local AND cloud storage of all documents. Today, the idea of saving a static copy of a document is almost foreign. New versions of Word, Google Apps, and other productivity packages do a great job of offering a versioning environment much like git or other VCS. So the question is, does “save” still work when describing what that icon does? In my opinion, no, it doesn’t.

If Not a Floppy Disk, What?

My first instinct was to say we should move toward a more VCS-like vernacular: pushing or checking-in changes that get stored in a repository. That works for people who are in my field, where words like commit, branch, and pull are everyday ways to describe saving and opening files. The complexity that type of language introduces, however, is far too much for novice users who know Word, Internet Explorer, email, and nothing else.

My next inclination was to design a culture-agnostic icon that depicts (in a very ethereal manor) the concept of syncing the work on your screen with whatever storage mechanism you’re using.

This is a depiction of what a new save icon could look like. I like what they have at Branch.com, but I really don’t think they are clear enough. Here’s why I think this is an improvement:

1. This icon tells the user that there is work that is unsaved/unsynced. The full and empty circles are different, which tells the user the local and stored versions of the file are different.
2. When the user presses the save icon, the animation either shows the work “moving” to the storage medium of choice, or shows that storage filling up with the new work. The metaphor works here wether the data is moving from volatile to non-volatile storage, syncing with the cloud, or whatever other storage medium we move to in the future.
3. When the save is complete, the user’s work and the storage are connected, and both circles are filled, showing that the work is synced.
4. This also works in reverse, with the smaller circle empty and the larger circle full, telling the user that there is a newer version of the document available in storage. This would work wonderfully for collaborative work where more than one version of the document is being worked on at the same time.

I believe that this is a very clear and powerful indication of the save state of the users work.

The Perfect Save Icon is No Save Icon

In a perfect world, the idea of having to save your work would just go away. Devices are powerful enough now to save after every keystroke or change. There’s no reason to make a user consciously remember to save their work. Reminders at close go a long way to making sure the user doesn’t lose work, and modern software has crash recovery mechanisms, but none of them work well enough. Also, none of them offer a solution to working in a stateless environment like a browser. A system that auto-saves every change does. That’s why it’s the best option.

The animation above would still work for systems that auto-save. The unsaved version can be used to show that work is pending a save, with the actual save happening in a separate thread that shows the saving animation, followed by the “saved” version, giving users visible feedback that their work is safe. The button could then serve as a “save version” button, much like the Photoshop snapshot function, so that a user could return to that version of the document any time in the future.

Of course, we can’t just jump on whatever solution is agreed upon. There will be a great deal of user confusion as we move away from the present solution and onto something new. But users adapted to changes in the icon used for menu, settings, and archive. They can adapt to this too.

Update: I am not advocating replacing the save button because it’s ugly, or because the floppy disk no longer exists. I’m advocating a change from the idea of “saving” something. We need to move onto a model where our documents are being saved both locally and remotely, where documents can and are worked on by multiple people simultaneously, where the idea of only saving when the user wants to save is an outdated idea that needs to be abandoned. 

I’d love to know your thoughts about the save icon above, other ideas you have for a save icon, reasons you think the save icon should stay a floppy disk, etc. Use the comments and let me know what you think!