Laden Sie die kostenlose Kindle App herunter und lesen Sie Ihre Kindle-Bücher sofort auf Ihrem Smartphone, Tablet oder Computer – kein Kindle-Gerät erforderlich. Weitere Informationen
Lesen Sie mit dem Kindle Cloud Reader Ihre Kindle-Bücher sofort in Ihrem Browser.
Scannen Sie mit Ihrer Mobiltelefonkamera den folgenden Code und laden Sie die Kindle App herunter.
Geben Sie Ihre Mobiltelefonnummer oder E-Mail-Adresse ein
Über „Link senden“ stimmen Sie den Amazon-Nutzungsbedingungen zu.
Sie stimmen zu, unter der oben angegebenen Mobiltelefonnummer über die Kindle App eine automatisierte Textnachricht von oder im Namen von Amazon zu erhalten. Ihre Zustimmung ist keine Bedingung für einen Kauf. Möglicherweise fallen Kosten für Nachrichten und Daten an.
Dem Autor folgen
The Inmates are Running the Asylum Gebundene Ausgabe – 1. April 1999
Dieses Buch gibt es in einer neuen Auflage:
Rather than provide users with a straightforward set of options, programmers often pile on the bells and whistles and ignore or deprioritize lingering bugs. For the average user, increased functionality is a great burden, adding to the recurrent chorus that plays, "computers are hard, mysterious, unwieldy things." (An average user, Cooper asserts, who doesn't think that way or who has memorized all the esoteric commands and now lords it over others, has simply been desensitized by too many years of badly designed software.)
Cooper's writing style is often overblown, with a pantheon of cutesy terminology (i.e., "dancing bearware") and insider back-patting. (When presenting software to Bill Gates, he reports that Gates replied: "How did you do that?" to which he writes, "I love stumping Bill!") More seriously, he is also unable to see beyond software development's importance--a sin he accuses programmers of throughout the book.
Even with that in mind, the central questions Cooper asks are too important to ignore: Are we making users happier? Are we improving the process by which they get work done? Are we making their work hours more effective? Cooper looks to programmers, business managers, and what he calls "interaction designers" to question current assumptions and mindsets. Plainly, he asserts that the goal of computer usage should be "not to make anyone feel stupid." Our distance from that goal reinforces the need to rethink entrenched priorities in software planning. --Jennifer Buckendorff
Über den Autor und weitere Mitwirkende
Alan Cooper is a software author and visionary whose industry credits include creating the visual programming interface for Microsoft's Visual Basic. His one-man crusade for better design in the '90s has evolved into the Cooper Interactive Design firm, which he founded in 1992. As an industry leader, he is frequently speaking at computer conferences such as VBITS as well as meeting with industry leaders to provide guidance and direction.
- Herausgeber : Sams; First Printing Edition (1. April 1999)
- Sprache : Englisch
- Gebundene Ausgabe : 261 Seiten
- ISBN-10 : 0672316498
- ISBN-13 : 978-0672316494
- Abmessungen : 16.51 x 2.54 x 24.13 cm
- Amazon Bestseller-Rang: Nr. 926,867 in Bücher (Siehe Top 100 in Bücher)
Informationen zum Autor
Spitzenbewertungen aus Deutschland
Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.
There are many better UX/UI books out there.
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.
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."
Spitzenrezensionen aus anderen Ländern
Something Mr Cooper talks about is people not knowing their customers, but falls into this trap himself. While the book may have been written with managers and project leaders in mind, many developers will read it as a means of improving themselves.
With this in mind, writing a book that often hints at poor interface design being a deliberate attack on users, and in some places implies that software is hard to use because programmers are getting back at people because they were picked on in high school might be a little silly. This kind of hyperbole is not helpful in getting the message across, and will not help business people further understand their staff.
Helping business people understand that different people have different skills and getting the right person for the job will deliver better results than forcing someone to do a job they are not suited for would have been a better result. As it is, I can see how some PHBs would come away from this book believing that they produce bad software because their developers hate them, rather than because they have poor processes and do not invest enough time and money in the right places.
I am one of the geeks that Cooper targets, but I think I'm sufficiently self aware to know that his point is entirely justified. Building workable, usable applications on time and on budget is a fiendishly difficult problem. Pretty well all of the effort in improving our working practices has focussed on getting our job done more efficiently and predictably so that customers get their applications in reasonable time and at a reasonable cost. We've always been pretty clueless about the human side, making sure that the applications can be used easily and efficiently. That, of course, has great practical and financial consequences, but the cost is often hidden from the developers who have moved on to screw up elsewhere.
Cooper sometimes overdoes his argument, and minimises the real, practical problems involved in applying his techniques. His insistence on calling all developers as "programmers" is a bit irritating, but I can accept that as a stylistic quirk rather than evidence of ignorance of software engineering.
I'd strongly recommend this to software developers who are starting to have doubts about whether they're really delivering what users need. Of course, the ones who have no doubts are the ones who really need to read this book, but I suspect they wouldn't even pick it up, and they's throw it aside after the first few pages if they did give it a go. Pity.
Read Part IV several times and take notes as it gives solutions to the identified problems and is actually really good.
Skim the rest...
For a man promoting that less is more he could do with applying his own advice to the new edition of this book...