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

Where I Falter

“Uses promptos facit.” — Latin, loosely translated, “Practice makes perfect.”

Earlier last week, I read an article about how a scientific study on practice as it relates to talent, conducted by Dr. Gary McPherson and Dr. James Renwick from the University of New South Wales, Australia, debunked the “10,000-Hour” rule. In summary, the study hypothesizes that talent is something that emerges from practice, but only when certain conditions are met. The most interesting condition to me was the final one in the article:

Strong, Direct, Immediate Feedback. Can you sense when you’re making mistakes and when you’re not? Can you use those mistakes to guide you to better performance?

This is one of the hardest things for me to do relating to practice. It’s very easy for me to gloss over my own mistakes, mostly because I don’t realize when I make them.

Recognizing Mistakes

One of my most favorite songs ever is John Mayer’s Why Georgia. Say what you want about John Mayer, he is a guitar acrobat, and this song really shows off his unique finger-picking style. In my admiration for this song, I decided I was going to learn it. That was about three years ago, and I still have yet to master it. It’s not for lack of time spent practicing, either. It’s because I don’t recognize my mistakes.

Essentially, I focus on certain things like chord structure and voicing, then overlook others like fingering trouble spots and incorrect rhythm. I want to understand the music, but I stop just short of mastering it.

The funny thing is I can correct this pretty easily. All I have to do is start recording myself, and all of my mistakes magically come into view. Pretty easy fix, right? My next thought is, How does this relate to me growing in the field of web design and programming?

Showing My Work

I have no idea at the end of the day how I’m making mistakes. I’m not sure I have a holistic enough understanding of the field to help me grow the way I want to. I think this may be where mentors and forums like Stack Overflow can come in real handy. Maybe the code version of recording a practice is to just post your code for experts to see.

To be honest, I’m a bit scared to do that. I have a tendency to keep myself happy by keeping everything I do to myself. Of course, that’s not a way to grow by any means.

When I can get up the courage to have others show me where I falter, I can begin to grow to the level I desire.

And Now for Something Different

It’s been a few months since I began pushing further into the world of designing for the screen, and I have thoroughly enjoyed the change of pace. One of the things I find the most fascinating is the ability to make my own tools. To clarify, building tools isn’t always necessary, but the experience gained in making them is priceless.

Currently, I’m working on an app for my day job. It’s basically a to-do list, but with a few modifications that tailor it specifically to my work environment. When it’s done, it will hopefully streamline the creation of my daily job progress report, nicknamed the Hotsheet. Basically, the Hotsheet is just an HTML email of work project tasks, when they’re due, as well as other bits of information that are important to the progress of a particular job.

The idea to build an app was born out of a persistent problem that bugged me. One day I was entering in project information and realized how much I was repeating myself. The project managers I work with print out production sheets that contain due dates for all major milestones of each project, and I found myself hand-keying each item into an email, finding the due date, and then manually updating the status (e.g., late, need item, etc.).

I’m a fairly careful person, but nobody’s perfect; I would forget to update tasks, projects were missed because they had been added after the latest production sheet, dates changed, etc. Coupled with an outdated and very WET system for tracking each individual project, this presented a great opportunity to simplify and automate.

I read this great 24 Ways article that inspired me to learn Ruby on Rails by digging deep into the trenches. So, that’s what I’m doing. When I’m done, I’ll hopefully have something of value that could possibly help out my print design compadres. Or, at the very least, I will have gained invaluable experience. I’ll keep this blog posted on my progress.

The Great Discontent Redesign

That other Ryan and Tina just rolled out a redesign of their excellent online interview mag The Great Discontent. I thought it’d be a good idea to break it down a little bit, especially since I’m still gathering inspiration for my FDGB redesign.

I think the biggest change on the website has to do with the IA. TGD’s almost three years old, and now that the site’s content needs are better defined, the structure has changed accordingly. Blog posts have now been broken out into a separate Blog page, and interviews can now be easily filtered on the Interviews (formally Archives) index through a more prominent tagging system. One of my favorite additions is the Recommended tag in the Interviews section. This really helps guide a new user through some of the best interviews TGD has to offer.

Typography has always been one of TGD’s design strengths. The main block copy and pull quotes are set in Leitura News, a smart serif face with editorial roots designed by Dino dos Santos, and the headers and various other pieces of micro copy are set in Maison Neue, a friendly contemporary sans-serif designed by Timo Gaessner. One nice detail about the layout is that FlowType.js is being implemented to ensure a comfortable line measure is always employed.

The layout, as before, is minimally elegant, but now reflects the new print magazine design, with Mondrian-esque thick black borders that section content and lead the eye. It manages to be at once both playful and poignant. The main hero block of every interview is still art-directed, and can now be either landscape or portrait, black-on-white or white-on-dark.

Overall, the redesign keeps everything that works about TGD while better defining its ancillary content and making once-buried-but-useful features more prominent. It even looks beautiful in the source code. TGD is a website I have constantly frequented in the past for inspiration, and this refresh will keep me coming back for the foreseeable future.

If you haven’t already, go and bookmark The Great Discontent, and start digging into its rich history of creative industry reviews.

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.