Informatik

Ergonomische Software sollte selbstbeschreibungsfähig sein. Die gesamte Benutzeroberfläche sollte selbsterklärend sein, idealerweise sollte der Benutzer nicht erst das Benutzerhandbuch einstudieren müssen, um mit der Software von der Installation bis hin zum erwünschten Ergebnis kommen zu können.

Dennoch sollte es ein Benutzerhandbuch geben, welches alle Funktionen verständlich und ausführlich beschreibt, jedoch den Nutzen jeder Funktion auf  den Punkt bringt. Für das richtige Schreiben des Benutzerhandbuchs gibt es eine  Reihe eigener Regeln für Struktur, Sprache und Technik. In Deutschland ist das Fehlen eines verständlichen und vollständigen Handbuchs sogar als ein Mangel nach dem BGB zu sehen.

Fern ab vom Handbuch, sollte die Software selbst jedoch selbstbeschreibungsfähig sein, denn dies gewährleistet den flexiblen Einsatz der Software.

Probleme durch falsche Bedienung sowie auch Programmfehler sollen durch Dialoge angezeigt und erklärt werden, zudem sollen nach Möglichkeit Lösungswege vorgeschlagen werden. Dabei ist auf eine Sprache zu achten, die an die Zielgruppe des Programms angepasst ist, in jedem Fall aber klar formuliert, ohne Rechtsschreib- und Grammatikfehler (diese stellen nicht nur die Software-Qualität in Frage, sondern könne auch für sprachliche Mehrdeutigkeiten sorgen).

Die Benutzeroberfläche ist dann nicht selbstbeschreibungsfähig, wenn Funktionen sowie der funktionale Zusammenhang ganz oder teilweise unverständlich ist. Wenn dazu noch keine weiterführenden Informationen (z. B. als Hilfe, FAQ etc.) abgerufen werden können, ist die Software bei entsprechender Komplexität quasi nur noch für an der Entwicklung beteiligten Experten bedienbar und somit weder wirtschaftlich noch flexibel einsetzbar.
Der Benutzer muss sich über den Funktionsumfang und den aktuellen Systemzustand informieren können, diese Informationen müssen ihm leicht zugängig sein. Es ist für den optimalen Softwareeinsatz außerdem unabdingbar, dass der Benutzer sich leicht über den Programmvorgang leicht verständlich und schnell erfassbar in Kenntnis gesetzt wird. Beispielsweise ist es sehr ärgerlich, wenn das Programm auf Parameter wartet, der Benutzer dieses jedoch gar nicht weiß und den Programmfortschritt abwartet.

Die Software soll Rückmeldungen an den Benutzer geben können und darüber informieren, wie das Ergebnis erreicht wurde (Prozesse) bzw. auftretende Probleme erläutern.

Um Routinetätigkeiten jedoch nicht unnötig auszubremsen, sollte der Informationsgrad jedoch vom Benutzer bis zu einem verantwortbaren Bereich einschränkbar sein.

Software ist auf eine bzw. mehrere Aufgaben ausgerichtet entwickelt worden. Die Software muss für diese Aufgaben angemessen gestaltet und benutzerfreundlich sein.

Ist die Bereitstellung aller benötigten Informationen und Funktionen zur Erledigung einer vorbestimmten Aufgabe (z. B. die Erstellung von Textdokumenten oder CAD-Modellen) durch die Software nicht gegeben, so ist die Software nicht angemessen praktikabel und wenig benutzerfreundlich gestaltet.

Der Benutzer soll (durch Tipps und Empfehlungen) von der Software über Informationen und Zustände informiert und unterstützt, jedoch möglichst nicht genervt werden. Dies wird mit einem Dialogsystem (vom kleinen Hinweis in der Statusanzeige bis hin zum Piepton begleitetem Fenster-Dialog) erreicht, wobei sich die Software Einstellungen (Kenntnisnahmen und Prioritäten wie Sicherheitsstufen / Warnlevel) merken muss. Wurde eine immer wieder auftauchende Information vom Benutzer zur Kenntnis genommen, soll dieser Benutzer den Hinweis auf diese Information deaktivieren können (deaktivierfähige Hinweise sind beispielsweise Tipps über die Software beim Start der Software oder bei Ausführen einer bestimmten Aktion z. B. dass eine Datei vor dem öffnen automatisch konvertiert und als temporäre Datei abgespeichert wird).

Äußerst wichtige Hinweise, insbesondere die, welche bei Unaufmerksamkeit zu Datenverlust oder schlimmeren führen können, sind jedoch von der Deaktivierfähigkeit auszuschließen. Ein Beispiel: Wird die Anwendung geschlossen, gehen nicht gespeicherte Änderungen verloren. Der Hinweis auf diese Tatsache sollte nicht automatisch umgangen werden können, es ist aber automatisch sicherzustellen, dass der Hinweis nur erscheint, wenn wirklich Änderungen nach dem letzten Speichern vorgenommen wurden.

Aufgaben, die aus der technischen Eigenheit der Software und des Systems erwachsen und aus denen keine kritischen Zustände entstehen können, sollen durch das System eigenständig ausgeführt werden (z. B. Zwischenspeicherung, Überprüfung von sowie Hinweis über Systemkomponenten und Kompatibilität).

Verfügbare Funktionen der Software sollen an wiederkehrende Aufgabenstellungen angepasst werden können (z. B. durch Standardwertdefinierung, Abspeicherung von Profilen für unterschiedliche Zwecke).

Die Komplexität der Software, ihrer Funktionalität und die Aufgabe soll auf ein angemessenes Level reduziert werden
können. Der Benutzer soll nicht permanent mit Informationen überflutet werden, sondern sich auf das im Moment Wesentliche beschränken können. Elemente (Items) sollen logisch gruppiert, Ausschnitte gezoomt, Funktionsumfänge angepasst, dabei insbesondere beschränkt (z. B. wählbare Minimalinstallation, benutzerdefinierte Installation oder Ansicht) werden können.

1. Funktionen/Methoden dürfen nur einen Ausstiegspunkt (return) haben
   Dies ist nicht richtig, es wird jedoch von vielen erfahrenen Entwicklern als unschön angesehen, wenn eine Funktion mehrere Ausstiegspunkte hat. Die Funktion kann so aber schneller abgehandelt werden, wenn die Funktion sofort mit „return“ verlassen wird, wenn eine Bedingung hierfür gesetzt wurde. Gibt es nur ein „return“ am Ende der Funktion, wird die Funktion in die Länge gezogen.
   
2. UDP-Pakete brauchen Prüfsummen
   Natürlich nicht. Das tolle an UDP ist ja gerade, dass Pakete quasi blind (und schnell) weggeschickt werden können. UDP sollte sowieso nicht da verwendet werden, wo Daten unbedingt ankommen müssen. Wenn Daten unbedingt ihr Ziel erreichen sollen, sollte der Weg auch frei sein, gleich das verbindungsorientierte TCP statt UDP zu nutzen.
   
3. C ist veraltet
   Bis jetzt gibt es viele Anwendungsbereiche, bei welchen C ziemlich alternativlos ist, z. B. teilweise in der Programmierung von Mikrocontrollern und der hardware-nahen Programmierung generell.
   
4. Open Source ist Freeware
   Freeware meint nur Software, welche kostenlos zu haben ist, also „frei“ im Sinne von „kostenlos“. Dabei kann Freeware auch Open Source sein, muss aber nicht. Freeware könnte zudem auch mit einem Kopierschutz etc. ausgestattet sein. Open Source (auch bezeichnet als „Freie Software“) ist quelloffen und kann zum Nutzen für die Gemeinschaft ausgeführt, verbreitet und verändert werden.
   
5. Jede nicht-objektorientierte Software ist nicht auf dem Stand der Zeit
   Objektorientiertheit zahlt sich in höheren Programmiersprachen sehr aus, jedes Skript und auch bestimmte Programme, die auf Geschwindigkeit ausgelegt sind, müssen (oder sollten?) aber nicht unbedingt objektorientiert sein.
   Ein umfangreiches Verwaltungsprogramm sollte schon in z. B. Java/C# rein objektorientiert umgesetzt werden, ein Skript, welches eine Textseite parsen soll oder ein Programm für einen Mikrocontroller muss aber nicht gleich objektorientiert sein.
   
6. Globale Variablen sind immer schlecht
   Als ich meine ersten Programme in C/C++ geschrieben habe, habe ich es mit den globalen Variablen schon ein bisschen übertrieben. Das ist ein typischer Anfängerfehler. Aber wenn man mal ein paar Schritte weiter ist oder sich mal Open Source betrachtet, findet man immer wieder ein paar globale Variablen, und das völlig berechtigt. Es gibt Situationen, da müssen neben Konstanten auch ein paar Variablen überall verfügbar sein. Anders als Konstanten können gloibale Variablen verändert werden und so einen aktuellen Stand beschreiben.
   
7. Arrays und Zeiger sind dasselbe
   Arrays sind in C mit Zeigern umgesetzt, dasselbe sind Zeiger und Array jedoch lange nicht. In anderen Programmiersprachen entfernen sich Array und Zeiger sogar noch weiter voneinander.
   
8. Objektorientierung ist in C oder Assembler unmöglich
   Das stimmt so überhaupt nicht. Allerdings muss man da schon in C und Assembler mehr tun, als einfach eine Klasse zu definieren wie in Java/C#. Jedoch ist weder C und noch Assembler (die Programmiersprache eines Assemblers) auf Objektorientierung ausgelegt, es wird daher aufwändig und undurchsichtig mit der Objektorientierung, möglich jedoch schon.
   
9. Rekursion ist immer besser als die Iteration (Schleifen)
   Rekursion wird als schöner empfunden (und einige wenige Programmiersprachen kennen auch nur Rekursion), Rekursion ist aber z. B. in C grundsätzlich langsamer und speicheraufwändiger als Iteration (da immer wieder eine Funktion aufgerufen und geladen werden muss).
   
10. Java ist langsam
    Halbes Gerücht. Denn Java ist, das haben viele Tests z. B. von Fachzeitschriften gezeigt, im Vergleich zu Sprachen wie C/C++ schon langsam. Man sollte hier aber auch wirklich auf die Konzepte achten, so auch nur ein rein objektorientiertes Programm in C++ mit einem solchen in Java vergleichen (dass C++ objektorientiert ist, ist übrigens auch ein Gerücht, es handelt sich eher um eine hybride Sprache).
    Das Problem ist doch eher, dass bei Java oft übertrieben wird, was die Langsamkeit betrifft.