« Homepage
The Process Toolbox, part seven: Convention
31/07/09
Simon Collison
After a short break, I’m back with part seven of The Process Toolbox, a transcript of my @Media presentation. Having dealt with inspiring creativity in the last installment, I’m moving on to conventions and flexibility. Without question or compromise, every website needs to be built with a solid foundation layer and an Ultimate Package.
Quality Control & Assurance
It can be beneficial to identify members of the 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, any of us 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 use comments to clearly define meta data and links to external files in a set order. We use conditional comments to always prepare for serving alternate CSS to IE versions. There are many conventions on view here.
In our main CSS file, we 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 import our own reset.css here – so we all know that browser defaults are turned off on all projects.
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.
The Ultimate Package
Over the last two and a half years, we at Erskine have worked together to develop a base layer of rules and conventions that act as starting points for HTML, CSS, JavaScript and ExpressionEngine for our own projects. It’s 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 the team will stay on convention, and be simpler for anyone else to step into and work with at any time. This includes:
- 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 are made – we’re currently on version 1.9 – and it’s available internally on our systems with a changelog, meaning anyone can use it as a starting point for both agency and personal projects.
We’re constantly considering HTML, CSS, browsers, JavaScript, naming conventions, CMS usage and any improvements in general methods or implementations. It isn’t publicly available because it is ours – bespoke, custom, built especially for our purposes suiting our 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. he is also responsible for the label Ultimate Package. Good work.
Further reading
Simon Collison published this at 14:56 on 31/07/09
