Die Verantwortung der Entwickler
Marc Ruef | 06.04.2009

Ich habe schon einige Jahre als Security Consultant gearbeitet und so manchen Security Audit durchgeführt, als ich bei meinem damaligen Arbeitgeber einen der Entwickler näher kennengelernt habe (eigentlich habe ich ihm zuerst über Monate hinweg in den Pausen beim Billard das Geld aus den Taschen gezogen, aber darum gehts jetzt hier nicht). Er war ein heller Kopf, manchmal ein bisschen in seiner Welt gefangen, doch rundum ein lustiger und unterhaltsamer Zeitgenosse.

Sehr oft haben wir über Programmierung im Allgemeinen, unterschiedliche Konzepte und Paradigmen diskutiert. Wir waren zwar nicht immer in allen Punkten einer Meinung, konnten uns doch aber immer auf die Ansichten des Gegenübers einlassen. In einem Punkt waren wir damals jedoch entschieden uneins. So fauchte er immer wieder durch das Büro, dass Programmierung ganz einfach sei und der Fehler eigentlich immer nur vor dem Bildschirm sitzen würde. Er spielte auf die manchmal etwas unbeholfenen Benutzer hin, die mit seinen komplexen Programmabläufen nicht immer zurecht kamen.

Er vertrat damit die Meinung, dass sich der Benutzer dem herangezogenen Programm anzupassen hätte. Dem hielt ich vollumfänglich entgegen. Meines Erachtens ist ein Programm die Idee des Entwicklers, der sie einem Benutzer zugänglich machen möchte. Genauso wie ein Autor, Musiker oder Filmemacher seine Gedanken dem Publikum entgegentragen will. Der Schaffende, in unserem Fall der Programmierer, sollte mitunter darum bemüht sein, sein Publikum möglichst zufrieden zurücklassen zu können (und nicht nur seine egoistischen und egozentrischen Wünsche befriedigen zu können). Der Anwender muss sich mit der Applikation wohl und sich stetig behütet fühlen.

Dies bedeutet, dass der Endanwender davor bewahrt werden sollte, für ihn mit negativen Konsequenzen behaftete Fehler machen zu können. Es gibt zwei Möglichkeiten, wie dies durchgesetzt werden kann:

(1) Einerseits kann man den Anwender durch Warnmeldungen auf mögliche Probleme hinweisen. Durch ein explizites Bestätigen kann der Nutzer die potentiellen Risiken akzeptieren und muss mit ihnen leben können. Ein typisches Beispiel ist eine Warnmeldung, die erscheint, wenn man eine Datei unter einem Namen speichern möchte, der schon existiert. Der Benutzer muss sodann entscheiden, ob er die alte Datei wirklich mit dem neuen Inhalt überschreiben oder doch lieber einen neuen Namen vergeben will.

(2) Oder man fängt die Fehler im Hintergrund ab, um sie transparent korrigieren zu können. Zum Beispiel haben gewisse Zeichen in einem arithmetischen Rechner nichts zu suchen. Diese könnten vor der effektiven Berechnung einfach herausgelöscht werden. Voraussichtlich wird sich der Benutzer nur vertippt haben, vielleicht ist er beim Schreiben der Zahlen abgerutscht oder hat bei der Nutzung von Copy&Paste ein Zeichen zu viel erwischt. Im besten Fall wird er gar nicht bemerken, dass er korrigiert worden ist. Im schlechtesten Fall wird er aber auch in Zukunft das Gefühl haben, den nicht wahrgenommenen Fehler immerwieder machen zu dürfen.

Die Schwierigkeit einer guten Anwendung liegt meines Erachtens also schlussendlich ebenfalls in ihrer Ergonomie: Wann werden potentielle Fehler überprüft und wie wird auf diese reagiert? Windows Vista macht unter anderem mit User Account Control (UCA) den Fehler, dass der Benutzer zu oft mit Warn- und Fehlermeldungen überhäuft wird. Die Folge davon ist, dass sich der Benutzer entweder genervt fühlt oder abstumpft. Oder er deaktiviert die Meldungen ganz, um sich endlich auf seine Arbeit konzentrieren zu können. Doch was nun, wenn ein Fehler vorliegt, der gemeldet werden müsste? Der Anwender wird sodann mit seinen Fehlern und den daraus resultierenden Problemen im Stich gelassen.

Doch nicht nur Fehlerquellen müssen beim Software-Design ausgemacht und mit flankierenden Massnahmen angegangen werden. Auch die Zugänglichkeit selbst, ist wichtigen Entscheidungen unterworfen. So ist es besonders wichtig, dass Menus mit logischen und damit nachvollziehbaren Strukturen definiert werden. Oder dass Felder in Eingabemasken eine aufbauende Reihenfolge aufweisen (ebenfalls in Bezug auf die Tabstop-Reihenfolge). Die Applikationslogik sollte damit massgeblich an das Denkmuster des Benutzers geknüpft werden (und nicht in erster Linie an das Denkmuster des Entwicklers).

Nicht selten denke ich bei der Nutzung diverser Software-Lösungen, dass die Entwickler doch lieber ein paar Stunden mehr in das Design und die Implementierung der Software-Ergonomie investiert hätten. Denn je länger ich mit einer Anwendung verbringe, desto wichtiger wird es für mich, dass sie mir das wohlige Gefühl intiuitiver und behüteter Benutzung gibt. Leider sind nicht alle Applikationen in der Lage, dieses in erster Linie emotionale Gefühl vermitteln zu können. In dieser Hinsicht hatte Apple mit Aqua auf MacOS X eine wichtige Vorreiterrole eingenommen. Doch auch da kann (je länger je mehr) nicht immer auf ganzer Linie überzeugt werden.