Why must users make conscious decisions when to save a file? Surely a computer can work this out for itself? Imagine if saving files just happened automatically. Imagine being able to undo actions somebody performed on a file ten years ago? It is generally not possible with the current way that files are saved but a software change can make this possible. Welcome to a rant I’ve had for the last decade.
Current Save actions place a snapshot of the current state of a file on permanent storage. Forget to save and it’s only one power outage away from the loss of hours of work. Files are created by a stream of user actions which each change the state of the file. If a computer saved actions as they were being performed then the current state of a file can be recreated by just replaying the action stream. Work can resume where the user was just seconds before an interruption.
File | Save is replaced by a “Bookmark Progress Milestone” command that inserts a status bookmark into the action stream that indicates some significance to that state of the file. A user should be able to annotate these bookmarks – and even rewind the action stream to add a bookmark to a past state. If a user wants to create different variations of the same file (e.g. a designer wanting to make a blue version and a red version) then the action stream can be forked. Our current Undo actions should rewind the action stream then create a fork in the action stream when the user resumes performing actions. This means that even an Undo action can be undone.
It should be left to the computer to decide when to create snapshots of the file state. For speed more snapshots can be created. The computer could create snapshots after every computationally expensive action just to make opening the file quicker in future. Snapshots at bookmarks are probably reasonable too.
Snapshots can be deleted to save storage space because only the action stream is needed to recreate the file state at any point in time. Snapshot culling should be integrated into the operating system so that it can be triggered automatically when storage space runs low even if the original creating programme is not longer available. Some actions in the action stream could be merged and perhaps some useless forks culled – like the forks created by Undo actions.
File | “Save as ...” still has an important role. It takes any point in an action stream (usually the most current one) and allows the user to save a snapshot to a different file type (e.g. a Photoshop file to a JPEG or a document to a PDF). “Save as …” should also create a bookmark in the action stream.
Storage space is cheap and managing storage space should be a task we delegate to the operating system. Why waste precious human time? The only reasons to keep Snapshot based savings are based on historical constraints that no longer exist in modern computer systems. Time for File | Save to go!
(This is the second article in Future Design Software. Read the first article: Design at the level of thought, message and feeling.)
From a conversation with Jono Williams:
ReplyDeleteIf the actions in the action stream are timestamped then the file state can be navigated by time too. I.E. Go back to the version at the end of yesterday.
This is a really great idea and something which I'm surprised hasn't been implemented earlier. I really don't understand why InDesign and Illustrator don't have a 'History' like Photoshop does. And while Photoshop does have a 'History' it only works while you're working on that file, close it and your history is gone. I think the idea of Actions Streams and especially forks in Action Streams is great. There have been many times when I've 'saved as' a new document in order to go off on another variant, while still keeping the original file in case I wanted to go back to it. This would also save he hassle of having 'versions' of files, especially when there is more than one person working on a file and you're not sure which is the current one. Great ideas, hopefully one day it will be a reality!
ReplyDelete