Building Twitter Bootstrap
Issue № 342

Building Twitter Bootstrap

A year-and-a-half ago, a small group of Twitter employees set out to improve our team’s internal analytical and administrative tools. After some early meetings around this one product, we set out with a higher ambition to create a toolkit for anyone to use within Twitter, and beyond. Thus, we set out to build a system that would help folks like us build new projects on top of it, and Bootstrap was conceived.

Article Continues Below

Made by myself and Jacob Thornton, Bootstrap is an open-source front-end toolkit created to help designers and developers quickly and efficiently build awesome stuff online. Our goal is to provide a refined, well-documented, and extensive library of flexible design components built with HTML, CSS, and JavaScript for others to build and innovate on. Today, it has grown to include dozens of components and has become the most popular project on GitHub with more than 13,000 watchers and 2,000 forks.

Here we’ll shed some light on how and why Bootstrap was made, the processes used to create it, and how it has grown as a design system.

Recognizing an opportunity#section2

Some of our early internal tools at Twitter lacked a refined and approachable design and we found it difficult to develop or iterate quickly. Folks from various teams recognized this problem and saw an amazing opportunity for this and future projects. Acknowledging this, we began to form a rough process by collaborating across Design and Engineering early on.

At a high level, our process began to look something like this:

  1. A few internal tools developers worked with product managers and the potential users of each tool to identify key functionality and features.
  2. I worked with developers to identify our needs and then design them in the browser to create a consistent visual language and explore interactions. After the first implementation, we debated each component and weighed other options and implementations carefully before moving on.
  3. After that, we designed and coded isolated components for the new internal tools project we originally set out to create. During this time, we quickly implemented, tested, and iterated each new feature.
  4. Lastly, as a follow-up, I took those same components from the internal tools project, and added them to a shared codebase (Bootstrap) to abstract and document them for other projects.

Ultimately this boiled down to one core concept: pairing designers with developers. Constant interaction with developers is what sparked Bootstrap and continues to drive its development over a year later. From whiteboarding ideas to coding rough prototypes, collaborating across disciplines is what made Bootstrap successful for internal use at Twitter. This process informed the development of nearly every feature in Bootstrap and has worked remarkably well over time.

Building Bootstrap in this way meant communication was key and most design work happened in code. Since the final deliverable for Bootstrap is always code, it made the most sense to work there as often as possible to communicate our ideas. This put one into the mindset of a good developer, encouraging succinct components, but with the visual polish and thoroughness one expects from a dedicated designer.

An example#section3

  Fig. 1

Fig. 1: Dropdown menus in the first release of Bootstrap were triggered on hover.

Let’s look at one feature of Bootstrap: dropdown menus. To help house information about the current session and bubble up other areas of the tool, we needed dropdowns. Everyone and their uncle has dropdown menus in their applications, each one with varying implementations, interactions, and visual design, so how would we do it? Following the outline above, here’s how the feature came to be in Bootstrap:

  1. We recognized we had too many navigation links and actions in the fixed topbar we were using; extensive, multi-level dropdowns seemed like a solution.
  2. We worked together to identify why so many links and actions needed to be there in the first place, and why we might need multi-level support.
  3. After some debate, we resolved to rearrange the topbar to remove some links and implement the dropdowns, but without multi-level support. At the time, they meant extra code that complicated our implementation and we wanted to avoid that.
  4. Next, we wrote the basic HTML and CSS for dropdowns on :hover. We refined the visual details within the tool’s codebase and then abstracted and documented them for Bootstrap.
  5. As one last step during abstraction to Bootstrap, we opted to have the behavior triggered on click rather than on hover. We found this helped avoid user confusion and accidental clicks, providing a better experience.

Most components and many of the finer details surrounding them were designed and built by pairing designers with developers. Together, our process for each new feature or design component matured to ideation, debate and feature review, implementation, and lastly abstraction and documentation. It made the development of our internal tools rather smooth, helped us avoid feature creep and code bloat, and helped us to document not only how to use a component but why you should use that particular component in Bootstrap.

This naturally extends beyond new features and into existing ones. Should a feature we already have need to be modified or removed, we follow the same steps: ideation, review, implementation, and documentation. Continuing the example, we have received a great deal of feedback around dropdowns and may revisit multi-level support. Since web applications are behaving increasingly more like desktop counterparts—which do use multi-level dropdowns—it makes sense that we consider supporting them. Sure—we could simply back out of our earlier decisions—but this process keeps us honest, relevant, and accountable to our users and their needs.

Parallel development#section4

Our process carried us through nearly all our feature development and highlighted an important aspect of our decision to go beyond building just one tool. Parallel development meant we had to effectively communicate our work to others who had no exposure to the processes or insights of our work.

While we were busy working to create a product roadmap and determine a single project’s goals, we actively considered how others would use the same component. Abstracting and documenting components became part of our process for building this one tool and Bootstrap in tandem. Overall, we saved time and effort, more clearly debated the value of adding (and on occasion removing) features, and set ourselves up for tackling much larger projects in the future.

After the first few weeks of development, we began to refer to this living document as “a toolkit built in style guide form.” This achieved our goal to communicate our work through Bootstrap, which allowed Bootstrap to quickly grow and become usable by anyone.

Bootstrap as a style guide#section5

The decision to create Bootstrap as a style guide came naturally out of our design and development process. Bootstrap helps us document components with live examples as we build them, while serving as a living document powered by itself, the very components and templates it prescribes. It gave us a single point of reference to share guidance from designers and created a set of documentation for each living component.

Building Bootstrap as a style guide affected its development early on. It kept us honest about the features we wanted to implement by helping us look beyond one project. We didn’t want to limit ourselves to designing a single project—we had higher ambitions and didn’t want to pigeonhole ourselves or those who could benefit from such a tool. Our approach ensured we didn’t just build tools for Twitter, but one that could be used by any designer or developer.

Cater to all skill levels#section6

The living document approach gave us a chance to not only share the entire toolkit, but to also provide written and interactive documentation to anyone who wants to use Bootstrap. This approach catered to those of us at all skill levels, allowing anyone to clone or download the repo for the source code or use the Inspector or view source in the browser.

As development progressed, this became one of the guiding principles of our work, one encapsulated by the credo, “Help awesome people do awesome stuff.” This dovetailed with our goal to clearly articulate design and development decisions to those who had no insight into the original process or product. No matter the skill level or workflow, we needed folks to be able to open this living document and be able to use Bootstrap to quickly and easily build something they love.

Evolving through collaboration#section7

In the beginning, Bootstrap only included typography, tables and forms, a color guide, and some graphical assets. It was a presentational best-practice guide for how to use some of our company-wide design rules. At the time, we only needed a more personalized CSS reset and company resources to add a small amount of flair to development.

  Fig. 1

Fig 2: One of the very first features of our toolkit was a go-to color guide.

As more folks and prospective applications became involved, more features were requested. Over time we ended up with many more components, including a fixed topbar, tabbed navigation, dropdown menus, extensive forms, and more. Throughout the entire process, the collaboration between designer and developer resulted in each new component being added. The collaboration made for many rewarding and exciting conversations and features.

  Fig. 3

Fig 3: Our initial release focused on supporting the latest browsers and included fewer components.

Today, Bootstrap includes dozens of components with many more planned, but only as their need and functionality are clearly identified using the process we established early on. Jacob and I iterate on the toolkit by managing feature requests and tracking issues and bugs. We work together to evaluate each new item to measure its usefulness to the community. We only implement a new feature if it doesn’t confuse users or unnecessarily inflate the framework. Having a process in place that allows folks to equally evaluate new features is incredibly powerful and necessary to the project. Our collaboration has extended well beyond the reach of a single project and into every one since then, especially Bootstrap.

Closing remarks#section8

Bootstrap had its first practical test in real-world use at Twitter’s first Hackweek. During the week, I helped a few folks use Bootstrap on their projects to speed up development, but had no idea how effective or widespread the toolkit would become. When all the teams got in front of the company to present their ideas, dozens of them were using Bootstrap. They had used Bootstrap to create projects that all felt like a family of ideas with a consistent design and implementation. A simple, well-designed, and documented toolkit saved countless hours with little to no help from a dedicated designer.

Put another way, it worked!

With the project now open-sourced and available to all on GitHub, our success continues as we help nerds everywhere accelerate their web development. Our development process for Bootstrap remains intact, but has evolved to make use of GitHub’s constant feedback cycle through issue tracking and wiki features to better communicate with those using the toolkit. Because of this, we’ve pushed out a number of releases and have more planned. Our next major release is v2, a larger effort to add a responsive grid system, extend the JavaScript plugins, close countless bugs, and improve our documentation.

Without parallel development and collaboration across teams, Bootstrap wouldn’t exist and we would have created another one-off tool. Internally, projects like Bootstrap began to change how we worked together. Questions began to change across teams from “make this look better” or “build this” to “how can we solve this problem”—and Bootstrap thrives on that. The collaborative process helped us work more efficiently and build a lot of trust among one other.

Thanks to the foresight and focus of a small group of designers and developers, we were able to evolve our development process, build an extensive front-end toolkit, and help thousands of others bootstrap the projects they love.

21 Reader Comments

  1. We’ve been working with Bootstrap since it first came out. Soon our new webapp (Richmetrics.com) will be released and it’s all based on Bootstrap. Heavily modified but still, the building blocks is in there. It’s been a pleasure to work with Bootstrap! Thanks for the insight.

  2. Great article, Bootstrap really takes things to the next level. I am interested to hear a little more about how you decided to include Less in the project. For myself, working with Sass allows an immense degree of flexibility that CSS just doesn’t provide for large frameworks. Bootstrap is pioneering these new styling systems and I am fascinated to see where this takes us. Like the leap to content management systems from HTML, will this be a leap to style management systems?

    Great stuff and thanks for writing and making Bootstrap open source!

  3. Mark, you’ve done a great job with Bootstrap. I absolutely love it. IT’s rejuvenated my development experience – I really am no designer, but Bootstrap has helped me to knock out some simple UIs for various projects and ideas – it really has been a joy to use.

    Thank you! And thanks for your support with Built With Bootstrap. It’s been amazing to see what hundreds of other developers and designers have been able to do with this brilliant toolkit.

  4. Mark I want to thank for putting all this together. Bootstrap helps us cut costs and speed product launch.

  5. erogers, if you take a look at the 2.0 branch on the Bootstrap Github repo you’ll see a bunch of responsive goodness. So it is coming, just not released quite yet.

  6. Thanks a ton for Twitter Bootstrap… I am now eagerly waiting for v 2.0… Is there any expected date of release?

  7. In the ALA Topics description for this article it says “Proper document markup. Separating structure from presentation and behavior.” I fail to see how any grid system separates structure from presentation. Markup such as class=”span6″ or class=”col_6″ are clearly presentational classnames.

  8. A great tool, just a quibble:

    > As one last step during abstraction to Bootstrap,
    > we opted to have the behavior triggered on click
    > rather than on hover

    Would be handy if the user gets to choose–messing with the JS source might not be advisable.

  9. We wasted soo much time designing our new site. Bootstrap means we can focus on functionality without having to worry about what it looks like. Our designer is happy. Our tech team love it. Its a great project. Thanks for sharing with the world. I will post link when we go live.

  10. This is just my sing up and would like to say hello to all of you. I think that I could make my contribution to this blog in the future.

  11. I was tasked to build or find a toolset that would create consistency within our app (www.3point5.com, http://www.promotive.com) that could span across different theming and it didn’t take long to find bootstrap paired with LESS CSS was the perfect solution for us.

    As we grow and more designers that don’t always get into the code as often but that do new feature mocks for the app I’ve found that having a PSD/Fireworks file for them to pull components from that match the bootstrap framework is useful. I took it upon myself to create one, with the help of @gradykelly’s firework template I converted it over to PSD and have started to refine it and provide it as a resource for our designers.

    // Twitter Bootstrap PSD Template
    If anyone here wishes that there was a PSD of the Twitter Bootstrap 2.0 toolset I’ve started one. Hopefully designers will find it useful. I’ll be improving it and trying to keep up with the geniuses over at twitter.

    http://www.bentdesignstudio.com/v2/2012/03/twitter-bootstrap-2-photoshop-template-psd/

  12. Bootstrap does a great job packaging everything an all in one toolkit. The only problem I have run into with using Bootstrap is that it is very CSS heavy. I found that on one website, I was actually using a third of the CSS that Bootstrap has by default.
    The kit itself, I think, would be great for individuals with less front end development experience as I feel more restricted when I have so many options to choose with JS without Bootstrap. Then again, there may be a project where I will be handing everything off to less knowledgeable customers who would not be able to make future changes easily without Bootstrap.

  13. Today most servers and browsers deal ascii content gzipped–css is repetitive and so compresses extremely well, therefore with most sites there hardly shouldn’t be a noticeable delay. I’m not sure about a possible delay due to more work for the browser’s rendering engine, though. If there is one, Google might detect and penalise it.

  14. I have only recently found Twitter Bootstrap and love it for developing the project core. So glad it was shared and OS!

  15. I think it’s great for prototyping your app. Before you’ll open photoshop you need to interact with interface, make some test with other people, so you can decide: is it good enough?

    After it could be taken final shape

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA