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.

Pointing Fingers

I’m really digging the improvements in the latest incarnation of Safari’s Web Inspector. Here’s another supremely useful feature.

When you select an element, all of the browser dev tools list all of the rulesets that apply to that element. The list them in order of precedence, and they indicate which declarations are being overridden. So, whenever I’m trying to figure out why a style isn’t being applied, that’s the first thing I check. It’s easy enough to find the ruleset that is taking precedence. However, the ruleset may have multiple selectors, and they could be long, complicated ones. It can be a challenge to figure out which selector is the culprit. That’s no longer a problem in the Web Inspector.

As you can see in the screenshot, all of the selectors in that big block are gray except the one, little “p”. That’s the selector that is applying padding to the element that I have selected.

I owe somebody at Apple a beer.

Who Would I Hire?

I’m not hiring. I wish I were, but that’s another post. The discussion I mentioned yesterday got me thinking. If I were hiring, who would I hire, and what would I expect of them?

I’ll break it into two “what if” situations. First, what if I could hire a senior designer?

If I were given the go-ahead by my company to hire a senior designer, I would ideally want someone with a masters degree in Interaction Design or an equivalent discipline, but several years of work experience with quality work products and obvious familiarity with a good design process would be acceptable without the degree.

Ideally, I would want a designer trained in graphic design. It would be difficult to hire a single person without visual design skills, as I wouldn’t necessarily have anyone to collaborate with them on the visual design other than myself, and part of the point of hiring another designer would be to get work done that I don’t have the time for.

Ideally, I would want a designer with basic understanding of HTML and CSS. If they didn’t have this, I would be very clear that their hiring would come with the expectation that they aggressively learn it. I’ve created a tight integration between myself and the developers that I believe is important to extend to any future hires.

What if I could only hire a junior designer?

In that case, I would likely weight my selection heavily towards someone with strong visual design and production skills. Again, willingness to learn both the interaction design process and HTML and CSS production would be necessary. The visual design skills would allow them to immediately take over a lot of my production work, freeing me to design for more projects at once. Over time, I could train them up to become another unicorn like myself.

Okay, since this is all pie in the sky, I’ll throw in a third “what if”. What if I could hire both a senior and junior designer? In that case, I’d want to make sure that the senior designer had strong interaction design skills and process first and foremost. I would again weight the junior designer towards visual design. I would expect both to be willing to learn to code. As the team grows, I would worry less about having all three skill sets in one person, strategizing to balance the skill sets between the team members. What I wouldn’t do is hire a visual designer to just do visual design, an interaction designer to just do interaction design, and a front end developer to just do HTML and CSS.

It all comes back to Jared Spool’s statement:

“Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results.”

Designer’s Toolbelt: New Rule

Whether I’m troubleshooting a bug in Safari or testing cross-browser compatibility in Firefox, the developer tools like Firebug and Safari’s Web Inspector are invaluable. I’ll often work up an entire solution directly in the browser and then apply it to my source code. There is one absent function, however, that trips me up frequently.

I could add as many attributes to a selector as I liked, and I could add a class to an element, but I couldn’t add a new selector. I either had to write an inline style on the element, which is only going to affect that one element, or write a rule in my stylesheet and reload the page, losing whatever manipulation I’d done in the inspector. I’ve wasted a lot of time doing this.

The new version of Safari’s Web Inspector added a New Rule button in the Styles pane.

Select an element and press the button. If the element has a class on it, you’ll be given a new selector with that class. If it doesn’t have a class, you’ll get the element itself. But you aren’t stuck with that. You can edit it to be whatever you want. This provides an enormous amount of flexibility and makes the Web Inspector an indispensable tool (if you didn’t consider it to be so already).

Designer’s Toolbelt: Safari Web Inspector

Safari’s Web Inspector was updated in the new version that shipped with Mavericks. They corrected an oversight that has long existed in all of the browser developer tools, including Firebug. If a selector uses a pseudo-class, such as :hover, it will only apply when the element is in that state. This means that in the inspector, the style would only be listed as long as the cursor was hovering over the element in the page. There was no way to actually edit the style, because as soon as you moved your cursor down to click on something, the hover state was no longer in effect, and the style disappeared from the list.

Apple added check boxes at the top of the style list for Active, Focus, Hover, and Visited. Now you can select an element in the DOM, check the state that you wish to apply, and the browser will consider it to be in that state as long as you have it checked, regardless of where your cursor is.

My job just got a little bit easier. Thanks, Apple.

Unicorn Quest - Part 4

In my last post, I began analyzing Dave Malouf’s article, Thoughts on code, programming, design, production, development, technology and Oh! Design. I started to write the post that would have followed on Thursday, but I had to prepare a haunted house to open Friday night and just couldn’t finish it.

Continuing where I left off, Dave Malouf gives us a dose of reality.

So for all intents and purposes, the point is just plain moot. Because as Jr. and Mid-level designers become Sr. and director level designers, their tech chops will just be assumed as they move up the ladder. Our whole frame of reference will be completely changed (is changing) in the next 3-5 years.

Dave thinks all junior to mid-level designers need to at least learn how to prototype using HTML, CSS, JavaScript, and jQuery. He claims it’s “an economic reality of employability.” He may be right. That’s not to say that a designer who can’t won’t be able to find a job, but they’ll have a lot more opportunities available if they can. The real problem here is that design schools are already stretched thin trying to cover everything students need to make it.

But what of more experienced designers? Are we grandfathered in? Do we get a free ride, delegating the implementation to the junior staff? Even Dave admits he lost out on positions because he couldn’t code at an appropriate level. I have always been one to teach myself new software and new technologies when I needed them to accomplish something. I taught myself to edit video in Premiere, create 3-D animations in Infini-D, and create interactive multimedia in Director in the course of a year while I was a senior in college. I experimented with numerous software packages for animation and web design in grad school. I had less opportunity to do this after becoming employed, but I’ve kept my HTML and CSS skills up-to-date and taught myself enough jQuery to use it on a project. I’m confident enough in my prototyping and implementation skills that I’m not concerned about a hotshot designer fresh out of school beating me out of a position.

Dave believes that designers must sacrifice depth in UX practice to add breadth in visual design and coding. If you’ve been following along, you already know that this is one point on which Dave and I don’t see eye-to-eye. As I’ve mentioned before, UX practitioners should develop some amount of depth in their specialty before putting the crossbar on their T, but a career is a long time. I’m not going to claim I know everything there is to know about Interaction Design, but I certainly know enough to branch out into some other areas.

That covers what Dave sees as the problems. Tomorrow, I’ll take a look at the good side.

Review: Responsive Web Design

I was on a business trip last week (training the crew of the USS Carl Vinson) and made good use of my travel time. During take-offs and landings, when I couldn’t have my laptop out, I read Ethan Marcotte’s Responsive Web Design, published by A Book Apart. It’s one I’ve had sitting on my desk for months now. The book itself is well designed with full color screenshots. The code is nicely formatted with just enough syntax coloring to improve readability without painting every page a rainbow. Ethan did a fantastic job explaining and demonstrating fluid and responsive layouts. He walks the reader through the design of a webpage, starting with a Photoshop mockup from “a designer” on their team. His writing style is easy on the brain with a good dose of humor.

I highly recommend the book, not just for front-end developers, but for designers that contribute production code. I’m looking forward to putting media queries to use in my own work.

Designer’s Toolbelt: Macaw

When I first began learning to design websites, I used the brand-spanking-new Adobe Pagemill. Who needs to learn code? I was a designer, not a programmer, and I wanted the freedom of the WYSIWYG tools I was used to using for print. The computer should do the boring work of figuring out how to actually specify it. When GoLive Cyberstudio released, I jumped on it. I continued using that tool after Adobe purchased it, and I eventually switched to Dreamweaver after Adobe acquired Macromedia.

By that time, I had graduated with my Masters and was working for a software development firm. It didn’t take long for me to realize why the developers turned up their noses when they saw the HTML I was handing them. Fortunately, I had been working with it long enough that I had developed enough understanding of HTML to be able to start coding by hand. Once I got my hands on CSS, you couldn’t pay me to go back to a WYSIWYG editor. These days, I’m a huge proponent of Object Oriented CSS (OOCSS), speaking at conferences and leading workshops about working with developers and contributing directly to the production code base.

So, it was with much interest and a hint of disdain that I took a look at Macaw, “the code-savvy web design tool” under development by Tom Giannattasio and Adam Christ. I must admit, I’m impressed with what they have shown so far.

Stop writing code. Start drawing it.

Macaw provides the same flexibility as your favorite image editor but also writes semantic HTML and remarkably succinct CSS. It’s time to expect more from a web design tool.

This tool is pretty slick, and you can tell that it has been thoroughly designed by a designer who understands typography, grid-based layout, and code. You can tell that it has been built to address all those little annoyances we web designer/developers face daily. From readouts that tell you things like the number of characters per line, to supercharged key combos for quickly aligning objects (pudging is going to make your heart skip a beat), the application looks to be chock full of awesome.

And then there’s the code. I’m awed by how intelligent their aptly named Alchemy engine is.

We wanted Macaw to write code you’d be proud enough to hand to developers. Current applications rely on trendy frameworks, export rigid positioning and generate ridiculous IDs. We think designers and developers deserve better. Macaw’s powerful, patent-pending engine is called Alchemy and it can do some incredible things.

Alchemy analyzes every possible selector to describe your document and determines the most succinct way of using them based on logical criteria: applicability, specificity and semantics.

Macaw offers designers the freedom of absolute positioning within the interface but will convert to a static document flow upon export by calculating the necessary margins, padding, floats and clears. It’s the best of both worlds.

There is an incredibly elegant outline palette, reminiscent of Photoshop’s layers palette, that not only serves as a method of hiding and showing elements within your page, but also creates the semantic linking between elements and the classes that will be generated in the CSS.

I’m just scratching the surface here. You really should check it out for yourself. I’m not saying I’m ready to start generating all the enterprise web applications I work on in this way, but it sure seems like an excellent tool for sketching, prototyping, and then moving your prototype to usable code. It’s leaps and bounds beyond any editor I’ve seen before. They say it’s coming to the Mac App Store soon. I’ll be following their progress with great interest.