Why don't we auto-save for users instead of having them save manually?

Question

With the advent of Apple moving to auto-saving in its newest release Lion, should everyone start adopting the convention of auto-saving?

At first it is definitely awkward and the user can feel like they have less control, but if widely adopted this could make everyone's lives easier. Of course we should still offer a "Save as" or "Create a copy" type option to allow them to manually save a copy.

Are there any large technical/performance hurdles regarding auto-saving and if not, should we all start adopting the auto-save technique?

If we (Windows and other platforms) do not adopt this new convention, it will certainly create an even larger gap between Windows and Mac users. People who have only used Macs or grow up using them from here on out will not be used to saving. People who use Windows will be driven crazy by Macs (some not all) because they will constantly want to save.

Inspiration taken from an answer on Save icon, is the floppy disk icon dead?

Answer 1

In Marketo, the app auto-saves everything. We have very few "Save" actions.

However, interesting side-effect. In the email editor, some users were so panicked that there was no "Save and close" button, that we added one. It's already saved so the button only closes the window, but it made the complaints go away. We have generous feedback saying the information was saved, but it didn't matter enough.

It's an issue of trust really. Did the system hear me? Am I sure that I am sure?

Generally, our sales department considers it a major advantage in closing deals.

Answer 2

Although the technical objections are largely obsolete, I think there is still a UX-based objection to auto-save. Other answers have alluded to the relationship between versioning and auto-save. @sova talks about them as alternatives, but I believe they are essential complements. Without versioning (or at least persistent, traditional undo), auto-save has an important potential downside.

In a document-based interaction model, all changes to a document are temporary until the document is saved. The ability to close without saving provides a course-grained undo capability, since the user can always revert to the last saved version. This form of undo has very poor usability compared to even CTRL-Z/-Y style undo/redo, but it still gives users a "panic button" safety net. Auto-save takes this option away from users. Without a compelling replacement, this arguably may be a net loss of data safety.

Google Docs and the new OS X Lion versioning feature provide an alternative, more powerful form of undo/redo based on a timeline, rather than the traditional command history stack. Both systems anchor versions to the timeline and allow the user to pull older state ahead into the present in whole or in part. This is vastly better than the single-version revert provided by a manual save document model. This removes the potential downside of auto-save.

In combination, auto-save and timeline-based version history provide a great UX. Auto-save without versioning is a mixed blessing.

Addendum

@andrew-neely reminds me of another important case. Many business transactions have a significant transition between data entry and execution. The document model is inappropriate in those situations, and another metaphor must be used. However, it is still possible to protect against data loss.

For example, a system might be engineered to restore the state of the UI upon relaunch after a crash or power failure. The user can then choose to cancel or proceed with the transaction without repeating the data entry. Storing the state of the UI is a form of auto-save, but this would be transparent to the user.

A timeline-based history mechanism is also somewhat less appropriate for active editing interactions in this situation. The more traditional undo/redo may be better suited to a UX with short, transactional interactions. The short duration means that managing a command stack will be less of a burden, and the transactional nature means that reverting back past a transition point may not be possible in any case.

Versioning in a transactional system would still be possible, but it would take on a different character. Instead of displaying the full state of the transaction at each point during editing, it might focus on only persistent changes and present them as a sequence of state transitions in an audit log. A transaction is not so much an artifact in itself as a symbol of an ongoing process. A log of transitions better reflects this active workflow nature.

Answer 3

It's partly historical - when saving meant sending data back to the server it was an expensive operation, and when it meant overwriting what you already had without the chance to roll back it needed to be under the user's control.

However, now with either data saved locally or with high bandwidth connections there isn't the overhead in saving. Version control gives you roll back functionality.

Google already have auto saving in Google Docs, and now with Apple moving that way there will be a general trend to having autosaving everywhere. If it's in enough places then people will start to demand it.

I suspect that Microsoft will bring it in with the next version of Office - after all OneNote already auto saves, and Word etc. do auto save already, but only to a temporary file. Having it save to the actual document is the next logical step.

One area where it might take longer is database applications where records have to be complete to be valid. Partial saves are possible, but it's not as straightforward as something like a word processor or even spreadsheet application.

It takes time for things like this to work their way through to every application.

Answer 4

I have two problems with auto-saving.

First, inadvertent editing (mistakes): If a user brings up a document for viewing and makes a mistake, the auto-save would overwrite the good copy with the invalid data, and require the user to take additional actions to undo the mistake.

We have a data entry system that was designed with auto-save, and I can't tell you how many times records are damaged because somebody's input focus was in the wrong window, and they over-typed the information. It's true versioning and rollback can mitigate this issue some, but it complicates the system, increases storage requirements, and adds additional features the user must learn to use.

Second, Lack of Control: I like the idea of having the user commit writes on purpose. I'm all for Auto-saving to a temp file and prompting the user when they are about to abandon the changes, but I want the user to say "Yea, I meant to do that."

Auto-saving presumes you wish to save in the first place. There are times when a data is entered into a program without the intent to retain it.

Example 1 I sometimes bring up a word processor to check the spelling of a word, or look up a synonym for an editor that lacks such features. I don't want to retain that information.

Example 2 I often use notepad to store temporary information I don't wish to retain for longer than a few moments. Auto-save would force me to clean up a mess of these files for no good reason.

Example 3 If I document an issue with one of my subordinates, I prefer to type it as my handwriting is not very neat. If I use a word processor, our HR section only wants paper, and doesn't want me to save the document anywhere. If I save the document, then the whole computer (or network) is open for discovery in case of a grievance.

Example 4 Often, when copying formatted data from one source to another, I will copy the data to notepad to strip all formatting, the copy it again to paste into the target document. I don't want that information to be saved.

Answer 5

Alan Cooper and friends have a lot to say about always saving, always allowing undo when applicable/possible. If you haven't read it already, you should definitely check out About Face.

The first thing to say when considering the best user interaction scenario is that software should always auto-save. Even here on SE my draft is auto saving as I type.

Second thing to note is the modeless feedback given. The user needs to be able to see that whatever she is working on has indeed saved. Google documents does this better than any interface I have ever seen.

Third is the "Save now" feature. If I need to go do something I don't want to have to wait until the document blinks a "I just saved" at me, I want to know that it was saved before I continue. Regardless of weather the software will definitely save if I navigate away to something else or upon it being closed, I want that "I know this is saved" feeling.

Fourth, beyond Save A Copy there should be rename functionality. If you have a word document open and want to name it something else, you have to close the document, go to the file and rename it there. That functionality should be provided where I can get at it easily.

And finally, you should always preserve the undo stack across sessions so that I can undo forever even if I close the program/browser and then open it back up in three months and realize something I didn't want was saved.

I think users are becoming more comfortable with the auto-save and I definitely have been personally relieved when a program crashes and I know I haven't lost anything because all of the saving has been taken care of for me. So to summarize, read the About Face section on this and check out Google Docs.

Answer 6

Every one talks about it from a document point of view. Your question states "should everyone start adopting the convention of auto-saving?" I have to agree with others that if you don't offer versioning, it's useless. To me, being a photographer, autosave alone would be the worst feature to have ever existed. We sometime spend hours "destroying" a picture in Photoshop to find out that we made to much, scrap everything and start again.

That much holds for any creative field I can think of. When you create, you often experiment, and you have to have the option to go back to the original quickly if you realize you don't like what you've done.

And that much is true of a text editor also. A writer who deletes a whole paragraph to rewrite it must have the option to go back to it if he liked the old version better.

So if you want to put a standard on autosave, you have to put one on versioning also, or it will create more problems than it will solve.

Answer 7

I don't think this has been mentioned by anybody, but one instance when you must NOT implement the Auto-Save functionality is when you're working with files opened from a USB memory stick. Although not widely known, but USB drives have a very limited amount of read-write cycles, sometimes as low as 3000-5000 (see Wikipedia: USB flash drive)). If your application saves often, say every second, it would essentially destroy the user's device within an hour or so.

Answer 8

I've built a lot of webapps and when this issue comes up I face one or more of the following issues:

1. It takes more time to build. Sometimes you need to build a "Draft" model in addition to the normal model.

2. It can be hard to make autosave discoverable; it's not super helpful to autosave for a user and have them just wonder how to save their changes.

3. When do the changes go where in the application? For example, consider a versioned Address Book, where past versions of an Address entry are kept to see changes over time. How small a change should be auto-saved and treated as one of these changes? Should many slices be taken over time and aggregated into one larger change?

4. What about other systems that make use of this data in parallel - when should they pick up these changes? For example if there's a system that uses this Address Book to notify users of system events - when should they pick up the user's changes - what if the user has a typo or pauses in the middle of typing an email address - should systems that use this address get this partial entry and fail to send as a result?

5. Depending on the way the application is used it can be harmful to the user, or very difficult to build in a way that isn't harmful. For example if your application edits documents of arbitrary length, and a user is editing a 100-page document over a cellphone stuck on 2G, the most obvious way to implement auto-save is going to hammer their connection. There are differencing approaches that are much more complex, but those might hammer their feeble CPU.

Auto-save is definitely a nice to have feature, but it can be a difficult design decision often-times, and sometimes a difficult systems problem.

Answer 9

Version control is definitely the key as long as the presentation of the versions (timestamped) is clear to the end user. So the question is, how useful would it be to record every micro change as a document history? Well, that depends on whether the you are looking at changes within a session or outside of a session. So the presentation of history should take this into account.

Interestingly we have been doing this for years, but it has been cloaked as a different experience. That is, undo vs save.

When looking within a session, the user will most likely want to go back versions at a micro level - that is every detailed change. This exactly the same as using undo with undo history. The difference here is that with autosave, the session is the complete period the document has been open. With undo, the session is defined as the period since the last save. As long as a user can see what changes they have made within the session they should be able to undo the changes to the point in time they desire.

When looking outside the session, the user will most likely think in terms of periods in time and go back to a time when they were editing the document and not necessarily to a specific detailed change point. This is definitely viewing things at a more macro level and should be presented as such. It is interesting to note that with the concept of autosave, we will now be able to provide 'new' functionality that allows the user to drill down to a specific change within previous session if they so wish.

And with respect to applicability to database vs document: These are different - there is a concept of 'publish' timeline which needs to be looked into. When you consider the update of content within a database record, you must be able to autosave these. However, records are shared resources, and you need the concept of publish as well. Publish also allows others to read and edit these records as well. A good example is a CMS where someone may have to create a new article but not allow the changes to be viewable immediately. Say when they go to lunch or meeting halfway through editing. These changes should not be viewed by anyone until the user has 'published' (or committed) these to the system ready for viewing by others.

Answer 10

Mac only has a 15% market share in USA. Of those 15%, only a small portion has OS X Lion, which is where auto-save was introduced. So there are a very few people that will be comfortable with auto-save. Regardless of whether auto-save is a good feature or not, it is not a popular feature. Most non-Lion users will find it strange. The ubiquity of a feature is all that matters in UI design. Things that may have good intent, but are out of the blue, may confuse users.

I, for one, have been using Windows my whole life. I've used Mac occasionally, and I've been uncomfortable with Mac auto-saving in other cases. You know how when you configure preferences on any program, there's no save button on Mac? I always find my self wondering whether my changes will be erased when I close that preference window. On Microsoft Windows, however, preference windows usually have an apply and save button. This makes it dead clear whether my changes will be saved or wiped out when I hit X or cancel.

Again, I'm not arguing about the virtue of auto-save. I'm just pointing out that it's avant-garde and may not be ready for mainstream user interfaces. Aza Raskin, the lead UI designer of Firefox, said that the only reason people find the iPhone intuitive is because Apple has spent millions on advertising. Nearly everyone has seen commercials of people using the iPhone. Now, I don't see Apple doing the same marketing push for Lion's auto-save. They've only posted video tutorials on their website, which only a small number of people have seen. Unless Apple does more marketing, and more companies rip off Lion like how nearly every cell phone company ripped off iPhone, I don't see this auto-save feature catching on.

Answer 11

Why isn't a hybrid system more common? i.e. Main doc is only saved on user saves but a parallel tree is maintained for unsaved edits. Even after program close if user forgets to save (or say program crashes etc.) the parallel tree always affords a chance to go back and recover.

With storage so cheap, the cost of saving edits (especially incrementally) is incredibly cheap. I especially hate Software that forgoes the Undo option after any Saves.

An example of a Program that does this right is Vim (the editor).

PS. An argument against autosaving is on OS's that allow multiple apps / users to open the same file simultanously. Some users may just be viewing, and the edits may be accidental.

Answer 12

In my opinion, version control is a wonderful thing. It would be great to have a more end-user-accessible version-tree for the files you've saved.

You know how Undo/Redo buttons only go one step forward and back? If you hit Undo, then change something, you can't get back to the original "Redo" -- it's a big flaw, and if you travel half-way down the transaction chain and change something, you effectively lose half your edits!

Auto-save is a great philosophy, but the better alternative, imo, is real-time saving + great version control.

Should developers start incorporating auto-save into everything they do until stable OS-based version control (hard disk time travel) is the norm? Absolutely.

Answer 13

In short "Consistency and standards" / convention is a powerful heuristic. And data loss is a powerful motivator.

The "manual save" was not the only UX choice. The Psion 5 was an interesting physical device, but the UX of it's software was possibly more notable as it chose to take an independent path to prevalent UI's of the time.

One of the Psion's conventions was an auto-save, with a "revert to last [version opened / explicit save]" in the case one should want to discard edits. Because this was a standalone device it could impose this new paradigm. Which users could accept as device was unique, and that save-by-default was a logical form of operation. At least compared to losing your edits accidentally.

This was a logical improvement to the prevalent desktop word processors of the time, namely 199). When memory capacity improved multiple version storage is logical enhancement of this "default-save + revert" model.

So clearly not all UX engineers thought the the default convention of the time was wise. So why did "manual save" last 15 years plus? Convention and consistency. That is what makes users nervous about change in behaviour. And also users value their time, so want to be sure that the edits are saved.

What has changed? Clearly the Psion range and the Symbian OS software it spawned was not enough to influence convention against the weight of Windows & Mac OS applications and the associated OS design guides at the time. What is new is AJAX applications. They had had a reasonably blank canvas in web applications, and different constraints (e.g unreliable connectivity). In particular GMail led the way. Notably this had a few variations of UI for their auto-save functionality.

Once enough people have a degree of comfort with a new convention, then the mainstream can come on-board.

Answer 14

I think Don’t Prioritize Efficiency Over Expectations from the Nielsen Norman Group articulates a lot of the problems with auto-saving, and a way to mitigate some of the UX problems with it:

Features meant to increase user efficiency by reducing steps can end up hurting users if they do not conform to existing mental models and expectations based on past experiences.

 

What is missing from this otherwise fairly standard form? There is no Save button! How do we apply our changes so they are saved in the system? Computer-savvy readers may realize that the form is likely saving any changes whilst they are made [...]. However, most users are not this savvy [...]. This is an excellent example of how even the smallest deviation from a standard can cause confusion and increase cognitive load.

By removing the Save button the designers have taken users out of autopilot mode, as the task can no longer be completed according to plan. [...] users encountering this form must now spend time looking around the page for the omitted Save button and relate this new situation to any other similar past experiences in order to determine what action to take next. The reduction in the number of steps does not translate in a reduction of the interaction cost, since users must spend cognitive effort to find a new procedure for dealing with this less common pattern.

 

[...] users want to feel in control. Feelings of control can only occur when [...] the system [...] clearly tells the user what the state of the system is and how to manipulate the interface to change that state. Users need to be continuously aware of the current status of the system [...]. For users, seeing is believing: visual feedback must be displayed for every process a system undertakes. Every action, from exposing hidden content to communicating progress during a wait, must be clearly displayed in order for the user to understand anything is happening.

Taking away the Save button reduces users’ control over the interface. Suddenly, the website is an autonomous entity that decides on its own how and when to do things. To give control back to the user, the system needs to show that it is not acting under its own accord, but it is merely responding to actions the user has initiated. In the NextDoor example, rather than autosaving only in the background, visual feedback must be displayed on the page to communicate to the user that the new settings have been saved as they are being selected.