Quarter Life Crisis

The world according to Sven-S. Porst

« WiiMainLabyrinths vs. PyObjC vs. Encodings »

Designing Interfaces

1239 words on

Book Cover Jenifer Tidwell’s book Designing Interfaces - Patterns for Effective Interaction Design -  discusses various aspects of user interface design (user behaviour, content organisation, navigation, layout, actions, visualising data, user input, editors and aesthetics) and lists around ten design patterns for each of those. While it is interesting to skim the book to see what has been done, it is likely to be more useful as a reference guide for looking up things. Generally the beginnings of chapters can be interesting as most of the discussion of the ideas behind the patterns is done there (although that’s at times inconsistent and specific patters can come with extra details).

Each design pattern is discussed in the same form (with paragraph length sections on: what, use when, why, how, examples). The patterns range from blatantly obvious to cool and subtle. And likewise the detail of the discussion varies widely but is generally rather short. The examples, which are almost always given as screenshots from computer applications or web sites (design patterns for hardware are mostly neglected as are non-visual aspects of interaction design) are sometimes spot-on but in other places appear a bit forced and imperfect.

What the book absolutely lacks is a touch of negativity. And I mean that in the most constructive way possible. To me it seems that in user interfaces the don’ts are more important than the dos. Many bad interfaces seem to owe their badness to designers being too easily excited by the rich toolkits they have at their hands these days. And while the patterns’ ‘use when’ section sometimes touches situations in which the pattern at hand should be avoided, that is never exhaustive and we aren’t shown bad examples (of which the software and web world certainly provides many).

The book also seems to limit itself to being descriptive. Unlike the design patters which we found in works like Apple’s Human Interface Guidelines from the 1980s, these patterns seem to be mostly based on observation and lack research and indications on how well they work and where their problems are. For many patterns I do not doubt that they exist but I really doubt that they are any good. Examples here could be Number 45 (Putting numbers in filled circles as they do for numbering the patterns in the book must be one of the stupidest graphical ideas ever, btw. It is hard to make those look good. And whoever designed that book certainly didn’t even try.), the Action Panel, by which Mrs Tidwell refers to panes which you frequently see in the Windows Explorer, for example. And in that specific example, I remain unconvinced that they help at all. As their contextual changes make it hard to know which command is where. And - possibly - in longer usage, I keep thinking that having these panels at hand is a way of dumbing down the UI in a fashion which keeps the user from learning its real power. That’s just an unproven hypothesis as well, of course, but I would have loved to see a well founded discusssion of it. And perhaps a discussion of how the right sidebar of an application like Lightroom relates to that pattern. (Amusing bonus point: The screenshots for this pattern feature a Windows file browser displaying a .DS_Store file. Now I have to wonder whether I should take this as careless or as ironic.)

The next pattern, Number 46, Prominent ‘done’ button merits discussion as well. If you have a preferences window which applies any changed setting immediately, should it have a ‘OK’ or ‘Save’ button? The argument in the pattern suggests that even if the button isn’t necessary it gives the user an obvious and reassuring way out. On the other hand, I’d say it suggests that changes are only applied when the window closes and that a good preferences window should only have a close box.

The next one, Number 47, Smart Menu Items certainly merits some discussion as well. In many cases it’s good if menu items adapt their text to the specific action they will trigger. The Undo command is a prominent example for that and is more helpful when it states what will be undone. On the other hand, Mac OS X.5 overdoes that idea in some places. For menu items which essentially reflect and change an on/off setting it doesn’t simply use a constant text plus a check mark but instead it changes the verb in the text to its negative. At least for me that makes the interface harder to use as I have to actually read the menu item to learn the current setting. If you want to see a particularly absurd example of that, look no further than TextEdit’s Format → Text → Writing direction sub-submenu. TextEdit’s menu item for hyphenation would be an obvious example for that and the View menus in many applications provide many others.

Want another one? Try Number 49 Progress Indicator. It gives all the commonly known things about progress bars and how to handle indeterminate situations as well as time remaining display. But I totally expected a discussion of the ‘phenomenon’ of what I’d call ‘double progress indicators’ which you see particularly in installers or generally in situations where an action consists of several distinct steps and you get a ‘global’ progress indicator a well as one for the step at hand. What about discussing (or at least trashing) that pattern which without doubt exists?

OK, one more: Number 68 Forgiving Format is what I consider to be one of the most important design patterns these days and for which I’d borrow the freeform goodness name from Dave: letting people enter data or queries as relatively freeform text and extracting what they want from that without getting into the way. Of course a lot of the magic there lies in the code behind the graphical interface elements, but this ‘pattern’ seems so important to me that mentioning on a single page seems underdoing it. I suppose this pattern alone could be discussed in a whole book of its own.

Perhaps these few examples illustrate what I think is missing in the patterns the book gives. What is written there isn’t wrong but it seems rather incomplete.

The coolest chapter of the book is probably the sixth - on data visualisation. Incidentally it’s also the chapter which the author claims to find most interesting. That’s probably because everybody is fascinated by cool and efficient ways to visualise data and a few nifty examples are given in that chapter. The shame is of course that situations where you have to actually handle data which are sufficiently rich and varied to ‘pull a Tufte’ in your user interface are rare. In most situations all you have are a few numbers. And if you have more data, it seems likely that your application is so specialised that nobody wants to ‘waste’ a lot of resources on researching how you could refine the user interface for it.

All-in-all, I found the book interesting but a bit superficial. With dozens of ‘patterns’ at hand I’d also find it hard to actually remember all of them. Particularly as some of them are trivial while others are highly sophisticated.

But at the end of the day, who’d want to disagree with an author who describes overly colourful interfaces as a rainbow colored ‘angry fruit salad look’?

[Buy at amazon .com, .uk, .de]

April 15, 2008, 0:02

Tagged as book, design, jennifer tidwell, ui.


Comment by niklas: User icon

I’m not sure, if I understood your example in the paragraph about Smart Menu Items. Using Mac OS 10.5.2, the menuitem you mentioned looks like this:

when unchecked and like this:

when checked.

April 15, 2008, 11:25

Comment by ssp: User icon

Yikes, looks like I mixed up my different pet UI quirks there!

I guess I meant something like the hyphenation menu item in TextEdit. But some View menus (e.g. top of Safari’s, middle of the Finder’s, bottom of iCal’s) could serve as examples as well.

Thanks for setting that right, I exchanged the example now.

April 15, 2008, 11:52

Add your comment

« WiiMainLabyrinths vs. PyObjC vs. Encodings »

Comments on




This page

Out & About

pinboard Links


Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.