Saving
It would be a piece of cake for programs to continually save a snapshot of what the user is working on onto the hard disk in case, heaven forbid, something unexpected happened. So why are we still forcing users to manually save their work?
Wood’s heart is in the right place, but I don’t agree with his example of HyperCard (or FileMaker Pro, which others have cited). True, these programs don’t require you to save, but I’ve found them frustrating to use. The automatic saving can cause you to lose data if you aren’t aware of how it works. For instance, if you discover that your experimental changes broke a stack, you can’t revert to the saved version because HyperCard has already committed your unwanted changes to disk. Furthermore, although it’s good that in the event of a crash you might lose less data, it’s bad that when you re-open the file you won’t know exactly which version you’re looking at. With manual saving, changes are committed to disk at mental checkpoints: the completion of a section, the fixing of a set of errors, etc.
Automated saving should probably be handled by the OS, so that it’s standard across applications. Any such solution should support multiple versions of files (like FlashBack), as well as optional manual checkpointing.
2 Comments RSS · Twitter
I think Jon has the right idea. But let's go further. (Farther? I hate grammar sometimes.)
One of the only things I like about Quark is that, at the newspaper at school, we use QuarkDispatch and it allows for manual save and versioning, in a much more intuitive way than, say, CVS or RCS: graphically.
I think extending that and having a visual listing of the differences would be better than persistent undo, for the explicit check-point revision saving. After all, persistent undo would just be a stack; being able to see it is better.
How about automatic saving, with optional explicit check-pointing? That's assuming, of course, persistent undo as well.