Naming stuff is hard at the best of times. Babies for example. To paraphrase David Mitchell – ‘However original or unique you think you’re being when you’re naming a child – after a few times, that just becomes the label for how to identify them from everybody else’. But I digress…
For the most part when we’re writing HTML we have either convention, or set roles to work with. A header for example, is very clear. It’s meaning isn’t likely to change, neither is it’s purpose. Therefore, naming a class .header isn’t likely to cause much issue down the road.
Colour however; Is a bit more difficult
At fffunction, we’ve been designing in live code and pattern libraries almost exclusively for the last two years, and in that time we’ve taken a few runs at how to do this.
What we are aiming to achieve here is a naming pattern that is obscure enough to adapt to change (e.g a colour that was once red, is now blue), but isn’t so abstract that is has no real value in and of itself (e.g for use as part of brand guidelines).
One thought (and one that is, in part, still useful in conjunction with my preferred method) was to abstract around roles.
As you can imagine, this on it’s own doesn’t really stand up too well, as you soon run into shared colourings that then semantically don’t make sense. So perhaps you have the need for blue links, not red, you’d need to assign the link a colour of $headings, which semantically makes little sense.
The first real idea was to use some kind of hierarchy, that hinged from an initial primary brand colour, a bit like so:
The problem with this approach was that clients seemed to get hung up on the names, and their order. They’d ask us to change the assignments and move colours around. And on reflection, these were quite valid concerns. As part of our pattern library contains a digital style guide – and can be used outside of the web’s context – having implied hierarchy might solve the problem of future-proof naming, but it doesn’t solve the full issue of brand control.
The method has some legs, and works much like the above, but with a simple shift in naming convention to use figures or letters:
This has less (or, arguably no) hierarchy, and didn’t confuse clients like the previous example. However, where I find this method falls down is when you have many colours, or shades. For example, if you have 3 blue colours, it would make sense to list them together like:
The problem here is, if you end up with lots of colours, and you’ve sensibly grouped shades together, then you need to change an assignment totally, or add more to that group, you end up with colour scattered around a set of variables that are too obscure to keep some track of. This means that you basically need to keep the list of variables open to reference them all the time – which is fine – but I find that too obscure, as there’s no meaning at all.
What I’ve found works quite well, is to almost take the Dulux approach (which I assume, when you make that much paint, you solve as a matter of course). What I mean is, using a name that can imply a colour without describing it.
To put that another way, if you can find a naming convention when you’re setting colours for a design that has some meaning to you – and you can, by way of your design, impart association with that colour and that name onto your client – you get gain some control over what that colour means. Crucially though, because you’re building association, you’re not bringing pre-conceptions to the table.
However, finding a way to name a colour, so that it makes sense to you, and can in turn can be reference-able and become part of a clients brand language, can be tricky. One method that works for me is to find a reference point that already exists. So perhaps you could root your references in TV show characters (no smurfs though), Rocks (they’re minerals, Marie), Formula one teams or album artwork, that could unlock the key to finding a good naming system.
I find, reaching into popular culture allows you extract or impart meaning without bringing with it established preconceptions about how something might look. This isn’t always the case of course, but it’s a method I find works for me.
Below I’ve listed some examples:
What’s also really nice about this, is you can now combine this approach, with the ‘Abstracting using roles’ approach, and you have the best of both worlds. For example, I can have assigned:
Which gives me role assigned colour variables, but without the problem of using those role names in places where the make no sense. For example, I can do:
And still send the right colour, to the right place
Personally, this works quite well for me (and us at fffunction), as I can have a pre-rolled basic setup, which has .scss files with role names for specific needs (form labels, borders, body color), but these roles can have colour assigned to them via this double abstraction.
The result I hope, is an abstracted naming system, that has some meaning to us when we’re building and to the client when they reference in the future, with the added bonus of being flexible enough to both grow and change over time.