Gadgetopia

I read Joel Spolsky’s book over the weekend: “User Interface Design for Programmers.” This is an excellent guide to usability — for client apps and for Web development.

The strength of the book is that it doesn’t start by presenting many hard-and-fast rules, but instead concetrates on general concepts that you really need to understand to develop an effective user interface. People Can’t Read. People Can’t Remember. People Can’t Control the Mouse. Design for Extremes. These principles then naturally lead to more specific guidelines.

For example: you know how when you first learn CSS, you put a textarea rule in your sheet to change the font in text boxes from that ugly monospaced, Courier font to some slick variably-spaced font? Looks nice, sure, but Joel demonstrates how hard it can be to edit for some people. Sure, it’s fine for you, but you’re young; and you have an optical, USB mouse; and you’ve been using computers since you got out of diapers.

Sadly, however, everyone isn’t you. Some users don’t have your eyesight, motor skills, or experience, and your tiny little variably-spaced font is now a problem for them. Lower-case L’s, for instance, are now just one pixel wide. A lower-case I differs from a lower-case L by only a single pixel. If two lower-cased L’s are next to each other (“allegory”), there’s only one pixel of “gutter” space between them — ever tried getting the text insert cursor to land exactly between them? You’re literally trying to hit a 1-pixel wide target.

(And what happens when there are two lower-case L’s and a lower-case I together, like in “alligator”? Egads.)

Upon reading this, I went back to an app I was writing and changed all text inputs and text areas to Courier New, 12px. It doesn’t look as nice, but I’ll concede that it’s easier and clearer to edit. Sometimes usability comes at the price of how things look, but so it goes.

Joel touches on the user model and system model that I read about earlier this year in Don Norman’s “The Design of Everyday Things.” Simply put, a user forms a model in his or her head about how your app works. That model may have nothing to do with how it really works (the system model), but that’s your problem, not the user’s. Your goal as an interface designer, is to make the implementation model (how the interface represents the system model) match the user model as closely as possible.

The book is full of good ideas and really solid, non-frilly advice. Joel’s obvious experience saturates every page (I gather he did the UI for the ISP Juno, and was on the Microsoft Excel team). It’s full-color with glossy pages and scads of screen caps.

I’ll finish here by hand-typing an excerpt that’s so good I’ll risk the copyright lawyers. It addresses a point I talked about a while ago when I was struggling with the non-confirmity of the Linux interface.

I’ve seen companies where management prides themselves on doing things deliberately different from Microsoft. “Just because Microsoft does it, doesn’t mean it’s right,” they brag, and then proceed to create a gratuitouisly different interface from the one that people are used to. Before you start chanting the mantra “just because because Microsoft does it, doesn’t mean it’s right,” please consider two things.

One, even if it’s not right, if Microsoft is doing it in a popular program like Word, Excel, Windows, or Internet Explorer, millions of people are going to think that it’s right, or at least fairly standard. […and] if you refuse to do it on some general religious principle that Bill Gates is the evil Smurf arch-nemesis Gargamel then you are just gratuitiously ruining your program so that you can feel smug and self-satisifed […]

Two, don’t be so sure it’s not right. Microsoft spends more money on usability testing than you do; they keep detailed statistics based on millions of tech support phone calls; and there’s a darn good chance that they did it that way because more people can figure out how to use it that way.

As reluctant as I am to admit Microsoft is right, amen to that.