Skip to main content

To Save or Not To Save....

6 replies [Last post]
agherring
Offline
Joined: 2003-06-12

There is a school of thought that the "Save" action found in just about every GUI nowadays is no longer needed. The argument is that the need for a Save action to persist user data was driven by the need to pause the application and wait for the persistence to take place. Once upon a time, that time could be measured in seconds (minutes?) - however in modern systems, most user data can be persisted in less than a second (especially if only saving deltas). Hence, the saving of user data can happen automatically in the background whenever data changes.

This argument is that we could actually get rid of presenting users with a Save action. Instead, any time data changes, it is automatically saved in the background. Of course, an undo log would need to be kept to allow users to roll back unintended actions. The advantage is that user data is always kept persisted without them having to manually intervene to hit save, or be prompted to save data when they quit the application.

As a software developer, I can see the elegance of such an implementation. However, I do have some usability concerns. For better or for worse, the "Save" button is part of everyday life in most computer applications. Would getting rid of it by moving to a different User Interface patten be confusing or counter-intuitive to an end user?

Any thoughts?

Ash.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
zander
Offline
Joined: 2003-06-13

The KDE Usability team has discussed such a way of working for some time since it is a certain usability gain! I still like the idea except for the fact that the 'undo' you agree should be always present is not really that always present.

The last I seen of this idea was that everyone agreed that in order to remove the save button altogether we need to have a RevisionManagement aware 'filesystem'. This is easier then it sounds like; just put a revision management layer between the app and the actual filesystem.

When that has happened and undo can be done based on change-date (i.e. a month ago, or at the same time I created document Y) then I feel the road is cleared for the removal of the save button.

I do, however, share your fear that people will start to look for a save button since they expect it. This new way of working stands the most change for new applications that people have not worked with before. So don't expect it to appear in your word processor just yet.

agherring
Offline
Joined: 2003-06-12

Undoable filesystem changes ... that's a whole other can of worms there! As our Uni Sys Admin guy used to say: "rm is forever."

I guess I'm really only talking about *user* data - ie prefered layouts, options, document content, drawings - that sort of thing.

The reason I think some sort of undo log is essential is that mistakes happen - a paragraph is deleted that wasn't required. Although most programs have in-memory undo capabilities, traditionally most of us have used the fact that the last 10 minutes work is unchanged as a way of "undoing" an unwanted action by reverting to the last saved version again. If you go and introduce smart auto-save in the background, you also need to give users a way to protect against unwanted changes, as they may have previously been depending on reverting from the in-memory version of work-data to the on-disk version.

zander
Offline
Joined: 2003-06-13

> Undoable filesystem changes ... that's a whole other
> can of worms there! As our Uni Sys Admin guy used to
> say: "rm is forever."

Thats not what I meant; if you save to a file, you use 'file://' or similar; now what if you save to 'cvs://' instead?
This means that indeed files will be used on a filesystem somewhere, but, as with CVS and friends, somewhere else the changes will also be stored.
In that case an RM will be undoable just like you can get a file back from a cvs checkout by asking the central repository for it again.

> If you go
> and introduce smart auto-save in the background, you
> also need to give users a way to protect against
> unwanted changes, as they may have previously been
> depending on reverting from the in-memory version of
> work-data to the on-disk version.

Usability research actually shows that a very low percentage of users thinks like that; for some reason this kind of 'big undo' is too hard to work with for them.

This is good since it takes away the problem you see, since the people that actually use this concept already are going to learn a new way pretty easy.

vdkuil
Offline
Joined: 2006-02-17

It looks to me like you are talking about "auto save", an action that most applications these days have. This way people can have a choice. In some cases people need to work with floppies (I know very scary) and autosaving on that (or network locations) can take more time than people want to.

I'ts funny though, I thought this auto-save was introduced because some applications on a certain OS tend to crash often and people did not want to loose data when it does... ;)

agherring
Offline
Joined: 2003-06-12

Well autosave is just part of it. The real crux of what I was getting at is actually getting *rid* of the save option all together - just have it happen automatically in the background, no prompts, no unsaved work etc.

Save to floppy is a good point - hadn't thought of that, probably because I can't remember the last time I actually used a floppy disk! Mind you, saving does not have to be a synchronous action, background saves can be a asynchronous process - so what if it takes 3-4 seconds to save?

I guess one key difference between the type of auto-save in things like Office and the type I'm thinking of is that it would be a bit smarted than "save every 5 minutes" - more like kick off a background save to persist the changes everytime a change is made. Ensure that the persisted data is only ever at worse few seconds out of date with the in-memory workspace data. This sort of auto-save has the advantage in it removes the burden of persistance management - through either manual save or setting up of auto-save - from the end user altogether.

zander
Offline
Joined: 2003-06-13

> I guess one key difference between the type of
> auto-save in things like Office and the type I'm
> thinking of is that it would be a bit smarted than
> "save every 5 minutes" - more like kick off a
> background save to persist the changes everytime a
> change is made.

This is harder then it sounds; consider that you want to save a data structure from a word processor. This is bound to give problems when you are still typing in it.
Your whole datastructuring should be done slightly differnt if you want to allow a-sync saving.

I talk a lot woth the KWord people (I used to maintain it) and in the next version a different way of storing the text the markup will be made to actually facilitate this way of working. The basis is that you actually only store changes in your data structure as well; with an occasional cleanup run...