Linux - quer gedacht
OK, das hier ist eine Idee von User:Mooz und mir.
Ein Gespenst geht um in der IT, das Gespenst heißt Linux. Linux ist eine Schöpfung von ein paar Couch-Potatoes, die gerne Helden wären, und sich deshalb eine soziologische Nische suchen, in der sie behaupten können, die "Freiheit" ("free, not as in 'free beer', but as in 'Freedom'") der Software, der Menschheit zu bewahren, sprich, die ganze Welt zu retten.
Man könnte fast meinen, die Linux user wären die verborten und die Windows-Nutzer die Normalen. Das Wichtigste, um ein angesehener Linuxer zu sein, ist der Stallgeruch. Wenn man nicht
- über Micro$oft (nicht Microsoft) schimpft
- einen Computer mit einer Uptime von einigen Jahren betreibt
- das graphische Einloggen als Administrator wie ein Verbrechen ablehnt
wird man nicht akzeptiert - da wird nicht diskutiert.
This topic lists simple means to make a program easy to use. It is intended for devolpers and bug reporters.
A good program tells you what it is for. This is especially important for attracting new user.
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 <email@example.com>. kolossus:~ #
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.
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.
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 ;)