Order is nice, order is neat and tidy, order brings peace to our developer minds. Chances are you’re also one of those people who cringe every time a template file is out of that one folder where files are supposed to be, or when SCSS variables are not in the right sequence and you’d go out of your way to reorder them and push a PR for that. Because order is nice.
And that’s why I love frameworks, I get excited every time I’m presented with a new and logical way to organize our work, or a new way to unify the language we use among ourselves at the company, or when that one methodology sounds EXACTLY like that’s what we need for the project we’re just starting.
So you can imagine my excitement the first time I heard about Brad Frost’s Atomic Design. Brad is a very well-spoken person obviously, he conveys the methodology’s main ideas very well and explains what each one of atoms, molecules and organisms are and it just MAKES SENSE. Like with all genius ideas, it’s simple and makes your slap your forehead — “how didn’t I think of this before?!”. Until you decide to use it in a real project.
We at BetaPeak make heavy use of Vue.js for our client projects, so when a large international company came to us with the request to completely rewrite their existing UI using modern frameworks, it was a no-brainer — we’ll use Vue. And what goes well with a component-based front-end framework like Vue? You guessed it — a sweet sweet design methodology to help keep all the components neat, tidy and in order — Atomic Design.
Right about the time we were beginning the project, I already had some experience with Atomic Design, but on a much smaller scale. My approach in the past has been to build a few components on the fly, then go back on those, identify similar elements and functionalities, and split them into atoms, molecules and organisms. A top-down approach of sorts.
And that works for the most part, if you’re a single developer, working on a small project with limited scope. It works because while you build up those components you subconsciously follow your own ideas of how components will be broken down in smaller and smaller pieces. It doesn’t work on large projects, where you need to build a gazillion components and lead a team of developers at the same time. But we went there anyway.
The first two sprints were a genuine mess. People have a tendency to see things differently and developers, although not perceived as the most creative creatures on the planet, show incredible fervor to see things differently than their peers and go at lengths to prove they can “build it smarter”. So if you have a two-column layout, you’d always have that one person who’ll manage to split it into two rows. It still looks like the mock up, it behaves like the user story describes, but the underlying structure of the markup is non-conventional, it’s not “how you would have done it”.
We ended up with a number of working (but still unsplit) “organisms”, with no apparent similarities both in choice of elements and in general approach to the layout. It was impossible to look at the source code and say “A-HA! So these two components have this and this in common, this shall from this day forward be called SuperAwesomeMolecule”. It wasn’t working, we had to take a step back.
The solution was the bottom-up approach of course. In hindsight it’s the obvious thing to choose — we’ve seen that conflicting perceptions of the abstract inner workings of a UI component can bring more confusion to the table than provide a common ground for refactoring.
We’ve decided to hold a number of meetings to go over ALL design mockups and literally draw out what we agree are 1) atoms (took two sessions), 2) molecules (two more sessions) and 3) organisms were pretty straight-forwards. Let me clarify something really quick here — we’re a company of doers, we dislike meetings and strive to keep them to a minimum. The fact that it took us 5 separate long meetings to comb over all components, and the fact that we all felt GREAT afterwards is a proof of how much this is the correct approach.
We decided to use InVision’s Freehand tool to collaborate in real-time so that everyone on the team can express their vision of what entails an atom or a molecule. We would walk through each and every component and ask questions like (props to Alla Kholmatova for the general direction):
Defining low-level UI bits (atoms) would in most cases be a relatively easy task. However, distinguishing more complex pieces of the component library, i.e. molecules, can present challenges both in terms of mental load and in terms of having a calm, open and secure communication environment. What I mean is — developers get passionate about tech, and more often than not we tend to lean heavily towards our own opinions, and we quarrel. So a thing to watch out for as a facilitators of such component definition sessions is to interfere and calm the conversation if it gets heated, and promote open discussion without the fear of being scolded by your peers.
We’ve come to the point where we’ve already defined and developed our atoms. It’s important to understand your atoms’ API surfaces (i.e. their props, events, etc) will likely change the moment you decide to use them in molecules, be prepared for a refactoring session. So how do we identify common structures in our mockups that we can unify under an umbrella name, i.e. a molecule? A few pieces of advice:
AirlineHorizontalSlider. Don’t call it
AirlineNumberCard, try to keep things generic. Even if you don’t have an organism in your library that uses that molecule, imagine ways to reuse it — is it a simple card with an option to specify a number via a prop, e.g.
<v-card :number="3" />or is it a card that you need more flexibility with, maybe add a slot, e.g.