Tools shape our work – even if they shouldn’t, they do. Ultimately, if all you have is a hammer, problems may start to look like nails. So it pays to look at the tools we are using once in a while, to make sure that we use them because they fit our purposes, not because we have fitted our purposes to their use. Today, I want to look at Bootstrap.
On a recent project we had been using the usual combination of (in this case) Visio and Photoshop to design a complex web application. Quite a while into the – agile driven – project we came to a point where a much requested feature was ramped up for development: printing the page-content without all the surrounding navigation. Simple enough, but as with all things there is always more than one way to skin a cat.
Usually, we would have fired up Visio (and Photoshop) to come up with a few variations on where to put the feature and how to design the flow. Minor stuff, but with such an important feature, little things matter. But by that time we already had a partly functional app, had gone through several rounds of testing with click-dummies, prototypes or even fully fledged beta-versions, so producing flat, non-interactive files to communicate the variations to the stake-holders and decide which one feels and works best just seemed like an outdated thing to do.
So instead I used a tool I had been tinkering with for a few weeks already: Bootstrap.
I then went ahead and built a representation of our app based on bootstrap: no backend, just frontend, which left looking sketch-ish. It was made to communicate the idea of how the user-flow for printing feels, not to recreate the entire product. That way, I could concentrate on getting the idea across by simply showing it in action – instead of flipping pages, going: and then this happens, and then this…
Going to the stake-holders afterwards, I could show them the design-concept in it’s natural environment: the browser. And not only one browser, but all the relevant ones we had available. We quickly agreed on the way forward and had a clear, common idea of the expected result – and that includes the developers.
This was not the only case where I found that using HTML/CSS/JS in the simple, accessible form of Bootstrap was the best way to communicate ideas to all members of the team and stakeholders outside the immediate team. And that is especially true if you are talking about ideas that involve interaction, but also if you are trying out page-layouts (We’ve all seen those beautiful, sprawling designs that, when looked at in a common sized browser, simply are too large to fit in the viewport of your most common user-setup).
What Bootstrap probably is not good for is that initial sketch. Gettings down those first ideas to see where you are going with the task: for that I mostly use another of my favorite tools: pen & paper.
Now for a quick overview of Bootstrap pro and con:
+ it’s a proper web page, in a browser!
+ very close to the finished product: helps you understand working with the material it will eventually be produced in.
+ responsive (as responsive as you make it)
+ default design, easily adapted
+ many interactions with a little coding, all interactions with a little more coding (using things like jquery etc)
– no hardcopies, so if you think about printing deliverable, it’s probably not for you (unless you want to print from a browser)
– coding, not drag and drop and stuff
– annotation is hard: you can use the tool’s inline labels and badges to create annotations, but doing so interactively over the web requires a little work. There are solutions, but… that’s another story
– HTML / CSS editor
– Bootstrap (not software, but framework, but, you know…)
– Bootstrap is free
– Aptana Studio is free, other editors may cost money.