Rules of Usability: Unix

Eric Steven Raymond and Rob W. Landley have written an intriguing, free online book called The Art of Unix Usability. Although the site has been receiving more than its fair share of attention over the past 24 hours, the chapter titled Rules of Usability is worth a second, third, and fourth look. Roll the highlight film:

Rule of Bliss: Allow your users the luxury of ignorance.
"Simplify, simplify, simplify. Look for features that cost more in interface complexity than they're worth and remove them."

Rule of Distractions: Allow your users the luxury of inattention.
"One good test for an interface design is, therefore: can it be worked comfortably while the user is eating a sandwich, or driving a car, or using a cellphone?"

Rule of Flow: Allow your users the luxury of attention.
"Well-designed interfaces do not clamor for attention or advertise their own cleverness . . . They support concentration and creativity by getting out of the way."

Rule of Documentation: Documentation is an admission of failure.
"The best user interfaces are so transparent and discoverable that they don't require documentation at all. "

Rule of Least Surprise: In interface design, always do the least surprising thing.
"If you're writing a calculator program, '+' should always mean addition! . . . The best interface designs match a pre-existing model in the minds of their user populations."

Rule of Transparency: Every bit of program state that the user has to reason about should be manifest in the interface.
"Mindspace is much more scarce and precious than screen space . . . Interface design is not a game to be won by claiming those slots [the 7+-2 slots in short-term memory; see below] -- to the contrary, you've done your job best when the user is freed to allocate them himself."

Rule of Modelessness: The interface's response to user actions should be consistent and never depend on a hidden state.
"It has been widely understood that modes are a bad idea . . . A computing system ideally designed for human use would have one single set of gestures and commands that are uniformly applicable and have consistent meanings across its entire scope."

Rule of Seven: Users can hold at most 7+-2 things at once in working storage.
"While users may be able to visually recognize more than seven controls, actually using them will involve refreshing short-term memory with retrieved knowledge about them."

Rule of Confirmation: Every confirmation prompt should be a surprise.
" . . . It is very bad practice to have confirmation prompts for which the normal answer is 'Yes, proceed onwards'. Thus, routine confirmation prompts are a bad idea."

Rule of Failure: All failures should be lessons in how not to fail.
"A special hell awaits the designers of programs whose response to errors is a message or popup giving a hex code, or one cryptic line that simply says 'An error occurred . . . ' . . . In a well-designed UI, all failures are informative. There are no brick walls; the user always has a place to go next and learn more about the failure and how to recover from it."

Rule of Automation: Never ask the user for any information that you can autodetect, copy, or deduce.
"Every time you require a human user to tell a computer things that it already knows or can deduce, you are making a human serve the machine."

Rule of Defaults: Choose safe defaults, apply them unobtrusively, and let them be overridden if necessary.
"Autodetection can become a problem if the computer guesses wrong and there is no way to override the guess."

Rule of Respect: Never mistake keeping things simple for dumbing them down.
"It is misguided and lazy to attack simplifications of an interface by claiming that they necessarily dumb it down. The test for a good simplification shoudl always be the same -- whether or not it makes the user experience better -- and that test shoudl be checked with real users."

Rule of Predictability: Predictability is more important that prettiness.
"You don't get usability from mere prettiness. Beware of pushing pixels around too much."

Rule of Reality: The interface isn't finished till the end-user testing is done.
"Far too many programmers who would never consider shipping a library without a test suite are somehow willing to ship programs that feature an interactive UI without testing them on real users . . . Go out and talk to people who are likely to use the thing. Slap together a quick prototype and get them to complain about it at length. Get a piece of paper and ask them to draw the interface they want with a pencil."