Bootstrap for Project Managers (aka Dummies)

Bootstrap has been around for a few years now, and everything I'd read about it said what a fantastic front-end framework it is. That everything is faster and easier, and it can save web developers heaps of time. Unfortunately, that's also everything I knew about Bootstrap. Ignorance is bliss, right?

Preface: I wrote this blog because I felt there was a lack informational sources that covered Bootstrap as a general 'overview'. Articles that didn't either have much assumed knowledge of front-end frameworks, or became otherwise too technically focused. Even Bootstrap's official website lacked the most basic overview. The issues I faced with Bootstrap were not understanding the implications from a Project Management perspective. Leave the technical details to the technical experts, but how does taking a bootstrap approach affect Production aspects such as scheduling, estimation and project life-cycle management? If this is of interest to you, then read on...

To Bootstrap or.. something else?

Discussions at a recent company training and education session turned to Bootstrap; whether or not we should use it more. As a Producer sitting in on this conversation, it was far too easy to drift off once the discussion between our front/back-end staff became a little too technical. At the end of the day, I didn't really need to know the development ins and outs of Bootstrap. The same as I don't need to keep across every other possible coding language, framework or technology we may end up using on a project. A high-level understanding of coding and design principles is generally more than enough to get an IT Project Manager by, when you can leave the technical details to the technical people. Having lived as a developer in a past life often makes this easy for me, though in fairness my coding days were over when classic ASP was still in-vogue. Yet despite nearly a decade passing, to this day I'm still just as capable of understanding what's going on, even though everybody now uses ASP.net MVC 3 Razor (you can't pull the wool over this Producer's eyes...). Even if I am not entirely up to speed on development 'developments'. All pun intended.

Thus, when Bootstrap was being discussed, all I was really interested in - from a PM's perspective - was whether or not it was considered a better alternative to our traditional manner of custom slicing? Wiliam has some seriously awesome slicing talent, so with this in mind, was it faster and easier to work with, and would this translate into better, more cost-effective website development that would further satisfy out clients. Would it ultimately increase our own business profitability?

The general consensus was, yes. All those things. But there's nothing arguably wrong with the traditional method we used to slice as well. And if the front-end developers (that currently worked at Wiliam) wanted to continue working on their own frameworks, that was also fine. From my perspective, (Wiliam) pride ourselves on our ability to produce - and specialise in - highly customised, bespoke applications. Not out of the box solutions, not 'themed' websites. Made sense.

Forced hand

The day would come when a client specifically requested a Bootstrap slice. We were to create the wireframe prototype (normal procedure for any new project), establish design concepts and then slice the designs. It was one of those glorious jobs where you get to do all the fun (read low-risk) stuff and then hand it over to the client's in-house team of developers to finish the job. Sounded easy. But I would soon discover that when it comes to Bootstrap, there is a whole new process of delivery that can be applied, which I had to familiarise myself with ASAP...

Traditional approach

Anyone who's stepped inside a digital agency this millennium will know the drill. I described it above. You take your scope/requirements and you throw it to a BA. They in turn create a wireframe prototype of the website, often (as at Wiliam) a nice functional, interactive one. This then is used by the design team to come up with the templates for every page, element, content module, etc. that is demonstrated in the prototype. The slicers take this output in PSD form and chop it up (slice it) and produce a wonderful HTML/CSS/JavaScript product that looks and responds fantastic in any browser, but doesn't really do anything as it's not hooked up to a database, web service or anything like that.

Pretty standard, needs no real explanation and what I thought we were doing, just like hundreds of projects before that.

Themed approach

Hello Bootstrap. I didn't think I'd be too surprised by anything a new front-end framework could throw my way, but I was wrong. I was totally unprepared to discover that the way most people (apparently) use Bootstrap is to create a CSS theme, the purpose of which is to accelerate and simplify the development roll out.

If you already know how Bootstrap works (have used it before) then this isn't going to come as much of a surprise. (Why are you reading this blog?). But going down this path, effectively throws the traditional approach to development on its head. Sure it follows the same phases that make up the project/development life-cycle - i.e. we still need UX, design, slice and development - and in that same order. However:

1. The role each plays is slightly different
2. How each phase relates to the others is also slightly different
3. The workload required of each phase is also impacted

Bootstrap - what's on the box (and themes!)

Probably the easiest high-level definition of Bootstrap I could find, came from Tutorial Republic. So I'm just going to acknowledge that upfront. That blog is also worth a read.

Bootstrap is a powerful front-end framework for faster and easier web development.

It includes HTML and CSS based design templates for common user interface components like Typography, Forms, Buttons, Tables, Navigations, Dropdowns, Alerts, Modals, Tabs, Accordion, Carousel and many other as well as optional JavaScript extensions. Bootstrap also gives you ability to create responsive (grid) layout with much less effort.

So in a nutshell, Bootstrap sets you up for success. This doesn't mean you are restricted by the framework in any way. You can add your own HTML templates (e.g. for content modules of your own design) define your own CSS styles, add to the framework, and just take what you need, ignore what you don't.

When it comes to themes, I was impressed to find that you can download (purchased or free) themes for Bootstrap. Much in the same way as you download complete templates for Wordpress or Joomla. I don't really know how I hadn't clued onto this earlier, but I guess I'd never had the need to go down that path. When you have an awesome design team at your disposal, you don't purchase ready-made templates!

What do these themes look like? Much like the ol' "standard content page" that a designer would piece together to show how common HTML elements should appear on a bog standard internal page - but much more detailed, leaving nothing to chance. Here's a link to a good example, a Bootstrap theme called 'Cerulean'. You can see that this page demonstrates pretty much any element that you could wish for. With Bootstrap, if you have a requirement or design for any other variations to content modules, you can simply define them in HTML/CSS and then you call this style whenever you want the module to appear. Bootstrap does the rest. Magic.

Roles and relationships

This is the interesting part. The general consensus is that Bootstrap - due to it's flexible and powerful ability to 'theme' a website - requires much less design and slice compared to a traditional project build. It also requires the developers to take more ownership of building out the application by calling what they need from the front-end framework as they need it. The role of the slicer therefore, is not to build out every single page, but simply to establish the framework and ensure all the themes render as per the design. Let's look at this in a little more detail.

UX - your BA or interface designer (whatever) will define the requirements and flesh out a thorough prototype. It's important that this is as accurate as possible. (It always is, but with Bootstrap, having a solid prototype is particularly wise). The prototype is handed to the design team. Nothing different so far, as you would expect.

Design - Traditionally at this point, we'd come up with a concept which would be reviewed, tweaked and approved by the client. Then we would roll out all the pages, modules, modals, elements etc., as presented in the prototype. All of it. Not missing anything. Bootstrap doesn't require this, because the job of laying out a page doesn't fall on the designer... it falls on the developer. Mind blown! I mean, trusting a developer to do this goes against all logic, when we've always relied on the design team to come up with a best practice user interface, brochure-ware layout, conversion funnel, or whatever the application calls for. How can somebody who specialises in 0's and 1's - and not pixel perfect PSD's be handed this responsibility? That's the beauty of Bootstrap, it makes this possible. The designer needs to ensure that all possible elements required for the site are covered in the design. And potentially do one or two internal templates as a guide to how the elements should fit together, but certainly there is no need to reproduce every page in the wireframe. Thus, the time required of the designer is significantly reduced. On top of this, the designer has very little reliance on the prototype, apart from checking that there aren't any specific content modules required, or anything fancy going on. For a bog standard site much of the work is just in the theme itself. Referencing / naming design elements in some form of ID fashion will help the developer identify the style they need when the developer requires them.

Slice - When the slicer gets hold of the designs, they normally require the matching prototype to guide them on putting the pages together, and to demonstrate the functionality. Under a themed approach, the prototype doesn't matter so much to the slicer as it does to the developer (more on that next). The slicer - like the designer - has a significantly reduced workload. All they need to do is slice all the elements and modules identified for the project. They have no responsibility to piece together the entire site. Bootstrap will do that shortly. The slicer only needs to style up (create HTML/CSS/JavaScript) for all the elements as designed and presented in the 'theme' PSD. And perhaps the one or two pages that might stand out as being different or used as examples. Easy, but important to get right.

Development - The workhorse arrives. After the designer and slicer have had their roles significantly reduced (in terms of hours required compared to a traditional approach) the developer makes up for this somewhat. But it is mitigated by the ease and brilliance of Bootstrap. The developer - not the designer or slicer - refers to the prototype and builds out the site by calling what they need. Bootstrap formats and delivers it based on the CSS provided by the slicer. Hopefully the designer has done a good job and the styles/elements required are easily identified by the developer.

Going forward, anything the developer needs to create a new page or feature on the site, is already defined and available to them. If it's not, it can be designed, sliced and added to the theme as a unique, but ultimately reusable element/style. Pretty clever and logical really.

There is a downside to not designing every single template. One that comes to mind is when dealing with those pesky (but thorough) clients that want to see all designs with final content and imagery in-situ, before approving. Not designing out all templates makes this impossible, so if you're building out a site this way using Bootstrap, you will need to make sure your client is onboard and happy to approve content once it's in place during the development / QA phase, and not before. This can be problematic for larger organisations that have ingrained red-tape. Legal and marketing departments that are too cumbersome and inflexible to change, or use their imagination. And even if they are onboard, a review during the development stage may mean lots of content fiddling at the pointy end of the project - just when you don't need it. You decide what you would rather; deal with content changes in Photoshop, or in the CMS at the end of the day.

Make no mistake - this is a professional framework

One of the misconceptions I had about Bootstrap was that it was somewhat of a 'cheat' approach to front-end development. That is, it made the task of creating a professional looking, grid-like responsive framework much more in reach of your average 'mug' slicer. I therefore dismissed it as a serious frame-work, which was a mistake. Given the bespoke, highly-complex, often enterprise level solutions we develop at Wiliam (for some of the big names both in Australia and globally)... These are not solutions built out-of-the-box, or using popular entry-level content management systems, such as Wordpress, Joomla or Drupal. If Wiliam choose to integrate with an existing plaftorm or product, we generally opt for well supported, open-source and non-proprietary solutions that can be built upon (customised) to our needs. The Umbraco CMS is a good example of this. The fact that you could download countless themes for Bootstrap from online template sites, probably did nothing to help me distinguish Bootstrap from something like Joomla, though remember Bootstrap is there as a framework to assist the creation of the front-end. It is not a fully blown CMS, and as such it avoids the complexity that comes with that. This gives the backend developers essentially free-reign to build or integrate whatever solution they see fit, behind the front-end. Leading to much more flexible and robust applications.

I had reservations about the product because our own slicing team had chosen not to generally adopt it, preferring the 'long road' approach. I wondered if this was because they felt it had limitations, if their own frameworks were more flexible or advanced, or as I felt - did they harbour thoughts that Bootstrap wasn't a suitable framework, given the enterprise level applications they were creating. Anyway, this (acceptance of Bootstrap) is something that is arguably changing; more and more staff in our office seem to think that it's only a matter of time before we utilise Bootstrap more widely across new projects. We have used it before, just not as the 'default' framework for all new projects.

Thus, the relative simplicity of Bootstrap should not see this frame-work dismissed. The job of a gun slicer is not put in jeopardy because the Internet has fallen in love with Bootstrap. It's just another weapon in the arsenal of front-end developers, who will know when to use Bootstrap, and when it may not be entirely appropriate. Do you need Bootstrap? Certainly not. But there are certain projects when you'd be mad not to really.

Project Estimation

Clearly Bootstrap promotes more efficient development, while reducing the requirements for design and slice, while potentially adding responsibility to the developer. This needs to be reflected when quoting for a project. A bit of number crunching and research hasn't led me to any hard and fast conclusions, but it's fair to say that if Bootstrap was deemed an appropriate framework to build out your responsive front-end, it's plausible that the overall budget of the project would be less than the traditional approach.

This is of course not the case if you decide to implement Bootstrap, yet still decide that you will design and slice every single page, even though it may not be required. In my case - the job that inspired this blog - we were handing over a slice to an international team of developers, and despite asking for a Bootstrap framework (which they were familiar with) they also wanted us to provide slices for every single page. Which means no saving in design or slice. Had we been developing internally, we certainly wouldn't have approached it this way, and would have shifted much of the work onto the development team, saving us design and slice hours.

The bottom line is, you can argue that there are significant efficiencies and cost savings (less hours required) when using Bootstrap, but obviously each project will be different, and there's no hard and fast figure (percentage?) that you can spruik. If your client was concerned about budget however, Bootstrap theming would be an obvious discussion point.

Conclusion

At the end of the day, discussing the front-end framework upfront (at the start of a new project) is ideal, unless of course the frame-work is a given, one way or another. From a PM's perspective, it can certainly have significant impact on resourcing requirements, scheduling and the cost investment for the project. Two sides of the iron triangle that you can't afford to ignore if you want to keep a grip on a successful project!

Discuss it with your entire project team so that everybody knows what is expected of them, and if you are producing a slice and handing it to a third party - like we were doing - make sure to involve them in the discussion when picking which path to go down. They may have expectations one way or another, and you will waste a lot of time if you don't manage expectations and take the wrong fork in the road.