CannyBill design process, package contents

Back in July (after the @media conference) Simon Collison wrote about his Ultimate Package™ (no sniggering please). As Simon said.

Without question or compromise, every website needs to be built with a solid foundation layer and an Ultimate Package.

With an uncanny ability to make sense, Simon outlined Erskine's conventions and convinced me to adapt my own starting files to the way that Erskine work.

A bumper compendium of cascading and connected CSS files, naming conventions, modules, plugins and library scripts that ensure any project will stay on convention and be simpler for anyone to step into and work with at any time.

On top of this, I have found that developing my own package of conventions and library items makes designing in a browser as easy, I would argue easier, than plugging in a third-party framework like 960gs or Baseline. So what is stuffed into my package?

Package contents

There are only so many ways to express content in HTML, so I developed several files that bring together our own naming conventions and Microformats that act as a starting point for common content types including;

• hAtom formatted news and blog entries, category and index pages
• Forms for various purposes
• hCalendar formatted date in tables and lists
• Tabular data of various kinds
• hListing formatted lists of products or other items

Over the last few iterations, I updated these files from XHTML1.0 to HTML5 so that (unless a client specifies otherwise) all our projects going forward will be written in HTML5. The attribute values I chose for elements in these templates always come from Microformats. Where I needed to extend these attributes, rather than starting from scratch I used Microformats as a basis for coming up with values such as entry-caption and entry-extended.

Assets

All of the assets that we need for a project are kept inside an assets folder that includes CSS files (more on those in just a moment), images (content images and UI), scripts and typefaces that we use for @font-face embedding.

Scripts

I keep a library of up-to-date scripts for designing. These are mostly replaced by hosted (so hopefully cached) versions when a site goes live. Using jQuery is a no-brainer, but what about Modernizr? I can't stress how important Modernizr is. It has taken designing alternatives for browsers' natural differences and implementations of CSS properties to a whole new level. It is now the cornerstone of my approach to using HTML5 and CSS.

Images

Recently I've found that separating images into folders can help enormously while designing and especially when we get ready to hand over the finished project. A temporary folder keeps placeholder and stock images separate and over the months I have built several sets of placeholder images, each with dimensions overlaid. I also store a selection of grid layout images to use as background images to make designing with CSS easier. I also keep UI icons from my favourite set tucked away in the UI folder.

CSS

The way that we structure our CSS files has changed most over the years as our ideas changed. Recently I brought our CSS structure inline with Erskine Design because, for one thing, they have great ideas and it makes the times that we collaborate with them easier. In particular, using a scratch CSS file for everyone involved makes perfect sense as it acts a place where everyone can experiment with styles before they are committed to the main, screen stylesheet. These stylesheets and others make good use of @import and the cascade to allow us to add new files without having to edit the list of linked files from every HTML document.

This set of files makes it incredibly fast and easy for me to go from rough sketches, PostIts and meeting notes to HTML and CSS. Best of all, because I never start off knowing that my markup and CSS might be scrapped later (as I would have to do if I used a third-party framework), almost 100% of the code that I write while designing makes it to the finished site. For me, running a small design business, this is hugely important. I can only imagine how, done in the right way, this process could help larger teams in larger organisations.

Will I share our package contents? I don't think so, although if you dig deep enough throughout the CannyBill redesign you'll get your hands on most of it. I don't want to share the package as a whole because I think that it is hugely important that you develop your own package of files and conventions that make sense to your projects, clients and working process. Using our package instead of your own would be no better than settling for a third-party CSS framework and all that goes with that.

Everything in our package has been built upon what we have learned from everyone else, from Eric Meyer's reset and print CSS to Dan Cederholm's grouping of elements to clear floats and onto the Erskine chaps' scratch system.

These are the files and structure that I am using for the current CannyBill redesign and all of our projects going forward. I'd be interested in hearing if you have developed your own package and what you have stuffed into it.