Customer Reviews

About Face: The Essentials of User Interface Design

5 star:		(29)
4 star:		(8)
3 star:		(14)
2 star:		(7)
1 star:		(6)

 

 

This book changed my life. No kidding. Before I discovered this book, I thought I was a pretty decent GUI programmer, but in retrospect, I really had no concept of usability. What I was doing was slapping an interface on top of my code. This book will change the way you design & write software, and even how you use software yourself. And at least in my case, it even changed the way I look at everyday life. I find myself asking why things were designed the way they were, and realizing how much better things could work if they were re-designed with usability in mind.

Cooper mainly looks at the Windows GUI in this book, explaining the basic elements of the GUI, and why they do or do not work well. And he gives suggestions as to how things could be done better.

And he gives some interesting reasons why today's developers design software the way they do.

I highly recommend this book to every developer who has to design/code GUIs. I've actually read through it twice. I can't say that about any other computer-related book I've ever read.

Alan Cooper needs an editor as badly as the builders of GUIs need a UI designer. This book reads like a hastily-assembled series of email flames.

In between the flaming rants, there are a few positive contributions. Unfortunately, they're typically presented in an oddly half baked way, with the metaphors being drawn much more sharply than the UI recommendations. Here are some examples from page 23, which I flipped to at random: "assembling bicycles on Christmas Eve was a cakewalk compared to getting _The Lion King_ CD ROM to work". Yes, we all know installation is hard. But what do we do about it? "Either the software industry will regulate itself like doctors and architects do, or the government will regulate it like hairdressers and taxi-drivers". Hmm. Still don't see how this relates to GUI design? "If carpenters designed houses, they would certainly be easier or more interesting to build, but not necessarily better to live in". Typical of his focus on getting design out of the programmer's hands. "It's as though the scaffolding is so labor-intensive that the urge to incorporate it into the finished house is irresistible". He goes on to discourage designers from using anything other than pencil and paper and to discourage prototyping because it'll stick. (You'll find much more insight on software engineering in toto in Hunt and Thomas's "The Pragmatic Programmer" or Beck's "Extreme Programming".

Just because Cooper's unfocused and condescending doesn't mean he's always wrong. Three topics, in particular, stuck with me: no dialog boxes, save is the default, and soverign apps. Reading this book caused me to completely rethink the current app I was designing.

It's clear that Cooper spends most of his time at the computer doing word processing. Almost all of the negative examples (I don't recall any positive ones) are drawn from Microsoft products, primarily Win95 itself and Word.

I found Johnson's book "GUI Bloopers" to be far more insightful on actually designing, laying out and testing GUIs. Johnson's book is refreshingly polite, case-study oriented and thoughtful.

I'd heard about this book for years. Alan Cooper is widely regarded as the guru of interface design. After reading this book, I wonder why.

For one thing, he contradicts himself--a lot. On the one hand he complains that software tends to mimic the physical artifacts--for example, calendars are laid out on one-month grids. According to Cooper, this is a serious problem-- we are restricting a computerized calendar based on the limitations of the printed page. We should exploit the power of the PC. Then, not more than thirty pages later, he complains that computer file systems are deficient because they aren't centered around 'documents', which users know and love. We should restrict our file systems based on the limitations of the printed page. Be either fish or fowl; don't try to have it both ways.

I was very disappointed by this book. I expected insight, but what I got was Alan Cooper bitching about Windows. I knew what was wrong with Windows before I read the book. What I wanted was guidance on how to best interact with the user. I got Cooper's pet theories, most of which strike me as just plain silly.

Another reader described the book as "incredibly arrogant". I'd have to agree. Save your money; I doubt this book would help you create better user interfaces.

Many of the GUI design books I've read just tell obvious things (align your controls, don't use saturated colors etc). This book is different. It's deeper. It's about how users interact with computers and how to build GUIs that (to use Cooper's words) don't make the user look stupid. The book is provocativly written which might not be everybody's taste. I'm a programmer myself but didn't find the book offending. Although five years old by now I consider this the best book on GUI design out there. Note that there is no mention of Web specific issues in the book.

Cooper's book is a must read for anyone serious about user interface design, especially for Windows. It explores a wide range of subjects, from understanding users and the goals of UI design to an analysis of the major Windows user interface components. He has many interesting things to say and a great deal of insight. The presentation (which could be significantly improved with better editing) is enjoyable reading and thought provoking. One oddity - Cooper has a penchant for naming things, but unfortunately he isn't very good at it. The book is filled with original, often bizarre names for user interface concepts and components, but you could never use them in public without embarrassment.

If you are doing Windows user interface development, you should also check out McKay's Developing User Interfaces for MS Windows, which gives a very practical treatment of much of this material and more.

After reading Alan Cooper's latest book, The Inmates are Running the Asylum, I immediately bought this book for more specific information regarding Mr. Cooper's design ideas. Hooooo, boy! This thing is SLOW! The author steps through each piece of the user interface, bit by bit by bit, and writes entire chapters on what seem the most trivial details. Truth is, though, his points are valid and thought provoking, but his writing is more tedious than Tolstoy. If you want a good overall philosophy of design, buy his more recent book...it's much shorter and much, much more fun to read.

I've long been curious about this book because it is so often cited and hailed by current usability experts as the "starting point of software usability." And maybe it was a groundbreaking work in 1995, when hardcore coders and "power users" still made up the majority of the user base. But now, many of Cooper's claims and proposals seem awkward or downright unusuable... the antithesis of what usability now stands for.

To be fair, this is an old book (in the IT sense of the word), and a new "About Face 2.0" is apparently hitting the shelves soon. Thank goodness! A lot of the ideas presented in the original are timeless and important, but others have hopefully been relegated to the dumpster.

Goal-directed design, for example, is something that interface designers should never lose sight of. Cooper does an excellent job of digging up the real goals of users (as distinct from their job descriptions) and maintaining focus on how to satisfy those goals while balancing them with other realistic business concerns-profit, professionalism, efficiency, and so forth. He decries the "real world analogy" trap that so many developers fall into and stresses the limits of "metaphors" in promoting user understanding. He stresses the importance of visual feedback for all actions and the need to protect users from "modes."

This is all good material that developers and project teams should always keep handy for the inevitable design arguments. (Although note that the tone of this book is relentlessly programmer-focused, hailing from a time when all "design" was done by coders, and interface or usability specialists simply didn't have a place in IT.)

But when Cooper gets into suggestions for "breaking the mold" and coming up with new and different types of interfaces, he loses me. He seems to vastly overestimate the readiness of users to learn new interface features and new designs. More recent comments from other usability sources acknowledge this basic truth. Joel Spolsky, for example, states that "An interface is well designed when it works exactly the way the user expects it would." Steve Krug states it even more baldly as "Don't make me think!" Don't make me think about the PROGRAM, that is; users are very willing to think about their tasks, they just refuse to waste time learning your cool new interface for what is (to them) just a complicated and badly-designed tool.

Cooper makes sweeping suggestions, such as doing away with file structures and directories entirely, or increasing the reliance on "chord clicking" and triple-clicking for key functions (for power users only, of course). He wants more icons and less text because of space considerations, even though he acknowledges that icons are inherently confusing to new users (idioms-something that can be learned only through experience) and are often poorly executed.

He also introduces several new concepts to the platform, such as a "milestones" feature in word processing. These new notions may perform valuable functions, but at what cost? Their suggested implmentation is awkward and confusing; the terms themselves are hard for non-coders to understand. Do we really want all dialog boxes to have an additional button: "OK, Cancel, Abandon"? It seems that, in his enthusiasm for trying something new and different, he temporarily forgets his own caveat: "No matter how cool your interface, less would be better."

I'm glad that a new version of this book has been developed; hopefully it has retained the core principles and jettisoned the specific examples, particularly the "totally new and different!" ideas. For better or worse, we have a standard for software interfaces now; changes must be approached with caution and delicacy, no matter how much of an improvement they seem to offer. Today's user base won't waste time learning a new interface and doesn't care how "cool" or even valuable it is. Don't forget the focus on user goals-and their goal will never be "learning to use this great new software."

This single quote can help you decide whether or not this book is for you. In chapter 12, a section called `Why pluralize' contains the following nugget. (Note: Cooper defines `pluralize' to mean `a window which does not occupy the full screen'. More on his vocabulary later.)

`Programs occupying the in-between state of pluralization are dying out, and Windows 95 is helping to kill them. The programs never have to pass through the pluralized or iconized state. Of course, that doesn't mean you can actually dispense with these options. [...] every program that can maximize must be able to be pluralized for those oddball cases when a user needs to tile the screen with the application [...] it is difficult to guess what the case might be'.

In other words, an emacs, three xterms, exmh, xcpustate, xcalc, and a Netscape coexisting on one screen does not fit into Cooper's world view.

If you find yourself nodding your head in bovine fashion after reading that, buy this book with my blessing. Please don't have children.

If, on the other hand, you had to read that twice, and are still not sure if it's a bad joke... if the vision of Excel excreted over all 1600x1200 of your pixels brings an involuntary whimper to your throat... if every reboot means spending ten minutes getting your windows laid out properly (but reboots only happen once or twice a year)... then save your money. Read Nielsen, Norman and Tufte. Heck, read Milne! You may not learn much about UI design from Pooh, but might pick up some wisdom and humility.

Incidentally, while others have commented on Cooper's capricious imposition of his own working vocabulary, nothing you read here can prepare you for the reality. It's almost as if Cooper, in that moment of introspection upon finishing A Clockwork Orange, had simply thought `How neat! I wonder if I can get away with this?' His three favorite words are `I call this ...', and with those he launches into a veritable orgy of word invention (I call this `wordvention'). Some terms he uses throughout the book; some he defines, then ignores, then uses again just to see if you're paying attention. This effectively makes it impossible to jump ahead, or to read the book in anything but linear order.

Oh, and does this wizard of user friendliness provide a glossary for all these new terms? I'll quietly leave the answer to your imagination.

This book tackles quite a few design issues from an abstract and concrete (individual widgets) viewpoint, and is full of ideas and approaches. But alas, that's almost all it is - Cooper's own thoughts about UI design. Not "the essentials" but "my opinion".

The book is quite good at taking groundbreaking research and rubbishing it after a shallow summary. Cooper rejects metaphors out of hand, in favour of "idioms" (scrollbars etc.). The work done at Xerox in the latter field (consider the Information Visualiser - Camtree etc.) is forgotten in favour of an attack on the desktop metaphor as if it were an issue of great personal insult.

The author loves to reinvent terminology, often to make up for a well-known definition he does not fully understand - for example mixing "affordance" with "visibility", then creating the term "manual affordance" for what affordance _actually_ is as defined by Norman.

In an area where so little study is done, as the author acknowledges, I'd rather not read 500 pages of one man's opinion. At least _some_ collation and discussion of research would go down well. _The Pragmatic Programmer_ follows a similar "practical tips" style to this book, but does it so much better.

A very useful book, with many great insights. It will force you to reconsider your approach to UI design; for example, the discussion of why message and error boxes are bad is a must-read. Pg. 428 shows an error box where the message is:
It's obvious from your actions that you don't know jack squat about computers or software.
The three buttons offered are:
I am not worthy
Please kill me now
I should go back to pencil and paper.

The error box is titled "Nerd-O-Gram". The point is: this is what EVERY error box feels like to a beginner. This single picture makes the book worth your money, if only for the laugh.

Note however that:
- It is very biased towards Windows UI design. If you're designing, say, an embedded UI, it will not be very valuable. Likewise, if you have any thought about portability, the recommended "approach" is basically "write for Windows exclusively, outsource the rewrite (forget porting) for anything else". Whatever truth there might be in this, the simple fact that the author comes from Microsoft should have made him think twice about offering such advice.
- It is somewhat dated, considering toolbars and tooltips as cutting edge; no mention of newer ideas like auto-completion.
- It is a very pure "design" book. Developers will find it insulting at times. There is very little regard for major implementation issues; not a word about internationalization, for example.