Yesterday, Brad Frost (@brad_frost) presented on Atomic Design at An Event Apart: Chicago 2013. Brad’s blog post and slide deck (video) from Beyond Tellerrand do a better job explaining the overall concept than I ever could. That said, I did want to touch on the recent changes that we made to his tool, Pattern Lab, to help designers and developers take advantage of Atomic Design. You can check out a simple demo of the front-end of the tool and take a peek at the code on GitHub. There is also an expanded set of documentation for the project.
PHP Shouldn’t Be a Requirement
One of the overriding goals with the re-write of Brad’s original version of Pattern Lab was to make sure the new edition wasn’t tied to any particular “server-side” language. The new edition breaks up Pattern Lab into four parts:
- Mustache-based patterns & templates,
- JSON-based dynamic data,
- a PHP-based static website builder
This strong separation should make it easier to share agnostic resources like patterns, data, & the viewport resizer amongst several different libraries. It should even be possible to convert patterns into other template languages like Liquid or Kit so they work with other tools.
Do you prefer node.js to PHP? Who, other than me, doesn’t, right? Take the patterns, data, and viewport resizer and mash it up with your own builder. Ruby? Do the same. Outside of making sure that patterns are compiled properly with the data we want to see what people can come up with to make Pattern Lab better.
Plusses & Minuses to Strong Separation
There are some nice upsides to this strong separation as another goal was to limit dependencies and installation of software as much as possible. You don’t need to run Apache locally to make this all work. Got PHP? You’re all set. Just use the “Open File…” dialog in your browser and open the vanilla
index.html. Also, the final product can be pushed anywhere for review by clients.
There are some downsides too. The new edition can feel a little indirect at first and the need to regenerate a site after changes feels like extra work. Pro tip: use the watcher to auto-regenerate your site when you make a change and use the auto-reload server to automatically reload your site when your site is regenerated. If you use CodeKit you’ll want to turn-off its auto-refresh feature when using Pattern Lab.
Don’t Like the Atomic Metaphors? Nuke ‘em
By default, Pattern Lab uses science-y metaphors but you can rename and reorganize your patterns anyway you see fit. We’re not trying to lock you into any particular way of thinking about your assets. You can put them together however you see fit. Just rename directories, update your Mustache patterns, regenerate the website, and, bingo bango, your edition of Pattern Lab will be updated. Atoms, molecules, and organisms are definitely not required though it might take a little work to update the patterns.
Related to that, do you want to use Bootstrap/Zurb, Zepto/jQuery or Sass/LESS for your site? Have at it. Pattern Lab makes no distinction between libraries you may want to use. For assets that will be referenced in your site just put them in the
_source directory and update the pattern header & footer in
_source/_patternlab-files/ so the assets are included when your patterns load. The docs go into more depth regarding patterns and assets.
We’re Not Done
There are a few features that have yet to be implemented in Pattern Lab:
- Annotations: one of the use cases for Pattern Lab is to share work with clients so they can review it. Annotations will offer you a way to explain the design decisions you made directly in Pattern Lab.
- Custom Viewport Sizes in the Toolbar: Brad can come up with a fancy name for this feature but it’s based on the “Phases” proposal from Ben Edwards. Because one of the goals of Pattern Lab is to be tool independent the final implementation will be based on parsing CSS but I think it’ll be really useful.
- Regenerate from the UI: Because Pattern Lab is, ultimately, a static site generator that means it takes user action to regenerate the Pattern Lab site to see changes. Currently, this means either using the command-line options or double-clicking a file on the Mac. We’d like to have a UI element that can make updates easier.
These are in a addition to a number of UI and under-the-hood tweaks that we still want to make.
We Want Your Feedback
Ultimately, we want to hear from you. What works and what doesn’t work for you when using Pattern Lab? Got an idea like Ben’s? Share it and we’ll see if we can make it work. Run into any problems? Let us know. Use Pattern Lab internally or with client work? We’re always curious to hear about real-world use. Just drop an issue for us and we’ll respond.