Anyone that knows me heard me say “Embrace the fluidity of the web!”. Atomic Web Design is a concept that I always circle back to whenever I’m talking about web. I am also a big fan of sass, and also of Zurb Foundation.
We were able to use a lot of those ideas on a hbr.org’s new responsive site, which launched November 10. My colleagues, Kevin Newman, Fred Lalande, Matt Wagner, Kevin Davis and I just did a presentation on SASS and Pattern-Lab team workflow using Vagrant/Puppet at our Boston CSS meetup, Cascade Bos. Topic was really wide, we talked about anything from Object-Oriented CSS to Web-based Style Guide to deployment method to… everything. You can go through our slide deck here.
But for the “workflow” part, here is the gist of it.
HBR’s pattern-lab work flow
- Instead of installing all our dependencies — such as php and apache for pattern lab, ruby and compass for css preprocessor and node for grunt and bower — into each of our individual computers, we have a Vagrant/VirtualBox virtual machine that are committed in our github repo.
- What is really nice about Vagrant is its pass-through file system. Meaning you can edit the file on your OS (be it Mac, Windows, or Linux) using your favorite text editor locally (without going through virtual window), and it can be accessed by both host and virtual machine.
- So we edit our
www/source/_patternfolder right on our machines. Then, with power of grunt, you can view your changes appear on your browser, served right from your VM.
- After we like what we see on our local machine, we make a pull request (we commit the whole thing, Vagrant and everything) in github. We have a internal agreement that you don’t merge your own request… so it gets reviewed by peers and then, eventually, gets merged to the master branch.
- Then our hardest working member of the team, Mr. Jenkins, who watches the changes on the master branch, sees that it changed. And he pulls the latest, compile sass, compile pattern lab, and then he puts the
publicfolder part of the pattern lab onto our internally available web server (is “intranet” still a word?). This is our living style guide. Our backend developers uses it to grab markup code out of it. Designers and editors, as well as marketing people, can access it any time they want.
- Only part that goes directly out of our pattern lab to production is compiled CSS (it gets minified on its way to our production). But CSS HAS TO BE EDITED IN pattern lab, which forces everyone to first create a new pattern inside our pattern lab. This also ensures that our style guide is most up to date. Win-win!
That’s basically our workflow. I understand that pattern lab is not the silver bullet that works for everyone, but I am pretty proud of how it turned out for us. Another nice thing about committing your entire dev environment in the repo like this, is, say, if you spilled a full glass of red wine on your MacBook Pro by accident (Oops!). All you have to do next day is to get a loaner from IT and download your text editor and you are right back at it. If I had to install node on my machine again ON A DEADLINE, I think I am going to cry. But anyhow…
One of the thing that I wanted to do was release public version of our pattern lab github repo. One without styles in it, and one that is a stand alone virtual machine which runs Pattern Lab.
And, lo and behold, (Thanks to Matt Wagner and Kevin Davis) we were able to release it. It is available for you to download.
Check it out. Star it, fork it. Comment it. File issues on it. Even make pull request on it!
I would absolutely love for you to try it out and let us know what you think.