Style Guides and Pattern Libraries with Cameron Wardzala | Episode 11

Cameron WardzalaOn this episode Cameron Wardzala and I discuss the emergence of style guides and pattern libraries instead of Photoshop comps when building web application and site designs. We also dig into his experience outgrowing bootstrap on a project, new modular CSS frameworks like SMACSS and Atomic Design, and the ongoing debate of Less or SASS.

To subscribe to the podcast, please use the links below:

Click Here to Subscribe via iTunes
Click Here to Subscribe via RSS (non-iTunes feed)

Show Notes:

Cameron’s Blog



Atomic Design




Full Transcript

Craig McKeachie:  On this episode, Cameron Wardzala and I discussed the emergence of style guides and pattern libraries.

[background music]

Craig: Welcome to the “Front-End Developer Cast.” The podcast that helps developers be awesome at building ambitious Web applications, whether you’re a JavaScript Ninja or you’re just getting started. I’m your host, Craig McKeachie.
Hi, everyone. My interview today is with Cameron Wardzala. We discussed the emergence of style guides and pattern libraries instead of Photoshop comps when building Web applications and site designs. We also dig into his experience outgrowing bootstrap on a project, new modular CSS ideas like SMACSS and Atomic Design, and the ongoing debate of Less versus SASS.
Today, I’m lucky to have Cameron Wardzala with me. I’m at a conference and was lucky to meet up with him. I’m noticing this trend in front end style guides that people are creating. Some people are calling them…what’s the other word that you hear them called by other things?

Cameron Wardzala: Style guides, pattern libraries. That’s pretty much the two that I hear the most.

Craig: That’s the other one I hear a lot. Cameron, would you like to introduce yourself?

Cameron: My name is Cameron Wardzala. I work for Findaway and I’m a front- end developer.

Craig: Tell me more, what is a style guide? That seems like a pretty new concept.

Cameron: The concept’s been around for quite a while. About 2011 is when they started being spoken about on a regular basis. A style guide is basically a living document of code, of the elements on your site, the style, the elements that you could have on your site.

Craig: Do you see them more for like websites or more for like Web applications? Or is it just a different implementation but the human used for either?

Cameron: In my personal opinion, I see them used for both. I’ve used them for both. Anytime you have a visual language, something like a style guide is a useful tool.

Craig: When people use the term pattern library, do you think they’re talking about something a little bit different? Do they talk about more component type stuff? Is it the same thing or is it just an interchangeable term for you?

Cameron: There are subtle differences. Roughly, they are the same thing. They are pretty interchangeable. But a lot of times when I hear pattern library, it invokes something a little bit more formulaic than a style guide. For me, a style guide is almost like a raw dump of all your style elements. With a pattern library, it almost invokes a feeling of much more purpose, much more thought put into it.

Craig: What is the need that caused people to start creating this? What do you think happened in the world where we used to use Photoshop comps or just build an application without a style guide. Explain to me what’s been happening that people are realizing that they need these.

Cameron: The need really arose when people, developers in particular, needed to start maintaining sites on a regular basis, and not just singular developers, but teams of developers.
They needed some way of cataloging the styles, the visual treatment of the site so that when other developers walked up, they could easily pick up things that are already been created, or start with elements that had already been created.
It really helped foster a mentality of maintainability. I think that’s really where it started was they needed this tool to help reduce redundancy and things like that.

Craig: Do you feel like there’s a standard set of things that are in a style guide, or is it more like a per project, or per company type thing.

Cameron: Yeah, for the most part there’s a standard set of information that you have, and then you get past that standard set of information. It becomes per application, per site, per company, per team.

Craig: What is some of the standard stuff, just so people can get a more concrete feel? What does a style guide look like, and what are its contents — a lot of common things that are in it?

Cameron: From a standard, basic standpoint, things like text treatment, typography, headers, paragraphs, body copy, things like that, and then typical elements, buttons, form fields, things like you would find on a site or may need to use on a site.

Craig: Gives me a feel for it. As a developer, sometimes I think that stuff is all needed, but beyond the button, there starts to be lists, grids, date pickers, and stuff. Some of that might not be needed. Some style guides, but the more application and less of a website you have, you pull in that sort of thing, you give it the same treatments?

Cameron: I try to tell people when they’re building a style guide to just be as verbose as possible. Put as much information in there as you can, because you may not need that button treatment right now, but somebody else later might need that. It’s going to make their life easier to be able to walk up and get the information that they need.

Craig: Is this replacing Photoshop to some? Used to be these static mock- ups. Is there some sort of evolution I’ve been hearing about? Is this a better work flow? Can you talk about that a little bit?

Cameron: It’s another piece in the evolution of the work flow that we already have, or that’s already going on, which is we’re moving much from this process of page-based design. “I’m designing a page, and here’s all the things on the page. Here’s the next page and all the things on that page,” to, “Here are the components that we’re building.”
“Here are the modules that we’re building. Here are the pieces and the parts of the site, rather than the much larger picture of things.”
Style guides really play well to that, because as you’re designing those, as they’re being built, the style guide can be updated and added to, but it can also be pulled from. Instead of saying, “Oh, the designer’s got to go and design this thing,” the designers may say, “Oh, let’s look at this style guide.” Pick out two or three things they want to use and build right from there rather than them taking time to design it, giving it to a developer, and then them developing it or that type of process that you see typically happen.

Craig: What kind of tools do you use? Tell me about…you obviously built some style guides. What do you use? What are your tools of trade for this task?

Cameron: It’s just stating with a blank page. There are a few generators and starting frameworks out there. Personally, most of the style guides that I build have been fairly specific to the site or application that I’m building them for.
I typically like to start fresh and start small. Start putting in the little things, like I said, typography, body copy, buttons. They are really small stuff. Then work out from there to much larger pieces on site.

Craig: What you’ve got is like a static-h at the end, where you’re using as a site generator? I’ve heard some people using Middleman or…

Cameron: I’ve heard of people using Jekyll or things like that to help facilitate building of style guides. But at the end of the day, you’re generating static HTML so you could just as easily break some static HTML team out, get some content in there and write it.

Craig: How much of this have to do with organizing and writing CSS and the approaches you take to that? Could you discuss that a little bit?

Cameron: Style guide briefs off of things like Atomic Design and SMACSS, and these modular approaches to CSS. If you’re using some of those models to build your CSS, then the style guide is a natural thing to build.

Craig: I’m not sure how familiar you are with these things but I’ve definitely heard of SMACSS at least five times in the last few months or something like that, and Atomic. Can you elaborate on what this movement is in terms of modular CSS without going too deep into it? What it is?

Cameron: There are a few different variations to it. SMACSS is just focusing on modularity and making sure that things can be portable and styles can be portable around the site. Then we have things like Atomic Design which stresses the concept of breaking things down into the smallest parts, focusing it on the smallest parts and then working up from there.

Craig: There are competing ideals about the right way to do this. Is it all about class-based versus ID-based or is it more like the things like what you’re just commenting on?

Cameron: You’re always going to have people who want to do it a little bit differently than somebody else and that’s healthy. Like somebody who came from the world of none of this to picking up SMACSS and falling in love with that, and picking up Atomic Design and focusing on that. Finding where I fit in that whole thing.
I don’t necessarily like to think I prescribe in one or the other. But it’s nice to have a really big pool of information to pool from. You have OCSS, you have SMACSS, you have Atomic, a few others out there. It’s really nice just to have somebody else coming up with great ideas and being able to figure it out for myself.

Craig: That makes a lot of sense. The style guides you’re building, are they more for a company and they’re used through several applications or you’re building a one off for this particular application? I know the purpose is more across but what do you find in the real world?

Cameron: My experience…there are two folds. When you’re dealing with a company or brand, you can almost have two separate style guides. You almost have a brand-base style guide which lays out that sort of thing that could be used across multiple applications or sites but then you also have style guides that are very focused to the applications and sites.
That’s typically how I approach it. Is if Findaway we have three of four brands that we have styles for and we build a number of sites for each brand. We’re going to have a nice brand framework that we pull from. But in each site that built have their own smaller style guides that sets up the patterns and styles for that site specifically.

Craig: Are you allowed to talk about which specific sites? I don’t know if it’s public information for…

Cameron: I can talk about the two that we have out there. We have Playaway which is our preloaded device side of the business. We have quite a few sites for that, We just launched Those sites hopefully, in the next year, will unify one brand framework and brand style guide. Each site individually has its own.
You can go to, and that’s our style guide for that site. You can see it. You can see all of our swatches, all of our patterns that we have on that site. We have Audioengine, which is a new brand that we just launched last year.
Right away, I said, “We have to go out the door with the style guide. We have to go out the door with focusing on setting up this brand framework, setting up this brand style guide.”
That was not public. For the two or three sites that we have for that brand, they all pull from the same set of styles. Each site has its own extended styles on top of that.

Craig: When people pull those styles in, it’s more almost like documentation or examples of the right way to do the styles. I’ve heard people talk about this holy grail of styles or patterns, API, that sort of thing. This is more like a static documentation, and then you’re supposed to reuse these best practices, isn’t it?

Cameron: It’s a little bit of that. We took a little bit different approach to it, something that I started with the Audioengine brand, which I call a brand’s framework. We treat that as a third party module. We install that with Bower. It lives in a GitHub repo completely separate of everything else.
We have a few other brands in that repo, as well. Whenever we need to use one those brands, we just Bower install Findaway brands, and we have all the CSS for all of those brands. It’s all SASS. We pull in the SASS file for that brand, it includes all the other stuff it needs, and we’re off to the races with that CSS.

Craig: I was just talking to a friend of mine on the way up. He’s more of a Less fan, but it seems like the world is moving towards the SASS side. Can you talk a little bit about the Less/SASS thing and why you maybe prefer SASS over Less?

Cameron: I read a tweet earlier that said, “There’s been a lot of SASS talk at CodeMash but not a whole lot of talk about Less.” I was like, “You know what? Yeah, there hasn’t been that much talk.”
For me, it was a personal thing. When I worked at Cheezburger, we built on Less. We started with Bootstrap, and we built on Less. That was the language that we chose.
When I came to Findaway, they had already chosen, as a team, they chose SASS. I was already a pretty big fan of SASS because of the level of tools that it provided that Less didn’t. It was a really nice, natural thing for me to just pick up on. It’s become my styling language of choice, at this point.

Craig: Are you an SCSS guy, or you’re more of a…?

Cameron: Yeah, I’m a CSS purist, when it comes to that. I can’t get behind the SASS syntax.

Craig: Explain that for people who don’t know. I just recently learned it myself.

Cameron: The difference is you have SASS syntax, which is the original SASS syntax when SASS was created, and then you have what’s called the SCSS or “SASS-y” CSS, I think I’ve heard it referred to this week.
The difference is SCSS follows the CSS patterns. You have curly braces. You have semicolons. You have things of that nature.
The SASS is much more like Haml, because it was written by the same guy that wrote Haml, which is you omit all the extraneous things that you don’t need, curly braces and semicolons. You let the preprocessor figure that all out. It’s indentation-based and things like that.

Craig: That’s helpful. I noticed you have a GitHub repo with lots of example style guides. I’ll definitely put a link in the show notes. Out to that, do you want to talk about…I know it’s hard on a podcast like this, but do you want to talk about maybe a few of those you like and some particular things you like about them? Or anything coop?

Cameron: I started the repo just to gather all these things up and there are some really great ones out there. The ones that I always go to are things like Starbucks which was one of the very first big, popular style guides that came out.
Just seeing what they do and how great their style guide is and how it really hasn’t changed that much over the last four years that’s been around. But that they continue to evolve it. You can see that it has a last updated date of sometime in the last month or two.
It’s nice that they’re continuing to maintain it. That’s always a good one that I go to whenever I need inspiration. I’m trying to think if there’s any more that stand out.
They’re all great. Somebody asked me Tuesday if I’ve ever seen a bad style guide. I had to say no, because the only time I’ve ever seen a bad style guide is when I haven’t seen a style guide. Anytime I see a style guide, it’s just great that people are doing that.

Craig: Help me understand, just playing devil’s advocate here, particularly in bigger enterprises where they’ve never done this sort of thing before. I’m a developer and I say, “Why not just use bootstrap?” Isn’t the bootstrap documentation basically a style guide or foundation? Another CSS framework.
Help me understand how you make that argument for the value of a style guide for an organization with all other things out there in the world.

Cameron: I can speak this really well. Not to devalue bootstrap or foundation, I love both of those frameworks. Their documentation was one of the big inspirations for…at Cheezburger, we actually built — we did a redesigning in 2011 — off of bootstrap. That was one of the big things. They had great documentation.
It was one of the very first responsive frameworks out there. We thought it was a natural thing to do. The problem we ran into is two years later we were outgrowing it.
I wrote a blog article about this two years ago, two and a half ago probably. We started to hit the walls…


Craig: I’m trying to understand what was it like. What was the first thing where you were like, “This isn’t quite working.” What things were happening when you hit that wall?.

Cameron: The big thing was when we chose Bootstrap we said, “Oh, we have this great documentation, so if you need to know how something works just go look at that.” Our developers…it was hard for them to wrap their head around that.
It wasn’t our thing. For back in developers who weren’t in front of the CSS all the time it was easy for them to forget that “Oh, this is just Bootstrap so I’m going to look at the Bootstrap documentation.”
That’s what really pushed us towards to…we need our own set of documentation. We need a style guide. We started to hit the wall with Bootstrap and overriding things, and changing things. We started coming up with our own model so it made sense to have our own documentation.

Craig: Was it things that were missing that you needed to be more detailed in order to get developers enough information and then override, you spoke of. What kind of elements did you find were useful to guide your developers that were missing from the Bootstrap world? Certain components? That sort of thing.

Cameron: At Cheezburger, it’s a pretty unique site, or set of sites. We have a lot of unique module, a lot of unique components that we’re building. That stuff wasn’t represented in the Bootstrap docs, because it was all custom.
That was one area where we needed to have the documentation on this. But we also started to get to things like we wanted to use a different set of icons than what Bootstrap was using so we swap in our own icons. Now, we have to have documentation for that because that’s not the same as bootstrap.
It got to this point where we’re starting to swap things out from Bootstrap and we really needed a way to get that information out to our developers who needed it.

Craig: I totally get that you need your own set of documentation because you got to be able to add to it, override things and stuff like that. Where you were to start a new style guide today from scratch, would you start with one of those frameworks and then build around it? Since there is so much man hours put into worrying about all the browsers and stuff or is it not that complicated if you really have done it a few times?
It’s easier to start from scratch.

Cameron: It depends on the application and the site. If what you’re going for can be achieved within the limitations of those frameworks, I think those frameworks are a great place to start. They’re a great first iteration. Maybe two or three iterations down the road, you start to pull those out. You start to swap them in with your own thing.
If out the gates, you’re going out. You already can identify on one hand things that you’re going to need to change or new things you’re going to need to introduce. Then I would almost say stay away from those. May be pull from them from a framework perspective. Maybe stay away from those. Go with something else like bourbon or meat that gives you those tools, but you’re not confined to a frame work.

Craig: This is a little bit of topic, but I hear a lot of buzz about the Goggle material design lately. It seems like what they’re starting to put out there is something similar to a style guide. I’m trying to make sense of all this stuff in my head. Can you help it all in?

Cameron: Yes. Goggle’s material design, especially their documentation, is probably one of the best. I should have mentioned this earlier, but probably one of the best style guides that I’ve seen. Just because of how thorough it is. How much information they give you.
It also goes back to what you’re talking about before where you have one style guide for one too many relationship. One style guide for whole bunches of sites and whole bunches of applications. It’s centralized, and it’s very concise. I think that they’re doing a great job of applying that to all of their applications and all of their sites. They’re really unifying under one brand.

Craig: That’s great. It seems like it’s still maybe…it’s infancy a little bit.

Cameron: Yeah. We’re going to see the idea. Not just Goggle’s material design and what that looks like right now. The concept, the material design, is going to…We’re going to see that evolve and really take off in the next…I don’t know two to three years.

Craig: It’s been a pleasure to have you on the show. Anything in particular you want to send people to your blog or things like that?

Cameron: You can check out my blog at I don’t update it very much, but hopefully maybe this year it will be a resolution of mine. If anybody is interested in style guides, check out my GitHub repo. Honestly, go check out
Debenham created this site. It is amazing. It has way more information than I could have ever imagined to gather, and it’s open sourced. If anybody has anything to add to it, feel free to do that. I don’t want to speak for her, but it’s a great site. I keep telling people about it. It’s amazing.


Cameron: Yes. It’s amazing. It came out a month or two ago. It has completely changed how everybody looks at style guides because just so much information, so many different perspectives, articles, books, presentations, links to style guides, and things like that. If you want to know anything about style guides, that’s the place to start.

Craig: Thanks again for coming on.

Cameron: Not a problem. Thanks for having me.

[background music]

Craig: Thanks for listening to the Front-End Developer Podcast. Please subscribe to the podcast by going to the iTunes store on your phone or desktop then searching for Front End or via RSS by going to where you also find show notes and a full transcript of each episode. You can also sign up for my free Angular JS Backbone and Ember Crash course.
All of them solve the same problems. Why not learn them together? See you next time.


Tags: , , , , , , ,

2 Responses to “Style Guides and Pattern Libraries with Cameron Wardzala | Episode 11”

  1. Manuel July 16, 2015 at 11:29 am #

    You might find this article interesting =)


  1. Dew Drop – July 15, 2015 (#2054) | Morning Dew - July 15, 2015

    […] Front-End Developer Podcast Episode 11 – Style Guides and Pattern Libraries with Cameron Wardz… (Craig McKeachie) […]

Leave a Reply