A living style guide - a way to control markup or CSS - has been making a name for itself. And for a good reason; they’re an important tool for web development. They keep developers in sync, communicate design standards, and help organize complex interfaces. Here’s why living style guides are important and how to implement one for Open Social with input from Lisa, one of our front-end developers.

We're using a living style guide because it serves as a valuable internal resource for development; we’re able to write reusable and consistent code that's easy to maintain. And it’s a great external resource for client deliverables. Ready to see how to make a living style guide work with Drupal software? Let’s go!

Moving From Static to Dynamic

We didn’t always rely on a living style guide. Open Social was built and maintained using different strategies such as component libraries and atomic designs. These strategies have advantages, such as reusability, facilitating collaboration within the team, and ensuring design consistency. There were, however, disadvantages to a static style of working.

In the past, a component library or style guide was usually graphic-based. The designer would create a visual representation of a component (in PS or Sketch, for example) and then the front-end developer would transfer these visuals to HTML and CSS. This immediately meant double maintenance; for instance, if the markup or CSS changes, the graphic style guide would need to be updated to reflect this change and vice-versa. In our experience, the shelf life of these “static” systems is only a few iterations before the graphic version gets left behind and forgotten due to too much maintenance and not enough return. Yikes.

This is why we decided that it was time for a change. What we needed what a more dynamic system: a living style guide.

A Living Style Guide Is the Best

Any style guide is better than none but a living style guide is the best.

A living style guide consists of a single source of code, thankfully. The style guide’s markup, javascript, and CSS are the same as what was used in production. This provides a wide array of benefits. See below!

 

  • Sharing design capabilities. Our team easily shares design capabilities between designers and front-end developers, which also benefits the backend developers and project managers who work with us.
  • Less reliance on other team members. The developers refer to the style guide and reuse components for new features without being heavily reliant on the designers and front-end developers for implementation.
  • Most importantly, the client benefits. The project manager offers new feature ideas and lower-cost solutions to the client, based on reusing and recombining existing components. Inevitably our clients benefit from this, especially when they begin thinking this way themselves.

 

While this blog focuses on how we work on Open Social enterprise projects, it is also an accurate reflection of working in the Drupal frontend nowadays. A quick google for “Drupal Living Style Guide” can give you some ideas about the current popularity, challenges, and general atmosphere surrounding the subject. In the next section of the blog, we will take you through the steps of setting up a living style guide with Open Social.

Creating the Living Style Guide

It’s important to note that this section assumes you have a copy of the Open Social distribution running locally on your development machine (here’s where you can install the Open Social distro, if you’re looking for it).

This demonstration uses a copy of the Social Blue theme, but you can implement the style guide using any custom theme. The Social Blue theme ships with the KSS style guide. Once we have the style guide up and running, the final result will look like this. Here we go!

Side note: refer to this github repo for an example of a component library within a Drupal theme folder structure, and package.json with dependencies, gulpfile.js for run KSSnode style guide and generate assets for the Drupal theme.

The Drupal Component Library Module and Twig Namespaces

The living style guide firstly requires the Component Library Drupal module to get up and running. The Drupal components library allows us to create custom twig namespaced paths. This means we are not limited to placing our components in the Drupal theme templates folder (as the current Drupal 8 architecture dictates).

The KSS style guide lives in our theme directory but has no knowledge of Drupal. This is what makes it so flexible. In theory, we can copy the component library directory and use it in other (non-Drupal) projects. A big thanks to John Albin, the maintainer of Zen Theme and KSS node, for paving the way for us to implement our theme and style guide.

In this demonstration, a namespace was created in the theme’s .info.yml file, just like this:


# This section is used by the contrib module, Component Libraries. It allows you
# to reference .twig files in your components/ directory.
component-libraries:
  demo:
    paths:
      - components
      - templates

(More documentation is available on the module’s drupal.org project page)

Once the namespace has been defined, you can include and extend twig templates from the component library, Drupal’s template override files and other components (like in an atomic design approach) by simply referring to the files like this:


{% include '@demo/02-atoms/image/image--teaser--topic.twig' %}

Social Blue comes with the style guide ready to go (read the Social Blue readme and follow the instructions on how to create a custom theme from it). However, because we have copied this to our custom theme folder, the gulpfile that runs the different tasks needs to be updated to reflect the new location in relation to the base theme (socialbase).

 

custom theme folder structure in relation to social base theme

 

Read the Social Blue readme and follow the instructions to create your own custom theme. Once you have updated the package.json file and the gulpfile.js with those provided in Lisa's demo repo, refer to the Social Blue readme again, and follow instructions under the heading “Working with Gulp”. These steps will install the theme’s dependencies.

Compiling the Style Guide

Basically, most of the action happens in the gulpfile. Spending some time reading its comments and exploring it really helps you understand the dynamics of linking a Drupal theme with a living style guide.

If we refer to the package.json, we will see which packages we have installed, and by examining the gulp tasks and configuration, we can get a sense of how the style guide is compiled from our component library and theme files.

The Theory

We are relying on Drupal's theme layer to render the twig files from our components and attach the libraries (our CSS and js). We also rely on the component module to create the namespace allowing us to map Drupal variables with the json variables in our style guide.

The style guide copies Drupal’s theme assets (CSS and js) and has its own twig compiler (see os-builder folder).

The end result is the style guide made up of CSS/js copied from the base theme’s assets folder, our theme’s assets folder, and HTML generated from the twig and json, from our component library. The CSS/js copied from the assets folders need to be included in the gulpfile to be copied into your style guide.

(Side note: a nice little improvement is to have a designated folder, therefore avoiding the need to list each file.)

The Drupal HTML pages and the style guides are not shared. This is important to point out because caching might affect each differently.

Conceptually, we are dealing with 3 layers.

  1. Drupal core
  2. SocialBase component library (as CSS/js already compiled) and Drupal templates (handled by Drupal’s theme layer)
  3. Custom theme extending base component library and drupal template

The style guide isn’t a layer because it doesn’t know Drupal exists beyond sharing the files in the component library directory. This concept illustrates one of the powerful elements of a dynamic component library - you can copy it from project to project, regardless of the environment, because in the end, all it really is is HTML, CSS, and javascript (see image below).

 

diagram of a living style guide
Diagram of how a component library, KSSNode style guide, and Drupal theme work together to make a living style guide

 

In Conclusion...

For front-end developers and designers, a living style guide is becoming an essential part of the web developer’s toolkit.

We are able to focus on the implementation of design components while the backend is being built, thus working in parallel with our team members instead of relying on others to finish before we can start.

We can do browser and accessibility tests on a component level, thus improving the quality of features (current and future). Another benefit (one that deserves a blog post on its own) is implementing visual regression testing on the living style guide to help spot changes in HTML or CSS negatively affecting existing elements.

The time investment needed, especially for a complex project, is nothing compared to the peace of mind knowing adding new elements does not break others.

Are you using a living style guide? Was this post helpful? Let us know in the comments below!

What you need to know:

250+ Communities are powered by Open Social

Don't miss our posts

Dec 11, 2017 - User Experience

Private Messaging: A Community Feature You'll Love

Open Social now supports private messaging! In this post, we’ll discuss how this feature benefits your community.

posted by Natasha
Dec 04, 2017 - Community Building

Which Members Rule Your Online Community?

Your online community is like a small society; it consists of people adopting various roles so things run smoothly. In this post, the top community member roles and responsibilities.

posted by Natasha
Nov 28, 2017 - Development

Creating a Living Style Guide with Open Social

A living style guide is becoming an increasingly important tool for web development. Here’s why and how to implement a living style guide for Open Social with input from Lisa, one of our front-end developers.

posted by Lisa