Highly leveraged
Generally speaking, templates help separate website content from presentation. Design templates are where the information architecture of a website is realized. Templates are applied to groups of pages, sometimes hundreds of pages at a time. This means that mistakes in template design are quickly magnified throughout whole sections of a website. No longer are designers working on a specific page, they are now working with a powerful "lever" to affect design changes. In other words, best be careful.

Does the 80/20 rule apply?
Consider the following platform statistics from calendar year 2002. These come from a college website that received 1.8 million pageviews in 2002:

Platform      Sessions
--------      -------- 
Windows        330,237 
Macintosh       17,492

It would be easy to focus your design and testing efforts on the Windows platform, but what about the 17,000 Macintosh sessions? Should the client ignore that platform because it's only 5% of the usage? If so, what do you say to a prospective student interested in a graphic design major? This person probably uses a Macintosh, all the classes are taught on a Macintosh, and virtually every newspaper, magazine and long-format publication is created on Macintosh. Ignore testing on the Mac platform and you will ignore whole swaths of prospective students, media, and parents. Each organization needs to determine its audience interests, but in this case the college cannot avoid the Macintosh. The 80/20 rule does not always apply.

Do you want to build a testing lab?
You must be careful in browser testing &mdash: the new template may appear fine in your limited review, but hundreds or thousands of visitors may see bizarre and inconsistent layouts in their browsers on their computers. If someone has the courtesy to call or email, then you will find out about the problem, but in many cases the average web surfer has little or no incentive to inform you of the problem and the site could go for months with major problems. How will you approach the template testing process?

Consider the variety of browsers on the Windows platform. Again, these statistics are from the same college website, calendar year 2002:

Browser                  Sessions 
-------                  -------- 
Internet Explorer  6.0    113,752 
Internet Explorer  5.5    113,355 
Internet Explorer  5.0     57,242 
Internet Explorer  5.01    26,688 
Netscape  6.0              15,259 
Internet Explorer  4.01     8,879 
Netscape  4.0               3,860 
Netscape  4.7               2,838 
Netscape  4.75              2,274 
Netscape  4.73              1,547 
Netscape  4.77              1,542 
Netscape  4.76              1,477 
Netscape  4.79              1,405 
Netscape  4.5               1,254 
Netscape  7.0               1,218 
Netscape  4.78              1,217 
Netscape  2.0               1,201 
Netscape  6.2.1             1,106 
Netscape  4.61              1,005 
Netscape  4.08                838 
Netscape  3.0                 821

It's almost unbelievable that in 2002 there were 821 sessions (each 30 minutes or greater) that used Netscape 3.0. Many people stopped testing for Netscape 3.0 in 2000, but there it is. Netscape 2.0 from the early days of October 1995 has even greater use! Where do you draw the line? Certainly you have to test most of the versions of Internet Explorer listed above. We know from experience that the HTML rendering engines in Explorer 4, 5 and 6 are different — each with different bugs. Every web designer wishes that the old and buggy Netscape browsers would just go away, but there are thousands of sessions using those browsers. How do you test for them all?A reasonable test plan would have up to three windows machines, each with different browsers and operating systems, and up to three Macintosh machines each with different browsers and operating systems. It might take several hours to fully qualify a template across reasonable combinations of browsers and platforms. Typically you will test several times during the design iteration process, since if your fundamental idea for the design is difficult to implement then it may not work, ever. After a template is qualified on these systems, you can handle other browser problems by exception. Someone says they have a problem, you can ask for a screenshot, examine the code and fix it, or sometimes, live dangerously and decide it's not worth fixing.

WYSIWYG, sometimes
Design tools like Macromedia Dreamweaver, Adobe GoLive and Microsoft FrontPage can help, but they do not solve the problem. You can more quickly design a broken template in Dreamweaver than by hand. Do not be lulled into a false sense of security that these mass-market tools will unify the differences of browser rendering engines, to say nothing of working around the bugs and lack of standards compliance. They are a great assistance, but they do not solve the problem.

Data-driven content
The biggest challenge in designing templates for content management systems is that you don't know what the page content is. That is, you're designing for a page that could be very wide (or narrow) and very long (or short). You never know. Further, the same template might be used for both long and short pages. Many designers are thrown off by the idea that they don't know what the content will be, and might initially have a hard time designing the template framework with a huge hole in the middle of the page.Fear not. The main idea is that the table structure, or the CSS structure, must account for variable width and height content data. This means thinking in advance about which elements of your table structure will stretch and shrink to accommodate the variable content. You might center photos in the left column of a normal page, but you don't want them moving up and down if the page length changes. Likewise, the design of the masthead or banner at the top of the page must stretch or shrink horizontally. Consider that certain cells in your table layouts will be specified with percentages, not fixed widths, but other cells might be fixed in place. Design spacer cells that can be narrow or wide and lock down the other elements in place. This is advanced HTML and the best way to learn the tricks of the trade is to wade in a start learning.

Should you build or buy templates?
There are both implicit and explicit reasons you might choose to outsource template design and production, including:

• Professionally trained and highly experienced designers
• Maintaining the organizational "brand identity"
• Maintaining a consistent look and feel across website sections
• Expertise in cross-platform and cross-browser testing
• Experience with data-driven website design
• Core competency in careful, minimalist, hand-coded HTML
• Avoiding internal friction in decision-making
• Retaining institutional knowledge when staff turnover occurs
• Focusing internal resources on the core mission

The build versus buy question is best decided through evaluation of multiple considerations — it is not fundamentally a technical decision. For example, it is possible for an internal employee with limited experience, or perhaps an employee with great experience but infrequent use, to break large sections of a website with a single small typo. Beyond basic functionality there are the issues mentioned above regarding consistency and design style. If this is a core competency of the organization then you will have no problem generating good-looking templates. If you have traditionally relied on outside resources for professional design then new content management capabilities shouldn't necessarily change that approach.

Recommendations

• Be thoughtful when designing and implementing new templates. Think about your table layout structure in advance and consider its complexity. Make a sketch on paper and determine column widths by hand. Figure outwhich columns will be fixed in place and which will expand or contract for different browser windows and different page content.
• Start to move toward using stylesheets for your designs so that you can standardize typical page elements and styles.
• Test your template design with several types of page content. Create a dummy page that has, for instance, lots of lengthy text, or another page with a single huge image that explodes the design in width and height. Place a wide table-based schedule on a page and see how it looks in your design.
• Test technically not only on the machine at hand, but on many other combinations of browsers and platforms. Send an email and ask friends and colleagues to send you a screenshot — they may not know what problems to look for, but you can easily compare screenshots to your design intent.
• Leave enough time before your deadline to spend a day or two fixing something that might be broken in an obscure manner. Don't try to design templates at the last minute, or under extreme deadline pressure. Better to design a single page and then convert it to a template later.
• Roll out your new template on a couple of pages before applying it to whole site sections. Wait a few days for feedback. Test some more.
• Whenever a browser manufacturer ships a new version, test it all again. Review your browser statistics annually and revise your testing plans accordingly.

In other words, measure twice and cut once.