Benennungen in lokalen User Interfaces

Eine bedeutende Rolle spielen sprachliche Elemente in Menüs. Die Norm definiert: „In Menüdialogen bietet das Dialogsystem dem Benutzer eine oder mehrere Optionen an, von denen er eine oder

mehrere auswählen kann, damit der Rechner den gewünschten Prozess ausführt, der durch die Option angezeigt wird.“ (DIN EN ISO 9241-14, 2000). Menüs werden Nutzern in lokalen User Interfaces optisch in Form von Menüleisten mit darunter angeordneten Pull-down-Menüs oder als Kontextmenü angeboten. Menüs sind jedoch nicht zwingend an grafische Oberflächen gebunden.

Untersuchungen mit explizitem Bezug zu sprachlichen Elementen in User Interfaces waren anfangs vorrangig auf die Menüstrukturierung bezogen (vgl. Norman 1991) und klassifizierten Menüelemente nach Handlungsoptionen. In den MS-Office-Produkten findet man verschiedene Arten von Menüs, unterscheidbar nach der Art ihrer Position und ihrem Bezug im Interface (Menüleiste, Drop-down-Menü, Kontextmenü). Eine andere Unterscheidung erfolgt danach, welche Arten von Funktionen angeboten werden. So gibt es unter dem Menütitel Bearbeiten das Aktionsmenü, das operative Funktionen enthält, und unter dem Menütitel Ansicht das Eigenschaftenmenü, welches dem Nutzer deklarative Funktionen anbietet. Diese für eine Standardsoftware entworfene Struktur muss für jede individuell erstellte arbeitsorientierte Applikation sorgfältig entworfen werden. Kent Norman stellte fest, dass jede Basis, also hier ein Arbeitssystem, eine höhere Funktionalität hat als die zu erstellende Applikation und bezieht dies auf Sprache: „Natural language has greater familiarity and functional than computer command language“ (Norman 1991, S.103).

Des Weiteren empfiehlt die Norm, dass Struktur und Syntax eines Menüs einheitlich sein sollten. Für die Anordnung der Optionen in der Menüstruktur wird empfohlen, von der semantischen Struktur auszugehen und mit einzubeziehen, dass erfahrene Nutzer ein räumliches Bild des Menüs haben (vgl.

ebd.). Auch die typografische Gestaltung kann zum räumlichen Verständnis der Menüstruktur beitragen. So wird in den Pull-down-Menüs unter der Menüleiste der MS-Office-Produkte durch die Verwendung unterschiedlicher Symbole visualisiert, was folgt. Für den Fall, dass die Verzweigung in ein weiteres Menü oder eine andere Dialogart erfolgt, ist ein rechtsgerichteter Pfeil hinter dem Menüelement dargestellt; es wird keine Aktion ausgelöst. Eine Verzweigung in einen weiteren Dialog wird mit drei Punkten gekennzeichnet (vgl. DIN EN ISO 9241-14, 2000). In vielen Individualent-wicklungen werden nicht einmal diese grundlegenden Empfehlungen berücksichtigt.

Neben der Anordnung der Menüelemente spielt die Anzahl der Menütitel eine Rolle. So erforschte Ebbinghaus, dass das Kurzzeitgedächtnis ein Fassungsvermögen für etwa sieben Informations-einheiten besitzt (vgl. Ebbinghaus 1885); Miller schrieb 1956 gar von der magischen Zahl Sieben (vgl. Miller 1956). Danach kann der Mensch nur Systeme überblicken, die aus wenigen Teilen bestehen. Etwa sieben (+/- 2) Gegenstände können ohne Problem erfasst werden. Sind es mehr Gegenstände, muss der Mensch sie nacheinander betrachten und ihren Zusammenhang systematisch entwickeln. Jedoch kann man diese Beschränkung durch Bündeln oder Gruppieren von Elementen umgehen, wenn die so neu geschaffenen Elemente wieder als Einzelelemente betrachtet werden.

Hierbei ist dann auch die angemessene Wortwahl von Bedeutung. Die Erkenntnisse wurden auf Menüstrukturen übertragen und haben sich offenbar bis zu heutigen Web-Anwendungen bewährt. So

hat Nielsen ermittelt, dass der Mittelwert der Top-Level-Kategorien bei amerikanischen Intranets bei Sieben liegt (vgl. Nielsen 2007a).

Nun steigt die die Zahl der in User Interfaces angebotenen Funktionen ständig weiter an. Dijkstras Aussage: „I have only a small head, and must live with it“ (Dijkstra 1979) hat schon früh problematisiert, dass zwar die Leistungs- und Speicherkapazität von Rechnern permanent steigt, aber die menschlichen Kapazitäten bleiben wie sie sind. Alle Funktionen einer Anwendung auf einen Blick anzubieten, scheint deswegen nicht ratsam. In komplexen Anwendungen, wie „Maya“, einer profes-sionellen 3D-Animationssoftware (Jurassic Park) mit über 1200 Befehlen, sind deshalb zahlreiche neue Menütechniken (Split-Menü, Fisheye) realisiert (vgl. Hübscher 2002). Auch Microsoft versucht, mit der Multifunktionsleiste (Ribbonbar) im Office-2007-Paket (Abb.22) das Problem in den Griff zu bekommen.

Abbildung 22: Multifunktionsleiste (MS Office 2007)

Hintergrund der Designentscheidung von Microsoft, ein neues GUI-Element zu verwenden, war die ständige Zunahme der Funktionalitäten in den Office-Produkten. So stieg allein die Zahl der Toolbars von MS Word für Windows von zwei in der 1989er Version auf 31 in der Version von 2003. Die Zahl der Menüelemente stieg im selben Zeitraum von ca. 50 auf über 250 an (vgl. Würsten 2008). In der 2003er Version versuchte Microsoft noch, mit der Einführung eines Arbeitsbereichs den Gebrauch der Funktionalitäten zu unterstützen. Ab Version 2007 steht als Ersatz für die bisherige Menüleiste eine Multifunktionsleiste (Ribbonbar) zur Verfügung. Diese ist applikationsabhängig, es gibt keine konsistente Menüführung über alle Programme hinweg. Sie stellt Befehle, unterstützende Funktionen und Optionen nach Aufgaben sortiert zur Verfügung. Der Menütitel Datei, den viele verzweifelte Umsteiger suchen, wird ersetzt durch eine sogenannte „Office“-Schaltfläche. Usability-Unter-suchungen hierzu stehen noch aus.

Eine andere Designentscheidung ist offensichtlich bei SAP gefallen. So verzichtet SAP für so-genannte Mini- und Web-Applikationen zunehmend auf komplexe Screen-Elemente wie Menüleisten oder Verzeichnisbäume, wenn diese nicht unbedingt erforderlich sind. Zwar war diese Idee durchaus umstritten, inzwischen wird aber darin ein großer Nutzen gesehen, weil damit Entwickler gezwungen sind, Funktionalität zu reduzieren (vgl. Waloszek 2000), da sie ein Mehr an Funktionen nicht in immer tiefer verschachtelte Kaskadenmenüs unterbringen können.

Neben den Anforderungen und Empfehlungen zur Gestaltung und Anordnung von Menüoptionen sind in den einschlägigen Normen insgesamt über 700 Empfehlungen zur User-Interface-Gestaltung zu finden. Einige davon mit Bezug zu sprachlichen Elementen. Die Empfehlungen zur Wahl von passen-den Benennungen beziehen sich jedoch nicht auf Fachvokabular, sondern sind eher grammati-kalischer Natur:

ƒ Optionsnamen sollten eine dem Nutzer vertraute Terminologie verwenden.

ƒ Aktionen sollten durch Verben ausgedrückt werden (löschen statt Löschung).

ƒ Objekte sollten als Substantive benannt sein (Ordner).

ƒ Wenn ein Optionsname sowohl eine Aktion als auch ein Objekt repräsentiert, sollte eine Verb-Substantiv-Syntax verwendet werden (delete folder²³)

ƒ Optionsnamen sollten mit dem Wort beginnen, das für die Option am repräsentativsten ist (Schlüsselwort). So sollte der Begriff Systemdokumentationsindex als Menüeintrag Index für Systemdokumente heißen oder statt Bestand alt besser: alter Bestand (vgl. DIN EN ISO 9241-14, 2000).

ƒ Bildschirmelemente (Felder, Icons, Grafiken etc.) sind mit Bezeichnung zu versehen, wenn diese nicht offensichtlich erkennbar sind (bei Platzmangel auch als QuickInfo möglich).

ƒ Bezeichnungen sollten Zweck und Inhalt der jeweiligen Informationseinheit wiedergeben.

ƒ Platzierung der Bezeichnung nah an der Informationseinheit (z.B. Feldbezeichnungen links vom Eingabefeld, Bezeichnungen für Optionsfelder rechts davon).

ƒ Optische Trennung von Bezeichnung und bezeichneter Information.

ƒ Formate und Ausrichtungen konsistent verwenden.

ƒ Maßeinheiten entweder neben die Bezeichnung oder neben das Eingabefeld positioniert (z.B.

entweder Entfernung (km) 1,5 oder Entfernung: 1,5 (km). (vgl. DIN EN ISO 9241-12, 2000).

Des Weiteren wird empfohlen, Wörter des üblichen Sprachgebrauchs nicht durch neuartige, differen-zierende Definitionen zu ersetzen und nicht aussagekräftige Wortverlängerungen (Suffixe) zu vermei-den. (Das Suffix -nummer oder -name ist oft überflüssig. Suffixe wie -schlüssel und -kennzeichen sollten nur dann benutzt werden, wenn sie für das Verständnis des Feldes notwendig sind (vgl. DIN EN ISO 9241-14, 2000).

Auch die Anforderungen an die statische Informationsdarstellung liefern Hinweise für die Benen-nungsfindung:

ƒ Klarheit: Der Informationsinhalt wird schnell und genau vermittelt.

ƒ Unterscheidbarkeit: Die angezeigte Information kann genau unterschieden werden.

ƒ Kompaktheit: Den Nutzern wird nur jene Information gegeben, die für das Erledigen der Aufgabe notwendig ist.

23 In der deutschen Normfassung von 1999 findet sich dieses englische Beispiel, was sich nicht problemlos ins Deutsche übertragen lässt.

ƒ Konsistenz: Gleiche Information wird innerhalb der Anwendung entsprechend den Erwar-tungen des Nutzers stets auf die gleiche Art dargestellt.

ƒ Erkennbarkeit: Die Aufmerksamkeit des Nutzers wird zur benötigten Information gelenkt.

ƒ Lesbarkeit: Die Information ist leicht zu lesen.

ƒ Verständlichkeit: Die Bedeutung ist leicht verständlich und eindeutig interpretierbar.

(vgl. DIN EN ISO 9241-12, 2000).

Neben den statischen Kriterien sind die dynamischen Dialogkriterien für Benennungen bzw.

sprachliche Elemente auf Interfaces anwendbar. Im Folgenden sind von den sieben Grundsätzen der Dialoggestaltung, wie sie in der DIN EN ISO 9241-110, 2006 definiert sind, vier benannt, die einen engen Bezug zu sprachlichen Elementen haben. So ist für eine aufgabenangemessene User-Inrterface-Gestaltung die Verwendung von aufgabenangemessenen Benennungen erforderlich. Diese ergeben sich aus dem jeweiligen Fachvokabular und der Terminologie. Auch der Aufbau der Menü- bzw.

Navigationsstruktur sollte der Fachlogik entsprechen. Angemessen sind dabei auch im Fachgebiet gängige Abkürzungen oder Anglizismen.

Zu einem selbstbeschreibenden User Interface gehören handlungsleitende Informationen, Rück-meldungen und Zustandsinformationen. Bezeichnungen in einer zugehörigen Benutzeranleitung oder der Online-Hilfe sollten den Bezeichnungen im User Interface entsprechen.²⁴ Eine Anwendung für die Abwicklung von Bankgeschäften muss erwartungskonfom bankenübliche Begriffe wie Überweisung und Girokonto nutzen. Für internationale Nutzer einer Anwendung mit Kreditkartenzahlung ist es erwartungskonform wenn die Eingabefelder zur Angabe des vollständigen Eigennamens eher mit Nachname und Vorname als mit Name und Rufname bezeichnet sind. (Fach-) bekannte Begriffs-hierarchien sollten berücksichtigt werden. Benennungen für Aktionen, die durch Nutzer ausgelöst werden können, sind konsistent zu verwenden. So ist für Schaltflächen statt des wenig handlungs-leitenden OK eher die Benennung Ja und Nein zu empfehlen. Um die Erlernbarkeit zu unterstützen sollen Rückmeldungen und Erläuterungen den Nutzer dabei unterstützen, ein konzeptionelles Verständnis vom interaktiven System zu bilden. Dazu ist auch die konsistente Verwendung von Begriffen notwendig. So sollte ein Rückmeldungstext nicht vorgefertigtes Vokabular verwenden (Vorgang gespeichert) sondern spezifisch auf die Arbeitsaufgabe bezogen sein (Antrag wurde gespeichert).

Neben den statischen und dynamischen Kriterien zur Dialoggestaltung gibt es normative Empfeh-lungen zur „Benutzerführung“. Unter Benutzerführung werden alle zusätzlichen über den regulären Benutzer-Computer-Dialog hinausgehenden Informationen verstanden, die entweder auf Verlangen des Nutzers oder automatisch vom System angezeigt werden (vgl. DIN EN ISO 9241-13, 2000).

Hierzu gehören folgende Hinweise zur sprachlichen Qualität:

24 Dies gilt auch für die Bezeichnung von Hardware-Bestandteilen wie der Tastatur von Mobiltelefonen. Ausführliche Hinweise dazu finden sich in ISO IEC 25051, 2006 und DIN EN 62079, 2001.

ƒ Die Benutzerführung sollte eine Terminologie verwenden, die den Nutzern bei der Erledi-gung der Arbeitsaufgabe sowie der Kontrolle der Anwendung und des Systems geläufig ist.

ƒ Das Ergebnis einer Aktion sollte angegeben werden, bevor beschrieben wird, wie die Aktion ausgeführt wird. Also statt: Drücken Sie OK, um alle Daten zu löschen besser: Wollen Sie wirklich alle Daten löschen?

ƒ Texte in Frageform sollten positiv bestätigend formuliert sein. Also statt: Wollen Sie die Daten nicht sichern? besser: Wollen Sie die Daten sichern?

ƒ Meldungen in der Benutzerführung sollten grammatisch einheitlich formuliert werden.

Statt Datei zeigen, Datei drucken, Löschung einer Datei untereinander anzuzeigen, besser:

Zeige Datei, Drucke Datei, Lösche Datei.