The "Latest Version" Problem

image

At Papertrailer, we recently released our implementation of version control — a long-requested feature — and we wanted to discuss how and why our approach differs from traditional method for solving what we've dubbed the "Latest Version" problem.

First, a little bit of history

For most people, document version control is not an unfamiliar subject. Before the widespread use of cloud services like Dropbox and Box, we relied on increasingly obscure and inconsistent naming conventions to distinguish between document versions:

image

(src: geek-and-poke.com)

The number of revisions between a document's initial authoring and when you completely lose track of which version is truly the final version can probably be counted on one hand.

With the move from storing important digital documents locally to an "enhanced" folder from one of the major cloud storage providers, we've taken one step forward, but sadly also another backward.

These services enhance actual control over documents by establishing an explicit ordering between versions of a document. It may not be clearly apparent to you if you're a casual user of Dropbox, but whenever you update the contents of an existing file, Dropbox records the update as a new version. This behavior is not obvious from their Desktop interface, but if you view your file from the web, it becomes clear that they're intelligently distinguishing between versions of your file.

The app's behavior is really valuable for certain types of files, and particularly so for media files; however, for documents under heavy revision: mortgage docs and legal documents for example, the experience leaves a lot to be desired. While explicit version control is happening behind the scenes, it isn't available to you the user in your primary interface to the product, which makes it hard for you to not only manage it, but also get a grip on what changes made it into which version. Secondly, as of this post's writing, if you move or rename the file, its entire version history is lost.

The problem, as we see it, comes from the tight coupling of the document's concept(s) to its file name, and the interface we're typically restricted to in managing these two (in reality) separate things.

Fortunately, one can do better.

To solve this problem Papertrailer breaks the anachronistic link between a document's name and its concept. With Papertrailer, you are now able to freely modify a document's concepts (its title, tags, etc.) without worrying about it's historical identifier (i.e., its filename). The document you received from your accountant about your 2014 taxes refers to the same underlying file even after you have clarified its title to refer to state taxes and you noted the sender to be your accountant.

Additionally, we made adding new versions explicit and clear: you choose to establish the relationship between your accountant's document from last week that you forwarded to your Papertrailer account, and the new version she emailed to you earlier today with an entirely different filename. Concomitant with that, Papertrailer also makes it easy for you to annotate your new versions, to further make explicit the difference between the most recent and prior versions.

This approach has been shown to be very useful in industries like software development, and we think it offers a much better experience for documents as well.

Our current implementation is the beginning, not the end of the road with respect to making versioning explicit and useful for you, and we're really excited to build additional functionality on top of it.

Let us know what you think about our solution to the Latest Version
problem on twitter, facebook, google+, or via email!