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.

Headway

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.