About Face 2.0: The Essentials of Interaction Design

Author: Alan Cooper, Robert M. Reimann List Price: $35.00 Our Price: Click to see the latest and low price ISBN: 0764526413 Publisher: John Wiley & Sons (17 March, 2003) Edition: Paperback Sales Rank: 10,169 Average Customer Rating: 3.11 out of 5

Buy now directly from Amazon.com -

Customer Reviews

Unfortunately, this book has a few bones to pick with the current ways that users work. In many cases, while I may agree with statements such as that the File menu is not strictly necessary, users of many programs already understand how things work under the hood and want to know about it directly. He sometimes preaches design as if all customers of software are and should be ignorant of the system they're working on. I write software for other developers, so a lot of the tips and advice he gives are actually things that would cause my customer to become quite angry -- they understand the system, want to work in terms of it, and want to be able to to understand how your program deals with it. There are a number of commercial software tool failures to prove the mistakes of those who've tried to force a model the designers thought was superior on developers who knew better (ever used Visual Age Java?).

There's also a lot of material duplicated from his earlier book, _The Inmates Are Running the Asylum_. If you're only going to read one of the two, I'd advise reading that one, and skipping this one.

The target field (cf. the users) of this book are developers, every programmer should have a copy, is not?
A software package, which is unfriendly, laughing and bashing to its user, such a package would be considered as a computer program with a bad design. The user would not like to use it.

Now, I'm wondering why the so self-declared software design god of the modern times is bashing, laughing and unfriendly against the users of his product.

Mister Alan Cooper does not have a clue how a company works and what the background of a developer is all about. He is bashing the wrong people. Bad software interfaces are not the fault of the developer but the management and the methodologies that are used in most companies.

Developers are trained in schools and universities to produce code and to design the internal architecture. Few of them receive cognitive psychology courses, which is needed to create five star interfaces.
The average management in a company, small or big just allows that developers do the graphical interface design, a task for which they were not prepared. The outcome is indeed bad software but don't shoot the pianist, instead turn the spotlight on the choirmaster.

The content-worth of the book is average. It is heavily focusing on one aspect of creating better software interfaces: design guidelines.

While these guidelines are important, it is not enough to create excellent interfaces. The risk is that a developer, after finishing reading the book will think he or she knows everything about the job and this is not his or her fault but the author.

No words are spoiled by instance on User Profiles, Contextual Task Analysis and so many other aspects of user interface designing.

The design guidelines itself are mostly not new, I have read them long ago in other works and with some research you find them for free on the internet. Some guidelines-laws described in the book are even examples of bad designs, which is dangerous, at least in a way.

I can imagine that for an average programmer the book is still revealing, but he or she should know that other grasslands are much greener. Best case, you have a design guideline book, nothing more, nothing less.

I do not know I am allowed to do this, but if you want a real step-by-step guide for creating better software you should try "The Usability Engineering Lifecycle" by Deborah. J. Mayhew, also available on Amazon.

For instance, he spends a lot of time explaining that programs need to be written to assume that users will make mistakes (because they will), rather than considering mistakes to be a break in the workflow. Sure, sounds good. But then later on, he suggests that if the user of an accounting system enters a record with an invalid account number, the computer should just assume that it's actually a valid account number that the user just hasn't told it about yet. And worse, he suggests that the system should accept it *silently*, and not tell the user that anything at all odd happened until it gets around to generating the end-of-month report and there's still no matching account number. Can you imagine the user of such a system, when the computer finally tells him that *a month ago*, he made a typo while entering a record, and now he has to go digging through paper records (assuming he still even has them) to find the correct information?

It's the same thing with many of his other examples. He suggests ways for the computer to be "smart" that are clearly smart in the very specific cases he's thinking of, but often dumber than before in every other case.

Similar Products