Patternlab and Modular CSS approaches: Part 1

Atomic Design, StyleTiles, SMACSS and SASS — How we combine these at BT48 into a unified approach to component-based design/development

As a modern development team, you need a strategy. You need guidelines and best practices and defined design patterns. You need a unified language that your team all shares. With a wide array of best practices out there it can be overwhelming to get started. This is the first of a blog post series about our approach and how it has helped us overcome decision paralysis around our front-end methodology.

(Front End) Alphabet soup

OOCSS, BEM, SMACSS… There exist hundreds of acronym-laden approaches to frontend development. That’s even before we get into Bower, Gulp, Yeoman, Composer and the myriad ways to improve your front end processes.

The specific framework doesn’t matter, what matters is that all members of our team agree and understand our choice and that the framework helps us work more effectively

After spending a lot of time looking at the various approaches and weighing up the pros and cons we decided — the specific framework doesn’t matter, what matters is that all members of our team agree and understand our choice and that the framework helps us work more effectively. As soon as we found the framework getting in the way of our process then we stopped and analysed the problem:

  1. Is the framework getting in the way?
  2. Is our process lacking?

Over the past 18 months we have radically transformed how we handle front end at BT48. We’ve roadtested and trialled a range of front end frameworks and our process has enabled us to produce better work, at lower cost in less time. We’ve picked a few tools and mental models that can be applied to any frontend process. These can be dropped right into an existing workflow and provide tangible benefits almost immediately.

Our process

Our ideal, framework-based front-end process consists of:

  1. Atomic Design using PatternLab
  2. SMACSS
  3. Sass

The key to everything we do is Atomic Design and PatternLab.

Atomic Design

Atomic design isn’t about designing a single instance or page, it’s about designing with the big picture in mind — it’s about designing the core of the system.

Atomic design means creating a system of pieces of functionality that can come together to create elements and templates we can reuse over and over again throughout the project. Essentially, Atomic Design states that there are five components to a site design. We combine lower complexity pieces together into higher complexity pieces into working web apps.

Atoms

Atoms are the absolute fundamentals of our system. Atoms are the smallest and most versatile component available through Pattern Lab. Atoms are best suited for repeatable or often used html tags, as well as many other functions such as variables, colours, etc. Atoms include:

  • colour palettes,
  • fonts,
  • headers,
  • paragraphs,
  • buttons,
  • links,

Atoms also include anything else that combines with other atoms to create a molecule. I’ve also used atoms for embed codes or other one-off elements.

Molecules

Molecules are the pieces we build with atoms. Although they require atoms, molecules are more along the lines of the lego blocks we will be building with, over time. Although some will get complex, simplicity is key here.

Molecules are traditionally a combination of atoms, as well as other markup that might not be completely suitable for an atom or a larger organism. A good example of a molecule might be in creating a social share widget where each of the social icons and links would be a separate atom and all would be contained under one wrapper (making it a molecule).

Molecules include things such as form fields with a label or a table with headings and data columns.

Organisms

Organisms are where we begin to see the interface come together. Organisms are usually a grouping of molecules (and sometimes atoms) that allow us to create specific sections of an interface. By combining molecules we can build more complex, but repeatable, pieces of our product. Organisms are the components we will place into our templates for reuse.

A good example of an organism might be a slider– which would be a collection of slider components, such as arrows, buttons, or pagers, and of course the slides themselves.

Templates

Templates are essentially our wireframes. Templates are mostly put together with organisms (and sometimes molecules) and allow us to create “page template” for us to build our more final pages or sections from. By combining multiple organisms, we really begin to see the big picture of what we’re building.

If a high fidelity deliverable is not necessary, this is the point where we could very easily start developing our system in code.

Pages

Pages are the high fidelity version of our templates. Pages aren’t always necessary, but for clients who need pretty visuals then pages are here to help?

PatternLab

By focusing on functional elements — rather than just a sweeping Photoshop document that bears no relation to the reality of a browser solution — our entire workflow is already primed for creation, iteration and delivery.

Pattern Lab is an implementation tool that allows us to improve the speed of our development process. PatternLab provides a framework where our front-end developers can work on the theming/styling while our back-end developers are still working on the Drupal or application functionality. This allows us to “work the bugs out” early on and even inform clients of any potential stress issues earlier in the development process.

Once we’ve decided on a few details (Drupal, Wordpress or Custom backend; Zen theme or Omega for a base theme in Drupal for example) we can begin breaking the designs down into atomically organised components. A focus on Atomic Design early on in the design process drastically affects workflow for the entire build team. Our designer can be creative and artistic while still adhering to component-based guidelines that mean the work can be reused effectively later in the process.

The focus here is on giving the designer a realistic set of constraints as the design moves through the process and becomes code. By focusing on functional elements — rather than just a sweeping Photoshop document that bears no relation to the reality of a browser solution — our entire workflow is already primed for creation, iteration and delivery.

Why bother?

But the main benefit for us? Shared assets across the development process. This is the ability to drop our PatternLab work right into a Drupal theme or Ionic application and everything works.

The first issue we ran into was — why bother with this change? The easy answer is that our old approach was broken and costing us time and money.

  1. Wireframes,
  2. Design comps,
  3. Build,
  4. Theme

We then had to change our content as:

  1. reality doesn’t match the comps
  2. responsive design issues crop up
  3. real content breaks the design comps

We needed to streamline our process. By using PatternLab we can get all our team involved at an earlier stage, the development team can work in parallel to the design team, and real content from the client can be used in PatternLab without the development team having to finalise how the site will be structured in Drupal beforehand.

The key wins for us are:

  1. Our designers can start working with a realistic approximation of what the site will look like without needing to install Drupal, or Wordpress, or Node, or Ionic or whatever stack we’re developing on.
  2. The issues around responsive design come out as early as possible in the process
  3. Styleguides continue to be updated and don’t become an outdated relic of previous ideas
  4. Design is integrated from the start to the end of the project.
  5. Design becomes more consistent — Most of the atoms and molecules will be reused. This recycling forces us to adopt consistency across elements.

But the main benefit for us? Shared assets across the development process. This is the ability to drop our PatternLab work right into a Drupal theme or Ionic application and everything works.

Finally

So to wrap things up — we’ve explained how implementing atomic design and parallel workflows have increased the effectiveness of our team. In the next part of this series we’ll look at how you actually use PatternLab.