on October 29, 2003
Usability Engineering (UE) is my profession, therefore I was interested in this book. After reading about half of it, I can only say it is a waste of time and money. The author just seems to be in love with his own ideas (which are by no means new- most of his stuff is old wine in a new barrel) but doesn't realy touch the essentials of UE. It is too simple to blame everything on the developpers.
For those really interested in UE stay away from this book.
on September 19, 2003
If you want a good example of how NOT to write a book, than this is it. It's unfortunate that Cooper and Reimann chose to take the condescending, developers are evil approach when trying to make their point because all it did was alienate me as a reader. As an example, in their discussions regarding scrollbars (page 360), they say "In many cases, though, it is used inappropriately only because designers and programmers don't have any better ideas. That's a poor rationale for any aspect of software design." What they are really saying is "You didn't invent something new, therefore, you suck." Or how about in the Chapter 34, Notifying and Confirming (page 449), the quote "Promise that you won't ever create one of these, please?" OK, I'll promise to never create one of these if the authors promise to never write another book.
It is my opinion that 70% of this book is a waste of paper and served no other purpose than to get the page count up to justify the price. Also, the authors seem to get some perverse enjoyment out of using obscure and unrecognizable words in order to sound more intelligent and give their book a college textbook feel. And the lack of examples for many of the problems they cite is inexcusable. If you're going to bring up a problem, then offer up a solution. Many times they fail to do this.
It's unfortunate that the authors failed so miserably in the delivery of their message because of their overall poor writing style since they do bring up some valid points. As a developer, I agree that software in general has to be made more user-friendly and have seen first hand many of the problems the authors cite throughout the book. I think they would have succeeded in bringing more developers around to their way of thinking if they would have just changed the delivery of their message.
One thing that will come from reading this book is that in the future, I will refrain from purchasing any book authored by Cooper and/or Reimann.
on September 18, 2003
This book had several very good ideas inside it. The vast majority of them are common sense in hindsight. Some ideas are radical and would require massive time and money to implement. Unfortunately, his ideas tend to fall on deaf ears due to the author's use of a writing style more suited to (bad) poetry than technical persuasion, a condescending attitude towards developers, and failing to provide sufficient application examples of his ideas.
Reading this was a departmental exercise for our (software) company. I got a lot out of it, but others did not. This is unfortunate, because if the author took his own advice and removed "excise" and the smugness, the rest of the team would have been more receptive.
Apparently Cooper wanted to be a poet and certainly not a technical writer. The first rule of technical writing is to get your point across. He goes on for pages without actually saying anything. He too frequently uses words that many people have never heard of. You don't change people's mind when they have to focus on the words instead of their message (doesn't he say something similar about software). Here's a sampling of his poor word choices.
conflated p 465
While there's nothing wrong with those words, he uses them when other more-recognizable words are available or he uses them when no word is needed at all! It could be removed from the sentence entirely.
All this emphasizes that he's more interesting in sounded like a pompous Lit major than trying to persuade readers. He gives the feel of someone wanting to write a college book and thus makes it intentionally sound technical. Gee, didn't his book say us developers do that with software too often? Can't take his own advice.
As a developer who gets paid by customers who buy our product, my goal is help the user as much as possible. Cooper gives the impression that ALL developers are rude, lazy, and hate the user. He calls us lazy because he assumes we always take the easiest (and less intuitive) way out - totally ignoring that we have schedules and our bosses often dictate our features based on time. He imbues us with evil traits as if we're a bunch of maniacal human-haters: "Mwa ha ha! I'll put yet another error message in my program. That should make my users feel stupid and they'll kill themselves and I'll rule the world." Most of us would love to create some of the intelligent interfaces he mentions (but gives few examples). Lack of time is the main reason why we don't. This should be obvious to even beggars on the street corner. Since developers must be persuaded to make these changes, it hardly makes sense to alienate them so.
If you're not part of the solution, you're part of the problem. In the extreme majority of his issues with current software, Cooper provides no suggestions for how to solve it. At that point, you're just complaining.
The book has some good information and some very interesting ideas. However, its presentation is awful. If you feel developers hate users and intentionally make software complicated (so they in turn will lose business and thus lose their jobs), but you seldom want examples of how to fix this problem, you'll love this book!
on December 20, 2003
I loved "The Inmates Are Running the Asylum", and bought "About Face" looking for some concrete examples of how to implement its ideas. Unfortunately, all of Cooper's concrete ideas are just awful. Half of them would require strong AI in order to implement, and many of them would actually require the computer to have psychic powers.
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.
on September 1, 2003
This book is by no doubt a valuable resource for any software developer, nevertheless, more liveliness, humor or variety would have made it less monotonous. Prepare yourself to spend a great deal of time to tackle through more than half a thousand pages of very dense text, which is worth reading. The previous book by Alan Cooper, "The Inmates are Running the Asylum" is much more vivid, concise and amusing. I would recommend reading "The Inmates" first to get acquainted with Goal-Directed Design and the concept of considerate software, and then proceed to "About Face 2.0" to expand the knowledge and make it actionable.
This book exposes the distinction between implementation model and mental model, and brings the concept of "perpetual intermediates" as the most common category of the users. The authors show how to classify applications by posture on the web and on desktop and handheld computers, as well as on mobile phones and public kiosks.
The aspects of the modern User Interface are well covered in this book: data entry and retrieval, direct manipulation and pointing devices, metaphors, idioms and affordances. Parts of the book are devoted to such interface constituencies as controls, menus, toolbars and tooltips.
You will also find chapters about installation process and dialog etiquette in this book.
on February 6, 2004
The main goal of usability engineering is creating the right interface for the right audience.
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.
on October 9, 2003
There seems to be some misunderstanding among previous reviewers of who this book is for, and I have to say I'm confused as well. I see the term "developer" used all over the place, but what exactly does it mean? Part of the problem is that according to Cooper (and just about anyone with basic reasoning skills)developers should be writing code and interaction designers should work on the interfaces. So, it would be reasonable to conclude that this book is targeted towards interaction designers. Then why bother mentioning developers as the source of all evil over and over again?
Who is this book for, anyway? When the author says "requirements" is he talking about project requirements in general or specific interface-related requirements? When he says "design" does he mean software design or interface design? If you have read anything about software engineering in general, I'm sure you will have lots of questions like these.
Although it is a book about interface design issues, it's a big disappointment that the author somehow forgets about the bigger picture and makes it seem like the product is the interface and the design of the product is the design of its interaction with the user.
The author also makes some arguable points. For instance, he claims that there is no such thig as computer literacy - we only have to talk about computer literacy because software is obscure and overly complicated to use.
Somehow it was no surprise to learn that the author also happens to be "the father of VB" :)
on September 19, 2003
Although this book contains some very good observations, it is underpinned by an agenda which is the creation of a new craft called "Interaction Designer". Since any new craft needs its own jargon to confuse those who are "less learned", Cooper wastes no time creating one. His frequent use of less-familiar terms for the sake of exactness is distracting and weakens the effectiveness of his message. Here are a few examples:
"Interaction design" instead of "user interface design"
"aphorism" and "axiom" instead of "principle"
"Subject Matter Experts" instead of "expert users"
"Ethnographic Interviews" instead of just "interviews"
"Personas" instead of "user profiles"
The list goes on and on. Almost every other page introduces some new or uncommon term to be included in the jargon to be used by this new profession that Cooper wants to create.
Personally, I think this book makes some really good points that deserve to be heard. Unfortunately, those "tender morsels" are buried in so much diatribe that most of the people who read the book are likely to miss them.
I hope the authors get busy soon on a "About Face 3.0" edition that eliminates at least a third of the text and replaces the academic "high-brow" vernacular with common words and phrases that are already in common use. They also need to provide more examples of potential solutions to the problems that they point out.
In the meantime, I can't honestly recommend this book.
on October 26, 2003
When Alan Cooper wrote the first edition of About Face in 1997, the software industry was in the midst of its biggest change ever. Just about every new user interface was being created in the context of a Web browser. Cooper was the leading advocate to persuade software developers, graphic artists, usability designers, and interaction designers to avoid bringing the mistakes that got baked into desktop application software developing into Web development. His impact has been profound, but not very easy for most software developers.
Key to this book is to understand that it challenges software developers to consider a user's goals first. And the book means "a user", not all of the users, but a single user. I've been to Alan's presentations and you can see the software developers in the audience squirm in their seats. "Don't I have to build my software to work for the largest group of users?" they ask. Alan's book says "No. Instead, build for a single user, and make sure your work accomplishes their one goal." About Face might be better titled "User Goal Oriented Software Development."
The book's focus on "interaction design," as opposed to user interface design, matches the key theme of user goal oriented development. For example, when my printer runs out of ink a dialog box appears on my computer asking for me to put more ink into the printer and then click one of the following buttons: Finish and Continue. As the user, my goal is to Finish, but the software wants me to put more ink in the printer and then to Continue. Interaction Design addresses this problem, where user interface design would more likely tell the software developer where to place the buttons in the dialog box. Interaction design keeps the focus on user goals.
I loved the original book, and find the new release to be refreshing.
-Frank Cohen, [...]
on February 7, 2004
Personas and goal-directed design are great techniques for putting together a quality product and really making sure that you're building the right things for your users. In particular, this book provides a process for doing design that would help most teams do a better job of being more customer-focused.
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.