Why this project?
I have a small issue with the standard definitions in Atomic Design and their practical application across disciplines in digital.
In Atomic design, an Atom is described as akin to ‘basic HTML elements like form labels, inputs, buttons, and others’ but Its not evident that this means the same thing to a Developer as it does to a non-technical Designer.
Does it matter for example to a non technical stakeholder, that there is significantly less effort in the implementation of a standard input field compared to say, a credit card field? Which is quite different in coded complexity but could be considered similar in terms of appearance.
When developing an interface I also have to consider that in some instances for semantic validity and accessibility, HTML elements contain others necessarily. Such as when I need to group <input>‘s inside of a <fieldset>. This nesting makes the parent essentially more complex and puts it at a higher level of the hierarchy. Yet an input can be present without a fieldset and so this seems not be a strict position.
Things are less complicated as components get higher level and less repeatable, but I find that the majority of components end up living inside of my Atoms and Molecules folders.
Lastly, and perhaps I’m nit-picking.. I can see how Atoms, Molecules and Organisms have a taxonomical relationship and the analogy is drawn from Chemistry, but when we get to Templates and Pages the analogy is lost.
Praise for Atomic Design
It is of course entirely possible that I’m not using the system as intended. I should say that I have huge respect for Atomic Design and the value of this approach. It has allowed me to work rapidly and with far less fuss.
Something new: Repeat, Interact, Consume
In my latest project I have been trialling a new system which doesn’t arrange itself by complexity per say, but along several axis which determine it’s categorisation. I have found that by forgoing the idea that any particular category relates to HTML elements, I am free to build components of different complexity at various levels of the design hierarchy.
As well as this decoupling, I have considered the relationship between components in three ways: Repeatability, Interactivity and ability to Consume other components. For me, this adds a level of clarity to and definition to what we’re calling complexity.
How to decide what’s what?
The axis along which the categories are defined can be asked as questions
- Is the component repeatable?
- Is the component interactive?
- Does the component consume other components?
What are the categories?
The answers to these questions help us to decided which category to place the component in, as described in the table here. Notice that complexity peaks at Pattern before tapering back down.
As you can see from the table, our categories are as follows:
- – A Non-interactive but repeatable component that does not consume other components
- – A Non-interactive but repeatable component that can consume other components
- – An interactive, repeatable component that can consume other components
- – An interactive component that can consume other components and is not repeatable
- – A Non-interactive component that can consume other components and is not repeatable
An example of how the RIC system might be applied to components (Note. the same across both design and development) is:
- – Colour, SVG Icon, Spacing value
- – Button group, Fieldset, H2
- – Button, input, credit card field
- – Page header, Page footer
- – Home page, Contact page
I’ve been using this method for my latest project and so far so good! I will continue to develop the idea until it is either superceded or proves to be flawed.
Happy New Year!