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?

  • 1
    The contacts manager in Gmail has a save buttons, but additionally it saves when you move the focus to another field (and the "save" button turns to "saved"). Despite I'm not used (and usually quite worried) about auto-saving, in this way I get used after a few times that I notice that the save button "works" without any direct intervention. This is similar to the other placebo ideas above, but it makes the user to get used not using it. – Omiod Aug 5 '11 at 12:48
  • 8
    I personally hit Ctrl+S every sentence or so (or Ctrl+X Ctrl+S in emacs) -- I guess it's a form of autosave -- so for users like me, I don't think it will be a huge switch (as long as Ctrl+S doesn't suddenly do something else). – NickAldwin Aug 8 '11 at 22:55
  • 1
    @NickAldwin - Years ago when using FileMaker Pro (a workgroup database product similar to Access), I used to be suprised by the sort dialog coming up unbidden ... guess what the shortcut key was for sorting ... – Bevan Aug 10 '11 at 22:32
  • 10
    Sometimes, I just want to edit a document just to see how it reads like, not necessarily want to commit the edit. Auto-save becomes a troublesome thing because it simply saves it for me, overwriting my original file. – xenon Feb 9 '12 at 9:49
  • 3
    Note that with some applications that save larger files, auto-saving is technically challenging. (Think 2gb photoshop files.) – kontur Dec 13 '12 at 19:16

14 Answers 14


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.

  • 18
    +1 Yeah one of the techniques I was thinking of to help people transition to this concept was some sort of placebo button. – Matt Rockwell Aug 3 '11 at 17:04
  • 2
    This stems, I think, from the user's not having any other way of assuring themselves that the state was actually saved. Adding some text that says something like "saved seconds ago (10:35:54)" would help as well, but it would also educate the users, eventually, that they don't need to worry so much about saving. – Assaf Lavie Oct 15 '11 at 18:28
  • 1
    We have that for the user. They usually ignore it. Most customers get used to it and start to get annoyed with other apps that dont autosave. Its a cultural evolution in app design..slow motion evolution. – Glen Lipka Oct 17 '11 at 14:52
  • 1
    You should answer the question about placebo buttons. This is a great example! – Patrick McElhaney Nov 29 '11 at 14:36
  • This is also why I press the 'save' icon many times (compulsively). – Möoz Sep 14 '14 at 22:46

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.


@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.

  • 13
    +1 This is what I came here to say. Sometimes users explore ideas that they want to be able to punt if they don't pan out, whether it's a document or a piece of email or code. If you auto-save you must complement it with a roll-back capability and it must be comprehensible to the user. – Monica Cellio Aug 4 '11 at 2:28
  • 4
    @Monica, not only comprehensible, but quick, obvious and intuitive. I may be able to understand the seven clicks it would take to undo a doc save, but a "quit and discard" button would be better. – Andrew Neely Aug 5 '11 at 2:38
  • 4
    Many years back, on the BeOS developer list, Neal Stephenson put forth the notion that "Save" should really be labeled "Destroy". That's always stuck with me. – steveax Mar 20 '13 at 4:18

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.

  • 3
    Microsoft Office does auto-save; it's how you can "recover" documents you were working on if the power goes out or the editor crashes unexpectedly. It's a bit roundabout, but I feel it should be mentioned anyways. I actually like that system, for the most part. – Reid Aug 3 '11 at 23:53
  • 13
    Yes: An almost infinite undo-function is essential for the auto-save function, to be acceptable and welcome. – user unknown Aug 4 '11 at 5:00
  • @Reid - I missed your comment - yes, but it's autosave to a temporary file. – ChrisF Aug 4 '11 at 14:35
  • 1
    I've a feeling that in the dim and distant past Word actually had an autosave function. However I have a recollection that everything used to stop for seconds while it did it so I used to turn it off. – PhillipW Mar 18 '13 at 12:03

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.

  • 5
    For some task-domains, it's not a bad concept. For others, it can be annoying. For others, it's just bad. – Andrew Neely Aug 5 '11 at 12:57
  • 1
    Auto-save requires a form of local history so that you can return to any prior version automatically. This is different than Undo since the versions must persist even after the editor is exited. – BacMan Oct 11 '11 at 15:27
  • 2
    @Andrew — This lacks constancy. If you have something to hide with so much care, maybe it is not clean. Me too, I sometimes use a text editor just to clean some text, quickly, without saving. And, when my (Mac) computer crashes while I am doing that, I am very happy to find my text back to life after restart. Thanks to auto-save. – Nicolas Barbulesco Mar 18 '13 at 21:30
  • 2
    @Andrew — I guess you are in the USA. A lawyer can search in a computer himself ?? Wow ! The American accusatorial system will always astonish — and appall — me. – Nicolas Barbulesco Mar 20 '13 at 17:31
  • 2
    @Andrew — TextEdit on my — pre-Lion — Mac does that. After a crash, TextEdit gives me back my file in its “unsaved” state — with the dot in the red light. And this is great. – Nicolas Barbulesco Mar 20 '13 at 17:37

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.

  • 5
    The persistent undo stack is interesting as it's also an integrity issue to deal with if it's a part of the file/document. – Oskar Duveborn Aug 4 '11 at 14:16
  • 1
    @Oskar Integrity issue in what way? I would probably have the undo stack be tightly coupled to the file but not saved within it. Alternately you could go with the timeline versioning where you just roll off copies of the file along a timeline (or a diff of the file from a particular state). Either way that is implementation's problem, not UXs. – Matt Lavoie Aug 4 '11 at 15:21
  • 1
    This was the answer i was going to add if it wasn't already here. Alan Cooper has been screaming for this since 1994; i have his book next to me. Everything in his book is the way things should be. The reason i don't do it is cause it's hard. Undo is hard, auto-save is hard, being able to interpret an address or date correctly is hard. – Ian Boyd Aug 5 '11 at 3:14
  • 1
    Filemaker Pro 2.0 for Mac (a database package) always did autosaves ( there is no 'save' button ) Version 2 came out in 1992... – PhillipW Sep 14 '11 at 19:44

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.

  • 6
    When I work in Photoshop I work off of a copy of the original file and ctrl-s all the time. What would you do if you worked for hours on something you actually wanted to keep and then Photoshop crashed? – Matt Lavoie Aug 4 '11 at 20:51

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.

  • You probably don't want auto-save every second anyway. Typically you'd want to save when the user has been idle for a few seconds, or if there have been too many changes since the last save. – MSalters Mar 15 '13 at 14:09
  • 1
    Thanks @kontur! To @MSalters: regardless of how often you auto-save, it's probably way too often for a USB flash drive. In fact, I believe a well-meaning application should guard against users with "Ctrl+S itch", and limit the number of saves to bare minimum while pretending to the user that it saves every time... But then we'll have a software which tells little white lies. How far from that to the big fat ones? – Pasha Mar 19 '13 at 5:22

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.


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.

  • 1
    “With undo, the session is defined as the period since the last save.” I disagree. The session for undoing is the period since I opened the document. The programs I am used to don't forget the undo history when I save. I have encountered a few programs who forget the undo history at save, but this is bad, this is poor usability, it gives bad surprises. – Nicolas Barbulesco Mar 17 '13 at 10:46

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.

  • 2
    "Avant-garde"? OS X Lion may have been avant-garde when this was written, but autosave as a concept has been around for decades, including in many very widespread programs such as Microsoft Word (and these days many webapps like Google Drive). I'm very familiar with Outlook's message "Outlook has automatically saved a draft of this message. Do you want to keep the draft?" – AlexC Mar 20 '13 at 13:16

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.

  • 1
    I think this is the Microsoft Word model. Launching after a crash, you get "Word has recovered the following documents that were open. Select which documents you wish to keep:" – AlexC Mar 20 '13 at 13:19
  • I understand the rationale behind disabling undo after a save: a person who does some operations after a save and then hits "undo" multiple times to get back to what is intended to be the saved state might accidentally go back too far. I think a better solution would be to nudge the user to take some deliberate action to 'undo' to states before the save, but allow a user who performs such action to go back. – supercat Jan 17 '14 at 18:19

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.

  • No real-time saving. Saving often, yes. But not real-time. Saving at every key press would ruin the disk ! Especially the Flash memories, as @user958624 said for USB sticks. But even true hard disks would suffer. Let's think of the planet too. And to our electricity bill. Saving all the time would eat way too much energy. Saving every 30 seconds, and only if there has been any change, would usually be enough. It depends on the application. – Nicolas Barbulesco Mar 17 '13 at 11:01
  • 2
    @NicolasBarbulesco: Would you have to save to disk? You could just keep saving a cache that you then flush, say, every 30 secs. – curious_cat Mar 18 '13 at 12:34

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.


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.

Your Answer

