Normally the whiteboards in the Clearleft office are monopolised by the designers, but just the other day, the front-end developers laid claim to some wall space for a quick’n’dirty exercise. We wanted to nail down the guiding principles behind our front-end work. All of us have a tacit shared understanding of where our priorities lie, but I thought it would be good to make it explicit.
After some scribbling on post-it notes slapped onto the wall, we were able to group our motivations into two categories: benefits for the user, and benefits for the developers.
The user-centric goals include:
- performance,
- accessibility, and
- device-agnosticism.
While the developer-centric goals include:
- maintainability,
- readability, and
- modularity.
Ideally, these goals can all be balanced, but when in doubt, favour the user’s interests over those of the developer.
As a result of articulating those driving principles, we were then able to also articulate the means by which we go about achieving those aims:
- use standards,
- apply progressive enhancement,
- use the right tools for the job,
- polyfill as a last resort, and
- loosely couple your pieces.
Those might sound pretty vague, but they then form the basis for setting expectations at the beginning of any project. So, for example, Mark is kicking off a project right now and drafted these design principles so that everyone is clear from the start on what will be delivered at the end:
- Core site content and functionality will available to all user agents.
- Less capable user agents get a simpler experience, more capable user agents get a richer experience.
- Missing or broken features in older user agents (e.g. media queries in IE8) will not be polyfilled unless deemed absolutely necessary.
- JavaScript will be used to enhance the site and provide a richer experience when it is supported/enabled, but will not be required for completing any tasks on the site.
Those principles articulate how our approach will benefit the end user. These principles articulate how our approach will benefit any developers working with our deliverables:
- The frontend code will consist of components and layouts, which can be assembled together to create pages.
- Wherever possible, specific page-level styling will be avoided in favour of layout or component modifiers.
- The code will follow a consistent style and format.
- The code will be suitably commented, and in-code comments will be favoured over documentation.
That still leaves lots of specifics to nail down:
- Which browsers will be explicitly tested?
- What kind of indentation will be used for the HTML, CSS, and JavaScript?
- Will any JavaScript libraries or CSS preprocessors be used?
The browser-testing question is one that needs to be answered on a project-by-project basis, based on all the available data. When it comes to coding style, we have our own preferences but those will take a back seat to the preferences of any developers who will be working with our code after we our work is done. Likewise, we might have our own preferences for libraries or preprocessors (if they are used at all) but our preferences are secondary to those of the developers taking delivery of our code. So those specific questions need to be asked anew for every project.
I’m a big fan of design principles—I’ve spoken about them at conferences and I’ve got a page of design principles I’ve collected from all sorts of projects—so it feels good to finally make a start on explicitly documenting our front-end design principles at Clearleft.