Creative Version Control

By Aaron Weyenberg on 25 January 2010

Thomas Fuller and my Krups egg cooker

The 17th Century English historian Thomas Fuller once said that “all things are difficult before they are easy.” Things like the reflecting telescope (Newton) the steam turbine (Branca), and the adding machine (Pascal) were all inventions to make life easier back in Fuller’s time. In this millennium, one device I use daily (generously gifted to me by a colleague here at Fanzter) is an amazing Krups egg cooker. Now I enjoy perfectly hard boiled eggs in 15 effortless minutes using only 3 ounces of water. I put the eggs and water in the device, turn it on and forget about it until the buzzer sounds. The traditional way of hard boiling eggs offers nothing but inconvenience to me now. The new way is expedient. It’s easy. I can’t imagine making a hard boiled egg the old way.

Such is the sentiment for version control among developers. Sure, a developer could sit down and write unversioned code day to day, but few developers worth their salt would ever recommend that approach. And multiple developers working collaboratively? Out of the question. Here at Fanzter, we have migrated from SVN to Git for all our products. While its learning curve is a little steeper than SVN, the benefits are worth the climb. But is versioning your work just for developers and engineers?

Designers as team members

My creative career spans the gamut (pun fully intended) from tiny design agencies to art direction in creative teams designing for over 20 million unique users per month. One observation has remained relatively constant throughout these environments: Creatives tend to operate as individuals, developers usually operate in small squads. Of course there are some exceptions to this precept, but they’re sporadic in my view.

This isn’t to say that creatives don’t often draw upon each other for inspiration, influence and feedback. I’m focusing on the actual modus operandi of how the work is generated, stored and revised.

Creatives: individualism, supposition, subjective leaning, binary files

Developers: collaboration, efficiency, objective leaning, plain-text files

It may be unsurprising that designers are generally unreceptive to version control systems, even with a GUI to take the geekery out of using the command line.

Developers have unsurprisingly capitalized on their own strengths by creating robust version control systems for themselves. Awesome. But how can creatives be more integrated?

My creative career has taken turns through tiny design agencies to art direction in creative groups designing for over 20 million unique users per month. One observation has remained relatively constant throughout these environments: Creatives tend to operate as individuals, developers usually operate in small squads. Of course there are some exceptions to this precept, but they’re sporadic in my view. This isn’t to say that creatives don’t often draw upon each other for inspiration, influence and feedback. I’m focusing on the actual modus operandi of how the work is generated, stored and revised.

Here's a rough, unscientific representation of these dynamics at Fanzter:

blog-post-chart

Developers have unsurprisingly capitalized on their own strengths by creating robust version control systems for themselves. Designers are generally unreceptive to this way of storing and revising their work, even with a GUI to take the geekery out of using a command line. But how can they be more integrated?

Creative crossover

While many teams include those whose prime skill is to convert mockups into something a developer can wire together, many creative types can (and often prefer) to translate their own artistic efforts into well-formed, semantic XHTML architecture and CSS. Some go as far as to mock the intended UI behaviors using popular Javascript libraries like jQuery, or even write custom scripts themselves. All well and good. But even if these files are created and managed individually, they can and should be versioned.

The moment a designer starts working with plain-text files, they have become a development squad member.

This is the moment to embrace version control. It’s a transient state, but it’s reality.

At Fanzter, every static XHTML mock is stored in the dev repository. This includes those mocks that are just exploratory and never see real development time. They also reference the same versioned CSS and other dependencies as files in the main dev repo do. This ensures that styling revisions to a mock never veer out of sync. It’s clean, it’s decentralized, it’s protected, and developers aren’t thrown any surprises.

Binary art files

Version control products like Git can store these files. Fanzter maintains a repo for key art source (.psd, .ai, and other binary formats) for all our products. It’s a bit of a tough sell for creatives to use these source control repos for art files, so there are some promising VC products available that may work well for those primarily working with these kinds of files. Timeline offers version control specifically for Photoshop using SVN, and Gridiron Flow lets you visually see how your art files are related and how they’ve changed.

But the essential distinction remains: design work is generally not socially collaborative, so the appeal for designers to faithfully use VC products may still be some distance away.

How does your creative team handle their own group's versioning? If there is critical source that is shared among other groups, how is it organized to maintain a sensible work flow? I look forward to the day when filenames like mockup05_revised_final_reallyfinal.psd are left in the dustbin of antiquity... but things are often hard before they are easy.