A brief look at Atomic Components
How to easily turn your mockups into real-time apps
Atomic Components is a conceptual fork of the Atomic Design principles established by the team behind Patternlab.io, designed to facilitate the creation and management of data-rich, scalable web and mobile applications.
While Atomic Design is fantastic for working with fellow designers and static mockups given its pages and template metaphors, Atomic Components is designed to work specifically within a component-based application architecture, extending and modifying the atomic principles to help catalyze technical details such as data delegation and component structuring.
Each type of atomic component has a specific color so that when annotating mockups in your favorite UX software, we can use rectangular containers of each color and immediately recognize the context in which each piece of the UI, each of which will eventually become a component, belongs.
Atoms are the basic building blocks of any particular app. These are usually semantic HTML elements, and they are the only atomic element that is not normally a container. Like atoms in the real world, these should represent the smallest possible component within which it wouldn’t make sense to abstract further. Think a Reply button that is simply some text and an icon and some styles. Together they compose the various other atomic components like organisms or molecules.
Molecules are groups of elements describing a static piece of an interface, such as a group of shared UI elements like a grouping that includes a like button, share button, bookmark button, etc.
Although they can appear anywhere in the hierarchy, molecules are most often found within repeating organisms.
Organisms are really the core component of any dynamic web application, these components represent dynamic containers of information that repeat consistently across a UI. Think tweet boxes, material cards, etc. Anything that is a repeating, dynamic container.
Ecosystems should represent the major core container components and ideas the interface is trying to communicate — this also provides an isolated outer context for styles.
If you are using Redux for your data-management (which you should be), ecosystems are what would possibly be your Smart Components, facilitating communication between each other on an ecosystem-to-ecosystem level.
Responsible for both handling the data reduced via redux as well as delegating the manipulated state through its child organisms, molecules, and atoms as stateless functional components.
Environments correspond to whole views or ‘pages’. If you are making an app that is either static, or has entirely separate views on separate routes, you’d have multiple environments.
Meet “Generic Real-time Reactive Progressive Web App”!
So this is Grrpwa, an abstract application wireframe with a bit of an identity crisis that might represent our new web app we’ve been working on. The example has a UI that’s abstract enough that it could be many things, maybe a news-feed-based app, or a social app, or even a dashboard.
The goal is to show that many themes recur in many of our dynamic applications, and by breaking these into constituent components we can help contextualize the complexity. It’s been color-coded according to component type to help aid visualization.
As mentioned previously Environments correspond to whole views or ‘pages’. In our dynamic app we are going to have only a single Environment within which all of our components update dynamically.
Within our Environment we have ecosystems, each representing a distinct portion of the application. In our example we might see an ecosystem on the right representing ads, or maybe that’s friends online, but each is semantically distinct from other ecosystems, say, a news-feed in the middle or “signed in profile” on the top left.
Within each ecosystem we have the real guts of our content, the dynamic organism components. Each can vary in complexity, from being an entire card holding dense information, to simply being a text-based ad that has a header and some body copy. The key here is that these are typically generated dynamically by the api along with constraints we set on the number shown at any given time, or rules on how to traverse an infinite list of organisms.
The blue outlines represent our molecules which are groups of elements but are semantically distinct. These are not dynamic by nature. Notice that we have at the top-middle perhaps a header molecule, and a subheader molecule inside of each repeating organism. Although molecules often appear inside of Organisms, they certainly don’t have to. The key take-away is that they group basic element and are distinct, where n=1.
Inside of each molecule we have the basic atoms which represent either a basic element for interaction or the guts of our content.
This area is consistently growing, and as with any sort of growth, there are growing pains involved. There will be edge cases, and if we work together by exploring these edge cases I think we can really build upon something special that will help bridge the divide between design and implementation.
Thanks for reading! -Joey
PS. Special shout out to my boy Jon Hargreaves for his superb illustration skills. Love ya man.