Save, an historical oddity
Monday, February 15, 2010 at 10:52PM Last year, I was teaching a group of 10-15 year olds about the history of computing. The kids were pretty familiar with the technology, mostly knowing what CPU and memory and storage are. What really amazed me, though, was the universally-blank expressions on their faces when I mentioned “floppy disks”. These kids were all born (1994-1998) right at the time when floppy disks became extinct. As a result, they had not a clue what they were. Unless you directly step in to educate the next generation, knowledge can be lost between generations pretty quickly.
The save button will be one such historical quirk.
By the time my group of teenagers manage to raise their offspring to teenagehood, *they* will have to explicitly teach their children about the “bad old days” when documents needed human action in order to save. They will tell heroic stories about redoing work due to blackouts or pulled power cords. And their children will sit there dumb-founded: “Computers used to lose information?”
It was only ever a performance hack that caused software developers to require users understand the difference between volatile and non-volatile memory. Other than image and video editing apps, it’s not technical limitation that causes the perpetuation of the save button; rather, it’s cultural inertia of software developers that preserves the save button. After all, Apple’s iPhone and iPad devices already hide the difference between RAM and flash; developers of productivity applications will soon borrow the concept. There’s sufficient computing resources to do this right now, for most apps.
The manual save mechanism on desktop apps will not outlast the generation of programmers who, as children, grew up using iPhones and iPads.
When you implement continuous, automatic autosave, you also have to provide a generous undo mechanism. After all, people still make mistakes; or explicitly rely on these mechanisms to experiment.
The session-specific undo mechanism will soon give way to persistent undo mechanisms. Applications will begin to universally implement journalling and automatic versioning to support persistent undo. They will enable the exploration of multiple time-points in the versioning history using multiple representations, transition effects and graphical slide-based timeline metaphors. (Think of app-specific Time Machine functionality.)
Furthermore, in addition to a purely linear undo mechanism, developers will analyse the independence of objects within their programs, using it to implement object-specific undo and version exploration mechanisms. So in a text editor, I’ll be able to select a paragraph and have it show me the half-dozen major variations over the last n minutes/hours/days, regardless of when I edited that paragraph.
Now, providing these features introduces a certain complexity to programming. You might ask how this fits with my assertion that programming productivity will only increase relatively slowly. These mechanisms will be provided by a combination of patterns, frameworks and the use of appropriate database technology. (Ironically, today’s database technology is frequently the reason database-centric apps frequently fail to implement undo.) In the future, the persistent store will provide the framework for journalling and versioning, for both single-user and multi-user environments.
Having these mechanisms on hand will enable independent developers to inexpensively include these “advanced features” in their apps way, way before we even get close to the Hundred Year UI.
Source: To my knowledge, Petter Hesselberg’s Programming Industrial Strength Windows first proposed getting rid of the save mechanism. He also makes a strong argument for changing Save As into Archive, whereby the newly-named archived copy is the *other* document (not the current one), reversing the conventional behavior of Save As and, in so doing, providing much better UX.
speculation in
Design,
Hundred Year UI
Tweeting tip
Tip for heavy tweeters—Actually read what you retweet.