Reducing the cognitive load of versioning

In my previous post I demonstrated two versioning perspectives: The archive-centric and stream-centric views. The stream-centric view is much easier to understand than archive-centric since it is just an integer rather than a combination of numbers and dots. In fact, any easily remembered notation will work for the stream-centric version labels, though the only other serious candidate is a timestamp.

Unfortunately, the stream-centric view is not good enough when you want to back-track through the previous changes to see when certain changes were made to it. Let’s say the artifact is a single quote which is part of a script for a play based upon a famous movie:

And the people did feast upon the lambs and sloths, and carp and anchovies, and orangutans and breakfast cereals, and humunculi, and fruit-bats. [1]

You are curious why breakfast cereals and humunculi were added to the quote. What you see in the stream-centric view is that somebody added “and humunculi” while fine-tuning the script for a live audience, but the trail ends there since there are only two versions in the current branch of the script. It is clear that to discover why breakfast cereals were added to the script, you will have to go back into the history of the original movie script. Thus the history must be extended back past the lifetime of the current stream:

This history of evolution of the quote has all the information you need to reconstruct its evolution, including its evolution prior to releasing the movie. Breakfast cereals were added just before the movie was released. Now, knowing what changes were made and when may prompt you to ask why these changes were made, and this is where it is especially useful to keep all the control information that authorized or requested the changes.

On the other hand, the archive-centric view gives you all the information you need, just not in an easily consumable form. The adage “a picture is worth a thousand words” applies here – sure, you get a healthy dose of the thousand words, but who has the time to take in all that? Not to worry, there are ways to reduce the cognitive load through clever design of the user interface.

If you refer back to the last post, the 3-branch scenario is starting to look quite busy. But the simple addition of the project name and some background colors (or some other appropriate method) helps you more quickly grasp the relevance of a particular stream. For example, if you are working on the “Harvard project” it’s pretty clear which stream you would want to focus on. Or, if you wanted to see what changes the “MIT project” has introduced, you know where to go.

You could even draw each stream in its entirety, including the bits that evolved in other streams, like this:

The trick to this view is that if you click on a version that shows up in more than one stream, all instances of that version are highlighted – like version 2 is, here. You might even make it blink, or provide a list of all streams that share that version.

Two important additions to the basic data model have been introduced: Enhancement of the view with an interface that is better suited to the needs of the user; and introduction of process information (the project labels) to provide more relevant information to the user. Traditional source code control applications do not have these features, but they’re getting better.

[1] Monty Python and the Holy Grail.