Design von Benutzerschnittstellen bei kooperativen Computerspielen am Beispiel von 'Campus Couples'

Inhaltsverzeichnis

1.Einleitung

2. User-Interface-Design
2.1. Einleitung
2.2. Was ist eine Benutzerschnittstelle?
2.3. Formen des Dialogs
2.3.1. Kommandosprachen und Menüs
2.3.2. Direkte Manipulation
2.4 Regeln, Normen und Richtlinien
2.4.1 Usability und die DIN EN ISO 9241
2.4.2 Benutzerzentrierte Softwaregestaltung
2.4.3 Heuristiken
2.4.3.1 Usability Guidelines nach Molich und Nielson
2.4.3.2 Die acht goldenen Regeln des Dialogdesigns von Shneiderman
2.4.3.3 Die Norm DIN EN ISO 9241 - Teil 10
2.5. Evaluationsmethoden
2.5.1. Die GOMS Methode
2.5.2. Keystroke Level Modell (KLM)
2.5.3. Usability Tests
2.5.4. Usability Inspections
2.6. Ergonomische & hedonistische Qualität
2.7. Icons
2.8. Die Verwendung von Farben
2.9. Menüs
2.10. Formulareingaben

3. Kooperative Systeme

4. Gestaltung der grafischen Benutzerschnittstelle von Campus Couples
4.1. Einleitung
4.2. Praxisprojekte im Studiengang Kommedia
4.3. Ziel des Projektes Game-Design (Computerspiele)
4.4. Die Spielidee
4.5. Die Zielgruppe
4.6. Elemente der Benutzerschnittstelle
4.7. Die kollaborative Lernumgebung „Cool Modes“
4.8. Das Spielfeld
4.9. Die Spielfiguren
4.10. Die Navigationsleiste
4.11. Der Spielbeginn
4.12. Das Campus-Radio
4.13. Das Betreten der Gebäude
4.14. Frage-Antwort Dialoge
4.15. In-Games
4.16. Einen Partner finden
4.17. Die zweite Spielphase
4.18. Was hätten wir besser machen können?

5. Verbesserungsvorschläge für die Benutzerschnittstelle

6. Literaturverzeichnis

1. Einleitung

Heutzutage ist nahezu alles vernetzt. Über das Internet kann man in sekundenschnelle Kontakt zu Menschen auf der ganzen Welt aufnehmen. Firmen koordinieren und erleichtern ihren Mitarbeitern im hauseigenen Intranet Arbeitsabläufe und Computerspiele spielt man nicht mehr alleine, sondern in Netzwerken oder im Internet. Da scheint es ratsam Computerprogramme, die zu diesem Zweck verwendet werden auch dahingehend auszulegen, um dem Nutzer die Arbeit zu erleichtern, oder wenigstens nicht unnötig zu erschweren. Doch weit gefehlt. Die heutigen Programme sind meist aufgrund ihrer Funktionsvielfalt unnötig kompliziert, unübersichtlich und lassen sich oft nur nach monatelangem Training vollständig beherrschen. An dieser Stelle würde ich gerne ein kleines Beispiel anführen, um die Problematik zu verdeutlichen.

Vor nicht all zu langer Zeit habe ich mich mit meiner Freundin spontan dazu entschlossen, eine Last-Minute Reise zu buchen und für ein paar Tage zu verreisen. Ich schaute also im Internet nach und wurde nach nicht all zu langer Suche fündig. Ich dachte mir, dass es kein allzu großes Problem sein sollte, die Reise direkt im Internet zu buchen und am nächsten Tag die Tickets am Flughafen abzuholen. Das Gegenteil war der Fall. Nachdem ich mich nach einigen Fehlversuchen durchgerungen hatte, die Hotline des Anbieters anzurufen, verwies mich der Herr am Telefon an eine Filiale des Reiseunternehmens in meiner Nähe. Ich ging davon aus, dass es wahrscheinlich sicherer und unkomplizierter sein würde, die Reise direkt im Reisebüro zu buchen. Unkompliziert war es auch. Jedoch nur bis zu dem Zeitpunkt, an dem Buchungssoftware und ein unerfahrener Mitarbeiter zusammenstießen. Der junge Herr hatte offensichtlich keine Ahnung, wie er die Reise zu buchen und die Tickets zu drucken hatte. Als ich einen Blick auf den Computerbildschirm warf, verstand ich auch warum. Die Oberfläche des Programms war übersät mit unübersichtlichen Textfeldern, Pulldownmenüs und anderen undurchschaubaren Funktionen. Zum Bedienen des Programms müsste man eine mehrwöchige Ausbildung absolvieren. Der Herr hatte nach eigener Aussage jedoch nicht einmal eine Einführung für die Software erhalten, und so kam es, dass er, oder das Programm nicht wenige Fehler machte. So war er sich unsicher, ob das Programm nach mehrmaligem Eingeben der Daten nun endlich die Tickets ausdrucken würde und legte zu Testzwecken statt eines leeren Tickets, ein normales Blatt Papier in den Drucker. Der Drucker druckte das Ticket. Jedoch nur einmal. Als er es dann auf einen Ticketvordruck drucken lassen wollte, verweigerte das Programm die Ausführung des Auftrags, denn das Ticket wurde ja schließlich schon gedruckt. Als ich ihm vorschlug, dem Programm den Befehl zu erteilen, es nochmals auszudrucken, sagte er, dass dies nicht ginge und schrieb eine e-mail an den Fehlerservice des Unternehmens. Diese ließen sich mit ihrer Antwort, dass es jetzt wieder funktionieren sollte, nicht wenig Zeit. Trotzdem funktionierte es nicht. Geschlagene drei Stunden später hielt ich dann endlich die Tickets in der Hand und konnte zum Packen nach Hause fahren. Was schließlich zum Erfolg geführt hatte, waren einige Anrufe in der Firmenzentrale, die das Problem daraufhin manuell behoben. Ohne Buchungssystem wäre es wahrscheinlich um ein Vielfaches schneller gewesen, die Reise zu buchen.

Lange Rede, kurzer Sinn. Die Benutzeroberfläche des Buchungsprogramms war äußerst unübersichtlich gestaltet, so dass es dem Mitarbeiter schwer fiel, das Programm fehlerfrei zu bedienen. Hätte er eine angemessene Ausbildung für die Buchungssoftware genossen, wären ihm wahrscheinlich weniger Fehler unterlaufen. Dies wäre allerdings zu teuer und würde damit nicht zur Unternehmenspolitik passen. Besagtes Unternehmen investiert laut Auskunft des Mitarbeiters nicht in die notwendige Ausbildung, sondern stellt gegenüber seinen Mitarbeitern bei fehlerhaftem Verschulden Regressansprüche.

Ich hoffe, durch dieses kleine Beispiel ist deutlich geworden, wie wichtig das Design von Benutzerschnittstellen bei kooperativen Computerprogrammen ist, und was ein schlechtes Design für negative Konsequenzen nach sich ziehen kann. In meinem Fall waren der Herr im Reisebüro und ich als Kunde diejenigen, die dadurch Nachteile hatten. Die Firma hat ihr Geld trotzdem bekommen, denn mir ging es ja darum zu verreisen und wenn man nicht gerade jede Woche eine Reise bucht, kann man über solche Schwierigkeiten schon mal hinwegsehen.

Wie sieht es jedoch bei Programmen wie Computerspielen aus, bei denen der Spielspaß des Anwenders das erworbene Produkt darstellt? Hierbei bietet sich keine Möglichkeit, ein schlechtes Interface-Design durch firmenpolitische Gegenmaßnahmen auszugleichen. Das Spiel würde schlicht und einfach nicht gekauft werden. Genau dieser Problematik wird sich mein Abschlussbericht über die Projektarbeit „Game-Design (Computerspiele)“ mit dem Titel „Design von Benutzerschnittstellen bei kooperativen Computerspielen am Beispiel von Campus Couples“ widmen.

2. User-Interface-Design

2.1. Einleitung

Der Bereich des User-Interface-Designs ist sehr komplex und bietet eine Fülle von unterschiedlichen Ansätzen und Richtlinien zur Entwicklung von Schnittstellen zur Mensch-Maschine-Interaktion. Spezielle Literatur zum Thema „Design von Benutzerschnittstellen bei kooperativen Computerspielen“ existiert nicht. Bücher, die das Design von User-Interfaces behandeln, beziehen sich meist auf das gesamte Spektrum der Softwarelandschaft und bieten allgemeine Beispiele zur Orientierung. Im Folgenden stelle ich die für die Entwicklung von kooperativen Computerspielen wichtigsten Grundlagen und Methoden des User-Inteface-Designs vor. Dabei werde ich allgemeine Richtlinien und festgelegte Normen aufzeigen und Methoden zur Evaluation präsentieren.

2.2. Was ist eine Benutzerschnittstelle?

Der Begriff Schnittstelle (engl. Interface) bezeichnet allgemein eine Übergangs- und Verbindungsstelle zwischen zwei Systemen. Man unterscheidet dabei zwischen der Mensch-Maschine- und der Maschine-Maschine-Schnittstelle. Als Mensch-Maschine- Schnittstellen werden z.B. Eingabegeräte wie Maus, Tastatur und Joystick und Ausgabegeräte wie Bildschirm, Drucker und Lautsprecher bezeichnet. Maschine- Maschine-Schnittstellen sind z.B. der parallele Druckeranschluss oder die serielle Schnittstelle, an die die Maus angeschlossen wird. Sie gewährleisten den Datenaustausch der Hard- und Software untereinander und mit den Peripheriegeräten.

Eine Benutzerschnittstelle (engl. User-Interface), bzw. Benutzungsschnittstelle ist der Bereich eines Systems oder einer Maschine, der dem Menschen zur Steuerung zur Verfügung steht. Dabei muss es sich nicht immer um grafische Benutzerschnittstellen (engl. Graphical User Interface, kurz: GUI) handeln, welche Informationen in grafischer Form ausgeben und für die Kommunikation ein Zeigegerät benötigen. Gibt man einem Programm z.B. Befehle mit Hilfe der Tastatur, handelt es sich um eine Befehlszeilenschnittstelle. Benutzerschnittstellen können grafisch, textuell, verbal oder akustisch gestaltet sein. Selbst eine Schnittstelle über den Geruchssinn wäre denkbar. Das „Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik (FIRST)“ entwickelte mit dem im März 2004 auf der CEBIT vorgestellten Brain-Computer- Interface (BCI) sogar eine direkte Schnittstelle zwischen menschlichem Gehirn und Computer. Dabei nimmt ein EEG Gehirnströme auf, die ein lernfähiges Computersystem analysiert und in Steuerungssignale weiterverarbeitet (10.03.2004, www.heise.de).

Jef Raskin, einst Koordinator des Apple Macintosh Projekts und Autor des Buches „The Human Interface“ (2001) geht mit seiner Definition des Begriffs Benutzerschnittstelle jedoch noch einen Schritt weiter. Seiner Meinung nach bezeichnet dieser „nämlich die Art und Weise, wie ein Produkt eine bestimmte Aufgabe ausführt - also was der Benutzer tun kann und wie das System darauf reagiert“ (Raskin, 2001). Damit erweitert er die Definition des Begriffs insofern, dass er seiner Bedeutung mehr beiwohnt als nur die bloße Verknüpfung zwischen Mensch und Maschine.

2.3. Formen des Dialogs

Generell lassen sich drei verschiedene Arten des Dialogs zwischen Mensch und Computer unterscheiden:

- benutzergeführter Dialog (z.B. Kommandosprachen)
- systemgeführter Dialog (z.B. Menüs und Formulare)
- hybrider (gemischter) Dialog (z.B. direkte Manipulation)

2.3.1. Kommandosprachen und Menüs

Bei der Kommandosprache handelt es sich um einen benutzergeführten Dialog, da der Anwender agiert und das System reagiert. Hierbei erteilt der Benutzer dem System klare, in einer speziellen Syntax festgelegte Befehle. Ältere Betriebssysteme wie DOS und UNIX verwendeten ausschließlich diese Form des Dialogs, welche für Experten sehr geeignet ist, da sie mächtig, schnell und effizient ist. Für ungeübte Anwender sind Kommandosprachen jedoch gänzlich ungeeignet, da sie schwer zu erlernen sind und das System kaum Hilfe bei der Frage, wie man was machen kann, bietet. Ein Computerspiel mit dieser Form des Dialogs zu entwerfen, wäre wohl eher nostalgisch als zeitgemäß. Sinnvoller erscheint die Verwendung einer systemgeführten Dialogform, wie der des Menüs. Hierbei agiert das System, indem es dem Anwender Auswahlmöglichkeiten präsentiert und dieser eine Auswahl trifft. Der Vorteil für ungeübte Anwender liegt mit dem minimalen Eingabeaufwand auf der Hand.

2.3.2. Direkte Manipulation

Der Begriff „Direkte Manipulation“ wurde 1983 von Ben Shneiderman eingeführt und bezeichnet die am weitesten verbreitete Form des Dialogs zwischen Mensch und Computer. Hierbei handelt es sich um einen gemischten Dialog, da Benutzer und System abwechselnd agieren und reagieren. Ein gutes Computerspiel ohne direkte Manipulation zu entwerfen ist wohl kaum möglich. Selbst die ersten Spiele Anfang der 70er Jahre wurden fast ausnahmslos mit Hilfe der direkten Manipulation gesteuert. Sie ermöglicht es dem Anwender direkt, z.B. per Maus, mit den visuellen Objekten auf dem Bildschirm zu kommunizieren.

Merkmale direkter Manipulation sind (Shneiderman, 1987):

- Die permanente Darstellung des zu manipulierenden Objekts.
- Physische Interaktion (Zeigen, Ziehen etc.), anstelle des Eintippens von Befehlen einer vorgegebenen Manipulationssprache.
- Unmittelbar sichtbare Operationen am Objekt, die bei Bedarf auch wieder rückgängig zu machen sind.

2.4 Regeln, Normen und Richtlinien

2.4.1 Usability und die DIN EN ISO 9241

Die software-ergonomische Qualität eines Produkts wird meist mit dem neudeutschen Begriff „Usability“ beschrieben. Dabei handelt es sich um nichts anderes als die Gebrauchstauglichkeit, Bedienbarkeit oder Benutzungsfreundlichkeit eines Programms. Da die Benutzerschnittstelle heutzutage von Anwendern häufig als das eigentliche Produkt angesehen wird und besonders bei Computerspielen nicht mehr nur als vermittelndes Medium zwischen Software und Mensch dient, ist es bei der Gestaltung eines User-Interfaces für ein kooperatives Computerspiel unumgänglich, sich der ausschlaggebenden Faktoren der Usability für ein erfolgreiches Produkt bewusst zu sein. Diese wurden in der internationalen Norm für Hard- & Software-Ergonomie DIN EN ISO 9241 festgelegt.

Danach ist Usability (DIN EN ISO 9241, Teil 11)

„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.“ (Eichinger, 2004)

Beim Betrachten dieser Definition sollte man folgendes hervorheben (Burmeister, Hassenzahl, Machate, 2000):

- Mit Effektivität ist die Genauigkeit und Vollständigkeit gemeint, mit der der Benutzer sein Ziel erreicht.
- Effizienz meint das Verhältnis von Aufwand und Effektivität bei der Erreichung des Ziels.
- Zufriedenstellend bedeutet, dass der Benutzer frei von Beeinträchtigung ist und eine positive Einstellung gegenüber der Nutzung des Produkts hat.
- Der Nutzungskontext beschreibt die Ziele, Aufgaben, die Ausrüstung sowie die physische und soziale Umgebung, in der das Produkt genutzt wird.

Außerdem ist hierbei zu beachten, dass (Eichinger, 2004):

- Usability demnach nicht allein die Eigenschaft eines Produktes ist, sondern das Attribut einer Interaktion eines Benutzers mit einem Produkt innerhalb eines bestimmten Kontextes, und
- die Usability eines Produktes nicht ohne weiteres auf andere Benutzer des gleichen Produktes übertragen werden kann.

2.4.2 Benutzerzentrierte Softwaregestaltung

Beim Software-Entwurf sollte man also generell besonderen Wert auf die Berücksichtigung der s.g. „Human Factors“, der menschlichen Faktoren legen. Gemeint ist eine benutzerzentrierte Gestaltung des Programms. Shneiderman (2002) schlägt folgende messbare Faktoren vor, die Kern der Evaluation sein sollten:

1. Lernzeit
2. Ausführungszeit
2. Fehlerquote bei Nutzern
3. Erinnerungsvermögen
4. Subjektive Befriedigung

Die Norm DIN EN ISO 13407 baut auf den oben genannten Prinzipien der DIN EN ISO 9241 Teil 11 auf und beschreibt, wie ein benutzerzentrierter Organisations- und Gestaltungsprozess idealerweise auszusehen hat.

Dieser umfasst folgende Phasen (Burmeister, Hassenzahl, Machate, 2000):

1. Feststellung der Notwendigkeit

- Ist ein benutzerzentrierter Gestaltungsprozess überhaupt nötig?

2. Erhebung und Analyse des Nutzungskontextes

- Empirische Analyse der Aufgaben und Ziele des Benutzers

3. Ableiten und Dokumentieren von Anforderungen an das Softwaresystem

- Was muss das System unter Berücksichtigung des Nutzungskontextes können?

4. Entwurf eines Bedienkonzeptes

- Überführung der Anforderungen in die tatsächliche Benutzeroberfläche
- Erst, Grobgestaltung der Navigationsstruktur, Informationspräsentation und der Metaphern
- Dann, Feingestaltung der einzelnen Elemente

5. Empirische Evaluation des Bedienkonzeptes

- Testen der Gebrauchstauglichkeit durch Usability-Tests
- Umgestaltung und Optimierung der Benutzeroberfläche

2.4.3 Heuristiken

Bei Heuristiken handelt es sich um allgemeine Gestaltungsrichtlinien, die den Entwicklern beim Entwerfen einer Software und ihrer Benutzerschnittstelle als Orientierungshilfe dienen sollen. Des weiteren sind Heuristiken Grundlage der Evaluationsmethoden die in Kapitel 3.5. dieses Berichts thematisiert werden. Heuristiken sind meist sehr allgemein formuliert, um sie universal, für jede Art von Software anwendbar zu machen. Empfehlenswert ist es, sich beim Entwurf einer Software eigene Richtlinien zu formulieren oder bereits existierende Heuristiken auf die Anforderungen, die an die zu entwerfende Software gestellt werden, abzustimmen. Es existiert eine große Variation von verschiedenen Guidelines, die über die Jahre immer weiter verfeinert wurden. Um einen umfassenden Einblick in die Thematik zu bieten, werde ich im Folgenden kurz die drei wichtigsten Richtliniensammlungen vorstellen.

2.4.3.1 Usability Guidelines nach Molich und Nielson

Die folgenden Prinzipien wurden von Molich und Nielson (1990) aufgestellt:

Einfacher und natürlicher Dialog

- keine unnötige Information (weniger ist mehr)
- Information sollte in einer natürlichen und logischen Reihenfolge präsentiert werden

Verwende die Sprache des Anwenders

- Verwendung von natürlicher, statt Systemsprache

Minimiere die Erinnerungsleistung des Benutzers

- der Anwender sollte sich innerhalb eines Dialogs nicht an vorher präsentierte Information erinnern müssen
- Hilfe zur Benutzung des Systems sollte leicht zu finden sein

Konsistenz

- der Benutzer sollte sich nicht fragen müssen, ob verschiedene Worte, Situationen oder Aktionen das Gleiche bedeuten.

Feedback

- das System sollte den Benutzer immer darüber informieren, was gerade passiert

Eindeutig gekennzeichnete Ausgänge

- der Anwender sollte immer die Möglichkeit haben, einen versehentlich gestarteten Dialog zu beenden

Shortcuts

- Experten können so die Interaktion mit der Software beschleunigen.

Gute Fehlermeldungen

- sie sollten in einfacher Sprache formuliert werden, das Problem eindeutig beschreiben und einen konstruktiven Vorschlag zur Behebung vorschlagen.

Fehlern vorbeugen

- noch besser als gute Fehlermeldungen ist es, Fehlern vorzubeugen und sie so erst gar nicht entstehen zu lassen.

Hilfe und Dokumentationen

- obwohl es besser wäre, wenn ein System ohne Hilfe benutzt werden könnte, muss dem Benutzer Hilfe angeboten werden. Diese Hilfe sollte leicht zu finden sein, sich auf die Aufgaben des Anwenders konzentrieren und nicht zu lang sein.

2.4.3.2 Die acht goldenen Regeln des Dialogdesigns von Shneiderman

Bei dem Design von Benutzerschnittstellen sollten nach Shneiderman folgende Richtlinien beachtet werden (2002):

1. Versuche Konsistenz zu erreichen

- konsistente Handlungssequenzen in ähnlichen Situationen
- Verwendung von einheitlichen Symbolen, Schriftarten, Farben etc.

2. Biete erfahrenen Benutzern Abkürzungen an

- Shortcuts wie besondere Tasten, versteckte Kommandos etc.
- Kurze Antwortzeiten und schnelle Anzeigeraten

3. Biete informatives Feedback

- Feedback für jede Anwenderhandlung
- Knappe Antwort bei regelmäßigen, ausführliche Antwort bei wichtigen Handlungen
- Visualisierung der interessanten Objekte (direkte Manipulation)

4. Dialoge sollten in sich abgeschlossen sein

- Handlungssequenzen in Gruppen mit Anfang, Mitte und Ende organisieren
- Geben dem Benutzer bei Beendigung der Handlung ein Zufriedenheitsgefühl und schaffen neue Ressourcen für die nächste Aufgabe.

5. Das Umgehen mit Fehlern sollte einfach gestaltet sein

- System darf schwerwiegende Fehler des Users erst gar nicht zulassen
- Gebe bei Fehlern Korrekturvorschläge

6. Biete eine einfache Umkehr von Aktionen

- Undo-Funktionen schaffen Sicherheit und nehmen die Angst, Funktionen einfach auszuprobieren

7. Ermögliche interne Kontrolle

- Überraschende Aktionen des Systems vermeiden
- Informationsabruf einfach gestalten
- Einfaches Ausführen von Aktionen

8. Reduziere die Belastung des Kurzzeitgedächtnisses

- Kapazität des Kurzzeitgedächtnisses beträgt 7, plus oder minus 2 Objekte
- einfache Anzeigeinhalte bieten
- Hilfeoption für Syntax, Abkürzungen und Codes

Diese Regeln können natürlich nur als Orientierungshilfe angesehen werden. Qualitätsstandards und Richtlinien festzuschreiben, ist aufgrund des rasanten technischen Fortschritts nur bedingt möglich. Im Zweifel muss immer für den Einzelfall entschieden werden, was am Sinnvollsten ist. Nicht alles, was im ersten Moment für den Anwender hilfreich erscheint, muss auch in der Praxis so sein. Dennoch wurde mit der Norm DIN EN ISO 9241 - Teil 10, ein Versuch der Standardisierung unternommen.

2.4.3.3 Die Norm DIN EN ISO 9241 - Teil 10

In Teil 10 der DIN EN ISO 9241 werden sieben, bei der Gestaltung von Software zu beachtende Grundsätze definiert und beschrieben. Diese beziehen sich zwar auf die Anforderungen von Bürotätigkeiten, sind jedoch problemlos auf andere Software, wie z.B. Webseiten oder ein Computerspiel zu übertragen.

Folgende Gestaltungsgrundsätze sind in Teil 10 der DIN EN ISO 9241 enthalten (Baggen, 2003):

Aufgabenangemessenheit

- Es müssen alle erforderlichen Funktionen vorhanden sein
- Nutzer sollten vom System entlastet werden
- Unterstützung von Routineaufgaben
- Vorgabe von Standardwerten
- Anpassung von Ein- und Ausgabe an Aufgabe und Benutzer

Selbstbeschreibungsfähigkeit

- Rückmeldungen vom System
- Einheitliche Terminologie
- Hilfefunktionen

Steuerbarkeit

- Dialogkontrolle muss beim Benutzer liegen
- Undo Funktionen
- Flexible Arbeitsabläufe des Benutzers
- Alternative Eingabemöglichkeiten (z.B. Tastatur oder Maus)

Erwartungskonformität

- Interne Konsistenz von Interaktion und Informationsdarstellung
- Ähnliche Dialoge bei ähnlichen Aufgaben
- Berücksichtigung bekannter Konzepte des gleichen Anwendungsfeldes

Fehlertoleranz

- Das System sollte den Benutzer bei der Vermeidung von Eingabefehlern unterstützen
- Aussagekräftige Fehlermeldungen und Vorschläge für Korrekturen
- Minimierung des Korrekturaufwandes

Individualisierbarkeit

- Anpassbarkeit an den Arbeitsstil des Benutzers

Lernförderlichkeit

- Stufenweises Erlernen ermöglichen (Tutorials, Hilfefunktionen etc.)
- Die Komplexität des Systems nachvollziehbar und beherrschbar machen

2.5. Evaluationsmethoden

2.5.1. Die GOMS Methode

Die GOMS Methode wurde 1983 von Card, Moran und Newell entwickelt und dient zur Modellierung der Aufgabenbearbeitung in einem System. Das Modell unterteilt den Bearbeitungsprozess einer Aufgabe in Goals (Ziele), Operators (Operatoren), Methods (Methoden) und Selections (Auswahlregeln) und ermöglicht Vorhersagen darüber, wie lange ein durchschnittlicher Anwender benötigt um eine bestimmte Anzahl von Aktionen auszuführen. Es existieren verschiedene Varianten des GOMS-Modells. Das Einfachste und Schnellste ist das s.g. Keystroke- Level Modell (Tastatureingabe- Modell), welches ich im Folgenden etwas ausführlicher vorstellen werde, das komplexeste das Critical-Path-Modell (CPM-GOMS). Des weiteren wurde von Kieras (1988) mit der Natural-GOMS-Language (NGOMSL) eine Methode vorgeschlagen, die in natürlicher Sprache formuliert wird und sich daher besonders für die Entwicklung von Manuals und Hilfefunktionen eignet (vgl.: Shneiderman, 2002).

2.5.2. Keystroke Level Modell (KLM)

Das Keystroke-Level Modell basiert auf Mittelwerten der Zeit, die ein Benutzer benötigt, um einzelne Schritte bei der Erfüllung einer Aufgabe auszuführen. Diese Zeitfaktoren ermittelten Card, Moran und Newell (1983) in einer sorgfältigen Laboruntersuchung (vgl.: Raskin, 2001).

- H = Homing = 0,4 Sekunden:

Zeit die benötigt wird, um die Hand von der Maus zur Tastatur oder umgekehrt zu bewegen.

[...]