I was browsing Kimbro Staken’s blog this evening, and happened across an article on his dislike of manual saving. This is a topic I’ve considered many times, so I decided to commit a few thoughts to (electronic) paper.
An extract from the first paragraph of Kimbro’s post effectively summarises his argument:
This is aimed at people developing software for Mac OS X. Will you please quit making people manually save. It’s an artifact of the computer that has been passed through to the user and that’s something that needs to stop. Computers are bad enough without having to remember to save your damn work all the time.
I’ve often considered the implications of system-wide autosaving, at least with regard to Cocoa applications. It strikes me that an enhancement of NSDocument and NSDocumentController could make this quite possible. These classes already manage saving and opening of files, maintenance of a document window’s represented filename and icon, and the tracking of recent documents. It could work something like this:
- A future version of OS X would provide a system-wide option (perhaps in the General pane in System Preferences) to determine whether Cocoa document-based applications would autosave by default. It would also allow specifying the root autosave folder, which would be the currently logged-in user’s Documents folder by default.
- When creating a document-based Cocoa application, you would have the ability to override the system’s setting for autosave; you could choose to either respect the system’s value (i.e. the user’s global preference), or to insist on always autosaving, or to disallow autosaving completely (perhaps to implement it yourself, if the default implementation wasn’t suitable - or indeed to actually disable autosaving).
- The developer would then set up desired behaviour in his NSDocument subclass:
- Choose whether to save periodically, or to save whenever the document becomes dirty.
- Choose whether, after an initial autosave, the autosave system is permitted to alter the file’s name (for example, if you wanted the filename to always reflect the first line of text in a document, the time and date last saved, or some other data).
- Implement a method which returns an NSString containing a suitable filename. NSDocument would then call this as needed to name autosaved files.
- When autosaving, files would be placed into a subfolder of the Documents folder, named after the application. A further NSDocument accessor could be provided to determine whether to create further subfolders by units of time (days, weeks, months, years?).
- An important consideration here is Undo behaviour. Autosave implies also saving after each Undo/Redo operation.
- The initial state of a document when created or opened would need to be cached until it was closed, to allow Revert to function intuitively. Revert could not simply roll the document back to its state the last time it was saved; it would need to revert to either its virgin state upon creation, or its state when most recently opened.
The two issues we immediately encounter are those of locating documents, and file proliferation. Let’s discuss those individually.
The act of saving, and being compelled to enter (or at least confirm) a filename and location creates a strong association between what we intuitively identify as “the document” (i.e. its content), and its representation on disk (the file). This association allows us to retrieve desired content at a later time. Autosaving could potentially greatly reduce our ability to readily locate previous work. There are a few possible solutions which spring to mind off-hand:
- Content indexing
Many problems: it’s slow to create the indices, very vulnerable to encoding issues, and doesn’t necessarily generalise across all possible file-formats.
- Leave it to the application
Provide no OS-level assistance for users trying to locate a specific autosaved document. Easiest to “implement”, but very nasty for the user!
- Intelligent browsing interface within the Finder
Provide a dialog in the Finder tailored to this task (which should also be available from within each autosaving application). Provide an outline view of appropriate documents, sorted and grouped by recency of modification date. Include file-sizes and other helpful information. Ideally, allow developers to implement a method which takes one of their application’s documents and returns a visual preview of its content. The Finder could access these methods (services?) from the appropriate applications to show an equivalent of Column View’s preview (this seems a reasonable idea even outwith the context of discussing autosave).
Of these, I prefer the last option. It’s certainly imperfect, but it would provide solid (albeit basic) assistance which addresses one of the downsides of autosave functionality.
I spend a great deal of time in BBEdit each day; I use it more than any other application, by a significant margin. I have no concrete idea of how many documents I create each week (especially if you include the temporary documents which I never save), but I do know that if I were to learn the number, I’d likely be staggered by it. I wouldn’t want that number of new files appearing each week inside a subfolder of my Documents folder (which is probably too cluttered as it is, but that’s another post). Clearly, autosaving needs a pruning policy.
- Let the system handle it
Extend the aforementioned system-wide autosaving options to include a pruning interval. Presumably this wouldn’t be simple pruning (move or delete all files older than x days), but would also consider recency of each file’s last modification, perhaps filesize, and other factors. The potential email-filters-like complexity of this UI could be simplified somewhat by making the default be simply to “archive” the older files in some way, rather than move them to the trash or (god forbid!) delete them outright.
It wouldn’t be at all difficult to integrate automatic compression via tar/gzip or even StuffIt. The “document finder” I mentioned above would obviously need to take this into account too, and there lies another issue to consider: the potential ballooning of the document finder’s cache.
- Let the app handle it
Each app would obviously need to be able to prevent the system from pruning its autosaved files, and would perhaps have to be able to specify a limit to the total number of retained (or unarchived) files. If however the system did not provide pruning at all, it would be each app’s own responsibility to manage its disk-space. I dare say that most serious apps would insist on implementing their own behaviour anyway in this regard.
One possibility would be for each new document to not automatically “qualify” for autosaving - perhaps it would only become an autosave candidate after amassing a certain amount of content, or being edited for more than a certain period, or passing a certain (potential) filesize on disk. Each application would have its own specific requirements and logic here.
No-one is more aware than I that the above general theory has more holes in it than a fishing net, and that some of the potential pitfalls and yawning and terrible. I’m not quite proposing this; instead, I’m proposing that we discuss the concept of implementing autosave in some generalised sense – even if (and indeed especially if) this means the merciless dismantling of my thoughts here!
Kimbro’s assertion that “inhumane artefacts” of the hardware have become dangerously imprinted on computer users is something that has a great deal of resonance for me. Computing remains in its infancy, but paradoxically we’ve all become remarkably set in our ways with regard to the basic tenets of a GUI OS, and very few are willing to seriously challenge the status quo. It is my strongly-held belief that problems like that of usable, system-wide autosaving are completely solvable, and indeed that it’s our duty to give them serious consideration.
As always, thoughts and comments are gratefully (and eagerly) invited.