Is Twitter Bootstrap good for all projects and teams?

Twitter Bootstrap is a good idea but not all teams will benefit from using it. TB is great for small teams and startups that do not have a designer or a front-end guy on board. If that’s the case I highly recommend using it.

For teams that have an experienced front-end person then TB could actually hold you back. I have been using TB now for 2 months and the cracks are starting to show. The idea behind this framework is a good one, its very convenient for me as a front-end developer to be able to point other team members to the TB site and tell them to use the patterns that are already their, ready to use.

Using a framework means that you are always confined within that framework and the how that framework solves problems. When I started to use TB one of the first things I wanted to do was offsetting or pushing a column in a fluid layout. Turns out TB only supports push and pull on fixed layout. The project I am working on required high levels of customization. We have already build custom UI widgets that are missing from TB (No framework can solve all problems) and our customers also need to be able to customize the colors of the app. Turns out many of the colors in TB are hard-coded for some strange reason.

For me the drawbacks simply outweigh the benefits, but I do recommend TB for quickly prototyping new ideas and specially for teams that do not have a front-end developer.

CSS frameworks can hurt usability and slow you down

I was faced with a tough question today. My boss wants me to redo everything I have built for the last few weeks using Twitter Bootstrap. Now I have nothing against TB as a framework, specially for teams that do not have a dedicated front-end programmer. But for teams that have one and that person is also the designer, forcing him to use a 3rd party framework can have some negative drawbacks.

Frameworks can be good to quickly prototype new features in HTML. But like someone pointed out, a framework can never solve all user-interface problems because no two sites have the same requirements and problems. New problems require new components and a new solutions. Trying to shoehorn a framework like this into your app can hurt usability, specially if you do not take the time to customize and write your own solutions on top.

If your website is highly specialized, using Twitter Bootstrap might have very little benefit. Specially if you are a front-end developer yourself. A better solution is often to copy other solutions and build your own set of custom tools and components that fit the design you are working with. This approach will give you a productivity boost as you are working with your own code. Not to mention if you are already using LESS or other compiled languages, making your own custom framework is easier then ever and if you are like me, its also a lot of fun!

Introducing Fluidable: A fluid/liquid CSS grid system

Since I started making responsive sites, I have been building a fluid grid system that fits my needs as a designer and a developer. Since there aren’t NEARLY enough CSS grid systems out there, I decided to write some documentation and put the code up on Github.

Fluidable works on IE7+ and is built using LESS. It has fixed gutters set in ems and can do nested columns. It also has basic media queries built-in for mobile devices.

Fluidable CSS Grid System

Responsive Design: Why use a fluid layout?

When developing a responsive web site, one of the first decisions one has to make is whether to use a fixed (pixel/em) or a fluid percentage based layout. As a developer and a designer, a fluid layout can offer a robust and flexible way when building responsive web sites. Here are a few reasons to go fluid:

  • Fluid layout can help you future proof your design, making your site adaptable to new devices. With new phones and devices coming out every week, new resolutions are being introduced faster than before. 
  • Unless you are using a very smart compiled CSS solution, fluid layouts are more flexible and easier to change and update than fixed layouts. Changing the width of your site can be as easy as modifying the max-width rule for your site’s container.
  • There are indicators that fluid layout saved considerable time on development. Because of the proportional nature of fluid layouts, you do not have to recalculate grid columns for each break point in your site.
  • With media queries you can optimize readability for your users. A fluid layout has been thought to hurt readability because of long text lines on large screens.  Using the benefits of responsive design you can turn that around.

Responsive design is still very new, and developers are working to find solutions to the problems that have arisen. But it’s not all problems, however; responsive design can also be a great opportunity to advance the web in a new environment, given that users are increasingly consuming the web on mobile phones and tablets.

Requirements for a responsive CSS framework

I have been working on a CSS framework for using when building responsive web sites. In the process, I have been thinking about the requirements for such a framework. Here is a list that I am following:

  • Moible first: Mobile devices should only load the needed CSS, and nothing more, to optimize bandwidth usage.
  • Fluid/Liquid layout: No questions about it, responsive sites have to be percentage based all the way. Doing it with pixels is simply not practical.
  • Fixed/Elastic gutters: Design above technical perfection. Designers want the gutters to be proportional to the content and not the screen size. This is why the gutters should be defined in ems.
  • Simple and flexible: I decided not to make guesses about how developers would be using my grid system, but instead, tried to make it flexible and usable for as many styles of web sites as possible.
  • Stand-alone: Focus on the grid system and layout aspect, and not reinvent things already been solved, such as reset styles and mixing (although those things might be nice to have as an optional download).
  • Compiled CSS: I think most developers should be using some version of a compiled CSS language by now. If anything else, it really does speed up the development process.