Slashdot Mirror

This book says it all.

"The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity
By Alan Cooper, Foreword by Paul Saffo

The Inmates Are Running the Asylum argues that, despite appearances, business executives are simply not the ones in control of the high-tech industry. They have inadvertently put programmers and engineers in charge, leading to products and processes that waste huge amounts of money, squander customer loyalty, and erode competitive advantage. They have let the inmates run the asylum. Alan Cooper offers a provocative, insightful, and entertaining explanation of how talented people repeatedly design bad software-based products. More importantly, he uses his own work with companies big and small to show how to create products that will both thrill users and improve the bottom line.

Reviews

"Frightening but true. Personal computers have engendered another New Age codependency. They shame us, they frustrate us and yet we keep spending money on them. Alan Cooper's book explains why it shouldn't be so and what we can do about it. A humbling and enjoyable read."
--Jean-Louis Gassée, Founder, Be, Inc. and Apple Computer France

"Once again, Alan Cooper shows the way. His books should be required reading for all those technology companies who think they are serving their customers: think again. We need more books like this one, and more people like Alan Cooper."
--Don Norman, Nielsen Norman Group, author of The Invisible Computer

"This clear-headed book teaches leaders what they need to know to create systems that win in the marketplace... you will find this one of the most thoughtful, practical, and helpful books you can read."
--Larry Keeley, President, Doblin Group

http://www.cooper.com/insights/books/

didn't buy Visual Basic

While that's strictly accurate, they did buy a tool for building task-specific customised Windows shells by dragging controls from a palette and dropping them onto a form, called at various stages, Tripod then Ruby, from Alan Cooper. they then glued a modified version of QuickBasic into it to create version 1 of VB. Cooper's original Tripod/Ruby could have multiple languages plugged into it, and he anticipated C as the main one. So while they didn't buy the VB language, they did buy the concept and the first version of the IDE.

Here's how Cooper tells the story

And homonyms! ;)

Yet mysteriously absent from http://www.cooper.com/alan/homonym_list.html and other homonym lists!

Ad homonym attacks are counterproductive

eye think ewe have heired.

-Ted

The notion that one person can collect (useful) end-user information and then implement it technically is analogous to asking the same person to design and then build your house. It's possible, but unlikely to be successful for larger projects.

You need someone who is trained in collecting the user behavior data, understanding what that means, and using that to guide the design (from a user standpoint) of the end product. They will gather information by interviewing and observing the users. This may include asking them what they want, asking them why they want it (what are the actual goals, not just features), observing the work they do, and understanding the greater context in which they do their work. Once they have an understanding of the needs, they will probably create many generations of cheap (perhaps on paper) prototypes that they can use to quickly acquire and integrate user feedback. Once that process has mostly defined the product (or aspects of a product) it can be turned over to you to figure out the technical implementation. (Of course the earlier on in the process that you are involved the more input you'll have on the final design.)

People who fill that role (or subsets of it) are commonly referred to as interaction designers, user experience architects, information architects, usability specialists, etc. They should be trained in accurate data collection, cognitive psychology, interface design, and a number of related skills. "Web Designers" frequently have a background in graphic design and don't have the rest of the training to make them the right person for this role. Accept no substitutes.

For more information on what this role is about, check out sites like Cooper, Boxes and Arrows, and OK-Cancel.

Good luck!

"Because managers don't trust engineers."

Oh, I can't imagine why.

Seriously, how on earth could they have picked something that is a homonym for a word that means either diminutive, penis, or urine and thought it was a good idea?

Actually, I think you mean synonym. Homonyms are words that sound the same but are spelled differently

Alan Cooper is a well known UI expert. His comments on dealing with users are fairly similar to yours: design for the user, observe the user, but don't let the user do the design.

-- Simon

What if necessary features aren't in the prototype?

Testing is a poor tool for doing feature selection and coming up with the concept, functional spec, and interaction design for a product.

Better than testing is doing up front field research to really understand user needs; internal business interviews to understand business goals; and then looking at features that will meet needs (instead of going on a feature frenzy first, as many many open source projects do)

I don't have a Gmail account either, so I'll speculate too. I don't see why you couldn't take your sorting methods, and instead of outputting a web page, just output some XML or some other information on the threading structure of that mail box. Then you can display it as a web page, or as a folder in Kmail or whatever. You might need to store your mail in some Gmail database or whatever, but it could be separated.

But as it happens you have underestimated the gmail guys. By approaching the problem from the point of view of user goals, they have started from first principles and built a new way of looking at one's mailbox, in which (for example) conversations are kept together forever (redundant quoted text is tastefully hidden by default), potentially able to be continued at any time, with fast searching.

This is arguably not revolutionary -- web forums like /. and USENET readers have worked this way for some time -- but gmail applies it to email better than any other MUA I've used before, and it couldn't have happened if the developers had approached the problem in a typical "programmery" way by building an uninspiried "bucket of messages" mail-folder mangement API like C-Client and leaving the UI folks to put a pretty skin on top of it.

homo logicus, Allan Cooper author of Inmates running the Asylum and creator of Visual Basic calls this. Software developers, coders call them what you like actually are very different to ordinary garden variety software users. Garden variety users run software to achieve goals. Cooper outlines in the book *goal directed* development that prescribes the interaction of the user to achive their goals and alligns user interaction with the software created.

This is not simply interface design ~ the sort normally tacked on the top of a product by graphic designers but a form of user interaction contract between user, user interaction and the underlying software completed before gui design, software engineering, coding etc. Think of it as a form of a user interaction interface (in the coding sense) that allows users to achive goals. Cooper pointed out this part is negotiatable with developers but not to be used as a guideline, but as a specification to be followed.

Having more power does not necessarily allow them to achieve their goals any better. In fact more complexity can actaully increase cognitive friction, a term describing the mental model you must construct to work the software to do something. Think about the cognitive friction the next time you want to create a document in MS Word ~ a product with a complex interface whose goal is essentially to create text documents.

Yes, the fact that the dialogs don't follow an established STANDARD does hurt the usability, but I don't think that they are BAD.

Yes, that is pretty much the definition of a bad GUI program.

Some of the most usable UIs don't conform to an established standard. For example, there are shopping cart apps that can be used by people who've never used a computer before, yet they don't get in the way of the expert user much either. Some custom-designed kiosk systems serve their purposes very well without following any standard other than "touch me".

Apple and Microsoft seem to throw out their own guidelines whenever they feel the need to "innovate". There's no hope of improving usability if no one's allowed to experiment.

Check out Alan Cooper's books if you want some solid reasoning behind this (better than I could give you). Edward Tufte is also a classic.

You know, English has Homonyms, too:

Sealing and Ceiling
Census and Senses
Cent and Scent
Right and Write

And just like Japanese, they are spelled differently (different Kanji == different spelling). As a beginner, you are learning Japanese in romaji and hiragana, but most homonyms are written in Kanji in everyday use, so it's really not a problem. Just because two words are spelled the same using hiragana, doesn't mean they are they same word.

The only chance for confusion comes when the language is spoken, but homonyms usually vary in meaning so much that only one meaning will fit in a given context.

Alan Cooper's book The Inmates Are Running the Asylum: Why High-Tech Products Drive us Crazy and How to Restore the Sanity" has a great story about a Porsche that required a factory reset if the fuel level was too low. This feature was designed to protect the fuel injectors from running on empty. Unfortunately, the engine could shut down if the tank was close to empty and the car went around a corner. The centripital force of cornering left the fuel level center high and dry. The car could only be restarted at a Porsche dealer.

Ahh...and the remotes. This is the kind of stuff that has ALWAYS needed a lot of work. Check out this Cooper article on an elegant solution.

Plus the old ones have such a crappy user interface that you accidentally drop bombs on your own troops. Apparently, its a 14 step process to replace the battery, and in the confusion of battle mistakes are made. The same display for "current" location is used for "target" location, and in Afghanistan they dropped some on themselves. (Learned during a presentation by Alan Cooper).

Sorry to continue on, on my own comment, but I just wanted to add some stuff.

Ironically, Alan Cooper's website has become a little less 'obvious' to navigate. So here's a direct link to Alan Cooper's books (like "The Inmates Are Running the Asylum").

To continue on the subject of how configurable a UI should be, I think it's very important to consider _what_ is configurable.

Take for example themeing. I couldn't care less for that shit. I have no time to fuck around with purtyfing a machine. I change machines too often and I use too many different machines.

On the other hand, say I start a large download from an FTP site and decide to go get a beer because it's a really large download that's going to take two hours, and while I'm gone, it bombs out at 50%, putting up a message box asking whether I want to retry or cancel, What The Fuck do the developers of that software think I would want to answer? Of course I want it to retry.

The alternative would be to write the software such that it would display the fact that it has problems, along with a 'cancel' button to quit anytime I like, but in the meantime it would continue to retry until it has what I wanted.

I mean the fact that I asked the fucking computer to download the file indicates that I want it right? Why would it need to ask me if I want to retry because of some technical glitch that I couldn't care less about?

Well, you catch my drift.

So, yes, I do want an option in the configuration that says "retry as long as I don't press cancel".

But I think too many configuration options are there because the developers are insecure about what's 'right'. Hidding the 'for experts only' options is a nice thing, but look at OS/X, they just said 'this is it, this is the right way' and they seem to be largely right.

At the end of the day, to make a product succesful, it's no good to have options to configure stuff that only one or two people care about. If you can have the UI present things in two different ways, and you have an evenly divided group of users that feel strongly that it should be either one way or the other, then yes, it should probably be configurable. Otherwise, screw it. Apparently not enough people complained about the fact that you have to hit 'Start' to shutdown your computer in Windows...

As mosfet writes:
Check this out to see a developers take on the whole "less-is-more" debate going on about Linux user interfaces

Now, I've no doubt he's a very gifted developer. But more often than not, a developers opinion on UI issues should be disregarded.

It's not because they couldn't potentially be good at it, it's because their brain is occupied with technical issues that have no relevance to an end-user.

Alan Cooper has written some pretty fine books about these issues, which I'm sure any developer related to UI design finds very informative. Some of the anecdotes are hilarious.

Unfortunately, it seems that Human Interaction Design is still not very high on the list when people design a product, resulting in there not being very many people that have specialized themselves in this field. It goes without saying that finding the right people for such a job for open source projects is tricky, to say the least.

For more information on how usability and user goals should be designed BEFORE coding, Alan Cooper written some great books on usability and design . Ok, so they are mostly Windows-focused, but his design approach is universal. "About Face: The Essentials of User Interface Design" is written for designers and programmers. "The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity" is written for PHBs and marketing people.

Rebuttal: If by bastardize it you mean change it to suit their needs, the needs of their users, and make several big improvements - you are very right...

I am not certain where you are coming from, but it is an indisputable fact that Microsoft rarely (if ever) invents the technology that it markets. Back in the mid-90s, industry pundits used the term, "leveraging" to describe this behavior. Examples are, of necessity, numerous. Here are a few examples off the top of my head, that every computer hobbiest should know:

1) DOS and Windows both contain code originally written by Digital Research for CP/M. In fact, DOS is a CP/M clone, re-compiled for the 16-bit microcomputer.

"on July 24, 1996, Caldera Inc. filed a private Federal Antitrust Lawsuit against Microsoft Corp. for alleged illegal activities and unfair practices in the marketing of MS-DOS and its successors, including Windows 95 and Windows 98, both of which are still Digital Research CP/M at their essential core. The lawsuit was settled out of court in January 2000 at which time Microsoft Corporation agreed to certain terms and paid certain funds to Caldera Inc."

CP/M: The First PC Operating System

2) Visual Basic was derived from the work of Alan Cooper (aka, "The Father of Visual Basic"), who had created a new Windows shell he called, "Tripod." Microsoft bought Tripod from Alan Cooper and code named it, "Ruby."

Why I am called "the Father of Visual Basic"

3) File compression had a rough birth into Microsoft's official OS distribution. Originally, Microsoft did not offer any data compression utilities, but several other companies did. One company, named, "Stac," lent their disk compression utility for Microsoft to evaluate. Microsoft included Stac's code in MS-DOS 6.0, but Stac sued, claiming that there was no licensing agreement for distribution (IBM also included Stac's code in PC-DOS, but they had a distribution license, and so were not sued). The two companies settled out of court. Microsoft initially pulled its disk compression software off the market, but then returned it after the settlement.

You see, the problem with your comment is that it's way too left-wing to ever be completely true

Left Wing or not, he is reasonably accurate.

while Microsoft has definately done some things that are a bit (ok, in some cases a lot) underhanded, that doesn't have anything to do with the quality of their software,

Stating that Microsoft has not invented the technology it markets is not the same thing as claiming that the quality of their product is poor.

which is getting better every release and starting to rival Linux on several very important issues.

Considering that Microsoft had about a 15-year head start over Linux, you make a sad statement.

Microsoft didn't create VB
This guys company did. Cooper.com
Microsoft just bought it off them.

He would call what you are talking about "interaction design" not "interface design". The Inmates book makes a good case for how the two are different and why interaction design is a better approach.

Herein lies an important tenet of usability testing, which is Jakob Nielsen's "First Rule of Usability:"

Don't Listen to Users

You may think the Windows interface is OK, but your saying so is no substitute for observing you in action. Chances are--and no offense intended--you probably don't get along as well as you think you do.

And you have to have something to compare it to. When compared with the Macintosh, the Windows GUI is much slower. Just, Ask Tog. Finally, as MaxVlast points out,

• the user shouldn't care or think about whether a program is running or not, he should simply use the right tool for the right job

Would you like to see a list of homonyms so you don't make an idiot of yourself in public?

If you have anything to do with designing any sort of interface to any sort of product (be it a piece of hardware, a piece of software, a widget, whatever), you should read this book. It will open your eyes.

You just know that if it finds any errors, it's going to blame me, even though I don't even know where its disks ARE.

The changes we need to make in software are far greater than just having "the most reliable Windows experience ever".

• Requirements will always fluctuate throughout the development cycle, because users cannot entirely formulate what they want until they have seen something close. For the same reason, requirements can never be fully formalized--the more explicitly complex behavior is described, the more likely it is not exactly what the user wants.

(Note: I'm still on my Inmates... kick.)

Alan Cooper would seem to argue that this is not a license to take longer. Rather, users "have funny quirks . . . that interfere with the design process" (129) (emphasis added); "it is more important to define [an estimated user's requirements] in great and specific detail [and design based on these] than that the [user profile] be precisely the correct one" (129).

As in your second point, in the absence of any other data (e.g., no popular competing product the features of which you can copy) it may be better to take a guess and get something out there than spend 10 years making it "perfect."

Great point. Most people simply want to be productive without feeling stupid.

For some wonderful insight on that very issue (among other things), I would highly reccommend reading The Inmates are Running the Asylum by Alan Cooper. (I'm reading it now and thoroughly enjoying it.)

I agree.

If anyone's interested in the theory behind usability, I recommend this book on Human Computer Interaction as an introduction.

Also, here are some web-sites I found useful:

- Cooper design
Excellent collection of articles, case studies and, for students who want bullet-point summaries for ease of recall, a nice list of HCI design axioms. See in particular http://www.cooper.com/design/ where there is a series of articles, including one entitled "The myth of metaphor". Cooper is also the author of two excellent books on interface design.

- Ask Tog Design
Bruce "Tog" Tognazzini developed the first version of the Apple Human Interface Guidelines in 1978, moved to Sun, and is currently lead designer at Healtheon. He has published two excellent books on interface and software design and at this web site, he answers questions and discusses interface issues with wit and insight.

- Jacob Nielsen's website
Nielsen produces a bi-weekly column on web usability and has also just published a book called Designing Web Usability: The Practice of Simplicity which is getting rave reviews. He is widely regarded as a leader in the field of web site design and usability testing.

- Interface Hall of Shame
An excellent collection of scathing but accurate reviews of user interface disasters of one sort or another. The ultimate depressing experience for any interface designer must be to end up here.

- HCI Reading List
If you want an exhaustive list of HCI reading materials, this is a good place to look. It is reasonably up-to-date (Feb 98) and has useful comments on the majority of textbooks in this area.

- University of Maryland Human-Computer Interaction Lab
The Human-Computer Interaction Lab (HCIL) at the University of Maryland conducts research on advanced user interfaces and their development processes. They study areas such as new approaches to information visualization, interfaces for digital libraries, multimedia resources for learning communities, zooming user interfaces (ZUIs), technology design methods with and for children, and instruments for evaluating user interface technologies. The director is Ben Schneiderman, author of the book "Designing the user interface".

I agree.

If anyone's interested in the theory behind usability, I recommend this book on Human Computer Interaction as an introduction.

Also, here are some web-sites I found useful:

- Cooper design
Excellent collection of articles, case studies and, for students who want bullet-point summaries for ease of recall, a nice list of HCI design axioms. See in particular http://www.cooper.com/design/ where there is a series of articles, including one entitled "The myth of metaphor". Cooper is also the author of two excellent books on interface design.

- Ask Tog Design
Bruce "Tog" Tognazzini developed the first version of the Apple Human Interface Guidelines in 1978, moved to Sun, and is currently lead designer at Healtheon. He has published two excellent books on interface and software design and at this web site, he answers questions and discusses interface issues with wit and insight.

- Jacob Nielsen's website
Nielsen produces a bi-weekly column on web usability and has also just published a book called Designing Web Usability: The Practice of Simplicity which is getting rave reviews. He is widely regarded as a leader in the field of web site design and usability testing.

- Interface Hall of Shame
An excellent collection of scathing but accurate reviews of user interface disasters of one sort or another. The ultimate depressing experience for any interface designer must be to end up here.

- HCI Reading List
If you want an exhaustive list of HCI reading materials, this is a good place to look. It is reasonably up-to-date (Feb 98) and has useful comments on the majority of textbooks in this area.

- University of Maryland Human-Computer Interaction Lab
The Human-Computer Interaction Lab (HCIL) at the University of Maryland conducts research on advanced user interfaces and their development processes. They study areas such as new approaches to information visualization, interfaces for digital libraries, multimedia resources for learning communities, zooming user interfaces (ZUIs), technology design methods with and for children, and instruments for evaluating user interface technologies. The director is Ben Schneiderman, author of the book "Designing the user interface".

I don't have his current book's title, but it would also be a solid read on interfaces.

Alan Cooper started Cooper Interaction Design as a consulting firm that specializes in optimizing any human-machine interaction. They've helped with cell phones, programmable toys, word processors, hospital records management vertical databases, you name it. They don't write the code. They help you build the RIGHT interface for YOUR application.

Cooper has trademarked the term, "Rich Visual Modeless Feedback." Rich: lots of it; Visual: seen on the screen; Modeless: doesn't interrupt you; Feedback: lets you see what the computer thinks. A classic example is the red squiggly underline in Microsoft Word: it happens automatically, you see it, you know the word is misspelled, it doesn't interrupt you, you can go back to it when you want to.

There's two sides to any interface. In computer user interfaces, the computer and the human should be considered in an implicit partnership to get the human's tasks done.

In essence:

• The Computer should be able to figure out what the Human is thinking, and
• The Human should be able to figure out what the Computer is thinking.

Alan likes to say things like "Don't make the user feel stupid!" By that, he means situations where the computer program seems to delight in stopping the user's flow, just to pop up annoying messages. Or they can't seem to remember the user's preferences.

Anyone who has used a computer before, bitches loudly at the Win95 default setting of showing subdirectory contents without a tree view.

As it turns out, in many useability studies, some Microsoft, some not, it turns out that a frightening percentage of people (even existing computer users) were unable to grasp the concept of a hierarchy . They just can't get it. Win95 hides the tree by default, since people can get used to "click this, click that, click that," sequences, much like driving-by-landmark.

One of Microsoft's aphorisms, which unfortunately they fail to follow, goes something like:

Make the everyday tasks simple; make the more complicated tasks possible.

winamp has a good many themes that do not mess with functionality

Winamp, which popularized this whole app theming thing, is an excellent example of an application where themes, while they may not help functionality, certainly don't hurt it. It's a simple app, with a few buttons and an information display area. Most people who cannot program their VCR can use it to play tapes. They also don't have a problem using the CD player, and that's really all Winamp is, so making the buttons look like brushed aluminum doesn't really slow most users down.

Additionally, Winamp is a parasitic application -- meaning that it usually runs alongside other applications, and the user rarely runs Winamp exclusively. The user spends little time working with Winamp itself, they're busy using their main applications, with Winamp playing in the background.

What's needed is to spend more time working on the basic usability of applications and widgets. Go read (as mentioned before) the Interface Hall of Shame. Read AskTog's rant about the differences in how Windows and the Mac handle cascading menus.

Lemme tell you about my little improvement to widget usability. I'm working on an application that works as a Win32 Appbar (like the Start menu). It can be docked to any edge, and can be auto-hidden, staying out of the way until the user moves the mouse over the edge the appbar is docked to.

When I first started testing it, I set the appbar properties to auto-hide and stuck it at the top of the screen (my Start bar, like most people's, is at the bottom). This sounds fine, but turned out to be a major irratant -- every time my mouse pointer hit the top of the screen (like, say, when I was going for a menu), the damn appbar would drop down! I'd then have to move the mouse pointer down, wait for the window to retract, then, slowly, move back up to the menu (without moving too high!), then make my selection.

A simple timer, with a user-defined delay, solves this problem. When the mouse moves to the appbar's edge, a timer is started. If, when the timer expires, the mouse is still on the edge, the appbar will show itself. If the user clicks on the top edge (indicating they want to see the appbar immediately), the appbar will show without waiting for the timer.

That's the kind of work UI designers should be doing.

Alan Cooper once said that the web has set user interface design back 15 years. I agree. Instead of ensuring that your applications can be themed by every 31337 h4x0r with a warez copy of Photoshop, make the interface work better.

Right.

This can't be resolved by making interfaces intuitive, any more than we can make graduate-level math accessible to children by using "intuitive" words and pictures to describe it. Eventually, we have to accept that part of what we want to do is educate the users a bit more, so they can figure out what they want to do; at this point, the interface can be designed for efficiency. Expert-friendly is the way to go.

Wrong.

This reflects a gross misunderstanding of what user interface design is all about. It's not about graphical user interfaces. It's about allowing low-risk exploration of the options with constructive feedback, so that the user will converge on something that works for them in a short time. Read Alan Cooper for some insight. Or play a good video game, thinking about how you learn how to play it.

Until the open-source community gets this, Linux on the desktop is going to suck.

Oh, and don't let the fact that he works for M$ sway you, I'm fairly convinced no one listens to him there. :)

Besides, that should perhaps be "worked for"; he works for Cooper Interaction Design (although, as the name of the company suggests, "works for" probably understates the case :-)). The book says that he was the designer of the visual programming interface for Visual Basic - but don't let that sway you, either; in About Face, he's perfectly willing to thump Microsoft for things he considers bogus (such as excessively-deep cascading menu on, for example, the Start bar; of course, excessively-deep cascading menus are hardly unique to Windows).

Alan Cooper is Da Man! I absolutely love "About Face : The Essentials of User Interface Design", but his new book "The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity" just seems to rehash his old material. Check out his company's web site: www.cooper.com

Before you pick up any book on how to build GUIs, you really ought to have a look at Alan Cooper's The Inmates are Running the Asylum. In fact, it ought to be compulsory reading for anybody building any kind of software. It explores concepts such as -- gasp! -- thinking about what the user is likely to need before design and coding, sticking to the original design, and treating prototypes as prototypes and not version 0.5.

Its theories on why all software is crap are refreshing and while it's simplistic in places, it's a book that both PHB's and those who actually do the work can comprehend.

Off topic, I know, but...

"About Face; The Essentials of User Interface Design", by Alan Cooper
ISBN 1-56884-332-4

I strongly recommend this particular book for anyone looking at doing some serious UI design.

Regardless of whether the browser is part of the OS or not, I think Micorosoft's Neptune project looks promising. Dvorak has an article describing it "Microsoft's Secret OS Plan" and a screenshot. Most users are not tool-oriented, they are task-oriented. They think "I want to copy my resume to that floppy disk", not "I need to mount my /dev/fd0 and blah blah".

For more info (and strong opinions) about UI usability, check out Alan Cooper's company. His book About Face : The Essentials of User Interface Design focuses on Windows (including many jabs a Microsoft Word), but it's applicable to any UI.