05. August 2012 · Categories: Apple, Software

When Lloyd Chambers noticed the rather peculiar way the Save As command in Mountain Lion works, it got me thinking about how saving files should really work. During normal operation you want to never notice saving. The document should be just there when you need it, with the content you expect to see. So documents should be saved automatically, and they should preferably even get a good name automatically.

Once you have your file, it will need to support a few typical use cases:

  1. You modify the content, and want the latest version kept around
  2. You want to compare with a previous version to review or undo some changes
  3. You want a specific version of the file to stick around, typically a version that you have shared with someone
  4. You want to use an existing document with similar content as the basis to create a new document

If we look at the current implementation in OS X, we see that it is well suited to only the first two requirements, but the last two are not really supported. You essentially get a cop out in the form of the Duplicate command. But what would a better implementation look like?

To deal with use case 3, we should get the following commands to support us:

  • Save Named Version will save a version which you can give a name. The OS guarantees that it will never delete this version on its own.
  • Export Version allows you to select a version and create a new file from it. This would basically subsume the standard export dialog by adding the native file format as an export option. The important feature here is that the exported version will have all history removed from it.
  • Clean Up Versions would allow you to scrub old versions hanging around, especially the named versions. With storage prices so cheap nowadays, this would not be used very often, but it would give peace of mind.

And for the last use case, we should be able to express our intent directly as a file command:

  • New from current Document will duplicate the document, remove its history, and treat it as an unnamed document from now on, maybe with the copy of name used as the default save name. The old document will stay around in its own window.
  • New from Document Changes will do the same, but also restore all changes made to the original document since it was opened. This supports people who start typing before deciding that they wanted to have a new document.

This way documents would finally behave as one unit, making the cognitive task for users a lot easier. The old save as command only makes sense as long as you understand that each document has two instances, one on disk and one in memory, and that changes done in memory are only copied to disk when you explicitly save. But if you treat the memory only as a cache of the file on disk, one layer of complexity disappears, and working with files become a lot more logical. No wonder that Apple wants to get away from this, because it makes using the computer unnecessarily complicated.

But this goal requires that your documents behave consistently no matter where they are stored. The fact that versions are only supported for local files on HFS+ volumes is a usability disaster, because now versions are making life even more complicated than before. You need to learn one model for local files, and a completely different one for remote files. This is a recipe for mistakes. So unfortunately this new approach is an all or nothing proposition: Have it implemented on all supported file systems, or nowhere. As the absolute minimum implement a local versions storage for all files opened on network drives, and keep them around for a month, so that we can rely on the versions being there when we need them.