A new approach to component hierarchy (RIC)

I’ve been considering component hierarchy since my last article and I’ve gotten to thinking.. Could I find a way to categorise components so they better suit my needs?

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

  1. Is the component repeatable?
  2. Is the component interactive?
  3. 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.

Category name Repeat Interact Consume
Token Yes No No
Arrangement Yes No Yes
Pattern Yes Yes Yes
Module No Yes Yes
Page No No Yes

Category definitions

As you can see from the table, our categories are as follows:

Token
– A Non-interactive but repeatable component that does not consume other components
Arrangement
– A Non-interactive but repeatable component that can consume other components
Pattern
– An interactive, repeatable component that can consume other components
Module
– An interactive component that can consume other components and is not repeatable
Page
– A Non-interactive component that can consume other components and is not repeatable

Implementing RIC

An example of how the RIC system might be applied to components (Note. the same across both design and development) is:

Token
– Colour, SVG Icon, Spacing value
Arrangement
– Button group, Fieldset, H2
Pattern
– Button, input, credit card field
Module
– Page header, Page footer
Page
– Home page, Contact page

Conclusion

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.

If you have an opinion about this, I am on Twitter.

Happy New Year!