Exkurse

In diesem Abschnitt mit mehreren Exkursen stellen wir einige zusätzliche Aspekte vor, die bei der Arbeit im Ergonomie-Bereich hilfreich, aber für die Verständnisbildung nicht erforderlich sind.

Das erste Exkurskapitel beschäftigt sich mit der gesetzlichen Grundlage für die ergonomische Gestaltung von Software. Wir behandeln in diesem Kapitel auch die wichtige ISO-Norm 9241. Wir stellen die für die Software-Ergonomie relevanten Normenteile vor und werfen abschießend einen genaueren Blick auf den häufig zitierten Normteil 110, den wir mit den Erkenntnissen unseres Ansatzes im Hintergrund einordnen.

Die weiteren Exkurskapitel behandeln Ansätze, die zwar auch einen Beitrag zur ergonomischen Gestaltung leisten können, denen aber problematische Annahmen zugrunde liegen und denen deshalb aus unserer Sicht eine zu große Wichtigkeit zugestanden wird. Dazu gehören sowohl Vorstellungen zur Wichtigkeit von Metaphern und der universellen Forderung nach Konsistenz im Gestaltungsprozess ebenso wie Modellierungsvorstellungen, bei denen die Nutzungsschnittstelle des Computers mit einem Dialog zwischen Mensch und Maschine betrachtet wird.

Die kurze Einführung in das Thema Farbmodelle hat hingegen einen pragmatischen Grund. Wir stellen dort einige Alternativen zum üblichen RGB-Modell vor. Sie sollen helfen, die in den Praxiskapiteln behandelten Empfehlungen zu Farbabstufungen in Helligkeit und Sättigung umzusetzen.

Exkurs: Gesetze und Normen

Ergonomisch gestaltete Software unterstützt und entlastet nicht nur die Nutzer, sondern verbessert auch die Effizienz der Nutzung. Sie verursacht dadurch auch weniger Support-Anfragen. Ergonomische Gestaltung ist jedoch nicht nur ethisch geboten und wirtschaftlich sinnvoll, sondern auch gesetzlich vorgeschrieben. Software-Ergonomie ist Teil der Gesetzgebung im Bereich Gesundheitsschutz am Arbeitsplatz, denn unzureichend gestaltete Software kann ernsthafte physische und psychische Belastungen verursachen. Es ist die Intention des Gesetzgebers, dem vorzubeugen. Regelungen zum Gesundheitsschutz im Arbeitsumfeld finden sich in drei Bereichen der Gesetzgebung:

• Das Wettbewerbsrecht soll verhindern, dass sich einzelne Unternehmen auf Kosten der Gesundheit der Arbeitnehmer einen Vorteil verschaffen können bzw. umgekehrt, dass Unternehmen, die den Gesundheitsschutz ernst nehmen, dadurch wirtschaftlich benachteiligt werden.
• Im Rahmen der Sozialgesetzgebung geht es darum, durch Vorschriften zur Arbeitssicherheit Arbeitsunfälle und gesundheitliche Beeinträchtigungen durch Vorbeugemaßnahmen zu vermeiden und damit verbunden die Folgen zu minimieren.
• Im Betriebsverfassungsgesetz (BetrVG) bzw. in den Personalvertretungsgesetzen (BPersVG und PersVGe) der Länder sind Regelungen zur Mitbestimmung bei der Gestaltung von Arbeitsplätzen und der Umstellung von Arbeitsabläufen insbesondere in Bezug auf den Gesundheitsschutz verankert.

Eine Charakteristik gesetzlicher Regelungen zum Gesundheitsschutz war – insbesondere bei der Mitbestimmung – lange Zeit die Tatsache, dass dieser sehr defensiv als nachlaufender Schutz gehandhabt wurde. „Nachlaufend“ bedeutet, dass erst gesicherte Erkenntnisse vorliegen mussten, bevor man in einer problematischen Situation auf Abhilfe dringen konnte:

Betriebsverfassungsgesetz § 91 Mitbestimmungsrecht

Werden die Arbeitnehmer durch Änderungen der Arbeitsplätze, des Arbeitsablaufs oder der Arbeitsumgebung, die den gesicherten arbeitswissenschaftlichen Erkenntnissen über die menschengerechte Gestaltung der Arbeit offensichtlich widersprechen, in besonderer Weise belastet, so kann der Betriebsrat angemessene Maßnahmen zur Abwendung, Milderung oder zum Ausgleich der Belastung verlangen. Kommt eine Einigung nicht zustande, so entscheidet die Einigungsstelle. Der Spruch der Einigungsstelle ersetzt die Einigung zwischen Arbeitgeber und Betriebsrat.

Formulierungen wie „besonders belastend“ und „offensichtlich“ drücken die Tendenz schon aus. Doch erst in Kombination mit dem Ausdruck „gesicherte” arbeitswissenschaftliche Erkenntnisse entfalten sie vollends ihre bremsende Wirkung, denn bis eine wissenschaftliche Erkenntnis auch als gesicherte wissenschaftliche Erkenntnis betrachtet werden kann, können mitunter viele Jahre ins Land gehen. Ab wann galt es beispielsweise für Gerichte als gesichert, dass Rauchen und auch passives Rauchen die Gesundheit gefährdet? Ist man auf 100 Prozent gesicherte Erkenntnis fixiert, können auch Jahrzehnte ins Land gehen. Im schnelllebigen IT-Zeitalter wäre das ein viel zu großer Zeitraum.

Europäischer Gesundheitsschutz

Über die Integration des europäischen Wirtschaftsraums (zunächst Montan-Union, dann Europäische Wirtschaftsgemeinschaft (EWG), dann Europäische Gemeinschaft (EG) und schließlich Europäische Union (EU)) wurden Regeln, wie die oben skizzierten, europaweit zu einem vorbeugenden Gesundheitsschutz ausgebaut. Schon der Gründungsvertrag der Europäischen Wirtschaftsgemeinschaft aus dem Jahr 1975 beschreibt in seinem Artikel 117 die Verbesserung der Lebens- und Arbeitsbedingungen als ein Ziel. Im Jahre 1986 wurde der Vertrag um Artikel 118a ergänzt, um Sicherheit und Gesundheit der Arbeitnehmer zu fördern und nationale Regelungen zum Arbeitsschutz zu harmonisieren. 1989 folgte dann die Rahmenrichtlinie „Maßnahmen zur Verbesserung der Sicherheit und des Gesundheitsschutzes der Arbeitnehmer bei der Arbeit“ (89/391/EWG). Die Präambel dieser Rahmenrichtlinie führt aus:

Die Arbeitgeber sind verpflichtet, sich über den neuesten Stand der Technik und der wissenschaftlichen Erkenntnisse auf dem Gebiet der Gestaltung der Arbeitsplätze zu informieren, um etwa erforderliche Änderungen vorzunehmen und damit eine bessere Sicherheit und einen besseren Gesundheitsschutz der Arbeitnehmer gewährleisten zu können.

Im Gegensatz zu einem nachlaufenden Gesundheitsschutz ist nicht mehr von „gesicherten“ Erkenntnissen die Rede, sondern es muss der „neueste Stand“ der Technik berücksichtigt werden. Auch präventive Regelungen werden deutlich ausgebaut, damit die Ursachen für mögliche Probleme vor ihrem Auftreten behoben werden können. Arbeitgeber sind zudem verpflichtet, sich in Eigeninitiative zu informieren.

Spezifische Regelungen zu den praktischen Implikationen der Rahmenrichtlinie finden sich in einer Reihe von Einzelrichtlinien. Für uns von Belang ist die fünfte dieser Richtlinien, „Arbeiten mit Bildschirmgeräten“ (90/270/EWG), meist kurz „Bildschirmrichtlinie“ genannt. Diese Richtlinie legt Mindestvorschriften in Bezug auf die Sicherheit und den Gesundheitsschutz bei der Arbeit an Bildschirmgeräten fest. Der Begriff Bildschirmgerät ist dabei recht weit gefasst und umfasst nahezu alle interaktiven Geräte mit einem Display.

Eine europäische Richtlinie muss von den nationalen Parlamenten der Europäischen Union in das jeweilige Landesrecht umgesetzt werden. Die EU-Rahmenrichtlinie wurde in Deutschland durch die Reform des Arbeitsschutzgesetzes umgesetzt; das deutsche Pendant zur Bildschirmrichtlinie ist die Bildschirmarbeitsverordnung. Im Jahre 2016 entschloss sich der Gesetzgeber, diese Einzelverordnung abzuschaffen und die entsprechenden Regelungen stattdessen als Anhang 6 direkt in das Arbeitsschutzgesetz zu integrieren. In Bezug auf die Regelungen der Bildschirmrichtlinie haben sich keinerlei nennenswerte Änderungen ergeben.

Zur Mensch-Maschine-Schnittstelle führt die Bildschirmrichtlinie der EU folgende Mindestvorschriften auf:

Bei Konzipierung, Auswahl, Erwerb und Änderung von Software sowie bei der Gestaltung von Tätigkeiten, bei denen Bildschirmgeräte zum Einsatz kommen, hat der Arbeitgeber folgenden Faktoren Rechnung zu tragen:

• Die Software muss der auszuführenden Tätigkeit angepasst sein.
• Die Software muss benutzerfreundlich sein und gegebenenfalls dem Kenntnis- und Erfahrungsstand des Benutzers angepasst werden können.
• Die Systeme müssen den Arbeitnehmern Angaben über die jeweiligen Abläufe bieten.
• Die Systeme müssen die Information in einem Format und in einem Tempo anzeigen, das den Benutzern angepasst ist.
• Die Grundsätze der Ergonomie sind insbesondere auf die Verarbeitung von Informationen durch den Menschen anzuwenden.

Diese Aufzählung wirkt in ihrer Zusammenstellung etwas eigentümlich. Größtenteils wird auf die Anpassbarkeit von Software eingegangen, doch finden sich auch sehr allgemeine Hinweise in Bezug auf Anzeigeformate und Anzeigetempo. Interessant für uns ist vor allem der letzte Punkt, der auf die „Grundsätze der Ergonomie“ verweist. Solche Grundsätze sind u. a. in der ISO-Norm 9241 „Ergonomie der Mensch-System-Interaktion“ niedergelegt. Wir werden sie weiter unten genauer betrachten.

Zwei neue Qualitäten

Die EU-Bildschirmrichtlinie bringt zwei neue Qualitäten mit sich, die in den bis dahin geltenden nationalen Regelungen keine Rolle gespielt haben.

1. Vorbeugender Gesundheitsschutz

Der vorbeugende Gesundheitsschutz umfasst entsprechend der Verordnung eine Reihe von Punkten:

• Orientierung am neuesten Stand der Erkenntnisse: Eine potenzielle Gefahr muss nicht erst nachgewiesen sein, um vermieden zu werden. Zur Vorbeugung gehört es daher auch, Maßnahmen zu treffen, wenn es nur hinreichende Anzeichen für Gefahren gibt.
• Umfassende Aufklärungspflicht: Gesundheitsschutz darf keine Geheimsache des Arbeitgebers sein. Die Arbeitnehmer müssen daher über die Maßnahmen zum Gesundheitsschutz und die Gefahren am Arbeitsplatz aufgeklärt werden.
• Verbesserte Mitbestimmungsmöglichkeiten: Neben den Pflichten zur Unterrichtung und Unterweisung der Arbeitnehmer sind auch entsprechende Mitwirkungsregelungen festgelegt worden.
• Präventivmaßnahmen: Um vorbeugend schützen zu können, ist grundsätzlich die Untersuchung des Arbeitsplatzes auf mögliche Gefahren erforderlich. Dies ist bei gravierenden Änderungen zu wiederholen. Erkannte Gefahren müssen entsprechend beseitigt werden. Weitere Präventivmaßnahmen sind das Angebot betriebsärztlicher Untersuchungen. Beispielsweise besteht ein Anspruch der Arbeitnehmer auf regelmäßige Augenuntersuchungen.
• Kontinuierliche Zyklen: Wichtiger Bestandteil des präventiven Gesundheitsschutzes ist sein zyklischer Charakter. Es reicht nicht, einen Arbeitsplatz einmal für gut zu befinden und dann nie wieder zu betrachten. Analyse (Finden von Problemen), Bewertung (Bestimmen von Verbesserungsmöglichkeiten), Dokumentation und Umsetzung müssen regelmäßig wiederholt durchgeführt werden.

2. Vermeidung psychischer Belastungen

Die zweite wichtige neue Qualität des europäischen Gesundheitsschutzes ist die Anerkennung psychischer Belastungen. Vorherige Regelungen ließen diesen Aspekt außer Acht und beschränkten Gesundheit auf physische Unversehrtheit. Psychische Belastungen können mannigfaltig sein. Die Norm DIN EN ISO 10075-1 definiert psychische Belastungen als die von außen auf die Psyche einwirkenden Faktoren. Diese ergeben sich aus den Arbeitsbedingungen, beispielsweise:

• der Arbeitsaufgabe (Art und Umfang der Tätigkeit),
• der Arbeitsumgebung (zum Beispiel Lärm, Blendungen),
• der Arbeitsorganisation (zum Beispiel Arbeitszeit, Arbeitsabläufe) und
• den sozialen Komponenten (zum Beispiel Führungsstil, Betriebsklima).

Arbeitsaufgaben, Klima oder auch soziale Komponenten liegen außerhalb der Software-Ergonomie. Die Gestaltung von Software hat jedoch einen großen Einfluss auf die Arbeitsumgebung und die Arbeitsorganisation. Schlechte Gestaltung kann zu einer psychischen Belastung werden. Die Nutzer sind unzufrieden, gestresst oder entwickeln sogar körperliche Symptome.

Ein Blick auf die DIN-EN-ISO 9241

Durch die Referenzierung in Gesetzen und Verordnungen kommt der ISO-Norm 9241 „Ergonomie der Mensch-System-Interaktion“ eine besondere Rolle zu. Besonders die Teile 110 „Interaktionsprinzipien“ und 112 „Grundsätze der Informationsdarstellung“ werden häufig betrachtet, da sie sehr allgemeine Grundsätze und Prinzipien enthalten. Andere Normenteile beziehen sich konkreter auf spezielle Interaktionstechniken. Gerade an diesen Stellen gehen die Vorgaben der Norm oft über das hinaus, was wir in diesem Buch etwa zu Menüs oder Formularen zu sagen haben.

Insgesamt macht es doch wenig Sinn, die ISO-Norm 9241 mit diesem Lehrbuch zu vergleichen, denn das Ziel der Norm ist ebenso wenig das Schaffen eines zusammenhängenden, operationalisierbaren Wissens über Nutzungsschnittstellengestaltung, wie es das Ziel dieses Buchs ist, alle Bereiche der Nutzungsschnittstellengestaltung abzudecken und mit Regeln zu belegen.

Die ISO-Norm 9241, in der deutschen Fassung in ganzer Länge DIN EN ISO 9241, war nicht immer derart umfangreich. Sie hatte zunächst den Titel „Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten“ und bestand aus 17 Teilen. Die ältesten Teile der aktuell geltenden Norm stammen aus dem Jahr 1993. Jeder Teil der Norm wird alle fünf Jahre überprüft und falls notwendig aktualisiert, was dann wiederum ca. fünf Jahre dauert. Im Rahmen dieser Aktualisierung wurde der Geltungsbereich der Norm im Jahre 2006 erheblich erweitert, was sich auch im neuen Titel „Ergonomie der Mensch-System-Interaktion“ widerspiegelt. Die Norm beschränkt sich also nicht mehr auf den klassischen Computereinsatz im Büro, sondern umfasst auch Bereiche der privaten Nutzung und neue Ein- und Ausgabetechniken wie zum Beispiel VR-Brillen.

Die einzelnen Normenteile haben sehr unterschiedlichen Charakter. Einige beziehen sich sehr konkret auf die technische Gestaltung, andere geben einen sehr allgemeinen Rahmen vor. Hier ein paar interessante Normenteile in Kürze:

Teil 125 (Informationsdarstellung) ist einer der längsten Teile der Norm. In ihm werden viele der Techniken angesprochen, die wir unter Präsentation besprochen haben, allerdings ohne sie von einer theoretisch-konzeptuellen Grundlage abzuleiten. An vielen Stellen ist dieser Teil der Norm ausführlicher und fasst bereits bekannte Designspezifika zusammen. Es sind zum Beispiel umfangreiche Hinweise zur Formatierung von Zahlen in Tabellen enthalten.

Die Teile 14 und 143 geben konkrete Gestaltungshinweise zu den Themen Menüs und Formulare. Ein Blick in diese Normenteile lohnt sich, denn die Ausführungen und Tipps gehen über den Rahmen Ausführungen in diesem Buch hinaus.

Von deutlich anderem Charakter als die vorgenannten Teilnormen ist Teil 161 der ISO 9241. Hier werden Nutzungsschnittstellen nicht in verschiedene „Dialogtechniken“ eingeteilt, sondern dieser Normenteil beschreibt im Detail die Elemente aktueller, WIMP-basierter Nutzungsschnittstellen.

Die Teile 300 und 303 der Norm beschreiben viele ergonomische Anforderungen an Bildschirmdarstellungen. Die meisten dieser Anforderungen, etwa die über Bildwiederholfrequenzen, sind für uns als Softwareentwickler weniger interessant. Ausnahmen sind Hinweise zu Zeichengrößen und zu Bildauflösungen. Die für uns wichtigen Aspekte haben wir ebenfalls im Bereich Präsentation behandelt.

Die „Interaktionsprinzipien“

Teil 110 der ISO 9241 ist der am häufigsten referenzierte Teil im Bereich der Software-Ergonomie. Er beschreibt sieben recht allgemeine Prinzipien, die ein Software-System erfüllen muss. Für jeden der Grundsätze werden grundlegende Anforderungen definiert, die dann mit Beispielen erläutert werden. Entstanden sind diese Grundsätze bereits in den 1980er Jahren in der Bundesrepublik auf der Grundlage empirischer Befragungen, in denen in einer großen Sammelaktion „Beschwerden“ über Probleme im Umgang mit Software erhoben worden sind. Auf der Grundlage dieser Sammlung wurden mit Hilfe der Faktorenanalyse Cluster gebildet, in denen nur Probleme enthalten sind, die unabhängig von den jeweils anderen aufgetreten waren. Für diese Cluster wurden möglichst inhaltsneutrale Bezeichnungen gewählt. Die fünf statistisch so ermittelten Cluster bildeten die „Grundsätze ergonomischer Dialoggestaltung“ in der ersten Norm (damals noch DIN 66235, Teil 8). Mit der Weiterentwicklung und Internationalisierung des Normenwerks zur ISO 9241 wurden später im entsprechenden Teil 110 zwei weitere Grundsätze hinzugefügt. Die neueste Überarbeitung der Norm stammt aus dem Jahre 2020. Aus den „Grundsätzen der Dialoggestaltung“ wurden nun „Interaktionsprinzipien“. Innerhalb der Prinzipien wurde ein bisschen umgeräumt, um Platz für das neue Prinzip „Benutzerbindung“ zu schaffen. Die sieben Prinzipien lauten nach aktuellem Stand Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Erlernbarkeit, Steuerbarkeit, Robustheit gegen Benutzungsfehler und Benutzerbindung.

Betrachtet man die „Interaktionsprinzipien“ (Teil 110) und nimmt noch die „Grundsätze der Informationsdarstellung“ (Teil 112) mit hinzu, finden sich sehr viele Hinweise und Beispiele, die auch in diesem Lehrbuch zur Ergonomie vorkommen. Aus der Struktur der Norm für sich lassen sich keine gestaltungsleitenden Konsequenzen für den Aufbau eines Lehrbuchs ableiten. Wir wollen dies am Beispiel „Robustheit gegen Benutzungsfehler“ illustrieren, denn an diesem Grundsatz lässt sich der empirisch begründete Sammlungscharakter dieses Normteils gut verdeutlichen.

Unter Robustheit gegen Benutzungsfehler sind all die Aspekte eingeordnet, bei denen es um Fehler und den Umgang mit ihnen geht. Benutzungsfehler definiert die Norm als „Benutzerhandlung oder Unterlassung einer Handlung während der Nutzung eines Systems, eines Produkts oder einer Dienstleistung, die zu einem anderen Ergebnis führt, als vom Hersteller angestrebt oder vom Benutzer erwartet“. Diese Definition ist sehr breit, wie die nachfolgenden Beispiele zeigen, die in der Norm zur „Robustheit gegen Benutzungsfehler“ angeführt sind:

Ein Online-Formular informiert im oberen Formularbereich darüber, dass das Formular nicht korrekte Einträge enthält. Außerdem wird jedes Feld mit einer nicht korrekten Eingabe markiert.

In einer Rechtschreibprüfung werden fehlerhafte Wörter markiert. Die Rechtschreibprüfung bietet die Auswahl einer oder mehrerer Versionen des falsch geschriebenen Wortes, wobei der Benutzer die Möglichkeit hat, eine andere korrigierte Version des Wortes einzugeben oder die Schreibweise des Wortes zu akzeptieren, auch wenn die Rechtschreibprüfung dieses nicht erkennt.

Ein Reservierungssystem mit Meldungsausgabe liefert eindeutige Meldungen wie „Der von Ihnen gewählte Zug steht am 25. Dezember bei dieser Verbindung nicht zur Verfügung. Verfügbar ist er am 23. Dezember sowie am 26. Dezember. Bitte wählen Sie einen anderen Zug, ein anderes Datum oder eine andere Verbindung“.

Zwar geht es in allen drei Beispielen um Fehler, doch liegen diese auf ganz verschiedenen Ebenen. Im ersten Fall geht es um eine fehlerhafte Eingabe in dem Sinne, dass sie bei der Modellierung des Systems nicht vorgesehen wurden und somit eine weitere Verarbeitung nicht möglich ist. Das ist im Fall der Rechtschreibprüfung ganz anders. Wird in einem Text „nähmlich“ mit einem „h“ rot unterschlängelt, haben wir keinen Interaktionsfehler im Sinne einer nicht verarbeitbaren Eingabe. Das h ließe sich ohne Probleme eingeben und könnte so auch im Text verbleiben, ohne dass es im weiteren Ablauf zu Nutzungsproblemen käme. Ein Fehler ist diese Rechtschreibanomalie nur auf der Aufgabenebene. Im letzten Fall schlussendlich ist die Eingabe eigentlich überhaupt nicht falsch. Es handelt sich weder um eine nicht verarbeitbare und in diesem Sinne falsche Eingabe, noch ist es von der Aufgabenstellung her falsch, am ersten Weihnachtsfeiertag mit dem Zug fahren zu wollen. Der Fehler liegt darin, dass das, was da jemand will, nicht erfüllbar ist. Gestalterisch haben diese drei Fehlerarten nichts miteinander zu tun.

Nehmen wir noch ein anderes Beispiel, um das Problem zu verdeutlichen: Unsere Aufgabe soll es sein, mit Hilfe eines Grafikprogramms die abgebildete Grafik in eine französische Flagge zu verwandeln, also die Flächen entsprechend mit den Grafikwerkzeugen farblich zu füllen. Bei dieser Aufgabe können mehrere Fehler passieren. Dazu einige Beispiele:

1. Wir haben das Füllwerkzeug gewählt, es wurde jedoch keine Farbe ausgesucht, mit der gefüllt werden soll. Wenn wir in einen der Bereiche klicken, um ihn einzufärben, zeigt die Software eine Fehlermeldung.
2. Wir haben die Farbe Blau ausgewählt, sind bei der Positionierung des Mauszeigers jedoch unpräzise und färben den mittleren Streifen blau.
3. Wir haben die französische mit der italienischen Flagge verwechselt und daher mit großer Begeisterung eine grüne Farbe ausgesucht und den linken Streifen grün gefärbt.

In allen drei Fällen ist ein Fehler passiert und man kann diese Fehler auch durchaus „Benutzungsfehler“ nennen. Diese Fehler sind jedoch sehr unterschiedlicher Art. Im ersten Fall haben wir das Programm im Sinne des Interaktionsmodells falsch bedient, sodass die Funktion nicht ausgeführt werden konnte. Im zweiten Fall war das zugrundeliegende Modell korrekt, doch die Ausführung unsererseits fehlerhaft. Im dritten Fall ist die Interaktion fehlerfrei abgelaufen. Das Ergebnis ist aber inhaltlich falsch. Nun kann man all dieses unter „Benutzungsfehler“ einsortieren und sich überlegen, wie man das Problem gestalterisch so lösen kann, dass diese Fehler nicht mehr auftreten oder sich ihr Auftreten deutlich verringert. Doch weder lassen sich übergreifende gemeinsame Begründungszusammenhänge formulieren, noch ist es möglich, einheitliche Gestaltungshinweise zu formulieren, die in all diesen Fehlerklassen gleichermaßen wirken.

Quintessenz

Unser Ergonomieansatz mit der Leitforderung nach der Reduzierung erzwungener Seqzenzialität, mit den in Designkonflikten verwobenen Einzelforderungen und mit unserem starken Fokus auf eine robuste Gestaltung lässt sich nicht durch eine Auseinandersetzung mit der Norm ersetzen. Umgekehrt kann dieses Lehrbuch den Umfang und die Vielseitigkeit der über Jahre gewachsenen Norm, die fast alle nur erdenklichen Aspekte der Nutzungsschnittstellengestaltung behandelt, nicht abdecken. Beide ergänzen sich in diesem Sinne wechselseitig; ein Blick gerade in die spezielleren Normenteile lohnt sich daher grundsätzlich.

Wenn Sie unseren Ansatz mit seinen Forderungen und Beispielen betrachten und sich die Prinzipien und Grundsätze aus den Normenteilen 110 und 112 anschauen, werden sie Vieles wiedererkennen. Sie können sich jeweils überlegen, ob, wo und wie das jeweilige Beispiel und das jeweilige Ziel in unser Schema passen. Vermutlich eröffnet sich dabei noch der eine oder andere zusätzliche Aspekt. Wenn Sie unseren Ansatz beherzigen und danach gestalten, werden Sie auch nach ISO 9241-110 und 112 gut gestalten. Umgekehrt wäre es weitaus schwieriger, denn die Norm fordert nur. Sie erklärt nicht, sie konstruiert keine Zusammenhänge und sie hilft nicht, konkurrierende Anforderungen abzuwägen. Nehmen Sie die Norm daher nicht als Alternative, sondern als willkommene Ergänzung für eine ergonomischere Gestaltung von Nutzungsschnittstellen.

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.

Exkurs: Konsistenz

Konsistenz wird oft als eine der wichtigsten Techniken zur Gestaltung gut nutzbarer Software angesehen. Ben Shneiderman beschreibt etwa in seinen Goldenen Regeln das Streben nach Konsistenz gleich als Erstes:

Strive for consistency. Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens and consistent color, layout, capitalization, fonts and so on should be employed throughout. ¹

Das klingt plausibel und einfach umsetzbar, doch leider ist es das nicht, denn je tiefer man in das Problem einsteigt, desto vertrackter wird es. Eine zentrale Schwierigkeit ist, dass man immer angeben muss, zu was etwas gleich oder konsistent ist („similar“). So sieht auch Shneiderman die Notwendigkeit für Ausnahmen, fordert jedoch: „Exceptions, such as required confirmation of the delete command or no echoing of passwords, should be comprehensible and limited in number.“ Tatsächlich zeigt sich, wenn man es genau betrachtet, dass Probleme oder Abweichungen von einfachen Konsistenzregeln eher die Regel als die Ausnahme („exception“) sind. Und sie sind auch sinnvoll.

Beispiel: Drag and Drop

Nehmen Sie als Beispiel Drag and Drop und, um es einfach zu halten, das räumliche Verschieben eines Datei-Icons von einem Ort auf dem Bildschirm zu einem anderen. Soll dieses Drag and Drop immer die gleiche Funktion auslösen, etwa das Verschieben der Datei an den Zielort? Das wäre konsistent, aber ist es auch erstrebenswert?

Schon bei der Entwicklung der frühen, auf der Desktop-Metapher basierenden Systeme fiel auf, dass dies zu unpraktischen Operationen führen würde. Bei der Verwendung eines zusätzlichen internen oder externen Speichermediums – also damals eine Diskette und heute zum Beispiel ein USB-Stick – will man in den meisten Fällen Dateien zwischen den Medien kopieren und nicht verschieben. Zieht man hingegen eine Datei von einem Ordner zu einem anderen Ordner auf demselben Speichermedium, ist das Verschieben die wahrscheinlichere Operation. Folglich wurde die Regel für das Drag and Drop komplexer gestaltet. Bei Drag and Drop innerhalb eines Datenträgers werden Verschiebe-Operationen ausgelöst, beim Drag and Drop zwischen Datenträgern hingegen wird ein Objekt kopiert.

Bei diesem Vorgehen wurde der Gestaltungskonflikt zwischen der Forderung nach Konsistenz und der nach Aufgabenangemessenheit zu Lasten der Konsistenz aufgelöst. Die gleiche Operation, das Verschieben eines Objekts von einem Fenster in ein anderes, hat nun also verschiedene Folgen je nach Kontext, in dem diese Operation stattfindet.

Man kann solche Konflikte austarieren, indem man Regeln einführt und die Konsistenz von Nebenbedingungen abhängig macht. Doch das hat auch Nachteile. Im Drag-and-Drop-Beispiel wird es schwierig, wenn man sich der unterschiedlichen Datenträger nicht bewusst oder der Unterschied faktisch ohne Bedeutung ist. Das kann beispielsweise der Fall sein, wenn es sich um zwei interne Speichermedien handelt oder um zwei Partitionen auf ein und demselben Medium. Man nimmt die Trennung dann oft nicht wahr. Liegt zum Beispiel der Desktop auf Laufwerk C und die Dateiablage auf Laufwerk D, ist die intendierte Operation meist nicht das Erstellen einer Kopie, sondern das Verschieben in eine Ablage. Konsistenz hilft aber in diesen Fragen nicht weiter. Es handelt sich schlichtweg um ein Modusproblem (siehe Kapitel Modusgestaltung), da die Reaktion des Systems (kopieren oder verschieben) vom Systemzustand abhängt, d. h. auf welchem Medium die Objekte gespeichert sind. Dieser Systemzustand ist bei der Nutzung aber nicht wahrnehmbar.

Beispiel: Scrollrichtung

Konsistenz, so wie von Shneiderman definiert, verlangt, dass in vergleichbaren Situationen auch vergleichbare Operationen durchgeführt werden sollten. Betrachten wir das beim Scrolling von Inhalten in Fenstern mittels Touch auf dem Bildschirm, mittels Geste auf einem Trackpad oder mittels Mausrad.

Hier findet sich eine vermeintliche Inkonsistenz. Bei Microsoft Windows und bis 2011 auch beim MacOS zeigte sich folgendes Verhalten: Scrollte man mit dem Mausrad oder mittels Trackpad nach oben, bewegte sich der im Fenster dargestellte Inhalt nach unten, drehte man das Rad nach unten, bewegte sich der Inhalt nach oben. Auf Tablets oder auch auf PCs mit Touch-Bedienung ist ein Scrollen durch direktes Berühren des Bildschirms möglich. Bei dieser Konstellation verhält es sich auf allen Betriebssystemen so, dass bei einer Bewegung nach oben der Inhalt sich nach oben und bei einer Bewegung nach unten dementsprechend sich nach unten bewegt.

Mit OS X Lion passte Apple die Scrollrichtung an und nannte dieses Verhalten euphemistisch „Natural Scrolling“. In einem Blog-Eintrag aus der Zeit liest man hierzu:

Aside from all the cool new features that Lion offers, the one that immediately stood out to me was a switch to natural scrolling. For the longest time, both Macs and PCs have used reverse scrolling.

An example of natural scrolling is the Apple iPad. When you want to scroll up a web page, you put a finger on the iPad and move up. When you want to scroll down, you move your fingers down. This is, of course, very natural and logical.

This process is reserved when using a mouse wheel or trackpad. To make a webpage scroll down, you have to push up on the mouse wheel or trackpad. To make a webpage scroll up, you push down. This doesn’t sound logical or natural but it’s been this way for so long that we think it is.“²

Diese Beschreibung der einen Option als „natural“ und damit der anderen als unnatürlich ist nicht haltbar! Das eine ist nicht natürlicher als das andere. Ebenso ist die Scrollrichtung von Windows (genauso wie die frühere Apple-Variante) keinesfalls „reversed“. Entscheidend ist vielmehr, welches Objekt mit der Scrolloperation bewegt wird: der Inhalt oder das Fenster. Die Windows-Logik ist, dass beim Scrollen mit dem Scrollrad der Ausschnitt bewegt wird. Man bewegt quasi das Fenster auf dem Inhalt hinauf und hinunter. Das ist auch genau die Information, die eine Scrollbar anzeigt. Man kann das Ganze also auch so interpretieren, dass man die Scrollbar rauf- oder runterbewegt. Beim Mac hingegen bewegt man den Inhalt selbst rauf oder runter.

Anders gesagt: Die vermeintlich nicht natürliche Variante kann durchaus als die konsistentere angesehen werden, denn in diesem Fall entspricht die Bewegung des Mausrads der der Scrollbar. Beim vermeintlich konsistenten „Natural Scrolling“ von Apple hingegen gibt es diese Kopplung nicht mehr. Dafür entspricht die Bewegung des Mausrads nun der des Inhalts. Beide Varianten sind gleichermaßen sowohl konsistent als auch inkonsistent.

Konsistenz mit der Außenwelt?

Der Anspruch an Konsistenz wird auch oft als Konsistenz mit Gegebenheiten außerhalb des Computers interpretiert. Ähnlich wie bei den Metaphern geht es um das Nachahmen von etwas bereits Bekanntem. Die Dinge sollen sich am Computer so verhalten wie in der „wirklichen Welt“. Die entscheidende Frage ist jedoch immer, zu was man konsistent sein will.

Unten zu sehen ist der Windows-Taschenrechner in zwei verschiedenen Einstellungen. In beiden Fällen wurde `5+5*3=´ eingetippt. Es gibt offenbar eine Inkonsistenz, denn die gleiche Eingabe führt nicht zum gleichen Ergebnis. Andererseits ist dieses Verhalten konsistent zu verschiedenartigen Taschenrechnern. Einfache, nicht wissenschaftliche Taschenrechner kannten früher oft keine Punkt-vor-Strich-Rechnung, wissenschaftliche hingegen schon.

Ein anderes Beispiel für die Konsistenz zu Konzepten außerhalb des Computers ist “Abwedeln” und “Nachbelichten” bei digitalen Bildverarbeitungsprogrammen. Diese Funktionen dienen der lokalen Helligkeitsanpassung in einem Foto. Abwedeln und Nachbelichten sind Techniken der analogen Fotobelichtung in der Dunkelkammer: Abwedeln bedeutet dort, dass während der Belichtung eines Fotopapiers mit einem Gegenstand im Lichtweg hin und her gewedelt wird, um die Belichtung des Fotopapiers im Bereich zu verringern und damit ein lokal helleres Bild zu erhalten. Nachbelichten ist das Gegenstück, es bedeutet zusätzliche Belichtung des Fotopapiers, um entsprechend ein dunkleres Bild zu erzielen. Für denjenigen, der den analogen Prozess kennt, sind die beiden Begriffe (und ihre dazugehörigen Icons) wahrscheinlich verständlich. Für die wohl mittlerweile größere Zahl derer, die nie in einer klassischen Dunkelkammer waren, sind die Begriffe unverständlich. Wieso sollte es beim Nachbelichten, also bei mehr Licht, dunkler werden? In diesem Fall kann man auf die Metaphorik einfach verzichten, denn die technisch neutralen Begriffe „Abdunkeln“ oder „Aufhellen“ sind für beide Nutzergruppen gleichermaßen verständlich.

Fazit

Was kann man aus dieser kurzen, eher anekdotischen Betrachtung von Konsistenz als Gestaltungsmittel lernen? Zunächst einmal, dass die hohen Erwartungen, die mit dieser Forderung verbunden werden, letztlich nicht gerechtfertigt sind. Konsistenz an sich ist als Gestaltungsleitlinie eher kritisch zu sehen, denn die Auflösung von widersprüchlichen Konsistenzanforderungen und die Entscheidung für passende Design-Systematiken zur konsistenten Gestaltung sind in der Regel aufgabenabhängig.

Auf der anderen Seite steht jedoch eine Fülle von Beispielen dafür, dass eine gleichartige Gestaltung gleichartiger Objekte oder Funktionen durchaus hilfreich ist. Dies lässt sich auch gut mit unserem Konzept der Differenzerfahrung verdeutlichen, denn wir gehen davon aus, dass ein Unterschied im Wahrnehmungsfeld zur Information wird, indem er bewusst wahrgenommen wird. Als Gestalter haben wir keine Sicherheit, dass dies während der Nutzung durchgängig passiert. Umgekehrt können wir feststellen, dass jeder wahrgenommene Unterschied hinsichtlich seiner möglichen Bedeutung auch interpretiert wird. Wenn der wahrgenommene Unterschied aber keinen informationellen Mehrwert bietet, weil er sich aus Nachlässigkeit oder Unbedachtheit wie eine Zeitungsente eingeschlichen hat, verkörpert die kognitive Leistung des Interpretierens nichts anderes als erzwungene Sequenzialität, die weitestgehend reduziert werden sollte. Bei einer stufenweisen Entwicklung eines Systems kann man das berücksichtigen, indem man der Maxime folgt, ohne begründbaren Anlass keine Unterschiede zur bislang erfolgten Gestaltung einzuführen, denn diese verkörpern automatisch Inkonsistenzen.

Exkurs: Mensch-Computer-Dialog

Obwohl die Idee, einen Computer mit Hilfe eines Dialogs zu steuern, technisch sehr aufwändig ist, wurde sie schon mit dem Aufkommen der Time-Sharing-Systeme in den 1960er Jahren propagiert. Später kamen Ideen eines computerisierten persönlichen Assistenten auf. Ein Video von Apple von 1987 etwa zeigt die Vision eines Knowledge Navigators, mit dessen Hilfe zum Beispiel eine wissenschaftliche Recherche durchgeführt werden kann und der gleich noch die Rolle der Telefonvermittlung übernimmt. Von solchen Szenarien sind wir nicht mehr weit entfernt. Dank KI-Sprachmodellen können wir uns mit einem Computer über wissenschaftliche Themen oder Kochrezepte unterhalten, fotorealistische Bilder erzeugen oder in Office-Software Folien automatisch generieren und per Text- oder Spracheingabe umformulieren lassen. Werden wir also bald alles durch ein Gespräch mit dem Computer erledigen? Hat die klassische Nutzungsschnittstelle ausgedient? Wenn das so wäre, dann wäre ja fast alles, was Sie in diesem Buch gelesen haben, bald obsolet. Lassen Sie uns deshalb ein paar Gedankenexperimente anstellen.

Wir stellen uns ein Computer-Assistenz-System vor, das perfekt funktioniert, also die gesprochene Sprache richtig erkennt und auch korrekt antworten und reagieren kann. In diesem angenommenen System gehen wir davon aus, dass es außer der Ein- und Ausgabe von Sprache keine andere Nutzungsschnittstelle gibt. Wir hätten somit einen Computer, den man für alle Arten von Aufgaben nutzen könnte, die man auch im Rahmen eines Telefonats erledigen kann. Man kann zum Beispiel das Wetter erfragen, etwas zu essen bestellen, Musiktitel abspielen, sich Geschichten oder neueste Informationen aus Wissenschaft und Technik vorlesen lassen und so weiter. Soweit dieses System auch Schnittstellen zu anderen technischen Komponenten hat, könnten wir beispielsweise auch Licht einschalten, Türen schließen, die Heizungstemperatur einstellen und vieles andere mehr.

Das Ganze hat aber seine Grenzen. Würden wir auf diese Art und Weise einen längeren Text wie z. B. einen Brief verfassen? Abgesehen davon, dass viele Menschen nicht in der Lage wären, ohne Vorlage druckreif zu sprechen (diktieren), müssten wir auch mit Unterbrechungen klarkommen und uns überlegen, wie wir Fehler korrigieren, wie wir jeweils spezifizieren, an welcher Stelle was wie ergänzt, geändert oder gestrichen werden soll. Wir gerieten in eine Situation, in der wir das bisher Gesprochene entweder komplett im Kopf haben oder ständig Teile des diktierten Textes neu erfragen müssten. Das ist äußerst unpraktisch oder, je länger der Text ist, sogar unmöglich. Erweitern wir das System also um einen Bildschirm zur Anzeige der Ausgabe, wobei die Eingaben weiterhin rein verbal erfolgen. Wir haben nun ein Computersystem, das wir per Textprompts bedienen können, das aber auch über eine Anzeige verfügt, auf der ein Text oder zumindest ein Ausschnitt davon dauerhaft zu sehen ist. Wir könnten ein solches System gut nutzen, um unter Vorgabe des gewünschten Inhalts und zusätzlicher Parameter einen Text generieren zu lassen. Doch wie geht es weiter, wenn der Text nicht perfekt ist, wenn hier und da etwas geändert oder wenn unterschiedliche Textteile zusammengefügt oder umgeordnet werden sollen?

Würden wir solche Arbeiten gerne rein verbal erledigen? Selbst unter der Annahme, dass wir ein KI-Gegenüber haben, das uns bestmöglich versteht, wäre das wohl keine gute Idee. Um das zu verdeutlichen, ersetzen wir die KI kurzfristig einmal um eine klassische, menschliche Intelligenz, mit der wir die gleiche Aufgabe durchführen wollen. Diese Nutzungsschnittstelle entspräche nun einer Art von Videotelefonat, bei dem die Person am anderen Ende der Leitung das Gehörte auf eine Tafel schreibt. Wir können die Tafel sehen und unserem Gegenüber laufend Anweisungen geben, wie das Tafelbild entsprechend unserer Vorgaben zu verändern ist. Diese Art der Manipulation hat jedoch den Nachteil, dass sprachliche Befehle zur Manipulation physischer Objekte – und nichts anderes ist ein Text ja – immer indirekt sind. Stellen Sie sich vor, Sie wollen in dem Text ein Wort einfügen. Anweisungen wie „Füge im zweiten Absatz, in der zweiten Zeile vor ‘wichtig’ ein ‘sehr’ ein“ sind zwar verständlich, aber nicht besonders praktisch. Statt sprachlich über die Beschreibung der räumlichen Lage oder des Aussehens anzugeben, welches Objekt gemeint ist, wäre es doch viel einfacher, direkt auf das entsprechende Objekt zu weisen und es zu bearbeiten. Unsere bisher vorgestellte Nutzungsschnittstelle sieht das aber nicht vor.

Wir müssten für Aufgaben der Objektmanipulation wie bei der Textverarbeitung die Objekte also nicht nur sehen, sondern auch räumlich verdeutlichen können, worauf wir uns jeweils beziehen wollen.³ Eine solche Nutzungsschnittstelle wäre also immer auch grafisch-räumlich, ganz unabhängig davon, ob die jeweiligen Operationen dann schlussendlich aus einem Menü ausgewählt oder in natürlicher Sprache eingegeben werden.

Die Möglichkeiten der natürlich-sprachlichen Interaktion mit dem Computer werden in der Zukunft sicher zunehmen. In einigen Bereichen mögen sie die heutigen grafischen Nutzungsschnittstellen ersetzen und ergänzen, in vielen anderen Fällen werden sie das aber wohl nie tun, denn die Errungenschaft, Objekte am Bildschirm räumlich darzustellen, auf diese zeigen und sie an Ort und Stelle bearbeiten zu können, kann genauso wenig durch rein verbale Kommunikation ersetzt werden, wie Tafelanschriebe, Mitschriften und gedruckte Texte nur durch Vorlesen und Zuhören sinnvoll erschlossen werden können.

Unabhängig von den Vor- und Nachteilen sprachlicher und direkt-räumlicher Interaktionen ist das Paradigma des Mensch-Maschine-„Dialogs“ mit zusätzlichen Problemen behaftet, die mit den Fähigkeiten von Sprachmodellen nichts zu tun haben.

Programmierte Dialoge?

In seinem Buch „The Art of Interactive Design“ schlägt Chris Crawford vor, dass eine Nutzungsschnittstelle einen Dialog nachahmen soll, um „freundlicher“ zu wirken. Er charakterisiert dazu den schwer zu fassenden Begriff der Interaktion als „a cyclic process in which two actors alternately listen, think and speak.“⁴ Ob moderne KI-Sprachsysteme dieser Charakterisierung entsprechen, hängt davon ab, was genau sie unter „listen“, „think“ und „speak“ verstehen und ob das, was in einem KI-Modell passiert, wirklich ein Denken und Verstehen ist. Wir lassen diese philosophische Frage an dieser Stelle unbeantwortet, denn die „Dialoge“, auf die Crawford anspielt, sind weit entfernt von der Interaktion mit einem solchen Sprachsystem. Es geht vielmehr um recht einfache, aber häufig anzutreffende Situationen, in denen für die Ausführung einer Operation zusätzliche Informationen benötigt werden, oder solche, bei denen unerwünschte Konsequenzen auftreten können. Eine klassische Situation dieser Art liegt zum Beispiel vor, wenn eingegebene Informationen noch nicht gespeichert worden sind und im nächsten Schritt verloren gehen könnten, etwa wenn die Software beendet werden soll, aber der Inhalt der zuvor bearbeiteten Datei noch nicht gespeichert worden ist. In diesem Fall sollten, so Crawford, die Konsequenzen verdeutlicht und die Möglichkeit der direkten Speicherung angeboten werden. Ganz recht! Diese Hinweise entsprechen nicht nur unseren Forderungen nach Differenziertheit der Rückmeldung und nach Beeinflussbarkeit, sondern sind auch gängige Praxis, um die Konsequenzen von Fehlhandlungen zu reduzieren.

Darüber hinaus schlägt Crawford in solchen Situationen vor, einen Dialog zwischen Mensch und Maschine zu simulieren und so zu tun, als würde der Computer über eigene Befindlichkeiten sprechen. Das Resultat wäre eine Meldung wie „Ich habe deinen Text noch nicht gespeichert. Wenn du das Programm jetzt schließt, geht dein Text verloren. Möchtest du das wirklich? Dies sind deine Möglichkeiten:“. Damit verbunden ist das Ziel, in einer Schnittstelle keine Aussagen mit Schuldzuweisungen zu formulieren oder unfreundliche oder rüde Ausdrucksweisen zu benutzen. Stattdessen fordert Crawford, dass die Meldungen die Schuld auf Seiten des Computers ausdrücken sollten, etwa in Titelzeilen wie „Ich brauche mehr Informationen“, „Ich kann damit nicht umgehen“ oder „Ich habe es vermasselt“.⁵

Da sind wir anderer Ansicht! Natürlich gilt es, bei Meldungen niemanden zu beschimpfen, sondern konstruktive Formulierungen zu verwenden, aber Meldungen in der Ich-Form auszugeben, den Computer sich selbst des Versagens bezichtigen zu lassen und durch Fragen Interesse an der nutzenden Person zu suggerieren, sind aufgesetzt und falsch. Formulierungen wie „Sind Sie sicher, dass sie das wirklich tun wollen?“ fragen persönliche Befindlichkeiten ab, auf die man unter anderen Umständen abgewogen antworten könnte. Etwa in der Art „Ich glaube schon, aber vielleicht sollte ich darüber nochmal nachdenken.“, „Ich bin generell keine sichere Person!“ oder „Lass mich damit jetzt in Ruhe!“? Doch solche auf Seiten des Systems „inakzeptablen“ Antworten offenbaren, dass es nicht um einen natürlichen Dialog geht. Vielmehr wird der Handlungsfluss absichtlich unterbrochen, indem das System erzwingt, eine Auswahl aus den vorgegebenen Handlungsoptionen zu treffen. Das ist sowohl inhaltlich als auch ergonomisch geboten, weil der mögliche Schaden in vielen Fällen den Aufwand einer zusätzlich erzwungenen Auswahl überwiegt. Die Software kann aber jeweils nur das „akzeptieren“, was bei der Entwicklung als Option vorgesehen worden ist.

Diese Meldung von OpenOffice stammt aus dem Jahre 2005. Sie erschien, wenn eine Datei in einem nicht unterstützten Dateiformat abgespeichert werden sollte. Nach Crawford müsste zunächst auf das Versagen der Software hingewiesen werden. In der Titelzeile müsste also „I screwed up“ stehen. Der Text sollte dann in der Ich-Form der Software die Schuld an der Misere zuweisen, etwa „I am not able to save your document properly in the format you selected. Some of the formatting or content might get lost, if you try anyway.“ Egal ob Aussagen oder Fragen, alle Elemente dieses „Dialogs“ sind vor der Nutzung entworfen und programmiert worden, weshalb sie nicht der von Crawford selbst angegebenen Definition einer Konversation entsprechen können, die er in folgendem Ablauf beschreibt: ⁶

1. Partner A hört Partner B zu und interpretiert die Worte zu einem großen Ganzen.
2. Partner A denkt über die Aussagen von Partner B nach, wägt sie ab und bildet sich in Gedanken eine Antwort.
3. Partner A antwortet Partner B, indem die Gedanken in Worte umgesetzt werden.
4. Nun macht Partner B dasselbe mit vertauschten Rollen.

Hier ist kein Sprachmodell am Werk, das eine Konversation führt und dessen Operationen man vielleicht, wenn man möchte, als zuhören, interpretieren, nachdenken und antworten bezeichnen könnte. Der Dialog ist (vor-)programmiert. Entwicklungszeit und Nutzungszeit sind getrennt. Zur Nutzungszeit können weder neue Fragen formuliert noch eigene Antworten kreiert werden. Die natürlich-sprachliche Interaktion reduziert sich auf die natürlich-sprachliche Beschriftung von vorgegebenen Auswahlalternativen. Das Resultat ist ein Pseudo-Dialog.

Das Hauptproblem dieses Pseudo-Dialog-Stils ist nicht eine Frage an sich, sondern das Erwarten einer Antwort, vor allem wenn die angebotenen Antwortoptionen auch noch generisch, also etwa mit „Ja“, „Nein“ oder „Okay“ vorgegeben werden. Eine Antwort wie „Ja“ oder „Nein“ auf den „Antwort“-Buttons bezieht sich inhaltlich stets auf die gestellte Frage, nicht auf die auszuführende Handlung bzw. den Folgezustand. Es ist also zusätzlicher mentaler Aufwand erforderlich, um auswählen zu können, welche Handlungskonsequenzen jeweils mit der generischen Antwortauswahl verbunden sind (Umsetzungsproblem). Dieser Zusatzaufwand soll in dem OpenOffice-Beispiel dadurch gemildert werden, dass zusätzlich textuell angegeben worden ist, was bei „Ja“ oder „Nein“ passiert. Doch stehen diese Informationen nicht am Ort der Handlung, dem zu drückenden Button, müssen somit an anderer Stelle erschlossen werden (Informationsbeschaffung). Wenn es kein grundsätzliches Problem bereitet, oberhalb der Buttons ihre Wirkungsweise darzustellen, warum schreibt man das dann nicht gleich auf die Buttons selbst? Der zusätzliche Übersetzungs- und Informationsbeschaffungsaufwand ist völlig unnötig! Selbstverständlich gilt weiterhin, dass zusätzliche Informationen z. B. über Nebeneffekte und Folgekonsequenzen hilfreich und teilweise notwendig sind, doch sollten sie nicht durch die Art der Gestaltung grundsätzlich erzwungen werden.

Begriffe wie Partner, Dialog oder Konversation machen in diesen, aus gutem Grunde programmierten Situationen keinen Sinn. Warum sollten wir sie dann simulieren, zumal durch den Pseudo-Dialog mehr Text entsteht, der wahrgenommen und interpretiert werden muss? Mögliche Verbesserungen, die wir nachfolgend beschreiben, tragen vielmehr dem Umstand Rechnung, dass es entscheidend ist, die der Entwicklung des Systems unterliegende Designrationalität für die Nutzung transparent zu gestalten bzw. offenzulegen.

Der Zweck der angezeigten ursprünglichen Meldung war nicht, situative Einschätzungen der Nutzungssituation zu erfragen. Vielmehr geht es bei solchen Meldungen darum, zwei (oder auch mehrere) Möglichkeiten des weiteren Programmablaufs zur Wahl zu stellen. Ein Pseudo-Dialog ist da hinderlich. Dies wird an der obigen Abbildung der gleichen Meldung aus dem Jahr 2008 deutlich, die eine Verbesserung mit sich bringt. Zwar wird unter der Problembeschreibung nach wie vor eine Frage gestellt, doch sind die Buttons jetzt mit dem Effekt beschriftet, der bei ihrer Auswahl eintritt. Ungeschickt ist allerdings die vage Angabe „aktuelles Format“ auf dem linken Button. Was das bedeutet, steht nach wie vor nur im Beschreibungstext, nicht am Ort der Handlung, dem Button.

Bis zum Jahr 2015 wurde die Meldung nochmals weiterentwickelt. Das einzige Überbleibsel des früheren Pseudo-Dialogs ist das Fragezeichen im Meldungs-Icon. Innerhalb des Meldungsfensters gibt es hingegen weder Fragen noch Antworten. Die Problembeschreibung ist in Fettschrift herausgestellt und die beiden Entscheidungsmöglichkeiten werden auf spezifisch beschrifteten Buttons angeboten. Auch die Beschriftung ist verbessert worden, denn auf den Buttons wird nicht mehr nebulös von einem aktuellen Format gesprochen, sondern dieses Format wird direkt angegeben.

Ist okay wirklich okay?

Eine sehr kritische „Antwortmöglichkeit“ in einer Meldung ist das „Okay“ bzw. das „OK“.

In dieser Meldung wird ungeheuerliches kundgetan! Teile des geschriebenen Textes sind verloren gegangen und das Einzige, was man darauf „antworten“ kann, ist „OK“. Das ist aber überhaupt nicht okay! „Okay“ ist eine Antwort auf eine Aussage, mit der der Gesprächspartner einverstanden ist. Es findet jedoch kein Dialog statt und es geht auch nicht darum, mit etwas einverstanden zu sein. Angemessener wäre die nüchterne Beschriftung „Schließen“ oder „Gelesen“, denn das ist der einzige Grund für den Button: Zur Entwicklungszeit ist nicht absehbar, unter welchen Umständen bzw. wie schnell Text gelesen oder zur Kenntnis genommen wird.

Vorsicht mit Humor!

In eine ähnliche Richtung der Simulation eines Dialogs oder einer Konversation geht die Idee, Meldungen mit Humor aufzulockern. Der Versuch, unerfreuliche Situationen durch lustige Meldungen angenehmer zu gestalten, steigert nur noch potentiell den Ärger über die Situation. Beim ersten Mal mag es noch lustig sein, beim zweiten Mal vielleicht auch noch, aber irgendwann schlägt es in Aggressivität um. Insbesondere wenn durch einen Fehler Arbeit verloren gegangen ist, sind Entsetzen und Ärger unmittelbar da. Humoristische Bemerkungen in Pseudo-Dialogen sind grundsätzlich fehl am Platz. Humor erfordert ein gehöriges Maß an Fingerspitzengefühl und Einfühlungsvermögen in die jeweilige Situation. Programmierte Meldungstexte können das aufgrund ihrer Natur nicht.

Hier sehen Sie ein Beispiel für eine vermeintlich humoristische Meldung. Die mit „I screwed up“ betitelte Meldung wird in dieser Art, der Idee des Mensch-Computer-Dialogs folgend, von Crawford empfohlen. Einen Knopf mit „Shoot the programmer!“ zu beschriften, ist weder konstruktiv noch hilfreich, möglicherweise aber geschäftsschädigend.

Auch YouTube witzelt in einer Fehlermeldung. Unabhängig davon, wie gelungen ein Scherz oder Witz sein mag, sind humoristische Einlagen bei Meldungen problematisch, weil sie in vielen Nutzungskonstellationen sowohl bei unterschiedlichen Personen als auch bei ein und derselben Person nicht vorhersehbar sind, sie keine sachlichen Zusammenhänge beschreiben und ein solcher Pseudo-Dialog verletzend und stressfördernd wirken kann. Die Gestaltungsmaxime lautet daher: Meldungen sollten sich immer auf die Offenbarung der Designrationalität beschränken, d. h. angeben, was die Ursache einer Meldung ist und welche Handlungsoption angeboten wird, jedoch nicht ungeprüfte Annahmen und Spekulationen über die Nutzungssituation und die Befindlichkeiten der beteiligten Personen. Diese sind nicht vorhersehbar und während der Nutzungszeit nicht korrigierbar. Designentscheidungen müssen sachlich, aber sehr zurückhaltend abgefasst werden.

Fazit

Bis auf Weiteres müssen wir davon ausgehen, dass die Metapher vom partnerschaftlichen Dialog zwischen Mensch und Maschine eine ergonomische Gestaltung von Nutzungsoberflächen erschwert, da durch die Pseudo-Dialoge Sachverhalte verschleiert und nicht transparent gestaltet werden. Meldungen und sogenannte Dialoge werden vor der Nutzungszeit festgelegt, müssen also darauf gerichtet sein, während der Nutzung zu beschreiben, warum sie auftreten und was jeweils getan werden kann. Verständnisbildung und Lernen findet in den Köpfen der Menschen während der Entwicklung bzw. Nutzung statt, nicht jedoch in der Maschine, da die beiden Phasen zeitlich voneinander getrennt sind. Das Hineinversetzen in Absichten oder emotionale Befindlichkeiten bringt eine zusätzliche, weitaus komplexere Dimension ins Spiel, ohne damit einen erkennbaren ergonomischen Zugewinn erzielen zu können. Ob das für immer so bleiben wird, ist zwar offen, doch zeigen unsere eingangs dieser Exkursion beschriebenen Szenarien, dass für viele Aufgaben eine ergonomische Gestaltung von Nutzungsoberflächen nicht auf eine räumlich-visuelle Einbettung verzichten kann.

Exkurs: Farbmodelle

Um Objekte am Bildschirm anzuzeigen, sie auszuzeichnen und sie räumlich strukturieren zu können, ist es nötig, Farben und vor allem Farbabstufungen zu erzeugen (siehe Kapitel zur Präsentation). Wenn Sie eine Entwicklungsumgebung oder ein Framework nutzen, das Ihnen ein Farbschema bereitstellt, können Sie sich dieser Farben bedienen, sollten aber die in den entsprechenden Kapiteln motivierten Einschränkungen bedenken oder begründen können, warum Sie sie missachten. Wenn Ihnen kein Farbschema zur Verfügung steht oder wenn Sie selbst eines erzeugen wollen, müssen Sie Farben definieren und zueinander passende Farben zusammenstellen können. In diesem Exkurs-Kapitel stellen wir Ihnen einige technisch-wissenschaftliche Hintergründe und daraus abgeleitete Farbmodelle vor, um diese Aufgabe ausführen zu können.

Als sichtbares Licht nimmt der Mensch elektromagnetische Wellen zwischen 380 und 780 nm wahr. Wellen dieser Wellenlängen stimulieren die menschliche Netzhaut. Wenn nur Licht einer bestimmten Wellenlänge ins Auge vordringt, wird ein bestimmter Farbeindruck ausgelöst.

Wie Sie auf der Abbildung sehen, können Sie jeder Wellenlänge im Spektrum des sichtbaren Lichts einen Farbeindruck zuweisen. Andersherum funktioniert es aber nicht. Wenn Sie eine Farbfläche sehen, die gelb ist, heißt das nicht notwendigerweise, dass Licht mit einer Wellenlänge von etwa 570 nm ins Auge fällt. Der gleiche gelbe Farbeindruck entsteht auch bei einer Mischung aus rotem und grünem Licht.

Die Drei-Farben-Theorie

In seinem 1867 veröffentlichten „Handbuch der physiologischen Optik“⁷ beschreibt Hermann von Helmholtz auf der Grundlage von Experimenten, dass die Farben des natürlichen Lichtspektrums, also die Regenbogenfarben, durch die Kombination der Farben Rot, Grün und Blau erzeugt werden können und dass es demnach im Auge Rezeptoren für diese drei Farben geben muss. Erst 1956 wurde entdeckt, dass es im Auge in der Tat drei verschiedene Zapfentypen gibt und dass diese, wie durch von Helmholtz dargelegt, verschiedene Bereiche des Spektrums abdecken. Heute weiß man, dass, anders als lange angenommen, die drei Zapfentypen, obwohl man sie so betitelt, nicht den Farben Rot, Grün und Blau entsprechen und weitaus breitbandiger sind als von von Helmholtz angenommen.

In dieser Abbildung sind die Absorptionsraten der drei verschiedenen Zapfenarten auf der menschlichen Netzhaut dargestellt. Wie Sie sehen, sind alle drei Zapfentypen recht breitbandig empfindlich. Wenn Licht mit einer Wellenlänge von 570 nm ins Auge trifft, werden sowohl die L-Zapfen als auch, in geringerem Maße, die M-Zapfen angeregt. Die gleiche Anregung erreichen Sie auch, wenn Sie etwa 90 % Rot (640 nm) und 80 % Grün (580 nm) mischen. Im Auge entstehen die gleichen Anregungen der M- und L-Zapfen. Die beiden Farbeindrücke sind nicht voneinander zu unterscheiden.

Obwohl die von Helmholtz’sche Theorie der Farbwahrnehmung im Auge relativ nahekommt, entspricht die Art der Farbmischung mit Rot, Grün und Blau nicht der Art und Weise, wie Menschen Farben empfinden. In der Frage dieser Farbempfindung des Menschen stellte zum Beispiel Goethe⁸ umfangreiche Untersuchungen an. Er verlor sich dabei zum Teil in dem Versuch, Newtons Modell über den Zusammenhang von Licht und Farbe mit Argumentationen zu widerlegen, die einer naturwissenschaftlichen Überprüfung nicht standhalten konnten. Goethes Untersuchungen sind dennoch interessant, weil er aus Beobachtungen der Umwelt mit einem vor das Auge gehaltenen Prisma ein eigenes Farbsystem ableitete. Für Goethe waren Gelb und Blau die einzigen reinen Farben. Grün beschreibt er, da es die Mischung aus Gelb und Blau ist, als im Gleichgewicht befindlich. Auf etwas eigentümliche Art und Weise, deren Erläuterung uns zu weit weg führen würde, kommt in seinem Farbsystem noch Rot hinzu. Goethe beschreibt somit ein System aus den vier Farben Rot, Grün, Blau und Gelb.

Etwa vierzig Jahre nach dem Tod Goethes zog der Psychologe und Hirnforscher Ewald Hering⁹ in seiner „Lehre vom Lichtsinn“ ganz ähnliche Überlegungen an und folgerte aufgrund seiner Beobachtungen, dass sich gewisse Farbkombinationen ausschließen: So kann man zwar von einem bläulichen Rot oder auch gelblichen Grün sprechen, aber ein bläuliches Gelb oder ein rötliches Grün lässt sich nicht beobachten. Diese Farben scheinen sich auszuschließen. Aus solchen Überlegungen und aus den Farbeindrücken, die entstehen, wenn man nach der längeren Betrachtung einer intensiven Farbe auf eine weiße Fläche schaut, entwickelte er das System der Gegenfarbpaare Rot-Grün und Blau-Gelb. Diese bilden laut Hering ein natürliches System der Farbempfindung.

Mittlerweile hat die Forschung gezeigt, dass sich Herings Beobachtungen auch bei der Signalverarbeitung im Auge belegen lassen. Wie in der Grafik dargestellt, werden die Reize der Zapfen so miteinander „verschaltet“, dass schon auf der Retina die beiden Gegenfarbkanäle Rot-Grün und Blau-Gelb sowie ein Helligkeitskanal entstehen¹⁰.

Farbmodelle

Für die praktische Gestaltung mit Farben ist es nötig, dass man Farben benennen oder beschreiben kann. Eine Benennung nur mit Worten wird nicht genügen, denn selbst wenn wir viele Farbwörter hätten, könnten wir uns unter diesen Worten immer noch Verschiedenes vorstellen. Da Farben am Bildschirm durch die Kombination der drei Farben Rot, Grün und Blau erzeugt werden, liegt es nahe, die jeweiligen Intensitäten dieser drei Grundfarben zur Beschreibung von Farben zu nutzen. Hieraus resultiert das RGB-Farbmodell. Bei RGB werden die Intensitäten von Rot, Grün und Blau üblicherweise als Prozentzahlen oder als Werte von 0 bis 255 angegeben. Der Farbraum lässt sich, wie hier zu sehen, als Würfel darstellen.

Das RGB-Modell kann immer dann angewandt werden, wenn Licht direkt von einer Lichtquelle ins Auge fällt und nicht von einem Gegenstand reflektiert wird. Man spricht in diesem Falle von Lichtfarben. Wird Licht hingegen an einer Oberfläche reflektiert, spricht man von Körperfarben. Lichtfarben und Körperfarben haben unterschiedliche Farbmodelle, da die Farbmischungen auf unterschiedliche Art erfolgen: Richtet man einen roten, einen grünen und einen blauen Scheinwerfer auf die gleiche Stelle einer weißen Wand in einem ansonsten dunklen Raum, wird die Wand weiß beleuchtet. Mischt man hingegen aus dem Wasserfarbkasten alle Grundfarben zusammen, ist das Ergebnis nicht etwa weiß, sondern eher schmutzig grau. Bei solchen Körperfarben, die z. B. im Druckbereich eingesetzt werden, wird das CMY(K)-Modell als Gegenstück zu RGB verwendet. Dabei werden Cyan, Magenta und Gelb gemischt. Betrachtet man den oben abgebildeten RGB-Würfel, stellt man fest, dass er auch ein CMY-Würfel ist. Der Nullpunkt für RGB liegt bei Schwarz, der für CMY bei Weiß.

Theoretisch müssten beide Farbsysteme äquivalent sein, sind es in der Praxis jedoch nicht. Da Farbpigmente sich nicht perfekt mischen lassen, sondern einander teilweise verdecken, sind nicht alle Farben darstellbar. Mischt man Cyan, Magenta und Gelb, so ist das Ergebnis nicht Schwarz, sondern ein schmuddeliges Grau oder ein Braun. Aus diesem Grund wird beim Druck zusätzlich Schwarz (K für Key) hinzugefügt, um kontrastreiche Bilder drucken zu können. Mittels der CMYK-Mischung ist es trotzdem nicht möglich, alle RGB-Farben darzustellen. Bilder können daher am Bildschirm und beim Druck unterschiedlich aussehen. Im weiteren Verlauf kümmern wir uns nicht um CMYK, denn Bildschirme sind selbstleuchtend. Ein additives Farbmodell wie RGB ist also gefragt.

HSV und HSL

Das RGB-Farbmodell ist eine gute Beschreibung der technischen Farberzeugung, denn jede am Bildschirm darstellbare Farbe kann als ein Tripel von Zahlen dargestellt werden. Das Modell ist für die Gestaltung jedoch nicht geeignet. Schon die additive Farbmischung ist für das menschliche Empfinden nicht besonders einleuchtend. Kaum jemand würde wohl auf Anhieb darauf kommen, dass die Mischung aus Blau und Gelb Weiß ergibt. Eher würde man wohl entsprechend der subtraktiven Farbmischung von Grün ausgehen. Von diesem Aspekt abgesehen hat das RGB-Modell den grundsätzlichen Nachteil, dass es nur schwer möglich ist, ähnliche Farben zu finden. Farben, die für das Wahrnehmungssystem ähnlich aussehen, haben ganz unterschiedliche RGB-Werte.

Die beiden dargestellten Farben sind Abstufungen voneinander. Sie könnten gut zusammen in einer Nutzungsoberfläche verwendet werden. Betrachtet man jedoch ihre RGB-Werte, erkennt man die Ähnlichkeit der Farben nicht. Die rechte Farbe ist im Vergleich zur linken etwas weniger rot (14 % weniger), nahezu genauso grün (1,7 % weniger), aber fast dreimal so blau (181 % mehr). Man müsste dieser Beschreibung nach annehmen, dass es sich um eine recht bläuliche Farbe handelt. So erscheint sie uns aber nicht.

Das RGB-Modell ist daher für die wichtige Aufgabe, ähnliche Farben zu finden, nicht geeignet. Es gibt aber eine Vielzahl von Möglichkeiten, die RGB-Werte miteinander zu verrechnen und die Farben für unsere Ansprüche praktischer darzustellen. Man könnte zum Beispiel, entsprechend der Hering’schen Ideen, eine Farbe als Kombination der drei Kanäle Helligkeit, Farbtemperatur (blau-gelb) und Tönung (rot-grün) beschreiben. Ein solches Modell ist teilweise im Bereich der Bearbeitung von Fotos hilfreich. Für unsere Zwecke bieten sich jedoch andere Farbmodelle an. Im HSB-Modell etwa, das unten vorgestellt wird, haben die beiden oben gezeigten Farben den gleichen Farbton, allerdings ist die rechte Farbe nur etwa halb so stark gesättigt und minimal dunkler.

Die Idee der Farbmodelle HSB (das auch HSV genannt wird) und dem ähnlichen HSL ist die Beschreibung einer Farbe als Kombination aus einem Farbton, der Sättigung und der Helligkeit. Da es sich um Projektionen des RGB-Modells handelt, sind alle RGB-Farben auch in HSB und HSV darstellbar und umgekehrt. In Bezug auf den Farbton sind die beiden Modelle identisch, ihre Interpretation von Sättigung und Helligkeit ist allerdings unterschiedlich.

Der Farbton (Hue) ist eine Gradangabe im Farbkreis mit der Null-Grad-Marke bei Rot. Dieser Farbkreis besteht größtenteils aus den Regenbogenfarben, die so im Kreis angeordnet sind, dass sich im Kreis gegenüber jeweils die Gegenfarbe befindet. Mit den Regenbogenfarben allein ist der Farbkreis aber nicht komplett, denn, entgegen dem Spruch, dass dem Regenbogen keine Farben hinzuzufügen sind, gibt es Farben, die zwar durch die Mischung anderer Farben erzeugt werden können, für die sich aber keine Wellenlänge von Lichtstrahlen findet, die diesen Farbeindruck direkt hervorrufen könnte. Diese dem Regenbogen fehlenden Farben sind die Purpur- und Magenta-Farben, die aus der Mischung aus kurz- und langwelligem sichtbarem Licht (Rot und Blau) erzeugt werden können.

Ein großer Vorteil des HSB-Farbmodells ist, dass man sich die Farbmischung mit Hilfe von Folien veranschaulichen kann, die in der folgenden Reihenfolge übereinandergelegt werden:

H wie Hue (Farbton): Man wählt eine Grundfolie mit einer Farbe aus dem Farbkreis aus, indem man den Winkel zwischen Rot und der jeweiligen Farbe angibt.

S wie Saturation (Sättigung): Nun wird eine Weiß-Folie hinzugefügt. Die Sättigung wird in Prozent angegeben. Diese bestimmt die Deckkraft. Die 100-%-Folie ist komplett transparent, die 0-%-Folie ist deckend weiß, verdeckt also die zuvor ausgesuchte Farbe vollständig. Alle Folien dazwischen sind teildurchlässig, machen die ausgesuchte Farbe also zu einem bestimmten Grad milchig.

B wie Brightness (Leuchtkraft): Als letztes wird eine Schwarz-Folie aufgelegt. Diese entspricht der Leuchtkraft. Das System funktioniert ähnlich wie bei der weißen Folie. Die 0-%-Folie ist komplett schwarz, die 100-%-Folie komplett durchsichtig.

HSL funktioniert grundsätzlich ähnlich wie HSB. Allerdings sind die Formel und damit die Interpretation von Helligkeit (L) und Sättigung (S) eine andere. Man kann sich die Farbmischung bei HSL besser veranschaulichen, wenn man die Größen in etwas anderer Reihenfolge beschreibt:

H wie Hue (Farbton): Genau wie bei HSB eine Farbe aus dem Farbkreis als Winkel von Rot aus gesehen.

L wie Lightness (Helligkeit): Das Besondere am HSL-Modell ist die Helligkeitsangabe von Schwarz bei 0 % und Weiß bei 100 %.

S wie Saturation (Sättigung): Die Sättigung ist bei HSL ein Mischungsverhältnis zwischen der Farbe in der in L angegebenen Helligkeit und einem Grauton in der gleichen Helligkeit. Eine Sättigung von 0 % ist ein reiner Grauton der Helligkeit L, 100 % die gewählte Farbe der Helligkeit L.

HSL und HSB haben unterschiedliche Vorteile. Der größte Vorteil von HSL ist der unabhängige Helligkeitsregler von komplettem Schwarz bei 0 % bis zu komplettem Weiß bei 100 %. HSB ist in dieser Beziehung komplizierter. Der größte Nachteil von HSL ist das nicht intuitive Konzept von Sättigung. Ein sehr helles Gelb beispielsweise ist kaum zu erkennen und man würde es üblicherweise nicht als gesättigt beschreiben. In HSL ist der S-Wert jedoch hoch. Ganz praktisch spricht für HSL, dass das Farbmodell in der CSS-Spezifikation des W3C verwendet wird. Damit kann im wichtigen Bereich des Webdesigns und der Farbgestaltung von Web-Anwendungen auf HSL zurückgegriffen werden.

Eine wichtige Einschränkung muss übrigens für beide Modelle bedacht werden: HSL und HSB/V betrachten nicht die unterschiedliche Ausstattung des Auges mit S-, M- und L-Zapfen. Eine Änderung des Hue von Blau zu Rot resultiert in einer viel helleren Farbe. Die Empfindlichkeit des Auges für Blau und Violett ist erheblich geringer als für die anderen Farben. Das bedeutet in der Konsequenz, dass es mit HSV und HSL zwar möglich ist, einen Farbton mit verschiedenen Helligkeiten und Sättigungen zu erzeugen. Mit diesem System kann man aber nicht Farben verschiedener Farbtöne mit gleicher wahrgenommener Helligkeit und Sättigung erzeugen. Es gibt Farbräume, in denen dies möglich ist. Ihre Besprechung würde aber über das hinausgehen, was für unsere Zwecke wichtig ist.