Frameworks for Designers

These days, “framework” is quite a buzzword in web development. With JavaScript frameworks like the Yahoo User Interface library, jQuery, and Prototype getting a lot of attention and web application frameworks like Rails and Django getting even more, it seems like everyone is using some kind of framework to build their sites. But what exactly is a framework? And are they only useful to programmers, or can we web designers benefit from the concept, as well?

What is a framework?#section2

So that we’re all on the same page, let’s agree—at least for the duration of this article—on this definition of “framework”: a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around. Generally speaking, this is the approach taken by the aforementioned JavaScript and web application frameworks.

To be clear, we’re not necessarily talking about something that is built, packaged, and released to the public. Rather, a framework may be solely for you or your team.

A framework for designers#section3

Chances are, you can benefit from a similar abstraction of CSS code for your web design process. Those who can benefit most are designers who work on several sites of a similar nature. Additionally, designers working on a team with other designers have a lot to gain from a framework approach. For example, I work for a newspaper company, and all of the 20+ sites in our stable have a lot in common. Simply by virtue of being news sites, they tend to be more similar than they are different. But, even a solo web designer who works on projects which are all quite different on the surface can probably find pieces that are suitable for abstraction into a general-purpose CSS framework.

At the Lawrence Journal-World, where I work, we’ve recently built a CSS framework and found it to be a huge efficiency booster. Sure, it took us a few days to create the framework itself, but once that was done, the speed at which we can put together quality page designs is tremendous. What’s more, since every designer on the team is now using the same framework, when one goes to make edits to another team member’s work, they don’t have to spend 20 minutes trying to understand why things were built the way they were. They can just dive right in.

What sorts of things can be abstracted?#section4

When you jump into putting together a CSS framework, you’ll want to look for things that you tend to do over and over again on every project. The goal is to consolidate these things into one central location, following the Don’t Repeat Yourself (DRY) coding methodology. This makes maintenance a lot easier, and can also save on bandwidth costs.

A few things I account for in the CSS of almost every single project I work on are:

• A “mass reset” of default browser styles. For example, setting margin and padding to 0 on all elements, turning off borders on framesets and images, etc.
• Aligning the type to a consistent baseline. This includes things like setting the margins on block level elements like paragraphs, headers, and lists to the same value as (or some multiple of) the base line-height setting for the site.
• Creating basic styles for forms.
• Creating a few CSS classes I always use, such as .hide (where I set the display value to none) and .mute (which I set to a smaller type size and sometimes a lighter color).

There are more interesting possibilities, too. Many web designers find themselves using the same basic grid structure over and over again. Why not move it into its own stylesheet and structure it in a way that is flexible enough to be used on multiple sites? Yahoo has done this, with their YUI grids component. When we built our CSS framework at the Journal-World, we looked at Yahoo’s implementation first. We decided it wasn’t quite what we wanted, but it served as a nice functional example and gave us lots of ideas on how to construct our own. We settled on a 16-unit grid, which is flexible enough that we should be able to use it on every one of our properties’ sites, even though every site looks and feels quite a bit different from the next.

Also, most sites share common widgets, like drop-down menus, navigation tabs, buttons, etc. These are prime candidates for abstraction, as well. Beyond that, you may have common content display idioms, such as a list of photos that appear as thumbnails. You could standardize on a CSS class name like “thumbnail-list,” so that all you need to do is add that class to get your thumbnails working.

Another possibility is to extract hacks and workarounds (such as those that accommodate older browsers) into their own external stylesheet modules. I’ve tried this myself, but found that ultimately hacks and workarounds tend to be too site-specific to pull out into a generic framework. But your mileage may vary.

What’s the real world benefit?#section5

The real beauty of having a framework like this is getting off to a fast start. You can create a new (X)HMTL document, include your framework, and be off to the races with reset padding and margins, good typography, clean forms, a layout grid, working widgets, and more.

Obviously, though, you’ll want to customize the look and feel for each site. To accomplish this, all you’ll need to do is overwrite and add to the default styles as necessary. For example, if your framework sets up basic-looking horizontal navigation tabs for any ul with the class “tabs,” and they are grey with a black border, you can easily customize them to match the look and feel of your site with just a few lines (Line wraps marked » —Ed.):

ul.tabs li {
  border: none;
  background-image: url('/images/tabs/ »
site-specific-tab-look.jpg');
}  

All the work of floating the list items the to the left and making the links inside them display as blocks (also floated to the left) with the text centered in the middle—ad nauseam—has already been done for you. You are left to focus on what is unique and interesting about the specific site you’re working on, rather than writing the same CSS you’ve written a million times before.

How should a CSS framework be built?#section6

There are several possible ways to go about building a framework, but the most common and arguably the most useful is to abstract your common CSS into individual stylesheets that each cover a particular part of the whole. For example, you may have a stylesheet that sets up the typography and another that handles the mass reset. The beauty of the approach is the ability to selectively include only the styles that you need. You may end up with six or seven different stylesheets in your framework, but if a particular project doesn’t need one or two of them, they don’t have to be included. The framework we created in our office has five stylesheets:

• reset.css—handles the mass reset.
• type.css—handles the typography.
• grid.css—handles the layout grid.
• widgets.css—handles widgets like tabs, drop-down menus, and “read more” buttons.
• base.css—includes all the other stylesheets, so that we only need to call base.css from our (X)HTML documents to use the entire framework.

We then store the framework in a single location and have every site pull it in from there. Then, of course, there are also site-specific stylesheets for each site which overwrite and add to the framework’s default as necessary.

A word of caution#section7

This method works quite well, but there is a valid concern to be raised: it adds to the number of HTTP connections needed to render each page. On large, high-traffic sites, adding five more HTTP connections to every page view may result in angry system administrators. Two possible solutions to this are:

1. Include everything in a single file, rather than breaking it into modules. The problem here is that you lose the ability to include only certain parts of the framework, and you also make maintenance more difficult.
2. Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well. Using my example framework above, this dynamic process could occur when base.css is requested, but not when type.css, grids.css, etc. are. This way, the individual components are still available, but the entire framework is available in a flattened version, as well.

In the end, it’s important to keep in mind that the goal isn’t making things as abstract as possible so that you can impress your friends. Rather, the goal is to get you off to a fast start and make your design process more efficient. It is definitely possible to over do it. If you abstract too much, things start to get confusing, and you end up hurting your website’s performance with too many HTTP requests.

Remember: a good framework should never make things harder or more complex than simply starting from scratch.

In conclusion#section8

The bottom line is that we web designers, just like our friends in the programming world, tend to repeat ourselves often. We find ourselves resetting the browser default styles, setting up a baseline grid and writing CSS for navigation tabs over and over again—on almost every project. Taking a bit of time out to abstract some of these idioms into a framework that you can utilize on every site you build will get you off to a faster start, make for easier maintenance, and help the other designers on your team understand the decisions you made. With a bit of care, these benefits can be realized without adding bloat or hurting the performance of a website.