Appearance
Subatomic Design
Atomic design is a popular methodology for managing design systems that draws parallels with biochemistry to describe a hierarchy of a design system's constituent parts, from atoms, through molecules, to organisms (and sometimes beyond).
The word 'atom' derives from the Greek atomos, meaning 'uncuttable'. As in physics, where the atom was discovered to be very cuttable indeed, it is becoming apparent in Design Systems that the design atom is, too, divisible.
The Über-Button
Consider, if you will, the humble button.
It may have different appearances:
Each of these will have multiple interaction states:
This may be available in multiple sentiments:
This is just colour; we will also have different sizes:
Different shapes:
And different content options:
With a worse case naïve implementation, we would have hundreds, if not thousands, of possible combinations.
There is a temptation to put all of these into some kind of 'über-button', which can express all possible combinations and behaviours. After all, the button is a classic 'atom' of atomic design.
However, this can result in an unwieldy component with too many knobs and levers, and a vast number of permutations only a few of which are actually cromulent.
When we throw behavioural differences into the mix we get additional questions:
Is this toggle button a button, or does it have a button? It is implemented as having a button, so how can an atom be made of another atom? This question will be repeated throughout your components—is the item in your side menu a button? The control of a tabs panel? The options in your select control? They will certainly share much of the appearance and behaviour of this button.
This is where the atomic design metaphor hits a bit of a wall as far as pragmatism is concerned.
Splitting the Atom
The trick here is to recognise that the categories described above are, or can be made to be, orthogonal. That is, it should be possible to reference each of them without reference to the others.
Then, instead of creating an über-button (or an über-card, or über-popover, etc.), you have a suite of behaviours, features or appearances (choose your own naming) from which to pick and mix each time you need them.
A question of handover
As things stand, there is a large information void between the highest levels of subatomic design and the lowest levels of atomic design.
There's a huge amount of information added in this step. Tokens generally refer to a single value, but even something as simple as a single button variant requires upwards of 18 variables just to describe its colour.
This relationship, or mapping, from subatomic to atomic, is strongly hinted at in the structure of semantics, but rarely (if ever) actually formally encoded.
As such, different implementations are inevitably going to have differing ways of describing this relationship:
This causes a not insignificant headache when it comes to handing over design definition, when developers must translate the design mapping (suited to the design tooling) to a development mapping (suited to the development tooling).
The purpose of torquens is to provide a vocabulary and framework to describe the bridge between semantics and components that works in both development and design domains, minimising the void between subatomic patterns and atomic implementations.
Why 'torquens'?
Naming things is hard, bad puns are easy.