The Simplest Things

I was helping a friend this evening who is having to do front-end web development for the first time. He knows about enough CSS to hang himself, so he asked me to give him a few pointers. We talked about ems and we discussed padding and margins. I covered the basics of precedence, and I explained that he really shouldn’t be using complex Sass nesting.

Out of all of it, though, I think the one thing that will help him the most was the simplest little thing. He’s been using Chrome’s developer tools for months, but he didn’t realize that you can click the little magnifying glass to switch to “inspect” mode within the browser window. All this time, he’s been hunting through the DOM. Just think of the number of hours that little tip will be saving him.

Practicing What I Preach

I mentioned yesterday that I’m working on some major product improvements. They’ve been a long time coming. I’m taking advantage of this situation to institute a design pattern library. Each UI element we design is being implemented as a plug-and-play component with modifier classes that handle different uses. As we go, we will document each component, explaining when and how it should be used. Every library entry will include a screenshot and an HTML snippet. More complex components will include multiple examples to illustrate different states and contexts. We’re doing this on our development wiki where all of the developers will be able to access it. Eventually, it will be possible to assemble entirely new screens in minutes by simply copying and pasting code out of our pattern library.

If you would like to learn how to do this for your company, consider attending my workshop at Midwest UX 2014.

Designer’s Toolbelt: Icon Fonts

I’ve been aware of icon fonts for awhile, but I wasn’t particularly interested in using any of the free ones out there. Don’t get me wrong, Font Awesome and Entypo, among others, are lovely icon sets with hundreds of icons to choose from, and for all those UX professionals and front end developers that don’t have the talent or the time to create their own icons, they’re a god-send. That said, they are still limiting, and they entice you to settle for something less than optimal. When you are working on enterprise software for specific industries, you’re going to require a lot of icons that aren’t covered in a typical set. Furthermore, you should remember that your UI is your brand. The iconography is a significant part of that. An application’s icons should match the sensibilities of the industry, customer, and users. Add to that the fact that I’ve already established a robust iconic vocabulary over the past 14 years, and you can begin to understand why I’m dead set against using a generic icon set, free though it may be.

Now, that doesn’t negate the huge technical benefits to using icon fonts. Especially now that we have retina displays and responsive layouts for all screen sizes, the ability to specify the size, color, and effects of a vector graphic in CSS is irresistible. So, where does that leave me?

I finally took the time today to research what is involved in creating your own icon font. It turns out that it’s quite simple, thanks to some excellent tools. I turned an Illustrator file containing my UI icons into a bunch of SVG files, imported them into IcoMoon, and had a font file downloaded in a small slice of my afternoon. Other tools you can look into include Fontello and Fontastic.

I’m in the process of doing some significant improvements to our products, and this is going to be the way I handle all of our icons going forward.

Book Launch

To commemorate the launch of my book, which is now shipping from Amazon and Barnes & Noble, here is the Preface.

As tends to happen with experience, my convictions have morphed over the course of my career. As a graduate student studying interaction design at Carnegie Mellon University (CMU), I was of the opinion that designers shouldn’t need to know how to code. We should have tools that give us complete freedom to create without requiring knowledge of the technical bits that are necessary to realize our visions. Looking back at my younger self, it seems hypocritical. I had already learned the technical process of offset printing—not enough to set up and run a press, mind you, but enough to know the difference between process and spot colors, how to specify them, and how to design a brochure with only two colors to keep the cost down. I knew that I had to include an extra margin if I wanted an image to bleed off the edge of the page. As it turns out, I had to learn a lot about the production process to be an effective graphic designer. Why did I not expect to have to do the same to effectively design for the web?

I was quickly disabused of the notion once I took a job with a software development firm where I was expected to hand over HTML that developers could cut and paste into their Java server pages (JSPs). My screens may have looked fine, but the what-you-see-is-what-you-get (WYSIWYG) editor I was using generated terribly ugly code. So it was that I began down a path that resulted in the book you hold in your hands now. But it isn’t just a book about code. More important than learning how to write clean Cascading Style Sheets (CSS) is learning how to integrate with your development team.

You see, when I was first hired by that small software development firm, I was set to work on a complete, ground-up redesign of their flagship product. This was to happen in parallel with the development team rearchitecting the product. The company was young, and I was inexperienced. I was advised by another designer who had been with the company since its inception to not show my work to the developers until I had polished it to perfection. I’m sure you already sense the train wreck that was coming. Sure enough, after months of brainstorming new features and iterating over pixel-perfect screen mockups, I presented my work to the developers, only to be told, “Hey, that looks great, but our architecture assumed the same functionality and a similar interface to what we have now.” They were too far down their side of the tunnel to come back for me, so my fully designed and specified user interface (UI) was shelved. I learned a valuable lesson the hard way, and since then, I’ve worked diligently to integrate myself tightly as part of the development team. Doing so has paid great dividends, and I’d very much like to share them with you.

I’ve now been working for that same company over 13 years, during which time I’ve been able to merge my design process with that of the developers. I use many of the same tools they use for task assignment, issue tracking, version control, and documentation. Where once upon a time I would hand over my designs to the developers for implementation, I now participate in implementation, ensuring that every detail of the design is translated correctly by contributing directly to the production code base. And that brings us full circle. If you want total control of your design, from its first inspiration to the day the finished product ships (not to mention future revisions), you have to participate in the entire development process. That means you should be able to write production-ready HTML and CSS. That’s why I decided to write a book that is one part down-and-dirty code tutorial and the other part ideological process and collaboration. Both parts give practical advice, some of which you can put into action immediately, and some you can begin to plan and build toward.

One person who has the skills of a visual designer, an interaction designer, and front-end web developer is often referred to in our industry as a unicorn—a magical, mythical creature and the object of many a great hunt. If you look at natural history, you’ll find many plausible origins for the legend of the unicorn. You’ll also find a number of creatures that, while not matching our perfect envisioning of a unicorn, are nonetheless creatures with four legs and a single horn. I posit that there are actually quite a few designers in the workforce who meet the base-level description of a unicorn; they just don’t have the opportunity or direction necessary to meet their full potential. Perhaps you are one of them? My sincere hope is that this book will be the incentive that leads you to take that next pivotal step in your career.


Our proposal to bring Midwest UX to Pittsburgh is almost ready to go live. Our design lead decided to give Wix a try to build our site. I’ve been doing some editing tonight, and I’m unimpressed. For one thing, it didn’t work in Safari, but that was the least of my issues. I realize it’s probably a great tool for someone that doesn’t know how to write HTML and CSS, but I found it extremely limiting and pound-your-head-on-the-desk frustrating to use. Unless you want to be tied to the specific designs they’ve made available, you have to “customize” your elements. When you do that, they no longer share their styles with any other objects, so if you have a list of buttons that have all be customized, and you decide you want them to be a different color, you have to change each one individually. I wouldn’t be surprised if there is some feature I don’t know about that lets you define styles, but if so, it isn’t obvious.

Sure, it makes it easy to add transitions, shadows, rounded corners, and to lay out a page, but you can have it. I’ll take my trusty text editor and a CSS file.

Midwest UX 2014 & Me

Last week, I took my annual vacation to a log cabin down in wild, wonderful Wes Virginia. During that time, I was completely off the grid. There’s still no cell phone signal in the valley, and we don’t have a land line. Nor do we have cable or any type of internet connection. We can pick up a few radio and television stations via antenna. So, of course, everything happened last week.

Most notably for me, registration opened for Midwest UX 2014, and as part of that, they announced my full-day workshop, titled Bridging UX & Web Development. Yes, it’s named after my book and will be based on it. I’ll be leading the workshop on Thursday, October 23rd. We’ll work from 9:00 am to noon, break for lunch, resume at 2:00 and finish at 5:00. Here’s the really cool part: it’s only $200. I know! Don’t miss this opportunity to improve your CSS chops and learn how to contribute to your team’s production codebase.

Documenting State

As I continue to refine my employment of OOCSS, I’m also improving the process by which I architect and document the UI. Until now, I’ve waited until implementation to think about the state classes I need and how they will be used. They have only been documented as comments in the HTML. States would be specified, but without any instruction as to how to enact them.

In the past two weeks, I’ve been working on a very detailed UI behavior specification for a complicated form (complicated behind the scenes to make it clear for the user). I figured out the various UI states that I plan to control with CSS and included state classes in my specification document. Now, I not only explain the behavior that is to occur, but provide the state class that can be added or removed to enact it. This is a significant step in improving collaboration with my development team on the CSS architecture. It also forces me to think more strategically about how I intend to implement the front end.

Three Things You Should Know This Week

  1. Midwest UX published their call for speaker proposals on April 1st—no foolin’! The conference will be held in Indianapolis, October 23-25. They’re looking for 30 and 45 minute talks, as well as full and half-day workshops. The submission deadline is June 1st. Get on it.
  2. Macaw, a new web design tool that works like a graphics program but writes semantic HTML and clean CSS, went on sale Monday. You can try it for free.
  3. Unicorn Institute announced today that they are accepting applications for full-time UX educators (aka Unicorn Wranglers). I’d apply myself if it weren’t for the fact that I would have to move to Tennessee. Nothing against the state, mind you—I’m just very happy where I’m living now.

Review: Sass for Web Designers

I’ve been reluctant to dip my toes into the waters of CSS preprocessors. I don’t like the idea of having to compile my CSS for it to render, of having non-standard compliant code in my files, of introducing a new standard that none of the developers will know anything about. Of come up with all kinds of reasons not to even try Less or Sass. Dan Cederholm felt much the same way. Then he dove in head first and ended up writing a book about it.

Sass for Web Designers is another great, little book from A Book Apart. I’m a big fan of Dan’s previous book, CSS for Web Designers, so when I saw his name on this one, I figure I ought to give it a shot. At just under 100 pages, I figured that even if I decided it wasn’t for me, I wouldn’t have to sink much time into it. I wasn’t disappointed, and I’m now itching to put it to use.

There is a lot to love about Sass, but the two main advantages to my mind are variables and mixins. Variables allow you to, for example, define a color once, give it a name (the variable), and then use it in multiple rulesets by name, rather than having to repeat the hex value. If you need to change it, change the variable’s value, and all references to it will be updated. Mixins basically do the same, except with chunks of CSS, rather than a single value. Define your drop shadow with all the various vendor prefixes and give it a name. Then you can use that name in any ruleset.

That’s just scratching the surface. If you are Sass-curious, I recommend Sass for Web Designers.


Rarely is there the opportunity to completely redesign a product’s UI, even when it is desperately in need of a redesign. Rather than completely ignoring the need, find ways to move the ball forward. For example, I’m currently adding a new capability to a product sporting the same UI it had in 2006 with HTML that dates back to 2001. Rather than implementing the new features with frames and table-based layout, I’m proposing some changes that will allow new screens to be implemented with modern CSS while leaving existing screens untouched.