Martin Colebourne

The need to ‘save’ work in order to preserve it is one of the basic things that can make working with a computer seem complex and confusing to those who are not familiar with them. Even experienced users sometimes get caught out – closing something without saving, or saving when they meant to ‘save as’.

In recent years, some applications have stated to experiment with alternatives to the traditional Microsoft office-style ‘Document’ model; and this change has been significantly accelerated by experiments with online services. 

I wanted to try to find a basic framework for thinking about the different approaches that are available. This post is a first attempt. It is certainly not the full story, but should serve as a useful starting point that can be expanded later.

I have broken down the different approaches into two parts: the nature of the relationship between the ‘live copy’ and the ‘disk copy’; and the question of how save events are handled.

‘Live’ and ‘Disk’ Copies

The primary reason that working with content on computers seems so different to working in the real world is the lack of direct physical creation, and therefore the lack of any automatic preservation of your content as you create it. When you write on a piece of paper, that content will remain available until you explicitly throw it away.

On a computer, as you edit content, you are working with a copy stored in RAM, which only persists whilst the computer is running. If you did nothing else, this content would be lost when you closed the application (or at least when you closed down the computer). Storing something means creating a copy of it on disk (or some other form of storage that will persist from session-to-session). This requirement is totally unlike anything in the real world and can therefore be a source of user errors.

The relationship between the ‘Live’ copy of the content in RAM and the ‘Saved’ copy on Disk varies in different saving models. Choosing the right approach can help to make a system easier to understand and less error-prone.

Save in Arrears

The first approach is the classic ‘Document’ model used by Microsoft Office and thousands of imitators and can be characterised as ‘Save in arrears’ model. The user can create a new piece of content (the document) and work with it in a Live state for as long as they wish without committing it to Disk. Typically, when the user attempts to close the application, it will then give a prompt asking the user if they wish to save the document, and at this point the Disk copy is created – hence the name ‘Save in Arrears’, since the Disk copy can be created long after the content itself is created.

The user can usually opt to create a Disk copy earlier by explicitly saving the document, but the software makes no attempt to suggest this, and content is usually lost if the application crashes prematurely.

When the user wants to go back and edit a document, they ‘Open’ the Disk copy, which creates a Live copy in RAM. Again, a prompt will remind the user to save changes back to disk when they attempt to close the document.

Save up Front

Another approach is to create the Disk copy as soon as the content itself is created. This then provides a target for preserving the content as you author it. In some cases, the user is forced to name the new document before they can begin working with it, which usually seems a little onerous and creates something of a barrier. A better approach is to create the Disk copy transparently, using a default name, and make the process of renaming it later seamless.

On its own, creating the Disk copy at the beginning wouldn’t offer many benefits, but it is usually linked with other changes in approach – such as autosaving, which is discussed later. Together, these can have the effect of significantly reducing the visibility of the Live copy vs. Disk copy distinction, making the systems easier to use.

Pre-created

In some cases, the Disk copy exists before the user begins interacting with it. This may seem counter-intuitive, but only because it doesn’t apply to most cases that we think of as content creation.

The typical example would be preference settings: as soon as you start using a computer, or a piece of software, settings exist governing its operation. The user can often modify these settings (changing their content), but they don’t have to create them first – they are already there, waiting to be edited.

In this case, the user simply accesses the settings, modifies them and then commits those changes back to Disk. In many cases, this is not represented as a ‘Save’ operation at all, but covered by OK/Cancel, or Submit/Cancel buttons.

Save and Autosave

Save

The basic approach is the classic save on demand – the user controls when changes are saved, by explicitly selecting a ‘Save’ command, or responding to a prompt when closing a document. The gaps between save events open up the possibility of data loss through crashes, whilst the last-ditch nature of the prompt on close opens up the possibility for user error (e.g. by accidentally selecting ‘No’).

Autosave

Autosave seems like the perfect solution to the problem – by constantly saving changes back to the Disk copy, the user is protected from significant data loss. However, applying autosave usually means switching to a ‘Save up front’ model, which may not always be appropriate.

More significantly, autosave is always an approximation – it isn’t possible (or at least isn’t efficient) to actually save every change back to disk, so in reality there is usually a compromise to save periodically based on fixed time intervals, or based on some more complex algorithm that takes into account the amount of change in the document. The gap between content creation and it commitment to disk still leaves the user at the mercy of some data loss in the event of crashes or unexpected terminations (like closing a browser window).

Micro-committment

I call the final approach ‘Micro-commitment’ because it works on the basis of the interface dividing up the user’s editing into discrete chunks that can be saved as the user completes each one. This doesn’t usually apply well to freeform document authoring, but can be useful in things like editing preferences, or editing online forms.

Processes involving dialogs are a great example – where a process involves the user completing a wizard, or filling in a form which uses multiple pop-up dialogs, the state can be saved at the end of each step, or when the user selects ‘OK’ in each dialog.

Conclusion

Combining together the choices for when to create the disk copy and how to save changes creates a number of possible permutations, some of which are more valuable than others. Hopefully, this analysis can provide some insights into the different approaches that are available and some of the benefits and weaknesses of each. I’ll write about some of the other characteristics on which Saving models can vary in later posts.