Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

Preparing Templates

Designing templates for a client to implement on their website can be tricky business. There is no way to plan for everything the template will be used for, so it’s best to be prepared with modular design, good documentation and comprehensive CSS.

A few weeks ago I published The New Generation of Clients, a piece detailing different trends in web design. The genesis of that article was the fact that I am now doing more templates than complete websites — a 3:1 ratio in fact. While this eliminates a lot of headaches attributed to traditional website projects (worrying about hosting, launch schedules, etc), it also introduces a host of new concerns.

First, by "template," I mean one core HTML page (sometimes two for a landing page / content page combination), two CSS files (one for screen display and one for printing) and any other necessary files like images of Javascripts. The HTML page contains dummy content, but the structure is developed to the highest level of detail possible.

Here is the issue with templates. You're delivering them to a client who's web-savvy enough to implement them but probably not artistically talented enough to create them. Most clients I know do not know CSS — the whole separation of content and structure idea hasn't permeated to the general masses yet. But they do understand HTML, and are able to adequately edit what you've given them.

To that end, templates should be simple and clear and easy to scale -- from a four page brochure site to a thousand page ecommerce site.

Finalize the Design

This seems like an obvious point, but beginning work on the markup before the design is approved can lead to annoying and costly delays. I adhere to a two-step approval process.

First, I deliver a simple wireframe that details the rough positioning of elements and the general scope and dimensions of a page, including content if it's available at that point. Once approved, I create the design in Photoshop based on the wireframe, so there are no big surprises once the comps are delivered. I don't even write the body tag in TopStyle until the design is completely approved, without question, in writing. I have had too many clients want to change the header graphic, bullet styles or navigation position well after I've begun the CSS, and it does nothing but grind the production process to a halt.

Simplify the Markup

Simplification of markup comes naturally to developers using standards-based processes. By nature, HTML is stripped to its core elements — headers, paragraphs, blockquotes, etc. Although tag soup has largely been eliminated with the removal of tables and depreciated tags, it is just as easy to clutter markup with unnecessary class and id calls. Keep the code clean by taking advantage of the cascade in CSS to target certain elements. For instance:

<div id="left">
  <ul id="mainnav">
    <li class="navlink"><a href="#">Link 1</a></li>
    <li class="navlink"><a href="#">Link 2</a></li>

This markup would have a stylesheet like this:

#left { styles; }
#mainnav {styles; }
.navlink {styles; }

However, the same could be accomplished through less cluttered HTML:

<div id="left">
    <li><a href="#">Link 1</a></li>
    <li><a href="#">Link 2</a></li>

And the more efficient stylesheet would use the cascade to target child elements:

#left { styles; }
#left ul {styles; }
#left ul li {styles; }

This is an elementary example, but complex pages quickly benefit from intelligent markup and thought-out stylesheets. The key is don't make the client think. They must be able to easily decipher what goes where (and why) and not worry about whether they need a certain class tag to accomplish a visual effect.

Most of my clients are amazed at the power of stylesheets. They expect to receive a dense maze of nested tables and are delighted to find they can focus on the content without struggling to decipher the layout. Which, of course, is the whole point of templates to begin with.


This plays off the previous point of simplifying the markup. Often, a template will need to adapt to different content environments. For instance, a three column layout with fixed widths might preclude certain wider elements, like large pictures or embedded movies, whose dimensions fall well beyond your design. Or, as was a recent case with one of my own clients, they might require a single page design whose color scheme can be swapped to six different versions — without having six different HTML pages.

The solution for both these examples is to provide a "toggle" in the body tag. Take the first example. The client needs two versions of the design: one with three columns that can be used for everyday content like text-based articles and one with two columns whose increased real estate can harbor larger elements like Flash movies or photographs. The body tag would look something like this:

<body id="threecolumn">


<body id="twocolumn">

The stylesheet would then use the cascade to define particular elements that fall inside that body tag. The CSS to toggle the layout style:

/* three column layout */
#threecolumn #leftcol { width:100px; float:left }
#threecolumn #middlecol { width:500px; float:left }
#threecolumn #rightcol { width:200px; float:left }

/* two column layout */
#twocolumn #leftcol { width:100px; float:left }
#twocolumn #middlecol { width:700px; float:left }
#twocolumn #rightcol { display:none }

This makes the entire design modular. The client need only change one small tag to alter the entire look of a page without mucking about tables or even the CSS. This idea extends into smaller elements of the page as well. For instance, a sub navigation might require two elements or ten elements, and your design better be prepared to handle both elegantly. They key is scalability and flexibility — you have no idea what the client is going to do with the template once it's out of your hands, so plan for things you couldn't possibly plan for.

Comment and Document

This is the most important point. Even the savviest clients are going to be baffled by your insanely long stylesheet and not understand why you placed the navigation inside an unordered list, or how you swapped that header's text for a graphic. The only way to effectively transfer this knowledge is to comment the hell out of both the HTML and CSS.

What seems obvious to you may be a totally foreign concept to someone not accustomed to standards-based design. Take the navigation example. It doesn't hurt to leave a trail of helpful notes. (Let the client be responsible for deleting the comments.)

<div id="left"> <-- this is the left column -->
  <ul> <-- this is the main navigation -->
    <li><a href="#">Link 1</a></li>
    <li><a href="#">Link 2</a></li>
</div> <-- closes #left -->

It also doesn't hurt to comment the CSS, especially if you're using some funky hacks or advanced techniques like image replacement. This is a sample from a recent stylesheet I sent with a template.

/* high pass filter for header -- please do not
edit unless you really know what you're doing */
#header h1 { /* this is the rule IE 5 and IE 5.5 get */

i{content:"\"/*"} /* do not remove */
#header h1 { /* this is the rule good browsers get, including IE 6 */

Be Comprehensive

Finally, a design is just a design. What you see in Photoshop works for the template but might not be comprehensive for all the site's requirements. In your stylesheet, you have probably made provisions for paragraphs — but also make sure you style ordered and unordered lists, definition lists, all header tags and even esoteric markup like <code> and <acronym>. It might also help to define the look of <strong> and <em>, just to avoid any possible browser nuances. The client might never use any of them, but if they do, at least they won't be trying to figure out why their definition list is being rendered in ugly black 12 pt Times New Roman.

commentary + criticism


wrote the following on Thursday July 7, 2005

Another great lesson, Thanks.

I liked the idea with the body tag, I never use add anything to it (bad memoies from onLoad I think)

Back to your first point there was a great guide posted at Juicy Studios about that called “div mania”

Chris K

wrote the following on Friday July 8, 2005

Its post like this that keep me from starting a blog. Great job. I’m finding clients that are becoming increasingly more web savvy and wanting to do their own updates. Because of that, I’m having to develop more templates along with creating a site design/redesign. This post helps me make sure I develop everything I need up front. Thanks.

Wesley Walser

wrote the following on Sunday July 10, 2005

Being a CS student commenting my codes is important, but in client it’s extremely beneficial for both them and myself. It’s always great to get to work with a client after several months away and be able to pick up your previous stuff quickly.