Slashdot
- No funny key combinations. Repeat, no funny key combinations.
Everything must be accessable through the menus. Yeah, I know you want
to be able to bind any control key combination to any function. Don't.
It doesn't really speed up use anyway. Read Apple's old studies on this.
People blank out on the 500ms they're thinking about the control key
combo. And never, ever use keyboard toggles that don't have a
permanently visible state on screen.
- If it's undoable, you don't need a confirmation dialog. If it's not
undoable, you need a confirmation dialog. Make it undoable if at all possible.
- Distinguish clearly between severe and non-severe errors. "You are
about to change your font to sans-serif" should look very different than
"You are about to permanently delete all your files".
- The user should never have to tell the computer something it already
knows. This is basic, and routinely violated in the Open Source world.
The user should never have to fill in a blank when the computer can find
out what goes in that blank. Offer a choice if necessary. Yes, much of
this comes from UNIX's crappy approach to system administration. Work on that.
- If you need a database, use a real database. Flat files are so 1970s.
Databases work today. The most troublesome apps in computing, BIND and
Sendmail, are both database apps with a bad homebrew database. Provide
for database validation and recovery.
- Anything that can get itself into a bad state must be able to get
itself out of that state. No more having to delete "XUL.mfl" every time
Mozilla screws up. Anything with cached data must get this right.
- If you try to be smart, make sure you're not being stupid. Try
entering data into an OpenOffice spreadsheet. If you have something like
"12 VDC" somewhere in your spreadsheet, and you type "1", it fills in
"12 VDC". Which you have to erase. Every time. Now go try that in
Microsoft Excel. Microsoft's wizards will fight you once, but if you
override them, they give up.
- Modal dialogs should be short and clear. They consist of a statement
of the problem and a suggested corrective action.
- Get the subtle stuff right. Grey out the options you can't use now.
Show in the menus whether something is off or on.
- Be rigorously consistent about how things appear to work, even when
it's more work for some cases.
Apple
Usability Guidelines