A few weeks back I was working with the dev team at WGC on some interface design for our product prototype. We came across a point at which we have to give the user the ability to indicate their desire to save a current state. As we discussed the various ways in which we could visually indicate a 'save' action button, I realized that as a whole the industry has settled on the image of a 'floppy disc' such as this:
Now in this day and age the floppy disk is an anachronism - have any of the myspace generation even ever seen one? It is certainly a few years since the average family PC came with a floppy drive as standard equipment and an online life requires little in the way of tangible media.
- and yet the iconography persists.
The more I thought about this however, the more I came to think that if we needed to provide a user action which is exemplified by an outmoded concept, then maybe we should rethink our interface and indeed application architecture at a deeper level.
When developing interfacing for an online or network based application the notion of 'save' perhaps makes little sense; yes, there are practical reasons such as data storage capacity and data transfer but should we not be thinking of state as a temporal condition, a set of attributes and values at a given point in time? How many layers of 'undo' should we set? Or should we dispense with the 'floppy' disk notion of a hard state and invoke some more contempoary notion of state control such as a play, stop, rewind etc. Is state not just simply a specific point along a constant flow of input and output.
Too much application interfacing is based around the technical solution - this made some sense when computer users were computer scientists, but for a long time computers have been the tools of the every man. We invented the notion of 'computer literacy' so we could teach people how to interface with computer - isn't it about time we started teaching our computers or at least our applications about people? At what point do interfacing conventions which have allowed users to move from computer to computer or application to application with some relative comfort start to hinder the possibility of how computers could work for people?
Returning to the discussion of state saving: Some time back applications started introducing the notion of 'auto save', but even this is insufficient. Like the safety ropes in the sport of rock climbing this only prevents a plummet to certain doom by providing a maximum 'safe' fall distance. Should applications not be more like a staircase of better still, an elevator?
It could be that the humble floppy disk lives on in collective memory as the state saving icon for some time yet - there is a precedent, just look at the road sign we use in the UK to indicate the presence of speed detection cameras:
Does this look anything like the type of camera you'd expect to be capable of taking a high resolution image of a fast moving license plate?
Now in this day and age the floppy disk is an anachronism - have any of the myspace generation even ever seen one? It is certainly a few years since the average family PC came with a floppy drive as standard equipment and an online life requires little in the way of tangible media.
- and yet the iconography persists.
The more I thought about this however, the more I came to think that if we needed to provide a user action which is exemplified by an outmoded concept, then maybe we should rethink our interface and indeed application architecture at a deeper level.
When developing interfacing for an online or network based application the notion of 'save' perhaps makes little sense; yes, there are practical reasons such as data storage capacity and data transfer but should we not be thinking of state as a temporal condition, a set of attributes and values at a given point in time? How many layers of 'undo' should we set? Or should we dispense with the 'floppy' disk notion of a hard state and invoke some more contempoary notion of state control such as a play, stop, rewind etc. Is state not just simply a specific point along a constant flow of input and output.
Too much application interfacing is based around the technical solution - this made some sense when computer users were computer scientists, but for a long time computers have been the tools of the every man. We invented the notion of 'computer literacy' so we could teach people how to interface with computer - isn't it about time we started teaching our computers or at least our applications about people? At what point do interfacing conventions which have allowed users to move from computer to computer or application to application with some relative comfort start to hinder the possibility of how computers could work for people?
Returning to the discussion of state saving: Some time back applications started introducing the notion of 'auto save', but even this is insufficient. Like the safety ropes in the sport of rock climbing this only prevents a plummet to certain doom by providing a maximum 'safe' fall distance. Should applications not be more like a staircase of better still, an elevator?
It could be that the humble floppy disk lives on in collective memory as the state saving icon for some time yet - there is a precedent, just look at the road sign we use in the UK to indicate the presence of speed detection cameras:
Does this look anything like the type of camera you'd expect to be capable of taking a high resolution image of a fast moving license plate?
Comments
By talking about cameras in your post maybe you hit on one possibility? Rather than 'saving' something you could think about the moment in time along your constant flow and take a 'snapshot' of it. This might still give the user confidence that they are in control enough to store their information, while at the same time reflecting the ongoing nature of the data flow.
I agree whole heartedly about the 'reassurance' that they have actually made some kind of committed 'save'. I remember someone at Etech last year in an Ajax session talking about how they had added a 'false' save button because users weren't convinced their changes had been made, despite the fact that the system was built to automatically save all changes the moment they occurred.
I'm also put in mind of when many appliances in the mid 80's employed 'touch sensitive' buttons - again here the user was never quite as comfortable as when using a mechanical switch with an audible click or he feel of something actually 'connecting'.
My point is really thought exercise in how long an icon for history can or should be applied to a contextually decedent process - and my guess is that while ever it taps into communal habit, memory or mental model it will be safe, as long as it doesn't limit capability.
Also, I like the 'snapshot' idea very much and it certainly fits with the notions of visual interfacing.
Thanks for your comments.
I came across this blog while looking for a contemporary icon for a "save" button on a touchscreen - and I find myself and my opinion about outdated floppy discs fully supported!
Nonetheless, I'll stick to this icon due to the lack of an alternative as common as an old floppy...