Exkurs: Metaphern

Die Verwendung von Metaphern und die Wahl der richtigen Metapher für eine Software-Anwendung werden vielfach als eine der wichtigsten Techniken für gut nutzbare Software angesehen. Die Idee hinter dem Einsatz von Metaphern ist, mit Hilfe einer Analogie zu etwas Bekanntem Unbekanntes einfacher erschließbar und verständlich zu gestalten. Ein typisches Beispiel für eine Metapher ist der elektrische Stromfluss, bei dem eine Analogie zu Flüssigkeiten hergestellt wird. Anhand dieses Beispiels lassen sich auch die Probleme und Grenzen von Metaphern verdeutlichen. Wenn die Grundaspekte elektrischer Stromkreise verstanden sind, kann die Metapher helfen, sich einige Aspekte von Strom und Spannung zu verdeutlichen und sie sich – wie bei einer Eselsbrücke – auch besser merken zu können. Sie ist aber nicht geeignet, das noch unbekannte Phänomen Strom durch die Metapher selbst zu erschließen, denn ein Vergleich trägt immer nur bis zu einem gewissen Grad. Wenn man aber das betrachtete Phänomen noch nicht verstanden hat, gibt es keine Möglichkeit zur Differenzerfahrung, denn man kann nicht einschätzen, wie weit die Metapher trägt bzw. ob die aus der Metapher abgeleiteten Schlussfolgerungen richtig sind. Es gibt zum Beispiel bei der Metapher des Stromflusses eine Analogie zwischen Flüssigkeitsmenge und Stromstärke sowie Flüssigkeitsdruck und Spannung. Andere Aspekte wie die Viskosität oder das Verhalten bei unterschiedlichen Temperaturen lassen sich allerdings nicht übertragen. Erst wenn man sich über Differenzerfahrungen ein Phänomen erschlossen hat, lassen sich Metaphern als Abkürzung bzw. Vereinfachung oder zur Gedächtnisentlastung angemessen nutzen.

Auch die Fachsprache der Informatik ist stark mit Metaphern durchsetzt. So wird wie selbstverständlich von Netzen, Navigation oder Verschlüsselung gesprochen, ohne dass wir die metaphorischen Anspielungen auf Spinnen- und Fischernetze, Karte und Kompass oder auch auf Schlüssel und Schloss ständig im Kopf hätten. Die ursprüngliche Metapher ist zu einem Fachbegriff geworden, der nun inhaltlich durch die gemachten Differenzerfahrungen ausgefüllt und präzisiert worden ist; das Wort fungiert nur noch als Hülle. Auch in Nutzungsschnittstellen gibt es vielfältige Metaphern. Diese weisen jedoch eine Besonderheit insofern auf, als es nicht um die metaphorische Übertragung eines Konzepts geht, sondern um die Nachbildung einer nicht digitalen Technik in Bezug auf Aussehen und Funktionalität. Das bekannteste Beispiel ist die Desktop-Metapher, die von Xerox als Büro-Metapher eingeführt worden ist.

Die Analogie der Desktop-Metapher geht sehr weit. Es ist nicht nur so, dass eine Ablage von Arbeitsmaterialien auf dem Computer grundsätzlich als ähnlich zur Ablage von Dokumenten auf einem Schreibtisch beschrieben wird. Vielmehr bildet die Nutzungsschnittstelle viele Details eines Desktops und auch seiner Funktionsweise bis ins Detail ab. Die Schreibtisch-Oberfläche eines Xerox Star zeigt in Icon-Form bekannte Schreibtischutensilien wie einen Papierkorb, Ordner und Ein- und Ausgangsboxen.

Allerdings haben sich in der Folge der weiteren Entwicklung grafischer Benutzungsoberflächen eine Fülle teilweise sehr unterschiedlicher metaphorischer Umsetzungen eines Desktops herausgebildet. Dies betrifft zum einen die Art der visuellen Abbildung realweltlicher Objekte wie Drucker, Dokumente oder Behälter für Dokumente (Ordner, Verzeichnisse, Papierkörbe usw.). Zum anderen betrifft es die Frage der Funktionalität. Beispielsweise wurde die Löschfunktion in einem Fall durch einen Behälter verkörpert, aus dem man ein Dokument auch wieder – ähnlich wie bei einem Papierkorb – herausholen kann, in einem anderen Fall – wie beim TOS-Betriebssystem des Atari-ST – verkörpert das entsprechende Icon einen Shredder. In der Konsequenz, die sich nur durch Handeln mit dem jeweiligen Objekt ergibt, führt das dazu, dass sich in einem Fall der Löschvorgang wieder rückgängig machen lässt, im anderen jedoch nicht.

Schließlich wurden im weiteren Verlauf der Entwicklung viele Konzepte und Ideen der Bürometapher des Xerox Star aufgegriffen, aber in sehr unterschiedlichen Modellvorstellungen umgesetzt, die mal von einer objektorientierten Sicht geprägt waren (Dokumente als zentrale Objekte), mal von einer funktionalen Sicht (Werkzeuge bzw. Funktionen als zentrale Objekte) oder auch als Mischform angelegt wurden (die heute gebräuchlichste Form). Was aber jeweils vorliegt, lässt sich allein auf der Basis der Metapher Büro oder Schreibtischoberfläche nicht erschließen.

Die Frage ist nun, ob trotz dieser Einschränkungen Metaphern eine konstruktive Kraft innewohnt, die man im Sinne unserer Forderungen gestalterisch nutzen kann. Bei einer guten Gestaltung gemäß der Forderungen Wiedererkennbarkeit, interne Konsistenz oder auch Konformität können Metaphern eine Unterstützungswirkung entfalten, wenn zuvor verstanden worden ist, in welchem Verhältnis der metaphorische Gehalt zur tatsächlichen Implementierung steht. Sie haben also in diesem Sinne eine entlastende Funktion, eröffnen aber keine zusätzlichen Möglichkeiten für Differenzerfahrungen. Obwohl Metaphern in diesem Sinne die Nutzung von Software unterstützen können, haben sie im Hinblick auf die Gestaltung nur einen sehr begrenzten Wert. Neben der schon angesprochenen Verständnisproblematik (jede Metapher muss ähnlich wie ein Icon bezüglich seiner Bedeutung erst erlernt werden) gehen mit ihnen auch viele konstruktive Beschränkungen einher, die wir nachfolgend kurz skizzieren wollen:

Zu enge Orientierung am Analogen: Die Nachbildung der Knöpfe eines Taschenrechners, wie oben abgebildet, bezieht sich auf das Gerät, das nachgebildet wird, verkörpert aber keine gute Schnittstelle für ein Rechenprogramm am PC. Nachgebildet wird ein Gerät mit allen seinen Nachteilen, ohne dass dies der eigentlichen Aufgabe des Rechnens zuträglich wäre. Die Knöpfe entpuppen sich bestenfalls als Zierwerk, das entweder nicht genutzt wird oder dazu verleitet, Eingaben umständlich per Maus zu erledigen statt die Tastatur zu nutzen.

Auch die möglichst realistische Darstellung eines Schreibtisches, auf dem verschiedene Utensilien untergebracht sind, ist eher hinderlich als förderlich. Allein die Nachbildung fordert einen hohen Aufwand. Dem höheren Aufwand in der Erstellung ebenso wie in der Wahrnehmung der Objekte steht jedoch kein imformationeller Mehrwert für die Nutzung gegenüber. Die mit den Utensilien verbundenen Funktionen würden auch dann als Analogie zu einem klassischen Gegenstück verstanden, wenn sie einfach als Icons auftauchten. Die Desktop-Metapher wurde hier auf ihre optischen Eigenschaften reduziert. Dadurch entfiel der Hauptvorteil des Desktops, einen Raum für die Anordnung und Manipulation der Arbeitsobjekte bereitzustellen. Die Desktop-Metapher erweist sich in ihrer engen Auslegung damit eher als Hindernis in der Entwicklung weiterer ergonomischer Innovationen.

Metaphorische Diskrepanzen: Irritationen können dadurch entstehen, dass etwas, was in der Bezugswelt möglich ist, in der digitalen Entsprechung nicht funktioniert. In der Regel ist beispielsweise auf einem digitalen Desktop die Möglichkeit der Anordnung von Dokumenten und anderen Objekten im Vergleich zu echten Schreibtischen stark eingeschränkt. Weder lassen sich Stapel bilden, noch gibt es ein digitales Pendant zu einem Tacker.

Umgekehrt besteht die Gefahr, dass die starke Anlehnung an eine Metaphorik dazu führt, dass genuin digitale Funktionen nicht genutzt oder nicht verstanden werden. Es gibt keinen Grund, warum eine Datei nur an einem Ort im Dateisystem erscheinen sollte, denn das Konzept von Hardlinks, wie sie in Unix- und Linux-Systemen verbreitet sind, ist mit dieser Metapher nicht vereinbar. Mit Hilfe dieses Konzepts kann ein und dieselbe Datei an mehreren Stellen auftauchen, obwohl es sich nicht um Kopien handelt, sondern immer um dasselbe Objekt. Nutzer, die das Dateisystem nur in der Desktop-Metaphorik kennen, haben daher Schwierigkeiten, dieses Konzept zu verstehen.

Pseudo-Metaphern: Völlig vermeiden sollte man übrigens Pseudo-Metaphern. In der nachfolgenden Abbildung sind gleich zwei Metaphern dieser Art zu sehen. Die Inhalte einer Multimedia-Präsentation über Musik wurden auf ein Haus und auf das Atomium abgebildet.

Diese Art von Bildern steigert die Komplexität der Darstellung, bietet aber keinen informationellen Mehrwert. Man kann mit entsprechenden Vorerfahrungen vermuten, dass man einen Datenraum durch einen Klick auf eine Tür oder den Klick auf eine Kugel des Atomiums betreten kann. Welches jedoch die anklickbaren Objekte in der Grafik sind, ist visuell nicht ausgezeichnet; ebenso wenig lassen sich aus der räumlichen Anordnung konstruktive Schlussfolgerungen ableiten. Auch müssen sich die Entwickler die Frage gefallen lassen, warum der Lieferanteneingang in der Luft hängt und warum sich das Foyer am anderen Ende des mit einer Treppe versehenen Eingangs befindet. Solche Visualisierungen sind metaphorische Umweltverschmutzung und sollten nicht mit einem Hinweis auf die hedonistische Gestaltung (Joy of Use) von Benutzungsoberflächen legitimiert werden. Niemandem ist damit geholfen, dass eine inhaltlich begründete Zusammenstellung mit einem Büro oder einem Foyer assoziiert wird, zumal wenn die zu selektierenden Objekte optisch gleich aussehen, aber das jeweils selektierte Objekt mal für einen Datenraum und ein andermal für eine technische Kommunikationsfunktion steht. Schließlich haben das Atomium und seine Struktur überhaupt keinen Bezug zum vermittelten Inhalt Musik oder einer spezifischen Didaktik des Vermittelns.

Konstruktive Beschränkungen: Ein weiteres Problem wollen wir an einer verbalen Metapher erläutern. Beispielsweise weist das Wort Kuckuck eine lautsprachliche Analogie zum Ruf des Vogels auf. Das ist eine schöne Analogie und gut zu merken. Was ist aber, wenn wir diese Analogie als durchgängiges Konstruktionsprinzip verwenden wollten? Zuerst fällt auf, dass es uns äußerst schwerfallen dürfte, alle möglichen Vogellaute lautsprachlich umzusetzen. Intensives Training und Kehlkopfakrobatik wären unverzichtbare Voraussetzungen. Hinzu kommt, dass man bei der Nutzung von Metaphern diese nicht konstruktiv um Aspekte erweitern kann, die bislang nicht Bestandteil der Metapher waren. Beispielsweise müsste man dann auch eine Lautfolge für Gattungsbezeichnungen wie Vogel oder Singvogel ableiten können. Nicht umsonst bestehen moderne natürliche Sprachen bezüglich ihres Alphabets aus willkürlichen Zeichen, die frei zugeordnet werden können und auch bezüglich ihres Wortschatzes nur sehr schwach metaphorisch ausgeprägt sind. Hinzu kommt, dass sich ihre Bedeutung im Sprachgebrauch verändert. Das Gleiche gilt auch für Benutzungsoberflächen. Als konstruktives Gestaltungsprinzip sind User-Interface-Metaphern nicht tauglich.

Fazit: Sollte man auf Metaphern also besser verzichten? Die Antwort darauf ist aus unserer Sicht ein „Jein“. Nutzungsschnittstellen-Metaphern können durch ihre Analogie helfen, Funktionen und Objekte einer Software zuzuordnen. Hat man beispielsweise zwei Bildsymbole zur Auswahl, beispielsweise einen Drucker und eine Feder mit einem Tintenfass, und soll schlussfolgern, welches der Symbole für einen Editor steht, so wird die Wahl vermutlich auf die Feder mit dem Tintenfass fallen, weil sie stärkere Assoziationen zum Schreiben aufweist. Gesichert ist dies jedoch nicht und für verlässliche Ableitungen muss man die Objekte und Funktionen in ihrem jeweiligen Nutzungszusammenhang ohnehin zuvor erlernt haben.

Metaphern erfüllen also nicht die Erwartung, das Erlernen einer Software sparen oder substantiell abkürzen zu können. Empirische Untersuchungen haben schon vor vielen Jahren ergeben, dass Metaphern die Verständnisbildung beim Übergang von einer kommandozeilenorientierten Interaktion zu einer grafischen Benutzungsoberfläche nicht erleichtern. Überraschenderweise kamen auch versierte Nutzer nicht auf die Idee, den Papierkorb mit der Funktion Löschen in Verbindung zu bringen. Auch kann man feststellen, dass viele Bildsymbole, wenn sie ohne Kontext gezeigt werden, nicht erkannt werden. Auf der anderen Seite musste man feststellen, dass auch falsche Metaphern den Umgang mit einem System unterstützen können. Das ist plausibel, wenn man sich nochmal vor Augen führt, dass eine Schnittstellen-Metapher eine Erinnerungsstütze für Funktionen sein kann, jedoch kein Modell, aus dem Schlussfolgerungen für die Nutzung abgeleitet werden können. Bei Ersterem stören Brüche in der Metapher viel weniger, als man annehmen könnte. So sind Nutzer von Systemen mit Desktop-Oberfläche in der Regel nicht dadurch irritiert, dass der Papierkorb auf dem Schreibtisch steht oder dass Ordner in Ordner gesteckt werden können. Sobald man sich im System bewegen kann, stören solche Brüche nicht, wohl aber wenn man sich das System auf der Grundlage der Metapher erschließen will.

Deshalb ist es müßig, bei der Entwicklung eines Systems krampfhaft nach Analogien für ein Konzept oder die Funktionalität einer Software zu suchen. Die Wahrscheinlichkeit, dass eine Analogie zu mehr Verwirrung und Irritation führen, als dass sie zur Unterstützung dienen kann, ist recht hoch. Wenn es sich jedoch um eine möglichst realitätsnahe Abbildung der mit Hilfe einer Software zu erledigenden Aufgabe handelt (Aufgabenangemessenheit), können Metaphern von Vorteil sein. In diesen Fällen handelt es sich nur noch um eine punktuelle Abbildungsfunktion und nicht mehr um ein metaphorisches Modell, bei dem sich durch Übertragung aus der zugrunde gelegten Metapher Schlussfolgerungen für den Umgang mit dem System ableiten lassen. Die Tauglichkeit der Metapher muss im Rahmen des Usability Engineering abgesichert werden.