Konventionen

Zwischen Ergonomie und Gebrauchstauglichkeit

Bis zu diesem Punkt haben wir uns explizit auf ergonomische Aspekte von Software beschränkt. Wir haben geschaut, wie sie gestaltet werden sollte, um an den Menschen und an seine körperliche und kognitive Konstitution angepasst zu sein. Wir haben gezeigt, dass eine nicht angepasste Gestaltung jeweils zu erzwungenen Sequenzialitäten führt. Gleichzeitig haben wir dargelegt, dass Forderungen zur ergonomischen Gestaltung einander oft widersprechen. Gestaltung von Software bedeutet also stets, diese Konflikte auszutarieren. Spätestens an dieser Stelle kommt die konkrete Nutzungskonstellation mit ins Spiel, denn das Austarieren erfordert die Betrachtung des Kontextes, das heißt, wie Menschen mit dem technischen System umgehen wollen und welche Aufgabe sie mit Unterstützung des Systems erledigen wollen.

Aus dem Einsatzkontext lässt sich für eine Softwaregestaltung indes weit mehr ableiten als nur die notwendigen Informationen zum Austarieren der Gestaltungskonflikte, denn in der Ergonomie haben wir völlig außer Acht gelassen, welchem Zweck die Software eigentlich dient und ob sich dieser Zweck erfüllen lässt. Ist dies nicht der Fall, kommt es wieder zu Hindernissen, die wir auch an dieser Stelle mit erzwungener Sequenzialität beschreiben könnten. Würde man etwa eine Software zur Lagerhaltung in einem Großlager für die private Weinsammlung nutzen, hätte man zwar ein umfangreiches Paket an Funktionen, doch wäre die Software für diesen Anwendungsfall sicherlich zu komplex. Sie würde über viele Eingabebereiche verfügen, die nicht benötigt und daher dauerhaft ignoriert werden müssten. Schließlich würde sie auch sprachlich an den Anforderungen vorbeigehen, da sie mit Begriffen wie Position, Warengruppe, Gefahrenklasse oder Ähnliches ausgestattet wäre, die im privaten Weinkeller kaum von Nutzen sein dürften.

Ein spezifisches Programm zur Weinkellerverwaltung könnte deutlich einfacher gestaltet sein und würde dadurch viele der entstehenden erzwungenen Sequenzialitäten nicht aufweisen. Es wäre für den Gebrauch tauglicher oder kurz: gebrauchstauglicher. Gleichermaßen ließe sich ein Warenlager sicher mit einer Tabellenkalkulation verwalten, wäre aber weniger gebrauchstauglich als ein den üblichen kaufmännischen Anforderungen angepasstes Lagerverwaltungsprogramm. Solche Fragestellungen fallen in den Bereich der Gebrauchstauglichkeit (engl. Usability Engineering), wo es das Ziel ist, die entsprechenden Anforderungen zu erheben und im Rahmen von Usability Tests zu validieren.

Einen Einblick in die Gebrauchstauglichkeit wollen wir an dieser Stelle nicht geben, denn in der gebotenen Kürze ließe sich nicht abhandeln, was anderswo Bücher füllt. Wohl aber wollen wir ein Schlaglicht auf einen wichtigen Gestaltungsaspekt lenken, der zwar nicht mehr zur Software-Ergonomie gehört, aber auch noch nicht auf empirische Erhebungen von Anforderungen im großen Stile angewiesen ist. Es geht um Konventionen, wie wir sie hier nennen möchten, also um Anforderungen aus dem Nutzungsumfeld, auf die man sich im Gestaltungsprozess abstützen kann, ohne sie stetig erneut erfragen zu müssen. Wir betrachten im Folgenden Konventionen innerhalb einiger grober Bereiche¹:

• Plattformkonventionen beschreiben Vorgaben für eine Systemplattform, in der Regel ein Betriebssystem oder ein Software-Framework. Das Erfreuliche an diesem Bereich der Konventionen ist, dass sie in großen Teilen von den Herstellern selbst aufgeschrieben werden und viele Ressourcen existieren, die bei der konformen Gestaltung helfen.
• Aufgabenkonventionen können sich auf nahezu jeden Aspekt einer Aufgabe beziehen. Unsere Hinweise beziehen sich, wie oben erläutert, nicht auf konkrete Aufgaben, sondern auf allgemein anwendbare Techniken, um mehr Konformität mit der Aufgabe zu erreichen. Hinzu kommen Hinweise auf einige Gestaltungsfehler, aufgrund derer keine aufgabenkonforme Nutzungsschnittstelle gestaltbar ist.
• Kulturelle Konventionen sind Gepflogenheiten, die sich durchgehend etabliert haben. Sie sind so mannigfaltig und zahlreich, dass wir keinen vollständigen Überblick geben können, sondern vor allem für das Problemfeld anhand typischer Aspekte sensibilisieren wollen.

Bevor wir die genannten Bereiche behandeln, müssen wir noch eine Grundsatzfrage klären. Sollte man sich an Konventionen halten, auch wenn sie unergonomisch sind?

Konventionen sind allgemein oder im Umfeld, in der eine Software eingesetzt wird, bekannt. Das ist ihre Stärke. Sie kommen auf sehr unterschiedliche Art und Weise zustande, verkörpern aber nicht notwendigerweise immer die bestmögliche Handlungsweise.

Etwas besser zu machen als üblich, erleichtert idealerweise die Nutzung bei denen, die neu mit einer Software umgehen, aber sie erfordert Aufwand bei denjenigen, die sich bereits auskennen. Sie haben die bislang übliche, vielleicht nicht perfekte Art und Weise über lange Zeit erlernt und verinnerlicht und sind daher in der Regel nicht bereit, zusätzlichen Lernaufwand zu spendieren, wenn es nur geringe Vorteile bietet. Hinzu kommt, dass die Expertise von anderen und die gebräuchlichen Hilfestellungen der konventionellen Methode entsprechen werden, sich dagegen mit dem Neuen viel weniger Leute auskennen.

Der Gestaltungskonflikt zwischen Vertrautheit und Effektivität tritt auch an anderen Stellen auf, wenn z. B. Plattformvorgaben – wie wir des Öfteren in diesem Buch gesehen haben – ergonomische Forderungen verletzen. Wie jeweils in solchen Fällen zu verfahren ist, lässt sich schwer verallgemeinern, weil es sowohl davon abhängt, wie streng und konsequent die jeweilige Konvention den Nutzungsalltag prägt, als auch davon, wie schwerwiegend die jeweilige Verletzung ist. Grundsätzlich gilt, dass Abweichungen von Konventionen explizit begründet werden sollten.

Plattformkonformität

Betriebssystemplattformen wie Windows, MacOS oder Android geben große Teile des Aussehens und des Verhaltens der Nutzungsoberfläche vor. Man braucht sich in den meisten Fällen nicht mehr darum kümmern, wie zum Beispiel ein Button aussehen soll.

Die ersten umfangreichen User-Interface-Guidelines wurden nach unserem Wissen von Apple für den Macintosh herausgegeben. Jede Macintosh-Software, ob von Apple selbst oder von anderen Herstellern, war angehalten, sich nach den Vorgaben dieses Dokuments zu richten. Lange Zeit war dieses einheitliche Design einer der Hauptvorteile von Macintosh-Systemen gegenüber anderen Systemen, zum Beispiel mit Microsofts DOS. Software-Produkte aus den 1980er Jahren unter MS-DOS weisen eine Vielzahl von verschiedenen Designs auf, die nicht nur unterschiedlich aussehen, sondern auch auf unterschiedliche Art und Weise funktionieren. In diesen Macintosh-Anwendungen kann man sich schnell zurechtfinden, denn jede dieser Anwendungen hat eine einheitliche Menüleiste, in allen gibt es Fenster, die sich auf die gleiche Art und Weise nutzen lassen, überall gibt es die gleichen Buttons und auch die Masken zur Auswahl einer Datei sehen in all diesen Anwendungen gleich aus und funktionieren auf die gleiche Art und Weise. Bei der Nutzung anderer Systeme wie etwa dem PC von IBM ist es dagegen erforderlich, mit jedem Programm, zumindest aber mit jedem Hersteller, eine andere Arbeitsweise zu erlernen.

Die Firma IBM reagiert auf diesen Missstand im Jahr 1987 mit der CUA-Spezifikation (Common User Access). Diese Spezifikation wird in der Folge in mehr oder weniger großem Maße von vielen MS-DOS-Anwendungen umgesetzt. Sie bilden die Grundlage für die Entwicklung von OS/2 und werden auch von Microsoft in Windows umgesetzt. Viele Aspekte dieser Spezifikation sind noch heute Standard, etwa, dass Buttons per Tastatur bedient werden können, indem die ALT-Taste zusammen mit einem unterstrichenen Buchstaben gedrückt werden kann (noch heute Standard in klassischen Windows-Programmen), dass F1 die Hilfe aufruft, noch heute üblich bei Windows, dass die Tabulatortaste zwischen Eingabefeldern und Buttons weiterschaltet und so weiter.

Heute gibt es User-Interface-Guidelines von allen Herstellern für alle Betriebssysteme bzw. Nutzungsoberflächen. Grundsätzlich empfehlen wir, sich die Empfehlungen jeweils durchzulesen und sich daran zu halten. Die User-Interface-Guidelines sind heutzutage meist mit der Bereitstellung einer Vielzahl von Ressourcen verbunden. Dies reicht von Farbschemata über Schriften und Standard-Icons bis zu einem großen Katalog von Standard-Nutzungsschnittstellen-Elementen. Bei Microsoft kann man ein Programm herunterladen, in dem alle Ressourcen inklusive aller Nutzungsschnittstellen-Elemente an einem Beispiel vorgeführt werden.

Wie schon erwähnt, genügen Design-Vorgaben in User-Interface-Guidelines nicht zwingend ergonomischen Kriterien und werden in der Regel auch nicht ergonomisch begründet. Die Abbildung zeigt eine Gegenüberstellung von Icons in Apples MacOS X. In der Version 10.10 Yosemite von 2014 sind die unten abgebildeten Icons durch die oberen ersetzt worden. So sehr wir uns auch bemühen, können wir keinerlei ergonomischen Fortschritt entdecken. Die neuen Icons sind stärker gesättigt und haben dadurch weit mehr Ablenkungspotenzial, die Overlay-Icons sind schlechter zu erkennen und die Farbverläufe widersprechen der Hypothese einer Lichtquelle von oben.

Auch Microsofts User-Interface-Guidelines weisen Kuriositäten und vor allem auch über die Zeit kuriose Entwicklungen auf. Für Windows 95 wird noch, ganz in unserem Sinne, Zurückhaltung bei der Farbgestaltung empfohlen:

Use of a Limited Set of Colors – While the human eye can distinguish millions of different colors, using too many usually results in visual clutter and can make it difficult for the user to discern the purpose of the color information. The colors you use should fit their purpose. Muted, subtle, complementary colors are usually better than bright, highly saturated ones, unless you are really looking for a carnival-like appearance where bright colors compete for the user’s attention. (Windows 95 User Interface Guidelines)

Die Begründungen von Microsoft sind gut gewählt, denn, ohne allzu sehr in die Tiefe zu gehen, wird mit der Wahrnehmbarkeit und mit der Gefahr der Ablenkung durch zu viele Farben argumentiert. Siebzehn Jahre später argumentiert Microsoft für Windows 8 aber anders:

Take full advantage of the digital medium. Remove physical boundaries to create experiences that are more efficient and effortless than reality. Being authentically digital means embracing the fact that apps are pixels on a screen. It means designing with colors and images that go beyond the limits of the real world.

Be dynamic and alive with communication. * Use typography beautifully. * Use bold, vibrant colors. * Connect to the cloud so that your users can stay connected to each other.

An solchen Stellen kann man die Konvention missachten, denn der Verzicht auf allzu viele farbige Flächen wird kaum dafür sorgen, dass das Programm nicht mehr nutzbar ist. Die Abweichungen von der Konvention sind ergonomisch begründet, unschädlich und somit generell empfehlenswert. Begründete Abweichungen von der Norm können auch in grundsätzlichen Abläufen und Arbeitsweisen angeraten sein. Sie sollten jedoch auch in der Gestaltung verdeutlicht werden**.

In diesem Beispiel ist das nicht geschehen. Falls es einen Grund dafür geben sollte, dass bei Microsoft Word die Funktionalität entgegengesetzt zu der von anderen Mac-Applikationen ist, kann von der Norm abgewichen werden. Diese Abweichung wird jedoch nicht durch die Gestaltung verdeutlicht. Das Meldungsfenster von Word sieht genauso aus wie ein Standardfenster. Die mögliche Folge ist, dass bei der Nutzung statt auf „Sichern und Beenden“, was ja eine sichere Wahl wäre, auf „Änderungen verwerfen“ geklickt wird.

Aufgabenkonventionen

In der Einleitung des Kapitels haben wir auf die Schwierigkeiten hingewiesen, aus ergonomischer Sicht über Aufgabenkonformität zu sprechen, denn Konventionen der Aufgabe sind dieser zu eigen und können schlecht verallgemeinert werden. Es gibt aber auch in diesem Fall einige allgemeine Hinweise, deren Einhaltung die Aufgabenkonformität generell verbessert.

Direkte, klare und einfache Sprache

Grundsätzlich gilt, klare und positive Aussagen zu formulieren. Wo Negationen erforderlich sind, sollten keine doppelten Verneinungen auftreten. Dazu ein Beispiel einer Mediensteuerung in einem Hörsaal, über die zwei unter der Decke hängende Projektoren gesteuert werden können. Neben der Auswahl der jeweiligen Quelle kann man auch die Projektion auf schwarz schalten. Diese Funktion hat die seltsame Bezeichnung „Picture Mute“. Dies ist schwer nachvollziehbar, weil „mute“ nicht „schwarz“, sondern „stumm“ bedeutet. Vor allem ist es aber eine inhärent negative Aussage. Das System zeigt in bestem Denglisch den Zustand mit „Picture Mute ist aus“ an. Das ist nicht ohne weiteres einsichtig und führt leicht zu Fehleingaben. In einer Überarbeitung haben wir deshalb diese Schaltfläche auf „Schwarz“ ändern lassen und damit die Unklarheiten beseitigt. Kritisch ist eine doppelte Verneinung übrigens vor allem, wenn sie in einer Frage verwendet wird. Auch dies passiert oft in indirekter Form mit einem negativen Verb wie „verwerfen“ wie z. B. in der Frage: „Wollen Sie Ihre Arbeit wirklich nicht verwerfen?“

Zur klaren Sprache gehört außerdem, dass keine tiefen Verschachtelungen und keine Konjunktivsätze verwendet werden. Berufsgruppen oder soziale Milieus prägen eine Art Fachsprache mit für Außenstehende meist kryptischen Abkürzungen und ungewohnten Redewendungen aus. Ein solcher Jargon, vor allem aus dem Technikbereich, sollte sich nicht in einer Nutzungsoberfläche wiederfinden, es sei denn, die Anwendung ist für Technikspezialisten entwickelt worden. In diesem Fall erfüllt es die Forderungen an die Aufgabenkonformität. In allen anderen Fällen sollte diese Sprache vermieden werden.

Ebenso sollten statt fremdsprachlicher Fachbegriffe entsprechende landessprachliche Übersetzungen eingesetzt werden. Für Begriffe wie „Backup“ oder „Viewer“ sollten beispielsweise „Sicherung“ oder „Sicherungskopie“ und „Betrachter“ verwendet werden. Da sich jedoch auch viele fremd- oder fachsprachliche Begriffe in der Alltagsprache etabliert haben, könnte die Verwendung des Wortes Datenpost für E-Mail seltsam anmuten und zu Verwirrung führen. In diesem Zusammenhang sind auch Begriffe problematisch, die beispielsweise im Bereich der Informationstechnik selbstverständlich verwendet werden, die aber außerhalb der IT eine andere Bedeutung haben. Sie sollten entweder erläutert oder vermieden beziehungsweise ersetzt werden. Typische Beispiele sind „Zertifikat“, „Konto“, „Prozess“² (noch problematischer sind die Termini „Kind-Prozess“ und „Eltern-Prozess“) oder „Routine“. Ein Konto, das den autorisierten Zugriff auf Daten oder Dienstleistungen verwaltet, ist etwas anderes als ein Bankkonto. Bei solchen Begriffen sollte nutzungsseitig keine Verwirrung entstehen.

Ebenfalls für Verwirrung sorgen Begrifflichkeiten, die im Rahmen der Entwicklung und damit auch innerhalb des Quellcodes in internen Bezeichnungen und in Kommentaren üblich, akzeptabel und angemessen sein mögen, wenn sie in die Nutzungsschnittstelle vordringen. Bei der anzutreffenden Fehlermeldung „Die Datei ist korrupt!“ etwa liegt ein Übersetzungsfehler vor. Das englische Wort „corrupt“ kann „beschädigt“ oder „unbrauchbar“ heißen. Das deutsche Wort „korrupt“ bedeutet das nicht.

Und was bedeutet die Meldung „unerwartete Fehler“? Wer oder was erwartet denn etwas? Da es diese Meldung gibt, muss sie bei der Entwicklung als Möglichkeit erwartet worden sein. Es wird also etwas Unerwartetes erwartet, doch warum ist das ein Fehler und wodurch wurde er verursacht? Ohne Kenntnis des technischen Konzepts der Ausnahmebehandlung ist diese Meldung kaum nachvollziehbar. Tatsächlich handelt es sich um Situationen, für die im Programm nicht explizit vorgesorgt worden ist. Erwartete Fehler werden anders behandelt und werden mit konkreten Methoden behandelt, etwa wenn der Speicherplatz nicht ausreicht oder aber die Datei ein falsches Format hat. Mit diesen Problemen wurde bei der Entwicklung gerechnet. Ein unerwarteter Fehler hingegen ist einer, mit dem nicht gerechnet wurde. Der technisch richtige Ausdruck wäre „unbehandelte Ausnahme“, doch sollte sich auch dieser nicht in der Nutzungsschnittstelle wiederfinden. Was kann man stattdessen machen?

Zunächst sollte die Anzahl der Situationen, in denen es zu solchen Meldungen kommen kann, möglichst klein gehalten werden. Wenn es aber doch dazu kommt, könnte man zum Beispiel von einem „internen Fehler“ sprechen. Das ist zwar nicht konkreter und noch weniger präzise, aber da das Programm sich bei Erscheinen einer solchen Meldung ohnehin in einem Zustand befindet, in dem nichts mehr zu ändern ist, spielt das keine große Rolle. „Interner Fehler“ drückt diesen Tatbestand recht gut aus.

Zu guter Letzt noch der Hinweis, Fachtermini zu vermeiden, wenn der jeweilige Tatbestand handlungsorientiert angemessener ausgedrückt werden kann. Die Meldung „Die Syntax für den Seitenbereich ist ungültig“ lässt alle, die den Begriff Syntax nicht kennen, ratlos zurück. Was ist passiert? Es sind Zeichen eingegeben worden, die an der entsprechenden Stelle nicht zulässig sind. Das kann man aber auch genauso formulieren, ohne den Begriff Syntax strapazieren zu müssen.

Kulturelle Konventionen

Ein großer Teil der (oft ungeschriebenen) Konventionen entstammt allgemeinen, kulturellen Übereinkünften. Doch die Frage, auf was sich der Begriff Kultur im Einzelnen bezieht, lässt sich nicht generell beantworten. Wir können beispielsweise von einem westlichen Kulturkreis sprechen und uns auf bestimmte Umgangsformen oder auch die Farbgebung beziehen. Es kann aber auch die Nutzung des gleichen Alphabets und die gleiche Leserichtung beinhalten, von links nach rechts und von oben nach unten. Nicht alle Konventionen müssen von den Mitgliedern eines Kulturkreises gleichermaßen geteilt werden. Hebräisch beispielsweise wird, ähnlich wie im arabischen Sprachraum, von rechts nach links geschrieben und gelesen. Im asiatischen Raum sind weitere Leserichtungen üblich. Japaner schreiben sowohl von links nach rechts, von rechts nach links als auch spaltenweise von oben nach unten. Kulturelle Konventionen dieser Art überspannen teils große Bereiche. Andere Konventionen sind national oder regional begrenzt. Schließlich gibt es auch noch „Subkulturen“, die sich wiederum übergreifend organisieren, Berufsgruppen, Sportverbände oder die Wissenschaft. In all diesen Gruppen gibt es eigene Konventionen und eigene Fachsprachen sowie spezielle Zeichen, Codes und Verhaltensweisen.

Wenn wir uns um kulturelle Kohärenz bemühen, um erzwungene Sequenzialität zu reduzieren, können wir dies also mit zwei gleichermaßen wichtigen Zielen tun:

• Die interne Sichtweise ist entscheidend, wenn die Software spezifisch auf einen bestimmten Kulturkreis zugeschnitten sein soll. Sie sollte den kulturellen Konventionen möglichst vollständig entsprechen.
• Bei der externen Sichtweise hingegen geht es um Software, die in mehreren Kulturkreisen Verwendung finden soll. In einem solchen Nutzungsszenario gilt es vor allem Probleme zu vermeiden bzw. abzumildern, die durch unterschiedliche kulturelle Konventionen verursacht werden.

In nahezu allen praktischen Fällen ist man gut beraten, möglichst beide Ziele gleichermaßen im Auge zu behalten, da es im Zuge der Globalisierung vielfach keine durchgängige Kopplung kultureller Besonderheiten mit Nutzungsorten oder sozialen Gruppen gibt.

Internationalisierung und Lokalisierung

In Zeiten des Internets wird Software zunehmend in verschiedenen Kulturräumen eingesetzt. Damit es nicht zu Problemen kommt, kann man Software lokalisieren, also auf den aktuellen Kulturkreis anpassen, oder internationalisieren, also so gestalten, dass sie in vielen Kulturkreisen funktioniert. Lokalisierung betrifft die Sprache, aber zum Beispiel auch Adressenformate, Maßsysteme etc. Internationalisierung beinhaltet unter anderem das Verzichten auf nur lokal verständliche Bilder (auch Sprachbilder), aber auch das Verzichten auf modische Farbgestaltungen, die in verschiedenen Kulturkreisen unterschiedlich aufgenommen werden können.

Sowohl für Internationalisierung als auch für Lokalisierung ist spezifische Expertise erforderlich, die in einem Entwicklungsteam ebenso wie bei uns in der Regel nicht vorhanden ist. Wir behandeln die Thematik trotzdem kurz, um zum einen für das Thema zu sensibilisieren und zum anderen, um bestimmte Fallstricke zu vermeiden.

Nicht nur Text, sondern auch bildliche Darstellungen können sehr spezifisch für eine Kultur sein. Damit sind Icons ein Kandidat für Lokalisierung und Internationalisierung. Viele Icons, die in grafischen Nutzungsschnittstellen verwendet werden, sind inzwischen standardisiert und werden international verwendet. Dass das Abgebildete einem bestimmten Kulturkreis entstammt und etwas zeigt, das nicht überall so aussieht oder so praktiziert wird, muss nicht problematisch sein. Wir verdeutlichen dies an einigen Beispielen aus „The Icon Book“³.

Diese Zeichen können beispielsweise international verwendet werden, auch wenn das darauf abgebildete nicht international ist. Das erste Icon wird international als Buch erkannt, auch wenn in Ländern, in denen von rechts nach links geschrieben wird, also im arabischen, persischen und hebräischen Sprachraum, das Bild den Eindruck erwecken mag, dass die Rückseite beschriftet wäre. Das zweite Zeichen zeigt einen Handschlag. Dieses Bild wird auch in Kulturkreisen verstanden, in denen ein Handschlag zur Begrüßung weniger üblich ist, etwa in Asien. Das Gleiche gilt für das Besteck als Zeichen für Essen oder Restaurant. Auch in Kulturkreisen, in denen diese Esswerkzeuge nicht vornehmlich genutzt werden, ist es bekannt. Das letzte Icon zeigt einen typischen amerikanischen Briefkasten. Schon bevor diese Briefkästen bei uns zunehmend in Mode gekommen sind, ist die Bedeutung dieses Zeichens bei uns bekannt gewesen. Es ist daher nicht nötig, dieses Zeichen in Deutschland durch einen gelben Postkasten und in Großbritannien durch eine rote Säule auszutauschen. Das Gleiche gilt für eines der bekanntesten Icons der Desktop-Metapher, dem Ordner. Das Ordner-Icon zeigt einen typischen amerikanischen Folder. Das Bild ist aber inzwischen international so bekannt, dass Sie nicht gut daran täten, es durch einen deutschen Leitz-Ordner zu ersetzen.

Dass diese Icons keine Probleme zu bereiten scheinen, dürfte damit zusammenhängen, dass es sich um echte Bild-Icons handelt. Es ist nicht nur ein abgebildetes Objekt zu erkennen, sondern dieses hängt mit dem zusammen, wofür das Icon steht (siehe Kapitel Icon-Gestaltung). Es kann zwar sein, dass das Abgebildete nicht erkannt wird, weil das Objekt, auf das es verweist, nicht bekannt ist, doch ist unwahrscheinlich, dass das Abgebildete im jeweiligen Kulturkreis für etwas ganz Anderes steht.

Bei diesen Icons sieht das jedoch anders aus. Wir erkennen sie wahrscheinlicb als „Alles in Ordnung“, „Lecker“ und „Stopp“. Wir wollen das an dieser Stelle nicht vertiefen, sondern nur darauf hinweisen, dass jedes dieser Zeichen in mindestens einem Kulturkreis jeweils etwas anderes bedeutet, oft sogar etwas Schlüpfriges oder Fäkales. Seien Sie daher immer vorsichtig, wenn Sie Handzeichen dieser Art verwenden. Zudem lässt sich an diesen Beispielen gut feststellen, dass Konventionen dem Zeitgeist unterworfen sind, denn spätestens mit dem Erfolg von Facebook und dem dort allgegenwärtigen Daumen nach oben dürfte diese Bedeutung des Zeichens weltweit bekannt sein und vermutlich dominieren.

Sehr problematisch sind schließlich auch Zeichen, die Tiere verkörpern, denn ihre Zuschreibungen sind meist stark mit religiösen oder spezifischen in einer Kultur verbreiteten Geschichten und Sagen verknüpft. Dem deutschen Kulturkreis entsprechend könnten die obigen Zeichen für „Suchen“, „Lexikon“, „Schnell“ und „Sparen“ stehen. Doch das ist keineswegs universell. Während eine Eule in Anlehnung an antike Geschichten in Europa oft für Weisheit steht, verkörpert sie in Indien die Dummheit schlechthin. Bei einem Kaninchen beziehen wir uns auf deren Schnelligkeit. In Australien sind bei einem Kaninchen eher Assoziationen wie Plage oder Fertilität zu erwarten. Auch andere Tiere wie Hunde oder Schweine gelten in vielen Regionen der Welt als verpönt oder werden mit jeweils unterschiedlichen Eigenschaften verbunden.

Ein besonders wichtiger Bereich der Lokalisierung ist die Übersetzung eines Textes in eine andere Sprache. Übersetzungen sollten grundsätzlich von Personen durchgeführt werden, die über die entsprechenden Sprachkompetenzen verfügen. Zudem sollte die Qualität der Übersetzung mit der jeweiligen Zielgruppe im Kontext getestet werden.

Übersetzungen bergen viele Probleme auch dadurch, dass eine Sprache kein einheitliches Kulturgebiet darstellt. Schon im deutschsprachigen Bereich gibt es viele Unterschiede im Sprachgebrauch etwa zwischen Norddeutschen und Österreichern. Bei sehr weit verbreiteten Sprachen wie Englisch, Spanisch und Chinesisch sind die damit verbundenen Herausforderungen jedoch ungleich komplexer. Folgendes Problem einer Übersetzung von Microsoft beschreibt zum Beispiel heise:

[Microsoft hatte] die Geschlechtsangaben für ein Formular aus dem Englischen in die Wörter „varon“ für „männlich“, „No especificado“ für „keine Angaben“ und „hembra“ für „weiblich“ übersetzt – und nicht bedacht, dass „hembra“ in manchen lateinamerikanischen Ländern für „Hure“ gebraucht wird.

Um gegen solche Probleme gefeit zu sein, helfen nur ausgeprägte Sprachkompetenzen und intensives Testen der Software in den intendierten Zielgebieten. Fundierte Sprach- und Kulturkompetenzen braucht man auch, wenn es um das Finden des richtigen Tons geht. Dies geht deutlich über das Erzeugen einer korrekten Übersetzung hinaus. Es gibt zum Beispiel einen bekannten Unterschied zwischen dem Tonfall in der westlichen Welt, in der eine direkte Aufforderung wie „Geben Sie ein Datum vor März 2028 an!“ völlig akzeptabel ist. Wenn man diese Meldung wörtlich ins Japanische übersetzt, würde das sehr unhöflich wirken, denn direkte Aufforderungen an Personen sind dort zu direkt. Dort würde man die Meldung eher wie folgt formulieren: „Ein Datum vor März 2028 muss eingegeben werden.“ Wenn diese Formulierung wiederum im Deutschen Verwendung fände, würde sie wohl nicht als unfreundlich, wohl aber als umständlich empfunden. Bei Übersetzungen von Software treten, von solchen Fallstricken abgesehen, oft viel einfachere Probleme auf, die aus dem Übersetzungsprozess selbst resultieren und die wir uns im Folgenden anschauen wollen.

Wenn der Übersetzungsprozess ausgelagert wird, das heißt, von der unmittelbaren Entwicklung separat erfolgt, gibt es meist lange Listen mit zu übersetzenden Inhalten. Im nachfolgenden Beispiel steht links der Text in Originalsprache und rechts in der Übersetzung. Das Problem ist, dass die Übersetzung nicht ohne den jeweiligen Kontext erfolgen kann, in dem ein bestimmter Ausdruck verwendet wird. Nehmen wir als Beispiel das englische Wort „none“. Wie sollte man „none“ ins Deutsche übersetzen? Bei „Mouse: none“ und „Screen: none“ müsste es einmal mit „keine“ und einmal mit „keiner“ übersetzt werden, vorausgesetzt, dass „screen“ mit „Bildschirm“ übersetzt worden ist.

Auch mit diesem Beispiel haben wir ein ähnliches Problem. Wenn man im Englischen „turn on“ betätigt, ist etwas „on“, entsprechend ist es bei „turn off“ hinterher „off“. Im Deutschen geht das so nicht. Ein Gerät oder eine Funktion ist nach dem Einschalten nicht „ein“, sondern „an“ oder allenfalls „eingeschaltet“.

Wie würden Sie „switch“ übersetzen? „Umschalten“ ist eine Möglichkeit, etwa bei „Switch sources“, aber bei „Switch mouse buttons“ werden diese nicht umgeschaltet, sondern schlicht und ergreifend vertauscht. All diese Übersetzungen haben das gleiche Problem: Wenn in einer Sprache dasselbe Wort in unterschiedlichen Situationen verwendet wird, muss das in einer anderen Sprache nicht der Fall sein. Gerade Englisch ist aufgrund seiner vielen generischen Ausdrücke als Quellsprache besonders problematisch.

Die Abbildung illustriert ein solches Problem, das in iWork-Anwendungen von Apple auftritt. Links befinden sich Ausschnitte aus der Nutzungsschnittstelle des Präsentationsprogramms Keynote, oben auf Englisch, unten auf Deutsch. Bei der Einstellung für das Aussehen eines Linienzugs wurden die Wörter „line“ und „lines“ korrekt mit „Linie“ und „Linien“ übersetzt. Im rechten Teil der Abbildung kommt das Wort „lines“ jetzt in der Textverarbeitung Pages vor. Dabei geht es um die Einstellung des Zeilenabstands. Zeilen heißen an dieser Stelle aber nicht Zeilen, wie es eigentlich richtig wäre, denn „lines“ ist schon mit „Linien“ (in diesem Zusammenhang falsch) übersetzt worden.

Rechts befindet sich noch ein Kuriosum, das erstaunlicherweise genauso in Keynote von Apple wie in PowerPoint von Microsoft vorkommt. Mehrere Elemente können in beiden Programmen zu einem Objekt zusammenfasst werden. Die Funktion dazu heißt auf Englisch „group“ und wurde mit „gruppieren“ übersetzt. Das entstehende Objekt heißt Englisch ebenfalls „group“ oder auf Deutsch, zumindest entsprechend Microsoft und Apple, „Gruppierung“ statt korrekt „Gruppe“.

Die genannten Beispiele sind noch relativ harmlos, weil auch die falsche Übersetzung zum Kontext passt, sodass die korrekten Übersetzungen noch einigermaßen nah dran sind. Unverständlich wird es, wenn die Übersetzung zu einem falschen Kontext gehört. Die Abbildung zeigt eine Anpassungsschnittstelle für die Werkzeugleiste im Grafikprogramm Pixelmator. Neben Funktionen wie „Bewegen“ und „Beschneiden“ kann man auch „Scheibe“ hinzufügen. Erst wenn man sich das englische Ausgangswort vor Augen hält, kann man feststellen, dass in diesem Zusammenhang das Wort „Slice“ falsch übersetzt ist. Richtig wäre „Zerteilen“ und nicht etwa „Scheibe“ wie in „a slice of bread“.

Überall dort, wo in der Nutzungsschnittstelle vollständige Sätze verwendet werden, sollte auch der komplette Satz übersetzt werden. Vermeiden Sie es, Sätze zusammenzusetzen oder, wie in der Abbildung zu sehen ist, dies im Rahmen der Nutzung zu ermöglichen. Das Ergebnis kann sehr verwirrend sein. In dem Beispiel geht um das Verhalten des Scrollrads der Maus. Auf Englisch vervollständigt die Auswahl den Satz „Roll the mouse wheel to scroll multiple lines at a time“, auf Deutsch wäre angemessen „Ein Drehen des Mausrads scrollt mehrere Zeilen auf einmal“. Da der Text aber in zwei Teile zerfällt, sind der obere und der untere Teil jeweils getrennt für sich übersetzt worden, was zu einem recht unverständlichen Ergebnis geführt hat. Selbst wenn in diesem Fall auf Deutsch bessere Formulierungen möglich gewesen wären, sollte man solche Trennungen vermeiden. Das zeigt auch das folgendes Beispiel:

Press + to [scroll/turn over] to the next page.

Wenn die Teile einzeln übersetzt werden, entsteht ein grammatisch falscher Satz wie „Drücken Sie + um zu [scrollen/blättern] zur nächsten Seite.“, denn im Deutschen müsste das Verb korrekterweise nach hinten wandern.

Dieses abschließende Beispiel zeigt ein weiteres Problem, wie bei der Übersetzung ohne Kontext typischer Eigenarten der Sprachen nicht berücksichtigt werden. Das Problem besteht darin, dass im Englischen auf Grundlage des geschriebenen Wortes nicht zwischen einem Infinitiv und einem Imperativ unterschieden werden kann. „Close Program“ kann sowohl „Programm schließen“ bedeuten, wenn es etwa auf einem Button in einer Fehlermeldung steht, oder auch „Schließen Sie das Programm“, wenn es etwa in einem erläuternden Hilfetext steht. Ohne den nötigen Kontext kann es bei der Übersetzung zu Vertauschungen kommen. In dem Fall steht auf einem Button „Schließen Sie das Programm“. Ähnliches ist bei der Option „Join the office insider program“ geschehen. Als Option müsste es mit „Am Office Insider Programm teilnehmen“ übersetzt werden, nicht aber mit „Nehmen Sie am Office Insider Programm teil“. Wenn man Letzteres liest, fragt man sich, wer hier mit wem spricht (vgl. unser Exkurs-Kapitel zum Mensch-Computer-Dialog.

Nutzung schafft Konventionen

Wir wollen dieses Kapitel mit einem interessanten Aspekt beenden, der bei der Betrachtung von Konventionen leicht übersehen werden kann. Der Gebrauch von Software schafft nämlich unter Umständen auch seine eigenen Konventionen. Die Art und Weise des Umgangs mit weit verbreiteter und häufig genutzter Standard-Software kann zur Etablierung von De-facto-Standards führen. VisiCalc oder WordStar sind Beispiele dafür, weil sich vielfach andere Software-Produkte an diese Schnittstellengestaltung angelehnt haben. Die Tastenkombinationen aus WordStar funktionieren zum Beispiel auch in frühen Versionen der integrierten Programmierumgebung TurboPascal. In der Frühzeit des World Wide Web hat man sich sehr darum bemüht, die aus Microsoft Word oder Microsoft Windows vertrauten Nutzungsweisen ins Web zu übertragen. Gegenwärtig läuft der Trend aber eher in die entgegensetzte Richtung, weil Nutzungsweisen aus dem Web zunehmend auch in nativen Anwendungen zu finden sind. Auch wenn es in der Hoffnung auf die Etablierung eines eigenen De-facto-Standards verlockend scheint, von gängigen Nutzungskonventionen stark abzuweichen, raten wir davon ab, denn es birgt ein sehr hohes Risiko durch mangelnde Akzeptanz.

Eine Besonderheit von Software ist, dass sie bis auf sehr wenige Ausnahmen in Versionen existiert. Mit der neuen Version einer Software können auch umfangreiche Änderungen in der Nutzungsschnittstelle einhergehen. So hat beispielsweise Microsoft beim Wechsel von der Version 2003 zur Version 2007 seiner Office-Produkte die Schnittstelle von den klassischen Icon-Leisten und Menüs zu den Ribbons umgestellt. Diese Änderung der seit über zehn Jahren etablierten Nutzungskonventionen hat sowohl bei gelegentlicher als auch bei häufiger Nutzung eine Fülle von Problemen verursacht. Die neuen Möglichkeiten erfordern einen entsprechend hohen Zusatzaufwand zum Erlenen der Software und zur Umstellung gut etablierter Arbeitsroutinen. In der Konsequenz bedeutet das, auch über Software-Versionen hinweg so stabil wie möglich zu bleiben, also größere Änderungen in Funktionsweisen und in Objektpositionen nur durchzuführen, wenn der Nutzen den entstehenden Produktivitätsverlust aufwiegt.

Eine Möglichkeit, in neuen Versionen geänderte Nutzungsschnittstellen anzubieten, ohne die eigenen, über Jahre aufgebauten Konventionen zu verletzen, folgt dem Prinzip Heterogenität (siehe Heterogenität), indem die alte und die neue Nutzungsform gleichzeitig angeboten werden. Diesen Weg hat auch Microsoft zumindest teilweise gewählt. Zwar ist es in den Office-2007-Programmen nicht mehr möglich, auch die alten Icon-Leisten anzuzeigen (inzwischen ist dies per Customizing möglich), aber die bereits etablierten Tastenkombinationen sind allesamt erhalten geblieben. Einige Jahre vorher beim Übergang von Windows 3.1 zu Windows 95 hat man wohl ähnliche Probleme befürchtet, denn die Art und Weise der Nutzung ist mit der Einführung des Desktops, der Taskleiste und des Startmenüs recht grundlegend geraten. Microsoft hat deshalb auch den ursprünglichen Programm-Manager als weiter bestehende Alternative angeboten.

Fazit

Konventionen sind, wie wir gesehen haben, nicht immer wohl begründet, jedoch sehr wirksam. Sie verkörpern geronnene Anforderungen aus den Anwendungsbereichen der Software, von der Branche über das Computersystem bis hin zur Kultur. Die relevanten Konventionen zu kennen und sich an sie zu halten, ist daher eine wichtige Abkürzung auf dem Weg zu einer gebrauchstauglichen Gestaltung, aber kein Ersatz für eine situative und beteiligungsorientierte Methodik zur Sicherung der Gebrauchstauglichkeit.

Unsere Forderungen und Beispiele zur ergonomischen Gestaltung bietet gewissermaßen das Grundwissen, das weitestgehend unabhängig von spezifischen Einsatzkontexten ist. Die Orientierung auf Gestaltungskonflikte verbindet dieses Wissen mit den Anforderungen der alltäglichen Gestaltungspraxis. Aus diesem Grund haben wir möglichst viele Beispiele aus täglich breit eingesetzten Softwaresystemen genommen, nicht um die Systeme zu bewerten, sondern um alltagsnahe Beispiele zur Illustration von Designkonflikten und den Möglichkeiten und Mitteln ihrer Austarierung genutzt. Mit dem Übergang von der Software-Ergonomie zur Gebrauchstauglichkeit haben wir angedeutet, dass das Verständnis für und das Austarieren von Gestaltungskonflikten auch bei kontextspezifischen Aspekten hilfreich ist.

Sammlungen guter (hall of fame) und auch weniger guter (hall of shame) Beispiele für ergonomische Lösungen und Praktiken ebenso wie lange Listen von Forderungen an die Gestaltung sind zwar praktisch, doch nicht wirklich konstruktiv, weil sich aus einer Sammlung von Einzelaspekten noch keine Orientierung für die Gestaltung ableiten lässt, die es auch gestattet, das Wissen auf neue technische Umgebungen oder neue Gestaltungskonstellationen zu übertragen.

Gewiss ist dieses Wissen sehr begrenzt und deckt nur einen Teil dessen ab, was man für die Gestaltung von Software und ihren Schnittstellen benötigt. Das ist und wird auch weiterhin begrenzt sein, denn einen Blick in die Zukunft ermöglicht auch der von uns vorgestellte Ansatz nicht. Wohl aber bietet die Betrachtung von Gestaltungskonflikten und der sie verursachenden Forderungen einen Rahmen für begründete Gestaltungshypothesen, die ebenfalls eine Abkürzung im Gestaltungsprozess verkörpern, weil eine begründete Hypothese das Explorieren vieler weiterer Lösungsansätze verringern hilft.

Insgesamt können wir konstatieren, dass wir von einer durchgängigen hypothesengeleiteten Technikgestaltung noch weit entfernt sind, hoffen aber, dass der von uns eingeschlagene Weg auch für andere ein hilfreiches Angebot sein kann.