55 Minutes

Welcome to the 55 Minutes blog.
55 Minutes is a web development consultancy in San Francisco building apps for design-led businesses and startups. On this blog we discuss the technology tools of our trade: Ruby on Rails, Django, Sass, OS X, and more.

How We Bootstrap Responsive Web Designs

In which we explain our design process and how it incorporates responsive web design.

Here at 55 Minutes, we spend a lot of time studying the latest and best practices in web design, constantly striving to improve our development process. Over the years of learning and experimentation, we’ve collected a set of best practices, conveniences and quick-starts that we use in our everyday work, and which we’ve distributed as a series of open source projects.

One of these, the cornerstone of all our projects, is our CSS3/HTML5 foundation. This quick-start contains all the (to our minds) necessary building blocks for static sites of applications:

File organization

In addition to incorporating these best practices and recommendations, we spent some time fine-tuning the code writing and organization process. Over the years, one of the biggest challenges our team has faced has been maintaining styles for large and growing projects. Sure, it’s not so bad when there’s just one HTML/CSS developer, but code organization that makes sense to the original author is not necessarily obvious to another developer who only needs to alter CSS piecemeal.

How could we organize the code in such a way that it’s intuitive to every developer, regardless of how often she touches the CSS, where to look for a style definition she needs to alter? After trying several different organization schemes, what we eventually agreed on is below.

We’ve copiously commented our code, so please refer to individual source files for detailed information on what should be included there. In the meantime, here are some general guidelines for file organization:

styles/
  basics/
  shared/
styles-compiled/
scripts/
  lib/
css3-foundation-01.txt – View Gist

CSS rule organization

But file organization does not solve the problem entirely. A single CSS rule set can quickly grow large and unwieldy, so to promote ease of reading and maintenance, we recommend following a prescribed order for writing your CSS rules.

Some teams alphabetize all the rules, but I find that, though alphabetic sorting makes reading easier, it doesn’t suit the way I think when I’m authoring CSS. The way I prefer to work, and the way we organize rules in the CSS3 foundation, moves from the outside in, from layout to text:

selector
{
  /* Display and positioning */
  display: ;
  visibility: ;
  position: ;
  top: ;
  right: ;
  bottom: ;
  left: ;
  z-index: ;
  clear: ;
  float: ;

  /* Transforms and animations */
  transform: ;
  animation: ;
  transition: ;

  /* Box model/layout */
  box-*: ;
  margin: ;
  outline: ;
  border: ;
  padding: ;
  width: ;
  min-width: ;
  max-width: ;
  height: ;
  min-height: ;
  max-height: ;
  overflow: ;
  clip: ;
  resize: ;
  table-layout: ;

  /* Alignment */
  vertical-align: ;
  text-align: ;

  /* Background/foreground color */
  background: ;
  color: ;
  opacity: ;

  /* Text properties */
  font-family: ;
  font-size: ;
  line-height: ;
  direction: ;
  font-style: ;
  font-variant
  text-decoration: ;
  text-indent: ;
  text-transform: ;
  letter-spacing: ;
  word-spacing: ;
  word-break: ;
  word-wrap: ;
  quotes: ;
  page-break-*: ;
  list-style: ;
  white-space: ;
}
css3-foundation-02.css – View Gist

It should have become clear by now, by the way, that our CSS coding standard is that the open brace is on a line by itself, and rules are also written one-per-line. There’s no reason to do multiple rules in one line when the Compass compiler can strip the whitespace for us through a configuration option.

Other best practices

Here are some other policies we follow/tools we use when writing our styles:

How this all fits into our design process

The coding conventions and best practices I’ve defined above are just part of our design process. Here’s a rough outline of how we typically work the design and early UI-development phases:

Wrapping up

We spent quite a few years and tried a quite a few things to arrive at this set of principles, but we feel we have a solid, reusable base upon which to build our current and future projects.

Fortunately, you won’t have to spend years to be able to take advantage of these tools. To get started, just get the code from Github and follow the instructions in the README. Play with it and see where it takes you!

comments powered by Disqus