Linux - quer gedacht

From ThorstensHome
Revision as of 20:44, 28 March 2009 by WikiSysop (Talk)

Jump to: navigation, search

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.


Es wird häufig gesagt, Linux sei nicht Enterprise-ready. Am Anfang habe ich nicht verstanden, was gemeint ist, dann habe ich nicht gewusst, wie ich es vermitteln kann. Ich hoffe, jetzt kann ich beides. Also, wir hatten mal bei Novell einen Bugreport aufgemacht, dass unsere Software mit NIS nicht funktioniert. Der Bug wurde geschlossen mit dem Vermerk "Disable NIS". Das ist symptomatisch für das völlige Fehlen von Verständnis für enterprise-readyness. Es ist eben nicht so, dass ich jederzeit über alles im System entscheiden kann - ob NIS eingesetzt wird oder nicht, ist nicht meine Entscheidung, sondern die von einer ganzen Gruppe anderer Leute. So funktioniert ein Unternehmen, und es ist typisch für die Open-Source-Gemeinde, dass die Entwickler sich nicht vorstellen müssen, dass ich nicht jedes Detail in meiner Konfiguration selbst bestimmen kann.



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 <>.
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.

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.

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 ;)