Article Preview

REVIEW

Book: User Interface Design for Programmers

Issue: 5.3 (March/April 2007)
Author: Marc Zeedar
Article Description: No description available.
Article Length (in bytes): 6,100
Starting Page Number: 9
Article Number: 5304
Related Web Link(s):

http://www.apress.com/

Full text of article...

If you're not an artist or graphic designer, you might think interface design is out of your league. It's hopeless, so why bother trying, right? But as Joel Spolsky -- of "Joel on Software" fame -- explains in his excellent book, interface design is not about making screens pretty, it's about making software useable.

We've all used bad software, products that made life worse instead of better. Most of the time the flaws were not huge, but merely a collection of tiny mistakes and annoyances that add up to utter frustration. Joel explores the reasons behind these problems and how to fix them.

For instance, the book begins by explaining that what makes users happy is the feeling that they are in control. When your program does things they don't expect or understand, they don't like using your software. The key issue here is that there are two models in play: the user's idea of how the program works, and the programmer's. When those two aren't the same, problems happen.

Joel illustrates this with the story of a college buddy who stayed up all night writing a term paper, then shut off the computer without saving his document. He was used to paper. There's no "save" command for paper. After all, he'd typed into the computer -- it had to be in there somewhere, didn't it? It couldn't just vanish!

It turns out that probably 90% of all computer problems are the result of this user-program model conflict. Users expect one thing and the software does something else. The interesting thing here is that it doesn't matter if the user's idea is stupid or impossible: it's still the programmer's fault that data was lost. It's the programmer's job, duty if you will, to make such misunderstandings as rare as possible.

Of course the problem is made worse because, as Joel points out in a series of chapters, "People can't read. People can't control the mouse. People can't remember." (I can totally vouch for this. I cannot count the number of times someone has called me saying, "There was an error message but I closed the window and I don't know what it said.")

So how do you correct people's misassumptions if they won't read the manual, run the tutorial, or read your dialog box explaining the solution? Joel has the answer in "Affordances and Metaphors." Here he explains that you can use a visual metaphor to give subtle hints to the user how the interface is supposed to work. Buttons that look three-dimensional, for instance, invite pushing. An icon that looks like a file folder or suitcase implies it might contain something.

But for metaphors to work properly, they need to be consistent and complete. They can't be only half like their real-world counterpart. Joel uses the example of Windows 95's "My Briefcase" feature, which is supposed to let you take files home with you. But you still had to drag the "briefcase" to a floppy disk -- it didn't do it automagically -- so users were confused. Did you drag files to the Briefcase or to the floppy drive or both?

There's also the problem of overextending a metaphor. Joel points out something that has been subconsciously bothering me for decades and yet I never realized it: the Macintosh's trash can, used for deleting files, gets "full" when you put stuff in it. This of course makes your fingers itch to "empty" it -- a desktop looks messy with an overflowing trash can -- but when you do you lose the ability to undelete files which was the whole point of the trash can metaphor in the first place!

(I can honestly say that I've rarely used the trashcan's ability to "undelete" files because I almost always immediately empty the trash after I've put stuff in it. I just hate seeing that "full" trashcan.)

Joel's book is full of great illustrations, ideas, and concepts like these. It's a terrific read, especially if you haven't studied interface design concepts.

However, the book is more of an introduction to these concepts rather than in-depth analysis. It's a great summary of ideas, but experienced programmers might find they prefer a book with more meat and detail. The book is brief and the writing style is long on stories and examples, which I found entertaining to read, but it's light reading for the hefty technical manual price. I would especially recommend it to hobbyists and those who don't like reading dry, technical material. Perhaps a cheaper used copy would be the best choice, or visit the "Joel on Software" website and read similar material for free.

End of article.