WYSIWOD

Proposal: 'Instant apply' saving of documents as you edit, What-You-See-Is-What's-On-Disc (WYSIWOD)

LukeHutchison: What about a fundamental move away from "Save" as a specific operation, to a model where every keypress (and all edit history) is saved along with the file, so that when you close a document window and open it again you are exactly where you left off? The idea is that there shouldn't be a difference between what you see on screen and what's on disk, for basic editing workflow. This is an extreme extension of "instant apply". TomBoy already does this (you just edit notes and close them when you're done, there is no "Save"). "Save" breaks the desktop metaphor rather badly (on a real desk your sheets of paper, even those containing draft notes, don't suddenly vanish when you switch off the desk lamp...)

Of course this raises privacy issues (Word "track changes"-style), so programs should store "work in progress" documents in an internal format, and have a function to export to a history-free format for sharing with other people. Or the user could choose not to save the history with the file, and just have an autosave function that would work in the background and save snapshots of the document more frequently than current programs do, and again at program shutdown. For large files, a lot of asynchronous logic would have to be added to allow saving a snapshot of a file in the background while the user continues to edit the document, however incremental saves could be implemented by just appending undo history since the last autosave to the end of the current work-in-progress (WIP) file. WIP files should probably be kept separate from exported files, perhaps in a dot-directory, with a special GTK bookmark to this directory so the user can pick up editing where they left off.

[Later thought: Actually the diffs/history/incremental saves should probably *always* be kept separate from the actual document that is being worked on. It should be the app's job to make sure a consistent snapshot of the current state of the document is written on exit. Raises session management issues, e.g. on logout/shutdown.] An extension of this is e.g. to have apps (e.g. OpenOffice) keep a PDF version of the document always perfectly in-sync with the non-PDF version of the document, so you don't have to remember to re-export whenever things are changed in the main document.

JohnNilsson: The "Save" button can also be thought of as manual memory/cache managment. I think that in the 21'th century we should let the OS handle memory management.

We should also note that in the 21'th century a computer isn't an isolated system wiht one user. The internet is a fundamental part of out lives. Collaboration and social software is an essential theme for a modern desktop. Thus we should also incorporate concepts from the RCS world into ordinary document handling. Branches, microbranches and changeset propagation could be layer on top of persistent undoable state changes. OTOH propagating a state change or state representation (ReST) doesn't mean that we should/must share entire document history. Even for storage reasons there must be a way to merge a line of history into a singel state transition.

ThomasRiedrich: I very much like your idea of "instant saving", but it raises a few problems. Lets asume I have a word processing application which such an instant saving, and I have an office document somewhere on my harddisk, and I open it for editing. I type something, change a few formatings, and when I close the application, the changes are instantly applied, without me having to do something at all. Well, I might not want these changes to happen because I rethought things and came to the conclusion that the previous version of the document was better. So there needs to be some kind of version management. I think this should be integrated into the file manager & into the application itself. When I double click a document in the file manager, the most recent version is loaded, but I can also - somehow - choose an older version of the file, and open this one. The file manager should also have functions to delete older versions of a file. The application itself could have some more advanced version handling, like showing the differences between versions, merging versions etc. etc.

Actually, F-Spot has a similar feature. If you edit a photo with F-Spot, you can choose to view the edited or the original version. The question arises of how to save those versions. In F-Spot, you have two pictures on the harddisk, which doubles disk usage. Especially with XML-based fileypes it should be possible to implement some kind of incremental saving. The first version is saved fully, and all changes are saved incrementally, or vice versa (the most recent version is full, and the older versions only contain information that has to be removed from the most recent version). I have an idea how Nautilus could handle multiple versions in "list view". IF a file has multiple versions, then there could be a simple symbol behind the file name, or perhaps there's an extra "version column". If you double click the file itself, the most recent version is opened. But you can click this version symbol, similar as how you can click the arrow next to a directory, and it opens like a directory, showing the different versions of a file (something like "Version 1.0: 2006-05-18, 15:30"). As you already stated, when I for example send such a file as e-mail (right-click in Nautilus: Send to) then only the actual version should be sent, without any versioning information (or only optionally).PauloVilela: Has anyone given a thought about using 3D features to better organize the desktop, like uncluttering it and giving it a more appealing look ? (EG : Project Looking Glass)

DanWalmsley: The idea of storing version history as part of the file and having most/all application support it sounds a lot like Apple's new Time Machine feature. Go to http://www.apple.com/macosx/leopard/index.html and click on Time Machine for a visual demo. Essentially, it allows you to graphically "browse" previous incarnations of folders, files and even application interfaces. Just look at how they restore previous contacts in the Address Book - they're browsing backwards in time with a live search running, and as they go back additional entries appear that satisfy the search. Very very clever.

gregsteffensen: Since linux filesystems don't generally support versioning, if you want versions to be available, you're going to have to store the "files" in some higher level medium that gnome provides an api to. I like that idea; it gives you a way to add other features that aren't supported by the unix filesystem api as well, such as tagging and introspectable structure. The data could still be made accessible through the filesystem through FUSE, but the more sophisticated api would be through gnome. The hierarchical filesystem metaphor is 60 years old now... microsoft and apple are trying to move beyond it (apple with more success :), and maybe gnome should too.

AndreasKohn: Just for reference, a similar change has been suggested in Cooper, Reimann "About Face 2.0". The main rationale was that the whole concept of "save" is rather difficult for really new users to understand, and everyone else "just got used to it". (ISBN: 0764526413) However, to really make that work, *no* application should have "Save" buttons, otherwise the whole UI gets a little bit messy and even more confusing ("Is that change now persistent, or did I just miss the save button somewhere?"). Non-modal, instant UI feedback may work for a transition phase.