Als Hexenküchen sehen viele DV-Anwender immer noch die Softwareschmieden an. So weit gefehlt scheint dieses Bild nicht zu sein, denn häufig wird gerade Innerhalb dieser Branche ein Produkt geliefert, von dem selbst die Hersteller die Ingredienzen nicht kennen. Den Vergleich mit der Kochkunst wagt Dr. Jan Witt von der PCS Periphere Computer Systeme GmbH aus München, der auf bissig-ironische Weise die Verdaulichkeit der Software sprich: ihre Ergonomie - aufs Korn nimmt.
Es gibt zwei grundsätzlich verschiedene Auffassungen zur Kochkunst: Diejenige, die den Erfolg ausschließlich dort gelten läßt, wo das fertige Produkt auf den Tisch kommt. So etwa die französische Küche, bei der der Gast normalerweise nichts in der Küche verloren hat.
Zum anderen die griechische oder auch chinesische Küche, bei der sich der Gast hinter dem Herd von der Qualität der verwendeten Substanzen und von der Art der Zubereitung überzeugen lassen darf und hier auch anhand des Gebotenen seine persönliche Wahl treffen kann.
In der Unterhaltungsliteratur wird vielfach erfolgreich die Idee ausgeschlachtet, wie es dem ahnungslosen Gast zumute sein würde, wenn er sähe, wie es in der Küche zugeht.
Die Analogie mit Software liegt auf der Hand:
Der Koch steht für den Softwareentwickler, der Gast ist der Endbenutzer, dem je nach Qualität der Speise der Appetit wächst oder vergeht.
Wenn man das Bild noch ein wenig weiter strapaziert, kann man auch für den Fall, daß der Koch eine Dose aufgemacht hat, die Analogie finden, bei der ein fertiges Softwarepaket verwendet wurde.
Der Doseninhalt läßt sich üblicherweise nur in sehr engen Grenzen verfeinern. Andererseits bekommt auch mancher Bauchweh, wenn ihm ein Softwareprodukt frisch aus dem Ofen auf den Tisch serviert wird. Hier endet nun allerdings auch wieder die Analogie, denn die Kochkunst ist, bei all ihrer Köstlichkeit, eben doch nur ein Kunsthandwerk, das heißt, der normale Gast wünscht ein Kalbsfilet in Sahnesauce so zu essen, wie er es gewohnt ist, und goutiert nur bedingt, wenn er pausenlos mit noch nie dagewesenen Kreationen überrascht wird.
Für den Softwareentwickler auf der anderen Seite ist wesentliche Voraussetzung seines Tuns, daß es das, was er verfertigt, in dieser speziellen Form bisher noch nicht gab, das heißt, er löst in gewissem Umfang immer wieder neue Aufgaben.
Der Neuigkeitsgrad mag zwischen höchster Originalität bei der erstmaligen Lösung bisher DV-technisch noch nie gelöster Probleme (Pionier-Situationen) und bei minimaler Originalität bei der Bearbeitung eines sogenannten Routineproblems schwanken, er ist ein wichtiger Faktor im Gesamtkalkül.
Hieraus resultiert nun eine grundsätzliche Schwierigkeit in der Lieferanten-Kunden-Beziehung: Keiner kann im voraus exakt sagen, wie das Essen eigentlich schmecken sollte. Darüber, wie es ausschaut und was es kosten darf, kann man sich verhältnismäßig leicht einigen. Aber über Geschmäcker läßt sich bekanntlich streiten. Was, üblicherweise als Softwareergonomie bezeichnet wird, hat sehr viel mit Geschmack zu tun.
Man kann auch, um sich dem englischen Sprachgebrauch anzuschließen, tagelang darüber debattieren, was wohl kontraintuitiv und was wohl kontrahabituell sei, das heißt was offenkundig der Intuition zuwiderlaufe und was lediglich der bisherigen Gewohnheit entgegenstehe.
Es gibt sehr wohl gewisse Maßstäbe dafür, was ergonomisch gute Software ist. Ergonomisch gute Produkte sind Programme, deren richtigen Gebrauch man rasch erlernen kann und für deren geläufige Anwendung man nur geringen Aufwand an Gedächtnisleistung benötigt.
Die Akzeptanzforscher - sprechen hier von minimaler kognitiver Last, die dem Besucher zugemutet wird. Qualitativ gehört hierher auch das .Prinzip der geringsten Verwunderung" (principle of least astonishment), das besagt, daß auch für den unerfahrenen Benutzer beim Gebrauch der Software recht selten der, Fall eintreten sollte, daß er über die Systemreaktionen als Antwort auf eine seiner Maßnahmen erstaunt ist.
Wie kann eine leichte Erlernbarkeit des Systems gewährleistet werden? Am einfachsten dadurch, daß der Softwareentwickler sich gewisse Prinzipien und Mechanismen fest vorgibt und in seinem ganzen Entwurfsprozeß nicht davon abweicht.
Solche Prinzipien können am leichtesten in der Weise gewonnen werden, daß man sich auf gewisse grundlegende Modellkonzepte, sogenannte Paradigmen oder Lehrbeispiele konzentriert.
So wie in einer natürlichen Sprache etwa alle "regelmäßigen" Verben nach dem gleichen Schema gebeugt werden können, so daß es genügt, ein Beispiel zu lernen, um eine ganze "Äquivalenzklasse" von Fällen behandeln zu können, ist es wünschenswert, sich mit solchen Grundprinzipien in einer Vielzahl von Fällen zurechtfinden zu können.
Die gewählten Paradigmen müssen für den Objektbereich der Anwendungsproblematik passen.
Ein einfaches Beispiel: Bei einem herkömmlichen Bildschirmterminal mit 25 Zeilen zu 80 Zeichen sowie fest vorgegebenem Zeichenvorrat und einer entsprechenden linearen Zeichendarstellung auf einem ASCII-Datenträger kann man sich aussuchen, ob man für den Benutzer
- den Bildschirm als ein Zeichenfeld von 25 x 80 Zeichen betrachten möchte (Matrix- Paradigma),
- oder den Bildschirm als eine lineare Folge von Zeichen auffaßt, die jeweils dort, wo in einer Zeile das letzte sich von einem Zwischenraum unterscheidende Zeichen auftritt, durch ein Zeilenwechselsymbol unterbrochen ist (Zeilentrenner-Paradigma).
Die zweite Darstellungsform ist sehr speichersparsam und bei zeichenweise druckenden Geräten auch zeitsparend. Ihr Nachteil liegt darin, daß die Symmetrie zwischen Zeilen und Spalten verlorengeht, das heißt, daß der Bildschirminhalt, als Matrix im mathematischen Sinne aufgefaßt, nicht ohne weiteres "transponiert" ("gestürzt") werden kann.
Für den Endbenutzer ist es wichtig zu wissen, welches der beiden Paradigmen der Entwickler ausgewählt hat. Falls der Entwickler gezwungen ist, aus internen Zwecken beide Konzepte nebeneinander zu verwenden, sollte er sich nach Kräften bemühen, trotzdem für den Benutzer den Eindruck zu erwecken, daß nur ein Paradigma für die Maßnahmen des Benutzers Gültigkeit besitzt.
Betrachtet man etwa den konkreten Fall , daß ein Texteditor mit dem einen oder anderen Paradigma arbeiten soll, so sieht man sofort, daß ein Kommando "lösche Zeile" im ersten, also in dem Matrixparadigma, so aufgefaßt werden kann, daß an die Stelle der aktuellen Zeile eine Leerzeile tritt, während im zweiten Paradigma, dem Zeilentrennparadigma, das Löschen einer Zeile bedeutet, daß die restlichen Zeilen lückenlos aufgeschlossen werden.
Das konkrete Beispiel ist sicherlich sehr einfach und auch jedermann geläufig. Bei modernen Textsystemen mit Bitmapgrafik, bei denen verschiedene Schriftarten und Schriftgrößen verwendet und auch grafische Darstellungen in den Text eingelegt werden können, werden jedoch die Konzept-Entscheidungen bereits schwieriger, und es muß weitaus, mehr Sorgfalt darauf verwendet werden, die kognitive Last des Benutzers klein zu halten.
Es gibt für den Softwareentwickler zahlreiche Gründe, sich mit der Notwendigkeit von Paradigmensprüngen oder -konflikten auseinanderzusetzen.
Es können dies Effizienzüberlegungen, Anpassung an bestimmte Hardwaregegebenheiten oder auch die Notwendigkeit, bereits vorhandene Lösung mit zu verwenden, sein. Ärgerlich ist es andererseits, wenn Paradigmenkonflikte fahrlässig herbeigeführt werden.
In der Softwaretechnik hat sich als abstraktes Gliederungsprinzip über lange Zeit das sogenannte Schichtenmodell gehalten. Hierbei geht man davon aus, daß eine Basis von Grundfunktionen, sogenannte Primitive, definiert wird und dann höhere Funktionen auf diesen aufsetzen.
Ein systematischer Aufbau sehr komplexen Funktionen aus funktionell undurchlässigen Schichten, das heißt solchen, deren Unterlage von der darüberliegenden Schicht nicht mehr erreichbar ist, hat sich in der Praxis oft als nicht konsequent durchhaltbar und auch oft als sehr ineffizient erwiesen. Ein wesentlich glücklicherer und aussichtsreicherer Ansatz ist demgegenüber die heute sich deutlich weiter verbreitende sogenannte objektorientierte Programmierung, wie sie im Ansatz in der Programmiersprache Simula-67 und später vor allem in Smalltalk-80 präsentiert wurde. Die objektorientierte Programmierung erlaubt es, den verwendeten Paradigmen und auch ihren Konfliktfeldem auf der Spur zu bleiben und vor allem auch sicherzustellen, daß durch konzeptuelle Erweiterungen das Bisherige nicht in Frage gestellt wird.
An dieser SteIle zeigt sich, daß unser Gast doch gut daran tut, von Zeit zu Zeit einen Blick in die (Software-) Küche zu tun. Er kann sich dort davon überzeugen, wie gekocht wird, und darüber hinaus davon, ob die verwendeten Zutaten auch für ihn bekömmlich sind.
Wie schon erwähnt, ist es besonders wichtig, daß die Paradigmen auch in den Anwendungsbereich hineinpassen. Im Idealfall können die Zutaten, das heißt die Objekttyp- Definitionen und die für sie zulässigen Operationen, auch vom Gast selber geliefert oder zumindest begutachtet werden.
Es ergibt sich immer wieder die Notwendigkeit, zwischen der Beschaffung von Erschwinglichem und ergonomisch einigermaßen Verträglichem, das bereits existiert, und dem erträumten ergonomischen Optimum zu unterscheiden. Wie bei anderen Beschaffungsfragen spielen auch hier die drei Merkmale Preis, Bewährtheit / Verbreitung, vom Endbenutzer wahrgenommene Qualität die entscheidende Rolle.