Background. I am an applications developer with 10 years experience. I usually write applications that are very "User centric" and I am always looking for ways to improve my design skills

I found this book to be very strong in some areas and very weak in others.

For example, in the first section where it is talking about the analysis, the ideas it suggests is very good but hard to grasp in practical terms. A case study example to tie all the stages together would have been invaluable.

Later on when the authors are talking about the "exise" they make a strong case of why it should be avoided but fail to mention the single biggest exise mistake of any application whch is the "mouse to keboard to mouse" transition.

In the later parts of the book when it gets down individual controls it really just describes them without giving any real concrete advise on how they should be used. I got as many good ideas from a single Joel on software blog than this whole section

I found myself disagreeing with several sections of the book, most notably the section on files and databases.

On the other hand the sections on "Posture" and "goals" has certainly made me think about applications differently.

On balance I think that it was valuable for me to read this book but I was dissappointed that there was so little in the way of "tips and tricks" and not enough examples in the earlier sections to really illustrate the points made

This book describes problems that people have when using software in everyday terms, while explaining the underlying problem. Bad interface design is like putting a handle on the side of a door that you need to push. It is not the end of the world, but when you first come to that side of the door you pull the handle. The door does not give, so you push. Next time you know to push the door. In the end you complete your trip with just a little delay, but by jolting the door, your journey has been disturbed. Thus, people are at their most effective when they enter a state of 'flow' - everything just works, you know where you are going and what you are going to do. Then you hit a menu option that you have to think about or does not do what you expected. You lose flow and you become less effective. This book highlights the issues that 'jolt' when using computers. For example, you write in a spiral notebook and place it back on the shelf. When was the last time it asked you if you want to keep your jottings? Yet when you finish writing in a software "notebook", the software will often ask if you want to save the changes. This is putting a programmers problem (reconciling copies on hard disk and in memory) into the users' domain - where it does not belong. These are the kinds of ideas that this book explores.
User Interface Design is a moving target, and more issues are addressed in the second edition than in the first. The second edition has more psychology of interaction and covers acquiring requirements through talking to people in their place of work while they are doing the job. Thus the second edition is a major rewrite, very informative and challenging. It ought to be read by anyone who designs user interfaces. The only bad thing that I can say about it is that the author does get a bit preachy at times. For those readers who were disappointed because there is no pseudocode in the book, remember that this is a book of ideas and concepts, not user interface programming formulas.

A great book , with alot of great content. Unfortunately , as has been noted before, the author's tone is often arrogant and demeaning. Throughout the book he stresses never make the user feel stupid , then on the next line he's calling you the reader / developer stupid because you did this or that. But don't let that ruin the book. Just like with most things in life , you have to weed out the BS and negativity to get to the good stuff. It really is a shame they didn't apply their own techniques to the book though.

Out of reading this book, I was inspired to make many changes to my software interface that resulted in dramatic improvements to quality and usability. There are times when I wish it had more out-of-the-box solutions and concrete examples of how to design, and there are times when it devolves to ranting. But there is real help here for me as a software designer.

This book is a self-indulgent rant, that is also poorly edited and structured. If the authors had read their own book and applied their principles to its pages, reading it would have been as much of a pleasure as using software that follows their advice.

Why do I give it 5 stars?
Because beneath the diatribes and soapbox oration there is a depth of experience and of thought I have not found elsewhere.

The authors have considered the issue of what makes using software a pleasurable experience for the user in a depth and with a degree of insight that opened my eyes.

- Cooper & Reimann have clearly explained the steps involved in the 'user centered design' process in a logical and easy to understand manner.
- Process is the problem : The book begins by talkin about User's goals, history of interface design process and blames the 'traditional process' being the reason for rude & difficult to use products and expensive development costs.
- A good book to learn about user requirements research basics, user goals, user profiles & personas, scenarios, etc.,
- The book is a must read for business teams & interface designers. This book can be used as a text book in interaction design schools too.
- Think ,whenever author blames 'developers' for bad user experience, he is blaming the usage of 'Implementation Model'

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.

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.

This is an excellent text on Software Graphical Interface Design. Do not build another application until you have read this book. Well written and organized, this book delivers details on designing for user goals, and how to avoid common pitfalls. There is only one chapter specifically on Web Design, but most of the other content is applicable.

Highly recommended!

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.

The ideas contained in this book are golden. It is irrelevant if Alan Cooper sometimes repackages and presents excellent ideas from others. I found this book to be very informative and an entertaining read. I study this text from time to time to freshen up on some of the ideas. If you are serious about developing quality software, you should read this book

Los dos anteriores libros de Cooper son magníficos: por concretos, directos y enfocados. En About Face se habla de problemas de usanza relacionados con pobres prácticas de diseño; y en "Inmates..." se establece un método razonable para tratar con "usuarios no-elásticos". Ambos son rotundos. Y divertidos. Y prácticos (yo utilizo algunas de sus técnicas en Diseño Contextual y de Interacción). About Face 2.0, sin embargo, sólo añade explicaciones innecesarias al About Face original, pues parece que se quiere formalizar un área que antes se había descrito precisamente como no formalizable, y se desprende un cierto tufillo academicista que no le hace justicia a las ideas de Cooper, expuestas muchas veces en conferencias. Así que, igual que con Meyer, sigo recomendando la primera edición, que con todo quedó algo atrasada (pero sus ideas siguen siendo magníficas para adquirir criterio).

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.

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, www.pushtotest.com

It seems that most reviews on this book are from software developers, which is why they are so negative. I manage a web development company that concentrates on easy to use websites. From my perspective the ideas and methods are by far the best out there.

His main point is that software developers should not create the interfaces we use. This is an important statement that many people need to understand. The software engineer can't design an interface when he/she has no interaction with the users. Even further, it takes a different mindset to create an interface than it does to code.

You can't blame the author for setting things straight. What you can do is maybe blame the books stores for putting it in the wrong section. It looks as though too many developers are reading this book for insight.

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" :)

To sum it up briefly:

"This book was filled with several good ideas and obvious shortcomings in today's software, but the authors' ideas are lost due to poor delivery."

The long story:

Although I was impressed with some of the authors' "radical ideas", I became distracted with their choice of words and constant finger pointing at obvious shortcomings in today's software interfaces. If this was the authors aim at humor, they missed their target completely. It becomes excessive when the negativity spills over from chapter to chapter. (I could have lived with less negativity directed at software developers...) I found that the authors' choice of words and finger pointing at software developers became the topic of my development team discussions versus the true matter at hand: "The problem with today's software interfaces and what can WE do to improve them."

I feel the book could have delivered its message better if only the first few chapters dealt with shortcomings leaving the remainder of the book to focus on new ideas or solutions. I would caution seasoned professionals to ignore the author's finger pointing and negativity and to focus on his ideas. Some of which are good and others are not, but it is obvious that software user interfaces have problems and the authors provide some ideas at addressing those. I would only recommend this book to those who are able to see beyond the authors' tone and truly listen to their ideas.

Some people have given this book a high rating and bashed others who are just stating their own opinion. ( I'm not that petty or immature )

The authors make some decent points, but their ideas are not original and their writing style is that of someone trying to impress rather than convey information.

This book appears to be more of a platform for developer and software bashing rather than the helpful user interface design text that I had envisioned. After chapters of repetitive whines about software developers, I was becoming irritated. That's not what I got the book for.

Usability folks will no doubt love this book because it will confirm to them that everything is the developer's fault. Developers will no doubt hate the book because it states that everything is the developer's fault. I don't like the book because it doesn't give me any good information on UI design, which is what I wanted it for.

This book is the work of genius. It is the best book I've ever seen on WHAT a GUI should do. Unlike other books which focus on how to arrange your controls or whether to use a combobox or radiobutton for xyz, this book addresses the basic design and considerations of a user interface.

This book is not for idiots. Anyone who would thumb this book either CAN NOT and WILL NOT appreciate what it means to make an application usable.

What this book does best is come up with a language for the elements common to every day programs. Soverign vs Transient apps, GUI excise (making users do needless repetative tasks), and the "interaction design" concept which is an analysis of the entire user experience with an app.

This book should be a must read for any serious GUI developer. Its what comes after you've mastered the use of basic controls and GUI programming, and want to go further into make your app a joy to use.

This book is a waste of money and should be avoided. The authors fail to give example solutions or suggestions for many of the problems they fault with today's software. Not only that, they continually slam developers for what they consider to be poorly designed software when its obvious they give little consideration to the real world constraints that exist when developing software. Save your money and try another book, I got very little out of this one.

I've read the book once, and I'll read it again. So will my colleagues. The authors had done a very good job gathering together the high-level problems concerning user interface (or user interaction) desing. They don't provide out-of-box solutions to every existing usability problem, but designing an interface is not like boolean logic.

The book introduces some new terms, to me that's fine. For example, "user profile" or "user role" is not the same as "persona", as the authors state in p. 61. It's a design tool for their design process, and the meaning behind the terms should not be considered the same.

We're propably going to apply this book's methods in our organization. But we're also going to use usability professionals. After all, we all have a developer background too.

Some developers might think that the book has an offensive attitude against them, as seen in other reviews. Hopefully in version 3.0 the authors find words that would be easier to swallow also for the people who actually do the coding. Then I'd rate it five stars.

My best advice for you regarding this book is to avoid it like the plague. The worst thing about it is the anti-developer attitude the authors take and the tone of their writing. They are highly critical of developers in general and seem to think that all the shortcomings with modern day software have been intentionally placed there.

Also, the authors feel the need to pepper the user with "big words" in what appears to be an attempt to make themselves sound smarter. Look at one of the other reviews where the reviewer actually documents some of these usages. The reader is advised to have a dictionary handy when reading this book.

Another problem I have with this book is that the authors like to talk about software usability problems yet in many cases offer no solutions or ideas on how to fix them. What's the point in bringing up a negative if you can't offer up a solution? If all the author is going to do is complain about something, why would anyone buy the book?

What is really unfortunate about this book, aside from the fact that I wasted $25 on it, is that the authors do raise some valid points but these are lost amidst all the wordy blather that is so prevalent.

One thing for sure is that in the future, I will think long and hard before I purchase any book authored by Cooper and/or Reimann.

The tone of the book is very negative, I was often distracted by the authors' strange wording choices, confused by the way their "rules" would flip flop, and insulted by their insinuations that *I* am the problem. This book took a tremendous amount of effort to read and definitely was not worth it.

This book has a very small content to filling ratio. Reading it like pulling teeth. It doesn't give you much guidance on how to better design user interface while mostly is just reviewing what user intefaces are out there and trashing 3/4 of them. For example, in one chapter authors say that creating cascading menus is really bad and whoever does it deserves to be called "Philistines, reprobate and a weaker soul". In the following chapter they say that sometimes it's Ok to have cascading menus. They make a statement and they overturn it later on. Our R&D team had to read this book and they have even stronger words for it.
Do yourself a favor and buy another book unless you want to spend long hours reating after reading it.

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.

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.

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.

Kafkaesque p440
simulacrum p265
conflated p 465
prolix p469
tessellation p324
interstice p292
appellations p331
proselytizing p334
adjudged p354
bifurcation p367
execrably p453
concomitant p478:

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!

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.

This book really made me think. The author has some really clever ideas which I never even considered, such as "Why do we need a Save button". As a professional software engineer I gained a lot of good ideas from this book.

The book is laid out in a very nice fashion. You can almost pick up it, turn to any random page, and start reading. The chapters are small and easy to read. I really enjoyed this book, and would recommend it to anyone that is interested in software interface design.

One valuable lesson on every single page. Required reading for designers, engineers, information architects and technical managers. Buy yourself a copy and another one for your boss.

even as a 14 year veteran of interaction design, i learned much more than i would have imagined. well written, well organized, full of great insights.

This is the first book and aspiring developer should read. It is also the next book they should read. After they get that big-bucks job and are writing code for a living ... read it again. When you finish a project, that would be a good time to pickup the book and see what of it applies to your "complete" software project. Alan has an engaging, no-nonsense style that is uniquely his. Like his first About Face and The Inmates Are Running the Asylum, this book is loaded with sage advice.

Reading rev 1 of this book a few years back changed my view of how programmers should program and gave insight on how to design programs the correct way. The second release is sufficiently different so that it still a bargin for those that have the first one. The biggest impact of those not familiar with the value of software/interface designers will be the altered view-point you may emerge with. A programmer (as i have been for the last 20 years) tends to get tunnel vision. It's not that we think we're doing things badly and do it anyway; we just don't see the opportunities opened by taking a different viewpoint on the functionality and design of software. Alan and Robert Reimann effectively describe this "enlightened" view of software design through effective use of examples and critique.

A final point is that the book is somewhat granular. The chapters build somewhat on each other, but it is the kind of book that can be read a chapter at a time in any order.

Thanks Alan and Robert!

I've been waiting for this book since I first heard about it from a friend last year. Now it's here and it's proving to be worth the wait. What I need to figure out now is, how can I make the designers of every software program I'll ever use read this book?

Hats off to Cooper and Reimann. You would think that their axioms are common sense, like "Never scroll text horizontally", or "If it's worth the user entering, it's worth the program remembering". But if those common sense ideas were actually common, why is there so much horrid software out there?

Two thirds of this book are roughly the same as the previous version, but if you want to find some new gems of information you should read it all. Reading it all was no exercise for me. It reminded me of some issues I had forgetten and am not using and I was pleased to be reminded.

The first part on the Cooper Process is excellent and gives lots of insights and new information. The new chapter on Visual Design is a bit simplistic in my view, but if you know the matter you shouldn't be bothered by that.

All examples are updated and fresh. Some new pictures of Cooper project help in making the case. I particularly liked the interactive pie charts for example.

As the Web is moving towards Rich Internet application and the desktop applicatios are moving towards Rich Internet information applications this is the best and most up to date resource for Interaction Design we have at this moment.

I read it in a weekend. I bet you will too...