Trivial usability
This is about simple means to make a program easy to use. It is intended for developers and bug reporters.
Contents
WhoAmI
A good program tells you what it is for. This is especially important for attracting new user.
- Good Example
kolossus:~ # whoami --help
Usage: whoami [OPTION]...
Print the user name associated with the current effective user id.
Same as id -un.
--help display this help and exit
--version output version information and exit
Report bugs to <bug-coreutils@gnu.org>.
kolossus:~ #
- Bad Example
You want to do a file compare between two files so you type
fc file1 file2
Now you find that fc does not do a file comparison, but it is not easy to find out what it actually does:
# fc --help -bash: fc: --: invalid option fc: usage: fc [-e ename] [-nlr] [first] [last] or fc -s [pat=rep] [cmd]
The 80% rule
The 80% rule says that 80% of the times, only 20% of the program functionality is really used. It also says, in order to make 80% of your users happy, you only have to care about 20% of your program code. As a negative example, let's take zip. In 80% of the cases, you just want to zip a directory or a file. But the command line to do this is not intuitive and the solution is also not indicated by zip's help. Advice is: Don't point out the ever-so-special functionality in your program, first make, that the "80% usecase" works understandable for the user.
Reasonable Defaults
When you start your car, you can just begin to drive. Sarcastically spoken, if software was a car, you could not begin driving before
- setting up the fuel-injection pump to deliver the right pressure
- having a discussion with your ABS system, telling him you do not use diesel fuel (although you never used that)
- switching off all the "explode my engine"-tabs in your front
So, guys, remember the normal user - he just wants to run your program. Don't ask him, offer him defaults. He can change them whenever he wants.
Do not rely on wizards
Instead of giving a page that explains in 5 sentences what a name is and then asks the user for his name, then giving a page that explains what an e-mail-address is and asking the user for his e-Mail, just ask. Ideally, provide reasonable defaults. Better enable a help function that the user can invoke then force him to read lengthy explanations and click through various pages.
Status messages
Tell the user what you are doing. Do not behave as john the ripper. John the ripper prints:
john /etc/shadow Created directory: /root/.john Loaded 7 password hashes with 7 different salts (OpenBSD Blowfish [32/64 X2])
And then does nothing for several hours. You can guess that it tries to rip passwords, but in the end, you do not know.
Do not rely on documentation
A developer must deliver written documentation with his program - but intuitive programs explain themselves. Documentation is a possible point of failure - it can be outdated, wrong, or not to be found. A program that does not need it is more stable.
Do not offer what you don't have
I used to play chess using xboard. I prepared all my game to do a rochade later - I had seen in the menu there was a menu entry for it. When I finally had everything in place to do a rochade, that menu item turned out to be without function. A rochade was not possible, the menu item "rochade" was just there as a reminder to implement it. Sad story - I lost my game and never played xchess again. Do not offer functionality that you do not have.
Make the user understand
Make sure the user understands a bit what you are doing and why. For example, in my OpenOffice, I always get a menu at the beginning where I can chose that xyz.doc should be recovered. I do not need xyz.doc any longer, and I wonder why I should recover it - and why I have to confirm it. BTW, I can only confirm, nothing else. These two things cause frustration to the user: having no choice and no understanding about why all this is needed.
Do not confuse the user
There are two programs, adduser and useradd. Both have the same purpose, but do not exactly the same. I have learned and forgot the difference so often, I gave up. Do not do this with your users! If you have a myProgram and a ProgramOfMine, let them at least do the same stuff ;)
