No More Saving

This proposal is aims to replace the traditional notion of manually having to "saving" a file in our applications with a new model based on implicit, continuous autosaving. To make such an approach usable, a redesigned File menu is proposed which preserves the benefits of the explicit-save approach.

This is inspired by a chapter of Alan Cooper's excellent book ''About Face 3''.

The Problem

While GNOME has always aimed for a great experience for casual users and has made great strides towards this goal in the 3.x cycle, it still shares a major usability issue with most other current desktop systems: its applications still require their users to manually save changes made to documents, and to explicitly choose a name and location for the document when it is first saved. This approach has several issues:

• It is unnatural. Arguably, the concept of saving is purely an artifact of the split of RAM and hard disks in current computers. There is no analogy for it in the real world: if you write something down on paper, you don't need to "save" it - it's just stays there.

• It makes data loss too easy. Everyone has probably lost a non-trivial amount of changes to an opened document because the application crashed, somebody tripped over the power cable, or he/she simply clicked the wrong button of a save confirmation dialog by accident. As a user, one would expect the application to take care that his hard work is preserved in any case, but very few of them actually do so.

• It requires unnecessary upfront decisions. It is not unusual to see people save new documents only after they are completely done with them, partly due to the reason that the act of saving forces them to explicitly give the document a meaningful title and filesystem location - even if they are not sure yet about these things. This unnecessarily disturbs their workflow, which is why they avoid it (and, thus, risk to lose everything with bad luck).

However, it is important to note that the explicit-save model also has good sides:

• It is possible to not save some changes to document. For instance, when toying around with a document application, you can simply close it when you're done and choose to not save the (probably meaningless) product of your experimentation. It is also easy to open an existing document, make some experimental changes to it and, if you don't like them, simply discard the modified version by not saving.

• Save As … allows a user to make backup copies of a document under another name. However, he/she needs to remember to re-open the original after doing this.

Every replacement for the traditional model needs to support these use cases just as well, or better.

The Proposal

With the proposed model, our applications wouldn't expose a Save command at all. Instead, they would save all document changes instantly (or as timely as possible). To make this work for new documents (which, of course, have no name and location yet), the application chooses a generic name itself and stores the document in the user's Documents folder (or any other XDG user directory that is appropiate for the document type).

Naturally, this model requires substitute commands for some of the things we currently handle via Save and Save As …. These would be made accessible through new items in the File menu:

• Rename… would be used to give the open document a meaningful name.

• Move… would allow the user to move the opened document to another folder than the default one. (This can include renaming.)

• Make a Copy would create a copy of the opened document with a generated name (such as "Original Filename (Copy)") and open it along the original one. This enables experimentation on the copy while leaving the original intact. (An alternative would be to offer file versioning to the user via commands such as Make Snapshot and Restore Snapshot; see later in this section why I find this problematic.)

• Revert Changes undos all changes done to document since it has been opened. It is the equivalent to simply not saving the document in the traditional model. This action must be undoable.

With this set of commands, the user can do everything he or she can do with the explicit-save model, while not having to think about about saving, serious data loss or even explicit file management at all.

Bonus: Making a file manager unnecessary

A nice side effect of having the File menu items detailed in this proposal is that they supports several actions - such as renaming and moving an opened document - which currently require the use of a file manager or shell. For many people, this means that the explicit management of files with a separate application becomes unnecessary in most cases - they can simply manage each document directly within the application they edit it in, and retrieval is easy via the shell search function or Documents. That way, these people need to think about the filesystem far less than now, which fits great into the document-based model that GNOME is currently heading to.

Thus while it is not necessary for the objective at hand, it would be convenient to also have a Move to Trash … item in the new File menu to complete the set of file operations. With this addition, users would also be able to remove documents without a file manager. Optionally, we could even expose (something like) Nautilus' file properties dialog for the opened dialog via a Properties… item. (This could replace Rename… if the dialog also allows renaming.)

Why No Versioning?

The proposal of a Make a Copy menu item might raise a question: why not do versioning? Personally, I think that having several revisions of the same file under a single logical name is unnecessarily opaque. It is too easy to not be aware of these revisions and think that only the latest version exists, especially for users not used to them (that is, most users that don't know about version control systems such as Git), which can have unpleasant privacy and security issues. Also, it is difficult to do this transparently on non-versioned file systems and external drives.

For these reasons, I think that explicit revisions with distinct names - that is, explicit backup copies - are much easier to follow and reason about, which is why I propose Make a Copy. I am eager to hear your opinions about this, though, so go ahead and add them to the Discussion section!

Issues

- Because the user is not required to explicitly name new documents, the proposed model encourages the accumulation of big piles of files with meaningless names such as "Document #23" or "Spreadsheet #5". A solution that would still avoid disruption of the user's workflow would be to ask the user to name the file after he is done with it - that is, when closing the application.

- The proposed model makes it impossible to play around with a new document without making it instantly persistent. Thus, throwing it away would require the user to explicitly remove the created file - which would be especially painful without a Move to Trash… menu item. (In any case, it would be easy to forget this and accumulate a lot of nonsense files this way.) This can be solved with the dialog proposed for the previous issue - it could include a Move to Trash button to discard the document instead of naming it. (Note that this is better than the traditional Close Without Saving because moving to trash can be undone.)

Implementation

To make it sufficiently easy to implement the model proposed here, it might be beneficial if we had a dedicated API for in-application document management that helps with implementing this, but I haven't thought about this much yet. Comments are welcome.

Discussion

This proposal is still very sketchy. Feel free to add any comments here so that we can make it better!

FedericoMenaQuintero - This is *fantastic* stuff, and you've outlined it very well! It's wonderful to see that it has ideas similar to what I had in the original Document-Centric Gnome presentation - but you've made this a lot more clear than I did:

• Auto-save, of course.
• Title bar of a document window is editable; you can change the filename there.
• We have a "Save" button to reassure people - just like Google Docs. When doing paper prototypes of this with my wife, she was looking all over the place for a Save command - so it looks like it's needed.

I think the "pick an automatic location and name" for new files requires having something like Zeitgeist's journal. That way, new/unnamed files *will* appear in your ubiquitous journal, so picking a good initial location is not so important (they can simply go to ~/Documents, as you say), because you *will* see them in the journal.

As for standard machinery for auto-save, we could have:

• Write to a temporary file; atomically replace the old file. libgnome-office used to have something for this (it's simple to implement, but has some pesky details).
• Pick a default location (or simply standardize to ~/Documents)
• Generate a default name. In my scheme for titlebar-is-the-editable-filename, I wanted to have simply "Untitled", since that just compels you to pick a better name.
• Maybe some machinery for "Revert"? This could be as simple as copying the original file to a backup location when you auto-save to it the first time, and having the app be smart enough to reload from that backup file.
• Some standard widgetry to indicate when things are being auto-saved, maybe.

I agree that our first cut at this should not take versioning into account - that's a much harder problem. Your scheme seems just perfect, and easy to implement.

JohnStowers - I am a fan of the google documents approach to introducing this feature:

• Have an always visible indicator that says 'Saved x seconds ago'
• In the File menu, where people usually look to click save, repeat that indicator, making it either for display (and inactive), or a manual way to initiate the auto-save.
• Both these features could ease the transition / reduce to panic, into this auto-save future

FedericoMenaQuintero - Apple's documentation for auto-save (look for the "Automatic Document Saving and Versioning" heading in that page). For the actual APIs, see this page and look for "Documents Are Automatically Saved".

LionelDricot - This proposal is awesome. I'm in love with this groundbreaking idea. I think the problem of multiple nameless documents can be partially solved with a closer integration of Zeitgeist. "Find the document I wrote last week" or calling a document "Document from yesterday" would be really useful. Another problem I foresee is migrating users which have 20 years of "saving" experience. Do we want to help them migrating to this new paradigm?