Rating: 
Summary: Simply the best book on user interaction design
Review: If you find yourself bemused by the current woeful state of software usability, Alan's entertaining mix of invective, insight, and good advice will leave you practically ready to shout "Hallelujah, Brother!"
Rating:
Summary: He has it right, but those who should read and heed won't.
Review: Bells and whistles have become an addiction for software developers, and it's high time someone finally turned a spotlight on this aspect of software "development" that has crippled many an otherwise good program.QuickBooks was once a nice little bookkeeping program for small businesses. We used it for years, loved it, then upgraded to version 5.0. Unfortunately our old version was out the window before we discovered what a colossal mistake we'd made. First, there's the "User's Guide": almost a thousand pages! A manual of such bulk is a tipoff that a program is too complex for most mortals (assuming the text was reasonably to the point). Second, the addition of a multitude of new (and useless, for us) functions so cluttered the functionality of QuickBooks that we couldn't fathom how to use the functions that were once a breeze. We never did figure out how to customize the "new and improved" invoice template to accommodate our use. Third: "Features" would jump up and stand defiantly in our way. When trying to prepare invoices using the barely acceptable template we'd be interrupted with an error message that said we didn't have the item in stock -- we didn't want to use QuickBooks for inventory control, but no, QuickBooks insisted. After trying to beat some use out of QuickBooks we unloaded it and tossed it out. Now we use the invoice template that comes with MS Excel (INVOICE.XLT)and it works just fine. Intuit actually did us a favor by exercising their compulsion to ruin a simple program; they forced us to discover that a totally functional little invoice template, one infinitely customizable, was on our computer all the time. (Of course, the discovery made us ask ourselves why we weren't heads-up enough to simply design our own invoice using Excel in the first place!) It's easy to get carried away searching for special-use utilities instead of using the tools already right at hand to create our own -- free. Grammatik is another disaster. Once I considered it indispensable and proofed all my books on it to get the reading level down and identify potential improvements in style. But the folks at Grammatik couldn't leave it alone. New and useless features were added which only bogged down the process of using it. A speller was included(as if we didn't have spell-checking features in WordPerfect and Word!), and if there was a way to disable Grammatik's spell check I never found it. And what a sorry spell checker it was -- wouldn't allow you to add words to its inadequate vocabulary, wouldn't allow you to ignore all occurrences of words it didn't like, so it stopped on every usage of them. Where I once used Grammatik on entire books of, say, 200,000 words, the new "improved" version would drive me mad trying to get through a 5,000 word chapter. Out it went. I considered Norton Utilities indespensable for a decade. Now it's not loaded on a single machine here because it pokes its nose into too many places where it has no business, slinging DLLs around in reckless profusion, causing problems and lockups, not to mention its insatiable appetite for computer resources. If Microsoft can't deliver a Windows version without bugs, how can increasingly "function-rich" programs written by third parties work under Windows without causing conflicts? They can't, and they don't. Cooper is on the mark: The inmates are running the asylum, and they don't care what us mere users have to endure to accommodate their passions for excess. It was Mark Twain -- wasn't it? -- who apologized to a friend for writing such a long letter by explaining, "I didn't have time to write a short one." Brevity is hard work. We've solved many problems here by brutally pruning the utilities on our machines, then formatting hard drives to clear out all the DLLs and other files that have been left behind. A typical gain in available hard-drive space is about a third after a format and complete reload of programs and data files. Unfortunately, there are too many computer users who "think" they want bigger and better programs even if they never discover how to use more than their most basic features. Also, the computer press fawns over "feature rich" programs -- the journalists review them, but aren't saddled with using them every day. So vendors keep bloating bloating programs and raising the prices. I've hoped in vain that some enterprising software writers would follow along behind the big boys and create iterations of the simple, functional and easy-to-use utilities they've discarded. Maybe Cooper will inspire some to do just that. Doug Briggs
Rating: 
Summary: Less is NOT better.
Review: This is another cutesy, emotional attempt to cover up for second rate products. One need only spend a few minutes comparing the word processors of ten years ago to the remarkable office products of today to realise that what Cooper thinks of as embellishments are the basis for real progress. Too often someone tries to sell second best as an end in itself. In every case they are really cheating the public. Life in the U.S. is full of countless refinements. Occasionally, there are snafu's and frustrations. But without many of those improvements life would not be as rich or as diverse.
Rating: 
Summary: Technical Thuggery Unmasked!
Review: I've been developing software / designing databases for over 15 years, and while I've known about the problems Alan brings forth in this book, I was unwilling to face them head on. It's always beneficial to read "opposing" viewpoints, but many in the business carefully ignore this opportunity. Alan helps you think differently, sometimes striking a hidden nerve - proof that it's worth reading.
Rating:
Summary: Better software design, part II
Review: Alan's books should be required for all programmers. College computer curriculums should require interaction design as well. This book, and Alan's first book are both great reading. They are humorous and yet highly valuable. The only regret I have is that the books point out all the little things that software does to annoy that I might not have noticed before...
Rating:
Summary: Best Business Justification for Interaction Design Ever!!!
Review: Wonderful metaphors and framework for talking about interaction with software-based technology. I bought copies for my 10 top developers.
Rating:
Summary: Shows a little design can save a lot of headache and money
Review: Alan Cooper discusses how a software implementation should begin. By designing how the application should interact with the user (and meet their needs), a programmer can save a project from failing to achieve its goals.
Rating:
Summary: Book Reviewed on VBTechniques website
Review: While much of the book is anecdotal, the stories can provide useful insights as to how to improve your own development projects. There are some good techniques included in the last two parts of the book for improving your own processes. Read the review at VB Techniques
Rating:
Summary: The best book ever on what software design is
Review: I am the silicon valley chapter president of the Association for Software Design and World Wide Institute of Software Architects, and I'm always on the look out for really good books on what design is. Most books miss the boat entirely. I had the pleasure to read the galleys before the book went to the publisher. As always, Alan has a very engaging and provocative writing style. A lot of people confuse Design with programming. This is like confusing Architecture with construction engineering. But really they are very different, even in a legal context, for the design and architecture about fitness to purpose, and programming and construction are about appropriate implementation a design. It's easy to construct a house without an architectural design, but it can be very frustrating to move around and use the space. You can also program software without design, and the result is "software that needs to be spanked", as Alan says. What is really great about this book is that Alan shows what software design is, in contrast to programming, and shows that while it is not an engineering science, it isn't touchy feely mumbo jumbo either. In the later chapters he talks about an actual methodology he uses in his company to do design, and these techniques can and should be widely copied. You'll learn a lot from this book: you'll know what software design really is, AND how to do it. And unless you are a programmer with a fragile ego, you'll split your sides with laughter as well.
Rating:
Summary: Say You Want a Revolution...
Review: I found myself really getting into Cooper's book as I read it. He's an easy writer to read. He keeps things interesting with all sorts of anecdotes and experiences, and he describes them with tongue planted firmly in cheek.
That's not to say that he isn't serious about what he has to say... clearly, he is very serious. In describing the difference between a Designer and a Developer, and even in more detail when contrasting a Visual Designer and an Interaction Designer, he makes clear just how important this subject is, and how the differences he is talking about can determine the process by which a piece of software or application comes together, and the success of the final product. His obvious frustrations with the roadblocks to effective user-focused design should be understood by anyone involved in the design process.
The pinnacle of the book, for me, came in the middle. At the end of Part 3 ("Eating Soup with a Fork" -- great title), he discusses the relationship between humans and technology. He says something so simple that it should have been obvious, but it's really a fairly major shift in perception from what many people think. He talks about the assumption that technology is dehumanizing here:
"It doesn't require sophisticated tools to dehumanize your fellow humans -- a glance or a kick does it as well. It is not technology that is dehumanizing. It is the technologists, or the processes that technologists use, that create dehumanizing products."
This is important to what Cooper is trying to say in "Inmates" in so many ways. The theme of the book throughout seemed to be that interaction design is only as friendly, or as UN-friendly, as people make it. Technology only does what we tell it to, as we design and implement its specific functions.
The real revolution that this implies is the possibility that technology can be made to interact successfully with humans, and that it doesn't have to frustrate or debase the people who try to use it. In fact, as a human creation, technology is as human as we want to make it. As Cooper said in chapter 6, "For users to be happy and effective with software, it must be written in harmony with the demands of human nature."
But like anything, to make software effectively intereact with humans (i.e. more helpful, more usable, etc.) takes more work... one of the roadblocks. Cooper talks, also, about the established culture of programmers. He defines them as almost a seperate breed of humans, at least as far as their thought process and rationale... "Homo Logicus" as opposed to "Homo Sapiens." He talks about the rift that often appears between them, largely because of the cultural perception (mostly an obsolete view) that software is a solitary occupation, that programmers work in a vacuum and are the sole authors of their work.
The book makes it clear that the software design process can no longer be one which belongs to a solitary person. The creation of software works better as a collaborative effort than it does as a single-author process. Product planners, interaction designers, usability experts, testers, and yes, programmers all have their part to play, and when it comes together, it can yield great results.
Cooper's conclusion seems to be that the most fundamental changes to the software industry need to be made to the process. The people who make the software are, by and large, talented at what they do, and willing to change for the better if they can. It is when they are asked to do more than they should be that problems arise. A change to the process will ensure that better, more usable products can be made.
It seems that most of the people who do the work of making the software in question are willing to change the way they do things, but only need permission to do so. Cooper's take on it, which I agree with, is that it has become not only advisable to move on from the obsolete programming culture we have relied on in the past. If we want to make a change towards more usable products that end-users feel comfortable interacting with, then a change to the process of software creation to a more collaborative effort of interaction design and development becomes an imperative, at the very least.
Recommended to anyone involved in the software design process. Record it on tape and play it for project managers while they sleep.
| 
