Category Archives: Workflow

A Change of Pace

Beginning with my last post, I have changed my blogging workflow. Before, I was typing up and proofing drafts in Google Docs, then transferring them over to WordPress, (which, as of this writing, is what this blog is built on, in case you’re into that sort of thing).

The main idea was that I would write a post and then have the ability to share with individuals to get as many eyes on the post as possible (a la Editorially). That was a pipe dream.

Now, I love Google Docs, but not for writing blog posts. For one thing, I write in Markdown to separate presentation from document structure. I don’t want to continually apply a format to imply content hierarchy when I’m stream-of-conscious writing, but that’s what ends up happening in Google Docs. I’m sure there’s a nice plug-in out there to allow me to write in Markdown on G-Docs, but I have yet to find one (if any one of you spam bots out there know of a good one, let me know).

What I’m really looking for is a way to visually represent the Markdown structure while maintaining the keyboard-only workflow Markdown offers, which is something Editorially did out of the box. Sadly, even WordPress’s text editor, which does indeed support Markdown, doesn’t do this, but at least I’m seconds away from a preview screen.

Another thing I don’t like about my old workflow was the transition from Google Docs to WordPress. It felt so disconnected. I can’t really describe it any other way. And now that I’m typing directly into the text editor, I feel a sense of immediacy or instant gratification. I think the change has even inspired me to write more.

It’s pretty amazing what a change of pace can do sometimes.

Lessons Learned: Tina Boone Website Redesign

I’ve written a few times about the process behind building my wife’s website, and to celebrate its official launch, I wanted to share some problems I encountered and lessons I learned throughout this project. I’ve also included a list of resources that were invaluable during this build.

Pattern Lab

I started this one-page site with Pattern Lab because I wanted to establish a style guide driven workflow. Pattern Lab helps implement that approach, but I don’t think it was very efficient for such a small project like this.

In fact, I ended up abandoning the framework about 75% in to the project, which added time and effort. This, admittedly, has more to do with my newness with Pattern Lab than any inadequacies with Pattern Lab itself. I still believe it’s a great tool for responsive design, and I will be using it extensively in the redesign of FDGB. In the end, it was still a great introduction to the workflow.


I tried to stick to the SMACSS way of styling components, and one of the things I found I found myself struggling with was separating style from structure. This is a core fundamental of SMACSS, as well as OOCSS, and following it really helps the organization and scalability of a site’s styles. I think finding these difficulties out right now will help me better structure CSS in future projects.


Going into this project, I knew what AJAX was and why it was so useful, but I really didn’t know anything more than that. I learned that AJAX involves using a JavaScript object called XMLHTTPRequest that, if supported, allows the browser to pass information to and from the server without refreshing the page. Both Treehouse’s AJAX Basics course and Mozilla’s Developer Network were great sources for learning how to evoke an AJAX call.

Plan for Performance

As of this writing, Tina’s site doesn’t perform very well in terms of speed. I will be optimizing images and CSS as I get time, but I would’ve definitely save time and effort if I had simply planned a performance budget from the very beginning. I have to admit, I’m not very experienced in this area, and any attempts at setting a budget would’ve been merely guesswork on my part. I definitely look forward to growing in this area.

Browser Bugs

I knew that no two browsers were quite the same, but I was fascinated by the odd bugs I found in very modern browsers. As of this writing, the latest stable build of Safari has trouble applying a transition to the fill of an SVG anchor element once that link has been visited. The handling of color profiles as well seems to be all over the map, making it a headache to achieve consistent color between browsers. Note the differences in the color between Safari and Chrome:


Comparison of Safari 7 (left) with Chrome 37 (right). There’s a slight difference in the CSS defined background color. It’s much more pronounced on my personal monitor with a custom color profile.

At the end of the day, I realize that it’s not the job of a web developer to achieve total consistency between all browser, but to achieve an acceptable compromise.


I think overall I’m happy with the final results. There are a few tweaks that need to happen, probably the biggest being PNG fallbacks for the SVG elements, as well as a full CSS audit, but I believe the end product is very close to what was designed in the beginning. It’s functional, usable and has a very friendly aesthetic. The lessons learned here have helped me grow as a front end developer and as a designer.

Now, on to the next project!


Pattern Lab
AJAX on Mozilla Developer Network
Brad Frost on Atomic Design
Responsive Design Workflow by Stephen Hay
Google PageSpeed Insights

Pattern Lab Workflow with CodeKit

As I’ve mentioned in earlier posts, I’m using this project to explore Atomic Design methodology, with Pattern Lab spitting out an easily-maintainable style guide. At first, I felt like I was stumbling all over the place, but thanks to CodeKit, I’ve gone from crawling to walking.

So, here’s my Pattern Lab workflow as it stands now:

  1. With a look established in Photoshop or InDesign, I jump into Pattern Lab, making sure startWatcher.command is activated.

  2. Also, I make sure CodeKit is open. I have it watching the entire Pattern Lab folder so it can compile my Sass files in “source” while still being able to auto-reload the index located in “public.” I click “Preview” to pull up the style guide in the default browser (I’ve set a custom path to the index file since it’s located in another folder).

  3. I select or add the appropriate mustache file and, as best I can, semantically mark up the component, then save it. The Pattern Lab watch command automatically generates the new site with the added component, and CodeKit reloads the browser, which I keep on a separate screen. The great part about Pattern Lab is that you change the “browser” width within the browser, so I can check certain media queries without leaving full screen mode on my Mac.

  4. Next I add the Sass/CSS to style up the component. Hitting save on a Sass file triggers CodeKit to recompile all the Sass and inject it live into the browser.

Before adding CodeKit, I had to use the command line to compile the Sass, manually reload the page, then scroll down to where the component was. It. Took. Forever.

It’s important to also note that I’m using Autoprefixer when compiling the CSS. It just makes things so much easier on anyone writing CSS, plus it’s built into CodeKit, and all I have to do to use it is check a box. Completely painless.

So, that’s my Pattern Lab workflow is shaping up. You could go hardcore and use Grunt or Gulp, both of which are free, but for the sake of ease, CodeKit is just amazing.

Update: After working with this setup for a while, it’s become increasingly annoying how both CodeKit and Pattern Lab both refresh the page. This becomes exponentially problematic the bigger your project get. I did some digging and found a post from Dave Olsen, the main PL developer, and he says “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.


Atomic Design and Pattern Lab Part II: Design

I wanted to write a quick update on my latest website design project. I’ve been working on a redesign of my wife’s website on and off for a bit now and have found that I keep bouncing back and forth between designer and developer, designing static element collages in Photoshop and coding out components in Pattern Lab. This seems to be the optimal workflow.

The thing I’m having the most difficulty with right now is that I’m using a lot of the Sass files that come with Pattern Lab, rewriting as needed. This may or may not be the best approach. The pros include getting to see a well-designed and maintained example of BEM notation as well as a look at a wonderfully organized Sass include structure. Lots to learn from there.

What I get hung up on is that it’s somebody else’s code, and no matter how beautifully well-done it is, it’s hard to wrap my head around what’s going on when I’m not producing at the same level of code. I know this will get easier in the long run, but for now, it’s a bit slow-going. I may just download another instance of Pattern Lab, start from scratch in my current build, and just refer to Brad’s files for Sass organizational inspiration. The beauty in having no deadline and an understanding client make it easy to experiment with these sorts of things.

Coming from a print world, I’m certainly much more comfortable in Photoshop. I’m using PS as a way to demo looks and feels rather than comping an entire website. I’m more interested in animations and transitions from different browser and device widths. Photoshop allows me to just build the look I need quickly, and speed is what I’m more interested in at this point. But only after tons and tons of hand drawn sketches.

So that’s it for now. I may or may not start to post some images of my sketches. I’ll have to check with the client.


Designing with Atomic Design and Pattern Lab

For the past few weeks, I’ve been redesigning my wife’s website using a process called Atomic Design.

Atomic Design is the web design philosophy that sees individual elements of a website, e.g. an input (<input>) or paragraph (<p>) element, as atoms that can combine to form molecules (e.g. a search or contact form), which then combine to form more complicated organisms (e.g. a site header or footer), which then combine to form a page. Brad Frost, a super-smart front-end developer whose blog I frequent and work I frequent, coined the term.

Pattern Lab is a tool created by Brad and the (also) super-smart developer Dave Olsen to help streamline the process of showing the design to clients. You can learn more about it from several sources across the world wide web.

I mention all of this because I’m curious to see how different people are using Pattern Lab in their workflow. And with that in mind, I want to publish some posts about my experience with Pattern Lab. I hope they can be informative, and with a little luck, maybe I can learn more about it as well.

Do you use Pattern Lab? Leave a comment and let me know how you use it or any thoughts you have about it. I’m all ears, figuratively speaking, of course.

Do you want to use Pattern Lab? You can start by downloading the files on Pattern Lab’s site and reading the docs. Enjoy.