Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
    
Use a standard version control system. For myself, I would always use Mercurial. On another note, it seems to me that this question isn't really appropriate on UX.SE. –  Chris Morgan Aug 10 '11 at 12:38
    
Why not appropriate? Most of us use an iterative design approach and end up with piles of revisions for even the smallest project. Good version tracking and control seems to me like an overlooked problem. –  Alex G Aug 10 '11 at 13:08
2  
It's a valid question since it's talking about version control in a high level sense, not version control as it relates to SVN specifically (even if the question mentions it). Remember Adobe Bridge? Designers need version control too :-) –  Rahul Aug 10 '11 at 13:09
    
@Rahul: I don't agree that it's suitable. This would be much more appropriate in SuperUser. –  Chris Morgan Aug 10 '11 at 13:53
4  
@Chris Super User is for power users of desktop software. Asking them a wireframing/prototyping question and expecting a UX-relevant answer wouldn't get you very far. The UX community, however, generally deals with this exact problem and can therefore help the OP. It's less a question of "what's the objective right place" and more of a "which audience is right for this question" issue. In other words, this is a process question, not a software question. If you have any more concerns please ask a question on meta. –  Rahul Aug 10 '11 at 16:20
add comment

10 Answers

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).

share|improve this answer
3  
Agree that many version control systems are aimed at developers. However, for any reader wishing to check it out (pun intended) then Tortoise SVN certainly makes life easier for Windows users. –  Roger Attrill Aug 10 '11 at 12:48
    
Cheers, Rahul. Awesome that you've got VC in Handcraft. What would be nice (feature creep, haha!) is the ability to flag and annotate a particular version for comparing to later - for example, an iteration that followed a user workshop or client feedback or scope change. –  Alex G Aug 10 '11 at 13:15
    
@Rahul: I haven't had time to look at your tool, yet. It looks very promising. But does this tool support various file types and is it "room for" other documentation? My impression is that this tool is excellent at managing the "delivery files", but that other documents (like usability reports, requirements specifications, analysis/spreadsheets, budget, presentations etc), should be held in another system? –  Jørn E. Angeltveit Aug 10 '11 at 14:25
    
@Jørn Yes, you can use other tools for that. Our view is that there are many excellent tools already doing that, so there's no point for us to clone that kind of functionality. Instead, we're focusing on being the best (and only) HTML prototyping tool on the market. –  Rahul Aug 10 '11 at 16:18
1  
I've tried Handcraft lately and I must say it's a very great tool for fast prototyping. –  Boris Delormas Feb 24 '12 at 9:10
show 1 more comment

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...

share|improve this answer
    
I see quite a few people relying on DropBox as their backup and version control system that also just happens to fileshare. It bothers me - but I'm not sure whether it should. However, the 'version control' features (i.e. restore file to previous version) I'm not sure make good sense for easy version comparison, and certainly not for change logging. +1 for SVN though –  Roger Attrill Aug 10 '11 at 12:32
2  
You are providing misinformation about SVN. It does guarantee not to mess things up. Its diffs, text or binary, are always correct. If they could be anything but that, it would not be used. –  Chris Morgan Aug 10 '11 at 12:36
    
Cheers for the feedback, all. I have thought about Dropbox as well as Google Docs (which now has version control). However, neither tool really lets you easily annotate and visually compare versions. I guess I'm just fantasizing about something like this: youtube.com/watch?v=RBL1cVzIQik&feature=player_embedded for us UI/UX types. –  Alex G Aug 10 '11 at 13:06
1  
@Chris: Thanks for the heads up. Post edited. As I said: I rely on SVN to handle binaries myself, but I didn't know that is was actually supported. –  Jørn E. Angeltveit Aug 10 '11 at 13:43
    
@Alex: That was nice! But remember that this tool only handles images. I use Araxis merge (araxis.com/merge) as image comparison tool myself. For other file types you need other comparison tools. –  Jørn E. Angeltveit Aug 10 '11 at 13:53
show 4 more comments

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.

share|improve this answer
    
This is correct. Github is also open-source, so implementation and integration with other tools is easy. –  HeyCameron Dec 11 '12 at 21:03
add comment

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.

share|improve this answer
    
If the environment you are working in is already making use of a version control system my recommendation would be to use it (as opposed to introducing something new). –  superduperfly Feb 22 '12 at 14:15
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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!

share|improve this answer
add comment

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!

share|improve this answer
add comment

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).

share|improve this answer
add comment

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

In simple terms:
SVN = centralized
Git = decentralized

I use both based pretty much on that difference.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.