Brad: Yeah. I think that, yeah, more or less, that’s it.
Molecules are a couple tags stitched together. You might have just a search form that’s comprised of search label, an input, and a button, and that is a self-contained little assembly of stuff that does something.
Atoms by themselves, the tags are all really abstract and floating around in space. You don’t really see, inherently, just from looking at that level, how these things might be useful. It’s like, “Well, that’s nice.” It’s helpful at an at-a-glance sort of level. Then you start combining them into these little packages, these little molecules, and now they could actually start doing something.
You might have your primary navigation as a molecule, your search form as a molecule, and stuff like that, and then you put those molecules together into a header organism. Now your header organism contains your logo atom and contains your navigation molecule, it contains your search-form molecule, and all those things operate at this standalone, reusable component.
From there, then you start stitching these organisms together and finally start building these sort of page-level things, like templates and then, ultimately, pages, which we don’t have to get into.
The idea is that you have these little clusters of elements, and then you combine those together into more complex clusters of stuff. The whole idea is to basically establish this really sound, really deliberate interface, where everything is being built up with the intention of creating a system that’s built for reuse, built for scalability.
Certainly helps with responsive design because, again, you’re able to treat these problems at the component level rather than at a page level. Also, just from being future-friendly — you’re establishing these nice rules and guidelines and constraints, and this goes inside of this, which means that the new hire you hire four months down the line can understand how things are put together and why things are put together in the way that they are.
I think that in my experience using this and helping create this, what we’re doing now, why we’re doing this, is that it’s no longer feasible to just throw over a handful of page templates to a client and just say, “Here’s your site. Have a nice day. Make sure I get my final paycheck.” It’s not enough to do that anymore. We have to be a lot more deliberate with this.
We have to give them better tools, better resources, so that we don’t come back next year and, all of a sudden, they’ve changed the color of green and they’ve put this thing next to this thing and they’ve created a bunch of new code all on their own, in different patterns and stuff, and it all looks like a big, giant, Frankenstein mess.
In part, that’s your fault if that happens, simply because you didn’t give them the library of components, you didn’t give them the building blocks, the LEGO bricks, so that if they need to add a new section to the site. If they need to add another widget, or an organism or component or whatever you want to call it, they have a language to choose from and make informed decisions. I think that that’s really, really cool.
In fact, one of the clients that we first did this on — actually, the very first client that I introduced this whole atomic-design, Pattern Lab concept — was TechCrunch. I was actually just on their site last night and noticed that they had added a different component to the site. You read the article, and then there was an extra little “You might also like” sort of thing.
Now, we had our own version of that, and that’s still there, but then they added a separate “You might also like these stories.” What I found is that they used the interface patterns that we provided them to construct an entirely new module.