The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.

Elements and Outline

My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the `` tag.

Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:

This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.

Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.

I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.

It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.

Layout and Style

Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.

My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.

Ok, one more code example:

body {} h1, h2, h3, h4, h5, h6 {} a:link {} a:visited {} a:hover {} #header {} #header h1 {} #navigation {} #navigation ul {} #navigation ul li {} #articles {} #articles h2 {} #articles div.article {} #articles div.article h2 {} #theblog {} #theblog h2 {} #theworld {} #theworld h2 {} #theworld ul {} #theworld ul li {} #footer {}

One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.

But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.

As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.

Building Templates

Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.

See how easy that is?

Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.

Starting Out

I love this process, but there is one thing you really need for it to go smoothly:

You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)

One final thought: use comments. Any time I create a div, I wrap it in comments like this:

I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.

I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.

Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?