Version control is a good idea, so it’s strange how little it’s reached outside of the world of programming.
For example, the Google Doc in which I’m writing this essay has a version history feature, which is cool. But it’s like the name suggests, a history, a timeline. Not a tree that can branch in several directions like proper version control software.
Part of the reason for this disconnect is the lack of accessibility.
Git is the most popular version control system in the world of open source software, but despite being the de facto standard and the version control system most programmers learn first, Git can be difficult to learn. There are whole books written on how to learn Git.
All this seems a bit odd when the basic ideas of version control are so simple and natural. Something seems wrong here.
Another reason for the lack of reach is Git’s design choices, which prioritize team collaboration over creative flow.
I want to propose a different version control interface that’s well-suited for design and creative work in general. But first I should talk about why version control is a good idea for design work in the first place.
Why version control can be good for design
Design can be defined as the purposeful exploration of a possibility space. Version control, with its ability to maintain different branching versions of a document, is well-suited to this task. It gives the user the ability to extend feelers into a design space.
I like to think of the design process as a tree. In completing a design project, decision points arise, where you can choose to branch off in a number of ways.
When a designer makes choices, they commit to a certain path down the design tree. Sometimes the designer hits a dead end and must retrace their steps. They have to recall some previous state of the project and then recreate it. This kind of thinking is difficult and error-prone for humans, but software does it effortlessly. Thus version control software can help a designer move up and down a design tree, as it can remember exactly the state of the project at every decision point.
In this sense, where we imagine design as a process of tracing a decision tree, the basic vocabulary of version control–branch, fork, merge–translates naturally to the world of design.
Now that we’ve established an abstract connection between design and version control, I want to talk about what this might look like in practice.
An idea of what version control software could do for creative work
Imagine that you are working on a musical composition.
You start with just a melodic idea. You record it.
Now you start to make some changes, while keeping the original intact. You wonder how it would sound if you reversed the melody, or inverted the tonality, or transposed it into a new key.
You save the changed melody, and then return to the original melody. Making new changes, again, you branch off of the original idea.
Now that you have two ideas branching off a derivative idea, you wonder what they would sound like if played concurrently, in a kind of counterpoint, or one after the other, as in different sections of a song. These ideas point to ways in which you could merge branches of your project.
You can continue endlessly this way, growing a family tree of musical ideas and combining ideas by merging them. Some ideas will not work. But some ideas will be interesting and suggest further development. As long as you commit your changes, you don’t have fear that you’ll lose your work, which means you can feel more free to try things.
You can also prune branches that don’t lead to anything interesting, what would be called removing branches in Git. This allows you to keep your work space decluttered.
Pruning branches isn’t the only option for the designer, however. In some cases, the function of the design tree may be to embody a family of ideas, variations on a theme. If the goal of a creative work is to create variations on a theme, then divergent branches don’t have to be simply abandoned in favor of a main branch.
The many forms of merge
I also want to take the time to look a little more closely at merging, an idea we introduced in the last section.
How merge is defined is application specific. In other words, merge is a polymorphic operation, it does something different depending on the context.
Even within a single application, I can imagine merge being used in multiple ways. In short, I can imagine it as being several words as opposed to one.
In my musical example, merge had two uses. The first use had the two merged phrases play simultaneously in a kind of counterpoint. The second use had the merged phrases play one after the other in a sequence. Because we have two separate uses of the word “merge” within the same application, we might want to separate “merge” into two words. For example, we could call the first type of merge “stack”, and the second type of merge could be called “sequence”. Better yet, we could allow the user to define their own custom merges and call them whatever they want. Much of the vocabulary of version control could be context-specific.
Criteria for version control software suitable for creative work
Using the software should be frictionless and easy. Nothing should impede creative flow.
With that in mind, common operations should only cost a single input. If we assume the UI language of conventional operating systems, the user should be able to branch a document with the click of a mouse, commit with a press of a button, and merge by dragging one idea onto another (the one it is to merge with).
The metaphors of version control must be communicated clearly, and we should prefer visual communication to verbal communication.
Uses
I’ve given a small example of how version control could be used for music composition, but I think this is only the tip of the iceberg. With a little bit of thought and planning, I suspect that version control could be well-integrated into all kinds of creative applications.
We could even apply the idea of version control as creative tool back to programming, because programming is itself a creative application. The software we might make for versioning code might look very different from existing software if our main goal was the guidance and maintenance of creative flow.
Of course, these ideas are in no way intended to replace existing version control software. I only want to extend the reach of the basic concepts. The main goal of most existing version control software has been on allowing multiple people on separate machines to work on the same codebase at the same time without breaking code. This is a very valid aim, but it’s not all that the technology can do.
Version control can also encourage a kind of free associative creative process. Yet, by keeping a record, it also reifies the creative process, making it subject to reflection and interrogation afterwards. The creative process is rarely linear, and version control software is uniquely equipped to give a non-linear account of the creative process.
In sum, version control can encourage exploration, creative flow, and it can reify the creative process, making it subject to interrogation and reflection.
Next
Next I want to look at user interfaces for version control software. What should the look and feel of the UI be given some set of design goals such as accessibility and encouraging creative flow? I’ll start to explore my thoughts on this subject in the next post.