Hier klicken Jetzt informieren Neuerscheinungen Cloud Drive Photos Alles für die Schule Fashion Sale Learn More HI_PROJECT Hier klicken Fire Shop Kindle PrimeMusic Summer Sale 16

Ihre Bewertung(Löschen)Ihre Bewertung


Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.

am 16. September 2004
Die meisten Revolutionen verliefen blutig. Auch heute, wo wir am Beginn einer Information Revolution, eines digitalen Zeitalters stehen scheint es Opfer zu geben. - Menschen, die mit den neuen supertollen Produkten einfach nicht zurecht kommen können. An und für sich ist es ja nicht verwunderlich, dass ein paar Softwareprodukte nicht besonders einfach bedienbar sind, seltsam ist nur, dass es heutzutage die große Masse der Programme ist, die einem das leben schwer macht.
"Bill Gates once observed, with uncharacteristic cynicism, that the way you made software user- friendly was by making a rubber stamp and stamping each box with the legend "USER FRIENDLY." Unintentionally, his method has become the computer industry's real method."
Alan Cooper hat erkannt, wie man die Situation verbessern könnte. Nicht, indem man ein weiteres Buch für die paar Interface Designer schreibt, die sich der Tragödie ohnehin bewusst sind, sondern eines, das sich an diejenigen richtet, die das Sagen haben. "The Inmates are Running the Asylum" ist das erste Buch über User Interface- Design, oder wie es Cooper nennt "Interaction Design", für alle, die noch nie damit zu tun hatten.
Die Rechnung geht auf: "The Inmates are Running the Asylum" ist ein hervorragender Einblick in die Welt des Software Designs allgemein und die des User Interface Designs im Besonderen. Es erklärt ausführlich, was an den bisher üblichen Abläufen der Softwareentwicklung falsch ist und wie einfach man diese verbessern könnte. Darüber hinaus führt es gut in die Cooper'sche Methode des "Goal Directed Designs"* ein und zeigt, wie falsch es eigentlich ist, Programme für "Den User" zu entwerfen. Cooper bringt immer wieder exzellente Beispiele unter anderem gibt er einen kleinen Einblick wie chaotisch die Produktentwicklung bei Microsoft abläuft. (Er ist quasi der "Erfinder" von Visual Basic)
Die wichtigsten Feststellungen des Buches:
# Design must be done before programming.
# Let interaction designers do the designing, let programmers do the programming.
# The only thing more expensive than writing software is writing bad software.
# Design for just one person.
# Design for the user's goals, not for specific tasks.
Ich bin sehr froh, dass ich das Buch gelesen habe und möchte jedem, der in irgendeiner Form vor hat, etwas im Bereich der Softwareentwicklung zu erreichen, dasselbe raten: Lest dieses Buch! Es gibt aber eine Sache, die mir negativ daran aufgefallen ist. Abgesehen davon, dass sich Cooper schon ein paar mal wiederholt, was aber nichts ausmacht, ist die Art, wie er über Programmierer schreibt, schon etwas verwunderlich. In einigen Kapiteln hat es fast den Anschein, Programmierer wären keine Menschen. Da helfen beschwichtigende Sätze, die zeigen, wie er es (hoffentlich) eigentlich meint auch nicht wirklich. Manchmal artet das dann sogar in so lächerlichen "Wir gegen die Programmierer" - Phrasen aus. Schade, denn der eigentliche Weg, zu guter Software zu gelangen besteht letztlich immer in einer guten und kooperativen Zusammenarbeit zwischen der Entwicklungsabteilung und der Design - Abteilung.
Wie gesagt, abgesehen davon ist dieses gut geschriebene, allgemein verständliche und amüsante Buch einfach rundum empfehlenswert.
0Kommentar| 7 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 24. Februar 2000
Good read, just be cautious of the one sided slant to this book!
According to this book, the inmates are everywhere and as is the main premise of this book, they are in charge of not only shaping the asylum known as software design, but also our world. Cooper uses various anecdotal examples throughout the book to illustrate his ideas and views on technological design. Focusing entirely on how it has run amuck. Many of the examples are painfully obvious and basic.
While points are well made and key to adding to ones thought process about designing software and better ways to bring product to market. Cooper misses the boat with regards to some of the realities of business. I found Cooper's ideas a little too idealistic with little suggestion in terms of comprimise or strategic change.
Methodology also seems to be off as book is all general impression based on observation and personal experience.
Finally, If you are looking for a reminder about good common sense and a prompt on how to make your customer king, you'll find this a helpful read.
0Kommentar| 3 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 1. Mai 1999
Although the goal, usable software applications, is noble, Alan Cooper is misguided in placing the blame on the engineers.
Feature creep is often caused by business and marketing professionals, as they think piling on more features will make it the product more desirable.
Project plans and specifications are usually poorly planned, which leads directly to engineering problems. Perhaps the business/product management side of the story needs the work.
0Kommentar| 2 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 29. August 2015
Some fundamental books are never outdated. This is not one of them. For me coming from a software development background it had very little information. It describes very long and repetitive what it's currently going wrong with software. Fair enough. But it has very little to teach which might be due to its "age". The things it does mention are very few and sometimes outdated, like doing all the designing up front and that an incremental process is not going to work (current agile/scrum trends would beg to differ)

There are many better UX/UI books out there.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 15. Juli 2000
The Inmates are Running the Asylum makes the business case for interaction designers playing a central role in the development of technology products. It starts by providing examples of technology that is difficult, frustrating, humiliating, and even dangerous to use. Cooper argues that, although people have gotten used to being humiliated by technology, it doesn't have to be this way. His claim is that most technology, especially software, is designed by engineers who think differently than non-technical people: they enjoy being challenged by difficult problems and they are trained to think in terms of "edge cases" rather than on the common case. Thus when engineers design software, they tend to create products with far too many neat features that clutter the interface and make it difficult to do the simpler tasks. In the second part of the book, Cooper describes an approach that he and his design firm uses to simplify products and keep them focused on the users' needs, eliminating or hiding more complex features that few people use. He gives some specific and compelling examples of how they took a different approach to an interesting design problem and keep the product simple while still being powerful. He makes the case that you can grab a market with powerful, feature-rich, complex software that is frustrating to use, but you don't build customer loyalty that way; as soon as a well-designed version of that product comes along, your customers will defect. If you delight the user with your products, on the other hand, you will engender deep loyalty that will help see you through some poor business decisions. His primary example of this is the fanatical loyalty that Apple garners from its users, compared with the rage that Windows users feel toward Microsoft. Apple has weathered some horrendous business decisions and still survives, whereas Microsoft users are more than happy to defect when a better product comes along, and in fact revel in the defection.
I also don't think he makes it clear enough that he's not proposing doing *fewer* features to make products simpler and easier to use, he's talking about doing *different* features. For example, he argues that software should not be so lazy; it should stop making the user do work that the computer is better suited to doing (e.g. remembering where they put files), and it should stop making users go through the same steps over and over again, as if it were the first time they had ever met this user. He argues that "Do you really mean it?" popups are evil (and I couldn't agree more - as most of my coworkers know), and instead it should be easy to undo anything, so it's not so catastrophic to do something you didn't meant to do. I agree with all that, but of course building a reasonable "undo" mechanism is a very complex feature. To cure the "How could you possibly want to quit my ever-so-important application?" popup syndrome, it would be much better to make the software very fast to start up, and to have it come back in exactly the state you left it in, so that quitting when you didn't mean to is not a problem. All of this is well worth doing, but it is lots of engineering work; it's another feature. I'm all for shifting engineer resources to these features instead of the "but somebody *might* want to do this obscure thing" features, but it should be clear that this is not doing fewer features, it's doing different ones, ones that help smooth the user's interaction with the software. Cooper seems to imply that engineers are so lazy that they don't want to do these features, but most engineers work very hard and care about their product. The key is to make it clear why doing this feature right will make such a big difference to the product. My experience has been that the more you understand the work involved in doing a feature, the better you can work with engineers. Not only can you better trade off engineering effort for user benefit, but engineers respect you for understanding what you're asking.
Having said all that, I can't deny that I finished this book with some very specific ideas about improving my own designs, and a renewed sense of the importance of what I do. I just wish Cooper could have articulated the case without putting interaction designers "on a throne."
0Kommentar| Eine Person fand diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 9. Januar 2002
Alan Cooper vermittelt dem Leser hier wieder den Blick für das Wesentliche. Obwohl der "Vater von Visual Basic" eigentlich die Engstirnigkeit heutiger Software-Entwickler und Produktmanager ankreidet, gelingt es ihm an vielen Beispielen aus dem täglichen Umfeld (Radiowecker, Videorekorder etc.) zu zeigen, was mit heutigen High-Tech Produkten nicht stimmt. Er zeigt einen praktikablen Weg, Software bedienbar zu machen.
Dieses Buch ist ein Muß für alle, die mit der Software-Entwicklung zu tun haben.
0Kommentar| 3 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 3. Juli 2000
The culture of software development is changing, but grudgingly. The short-sighted notion "It's better to be first with something bad than second with something perfect" has been discredited after too long a reign as the New Paradigm of the Information Age ("It's brilliant because it's counter-intuitive!"), and instead has been exposed for what it is: bad business and a lousy way to treat customers. Alan Cooper's book helps make sense of things as software developers, after decades of coding for each other, are forced to begin acknowledging the cold and strange outside world of Real Life Users.
Cooper's writing is generally clear and easy to follow. He documents his points well and uses numerous true-to-life examples to illustrate the concepts. The ATM analysis, for example, is both effective and memorabl: Why DOES the ATM list account types you don't have, permitting an invalid selection? Why can't you return to a previous screen to correct mistakes, instead of starting over from scratch? Why doesn't the system give you an error message that helps you understand the problem, rather than "Unable to complete transaction"? No one even bothers to ask these questions, Cooper points out, because we've accepted the default structure of ATM screens--which were created for the convenience of coders and system engineers, rather than users.
Cooper also performs a valuable service in demolishing that old standby programmers' excuse: "We don't call any of the shots-it's all management's fault!" Bull. Half the managers in the computer industry are former coders themselves (and laboring under an outmoded and faulty mental model of how software development must occur, by the way). The other half are so non-technical that they're at the mercy of the coders, who are free to decide which features are most important, which will take too long, and ultimately, which will or won't make the cut for the next release. Coders ARE driving this bus, if occasionally from the back seat, and they need to take responsibility for what they produce-and be humble enough to admit that an indispensable part of the development process (interface/interaction design) is beyond their abilities.
That said, Cooper's writing style itself is less than perfect. He presents many compelling case histories, but at times he seems to lean too heavily on insider stories, as if showing off his contacts and expertise in the industry. And, of course, Cooper is far too much in love with his "dancing bear" metaphor; long before you've reached the halfway point, you'll be muttering, "One page...just ONE page without a 'dancing bearware' reference, PLEASE! That's all I ask!"
But the messages and lessons in this book are too important to ignore. As Cooper tries to remind us, it is everyday users-not the power users, not even the "computer literate"-who are the core audience. They're the ones you have to design for: a successful interaction design, rather than a burgeoning list of clever features, is what will determine your product's success or failure.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 27. Juni 2000
Being fairly new to the usability business, this book has provided me with some very very powerful methods and ideas for interaction design. Until I read this book, I thought that usability inspection methods constituted the holy grail to developing state-of-the-art software. Alan Cooper, however details my naive picture somewhat by arguing about the importance of interaction design, i.e. the process of creating a detailed software manuscript (just as they do in the movie business) before bringing in the programmes. In addition to explaining his ideas, Mr. Cooper also provides some very specific guidelines for implementing these ideas. The guidelines are backed by real-life examples from the work performed by Mr. Cooper and co-workers.
The first part of the book is devoted to an explanation of why software is designed the way it is. The responsibility for software development is largely placed in the hands of the programmers - which in the mind of Mr. Cooper are a breed of highly technical, skilled and devoted persons that in general have no understanding for the problems or needs of the end-user.
I like this book for many reasons: Mr. Cooper is witty, the examples are good and informative, everything is well written. But most of all: I really like his message, and this book has been an eye-opener to my narrow sighted vision of usability. Bravo!
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 26. Juni 2000
The culture of software development is changing, but grudgingly. The insane notion "It's better to be first with something bad than second with something perfect" has been discredited after too long a reign as the New Paradigm of the Information Age ("It's brilliant because it's counter-intuitive!"), and instead has been exposed for what it is: bad business and a lousy way to treat customers. Cooper's book helps make sense of things as software developers, after decades of coding for each other, are forced to begin acknowledging the cold and strange outside world of Real Life Users.
Cooper's writing is generally clear and easy to follow. He documents his points well and uses numerous true-to-life examples to illustrate the concepts. The ATM analysis, for example, is memorable and effective; millions of us have learned, adapted to, and continued to use ATMs without the slightest recognition of their failures in user interface design. Why DOES the ATM list account types you don't have, permitting an invalid selection? Why can't you return to a previous screen to correct mistakes, instead of starting over from scratch? Why doesn't the system give you an error message that helps you understand the problem, rather than "Unable to complete transaction"? These are questions no one bothers to ask, because everyone has accepted the default structure of ATM screens--which were created for the convenience of coders and system engineers, not users.
"Computer literacy" is another important concept that too many developers are looking at from exactly the wrong direction. Instead of complaining that not enough users take the time to learn and understand the basics of computers, we should be improving and simplifying computers to the point where they don't have to. "Users aren't reading the manual" is not a valid complaint, it's a simple fact of life that developers-not users-are responsible for working around. Your job is not to get users to read the manual; it's to design an application that doesn't need one.
This is an important concept, and the perception of users in the software development culture must change in order to address it properly. Anyone who sneeringly refers to simplifying and improving the user interaction as "dumbing down" illustrates how completely he has fallen victim to one of the core fallacies of programming: the "user as idiot" image. You may prefer to design for clean, logical hardware requirements, but your project is doomed to failure unless you bring in someone willing to take on the messy, nasty, error-prone real world of genuine user interests, behaviors, and preferences. And for the most part, programmers are not qualified to do that.
The book also does a valuable service in demolishing that old standby programmers' excuse: "We don't call any of the shots-it's all management's fault!" Bull. Half the managers in the computer industry are former coders themselves (and laboring under an outmoded and faulty mental model of how software development must occur, by the way). The other half are so non-technical that they're at the mercy of the coders, who are free to decide which features are most important, which will take too long, and ultimately, which will or won't make the cut for the next release. Coders ARE driving this bus, if occasionally from the back seat, and they need to take responsibility for what they produce-and be humble enough to admit that an indispensable part of the development process (interface/interaction design) is beyond their abilities.
That said, Cooper's writing style itself is less than perfect. He presents many compelling case histories, but at times he seems to lean too heavily on insider stories, as if showing off his contacts and expertise in the industry. And, of course, Cooper is far too much in love with his "dancing bear" metaphor; long before you've reached the halfway point, you'll be muttering, "One page...just ONE page without a 'dancing bearware' reference, PLEASE! That's all I ask!"
But the messages and lessons in this book are too important to ignore. The problem is, too many hardcore programmers take pride in the arcane complexity of their work, and the "elegance" of the solutions they devise; they are unwilling to accept the simple reality that USERS DON'T CARE. They never have cared, they never will care, and like it or not, THEY-not the power users, not even the "computer literate"-are your core audience. They're the ones you have to design for: a successful interaction design, rather than a burgeoning list of clever features, is what will determine your product's success or failure.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
Alan Cooper makes the case for goal-directed interactive software design in his provocative book, The Inmates are Running the Asylum. He argues that though it would seem common sense, few software-based computer products are designed with the end-user in mind prior to their construction. Instead, they are all too often feature-laden "dancing bearware" that may impress the inexperienced, but infuriate them as well. Cooper suggests that software engineers are to blame for this phenomenon, identifies several examples of ill-conceived software engineering, and offers design specifications to ameliorate the problem.
The real culprits in Cooper's book are the programmers and engineers who design products to work their way as opposed to the best way. Cooper argues that the approach that companies take in creating technological products is backward. They do not consider what customers want first. Rather, they consider what programmers can produce (what's capable) and what business people can sell (what's viable), rather than what customers want and need (what's desirable).
Examples abound throughout the book illustrating the frustrating results of such backward engineering. These vary from the tragic to the mundane. The first page of the book details a fatal plane crash which could have been prevented had the pilot's computer been programmed to account for human error in navigational commands. Later in the book, Cooper proposes simplified VCR design that would eliminate universal frustration with programming one's VCR, not to mention eliminate the ubiquitous flashing 12:00!
Clearly airplane accidents, if not VCR ineffectuality, concern most people. How can computer manufacturers design the most desirable products to avoid such public danger or distress? Cooper outlines specifications that require goal-directed design and end-user orientation. Software engineers typically design programs to accomplish tasks, e.g. the aforementioned navigational computer was programmed to direct the plane where the pilot commanded it. That was its task.
Unfortunately, the pilot commanded it to fly into a granite mountain. Had the computer been goal-directed designed, i.e. programmed to direct the plane where the pilot commands it, given that such directions do not result in a collision, tragedy would have been avoided. The latter case illustrates end-user orientation, for it allows for pilot fatigue, emotion, latitudinal unfamiliarity, or oversight, any of which may occur on a given flight.
Cooper's call for goal-directed design and end-user orientation of software-based computer products is compelling and seemingly common sense. Overall the book is well written and includes memorable examples and convincing arguments. One less cogent claim, however, is Cooper's suggestion that technology apologists will play an important part in affecting change toward goal-directed interactive software design. I assert that change must come from within the programming and engineering ranks. Apologists, by definition, are not cohesive or likely to take a stand against that which they're apologizing for. This is like asking an enabler to seek help for an alcoholic. It is not going to happen. The software engineers must lay down their addiction to bells and whistles, tasks and tortuous interfaces, and see through the eyes of the end-user: you, me, and the other 98% of the world with flashing 12:00s on our VCRs.
0Kommentar|War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden