How do you version-control your wireframe/prototype assets?

Question

How do you version-control your wireframe/prototype assets? I have largely been working with interactive HTML prototypes and as I go through iteration after iteration I find that my process of versioning, change-logging and comparing versions, is quite lacking. Anyone have suggestions? Use SVN?

Answer 1

Subversion (aka SVN)

For text-based sources, like HTML, CSS, JavaScript etc, it's perfect and highly recommended.

When it comes to binary files and media-files, SVN is not the ideal solution. IMHE it does work OK, but I can't guarantee that SVN wouldn't mess up something. Technically, SVN saves the textual differences between each version, so you can imagine that this might be risky. I use it myself, though, and have never experienced any problems.
Update: I was wrong about the binary issue. Thank you for pointing this out, Chris.
Subversion (aka SVN) does support binaries: http://subversion.apache.org/faq.html#binary-files.

You do need, however, to check if you SVN client support the binary feature as well.

---

File sharing

Another solution is some kind of file-sharing system that automatically backs up the history. Dropbox one solution that I use a lot. Really simple to use and very easy to share folders with other people. IIRC, Dropbox saves the history, so you can go back and get a former version of a file, but this is not the main feature of Dropbox, of course.

---

Further discussion on binaries in SVN

You might consider to do some searching on StackOverflow.com. I know that this topic has been discussed over there. Maybe you'll find something at programmers.stackexchange.com as well...

Answer 2

SVN isn't great because it has a high learning curve and is primarily used by developers. If you don't have a problem with that, go ahead and use it (or git, or hg, or whatever), but I think there's a better way.

Handcraft (which I build) was designed with this problem in mind. Instead of using version control, you have distinct prototypes in your account. In practice I find that if I need to create an alternative design, there are several options:

• Create new pages within a prototype that re-use some CSS and overwrite other parts
• Clone the prototype and continue working from there

Both of these actions are very easy to do with Handcraft as we felt that asking designers to learn version control just to work with interactive prototypes is a bit "developer-minded". There should be a tool specifically geared towards interaction designers and front-end engineers which cuts out all the stuff you don't want while prototyping. That's what Handcraft is.

For instance, we're currently testing an alternate homepage design for Handcraft's promo site. It's a prototype in the sense that we're not sure about it and are trying some different things out. What I did was copy the homepage's HTML and start changing things around. It still refers to the original CSS but I created a new stylesheet that only this page uses for exceptions, changes, and overrides. It works pretty well. If I planned on approaching the homepage in a completely different way, I might start from scratch or create a second prototype based on this one so I can really dig in.

In case you're wondering, Handcraft does support rudimentary version backups so you won't lose your historical changes. But we noticed that prototyping by nature is geared towards experimentation. So the version thing is in place just in case. You should really be looking to explore as much as possible and iterate as quickly as possible instead of trying to snapshot every little change. If you want to compare different approaches, what I outlined above works really well.

Edit: something else I just thought of - I'm actually currently working on a prototype for a client and I wanted to save a specific version as reference for later. So I exported the prototype from Handcraft, which gives me a bunch of HTML files and all the included media. I then checked this into our development trunk for the final app and I plan to do that with future snapshots as the project progresses.

(Obvious disclaimer: I created Handcraft).

Answer 3

I use our SCM's version control.

Balsamiq is nice and uses XML, which the diff tools work great on and which is very compact.

For image-based mockups, it's more space-consuming, but I still use version control when I can. However, when I render high-res outputs, I tend to save those off as a separate named version, just to make it easier to find later. I ought to be using SCM labels, but the interface isn't up to snuff for this.

One pitfall: make sure you version-control the entire site at once. This includes all the pages and the scripts, and whatever external libraries you're using (jQuery, etc.). Otherwise, you won't be able to reproduce old state.

Answer 4

File versioning should be used for everything. Wireframes and similar documentation is often versioned within SharePoint (SharePoint is evil, and awful, but I will grant it that it's does one thing OK and that's sharing documents and versioning them).

That said, playing devil's advocate, if you find yourself editing wireframes a lot, I'd argue that it's a waste of time. Wireframes are meant to get the process rolling but, IMHO, not meant to act as a permanent piece of documentation that needs to be updated. I'm a fan of keeping Wireframes internal to the team and tossing them aside once the building process begins.

Answer 5

There are no right answer to this questions as there are LOADS of tools and way to face the problem. Personally I use Github for my interactive prototypes and google Docs for PDF, simply because is easier to share them, but I think you could use github with virtually everything!

Answer 6

It's not a perfect answer, but if your development team uses Subversion, PixelNovel Timeline integrates SVN into the Creative Suite so you can easily commit proofs to source control.

Answer 7

Dropbox does the job for updating graphic comp. such as wireframes design etc. It has a built-in svn and very easy to use. And yes for collaboration its great as well!

Answer 8

I also use DropBox, mostly for the auto-backup and versioning, but also for the sharing. As I'm on OS X I've also got Time Machine running, which gives me versioning even further back in time (Dropbox has limits).

Both DropBox and Time Machine have a habit of saving revisions when they want, which usually doesn't align with when I consider it relevant. DropBox saves a version on every save event (which for me is very often, not after I've done 3 hours of work without saving), while Time Machine runs on a hourly schedule. (This is where SVN et al would be appropriate).

Both are thus are not sufficient for me - my wireframes are design and communication documents, and as such get printed, emailed, transmitted via sneakernet, copied to USB sticks, posted on walls, spindled, folded, buried in peat moss, and recycled as fire lighters. If the file has the same file name throughout all my changes then I end up wasting a lot of time sorting out confusions if they are looking at an old version. Which someone inevitably will be.

Thus I also make sure my documents have a file name reflecting which edition it is. The schema I've found that works well for me is <thing-name>-v<requirements-version>-<yyyy-mm-dd>.<extension>. I've found using a date as my edition differentiator to be more useful than incrementing some abstract number: myself and others can thus look at a version and know if it was produced before or after some project event (e.g. a round of usability testing). The date format also let's me know at a glance if I've remembered to renamed the file today or not ... which isn't at all obvious when I look at something like v1.7.18.

I most certainly don't rely on the OS file modification date (there are actually some apps which touch the date when you simply open the file for viewing).

Answer 9

If you're on OS X, I highly recommend one of these two options:

• SVN via Cornerstone (or Versions)
• Git via SourceTree

In simple terms:
SVN = centralized
Git = decentralized

I use both based pretty much on that difference.

Answer 10

I understand fundamentally what Git does and I think it would be really handy in the context of high-fidelity prototyping, but as a non-programmer without a lot of command line interface chops it has a heckuva learning curve.