Technology•Nov 22, 2016
Leveraging Bootstrap and a Living Style Guide to Easily Rebrand Your Web App
“Many have tried, but very few succeed.”
That was the response I got from Senior Architect Cody Case when I told him about our plan.
Three of us were going to take a client’s web application—an application written by 24 consultants over the course of two years that included 14,052 lines of HTML, 24,721 lines of JS, 8,007 lines of SCSS, —and completely redo the look and feel in two weeks.
In the end, it worked out, but only because we laid a solid foundation before launching into the rebrand.
Where It Began
Our client needed to build the first of multiple applications in an analytics suite to help their customers filter, manipulate, and sort large sets of data.
The initial app was built by six full-time consultants over a year. The front-end code was written in AngularJS and used a mix of custom and Bootstrap styles.
Rewriting and Standardizing on a Framework
At the end of the first year, Credera conducted an in-depth usability assessment, redesigned the app, built a prototype, and tested it with users.
With the redesign, we decided to standardize the app as close as possible onto Twitter Bootstrap, since it would give us the best velocity out of the gate due to its pre-built and well-documented styles, particularly when compared to building our own CSS or JS framework. We estimated that standardizing on Bootstrap and completing new features would require a team of eight consultants for approximately six weeks.
Two feature-focused teams started rewriting the application using purely out-of-the-box Bootstrap classes. Meanwhile, another team focused on user experience (UX) started building a custom compiled version of the Bootstrap styles that could be pulled into the application via a Bower component.
Our hypothesis was this: If we could use more Bootstrap classes and write less custom CSS, we would be able to ship a much better experience with much less effort. Specifically:
The user experience would be significantly more consistent across the app.
It would take significantly less effort to develop future features due to component reusability, not having to write and test new CSS, etc.
If we abstracted Bootstrap from the app, we could reuse the same Bootstrap configuration and code across multiple applications, leading to a more unified experience and gaining efficiencies across the analytics suite.
A few weeks in, we pulled the framework into the application and it worked perfectly. All the standard Bootstrap looking elements the feature teams had been creating were now taking the styles the branding team had created.
While the feature teams continued to rewrite the application, the UX team spent the next few weeks building out a fully fleshed out style guide with example code, cross-application directives, and key CSS classes to look for.
While this was a great victory, the largest test was yet to come.
The Team Scales, Velocity Increases
At this point the team continued to grow, eventually scaling up to 24 full-time consultants. We began to roll the framework into other applications the client was building so they would be able to deliver the same great experience to their users and realize our benefits of efficiency.
One new consultant to the project actually remarked, “This basically eliminates the need for me to write CSS.” Without the need to write CSS, we enabled most of our consultants to operate where they were most skilled—at creating functional code—rather than wallowing in things they weren’t, like trying to figure out how to lay out a page, space it correctly, or what size font to use for a section header.
Our approach to writing new CSS was:
Don’t write new CSS.
Check the Bootstrap docs to see if there’s a class you can utilize.
Check the Bootstrap variables to see if you can manipulate Bootstrap to do what you need it to do.
Check our documentation to see if we’ve already created a custom component for it.
If all of the above don’t help you, now you can write new CSS component, but you better document it.
Of course, this was all reliant on the UX team reusing components across the application. If our designers were consistent, our developers could be also. With the framework in place, we actually got to the point where the designers could essentially deliver wireframes and our team could implement based on those guidelines, which alleviated the designers’ need to deliver pixel perfect comps.
Rewriting and Leveraging the Framework
At this point we were realizing a lot of the benefits from the framework in our daily operation. Consultants stayed focused working in their wheelhouse and styles remained consistent.
The big test came when marketing rolled out a radically new look and feel for the whole company to implement.
With our framework in place, most of the consultants continued developing new features, while only three UX-oriented developers stopped to work on rebranding. Since our team was consistently utilizing Bootstrap classes and our framework was already abstracted from the app, the only rebranding changes we had to make were to the pre-existing Bootstrap styles in the framework.
For example, if the new brand guidelines called for all primary buttons to now be semi-transparent orange with a dark orange border, all we had to change were the styles for our one primary button in the framework and that would apply to all primary buttons in the app. We repeated this for each element including tabs, modals, dropdowns, links, tables etc.
Once the framework styles were changed and pulled into the actual app via Bower, the new styles applied seamlessly across the app. After that, we simply had to do a spot check across the application to ensure that all the elements in the app were using predefined Bootstrap classes. Because our team had been so consistent in adhering to the Bootstrap and documented custom classes, these were few and far between.
In conclusion, it was ultimately our teams’ adherence to reusing classes across the application that enabled us to do such a radical rebrand in two weeks. This was enabled by often referencing the Bootstrap docs and maintaining a well-documented and up-to-date, living, integrated style guide framework and including it in our application as a Bower component.
Without the pre-written styles, documentation, and team discipline, the rebrand wouldn’t have been possible.