Categories

With Drew kind enough to let me write for 24 ways again, this year’s contribution was an opportunity to bring together a series of thoughts that had been languishing in my drafts folder. These centred around modular design, in particular the growing use of front-end style guides:

In straddling the realms of graphic design and programming, it’s the point at which they meet that I find most fascinating, with each discipline valuing the creation of effective systems, be they for communication or code efficiency. Front-end style guides live at this intersection, demonstrating both the modularity of code and the application of visual design.

I also wanted to write about the role CSS preprocessors can play in this context, one that ensures their use is more considered and focused. Such is the power of preprocessors like Sass, that without exercising restraint, we can find ourselves creating endless abstractions, with even the most fundamental aspects of CSS being drawn into the mixin. Much like jQuery (and frameworks like Bootstrap and Foundation), we can find ourselves growing dependent on such tools, to the extent that simpler, more effective alternatives get ignored.

Thinking of Sass an an intermediary between CSS and a visual language, is one way I try to keep my reliance in check: if you see a mixin or variable in my CSS, it should relate to an attribute in my design system.

So, I end this year much like I did the last, with one final article on a topic of interest. Unlike last year, I’m looking towards a new year that sees me write less long-form pieces like this. Instead, I wish to spend more time making things (my list of abandoned/neglected/potential side projects can only grow so long), and perhaps embracing a means of writing that’s a little more fast and loose.

My contribution to this year’s 24 ways attempts to tackle one of the most difficult aspects of web development, naming things:

Working in-house may mean working with multiple developers, perhaps in distributed teams, who are all committing changes – possibly to a significant codebase – at the same time. Left unchecked, this codebase can become unwieldy. Coding conventions ensure everyone can contribute, and help build a product that works as a coherent whole.

Even on smaller projects, perhaps working within an agency or by yourself, at some point the resulting product will need to be handed over to a third party. It’s sensible, therefore, to ensure that your code can be understood by those who’ll eventually take ownership of it.

Put simply, code is read more often than it is written or changed. A consistent and predictable naming scheme can make code easier for other developers to understand, improve and maintain…

This is the fourth successive year I’ve been involved with 24 ways (including last year’s redesign), although this article rounds out a year in which I have been deliberately quiet in terms of writing and speaking. I don’t intend for that to be the case in 2015.