Jump to page content

Saving changes

Caveats

Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.

If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.

No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.

Contents

Overview

To save, or not to save …

There is no question that all document-orientated applications must at a bare minimum support autosave, in a clear, logical and intelligent manner.

There is a more burdensome question as to whether Apple’s idea of never needing to save at all is a good idea or a bad idea. Per consistency, the answer to this question is easier when the behaviour is identical across all applications. Microsoft Office implements “live autosave” (automatic save into the actual live document) in Microsoft’s typical manner of making Office behave differently to the rest of the system. The problems are two-fold:

  1. “Live autosave” in Microsoft Office only works when it wants to: some documents use it, and some do not, so the user is never clear on what is going to happen. While there are technical reasons behind this (for example whether or not the file lives in SharePoint), to a non-technical user these reasons are not necessarily apparent.
  2. “Live autosave” does not exist in most other applications, so users are burdened further with having to carry this unnecessary distinction in their head.

Assuming that “live autosave” is in use when it is not will result in lost work from forgetting to save periodically. Assuming that “live autosave” is not in use or simply forgetting that it exists (or indeed not realising it exist) will lead to files being overwritten. Excel has long had a bug where some documents recalculate (or some other irritant) on load and this causes the document’s dirty flag to be set, triggering a “live autosave” that resets the file’s modification timestamp when the user is merely examining the document.

“Live autosave” is not necessarily a bad idea, but it must be implemented with great care and consideration. Otherwise, all document-orientated applications must implement “classic” autosave. The latter alone is quite sufficient to survive reboots.

Manual save

Should Save be made a manual action, there needs to be a way to indicate when the active document contains unsaved changes. Existing implementations include:

For example:

“*” added to the title bar; most programs put this before the filename but JujuEdit puts it after the filename
LibreOffice uses both a red circle over the Save button in the toolbar and a warning icon in the status bar

Applications should only be telling the window manager about the document status. How the unsaved changes state is shown should be left to the window manager to handle, to ensure that the behaviour is consistent between applications. For example, WordPad and Paint in Windows 10 do not indicate unsaved changes at all, neither does Adobe Photoshop 7.

Session saving

One of the underlying concepts of Apple’s pervasive “no-save” approach is that it is possible to sign out and sign back in and have all your applications and documents reappear just as they were prior to signing out. This means that reboots for updates can be performed without losing the state of your working environment.

Where possible, document-based applications should be capable of storing their state upon exit and restoring it upon launch. This state will include all open files and the position of each window. If file saving is to be made a manual action, a final autosave must be made of each file prior to the application’s exit and the files will be restored from autosave, to ensure that the user can back out of any changes made to the document that were not intended to be committed to disk.

Under these conditions, a modifier key or similar will be needed to close and re-open an application without restoring the state. Autosaved work will not be lost and auto-saved documents may still need to open automatically, depending on what standard means is chosen to notify the user of unsaved work.

For years, browsers have maintained crash-safety in the form of remembering what tabs are open and even the contents of form fields. Ideally, this concept would be extended as much as possible, starting with document-orientated applications, to accommodate from (for example) unexpected loss of power. Browsers themselves are likely to be exempted from the standard session-saving system but it may well be that a single state-saving mechanism can be used for browsers and other applications alike. Games will likely be exempted from session saving, although there is no reason why single-player games cannot also implement on-exit state saving.

See state for general notes on state.