When talking about prototyping and wireframing, one rarely ever thinks about GIT. However, in the recent past, I found it to be something that I could actually use to improve the way I prototype. I must warn you that this is just another of my experiments and although it seems to fit my situation now, it may or may not be the best way for you to wireframe. Nevertheless, read on if you thing you can build upon this or maybe just let me know how I can make this better.
First lets talk a bit about wireframing. Wireframing is basically one phase of the user centered design process of software development. The process of wireframing is preceeded by a number user research activities which are used to create personas and scenarios to guide the product design. Once you have an idea of what kind of website/app you need to create for your customers, you then create half baked mockups that you can test with some participants or present them to the development teams to foster discussions and learn about the feasibility of the features and interactions that you are proposing. You do that because not all designs(no matter how good they are) will make it to the end product due to several technical limitations.
This last part, where you iteratively build wireframes/prototypes/mockups of your product's interface is one of those activities that in my opinion requires version control. Now, if you have a little bit of patience, you can pretty much do this in a way that is not only simple but also collaborative.
First things first : Tools
- Inkscape - Open source - Vector graphics - SVG - Small file size - Git - Open source - Collaborative - Amazing version control
So, heres my workflow.
Step 1 : New repository
Create a an empty git repository in your local file system using the standard
git init command.
Step 2 : Creating a .gitignore Create a .gitignore file and exclude any scalar image formats from being version controlled. (e.g. .jpg, .jpeg, .png, .gif). You should to do that because sometimes you might have to export your mockups from inkscape and you dont want to accidentally version control them. You only need to version control the source code of your svg files since you can generate the exports from them at any time.
Step 3 : Commit the .gitignore file.
Step 4 : Create a 'demo' branch
Step 5 : Create an annotated tag for this commit on the demo branch.
The reason I am doing this is because at this point the folder is completely clean. By tagging it, I will always have a 'named' way of coming back here. And we will be doing that a lot. Creating this tag is easy. Just do
git tag -a demo0 -m "Empty repository - It begins here."
The Strategy The strategy that I use is similar to the branching strategy proposed by Vincent Driessen here, albeit with a slight twist.
- The 'master' branch only contains the final wireframes - the ones that the development teams work on.
- The 'demo' branch, as the name suggests, contains the demo versions which you can use to discuss with the teams before finalizing.
- All the other branches that you create should be based off the first commit in the dev branch. The first commit, as we saw earlier, is essentially empty.
The question here is, when do you create the 'other branches'. Through several trials, the one that turned out to be the most effective strategy for me was a branch-per-page strategy. What you do is, you create a branch for each different page that you need to wireframe. And since these branches are all based off demo0, each branch will essentially contain only a single svg file with all the iterations of that page, or the branch might contain a set of svg files pertaining to the mockups of the different interactions on that page.
The key point to remember is that any new page MUST branch of the root of the dev branch - the one tagged as demo0. This will make sure that the commit messages for each branch can represent only the changes that are done for that particular page's wireframes enabling easier discussion.
Using this strategy, sets assume that you create three seperate branches for the three main pages in your application - page1, page2, page3.
After making several changes to the pages in these branches, when its demo time, you would finally need to commit them into the demo branch so that you can demo the whole prototype from a single folder without having to switch branches. Instead of merging one branch at a time, you can merge multiple branches using a single merge command in git. And since the files in these branches dont overlap, it almost feels as if you are doing an arithmetic addition. However, the best way to do this commit is by using the --no-ff option. Here's how I would do it.
git checkout demo git merge --no-ff page1 page2 page3
The result of this operation is that you only get one new commit for all of the branch merges and that happens because each branch is essentially independent of the other. Your demo branch has now moved ahead by a single commit that contains all the files in branch page1, page2 and page3.
Now if you decide to create a new page - page4, this is what you should do.
git checkout demo0 git branch page4
And then you can go ahead and make as many commits and iterations for page4. And when you are ready for the next demo, you can simply merge this branch while merging the other branches into the demo branch.
Modifying page1, page2, page3 and page4
Merging the wireframes of all the pages
Sometimes you may want to use a file from another branch, for example a menu template. At such times, switching to another branch can be a pain. There are a few ways to workaround this, however the one that I found the best was to simply checkout a file from the other branch, do a git reset and then use the checked out file as ususal.
git checkout page1 mypage1.svg git reset HEAD mypage1.svg
Now you have the file you need in your directory as an untracked file. Just make sure that when you are committing, you dont add all the untracked files using the
git add . command. You can instead use
git add -u to only add the modified files.
Let me know what you think!