Development icon

We’re going to turn it up a notch this week and dig into some tools that drastically improve your design and development process.

Christopher Bloom, Front End Lead
#Development | Posted

Welcome back! This is part 2 in a blog series about coherent frontend methodology. There is a daunting amount of information out there when it comes to development, and we’re trying to help guide at least the frontend portion of your development toolchain.

In part 1 of this series, we went over simply applying a modern framework like Compass to solving uncertainty in page styling. We’re going to turn it up a notch this week and dig into some tools that drastically improve your design and development process.

I’ve picked up some heat for my love of frameworks (You can pry Foundation from my cold, dead fingers). However, that passion stems not from a flavor-of-the-month obsession, but rather the ease of expressing technical concepts in a clear and lucid way. Frameworks reduce cognitive churn when approaching new problems. A lot of work has already been done for us in these systems and we realize benefits like:

  1. Extensive documentation
  2. Case studies in the wild
  3. Emergent standards
  4. Unified language
  5. Rapid training
  6. Repeatable implementation

“We’re not designing pages, we’re designing systems of components”

 ~ Stephen Hay

 

Gluing a few together

The design-to-development process is different within each team – and often different from project to project, within the same team. 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.

If we think of the development process as starting with design, and moving through various steps before eventually arriving at code, the following approaches compliment each other smashingly. This graphic picks up after initial creative work, as we move into the “frontend” process.

diagram of front end process

An ideal, framework-based frontend toolchain consists of:

  1. Atomic Design (alternative: StyleTiles)
  2. Object-oriented CSS
  3. BEM
  4. SMACSS
  5. Sass/Compass

Today we’re going to focus on Atomic Design (and it’s sibling tool Pattern Lab).

Atomic Design

Atomic Design is a lot of frontend-y things rolled into one inclusive system. It is first and foremost a way of thinking about design that relies on interlocking components, from small concerns like colors to large systems like full page templates. Second, it is a PHP-based generator for interactive styleguides (think StyleTiles on steroids) and prototypes. Architects are free to implement Atomic Design as a whole or piecemeal.

A focus on Atomic Design early on in the comp process drastically affects workflow for the entire build team. A designer can be creative and artistic while still adhering to component-based guidelines.

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 webapps.

icon of atomic design "atom"Atoms

Translated to interfaces, atoms are basic tags, such as form labels, inputs or buttons. They also include more abstract elements like color palettes, fonts, and animations.

icon of atomic design "molecule"Molecules

In interfaces, molecules are groups of elements that function together as a unit. For example, a form label, search input, and button atom can combine them together to form a search form molecule.

icon of atomic design "organism"Organisms

Organisms are groups of molecules (and possibly atoms) joined together to form distinct section of an interface. Building up from molecules to organisms encourages creating standalone, portable, reusable components.

icon of atomic design "template"Templates

Templates are comprised mostly of organisms combined together to form page-level objects. Templates provide context for these relatively abstract molecules and organisms, which is helpful for designers and clients alike.

icon of atmic design "pages"Pages

Pages are specific instances of templates and swap out placeholder content with real representative content to give an accurate depiction of what a user will ultimately see.

The focus here is on giving the designer a realistic set of constraints as the design moves through the process and becomes code. By adhering design to a set of components early on – rather than just a sweeping, bespoke “picture” or Photoshop comp – the entire development flow is already primed for rapid production.

As is a recurring theme for these listed frameworks, the Atomic Design site is filled with documentationcoherent examples, and helpful resources to get your team started thinking this way.

Pattern Lab

logo of pattern lab

Atomic Design is a lot more than a mental model. It’s actually an entire command-line PHP framework called Pattern Lab used to generate real markup for a fully interactive styleguide and prototype system. It is a command line utility packed with “patterns” out of the box – or custom defined by your team – to build out all of the individual pieces of your working webapp.

Getting Pattern Lab up and running is simple.

  1. Start by cloning the Pattern Lab github repository:

    git clone git@github.com:pattern-lab/patternlab-php.git

  2. Hop into that directory, and then run:

    php builder/build.php -g

  3. Now visit your new local site at <path to patternlab-php>/public/index.html.

screenshot of pattern lab demo

Welcome to your very own Pattern Lab demo! This is cool as a proof of concept, but we probably want to build something real. Let’s take a look at existing pattern, then let’s make our own!

Digging In To Pattern Lab

Pattern Lab’s file structure is self-explanatory. Starting within the source/_patterns folder, we can see the major pieces of Atomic Design broken out into their respective folders: 00-atoms, 01-molecules02-organisms03-templates04-pages.

screenshot of pattern lab directory

The pattern directories are set-up using the following naming convention:

source/_patterns/[patternType]/[patternSubType]/[patternName].mustache

As mentioned above, [patternType] is the overall pattern category like “atoms”, etc. For further categorization we have a sub-folder: [patternSubType]. We name our specific patterns with a .mustache extension. Pattern names containing “-” end up converted to spaces.

Let’s take a look at a pre-existing pattern in the venerable “media block” in 01-molecules/02-blocks/00-media-block.mustache:

<div class="block block-thumb">

  <a href="#" class="b-inner">

    <div class="b-thumb">

      {{> atoms-square }}

    </div>

    <div class="b-text">

      <h2 class="headline">{{ headline.short }}</h2>

      <p>{{ excerpt.medium }}</p>

    </div>

  </a>

</div>

Our templates use the Mustache PHP templating language. This allows us to fill in content dynamically wherever we see {{ }}. One of the magical things about Mustache is that one template can render another template. We can see that in action in the {{> atoms-square }} snippet. This is simply grabbing an atom from 00-atoms/03-images/03-square.mustache which itself is printing:

<img src="{{ img.square.src }}" alt="{{ img.square.alt }}" />

Our media-block pattern is printing a square image!

 

Atomic Design lets us stack small components together to build bigger, more complex components; atoms make molecules, molecules make organisms and so on.

We feed our templates dummy data that is stored in source/_data/data.json. You can see both our headline and excerpt data used within the 00-media-block.mustache template at data.json here:

 

 

  ...

  "headline" : {

    "short" : "Lorem ipsum dolor sit (37 characters)",

    "medium" : "Lorem ipsum dolor sit amet, consectetur adipiscing elit. (72 characters)"

  },

  ...

  "excerpt" : {

    ...

    "medium" : "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.",

    ...

  },

This is how our Media Block template knows how to fill in dummy content when rendered out into our full Pattern Lab implementation at the URL <path to patternlab-php>/public/?p=molecules-media-block:

screenshot of pattern lab media block

Now that we’ve seen how pre-existing patterns are built and rendered, let’s make one of our own! Let’s make a new type of organism called a “Centered Floaty Plaque” that vertically and horizontally centers and contains a (pre-existing) Heading Group molecule.

Make a new file within 02-organisms/03-components called “02-centered-floaty-plaque.mustache”:

screenshot of new file in directory

Why are we creating out file at this location? Simple:

  1. What we are creating is an “organism” because it contains molecules defined elsewhere.
  2. When we preview our rendered Pattern Lab website, we’ll have a new menu entry under Organisms > Components

We’re going to include a pre-existing molecule called Heading Group, so we use our mustache syntax to pull it in like so:

<div class="block floaty-plaque">

  <div class="floaty-plaque-content">

    {{> molecules-heading-group }}

  </div>

</div>

Add our new organism definition to the system by returning to the root of the pattern lab repository and running:

php builder/builder.php -g

You should see a confirmation like the following if all went well:

PL site generation took 0.13547706604004 seconds...

your site has been generated...

You should now be able to visit <path to patternlab-php>/public/?p=viewall-organisms-components in a web browser and see our new widget at the bottom of the components organisms list:

screenshot of widgets in a component

All we have left to do is style the thing, so let’s crack open source/css/style.scss and add the following line to the bottom of the “$COMPONENTS” section:

@import "scss/objects/plaques";

Now create a file called _plaques.scss in source/css/scss/objects which contains the following code:

.floaty-plaque{

  min-height: 200px;

  width: 100%;

  position: relative;

}

.floaty-plaque-content{

  width: 60%;

  height: 30%;

  margin: auto;

  position: absolute;

  top: 0; left: 0; right: 0; bottom: 0;

}

We need to compile our Sass, so from the root of Pattern Lab, run the following to compile our SCSS to CSS:

sass source/css/style.scss:source/css/style.css

Now, let’s rebuild our site (again) so we can view it in a browser:

php builder/builder.php -g

You should now be able to see our new component with its new styles!

styled componenet

Fun fact: if we run our builder with the -wr switch like so:

php builder/builder.php -wr

then Pattern Lab watches for our changes in realtime, rebuilds our project automatically, and refreshes our server! More information can be found here.

Pattern Lab Is Just The Beginning

Atomic Design/Pattern Lab is a powerful tool to bring to the table at the start of a frontend process. It front-loads a lot of development by answering most of the questions that aren’t apparent until many lines of CSS and HTML are written weeks later: How does this login form behave in the header? How about when we stick it in the sidebar on internal pages? What do our callouts look like on internal pages? Why do we have so many text colors? Can we simplify that now?

By implementing this simple tool (Pattern Lab,) and this way of thinking (Atomic Design), we’ve set up our entire frontend development chain to be component-ized. We’re not designing pages, we’re designing systems of components.  If you missed the first blog post of this series about applying a modern framework like Compass to solving uncertainty in page styling, check it out here! And stay tuned for the next installment of this series which will cover object-oriented CSS using BEM, SMACSS, and Compass!

Christopher Bloom

Front End Lead