Zurück zur Übersicht
Eine Einführung in die Analyse eines User Interface mittels GOMS
Benjamin Kunze
Ludwig-Maximilian-Universität München
Im Zuge der Lehrveranstaltung Mensch-Maschine-Interaktion1
Leitung: Albrecht Schmidt - HCI-Lab des Lehrstuhls Medieninformatik
12 November 2005
Abstract:
Das sogenannte GOMS Modell, eines der ersten theoretischen Konzepte Bedienungsschnittstellen
in der Computerwelt methodisch zu analysieren, etablierte sich schon Mitte der
80er. Die mittlerweile in die Jahre gekommene Theorie revolutionierte die Daseinsberechtigung
professioneller Benutzerschnittstellen und sorgte für Ernüchterung
bei benutzerunfreundlicher Implementierung. Zu Beginn dieses Essays werden die
Grundzüge und Realisierung des Modells vorgestellt und zu Schluss ein Überblick
über die Weiterentwicklung von GOMS beschrieben.
Was ist GOMS?
Das GOMS Modell wurde 1983 von Card, Moran und Newell entwickelt. Ziel war die
Entwicklung einer Methode, die es erlaubt Vorhersagen zu treffen, inwieweit
ein User gewisse Vorkenntnisse besitzen muss, um Aufgaben innerhalb eines Systems
oder Interface lösen zu können. Dabei steht das Synonym GOMS für
„ Goals, Operators, Methods and Selection Rules“. Zitat : “
It is useful to analyze knowledge of how to do a task in terms of the components
of goals,
operators, methods, and selection rules” (Bonnie E. John & David E.
Kieras, 1994). Nun gibt es in jedem System Ziele, die es zulösen gilt,
Methoden, wie man diese Ziel erreicht, Operationen, also kleine Schritte, die
einen zu nächsten Ebene weiterführen und Regeln , die einem bei einer
Auswahl von Lösungsmöglichkeiten den richtigen Weg zeigen. Sollte
es zum Beispiel mehrere Möglichkeiten geben eine Aufgabe zu erfüllen,
dann gibt es demzufolge mehrere Zwischenschritte, die erfüllt werden müssen,
also demnach auch untergeordnete Methoden und Operationen, die diese Schritte
erledigen.
So lässt sich also Schritt für Schritt ein System in logische Handlungen
und Möglichkeiten unterteilen, die es dann gilt auf „Usability“,
also auf Nutzungs- und Navigationsfähigkeit zu überprüfen.
Ein typische GOMS Modell stellt also den Ablauf/Prozedur einer Handlung zwischen
dem User und dem System dar und ermittelt dabei die Effizienz und Konsistenz
der vorliegenden Schritte.
Diesem Ablauf liegt allerdings eine gründlegende Analyse des System zugrunde,
der sogenannten „Task Analysis“, also was sind eigentlich die Ziele
des Users, was sind essentielle Schritte, Operationen und Aspekte und welche
sind von geringerer Bedeutung?
Die Operationen werden hierbei mittels der Betrachtung der untersten Ebene eines
System ermittelt, wie beispielsweise der Hardwareausstattung. Entsprechende
Regeln, also die eben erwähnten „Selection Rules“, werden meist
subtil aus dem Kontext erschlossen. Sollten dabei mehrere Möglichkeiten
existieren eine Aufgabe zu bewältigen, liegt die Kunst eines guten Interface,
in der intuitiven Auswahl der geeigneten Methode. Eindeutige Ziele zu bestimmen
sind dagegen relativ schwierig zu definieren, da der jeweilige Nutzungsrahmen
des Systems mit eingebracht werden muss, d.h. in welchen Kontext wird das Programm
an diesem Ort von jener Person ausgeführt. Die Methoden liegen verständlicher
Weise der Funktionalität des Systems zugrunde, also welche Funktionen,
Operationen etc. von Haus aus angeboten werden.
Doch das GOMS-Modell an sich setzt die Resultate der eben genannten Analyse
voraus, ohne dabei groß auf Rahmenbedingungen, wie menschliche Faktoren
und Umwelteinflüsse einzugehen. Der Grund hierfür liegt sicherlich
in der damalig-vorherrschenden Sichtsweise des Behaviorismus-Konzepts, welches
das menschliche Innenleben als nicht-erfassbares schwarzes Loch bezeichnete,
um so das damals einzig Messbare, nämlich das Handeln, analysieren zu können.
Die GOMS Familie
Im Laufe der Jahre entwickelte sich das Modell natürlich weiter, verfeinerte
seine Methoden, Aspekte und Herangehensweisen. Generell spricht man von zwei
großen konzeptionellen Richtungen: Zum einen das Modell als in sequentieller
Form und zum andern in Programmform darzustellen.
Die zweite Variante teilt das System aufgabenorientiert in mehrere Klassen mit
verschiedenen Methoden ein mit deren Hilfe der sogenannte „Task“
erfüllt werden kann. „ A program form model is a compact, generative
description that
explicitly represents the knowledge of what features of the task environment
the user should attend to and how the user should operate the system to accomplish
the task goals.” (Bonnie E. John & David E. Kieras, 1994)
Die sequentielle Variante veranschaulicht dagegen eine bestimmte Aufgabenstellung
mit Hilfe von sequentiell angeordneten, festgelegten Operatoren die nacheinander
abgearbeitet werden müssen, wobei auch situationsabhängige Bedingungen
und Parameter miteinbezogen werden.
In einer grafischen Gliederung veranschaulichen John & Kieras das Konzept
der GOMS Familie durch drei große Teilaufgaben: Task Analysis Techniques,
Computational Cognitive Architectures, und Conceptual Frameworks.
Der ursprüngliche Ansatz von Card, Moran und Newell wird vom Task Analysis
Sektor integriert. Die untere kognitive Schicht setzt auf empirische Erfassung
des Verständnisses und Interaktion, die das Programm bereitstellt. Die
unterste Schicht repräsentiert die Rahmenbedingungen des System- oder Interface-Gebrauchs
und versucht Umwelteinflüsse und kognitive Prozesse zu erfassen.
Eine der ersten Modelle von (Card, Moran und Newell) entstand Anfang der 80er
im Zuge des KLM (Keystroke-Level-Model). Dabei werden Vorraussagen über
die Art der Methoden und Dauer, wie lange der Task benötigt getroffen.
Hierbei gibt es 6 verschiedene Operationstypen. K wird für Key oder Button-pressed
benutzt, P ist die Bewegung mit der Maus auf eine Zielfläche, H ist die
mechanische Bewegung der Hände auf ein Device, wie das Keyboard oder Maus,
D ist das Zeichnen einer Linie, M ist die mentale Vorbereitung auf eine zukünftiges
Handlung und R ist die Reaktionszeit des Systems. Unterteilt man nun aller Schritte
in diese 6 Kategorien ein, summiert diese dann nach vorgegebenen Gesetzen und
Annahmen, wie z.B. Fitt’s Law, so kann man Best-Case Aussagen über
die Zeitspanne, die wahrscheinlich benötigt wird treffen. Der Vorteil dieser
Methode liegt in seiner Einfachheit und der schnell zu realisierenden Umsetzung.
Beispiel:
Moving text with the MENU-METHOD
Description            Operator            
    Duration (sec)
Mentally prepare by Heuristic Rule 0     M     1.35
Move cursor to beginning of phrase       P       1.10
(no M by Heuristic Rule 1)
Click mouse button       K       0.20
Daneben gibt es natürlich ausgeklügeltere, aber auch komplexere Techniken
wie das CMN-GOMS Modell. Die sehr spezifische Ausrichtung des Modells macht
es komplexer, aber auch variabler. Es existiert eine strikte Goal-Hierarchie
mit Pseudocode-Schreibweise erläuterten Methoden, entsprechenden Submethoden
und Bedingungen.
Beispiel:
GOAL: EDIT-MANUSCRIPT
. GOAL: EDIT-UNIT-TASK ...repeat until no more unit tasks
. . GOAL: ACQUIRE UNIT-TASK ...if task not remembered
Die von Kieras entwickelte Technik namens NGOMSL (Natural GOMS Language)
verfeinert diese strikt-logische Herangehensweise. Hierbei wurde eine eigene
Sprache entwickelt um das CMN-Modell mit einer simplen kognitiven Architektur
namens CTT zu verknüpfen. NGOMSL Modelle sind schon in Programmform vorhanden.
Beispiel:
NGOMSL Statements Executions External
Operator
Times
Method for goal: Move text 1
Step 1. Accomplish goal: Cut text. 1
Step 2. Accomplish goal: Paste text 1
Step 3. Return with goal accomplished. 1
Anwendung
Nachdem nun die Resultate, wie benötigte Zeit, Zielsetzungen des Users,
Konsistenz oder Methodenanwendung gesammelt und erstellt wurden, kann nun die
Auswertung stattfinden. Die Resultate lassen nun auf Problemzonen und Unsicherheiten
des Systems schließen, wie z.B. eine lange oder benutzerunfreundliche
Unklarheiten des Interfaces. Performance-Aspekte und Vereinfachung der Komponenten
können dadurch später eine enorme Verbesserung der intuitiven Benutzbarkeit
bewirken. Generell liegt diesem langen Prozess jedoch eine genaue Planung und
Abwägung zugrunde, denn die Erstellung eines NGOMSL-Konstrukts beispielsweise
benötigt großen Zeit- und
Arbeitsaufwand. Ein weiteres Problem liegt in der Festlegung und Erzeugung der
GOMS Komponenten. Können dadurch alle essentielle Felder der Nutzung abgedeckt
werden? Ist die entstehende Strukturierung noch verständlich und nah an
der tatsächlichen Nutzung des Systems? Ein Patentrezept gibt es daher nicht,
obwohl große Anstrengungen unternommen wurden ein weitereichendes Modell
der GOMS-Familie zu entwickeln. Viele Faktoren sind hinzugefügt worden
um die realitätsnahe Umsetzung in eine logische Benutzungsstruktur zu gewährleisten.
Referenz:
Paper: “A Guide to GOMS Model Usability Evaluation using NGOMSL”
By David Kieras
University of Michigan
Spring, 1996
Copyright © David Kieras, 1996. All rights reserved.
Paper: “The GOMS Family of Analysis Techniques: Tools for Design and
Evaluation”
By Bonnie E. John & David E. Kieras*
24 August 1994
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15213
*Department of Electrical Engineering and Computer Science
University of Michigan