Diplomarbeit
 HTML-Version
 HTML (eine Datei 300 Kb)
 PDF-Version
 

Links
 Startseite
 Empfohlene Seiten

Suchportale Campingplätze in Deutschland bei Campingplatz-suchen.de

Reiterhöfe in Deutschland bei Reiterhof-suchen.de

3 Design ergonomischer Oberflächen

Unter dem Design ergonomischer Oberflächen wird sowohl die Analyse als auch der Entwurf einer Benutzungsschnittstelle verstanden. Design und Evaluation einer Oberfläche stellen mit ca. 50 Prozent einen gewichtigen Anteil am gesamten Softwareentwicklungsprozeß dar.

Der Prozess der Oberflächenentwicklung gestaltet sich grundsätzlich in iterativer Art und Weise (vgl. [Prei99] S. 5f). Dies unterscheidet ihn von dem typischerweise phasenorientierten Software Engineering. Es ist nahezu unmöglich, beim ersten Versuch ein annehmbares Ergebnis zu erzielen. Das größte Problem besteht darin, dass sich die Anforderungen während der Entwicklung verändern. So können Benutzbarkeitsprobleme oft erst erkannt werden, wenn für die zu lösende Aufgabe auch ein Prototyp zur Verfügung steht. Eine weitere Ursache liegt in der Vielfalt der Aspekte, die eine Benutzungsschnittstelle beeinflussen. Diese besteht nicht nur aus visuellen Elementen, die auf dem Bildschirm angezeigt werden. Leistungsfähigkeit, Sicherheit, Unterstützung durch Hilfesysteme, Individualisierung, Organisation der Informationen oder Mehrsprachigkeit sind weitere Gesichtspunkte, die beachtet werden müssen. Die Besonderheiten des Entwicklungsprozess für Benutzungsschnittstellen haben zu dem von Nielsen geprägten Begriff Usability Engineering geführt. Ein so ausgerichteter Softwareentwicklungsprozeß stellt sich das Ziel, durch ergonomisches Design Effektivität bei höchstmöglicher Effizienz und Benutzerzufriedenheit zu gewährleisten. Usability Engineering ist durch einen engen Kontakt von Benutzern und Entwicklern charakterisiert. Typisch ist auch die Verwendung von Werkzeugen, um das Prototyping zu beschleunigen.

3.1 Usability Design

Die wörtliche Übersetzung von Usability ist Benutzbarkeit. Die DIN neigt jedoch dazu, dieses Wort mit Gebrauchstauglichkeit zu übersetzen (vgl. [Dzid94] S. 387). Im folgenden Beitrag werden beide Varianten synonym gebraucht. Die ISO definiert Gebrauchstauglichkeit als "das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen." ([ISO9241-11] S. 4) Der Nutzungskontext definiert die Benutzer, Arbeitsaufgaben, Arbeitsmittel (Hardware, Software und Materialien) sowie die physische und soziale Umgebung, in der das Produkt genutzt wird. Nielsen nennt fünf Eigenschaften von Softwaresystemen, die entscheidend die Benutzbarkeit beeinflussen. Dazu gehören Erlernbarkeit, Effizienz, Wiedererkennbarkeit, Fehlerbehandlung und Benutzerzufriedenheit (vgl. [Niel93] S. 26).

Beurteilt wird das Anwendungssystem von dem Benutzer mit seinen individuellen Bedürfnissen. Er spielt demzufolge die zentrale Rolle bei der Betrachtung der Gebrauchstauglichkeit. Aus diesem Grund schlägt die ISO 13407 einen benutzerorientierten Gestaltungsprozess vor. Dieser ist eine Art der Entwicklung interaktiver Systeme, die sich darauf konzentriert, Systeme gebrauchstauglich zu machen (vgl. [ISO13407] S. 2). Obwohl in der Norm explizit darauf hingewiesen wird, kann der Begriff "benutzerorientiert" fälschlicherweise so verstanden werden, lediglich die Belange des Benutzers zu berücksichtigen (vgl. Burm+00] S. 54). Aus diesem Grund wird synonym auch von der benutzerzentrierten Softwaregestaltung gesprochen, die eine aktive Einbeziehung des Benutzer klarer ausdrückt.

Der Gestaltungsprozess beginnt mit der Feststellung für die Notwendigkeit des benutzerorientierten Ansatzes. Steht Ausmaß und Umfang fest, kann ein interdisziplinäres Gestaltungsteam zusammengestellt werden, welches aus DV-Verantwortlichen, Entwicklern und Endbenutzern besteht. Dieses Team bleibt für die gesamte Projektdauer zusammen. Wurde ein der Größe des Projektes angepasstes Team gebildet, können die vier benutzerorientierten Gestaltungsaktivitäten durchlaufen werden (vgl. Anhang A.8). Im ersten Schritt wird der Nutzungskontext identifiziert (vgl. [ISO13407] S. 6ff). Dabei werden die Benutzermerkmale, Arbeitsaufgaben und die organisatorische und physische Umgebung analysiert. Abschnitt 3.2 beschäftigt sich mit diesen Aktivitäten eingehend. Im anschließenden zweiten Schritt werden daraus die Benutzeranforderungen und die organisatorischen Anforderungen abgeleitet. Das IEEE fordert, dass die Anforderungsspezifikation abstrakt, eindeutig, nachvollziehbar und überprüfbar ist. (vgl. Burm+00] S. 55). Das Entwerfen der Gestaltungslösungen ist Inhalt des dritten Schrittes. Er stellt die komplexeste Phase dar. Dabei können die Anforderungen mit Hilfe von Simulationen, Modellen oder Prototypen konkretisiert werden. Die Abschnitte 3.3 und 3.4 unterstützen bei der Grobgestaltung, zu der Navigationsstruktur und Informationspräsentation gehören. Für die Entwicklung von geeigneten Metaphern kann zusätzlich der Abschnitt 2.3 zu Rate gezogen werden. In der Feingestaltung werden grafische Gestaltung und Interaktionsverhalten bis ins Detail ausgestaltet. Dabei werden die in Kapitel 4 genauer betrachteten Style Guides verwendet. Der vierte Schritt des Gestaltungsprozesses besteht in der Beurteilung der Gestaltungslösungen gegenüber den Anforderungen. Die Beurteilung bzw. Evaluierung wird ausführlich in Kapitel 5 beschrieben. Sind die Anforderungen nicht erfüllt, wird erneut der erste Schritt des benutzerorientierten Ansatzes ausgeführt. Praktische Erfahrungen haben gezeigt, dass vor allem bei den ersten Iterationen erhebliche Verbesserungen der Gebrauchstauglichkeit zu erwarten sind. Der Gestaltungsprozess sollte mindestens eine Iteration aufweisen, wobei eine Zweite wünschenswert ist. Erfüllt die Gestaltungslösung die Anforderungen, so ist die Entwicklung abgeschlossen. Die ISO 13407 bietet im Anhang Formulare an, die bei der praktischen Umsetzung der vier Aktivitäten genutzt werden können. Die Norm berücksichtigt auch, dass bestimmte Benutzbarkeitsprobleme erst während der Anwendung über einen längeren Zeitraum erkannt werden können. Sie fordert daher Pläne und Verfahren für die Langzeitbeobachtung (vgl. [ISO13407] S. 9). So können durch eine Hotline oder eine Seite im Internet dem Benutzer Möglichkeiten zur Rückmeldung gegeben werden.

Wie bereits beschrieben, besteht der erste Schritt im benutzerorientierten Gestaltungsprozess aus der Identifikation von Aufgaben, Benutzern und Umgebung.

3.2 Aufgaben und Benutzeranalyse

Die Analyse von Benutzern und Aufgaben, ist eine zentrale Voraussetzung um eine ergonomische Oberfläche zu entwickeln. Ebenso entscheidend sind organisatorische und ökonomische Rahmenbedingungen. Dieser zweite Bereich wird an dieser Stelle nicht genauer betrachtet.

Eine 1997 durchgeführte Studie ergab, dass etwa 60 Prozent aller Benutzbarkeitsprobleme darauf zurückgehen, dass der Dialogablauf nicht dem Arbeitsablauf entspricht. Das heißt, dass die Benutzungsschnittstelle nicht optimal an die zu lösende Aufgabe angepasst ist (vgl. [GeHa98] S. 169). Inkonsistenz ist für 25 Prozent und Unübersichtlichkeit der Dialogelemente für 15 Prozent der Probleme verantwortlich. Der Entwicklungsprozess einer ergonomischen Oberfläche muss demzufolge mit einer Aufgabenanalyse beginnen.

3.2.1 Aufgabenanalyse

Dieser Arbeitsschritt wird im allgemeinen Softwareentwicklungsprozeß als Anforderungsanalyse bezeichnet. Im Bereich der Oberflächenentwicklung spricht man jedoch von der Aufgabenanalyse (vgl. [Olse98] S. 18). Das Ziel besteht darin, zu erkennen, was der Benutzer mit dem Anwendungssystem erreichen möchte, welche Strategien und Techniken er dabei benutzt und welche Informationen er für ihre Realisierung benötigt.

Da Benutzer und Softwareentwickler zwei verschiedene "Sprachen" sprechen, ist es wichtig, am Anfang des Projektes eine gemeinsame Kommunikationsbasis zu bilden (vgl. [Prei99] S. 210ff). Der Entwickler muss sich mit dem Handlungsumfeld des Benutzers beschäftigen, um einen Einblick in das Fachgebiet zu bekommen. Anschließend sollten Definitionen der verschiedenen Fachbegriffe aufgestellt werden. Sprechen beide Seiten die gleiche "Sprache", kann mit der systematischen Informationssammlung über die zu unterstützenden Aufgaben begonnen werden.

Für die Informationserfassung gibt es verschiedene Möglichkeiten. Die einfachste ist die Beobachtung. Für sie wird keine Vorbereitungsphase benötigt. Ebenfalls positiv ist der persönliche Kontakt zwischen beiden Parteien. Fragebögen und persönliche Interviews bieten die Möglichkeit, eine Vielzahl von Benutzern in die Analyse mit einzubinden. Allerdings muss bei diesen beiden Techniken mit einer größeren Vorbereitungszeit gerechnet werden. Fragebögen eignen sich insbesondere zur statistischen Auswertung. Ein Nachteil sind die unter Umständen langen Rücklaufzeiten. Im Ergebnis der Informationssammlung sollte der Entwickler wissen, welche Aufgaben existieren, wie sie bisher gelöst wurden, welche Probleme dabei auftreten und wie sich der Benutzer zukünftige Lösungen vorstellt. Anschließend sollte der Prozess der Aufgabenzerlegung beginnen. Shneiderman weißt auf dabei auftretende Schwierigkeiten hin. Werden zu kleine Teilaufgaben gebildet, können Benutzer durch die Vielzahl durchzuführender Aktionen bei der Aufgabenerledigung frustriert werden (vgl. [Shne98] S. 70). Sind die Teilaufgaben zu komplex, werden viele spezielle Optionen benötigt, die den Benutzer verwirren können. Im Anschluss an die Informationssammlung sollten Aspekte der Reihenfolge, Dauer und Häufigkeit einzelner Teilaufgaben bekannt sein. Ebenso wichtig ist eine Unterscheidung in kritische und unkritische Aufgaben. Kritische Aufgaben sind solche, welche bei fehlerhafter Ausführung entscheidend den Arbeitsablauf negativ beeinflussen. Bekannt ist auch, welche Informationen für die Aufgabenerledigung obligatorisch oder optional sind.

Im nächsten Schritt der Aufgabenanalyse werden Sequenzen von Handlungsschritten entworfen. Dabei ist zu definieren, welche Informationen vom Benutzer benötigt werden, welche das System liefern kann und welche Informationen an den Benutzer zurückgegeben werden müssen. Orientierungshilfen sind die oben genannten Aspekte. Häufig auftretende Handlungen sollten besonders schnell erreichbar sein. Bei ihnen ist auch auf eine angemessene Leistungsfähigkeit des Softwaresystems zu achten. Bei jeder Sequenz ist zu analysieren, ob Komplikationen auftreten können und welche Maßnahmen in diesem Fall einzuleiten sind. Mit diesem Wissen können bereits Aussagen über die zu verwendenden Interaktionsformen (vgl. Abschnitt 3.4.2) getroffen werden.

Den Abschluss der Aufgabenanalyse bildet die Auswertung. Bis zu diesem Punkt wurde die Aufgabenanalyse darauf beschränkt, den bisherigen Ablauf zu erfassen. Die Einführung eines neuen Softwaresystems sollte jedoch als Anlass genommen werden, Verbesserungsmöglichkeiten zu erkennen und einzuführen. In den seltensten Fällen ist die Art und Weise, wie die Aufgaben bisher erledigt wurden, optimal. Vor allem die Benutzer, als Experten auf ihrem Gebiet, können dabei wichtige Anstöße geben. Die erweiterten Möglichkeiten, die ein Softwaresystem bieten kann, beispielsweise der Einsatz von leistungsstarken Datenbanken, müssen dem Benutzer jedoch dargeboten werden. Werden diese neuen Techniken eingesetzt, ist eine qualitativ bessere Lösung der Aufgabenerledigung möglich.

3.2.2 Benutzeranalyse

Kontakt zu den Benutzern eines Systems aufzubauen, ist für die Entwicklung von ergonomischen Benutzungsschnittstellen von großer Bedeutung. Nur dadurch kann eine angemessene Benutzeranalyse durchgeführt werden. Dabei muss zwischen Auftraggebern, d.h. dem Kunden und den Benutzern unterschieden werden. Zur Verdeutlichung wird deshalb auch von den Endbenutzern gesprochen (vgl. [Prei99] S. 214f). Um die Aufgaben genau zu analysieren müssen die Benutzer des Systems eingebunden werden. Sie kennen nicht nur die Abläufe und Ergebnisse, sondern vor allem die praktischen Probleme bei der Bewältigung der Aufgaben. Demgegenüber stehen die Auftraggeber. Sie können die Aufgaben des Anwendungssystems definieren, wissen jedoch weniger über die praktische Umsetzung. Doch vor allem die Betrachtung von Details führt zu einer ergonomischen Oberfläche. Außerdem hat die Einbeziehung der Benutzer einen wichtigen Nebeneffekt. Wie in der Organisationslehre herausgearbeitet wurde, können Individuen Veränderungen gegenüber ablehnend reagieren. Werden die Benutzer aktiv in den Entwicklungsprozess einbezogen und können das System mit gestalten, sinkt diese ablehnende Haltung. Ihre u.U. vorhandenen Ängste werden dadurch abgebaut. Wird das nicht beachtet, kann das im schlimmsten Fall zum Boykott und damit zum Scheitern des Projektes führen.

Benutzer unterscheiden sich in einer Vielzahl von Eigenschaften. Dazu zählen Alter, Geschlecht, physische Fähigkeiten, Ausbildung, kultureller und ethnischer Hintergrund, Motivation, Ziele und Persönlichkeit, um nur einige zu nennen (vgl. [Shne98] S. 67f). Diese verschiedenen Voraussetzungen müssen im Anwendungssystem berücksichtigt werden, um für alle Benutzer eine ergonomische Oberfläche anbieten zu können. Eine sorgfältige Analyse führt zur Bildung von Benutzergruppen. Übliche Einteilungen gliedern sich beispielsweise in Anfänger, erfahrene Benutzer und Experten. Eine Klassifikationen nach der Arbeitsaufgabe kann beispielsweise die drei Gruppen Lehrling, Sachbearbeiter und Abteilungsleiter ergeben. Ziel ist es, möglichst viele heterogene Individuen in homogene Gruppen einzuordnen. Die Auswahl der Kriterien hängt von dem konkreten Anwendungsfall ab. Sinnvolle Unterscheidungsmerkmale sind zum Beispiel Ziele oder die Fähigkeiten und Erfahrungen des Benutzers mit dem Anwendungsgebiet. Die Ermittlung der verschiedenen Gruppen kann ähnlich wie bei der Aufgabenanalyse mit Hilfe von Interviews und Fragebögen oder durch Beobachtung erfolgen. Hix und Hartson weisen darauf hin, dass vor allem die Beobachtung der Benutzer geeignet ist (vgl. [HiHa93] S. 128). Jede der identifizierten Benutzergruppen hat verschiedene Anforderungen an das Anwendungssystem. Da aus ökonomischen Überlegungen heraus nicht alle realisierbar sind, müssen im Vorfeld der Entwicklung Prioritäten gesetzt werden. Im allgemeinen wird man die meisten Zugeständnisse der Benutzergruppe mit den meisten Mitgliedern machen. Ein anderes Kriterium ist die Dauer bzw. Häufigkeit der Nutzung des Anwendungssystems.

Die Bildung von Benutzergruppen kann als Ausgangspunkt der Erstellung von Benutzermodellen angesehen werden. Ein Benutzermodell enthält explizite Annahmen über einen konkreten Benutzer, die es ermöglichen, dass das System auf diesen Benutzer zugeschnitten wird (vgl. [Prei99] S. 466). Die Annahmen bestehen im einfachsten Fall aus Attributen mit entsprechenden Werten. Die Erstellung und Verwaltung von Benutzermodellen durch das Anwendungssystem ist die Grundvoraussetzung für adaptive Systeme.

Die folgenden Ausführungen sollen den Sachverhalt verdeutlichen. Betrachtet man die zu lösende Aufgabe als Anwendungsbereich A, so kann S(A) als Anwendungssystem bzw. die Implementierung des Anwendungsbereiches bezeichnet werden (vgl. [Herc94] S. 18f). Das mentale Modell des Benutzers vom Anwendungsbereich wird durch B(A) beschrieben. Das Benutzermodell S(B(A)) ist somit das Modell des Systems vom mentalen Modell des Benutzers. Eine Inkompatibilität zwischen S(A) und B(A) führt bei der späteren Nutzung des Anwendungssystems zu Problemen. Diese Inkompatibilität resultiert im allgemeinen aus einem unzulänglichen Modell des Entwicklers vom mentalen Modell des Benutzers E(B(A)), kurz einer unzureichenden Benutzeranalyse.

3.3 Gestaltungsgrundsätze für Dialoge

Unter dem Dialog zwischen Mensch und Maschine wird der wechselseitige Informationsaustausch zur Erfüllung einer Aufgabe verstanden (vgl. [Geis90] S. 141). Den hier betrachteten Dialog eines Anwendungssystems kann man als zielorientierte Interaktion zwischen Benutzer und Dialogsystem definieren. D.h., dass eine Benutzungsschnittstelle aus mindestens einem, meist aber aus mehreren Dialogen besteht. Die Initiative für den Informationsaustausch kann sowohl vom Menschen als auch von der Maschine ausgehen und kann während des Dialogverlaufes wechseln. Ziel des Dialoges ist eine Benutzerführung. Der Anwender soll bei der Erledigung seiner Aufgabe unterstützt werden. Ein guter Dialog vermeidet dabei jegliche Über- oder Unterforderung des Menschen. Die vorher durchgeführte Benutzeranalyse hilft bei der Umsetzung dieser Forderung. Ein Dialog sollte selbsterklärend sein (vgl. Abschnitt 3.3.2). D.h., dass der Anwender den Dialog selbstständig, ohne fremde Hilfe benutzen kann. Das bedeutet jedoch nicht, dass auf die Einführung eines Anwendungssystems, die mit einer Schulung verbunden sein kann, verzichtet werden darf. Weiterhin ist durch die Dialoggestaltung sicherzustellen, dass das System vom Benutzer akzeptiert wird. Die Anpassung des Dialoges an die Fähigkeiten des Benutzer sollte ebenso möglich sein (vgl. Abschnitt 3.3.6). Diese kann entweder durch den Benutzer erfolgen, oder durch das System automatisch vorgenommen werden.

Um einen Dialog nach seiner Brauchbarkeit zu bewerten, werden angemessene Kriterien benötigt. Benutzungsschnittstellen sind jedoch "sehr inhomogene und vieldimensionale Gebilde, die sich weitgehend einer direkten, objektiven Messung entziehen." ([Herc94] S. 104) Dennoch gibt es eine Reihe von Merkmalen, die eine Bewertung ermöglichen. Die ISO 9241 definiert sieben Grundsätze der Dialoggestaltung (vgl. [ISO9241-10]). Diese sind nicht unabhängig voneinander. So kann es nötig sein, Vorteile des einen Grundsatzes gegenüber denen eines anderen abzuwägen. Im folgenden werden die Grundsätze einzeln beschrieben.

3.3.1 Aufgabenangemessenheit

Die ISO 9241-10 definiert einen Dialog als "aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen." ([ISO9241-10] S. 4)

Ein Dialog sollte nur die Informationen anzeigen, die für die zu erledigende Aufgabe relevant sind. Damit soll eine Reizüberflutung des Benutzers vermieden. Entwickler bieten oft überflüssige Informationen an, weil beispielsweise die bei der Programmierung verwendete Komponente diese Funktionalität bietet. Die Frage, ob damit die Erledigung der Arbeitsaufgabe erleichtert wird, wird oft nicht gestellt. Die Darstellung der Informationen muss dabei an die Arbeitsaufgabe angepasst werden. So sollten beispielsweise lange Listen nach Vorgabe des Benutzer sortiert werden können. Die Anzeige der Genauigkeit von Zahlen wird nicht von den technischen Möglichkeiten sondern von der Aufgabe vorgegeben. Aufgabenangemessenheit bedeutet auch, dass das Dialogsystem automatisierbare Arbeitsschritte auch selbständig ausführt. So können Positionsmarken im vorhinein sinnvoll platziert werden oder Startprozeduren automatisch vom System ausgeführt werden. Bei der Dialoggestaltung ist sowohl der Grad an Komplexität der Aufgabe als auch die Qualifikation des Benutzers zu beachten. So müssen beispielsweise bei komplizierten Aufgaben die Hilfetexte entsprechend umfassend die einzelnen Teilprobleme erläutern. Die auf Verlangen des Benutzer angezeigte Hilfe sollte sich mit der gegenwärtig zu bearbeitenden Aufgabe beschäftigen. Innerhalb des Hilfesystems kann dann der Benutzer zu anderen Themenbereichen navigieren (vgl. Abschnitt 3.4.6). Eine weitere Forderung besteht in der Vorgabe von Standardwerten. Diese müssen sinnvoll ausgewählt und durch den Benutzer veränderbar sein. Vor allem bei Datumseingaben tritt häufig der Fall auf, dass das aktuelle Datum eingegeben werden muss. Das Eingabefeld kann in diesem Fall vom Anwendungssystem gefüllt werden. Enorme Zeiteinsparungen lassen sich auch erreichen, wenn häufig wiederkehrende Aufgaben speziell behandelt werden können. Es sollte möglich sein, diese zu automatisieren und damit zu beschleunigen. Im allgemeinen wird das durch den Einsatz von Makros realisiert (vgl. Abschnitt 3.4.8). Werden während der Erledigung einer Aufgabe Daten geändert, sollte dem Benutzer möglich sein, die ursprünglichen Daten wieder herzustellen. So kann beispielsweise die Eingabe in einem Textfeld durch Drücken der Taste ESC wieder zurück gesetzt werden. Deutlich mächtiger als dieser einfache Mechanismus ist eine Undo-Funktion, die ganze Dialogschritte rückgängig machen kann (vgl. Abschnitt 3.3.3). Die letzte Forderung besteht in der Vermeidung unnötiger Arbeitsschritte. So kann beispielsweise das Drucken und Schließen einer Rechnung in einem Schritt durchgeführt werden.

Die Effizienz des Dialoges hängt entscheidend von der Anpassung des Systems an die Aufgabe ab. Die in Abschnitt 3.2.1 beschriebene Aufgabenanalyse ist dafür die Voraussetzung. Die benutzergerechte Gestaltung kann mit der Anpassung an die Aufgabe konkurrieren. In diesen Fällen muss ein Kompromiss gefunden werden.

3.3.2 Selbstbeschreibungsfähigkeit

"Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird." ([ISO9241-10] S. 5)

Diese Erläuterungen stellen eine Ergänzung der vorher durchgeführten Benutzerschulung dar, keinen Ersatz. Hilfetexte sollen es dem Benutzer erleichtern, sich schnell und problemlos ein mentales Modell des Anwendungssystems aufzubauen. Die Erläuterungen müssen den Kenntnissen des Benutzer angepasst sein. So kann vor allem bei Anfängern die Darstellung von Beispielen hilfreich sein. Die Texte sollten sowohl die Muttersprache des Anwenders als auch die Fachbegriffe des Arbeitsgebietes verwenden. Ein Dialogsystem sollte nach jeder Handlung des Benutzers eine Rückmeldung geben. Wird vom Benutzer ein Arbeitsschritt initiiert, der schwerwiegende Folgen haben kann, sollte zuvor eine Bestätigung verlangt werden. Dabei sollte der Benutzer die Möglichkeit haben, sich dazugehörige Erläuterungen anzeigen zu lassen. Das Dialogsystem sollte sicherstellen, dass der Benutzer immer über den gegenwärtigen Dialogzustand informiert ist. Dazu gehört beispielsweise ein Überblick über vergangene und zukünftige Dialogschritte. Wird eine Eingabe verlangt, sollten dem Benutzer Informationen darüber angezeigt werden. Ein Beispiel ist die Anzeige des erwarteten Formates. Das Hilfesystem (vgl. Abschnitt 3.4.6) sollte die Erläuterungen kontextabhängig anbieten. Das bedeutet, dass in Abhängigkeit der aktuellen Dialogsituation ein an den Anwendungszustand orientierter Text angeboten wird. Merkmale der Dialogsituation stellen beispielsweise das ausgewählte Fenster, der Eingabefokus, oder der aktuelle Bearbeitungsschritt der Aufgabe dar. Hilfetexte können aktive oder passiv sein. Ersteres bedeutet, dass der Benutzer die Initiative übernimmt und durch eine entsprechende Eingabe die Anzeige von Erläuterungen fordert. Aktive Hilfe sind automatisch vom System angebotene Erläuterungen. Ein Beispiel wäre die Anzeige eines Hilfetextes nach einem Eingabefehler.

3.3.3 Steuerbarkeit

"Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist." ([ISO9241-10] S. 6) Das heißt, dass die Kontrolle, soweit es die Aufgabe zulässt, beim Benutzer liegen soll. Parallel durchführbare Aufgaben müssen auch gleichzeitig abzuarbeiten sein. Das System sollte in mehrere unterbrechbare und wieder fortsetzbare Teildialoge gegliedert werden. Auf modale Dialoge, die einen Wechsel in einen anderen Dialog ohne vorherige Beendigung verhindern, sollte beim Systementwurf verzichtet werden. Ausgeschlossen sind kritische Vorgänge, wie zum Beispiel Fehlermeldungen. Bei Systemen mit hohem Sicherheitsbedürfnis ist ebenfalls von zu großer Freiheit für den Benutzer abzusehen und ein systemgesteuerter Dialog vorzuziehen. Die Geschwindigkeit des Dialoges sollte dem Benutzer nicht vorgeschrieben werden. So wird beispielsweise das Ende der Eingabe in einem Feld mit der Taste ENTER durch den Benutzer signalisiert. Der Benutzer sollte selbst die Interaktionsform auswählen können (vgl. Abschnitt 3.4.2). So bevorzugen Anfänger beispielsweise die Funktionsauswahl über Menüs, während Experten lieber Kommandos verwenden. Die ISO 9241 subsumiert unter dem Begriff Steuerbarkeit auch die Forderung nach Stornierbarkeit von Aktionen. Es sollte wenigstens der letzte Dialogschritt, soweit seine Folgen reversibel sind, zurückgenommen werden können. Diese Technik wird als Undo bezeichnet. Durch die Möglichkeit die letzte Aktion rückgängig zu machen, wird der Anwenders angeregt, das Anwendungssystem zu explorieren. Die Angst, einen Fehler zu begehen wird entscheidend gesenkt. Soweit möglich sollte das System nicht nur für den letzten, sondern für alle gemachten Schritte ein Undo ermöglichen. Möchte der Benutzer etwas ausprobieren, ist meist eine gewisse Anzahl von Arbeitsschritten notwendig, um das Ergebnis zu erhalten. Wird diese Technik unterstützt, sollte die direkte Wahl des entsprechenden Undo-Schrittes möglich sein, um mehrere Arbeitsschritte auf einmal rückgängig zu machen. Da sich der Benutzer nur bis zu einen gewissen Grad die letzten Aktionen merken kann, muss in diesen Fällen die Anzeige der Schritte auch eine kurze Erläuterung beinhalten. Die Rücknahme einer Undo-Operation wird mit Redo bezeichnet.

3.3.4 Erwartungskonformität

"Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z. B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen." ([ISO9241-10] S. 6)

Während sich die Erfahrungen des Benutzers bei der Arbeit mit dem System immer mehr ausweiten, schränkt sich die Menge der Erwartungen immer mehr ein. Stimmen die Erwartungen des Benutzers mit dem tatsächlichen Systemverhalten überein, so ist das Anwendungssystem konsistent. Dazu sollte Dialogverhalten und Informationsdarstellung innerhalb des Dialogsystems einheitlich sein. Hierbei helfen sowohl der Einsatz von Standardkomponenten als auch Style Guides. Eine Änderung des Dialogzustandes sollte auf einheitliche Weise herbeigeführt werden. Dazu zählen der einheitliche Aufruf des Hilfesystems oder der Abbruch eines Dialogs mit der Taste ESC. Der Einsatz eines einheitlichen, dem Benutzer vertrauten Wortschatzes steigert nicht nur die Selbstbeschreibungsfähigkeit sondern auch die Erwartungskonformität. Die Gestaltung von ähnlichen Aufgaben sollte immer gleich sein. Damit kann der Benutzer ein bekanntes Verfahren leicht abgewandelt wieder einsetzen. Zusätzlich ist ein hoher Grad an Konsistenz von Bedeutung, da er das Lernen vereinfacht und unnötige Belastungen für den Benutzer vermeidet. Es lassen sich drei Arten von Konsistenz unterscheiden (vgl. [Herc94] S. 112). Die Einheitlichkeit der Dialoge innerhalb einer Anwendung wird als innere Konsistenz bezeichnet. Sie muss durch den Dialogentwickler sichergestellt werden. Dabei haben Verwendung, Positionierung, Farbe und Verhalten von Bildschirmelementen einen großen Einfluss. Die äußere Konsistenz beschreibt die Einheitlichkeit von Dialogen verschiedener Anwendungssysteme. In diesem Bereich wirken die Richtlinien und Techniken des zugrunde liegenden Betriebssystems unterstützend. Die metaphorische Konsistenz beschreibt die Einheitlichkeit der Dialoge mit der realen Arbeitswelt (vgl. Abschnitt 2.3). Insbesondere die Aufgabenanalyse hilft dabei, eine entsprechende Metapher zu entwickeln.

3.3.5 Fehlertoleranz

"Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann." ([ISO9241-10] S. 7)

Fehler und Probleme im Umgang mit Software treten alltäglich auf. Etwa 10 Prozent der Computerarbeitszeit verbringen Benutzer damit, diese zu bewältigen (vgl. [Kens+95] S. 217). Damit stellen sie nicht nur eine zusätzliche Belastung für den Benutzer dar, sondern verursachen ferner für das Unternehmen hohe Kosten. Fehler sind immer vom aktuellen Arbeitskontext abhängig und bedürfen daher spezifischer Behandlung. Syntaktische Fehler sind vom System erkennbar. Eine Korrektur kann automatisch oder manuell erfolgen. Wird der Fehler automatisch korrigiert, beispielsweise Tippfehler, muss der Benutzer darauf hingewiesen werden, ohne jedoch den Dialogablauf zu stören. In dem genannten Fall kann die Eingabe korrigiert angezeigt werden, was als Hinweis ausreichend ist. Die automatische Fehlerkorrektur muss abschaltbar sein. Bei manueller Fehlerbeseitigung muss eine Fehlermeldung erfolgen, die in ihrer Ausführlichkeit anpaßbar ist. Das erlaubt unerfahrenen Benutzern sich über den Grund des Fehlers ausführlich zu informieren, während Experten mit diesen Informationen nicht belästigt werden. Zusätzlich sollte der Benutzer bei der Behebung des Fehlers unterstützt werden. Vorhandene Alternativen können dargestellt und erläutert werden. Die Fehlermeldungen selbst sind verständlich, sachlich und konstruktiv zu formulieren. Sie sollten einheitlich strukturiert werden. Dazu gehört sowohl der Aufbau des Fehlertextes als auch seine Darstellung.

Das Ziel beim Entwurf des Anwendungssystems besteht darin, das Auftreten von Fehlern zu vermeiden. So können Eingaben beschränkt werden, indem z.B. keine Ziffern in Textfeldern mit Zahlen als Inhalt erlaubt sind.

Semantische Fehler treten immer dann auf, wenn das mentale Modell des Benutzers von dem tatsächliches Modell des Anwendungssystems abweicht. Sie können vor allem durch erwartungskonforme Systeme und den Einsatz geeigneter Metaphern eingegrenzt werden.

3.3.6 Individualisierbarkeit

"Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers zulässt." ([ISO9241-10] S. 8) Umfassende Individualisierungsmöglichkeiten sind keine Rechtfertigung, auf die ergonomische Gestaltung von Dialogen zu verzichten. Die Möglichkeiten der Anpassung müssen durch den Entwickler sinnvoll begrenzt werden. Damit sollen Beeinträchtigungen durch Individualisierung vermieden werden. Beispielsweise darf es nicht möglich sein, die Lautstärke eines Audiosystems soweit zu erhöhen, dass Hörschäden entstehen können.

Grundsätzlich sollten Techniken zur Anpassung an Sprache und kulturelle Eigenheiten bereit gestellt werden. Dieser Aspekt wird unter dem Begriff Internationalisierung diskutiert. Weiterhin sollten sensomotorische und geistige Fähigkeiten des Benutzers beachtet werden. So ist beispielsweise für farbenfehlsichtige Anwender die Anpassung von Farben ein wichtiges Kriterium. Das Wissen der Benutzer und ihre Erfahrungen im Aufgabenbereich und mit dem Anwendungssystem sind unterschiedlich und unterliegen einem stetigen Wandel. Dementsprechend sollten Individualisierungsmöglichkeiten auch diesen Bereich abdecken. Ein Beispiel ist die Anpassung des Umfanges von Hilfetexten. Die Darstellung von Informationen sollte ebenfalls änderbar sein. So bevorzugen manche Benutzer eine Listendarstellung, während andere die Darstellung in Karteiform präferieren. Auch wenn in der Anwendung der Wortschatz des Arbeitsgebietes verwendet wurde, sollte es dem Benutzer erlaubt sein, eigene Bezeichnungen festzulegen. Die letzten Forderungen sind Anpassung von Kommandos und die Wahl der Interaktionsform. Die Kommandoanpassung umfasst sowohl ihre Bezeichnung als auch die Funktionalität. Als Beispiel können die in Abschnitt 3.3.1 erwähnten Makros genannt werden.

3.3.7 Lernförderlichkeit

"Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet." ([ISO9241-10] S. 9)

Lernen als das Erarbeiten einer möglichst geeigneten Vorgehensweise oder Strategie zur Erfüllung einer gegebenen Aufgabe durch wiederholte Übung (vgl. [Joha93] S. 147) ist für die effiziente Nutzung eines Softwaresystems von großer Bedeutung. Umfangreiche Systeme können auch durch einführende Schulungen nicht von Anfang an umfassend erfasst und in ihrer ganzen Funktionalität genutzt werden. Vielmehr sollte der Benutzer unterstützt werden, selbstständig sein Wissen über das System während seiner Nutzung zu verbessern und zu erweitern. Dabei helfen die bereits erwähnten Metaphern, die es ermöglichen, bereits vorhandenes Wissen in den neuen Bereich zu transferieren. Eine Hilfefunktion wirkt ebenfalls unterstützend. Die im Abschnitt 3.3.3 erläuterte Undo-Funktion unterstützt das "Learning-by-doing". Bei diesem Konzept soll der Anwender während der Erledigung einer Aufgabe lernen. Werden Schritte ausgeführt, die fehlerhafte Auswirkungen haben, können sie jederzeit wieder rückgängig gemacht werden.

Die Lernförderlichkeit eines Anwendungssystems ist auch wichtig, weil Benutzer die Eigenschaft besitzen, Funktionen und Abläufe die länger nicht genutzt wurden, wieder zu vergessen. In diesen Fällen reicht ein kurzes Wiederauffrischen des bereits Gelernten. Kurze Hinweise in Form von Tipps (vgl. Abschnitt 4.2.23) können dabei bereits ausreichen. Ein wichtiger Nebeneffekt besteht darin, dass Lernen bei der Benutzerzufriedenheit ein positiven Einfluss besitzt.

3.4 Entwurfstechniken

Die im vorherigen Abschnitt herausgearbeiteten Gestaltungsgrundsätze müssen bei der Entwicklung einer Benutzungsschnittstelle umgesetzt werden. Erst damit kann eine ergonomische Oberfläche entstehen. Es gibt eine Vielzahl von Prinzipien und Techniken, die dabei helfen können. Diese sind allgemeiner formuliert als konkrete Style Guides. Die Palette der Möglichkeiten ist jedoch zu weit gefächert, als das eine umfassend vollständige Beschreibung aller Aspekte möglich wäre. Aus diesem Grund werden die wichtigsten Prinzipen ausgewählt und diskutiert. Die einzelnen Techniken sind meist von mehreren Gestaltungsgrundsätzen beeinflusst. So unterstützt beispielsweise die Anwendung von Icons die Selbstbeschreibungsfähigkeit und Lernförderlichkeit. Die Auswahl der Interaktionsform wirkt sich dagegen hauptsächlich auf die Steuerbarkeit von Anwendungssystemen aus.

Die hier aufgeführte Reihenfolge der einzelnen Techniken steht nicht im Verhältnis zur ihrer Wichtigkeit. Vielmehr sollten alle Prinzipien beachtet und benutzt werden. Den Grad der Intensität geben die Rahmenbedingungen des Entwicklungsprojektes vor. Zu diesen gehören sowohl die Aufgabe und die Benutzer als auch finanzielle Gesichtspunkte. So wirken Sicherheitsabfragen innerhalb eines Systems erschwerend bei der Benutzung, können aber äußerst nützlich und somit sinnvoll sein. In diesen Fällen müssen Kompromisse eingegangen werden.

3.4.1 Fenstersysteme

Grafische Fenstersysteme werden heute in den meisten Computersystemen als Dialogform genutzt. Durch sie ist eine bessere Abbildung der menschlichen Gedankenwelt möglich, als das auf textueller Kommunikation beruhende Dialogsysteme vermögen (vgl. [Prei99] S. 77). Ein Fenster beschreibt dabei einen "separat steuerbaren Bereich auf dem Bildschirm, der zur Darstellung von Objekten und/oder zur Durchführung eines Dialogs mit dem Benutzer verwendet wird." ([ISO9241-16] S. 5) Es bietet dem Benutzer eine Sicht auf das Anwendungssystem. Durch die Verwendung mehrerer Fenster und damit unterschiedlicher Sichten kann dem Anwender ein umfassendes Verständnis der Anwendung und ihres aktuellen Zustandes vermittelt werden.

In den meisten grafischen Systemen können eine Vielzahl von Anwendungen simultan ablaufen (vgl. [Olse98] S. 91). Dabei besteht jede aus einem Haupt- und mehreren Unterfenstern. Um eine unnötige Konfusion zu vermeiden, werden grafische Benutzungsschnittstellen auf der Grundlage von Basis-Window-Systemen entwickelt. Diese werden durch zwei Aspekte charakterisiert. Zum einem bieten sie Softwaredienste an, die es Anwendungen ermöglichen, sowohl eigene Fenster zu erstellen und zu organisieren als auch diese mit Interaktionselementen zu füllen. Andererseits gestattet das Basis-Window-System dem Benutzer Größe und Position der Fenster zu kontrollieren. Die dafür zuständige Softwarekomponente wird als Fenstermanager bezeichnet.

Damit eignen sich Fenstersysteme ideal für die parallele Bearbeitung mehrerer Aufgaben. Diese kann sowohl anwendungsintern als auch anwendungsübergreifend stattfinden. Durch überlappende Darstellung der Fenster können dem Benutzer die vorhandenen Prozesse angezeigt werden. Diese Darstellung unterstützt die Schreibtischmetapher. Genau wie beim Stapeln von Dokumenten, ist nur das zu oberst liegende komplett sichtbar. Entsprechende Auswahlmechanismen, um das aktuelle Fenster festzulegen, müssen durch das Anwendungssystem bereit gestellt werden. Die einfachste Möglichkeit ist das Anklicken mit einem Zeigegerät wie der Maus. Da Fenster nicht zwingend angezeigt werden, sondern auch komplett verdeckt sein können, müssen innerhalb der Anwendung Alternativen angeboten werden. Eine Auswahl mittels Menü umgeht das genannte Problem.

Sowohl die Größe als auch die Position von Fenstern kann vom Benutzer verändert werden. Ist durch den speziellen Anwendungsfall diese Freiheit nicht sinnvoll, kann sie beispielsweise durch Angabe der maximalen Größe beschränkt werden. Ein wichtiges Kriterium bei Fenstersystemen ist die Platzierung der Fenster. In den meisten Fenstermanagern, wie z.B. Microsoft Windows, sind zwar Strategien integriert, diese sind jedoch unzureichend. So betreffen die Befehle zur Neuanordnung der Fenster alle im derzeitigen Nutzungskontext erreichbaren Fenster. Damit lassen sich Operationen nicht gezielt auf Fenster anwenden, die für eine bestimmte Aufgabe erforderlich sind. Es gibt zwar den Mechanismus einer Eltern - Kind Beziehung, diese Einteilung wird jedoch durch den Entwickler vorgenommen und ist für den Benutzer unzugänglich. Beim Anzeigen eines neuen Fensters sollte vom System sichergestellt werden, dass es wichtige Bildschirmbereiche nicht verdeckt. So darf der Dialog zum Suchen und Ersetzen bei der Sicherheitsabfrage nicht das Objekt überlappen, welches ersetzt werden soll. Fenster sollten sich nach Möglichkeit ihre letzte Position und Größe "merken". Üblicherweise entwickelt ein Benutzer während der Arbeit mit dem Anwendungssystem eine Fensteranordnung, die er auch zukünftig präferiert. Im entwickelten Prototyp wurden dafür zwei Methoden eingeführt, die diese Arbeit automatisch übernehmen (vgl. Abschnitt 4.2.1). Fenster bieten die Möglichkeit, Daten von einem Fenster in ein anderes zu transferieren. Dies erhöht die Effizienz bei der Aufgabenerledigung, da eine redundante Erstellung der Daten nicht notwendig ist. Im allgemeinen wird dieser Mechanismus mittels einer Zwischenablage realisiert.

Werden mehrere Aufgaben gleichzeitig abgearbeitet, werden entsprechend viele Fenster benötigt. Dabei kann die Bildschirmorganisation unübersichtlich werden, was zur Verwirrung des Benutzer führt. Dieser beschäftigt sich dadurch sehr lange mit der Verwaltung der Fenster. Die Effizienz der Aufgabenerfüllung sinkt. Virtuelle Bildschirme sind eine Technik, um das zu verhindern. Der Bildschirm wird in eine Raummetapher gewandelt. Dabei kann der Benutzer verschiedene Fenster gruppieren und diese einem Raum zuordnen. Zwischen den einzelnen Räumen kann der Benutzer beliebig hin und her wechseln, wobei der jeweils aktuelle Raum bildschirmfüllend dargestellt wird.

Kruschinski gibt einige grundsätzliche Richtlinien zum Aufbau von Fenstern (vgl. [Krus99] S. 36ff). Ein Fenster sollte nur die für die Teilaufgabe relevanten Informationen anzeigen. Diese sind allerdings vollständig darzustellen. D.h., dass alle benötigten Informationen direkt im Fenster zugänglich sind. Die Informationsdichte eines Fensters sollte zwischen 25 Prozent und 40 Prozent liegen. Sie wichtet den durch die Interaktionselemente benötigten Platz mit der gesamten Größe des Fensters. Einer der wichtigsten Aspekte der Fenstergestaltung ist die Einhaltung der Konsistenz. Ein gleichartige Struktur hat verschiedene Vorteile. So sinkt beispielsweise sowohl die Lernzeit als auch Suchzeit des Benutzers, was gleichzeitig zu einer Steigerung der Effizienz führt. Als letzter Punkt ist bei der Gestaltung von Fensters auf ein harmonisches Erscheinungsbild zu achten. Dabei sind die wichtigsten Faktoren Proportion, Balance, Vorhersagbarkeit, Symmetrie, Einfachheit, Klarheit und Sequenz. Diese werden an dieser Stelle jedoch nicht eingehend diskutiert. Kruschinski gibt in seiner Arbeit einen ausführlichen Überblick darüber (vgl. [Krus99] S. 41ff).

3.4.2 Interaktionsformen

Bei der Nutzung von Anwendungssystemen treten bestimmte Aktionen in gleicher oder ähnlicher Form immer wieder auf. Die Aktionen werden als Interaktionsaufgaben bezeichnet (vgl. [Prei99] S. 117). Sie drücken aus, was der Benutzer machen kann. Die Interaktionsaufgaben können in verschiedener Art und Weise durch den Anwender durchgeführt werden. So kann er beispielsweise zwischen Maus- oder Tastatureingabe auswählen. Die verschiedenen Möglichkeiten werden als Interaktionsform bzw. synonym Interaktionstechnik bezeichnet. Sie drücken aus, wie der Benutzer etwas machen kann. Grundsätzlich lässt sich die Aussage treffen, dass die Interaktionsform sowohl von der zu erledigenden Aufgabe als auch von dem Benutzer abhängt. Im folgenden werden die wichtigsten Interaktionstechniken näher beschrieben. Obwohl hier eine getrennte Betrachtung stattfindet, werden sie in der Praxis meist gemischt verwendet.

3.4.2.1 Deskriptive Interaktion

Die deskriptive Interaktion basiert auf der Verarbeitung von Sprache. Dabei kann sowohl eine Kommandosprache als auch natürliche Sprache eingesetzt werden. Die Kommandosprache war eine der ersten Interaktionsformen von Benutzungsschnittstellen (vgl. [HiHa93] S. 82). Sie besteht aus einer kontextfreien Grammatik, deren Schlüsselwörter mit möglichst wenig Buchstaben auskommen. Aus diesem Grund muss diese Sprache vom Benutzer erlernt werden. Wird sie beherrscht, stellen die Kommandos eine äußerst effiziente Methode dar, mit dem System zu kommunizieren. Unterstützend kann eine AutoComplete-Funktion vom System angeboten werden (vgl. [Prei99] S. 119). Wird ein Kommando während der Eingabe erkannt, obwohl es noch nicht komplett eingegeben wurde, so kann es vom System automatisch ergänzt werden. Der Einsatz von Aliasnamen, d.h. die Definition eines normalerweise kürzeren Wortes für ein Kommando ermöglicht weitere Effizienzsteigerungen. Ein wichtiger Aspekt bei Kommandosprachen stellt das Hilfesystem dar. Shneiderman betont, dass ein solches nur schwer anzubieten ist (vgl. [Shne98] S. 73). Es existieren jedoch Möglichkeiten, auch diese Interaktionsform entsprechend zu unterstützen. So sollte der Benutzer möglichst schnell sowohl verfügbare Kommando als auch seine Parameter einsehen können. Bei fehlerhafter Eingabe kann automatisch eine Übersicht entweder der Parameter oder der lexikalisch benachbarten Kommandos angeboten werden. Fehlende Angaben können durch Standardwerte ergänzt werden.

Kommandosprachen besitzen viele Vorteile. Sie erfordern keine speziellen Eingabegeräte und sind universell hinsichtlich der Ausdrucksmächtigkeit. Bei Beherrschung der Syntax können Aufträge aller Art effizient formuliert werden (vgl. [Ober94] S. 119). Die Aufzeichnung eines Protokolls ist sehr leicht umzusetzen. Die Definition von Makros gestaltet sich für den Benutzer unproblematisch. Neben den Vorteilen existieren jedoch auch erhebliche Nachteile. So müssen die Kommandos gelernt werden um aus dem Gedächtnis abrufbar zu sein. Eine flüssige Interaktion erfordert eine schnelle und fehlerfreie Tastatureingabe. Abkürzungen, Standards und Makros können dabei unterstützend wirken, erhöhen jedoch den Lernaufwand. Der Wirkungsbereich von Kommandos umfasst das gesamte System. Aus diesem Grund sind die Auswirkungen eines Kommandos für den Benutzer schwer zu kontrollieren. Der hohe Lernaufwand gepaart mit der konsequenten Ausrichtung auf Effizienz prädestiniert diese Interaktionsform für professionelle Benutzer.

Die Interaktion über natürliche Sprache geht von der gewohnten Sprache des Menschen aus. Sie erfordert deshalb keinen zusätzlichen Lernaufwand. Damit ist sie für Gelegenheitsnutzer bzw. Anfänger gut geeignet. Bei ihnen sinkt vor allem bei umfangreichen Datenmengen die Effizienz der Eingabe. Das Hauptproblem bei natürlich-sprachlichen Systemen besteht jedoch in ihrer Interpretation. Die Bedeutung der Eingabe hängt stark vom Kontext ab. Tritt ein solcher mehrdeutiger Fall auf, muss das System einen Klärungsdialog initiieren, der wiederum die Effizienz mindert. Da die natürliche Sprache mit bis zu 300.000 Wörtern ein extrem umfangreiches Vokabular besitzt, können heutige Anwendungssysteme nur einen kleinen Teil kennen und verarbeiten.

Das Gebiet der deskriptiven Interaktionsformen gewinnt in letzter Zeit wieder an Bedeutung. Grund dafür ist die Einführung der Spracheingabe. Die Steuerung von Computern über Sprache, beispielsweise bei Fahrzeugnavigation oder -telefonie, wird auch in Zukunft weiter an Bedeutung gewinnen.

3.4.2.2 Menüs

Menüs zählen zu den deiktischen bzw. selektionsorientierten Interaktionsformen. Bei diesen wird dem Benutzer die Möglichkeit gegeben, aus einem Angebot von Operationen bzw. Objekten auszuwählen (vgl. [ISO9241-14] S. 5). Damit wird das Konzept der Wiedererkennung unterstützt. Dieses basiert darauf, dass ein Mensch bei der Erkennung deutlich leistungsfähiger als bei der Erinnerung ist.

Menüs sind eine Interaktionstechnik, die schnell verstanden wird. Vor allem für Gelegenheitsbenutzer und Anfänger sind sie gut geeignet. Zu den Vorteilen gehören die leichte Erlernbarkeit, die hohe Anwendungsneutralität sowie die Vermeidung von Syntaxfehlern. Zusätzlich ist der Eingabeaufwand sehr gering. Menüs unterstützen das entdeckende Lernen , da sie bisher nicht verwendete und nicht erinnerte Alternativen sichtbar machen (vgl. [Ober94] S. 129). Nachteile sind vor allem die langsame Auswahl und der hohe Platzbedarf auf dem Bildschirm. Menüs sind nur für kleine Auswahlmengen geeignet. Ein weiterer Nachteil ist die Parameterübergabe bei Operationen. Diese sind nur durch aufwendige Kaskadierung, d.h. die Bildung von Untermenüs, oder durch einen zusätzlichen Dialog möglich. Die partielle Darstellung eines Menüs kann zu Orientierungs- und Navigationsproblemen führen.

Menüs sind eine wichtige Interaktionsform, die in fast jeder Anwendung genutzt wird. Aus diesem Grund wird ihnen in der Richtlinie ISO 9241 ein eigener Teil gewidmet.

Das Hauptproblem bei der Verwendung eines Menüs ist ihre Strukturierung. Das Ziel besteht darin, dass der Benutzer so schnell wie möglich den gesuchten Menüeintrag findet. Da meist die Anzahl der verfügbaren Optionen zu hoch ist, um effizient in einem einzigen Menü angezeigt zu werden, ist die Bildung eines hierarchischen Menübaums erforderlich (vgl. [ISO9241-14] S. 7). Jede zusammen angezeigte Gruppe von Menüeinträgen wird als Menü bzw. Untermenü bezeichnet. Unter der Tiefe eines Menüs versteht man die vorhandene Anzahl von Untermenüs. Die Breite eines Menüs gibt die Anzahl von Menüpunkten der aktuellen Ebene an.

Üblicherweise werden Menüpunkte nach ihrer inhaltlichen Zusammengehörigkeit gruppiert. Das Ziel sollte eine breite Menühierarchie sein, da die Suche deutlich schneller als in tiefen Hierarchien ist. Hier tritt ein Zielkonflikt ein, da der Entwickler in Versuchung gerät, inhaltlich relativ unabhängige Optionen in einem Menü zu gruppieren. Dem ist jedoch entgegenzuwirken, da bei unlogischer Strukturierung der Zeitvorteil der breiten Hierarchie verloren geht. Um den Entwickler bei diesen Entscheidungen zu unterstützen, wurden umfangreiche Untersuchungen durchgeführt. Shneiderman fasst diese zusammen und gibt einige Empfehlungen (vgl. [Shne98] S. 257). Grundsätzlich sollte ein Menü aus mindestens drei, maximal jedoch 20 Einträgen bestehen. Bei der Verwendung von relativ vielen Menüeinträgen ist sind Separatoren bzw. Trennlinien einzusetzen (vgl. [Prei99] S. 103). Diese führen zu Untergruppen und beeinflussen die Suchzeit ebenfalls positiv. Die durchschnittliche Tiefe von Menüs sollte zwischen zwei und drei liegen. Werden mehr Ebenen genutzt, so kann das eine Desorientierung des Benutzers nach sich ziehen. Ein Problem tritt auf, wenn bei der Entwicklung des Systems die Anzahl der Menüeinträge noch nicht bekannt ist. In diesen Fällen sollten Maßnahmen getroffen werden, welche die Bildung von schlechten Menühierarchien vermeiden. So kann beispielsweise eine Aufteilung in mehrere Spalten erwogen werden, oder dem Benutzer selbst die Möglichkeit der Anpassung gegeben werden (vgl. Abschnitt 3.4.8).

Ein weiteren wichtigen Anhaltspunkt für die Strukturierung bieten die verbreiteten Konventionen. Diese sind nach Möglichkeit einzuhalten, da sie vielen Benutzern bekannt sind. So befindet sich beispielsweise das Dateimenü jeweils links, während das Hilfemenü grundsätzlich rechts angeordnet ist. Außer der Strukturierung sind Platzierung und der Zeitraum, in dem das Menü sichtbar ist, festzulegen (vgl. [Ober94] S. 127).

Das Konzept der Beschleunigungstasten ist ebenfalls zu unterstützten. Beschleunigungstasten (engl.: accelerator key, shortcut key) sind eine Kombination von Tasten, um eine Menü-Option aufzurufen, ohne dass das entsprechende Menü auf dem Bildschirm angezeigt wird (vgl. [ISO9241-14] S. 4). Damit kann der Zugriff auf einen Menüeintrag wesentlich beschleunigt werden. Die Beschleunigungstaste wird im Menüeintrag rechts vom beschreibenden Text angezeigt. Das System sollte es dem Benutzer gestatten, für Menüeinträge selber Tastenkürzel zu vergeben. Das bedeutet jedoch nicht, dass der Entwickler auf sinnvolle Vorgaben verzichten kann. Für die Hilfefunktion ist beispielsweise die Funktionstaste F1 üblich. Diese Beschleunigungstasten sind auch aktiv, wenn das Menü nicht geöffnet ist. Zur schnellen Navigation in Menüs bietet sich jedoch auch eine Selektion über Anfangsbuchstaben von Menüeinträgen an. Der zu drückende Buchstabe wird in diesem Fall unterstrichen dargestellt.

Häufig werden oft benutzte Menüeinträge in Werkzeugleisten (auch: Symbolleisten) zusammengefasst, die durch den Benutzer beliebig ein- und ausgeblendet werden können. Dabei werden die Menüeinträge durch Icons repräsentiert. Diese sollten auch im Menüeintrag genutzt werden, wobei sie links vom beschreibenden Text platziert werden. Damit wird die Fähigkeit der Wiedererkennung des Anwenders genutzt und ebenfalls eine Beschleunigung bei der Selektion erreicht. Von einer dynamischen Modifikation von Menüs wird abgeraten. So könnten oft genutzte Menüeinträge dynamisch in ihrer Position im Menü nach oben positioniert werden. Kaum gebrauchte Einträge werden entsprechend weiter unten angeordnet. Untersuchungen haben jedoch gezeigt, dass durch die ständige Neuorientierung des Benutzers der erhoffte Geschwindigkeitsvorteil ausblieb.

Außer dem globalen Menü werden in Anwendungen oft lokale Menüs angeboten. Sie werden als Pop-up-Menüs bezeichnet. Diese werden üblicherweise mit der rechten Maustaste aktiviert und erscheinen dynamisch in der Nähe des ausgewählten Objektes. Sie bieten sowohl von der aktuellen Selektion abhängige, als auch globale Optionen. Die Nutzung solcher Menüs ist insofern problematisch, als das sie nicht explizit sichtbar sind. Aus diesem Grund müssen grundsätzlich alle Optionen auch anderweitig aktivierbar sein.

In den letzten Jahren wurden einige interessante Ansätze entwickelt, bestimmte Nachteile von Menüs abzuschaffen. Ein Problem bei der Nutzung von Kontextmenüs besteht darin, dass der aktuelle Bildschirminhalt teilweise verdeckt wird. Abhilfe lässt sich durch Nutzung transparenter Menüs schaffen (vgl. [Prei99] S. 105ff). Bei diesen kann der Benutzer durch den Hintergrund des Menüs "durchsehen". Im Idealfall lässt sich die Stärke der Transparenz durch den Benutzer beeinflussen. Ein Nachteil dieser Menüs ist, dass sie etwas schwerer lesbar sind, als normale Menüs. Kreisförmige Menüs sind der Versuch, die Suchzeit weiter zu verringern. Vorteilhaft ist dabei, dass alle Menüeinträge von der Kreismitte gleich weit entfernt sind. Zeitgewinn bringt auch, dass ein Benutzer sich die Richtung, in der sich der Menüeintrag befindet besser merken kann, als dessen Position in einem linearem Menü. Während Kreismenüs sich bisher nicht durchsetzen konnten, werden Abreißmenüs vor allem in Grafikanwendungen benutzt. Diese Menüs sind auf dem Bildschirm frei platzierbar. Sie können je nach Bedarf aus- bzw. eingeklappt werden. Damit sind sie schnell im Zugriff, überdecken jedoch den Bildschirminhalt nicht.

3.4.2.3 Direkte Manipulation

Die direkte Manipulation ist "eine Dialogtechnik, durch die der Benutzer den Eindruck erhält, die Objekte am Bildschirm direkt zu bearbeiten, z.B. indem er mit Hilfe eines Zeigeinstrumentes auf sie zeigt, sie verschiebt und/oder ihre physikalischen Eigenschaften (oder Werte) verändert." ([ISO9241-16] S. 4). Thimbleby nennt als Hauptmerkmal der direkten Manipulation die sofortige, konsistente und eindeutige Darstellung der manipulierbaren Daten (vgl. [HaTh90] S. 130). Das bedeutet, das verfügbare Objekte und Werkzeuge der Anwendung ständig visualisiert werden. Damit soll dem Benutzer das Gefühl gegeben werden, analog zu Realität arbeiten zu können. Auf Grund der Komplexität eines Anwendungssystems kann in den wenigsten Fällen alles gleichzeitig dargestellt werden. Eine Möglichkeit die Komplexität zu reduzieren, stellt der Mechanismus der Modi dar. Ein Modus definiert einen Zustand des Systems, in dem nur Teile der Daten und Funktionen angezeigt werden. Die direkte Manipulation wird heute in fast allen grafischen Benutzungsschnittstellen als Interaktionstechnik angewandt. In der aktuellen Literatur wird sie oft zusammen mit dem Begriff Virtual Reality (auch: Virtual Environment) genannt. Letzteres wird dabei als konsequente Weiterentwicklung der direkten Manipulation angesehen.

Die direkte Manipulation bietet eine Vielzahl von Vorteilen. Anfänger erlernen hier die Grundfunktionalität schneller als in Systemen, die als Eingabe eine komplexe Syntax verlangen. Auch Gelegenheitsbenutzer können sich die Grundkonzepte besser merken. Werden an Objekten Veränderungen durchgeführt, so ist das Ergebnis direkt erkennbar. Entspricht es nicht den Erwartungen des Benutzers, so kann er es über die Undo-Funktion sofort rückgängig machen (vgl. [Ober94] S. 136). Anschließend kann ein erneuter Versuch unternommen werden. Dieses Rückkopplungsprinzip wird oft mit dem WYSIWYG-Prinzip verknüpft (vgl. Abschnitt 3.4.5). Durch den Verbund von Objekt und Operation, verringert sich die Fehlerrate, da der Benutzer nur Operationen auswählen kann, die für das Objekt auch sinnvoll sind. Damit werden auch deutlich weniger Fehlermeldungen benötigt. Zusätzlich erleben Benutzer weniger Angstgefühle, da die Systeme verständlicher sind und Aktionen gefahrlos ausprobiert werden können. Zutrauen und Sicherheit steigern sich ebenfalls, da der Benutzer als Initiator auftritt und damit das Systemverhalten vorhersehen kann.

Es gibt jedoch auch Einschränkungen. Vor allem bei Routineaufgaben kann die Effizienz der Aufgabenerledigung sinken. Da die Objekte immer direkt mit dem Zeigegerät anzusprechen sind, steigt mit der Anzahl der auszuwählenden Objekte auch der Interaktionsaufwand. Das Problem tritt auch auf, wenn Objekte anhand ihrer Eigenschaften ausgewählt und manipuliert werden sollen. Soll beispielsweise aus tausend Objekten eine Auswahl anhand von drei Eigenschaften vorgenommen werden, so muss bei konsequenter Umsetzung der direkten Manipulation jedes Objekt ausgewählt und bewertet werden. Es ist offensichtlich, das damit ein unzumutbarer Interaktionsaufwand entsteht. Ein Lösungsansatz besteht darin, kleinere Teildialoge zu entwickeln, die eine Filterung von Objekten nach verschiedenen Eigenschaften durchführen. Die Ergebnismenge des Filters kann dann einfach komplett selektiert und manipuliert werden. Als Beispiel kann hier der Dateisuche unter MS Windows genannt werden. In dem oben genannten Beispiel können deskriptive oder deiktische Interaktionsformen deutlich effizienter sein. Ein weiterer Nachteil besteht darin, dass alle Operationen des gewählten Objektes visualisiert werden müssen. Das ist jedoch nicht immer möglich, da eine Überflutung des Benutzers die Folge ist. Aus diesem Grund wird nur eine gefilterte Auswahl von Operationen angeboten. Damit wird unter Umständen nicht die volle Funktionalität kennengelernt und genutzt. Nachteilig ist auch der Umstand, dass die grafische Symbolik kaum normiert ist. Ein großes Problem kann auftreten, wenn die Grenzen der verwendeten Metapher vom Benutzer nicht erkannt werden. Dies führt dann zu falschen mentalen Modellen und damit zu Fehlhandlungen.

Durch eine intensive Aufgabenanalyse ist festzustellen, in welchen Bereichen des Dialogs die direkte Manipulation nachteilig sein kann. Hier ist dann dem Benutzer eine alternative Interaktionsform anzubieten.

3.4.3 Antwortverhalten

Unter dem Antwortverhalten versteht man die zeitliche Reaktion des Anwendungssystems auf Benutzereingaben. Das Antwortverhalten ist für interaktive Systeme von großer Bedeutung. Treten hierbei unerwartete Verzögerungen auf, verunsichert das den Benutzer. Mit steigender Häufigkeit dieses Verhaltens kann das den Benutzer verärgern und sogar frustrieren. Andererseits kann eine zu schnelle Systemreaktion den Benutzer zu hastigem arbeiten animieren. Die Folge sind schlechterer Lernerfolg, oberflächliches Lesen von Systemausgaben und Eingabefehler. Der Zeitgewinn durch das schnellere Antwortverhalten geht damit wieder verloren (vgl. [Shne98] S. 352). Ein Studie mit 4.448 Computerbenutzern ergab, dass das Antwortverhalten die wichtigste Einflussgröße auf die Zufriedenheit darstellt (vgl. [Goul+97] S.232). Eine höhere Benutzerzufriedenheit führt zu größerer Motivation und damit zu einer effizienteren Aufgabenerledigung.

Die wichtigste Teilgröße des Antwortverhalten eines Computersystems ist die Antwortzeit (engl. response time). Diese gibt den Zeitraum zwischen dem Ende der Eingabe des Benutzers und dem Beginn der Ausgabe des Systems an.

Wie in Abbildung 4 zu sehen ist, plant der Benutzer schon während der Eingabe der Daten weitere Schritte. Dieser Planungsprozess wird auch innerhalb der Antwortzeit des Computersystems fortgesetzt. Bei komplexen Aufgaben kann eine längere Antwortzeit zu einer präziseren Planung und damit zu weniger Fehlern führen. Bei einfachen Aufgaben wird der Benutzer durch eine lange Antwortzeit behindert. Dabei wirkt sich vor allem der Informationsverlust des Kurzzeitgedächtnisses aus. Die verlorenen Informationen müssen erneut beschafft werden, was zusätzliche Zeit benötigt und Kosten verursacht. Das bedeutet, dass eine optimale Antwortzeit sowohl durch den Benutzer, als auch durch die Komplexität der Aufgabe bestimmt wird.

Empirische Untersuchen haben einige Faktoren herausgearbeit, welche die Bestimmung einer günstigen Antwortzeit beeinflussen. Vor allem Erfahrungen mit ähnlichen Systemen rufen entsprechende Erwartungen bei dem Benutzer hervor. Miller hat heraus gefunden, dass Benutzer bei einer Antwortzeit zwischen zwei und vier Sekunden eine Abweichung von 8 Prozent bemerken (vgl. [Shne98] S. 359). Ist die Antwortzeit länger als erwartet, wird der Benutzer ungeduldig. Die Akzeptanz gegenüber dem Anwendungssystem sinkt. Ist sie jedoch überraschend kurz, so wird der Benutzer skeptisch, ob alles korrekt abgelaufen ist. Wird beispielsweise der aktuelle Arbeitsstand durch den Benutzer gesichert, so erwartet dieser eine kurze, aber merkbare Antwortzeit. Das völlige Fehlen dieser Verzögerung kann in dem Benutzer das Gefühl einer Fehlfunktion wecken. Einen Einfluss auf die Antwortzeit haben auch persönliche Merkmale des Benutzers. So akzeptieren Anfänger eher längere Wartezeiten als Experten. Weitere Faktoren sind Alter, momentane Belastung oder die Tageszeit. Die untere Grenze für die Antwortzeit legt die Rechenleistung des benutzten Computersystems fest. Im allgemeinen sollte die Antwortzeit unter einer Sekunde liegen. Die Obergrenze liegt bei drei bis vier Sekunden. Ab dieser Zeitspanne wird durch die ISO 9241 eine entsprechende Systemmeldung verlangt. Diese informiert den Benutzer über den aktuellen Zustand des Systems. Verbreitete Techniken sind dabei Fortschrittsbalken oder Mauszeiger mit sich zeitlich verändernder Darstellung. Bei Microsoft Windows ist das beispielsweise eine sich drehende Sanduhr. Letzteres wird genutzt, wenn der für die Funktion benötigte Zeitraum nicht im voraus berechnet werden kann.

Im Prototyp wurde für diesen Anwendungsfall die Klasse ProgressBar entwickelt. Diese zeigt ein Fenster mit einem Fortschrittsbalken an. Ist eine genaue Anzeige des Systemzustandes auf Grund fehlender Granulierung der Prozessschritte nicht möglich, so kann eine Zeitspanne angegeben werden, in welcher der Balken 100 Prozent erreicht. Für die Ermittlung dieser Zeitspanne kann der Prozess während der ersten Ausführung überwacht und die tatsächlich benötigte Zeit gemessen werden. Bei wiederholter Abarbeitung des Prozesses kann diese als Vorgabe für den Fortschrittsbalken genutzt werden. Sind Messungen nicht sinnvoll, da die Prozessdauer bei jeder Ausführung schwankt, sollte die Anzeige durch einen sich verändernden Mauszeiger realisiert werden.

Die Antwortzeit lässt sich nur schwer messen, da sie sowohl von hardware- als auch softwaretechnischen Einflüssen abhängt. Statistische Messungen an Prototypen ermöglichen es jedoch, Aussagen zu treffen. Die Zielgröße für die Evaluierung von Antwortzeiten stellt die Produktivität dar. Sie wird durch die Anzahl der korrekt durchgeführten Aufgaben pro Zeiteinheit bestimmt. Damit wird sie durch eine höhere Fehlerrate negativ beeinflusst. Das Optimum ist erreicht, wenn die Kosten für eine weitere Verbesserung der Antwortzeit höher sind, als die Einsparungen durch höhere Produktivität. Damit muss die durch das System mögliche minimale Antwortzeit nicht immer die günstigste sein. Tendenziell lässt sich jedoch feststellen, dass die zu langen Antwortzeiten den größeren Problembereich darstellen.

3.4.4 Icons

Icons stellen einen Grundbestandteil grafischer Benutzungsschnittstellen dar. Sie sind symbolische Darstellungen von Objekten bzw. Operationen. Im deutschen Sprachgebrauch werden sie synonym als Piktogramme bezeichnet. Die wörtliche Übersetzung aus dem lateinischen lautet geschriebenes Bild. Der Duden definiert Piktogramme als "formelhaftes, graphisches Symbol mit international festgelegter Bedeutung." ([Stau87] S. 5) Nach ISO 11581 ist ein Icon "eine Graphik auf einem Sichtanzeigegerät, das eine Funktion eines Rechnersystems repräsentiert." ([ISO11581-1] S. 6) Das wichtigste Merkmal von Piktogrammen ist ihre abstrakte Darstellung. Damit sind sie gegenüber Fotos oder Bildern nicht so anschaulich. Ihre Bedeutung, d.h. was sie repräsentieren sollen, wird vom Benutzer hingegen besser erkannt. Durch die grafische Darstellung fallen Icons dem Anwender leicht auf. Deshalb werden wichtige bzw. oft benötigte Funktionen oder Objekte mit Hilfe von Icons dargestellt.

Icons entsprechen durch ihre abstrahierte Darstellung einer symbolhaften Sprache. Solche Sprachen werden in allen Bereichen des Lebens genutzt. So ist die Beschilderung im Straßenverkehr oder von Bahnhöfen und Flugplätzen ein Beispiel für die Verwendung von Piktogrammen. Damit können Kenntnisse aus diesen Wissensbereichen auch bei den Icons für die Benutzungsschnittstelle eines Anwendungssystems angewendet werden. Durch den bildhaften Charakter können Piktogramme in verschiedenen Kulturbereichen verstanden werden. Icons sind demzufolge nicht nur bei Vorhandensein von verschiedenen Benutzergruppen ideal anzuwenden. Sie tragen auch zur Internationalisierung des Softwaresystems bei. Bei der Entwicklung ist allerdings zu beachten, dass beispielsweise bestimmte Farben in manchen Ländern eine unterschiedliche Bedeutung besitzen.

Die Entwicklung von Icons bzw. Icon-Sätzen ist ein aufwendiger Prozess, der nicht unterschätzt werden darf. Ein Icon-Satz besteht aus einer Gruppe von inhaltlich zusammengehörigen Icons. Diese Zusammengehörigkeit sollte auch durch die grafische Darstellung deutlich gemacht werden. Bestimme Aufgabenbereiche finden sich in vielen Anwendungssystemen wieder. Ein Beispiel dafür sind die Funktionen Undo, Ausschneiden und Einfügen. In diesen Fällen existieren bereits Piktogramme, die dem Benutzer bekannt sind. Um eine anwendungsübergreifende Konsistenz zu erreichen, sollten sie berücksichtigt werden (vgl. [Stau87] S. 99). So wird für die Funktion Drucken im allgemeinen ein Icon mit einem Drucker genutzt. Innerhalb eines Icon-Satzes sollten gleiche Farben sowie einheitliche Symbolgrößen und Ränder benutzt werden. Trotz der Gleichartigkeit innerhalb des Satzes müssen die einzelnen Piktogramme klar voneinander unterscheidbar sein. Durch einen klaren Kontrast zum Hintergrund wird das Erkennen der Icons ebenfalls erleichtert. Die verschiedenen Icon-Sätze sind innerhalb eines Anwendungssystem konsistent zu gestalten. Dabei ist die Definition einer Farbtabelle hilfreich. Die Erstellung bzw. Produktion von Piktogrammen wird idealer Weise mit Hilfe der Benutzer durchgeführt (vgl. [Stau87] S. 95). So können bereits vorhanden mentale Modelle Vorgaben über die Darstellung liefern. Es ist zu beachten, dass der Benutzer die Funktion des Icons erkennen muss, nicht der Designer. Nach der Entwicklung von Piktogrammen ist im Rahmen der Evaluation sicher zustellen, dass die Symbole richtig gedeutet werden. Staufer gibt in seinem Buch einen detaillierten Überblick über mögliche Methoden. Im wesentlichen wird die Erkennbarkeit und Verständlichkeit bewertet. Die ISO 11581 nennt mit Unterscheidbarkeit, Erlernbarkeit, Leserlichkeit und Wiedererkennbarkeit weitere Kriterien, die eine Beurteilung des Icon erlauben (vgl. [ISO11581-1] S. 6f). Quantifiziert werden diese Eigenschaften durch Zeitmessungen, Zählung von Fehlern und Übereinstimmung zwischen der erkannten semantischen Bedeutung und der tatsächlichen Funktion des Piktogrammes (vgl. [Stau87] S. 119). Der Gesamtprozess der Piktogrammentwicklung wird in Anhang A.8 dargestellt.

Die Entwicklung und Verwaltung von Icons kann bei umfangreichen Projekten ein nicht unerhebliches Ausmaß annehmen. Aus diesem Grund existieren Tools, die diese Aufgaben übernehmen. Moderne Softwareentwicklungsumgebungen bieten in der Regel einen integrierten Icon-Editor an.

Einen weiteren großen Vorteil, den Icons bieten, ist die Möglichkeit, auch Zustände bzw. Modi anzeigen zu können. Dazu wird ihr Aussehen geändert. Häufig wird diese Technik bei Ein/Aus Zuständen eingesetzt. Meist wird durch eine Änderung des Hintergrundes bzw. der Farben der jeweilige Zustand angezeigt. Es besteht auch die Möglichkeit, das Symbol selbst zu ändern. Allerdings ist zu beachten, dass eine zu große Abweichung Nachteile bei der Wiedererkennung nach sich zieht. Unter Umständen wird dann vom Benutzer der Zusammenhang zwischen beiden Zuständen nicht mehr erkannt, was zu Einbußen bei der Effizienz führen kann.

Ein Nachteil von Icons ist, dass auch momentan nicht verfügbare Aktionen bzw. Objekte angezeigt werden. Um diesen Effekt abzuschwächen, werden diese Icons üblicherweise grau dargestellt, um ihre Inaktivität anzuzeigen. Weiterhin wird für die Erkennung von Piktogrammen ein Vorwissen des Benutzers vorausgesetzt. Eine weitere Schwachstelle ist die Mehrdeutigkeit. Es wurde zwar hinreichend beschrieben, wie dieser Nachteil möglichst vermieden werden kann, auszuschließen ist er jedoch nie.

Icons werden auch zusammen mit Schaltern oder in Menüs verwendet. Auch hier gelten die oben gemachten Aussagen. Ist an anderer Stelle ein Zugriff auf die gleichen Funktionen oder Objekte möglich, so sind jeweils die gleichen Icons zu verwenden. Ein Beispiel dafür ist die Verwendung von Symbolleisten für den Schnellzugriff von wichtigen Menüpunkten.

3.4.5 WYSIWYG-Prinzip

Das WYSIWYG-Prinzip (What you see is what you get) bedeutet, dass die Benutzereingaben auf dem Bildschirm so dargestellt werden, wie sie später auf dem Drucker erscheinen würden (vgl. [Prei99] S. 120ff). Ursprünglich für Textverarbeitungen entwickelt, wird dieses Prinzip heute in vielen Softwaresystemen integriert.

Führt ein Benutzer eine Manipulation an einem Objekt durch, so werden die Auswirkungen und damit das Ergebnis sofort sichtbar. Diese sofortige Rückkopplung führt dazu, dass Fehler schneller erkannt werden. Vor allem vom System erkennbare Fehler können dem Benutzer unmittelbar angezeigt werden. Dieser kann dadurch sofort zielgerichtete Gegenmaßnahmen einleiten, ohne weitere Operationen auszuführen, die auf den Fehler aufbauen und damit unsinnig wären. Ein weiterer Vorteil dieser Technik ist, dass zusätzliche Informationen, die die Darstellung betreffen, nicht auf dem Bildschirm erscheinen. So kann auf die explizite Anzeige von Formaten oder Positionen verzichtet werden, da der Benutzer diese implizit aus der Darstellung erkennen kann. Damit wird eine größere Übersichtlichkeit erreicht.

Das WYSIWYG-Prinzip hat jedoch auch Nachteile. Ein Problem stellt die nie ganz exakte Übereinstimmung zwischen Bildschirmausgabe und Ausdruck dar. Diese beruht auf den physikalischen Charakteristika der unterschiedlichen Geräte. Vor allem bei farbigen Grafiken tritt dieses Problem auf. Die konsequente Umsetzung des WYSIWYG-Prinzip kann sich bei der Erledigung bestimmter Aufgaben auch hinderlich auswirken. So ist zum Beispiel bei der Verfassung eines längeren Textes die ständige Darstellung der eingefügten Grafiken störend, da sie sowohl Platz auf dem Bildschirm als auch Computerressourcen beanspruchen. Ferner können für bestimmte Aufgaben Informationen über die Darstellung der Objekte für den Benutzer wichtig sein. Beispiele dafür sind die Gliederung eines Dokumentes oder die hierarchische Struktur eines CAD-Modells.

Aus den genannten Gründen ergibt sich die Forderung, dass WYSIWYG-Ansichten nicht die einzige im Softwaresystem angebotene Sicht sein darf. So können diese Ansichten mit zusätzlichen Informationen angereichert werden, was jedoch das Konzept durchbrechen würde. Eine andere Lösung ist das gleichzeitige Angebot von Struktur- und WYSIWYG-Ansicht. Beide Sichten müssen in diesem Fall jedoch synchronisiert werden. Der einfachste Ansatz ist, es dem Benutzer zu ermöglichen, zwischen den verschiedenen Sichten wählen zu können. Dabei entspricht jede Sicht einem Modus. Das WYSIWYG-Prinzip wird häufig mit der Technik der direkten Manipulation verknüpft (vgl. Abschnitt 3.4.2.3).

3.4.6 Hilfesystem

Es gibt praktisch kein Anwendungssystem, welches umfassend verständlich ist. Aus diesem Grund müssen dem Benutzer Möglichkeiten zur Unterstützung geboten werden. Das können Schulungen durch Experten, Handbücher oder Hilfesysteme sein. Im Rahmen dieser Arbeit werden letztere genauer diskutiert.

Als Hilfesystem wird jedes Programm bezeichnet, das bei der Benutzung eines interaktiven Systems durch explizite Erklärungen hilft (vgl. [Herc94] S. 161). Es erklärt den Systemzustand, d.h. vorhandene Objekte, ihre Eigenschaften und Beziehungen untereinander. Zusätzlich wird die Funktionalität beschrieben, also die Operationen mit denen die Eigenschaften von Objekten manipuliert werden können. Hilfesysteme bieten eine Reihe von Vorteilen (vgl. [Shne98] S. 425f). Sie sind, im Gegensatz zu Handbüchern, während der Arbeit mit dem Anwendungssystem ständig verfügbar. Durch Aktualisierungen, beispielsweise mit Hilfe des Internet, können sie kostengünstig immer auf dem neuesten Stand gehalten werden. Der Einsatz von Suchmaschinen ermöglicht das Anbieten spezifischer, aufgabenabhängiger Informationen. Innerhalb des Hilfesystem können multimediale Komponenten wie Grafik, Ton oder Animation verwendet werden. Es existieren jedoch auch Nachteile. So sind längere Texte vor allem auf Monitoren mit niedriger Auflösung nicht so gut lesbar, wie auf Papier gedruckter Text. Dabei können längere Bearbeitungszeiten von 15 bis 30 Prozent auftreten. Die niedrigeren Auflösungen können auch dazu führen, dass Grafiken und Bilder schlechter dargestellt und damit fehlinterpretiert werden. Bei Anfängern können Probleme bei der Anwendung des Hilfesystem auftreten, da sie mit der Benutzungsschnittstelle des Hilfesystems nicht vertraut sind. Ein weiterer Nachteil besteht darin, dass das Hilfesystem Platz auf dem Bildschirm benötigt. Dadurch können Teile des Anwendungssystems verdeckt werden, was zu einer höheren Belastung des Kurzzeitgedächtnisses des Benutzers führt. Aus diesen Gründen sollten sowohl Online-Hilfe als auch Handbücher angeboten werden. Moderne Konzepte ermöglichen es, beides aus einem einzigen Datenpool zu erzeugen, so dass nur ein geringer zusätzlicher Aufwand entsteht.

Sieht man Hilfesysteme als eine besondere Form von Anwendungssystemen, so lassen sich die gemachten Aussagen über ergonomische Aspekte auch in diesem Bereich anwenden. Da jedoch Aufgaben und Ziele eines Hilfesystems bekannt sind, können einige speziellere Aussagen getroffen werden.

Wie ein Dialog kann auch das Hilfesystem nach Art der Aktivierung unterschieden werden. Passive Hilfe wird durch den Benutzer initiiert. Sie ist bei fast allen Softwaresystemen integriert. In den Anfängen der Hilfesysteme waren dies meist Online user manuals, die lediglich die Handbücher in elektronischer Form anbieten (vgl. [Shne98] S. 411). Diese Hilfesysteme waren schlecht zu nutzen, da die angebotenen langen Texte sehr unüberschaubar waren. Eine erste Verbesserung war die Einführung von Zugriffsstrategien. Sie ermöglichen dem Benutzer durch eine Auswahlfunktion gezielt auf Teile der Hilfeinformationen zuzugreifen. Solche Hilfesysteme werden als Online help facility definiert. Bei ihnen ist mindestens ein statischer Index vorhanden. Implementierte Suchfunktionen, die mit natürlich-sprachlichen Anfragen umgehen können, stellen ein leistungsstärkeres Instrument für den Benutzer dar. Das Anfrageergebnis stellt einen dynamisch erzeugten Index dar. Dieser zeigt auf die entsprechenden Hilfetexte, die selbst aber weiterhin statisch sind. Das Problem bei natürlich-sprachlichen Anfragen ist die Schwierigkeit, die Anfrage syntaktisch und semantisch korrekt zu erfassen. So können Tipp- oder Schreibfehler ein korrekte Auswertung verhindern. Ebenfalls problematisch stellt sich die Auswertung des inhaltlichen Zusammenhangs bei Eingabe von Wortgruppen dar. Die angesprochenen Probleme sind im Rahmen des Information Retrieval Thema intensiver Forschungen.

Aktive Hilfesysteme übernehmen selbst die Initiative (vgl. [Herc94] S. 165ff). Dazu ist eine Überwachung des Dialogs zwischen Benutzer und Anwendungssystem notwendig. Dabei sind einfache Fehler, wie das Drücken einer falschen Taste einfach zu erkennen. Fehlerhafte Parameter oder unzulässige Nutzung von Operationen können ebenfalls mit relativ wenig Aufwand erkannt werden. Deutlich schwieriger ist die Erkennung von logischen Fehlern. Hierzu muss bereits explizites Wissen über Anwendungsbedingungen vorhanden sein. Wünschenswert, aber ebenfalls schwierig ist das Feststellen einer suboptimalen Nutzung des Anwenders. Das Hilfesystem muss dafür aufwendige Mechanismen zur Wissensrepräsentation beinhalten. Diese Mechanismen sollen die Ziele des Benutzers erkennen und die von ihm ausgeführten Aktionen auf Optimalität prüfen. Werden Defizite festgestellt, aktiviert sich das Hilfesystem und weist den Anwender auf alternative Lösungswege hin. Diese Art der Hilfesysteme steht heute noch am Anfang ihrer Entwicklung. Aktive Hilfe ist vor allem bei unerfahrenen Benutzern einzusetzen. Experten benötigen diese Art der Hilfestellung nicht, werden u.U. sogar dadurch behindert (vgl. [ISO9241-13] S. 10). Aus diesem Grund muss der Benutzer die aktive Hilfe aus- und wieder einschalten können.

Im allgemeinen bieten Hilfesysteme ihre Informationen statisch an. D.h., dass die Inhalte vom aktuellen Zustand der Anwendung unabhängig sind. Das ist jedoch für den Benutzer unbefriedigend. Möchte dieser z.B. vom Hilfesystem Alternativen zur Fortführung des aktuellen Arbeitsstandes angezeigt bekommen, ist dies mit statischen Hilfeinformationen schwer zu lösen. Die Anfrage nach zur Zeit verfügbaren Operationen im Anwendungssystem stellt ein weiteres Anwendungsbeispiel für diesen Problembereich dar. Teilweise lässt sich das Problem mit Zugriffsstrategien umgehen, günstiger ist jedoch die dynamische Bereitstellung von Hilfeinformationen. Damit wird dem Benutzer ermüdendes Durchsuchen des Informationsraumes abgenommen. Ein dynamisches Hilfesystem muss bereits während der Entwicklung eingeplant werden, da es eine Repräsentation des Anwendungszustandes benötigt. Die dynamischen Hilfesysteme sind auch ein guter Ausgangspunkt, individuelle Hilfeinformationen anzubieten. So kann in Abhängigkeit der Benutzergruppe ein bestimmter Detaillierungsgrad der Hilfeinformation angeboten werden. Noch weiter geht der Ansatz, die bereits in Anspruch genommenen Hilfeleistungen eines einzelnen Benutzer zu protokollieren und bei weiterer Hilfeanforderung zu beachten. Der Ansatz der individuellen Hilfe unterstützt auch die dynamische Änderung und Erweiterung von Hilfeinformationen durch den Benutzer. So ist es wünschenswert, dem Anwender die Möglichkeit zu geben, eigene Texte und Hilfethemen hinzuzufügen (vgl. [ISO9241-13] S. 11).

Hilfesysteme sollten ihre Informationen grundsätzlich in einem eigenen Darstellungsbereich ausgeben. Das ermöglicht die parallele Nutzung von Anwendungs- und Hilfesystem. Außerdem wird damit der Ansatz unterstützt, Hilfesysteme anwendungsunabhängig zu entwickeln. Einerseits kann damit eine eigenständige, für Hilfesysteme typische Schnittstelle entwickelt werden, andererseits können damit die Hilfesysteme in verschiedensten Anwendungen wiederverwendet werden. Damit ist das Hilfesystem dem Benutzer auch und vor allem gerade bei neuen Anwendungssystemen bereits vertraut. Die Kostensenkung bei der Entwicklung ist ein positiver Nebeneffekt.

Zur Umsetzung von Hilfesystemen eignen sich im besonderen Maße Hypertext- bzw. Hypermediasysteme. Hypermediasysteme dienen zur Erkundung eines Informationsraum. Sie basieren auf multimedialen Datenbanken (vgl. [Komm+98] S. 3) Diese bestehen aus vernetzten Informationen, die in Text-, Grafik- und Tonform vorliegen können.

3.4.7 Fehlerbehandlung

Bei der Nutzung von Softwaresystemen treten, obwohl nicht gewünscht, Fehlersituationen auf. Diese definieren sich dadurch, dass der Benutzer das beabsichtigte Ziel nicht erreicht. Fehler können aufgrund von Funktionsstörungen des Anwendungssystems oder durch den Benutzer selbst verursacht werden (vgl. [ISO9241-13] S. 8). Eine Fehlhandlung des Benutzers weist auf eine mangelnde Anpassung zwischen Mensch und Computersystem hin. Im Rahmen dieser Arbeit wird auf die zweite Gruppe von Fehlern näher eingegangen. Generelle Aussagen über Darstellung und Behandlung lassen sich jedoch auch auf Systemfehler übertragen.

Grundsätzlich existieren zwei Strategien um mit einem Fehlerproblem umzugehen (vgl. [Kens+95] S. 219). Bei der Fehlervermeidung wird versucht, durch gutes Softwaredesign die Fehlerrate klein zu halten. Das Fehlermanagement zielt darauf ab, die Auswirkungen eines Fehlers möglichst gering zu halten. Dazu gehört sowohl die Vermeidung von Folgefehlern und negativen Effekten als auch die Minimierung des Fehlerbewältigungsaufwandes.

Die handlungstheoretische Fehlertaxonomie ist eine der bekanntesten Klassifizierungen von Fehlern (vgl. [Kens+95] S. 218 und [BrRu94] S. 199ff). Dabei werden sieben verschiedene Fehlhandlungen identifiziert. An dieser Stelle wird eine einfachere Aufteilung in lediglich zwei Klassen vorgenommen. Die Erste beruht auf der Unaufmerksamkeit des Benutzers. Dazu gehören die Gewohnheits-, Unterlassens- und Erkennensfehler der eben angesprochenen Fehlertaxonomie. Die bei hochautomatisierten Operationen auftretenden Bewegungsfehler sind ebenfalls dieser Klasse zuzuordnen. Die zweite Klasse geht auf ein mangelndes Verständnis des Benutzers zurück. Hierzu gehören vor allem Denk- und Urteilsfehler.

Die meisten Fehler treten bei Routinehandlungen auf und gehören ersterer Klasse an. Das liegt daran, dass bei "automatisierter" Abarbeitung von Aktionen die Aufmerksamkeit des Benutzer nachlässt. Es finden meist mehrere mentale Prozesse gleichzeitig statt, wobei es zu Interferenzen zwischen diesen kommen kann. Beispielsweise kann ein zu weites Vorausplanen zur Folge haben, dass der aktuelle Stand der Handlung vergessen wird. Im Rahmen der Fehlervermeidung kann diesen Fehlern durch das Einfügen von Kontrollpunkten entgegen gewirkt werden. Solche Kontrollpunkte können beispielsweise zusätzliche Eingabebestätigungen sein. Damit wird der Benutzer bewusst zur Aufmerksamkeit gezwungen. Kontrollpunkte sollten vor allem vor kritischen Aktionen eingefügt werden, d.h. Aktionen die bei unbedachter Ausführung schwerwiegende Folgen haben können. Bei Routinehandlungen können im allgemeinen effizient Fehlervermeidungsstrategien eingesetzt werden. Brodbeck und Rupietta nennen als wichtigste Techniken konsistente Dialoggestaltung, Einschränkung von Freiheitsgraden, Sicherheitsrückfragen und Sicherheitskopien (vgl. [BrRu94] S. 205ff).

Fehler aufgrund von mangelndem Verständnis sind durch das Anwendungssystem schwer zu erkennen. Hier muss durch ein gutes ergonomisches Design eine Vermeidung angestrebt werden. Vor allem der Einsatz einer adäquaten Metapher kann dabei unterstützend wirken. Ein umfassendes Hilfesystem kann dem Benutzer dabei helfen, sich vor der Ausführung von Operationen genauer über den Problembereich zu informieren.

Es ist jedoch unwahrscheinlich, eine vollständige Fehlervermeidung zu erreichen. Dies liegt auch daran, dass es durchaus Handlungen gibt, bei denen der Aufwand zur Bewältigung eines Fehlers geringer ist als die Vermeidung des Fehlers selbst. Die Beseitigung von Fehlern wird durch ein Fehlermanagement umgesetzt. Dieses umfasst die Fehlerentdeckung, Fehlererklärung und Fehlerbehebung. Grundsätzlich können Fehler sowohl vom Benutzer als auch vom System erkannt werden. Kann ein Fehler nur durch den Anwender entdeckt werden, sollten ihm entsprechende Diagnosewerkzeuge wie WYSIWYG-Editoren oder Vorschau- und Simulationsfunktionen zur Verfügung gestellt werden (vgl. [ISO9241-13] S. 9). Der Klärungsdialog wird in diesem Fall durch den Benutzer initiiert und stellt im allgemeinen das Hilfesystem dar. Wird der Fehler durch das System erkannt, sollte dies einen Klärungsdialog in Form einer Fehlermeldung initiieren (vgl. Anhang A.6). Diese muss vermitteln, was falsch ist, die Ursache nennen und Korrekturmaßnahmen beschreiben. Die Behebung des Fehlers kann ebenfalls sowohl durch das System selbst oder den Benutzer erfolgen. Die automatische Korrektur darf sich jedoch nicht der Kontrolle des Anwenders entziehen. Im Rahmen des Fehlermanagement sollte eine Undo-Funktion angeboten werden.

In einer empirische Studie wurden bei der Nutzung einer Adresslösung 305 Nutzungsprobleme festgestellt (vgl. [Kens+95] S. 222ff). In der anschließenden Auswertung konnten für 210 (68,9%) Fehlervermeidungs- und für 295 (96,7%) Fehlermanagementvorschläge entwickelt werden. Der Fehlerbehandlung sollte demzufolge vor allem im Rahmen der Evaluierung eine entsprechend hohe Priorität eingeräumt werden.

3.4.8 Individualisierung

Ein Softwaresystem wird für eine Vielzahl von unterschiedlichen Benutzern entwickelt. Wie bereits in Abschnitt 3.2.2 beschrieben, können diese in Benutzergruppen gegliedert werden. Eine Anpassung der Benutzungsschnittstelle an diese Gruppen wird bereits während der Entwicklung des Softwaresystems vorgesehen. Die konkrete Arbeitssituation kann jedoch trotz intensiver Aufgaben- und Benutzeranalyse nicht von vornherein umfassend beschrieben werden (vgl. [Oppe94] S. 236). Daraus ergibt sich, dass die angebotene Schnittstelle im Einzelfall nicht optimal ist. Um maximale Effizienz zu ermöglichen, muss die Benutzungsschnittstelle anpaßbar sein. Die dabei auftretenden Aspekte werden unter dem Begriff Individualisierung von Benutzungsschnittstellen zusammengefasst. Oppermann weist auf einen weiteren Grund für Individualisierung hin. So beinhaltet ein vollkommenes Fehlen von Freiheitsgraden die Gefahr der Abstumpfung und Dequalifizierung des Benutzers. Ein zu hoher Grad Individualisierung ohne Strukturierungshilfe führt dagegen zu Orientierungslosigkeit und ist demzufolge ebenfalls zu vermeiden.

Grundsätzlich lassen sich zwei Arten von Individualisierung bestimmen. Wird die Anpassung vom Benutzer selbst vorgenommen, spricht man von adaptierbaren Benutzungsschnittstellen (vgl. [Herc94] S. 175ff). Die zweite Möglichkeit besteht in der Anpassung durch das Softwaresystem selbst. In diesem Fall liegt eine adaptive Benutzungsschnittstelle vor. Ähnlich wie bei den Hilfesystemen, befindet sich diese Form noch in einem frühen Entwicklungsstadium.

Eine Individualisierung kann auf verschiedenen Ebenen stattfinden. Die einfachste Form ist die Anpassung des Anwendungssystems in seinem Erscheinen. D.h., der Benutzer wählt nach seinen Präferenzen Farben, Schriftarten, Sprache, Positionen einzelner Bildschirmelemente u.a. aus (vgl. Abbildung 5). Das Anwendungssystem sollte am Anfang sinnvolle Voreinstellungen anbieten. Diese Einstellungen können dann je nach Bedarf in einem einfachen Dialog durch den Benutzer geändert werden. Die Festlegung von Synonymen stellt ebenfalls eine einfache Form der Individualisierung dar. So können bestimmte Funktionsbezeichnungen bei Benutzern falsche Assoziationen auslösen. Durch einfaches Umbenennen kann dieses Problem gelöst werden. Eine weitere Form der Individualisierung ist die Vorgabe von Standardwerten durch den Benutzer. Dies ist vor allem bei Eingaben in Masken zweckmäßig. Durch geschickte Vorgaben lassen sich erhebliche Effizienzsteigerungen erreichen. Eine sehr mächtige Art der Individualisierung ist die eigene Definition von Operationen. Im alltäglichen Arbeitsablauf werden bestimmte Sequenzen von Operationen immer wieder ausgeführt. Fasst man diese einzelnen Schritte zu einem einzigen zusammen, erhält man ein Makro. Für das Erstellen von Makros wird der entsprechende Arbeitsablauf aufgezeichnet und mit einem Namen versehen. Der Benutzer kann nun unter diesem Namen die einzelnen Operationen mit einer einzigen Aktion auslösen. Kann man die Makros parametrisieren wird dieser Mechanismus noch leistungsfähiger. In umfangreichen Anwendungssystemen werden heute ganze Makrosprachen integriert. Das bedeutet, dass der Benutzer eigene Programme schreiben kann. Der Übergang vom reinen Makro bis zur Programmierung ist also fließend.

Oft wird vom Softwaresystem ein Mechanismus angeboten, der die Einstellung von Modi erlaubt. So kann der Benutzer durch eine einzige Einstellung eine Vielzahl an Individualisierungsmöglichkeiten durch das System vornehmen lassen. Beispielsweise wird in einem Anfänger-Modus üblicherweise der Funktionsumfang eingeschränkt und die Interaktionsinitiative hauptsächlich auf Seite des Softwaresystems liegen.

Die verschiedenen Formen der Individualisierung verlangen vom Benutzer entsprechende Fähigkeiten. Zu ihrer Realisierung werden Dialoge benötigt, die die Komplexität des Anwendungsprogramms steigern. Es ist bei der Benutzer- und Aufgabenanalyse klar festzustellen, welcher Grad der Individualisierung sinnvoll und dem Benutzer zumutbar ist.

Im dem hier gezeigten Beispiel kann der Benutzer bestimmte Farben einstellen. Diese einfache Form der Individualisierung ist heute in fast jedem Softwaresystem verfügbar. Für den Farbdialog wurde eine Standardkomponente benutzt. Die hier englischen Beschreibungen müssen noch durch Deutsche ausgetauscht werden.

 © yves köth