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