22nd March, 2010

Process Toolbox, part seven: Convention

Here’s part seven of The Process Toolbox, a transcript of my @Media presentation. Having dealt with inspiring creativity in the last instalment, I’m moving on to conventions and flexibility. Without question or compromise, every website needs to be built with a solid foundation layer - a reusable package.

Quality control

Quality Control & Assurance

It can be beneficial to identify members of a team who will be responsible for quality-controlling certain areas throughout the project - such as a CSS lead, a CMS lead etc. This puts responsibility in the hands of members of the team, and they then develop the ideas and establish agency-specific conventions. Naturally, anyone can contribute ideas or suggestions at any time, but it’s good to have someone fostering your CSS and making sure it’s as good as it can be prior to any releases.

On Convention

We all understand the importance of semantic naming conventions; of the stylesheet cascade, of JavaScript frameworks and unobtrusive implementation; of choosing a way of writing code and sticking to it. There are many different ways of doing many different things. My naming conventions might differ from yours, and my way of ordering my CSS might clash with your own.

This can be taken a step forward and given clarity by setting out a suite of files and resources that kick-start any build, whether final product, prototype etc. You can call it a framework if you wish, but I don’t. Anyway, there are good reasons for working in this way:

  • Allows better collaboration within the team; the designer can jump into the developer’s code and vice-versa.
  • Anyone who hasn’t even worked on a certain project can jump in and quickly solve problems because everything is on convention.
  • Keeps output fresh and ensures use of best practices.
  • Establishes a thoroughly connected layer of base files allowing for swift CSS and JavaScript implementation and other assets.

HTML and CSS examples

For example, in the head element of our web pages, we can use comments to clearly define meta data and links to external files in a set order. We can use conditional comments to always prepare for serving alternate CSS to IE versions. There are many more bits and pieces to include by default (view source on this site).

In the main CSS file, we can add a Table Of Contents as we build, making it easy for anyone to quickly find a chunk of CSS. That TOC is in place from the start, so the designer can simply begin adding to it. Note also that we can import our own reset.css here - so we all know that browser defaults are turned off on all projects.

Shared approaches to CSS syntax

Finally, we all approach writing CSS in the same way, in our case single lines for each selector. Not everyone likes to do it the way we do, but we are happy. So, its become a convention, right down to the spaces between rules and brackets.

A reusable package

It pays to develop a base layer of rules and conventions that act as starting points for HTML, CSS, JavaScript and ExpressionEngine for your own projects. Think of it as a bumper compendium of cascading and connected CSS files, naming conventions, modules, plugins and library scripts that ensure any project led or worked on by any member(s) of a team will stay on convention, and be simpler for anyone else to step into and work with at any time. This could include:

  • Basic HTML files & naming conventions
  • CSS: Stylesheets, IE-specific, reset, scratch files.
  • JavaScript: jquery, function file, transparency support
  • PHP for basic templating prior to CMS integration.
  • Other Assets such as set folder names for images and CMS stuff
  • Essential CMS set-up procedures, plugins, modules etc

Constant iterations of the package should be made, and it should be made available internally with a changelog, meaning anyone can use it as a starting point for any projects.

It’s important to constantly consider HTML, CSS, browsers, JavaScript, naming conventions, CMS usage and any improvements in general methods or implementations. My package isn’t publicly available because it is mine - bespoke, custom, built especially for my purposes suiting my needs. If you like the idea and general approach, you’d do worse than to build your own constantly evolving package.

Note: Slides designed by Gregory Wood.

Full series…

This article was originally posted on Erskine Labs, September 2009.

Prev / Next


If you enjoyed this article, please subscribe to my Internet of Natural Things letter, and maybe grab the RSS feed. Thank you.