The Style Template schema
When you need to create detailed specifications for how a site should be constructed, you need a fairly detailed template schema. When this is the case, I use something I call the Style Template schema. It is made of three elements: templates, style templates and modules. Here’s how I define each of those elements:
A template:
- is something that graphic designers can refer to when creating a designed template.
- is something that developers can refer to when writing the HTML, CSS and JavaScript.
- should be reusable for the creation of multiple pages across the site.
- should have a default style template. If no default is specified, the template doubles as a style template.
A module (for example, a table showing teams and their scores):
- is unique. Separate modules should be created for all unique presentations of content.
- can be combined with other modules on a style template to specify a unique page.
- doesn’t have to be specified outside of a style template. For certain projects, there is no need to create a separate document detailing the specifics of modules. Simply including them on a style template is generally sufficient in these cases. can exist on multiple style templates.
A style template (for example, a content table style template):
- is something that graphic designers can refer to when creating a designed template
- is something that developers can refer to when writing the HTML, CSS and JavaScript
- is related to a specific template.
- shows how modules are presented on templates. For example, if “landing page” is a template, a landing page table style template should show how tables are presented on landing pages.
- should be reusable for the creation of different pages across the site. (You don’t need to create a style template for every page with a table but you should create a style template for each template that presents tables differently.)
So why do I use style templates? A single template can contain different combinations of modules but the different treatment of those modules is not always inherent in the template. Many would just create a new template for this purpose but I find it quite useful to know how templates relate to each other and style templates make this somewhat easier by forming a template hierarchy.
Most high-level templates (homepage, first level templates) don’t have style templates, so practically speaking, style templates can be put to the side on these occasions. Where style templates really come into play are on content pages, the pages that have to fit content of every shape and size. Consider the following two examples for a practical explanation.
Example #1. Landing page is a template. Sign up form and table are modules. The landing page template shows how typical landing pages are laid out. The landing page table style template shows how tables are presented on landing pages. Similarly, the landing page signup form style template shows how signup forms are presented on landing pages.
Example #2. Content page is a template. A-Z navigation is a module. The content page template shows how typical plain content pages are laid out. The content page glossary style template shows how the A-Z navigation is presented on glossary pages. The content page address style template shows how the A-Z navigation is presented on address pages.
As a further example, here’s a short template specification that includes four templates (T), three style templates (ST) and three modules (form, table and large image).
T1 Homepage
T2 Level one
T3 Level two
T4 Content
ST4.1 Content form style
ST4.2 Content table style
ST4.3 Content large image style
I’d love to hear your thoughts and feedback on this schema or how you work with templates and modules in your everyday IA work.
- 29 Jul 06
- information architecture, web design
