Archives For Development

The use of pattern libraries (or style guides) is becoming more and more popular these days (if you’ve never heard of a pattern library before, I have some great articles about them listed at the bottom of this post). The idea has intrigued me for awhile, but because I work on mostly smaller sites and mostly as a one-person team, I didn’t see the benefit (or at least enough benefit to make the effort worthwhile). Although it’s true that many of the advantages that come with using a pattern library don’t exist for many of my projects, I finally decided it had enough benefits to integrate into my workflow.

The Benefits

I knew that to make a pattern library worthwhile for my workflow, it not only needed to help keep my code clean and concise & my designs consistent, it needed to improve (and speed up) my workflow. I used the A Pattern Apart & BareBones to create the framework of the pattern library and then added my own design and code snippets to create the various patterns. The result: a boilerplate pattern library that I can use as a starting point for each of my projects. I put together common elements that I use in almost every site in the pattern library (buttons, headings, navigation, etc.). This way when a new project begins I can change colors, typography and a few basic styles and within a few minutes have a pretty solid starting place for a style guide for the site. I have a few default patterns in the library, but usually customize, add, and remove sections based on the site I am working on.

The Details

Below I break down into a bit more detail the organization and setup of the pattern library. I have loaded the pattern library (with a few modifications described below) to GitHub, so feel free to dig in and explore. Keep in mind this is still very much a work-in-progress and I am by no means a front-end guru, so if you have any thoughts, suggestions or corrections, I would love to hear them.


One of the biggest benefits of a pattern library in my mind is organization. The importance of organization becomes magnified as you work in larger teams, but it is still important on one-man projects. Keeping your code organized, well-documented and easy to read allows future developers that may touch the code to get up-to-speed as quickly as possible (whether they are on your internal or the client’s team).

  • File Structure: I have all css, js, fonts, images and other media in a subfolder called ‘library’ (each in their own subfolder). I do this in all my sites. This helps keep all of those items organized in a single subfolder and easy to find. All of the pattern elements are located in the ‘pattern’ folder as individual HTML files. These files are automatically pulled into the main pattern library page using some PHP code.
  • CSS: I use LESS as the pre-processor when writing CSS. I have the CSS divided into 8-10 .less files that get merged into a single .css file when compiled (using CodeKit, which is amazing!). The key here, as Susan Robertson so wisely wrote in her article Creating Style Guides, is to use the same CSS from the live site within your pattern library. This means as you update CSS for the site you can a) make sure the changes are consistent with the rest of the site easily and b) make the change once. As Susan wrote, ‘If you have to do extra work to update your style guide when making changes to your look and feel, the likelihood of it staying up to date is pretty slim.’
  • JS: All JS is compiled and compressed into a single production.js file via either CodeKit or Grunt before being used in the site. Before the code is compiled, I have my JS divided into a plugins.js file with all external, plugin code and a main.js file with all hand-written, project-specific JS.

Colors & Typography

The colors and typography aren’t necessarily patterns, but help define the overall site’s brand. I wanted to have them at the top of the page to quickly give some reference to the palette and type used throughout the rest of the patterns. These colors also align with the color variables I use when writing LESS to make sure all of the colors used throughout the site stay consistent.


The core of the page consists of various patterns. From buttons to navigation to form elements, the various patterns represent pieces of a site that go into making the larger whole. A few quick notes about some of the various patterns/sections found throughout the library:

  • Global: I include the footer, head and header elements of the site here. These are great starting points when beginning a new site.
  • Headings: Recently I have begun use ‘-alt’ to create secondary header styles for a site. It opens up a lot of potential. One area I am having difficulties determining the correct route to go is using the semantic heading style vs. the one that is sized correctly. For example, setting all h2’s to be 2.25em makes the code really concise and easy to follow, but it encourages you to use a h2 tag for a heading where you otherwise would use an h3 or h4 because the h2 is the appropriate size.
  • Icons: For almost every site I include a set of 40-50 icons from the free Font Awesome set. These are more generic icons that can be used for social links, navigation drop-downs, etc. They are fairly generic so they work stylistically with most sites and are fairly lightweight. I then include a secondary set of icons that are more specific to the site. I don’t include a secondary set in GitHub because most of the sets are ones I have purchased that require a license. On the example site I include the entire set of Streamline (an awesome—and huge—icon set). I would never include all of these icons in the final project, but this acts as a reference to quickly find the icon and the CSS class value. I use Fontastic to create versions of the set with only the icons I need.
  • Patterns: This section is always growing. I create elements that I reuse in many sites and then pick and choose based on the site. Any site specific elements usually go in this section as well.


As I mentioned above, I am still at the infancy of using the pattern library and determining how it best fits into my workflow. At this point I have been mostly using it as a guide for myself and not sharing it with the client until the end of the project. I could easily see it becoming a great tool to use with clients early on (before even beginning initial designs) to give them options for color, type, etc. before even having to open Photoshop (kind of a different approach on Samantha Warren’s Style Tiles concept). I would love to hear what you think of the pattern library, any suggestions you have or ways that it could be improved. If you are just getting started with pattern libraries and would like to see some great examples, check out these:


If you would like to learn more about style guides and pattern libraries, here are some of my favorite articles:


View the Pautler Design Pattern Library

I recently returned from the An Event Apart conference in Austin. An Event Apart is—in their words—the design conference for people who make websites. They bring in some of the biggest people in the web design industry to talk at the conference. Names like Jeffery Zeldman, Luke Wroblewski, and Ethan Marcotte are known by almost every web designer. Throughout the few days I was in Austin there were many social gatherings including the Dribbble meet up on Sunday night and the awesome opening night party at Frank’s Monday. After going to the conference and talking with the speakers, people attending the conference, and some designers from Austin, I realized something. The web design community is awesome. It’s that simple. I’ve known it for a long time, but my time in Austin really solidified it. I would not want to work in any other industry. There are a lot of reasons that I love working in the web design industry. There is one reason, however, that I think is unique to our industry and which makes our community so amazing and rewarding. It is rare to be in an industry where the most experienced and successful members of the community are so willing to help the rest of us stumbling along in an effort to create something amazing on the web. The awesome speakers at An Event Apart are just a few examples. Individuals like Brad Frost, Scott Jehl, Chris Coyier and the three amigos at Paravel immediately come to mind as well. Brad is one of the most respected individuals in the responsive web design community and yet he has spent countless hours putting together amazing resources on responsive design that he shares freely. Scott has worked on some of the most important web development advancements over the past 10 years and yet will always answer your tweet in a matter of hours and has a GitHub repo with years of code he has written that he shares with the community. Chris runs one of the most well known CSS sites and yet is happy to have a discussion on the best way to build something on the web. Trent, Dave and Reagan have worked on huge projects like the Microsoft site, and yet when I met them at the Dribbble meet-up last Sunday in Austin, they remembered having Twitter conversations together and said to write them anytime I needed help. These guys are just a few examples of people who are big names in our industry and are not just willing, but excited, to help others in our community grow and learn in an effort to make our industry better. How awesome is that? How different is this from so many other industries—even other industries in the design world? I could not be more proud to work in the web design community and I can’t see myself doing anything else. Thank you everyone who makes being part of our industry so fun.

I’ve known the benefits of version control for quite a while now. I’ve dabbled in it a bit, but haven’t taken the plunge. That will soon change. I have finally made the decision to move most, if not all, of my personal sites and client sites over to GitHub in the next few months (deadline: end of August). I looked at a variety of options and determined a) Git is the best version control option and b) GitHub is the simplest and easiest way to use Git (especially if I don’t want to touch the command line, which I don’t).

I have been hesitant to start using version control for three primary reasons:

  1. Although fairly simple, there is a time investment and learning curve when it comes to setting it up. I simply haven’t had—or better said, made—the time to get it all setup.
  2. I have other ways to back-up my code, so why do I need version control. Between Time Machine, Packrat with Dropbox and manual backups, I thought I was covered with back-ups and so had no need for version control. I slowly realized this isn’t really the case and that version control has a lot of other benefits outside of backing up your code.
  3. I’m currently a one-man team, so managing all of the code locally works great. It is true that I loose some of the benefits of collaboration that comes with GitHub simply because I have no one to collaborate with many times. That said, I have found it is always better to get a good framework in place before the need really arise for it just to be prepared.

It may seem strange to write this post now, before I have made the switch. I am doing so for two reasons:

  1. Accountability. I’ve been saying I am going to do this for months now. I am hoping now that I have it in writing this I will make the commitment to actually do it by the end of August.
  2. Support. I would love to hear from any of you who have gone through this process before, what you learned, any suggestions you would make, etc. I’ve read a lot of articles, but at the same time am kind of winging it, so I’d appreciate any suggestions or support people can give.

My end goal with moving my sites to GitHub is three-fold:

  1. Tap into the benefits of version control with my code, so I can use branches, etc. to make changes to sites without effecting the live site.
  2. Organize my sites’ code. I currently have a process where all live sites are in my computer’s “Sites” folder and then I move them to the job folder once finished. This works great in some situations, but situations when I am continually making changes to the site or there are multiple versions of the site, it gets a bit hairy to say the least. Folder names like “sitename-new-prewordpress” are never a good thing.
  3. Although all my files are on Dropbox, having another cloud backup is never a bad idea.

I am hoping to write a second post in a few months once the process is complete to share what I have learned and the process I took. Stay tuned.