Mousemaps ein Ansatz für eine Technik zur Visualisierung der Nutzung von Software und zur Automation der Entdeckung von Bedienungsfehlern

Transkript

1 Mousemaps ein Ansatz für eine Technik zur Visualisierung der Nutzung von Software und zur Automation der Entdeckung von Bedienungsfehlern Michael Gellner Universität Rostock, Institut für praktische Informatik, Lehrstuhl für Softwaretechnik Zusammenfassung Es wurde ein System ObSys entwickelt, welches eine multidimensionale Darstellung des zeitlichen Verlaufs der Aktionen von Usability Testern an Prototypen auf zweidimensionalen Flächen liefert. Die Kodierung erfolgt durch Linienfarbe, -verlauf und -breite sowie durch die Visualisierung von Mausklicks. Diese Abbildungen, Mousemaps genannt, geben einerseits ad hoc Überblick über den Verlauf einer Testsitzung ohne längere Zeit Videomaterial betrachten zu müssen, ermöglichen statistische Untersuchungen und liefern neue Sichten über den Gebrauch von GUIs durch Anwender. Mit der Mousmap-Visualisierung und der Unterstützung von bis zu vier verschiedenen Aufzeichnungstechniken geht ObSys über die Fähigkeiten ähnlicher Eventrecorder hinaus und eröffnet neue Möglichkeiten für Usability-Evaluationen sowie für grundlegende Methodenvergleiche. 1 Einleitung Ein zentrales Mittel bei Evaluationen zur Gebrauchstauglichkeit von Software sind Sitzungen mit Testpersonen. Ein Problem hierbei ist die Aufzeichnungsmethode: Es gibt verschiedene Methoden, alle haben Vor- und Nachteile. Mit der Entscheidung für eine bestimmte Aufzeichnungsmethode hat man gleichzeitig auch über die zeitlichen Aufwände zur Auswertung, über die Automatisierbarkeit, die notwendigen Speicherkapazitäten, die benötigte Hardware und zahlreiche weitere Aspekte entschieden. Eventrecording ermöglicht eine Visualiserung der Aufzeichnungen von Handlungen der Testpersonen. Dies erlaubt die Erzeugung überschaubarer zweidimensionaler Abbildungen der erfolgten Interaktionen. Gegenüber Videoaufzeichnungen, deren Aufbereitung häufig enorm zeitaufwendig ist (siehe z. B. (Preece 1994; Mayhew 1999)), stellt dies einen bedeutsamen Vorteil dar. Das hierzu entwickelte Tool ObSys ermöglicht durch den Einsatz von Farb- und Breitenattributen bei Linien die multidimensionale Darstellung von zeitlichen Verlaufsdaten auf zweidimensionalen Flächen und geht damit über die Fähigkeiten ähnlicher Eventrecorder wie GUITESTER (Okada und Asahi 1999), Kaldi (Al-Qaimari und McRosstie 1999) und verschiedenen anderen hinaus. Weitere bekannte Aufzeichnungstechniken wie Eventlogging, Videoaufzeichnung und Screencapturing werden ebenfalls von ObSys unterstützt. Im folgenden Kapitel wird erläutert, welche Technik hier unter dem jeweiligen Methodennamen verstanden wird.

2 ObSys ermöglicht neben der parallelen Nutzung der Aufzeichnungstechniken als solche auch die Nutzung zu Vergleichszwecken, d. h. Untersuchungsgegenstand ist die Leistungsfähigkeit der erwähnten Aufzeichnungsmethoden. Hierzu gibt es bislang nur wenige Veröffentlichungen, bei denen Daten anhand von indirekten Vergleichen der Angaben in den jeweiligen Veröffentlichungen abgeleitet werden, siehe etwa (Gray und Salzman 1998; Henderson 1995; Hilbert und Redmiles 1999; Ivory und Hearst 2001). Zudem unterstützen diese häufig nur Inhouse verfügbaren Systeme meist nur eine oder zwei Aufzeichnungstechniken. Perspektivisch ermöglicht eine Kombination mehrerer Techniken wie in ObSys eine Automation vieler zeitaufwändiger Arbeitsschritte bei Usability-Evaluationen. 2 Die Testmethoden und die unterstützenden Werkzeuge Für Usability-Evaluationen sind im Kern vier Aufzeichnungstechniken praktikabel. Da es vereinzelt voneinander abweichende Darstellungen gibt, wird im Folgenden ein Überblick darüber gegeben, wie die Techniken in diesem Zusammenhang angewandt werden. Videoaufzeichnungen In den meisten Usability-Laboratorien steht die Videoaufzeichnung im Mittelpunkt der Evaluation. Hierbei werden eine oder mehrere Kameras auf den Anwender gerichtet, um seine Handlungen, Mimiken und Gestiken aufzuzeichnen. Mehrere Kameras ermöglichen es beispielsweise, die Hände bei Eingaben separat zu erfassen. Videoaufzeichnungen gehen mit hohen zeitlichen Aufwänden für die Analyse einher. Es gibt zahlreiche Standardwerkzeuge zur Verarbeitung von Videodaten, ferner ermöglichen Tools wie der Observer von Noldus, Interact von Mangold oder das selbst entwickelte ObSys-System das Aufzeichnen von Videodaten nebst Kommentaren bzw. Log- Informationen. Aus der Sicht der Analyse handelt es sich um eine Sammlung von Bewegtbildern, deren Analyse in der Praxis bis heute dem Menschen vorbehalten ist. Eventlogging Unter Eventlogging wird das Notieren von Kommentaren zu Ereignissen verstanden. Die gängigen Tools ermöglichen es, im Vorhinein eine Liste zu erwartender Auffälligkeiten vorzubereiten und mit einer bestimmten Taste zu assoziieren. So ist es dann möglich, in Echtzeit anhand einzelner Tastendrücke umfangreiche und einfach lesbare Kommentarlisten zu erstellen ohne Stenographie oder ähnliches beherrschen zu müssen. Die oben bereits genannten Tools eigenen sich auch zum Eventlogging mit Videodaten. So können die Kommentarlisten auch mit den Videodaten in Verbindung gesetzt werden, so dass beim Anwählen eines Kommentars zu einem Zeitpunkt hh.mm.ss auch die zugehörige Stelle in der Videodatei angesprungen wird. Auf Basis der Tastatureingaben sind einfache Analysen möglich. Eventlogging kann viel Zeit bei der Aufbereitung von Videoaufzeichnungen sparen, wenn parallel zur Aufzeichnung mitgelogt wird. Dies erfordert jedoch mindestens eine weitere Person, die das manuelle Logging übernimmt. Da das das Gefühl, beobachtet zu werden, weiter zuspitzt und somit die Testverzerrung signifikanter wird, gibt es in vielen Usability-Laboratorien mit halbdurchsichtigem Glas verdeckte Regieräume für die Protokollführer. Eventrecording Im Gegensatz zum Eventlogging erfolgt Eventrecording automatisch. Alle gängigen Betriebssysteme verfügen über Nachrichtenschleifen, in denen unter anderem die Eingaben von Anwendern per Maus und Tastatur sowie ferner durch Joysticks, Tableaus etc. zur Abarbeitung zwischenge-

3 speichert werden. Über sogenannte Journaling-Mechanismen können diese Input-Informationen ausgelesen und gespeichert sowie auch wieder in die Warteschlange eines Betriebssystems eingespeist werden (zur Realisierung von Abspielfunktionen). Eventrecording kann mit dem System ObSys durchgeführt werden. Im Gegensatz zur Videoaufzeichnung stellt Eventrecording eine direkte Aufzeichnung des Eingabeverhalten des Anwenders dar. Während Eventrecording früher das Manipulieren des Quellcodes erforderte (über den man verfügen musste) kann über das Journaling die Aktivität jedes Programms, das Eingaben erhält, verfolgt werden. Dies ermöglicht es ohne die Interpretation von Bildern per Software beherrschen zu müssen zu untersuchen, welche Verhaltensweise Bedienungsfehler und probleme indizieren. Problematisch beim Eventrecording ist die Positionierung von Fenstern. Erfolgt diese zufällig, immer an anderen Stellen und in anderen Größen, verfehlt das Abspielen seine ursprüngliche Wirkung. Screencapturing Auch Screencapturing führt auf Videosequenzen, allerdings wird ein andere Aufzeichnungskanal genutzt. Basis für Screencapturing sind die Daten, die Grafikkarten an Bildschirme senden. Dieser Bilddatenstrom kann kopiert und auf Speichermedien geleitet werden. Der Vorteil bei dieser Methode ist, dass zur Aufzeichnung keine Extrageräte benötigt werden. Dem steht jedoch der Nachteil gegenüber, dass weder Mimik noch Gestik von Testpersonen zur Verfügung stehen. Ebenso können die Events nicht per Software sondern vorwiegend von einem menschlichen Evaluator ausgewertet werden. Screencapturing kann in Verbindung mit Videokameras zu effektiveren Aufzeichnungen führen, da sich die Videoströme in die Capturingströme einblenden lassen (siehe Abbildung 1). Tools wie HyperCam oder ScreenCam von Lotus ermöglichen Screencapturing. Abbildung 1: Kombination von Screencapturing- und Videostream 3 Zeitverteilung der Tätigkeiten bei Usability-Evaluationen Nicht viel anders als bei der Softwareentwicklung durchlaufen auch Usability-Evaluationen diverse Phasen. Um unterstützende Tools entwickeln zu können, wurde anfänglich ein Phasenmodell

4 erstellt, aus dem hervorgeht, welche Abschnitte sich zunächst anbieten, siehe Abbildung 2, links nach (Gellner 2000). Dieses Phasenmodell wird auch hier genutzt, um die Einordnung von ObSys einerseits und unsere Erfahrungen mit Usability-Evaluationen anderseits zu beschreiben. 1. Festlegung der Testziele 2. Wahl der Testmethoden 3. Entwurf des Testmaterials 4. Planung und Organisation 5. Durchführung des Tests 6. Aufbereitung der Daten 7. Auswertung der Daten 8. Verfassen der Studie Phase Zeit [h] Abbildung 2: Acht-Phasen-Pattern der Usability-Evaluation (links) und Verteilung des zeitlichen Aufwands bei Usability-Evaluationen auf die einzelnen Phasen (rechts). Im Sinne der Pattern-Terminologie handelt es sich bei diesem Modell um ein Process Pattern (Ambler 1998), daher wird das Modell auch unter dem Begriff Acht-Phasen-Pattern geführt (Gellner 2002). Während das Acht-Phasen-Pattern lediglich die Abfolge der Schritte beschreibt, zeigt Abbildung 2, rechts, die Verteilung der zeitlichen Aufwände von Usability-Evaluationen auf die einzelnen Phasen. Die Darstellung basiert auf den Aufwänden, die bei den in unserer Abteilung durchgeführten Untersuchungen angefallen sind; stattgefunden haben 5 Evaluationen mit 15, 10, 5, 5 und 4 Testpersonen. Die Sitzungen haben je Testperson zwischen ca. 30 Minuten und 1,5 Stunden Zeit beansprucht und fanden in den letzten 2 Jahren statt. Hierbei wurden den Testpersonen Aufgaben gestellt, die mit den jeweiligen Softwaresystemen zu lösen sind und deren Aktionen mit Videokameras aufgezeichnet. Die ersten zwei der fünf Testreihen wurden zusätzlich mit Fragebögen unterstützt. Die mit Abstand meiste Zeit hat die Nachbearbeitung bzw. Aufbereitung der Ergebnisse benötigt. Die bei den Testsitzungen direkt anfallenden Resultate sind für eine Auswertung meist noch ungeeignet; entweder verstellt Rauschen zunächst die eigentlichen Daten oder die Daten müssen noch in ein auswertbares Format gebracht werden. Rauschen in diesem Sinne stellen hierbei etwa 58 Minuten je Stunde Videoaufzeichnung dar, in denen es keinerlei Probleme gibt und die daher nicht oder nur unwesentlich zur Verbesserung eines Systems beitragen. Eine Usability-Evaluation beabsichtigt Fehler zu finden, daher sind lediglich die Punkte von Bedeutung bei denen Probleme auftraten. Nach unseren Erfahrungen (die sich mit Angaben der Literatur decken, siehe z. B. (Preece 1994)) benötigt man je Stunde Video etwa 5 bis 8 Stunden, um zunächst alle kritischen Stellen zu finden und für die sich anschließende Analyse zusammenzuschneiden. Diese meist nur wenigen Sekunden (Mimik, Gestik oder auch Nachfragen sind meist kurzweilige Ereignisse) aus einer Testsitzung bilden dann die Basis für die Testauswertung.

5 Ein Stapel Fragebogen, der ausgefüllt wurde, stellt hingegen Daten in einem nicht direkt auswertbaren Format dar. Hier müssen im Rahmen der Aufbereitungsphase zunächst die Scores in eine Tabellenkalkulation oder eine Statistiksoftware übertragen werden, um dann eine Auswertung durchführen zu können. Diese immensen zeitlichen Aufwände sind die Motivation dafür, Usability-Evaluationen zumindest in Teilen automatisieren zu wollen. Die Literatur nennt hierzu verschiedene Ansätze, die bislang jedoch entweder ohne Toolunterstützung sind oder sich vielfach nicht anwenden lassen, z. B. weil keine detaillierten Aufgabenmodelle vorliegen (siehe beispielweise die Arbeiten von (Balbo 1995; Lecerof und Paternò 1998; Helfrich und Landay 1999)). zu formatierender Absatz Abbildung 3: Testaufbau zum Minimalszenario 4 Mousemaps Mousemaps bilden den zeitlichen Verlauf der Aktionen mit der Maus auf eine zweidimensionale Fläche ab. Relevante Informationen können hierbei die Geschwindigkeit der Mausbewegung sein, die Richtung, in die die Maus bewegt wurde und die Positionen, an denen Mausklicks getätigt wurden. Um die Visualisierung zu diesen Punkten zu veranschaulichen, wird folgendes Minimal- Szenario genutzt: Die Textverarbeitung Word ist geöffnet und ein Anwender soll den obersten Absatz der gezeigten Seite markieren und die Schriftfarbe auf rot setzen (siehe Abbildung 3). Zur Darstellung dieser Komponenten von Mausaktionen bieten die Mausmaps folgende grafische Kodierung an: Die Geschwindigkeit wird mit der Dicke der Mausspur ausgedrückt. Je mehr Zeit zwischen zwei Punkten liegt, umso dicker wird eine Mausspur gezeichnet. Abbildung 4 zeigt das Minimal-Szenario links einmal mit überbetont langsamen Bewegungen ausgeführt und rechts mit überbetont schnellen Bewegungen.

6 Abbildung 4: Darstellung der Maus-Geschwindigkeit durch die Dicke der Linien Zur Darstellung der Bewegungsrichtung werden Farbverläufe genutzt. In Abbildung 5 ist das Markieren des zu formatierenden Textes dargestellt, das linke Bild zeigt, wie das Markieren des Textes von links oben nach rechts unten aussieht. Das rechte Bild stellt den Vorgang des Markierens von rechts oben nach links unten dar. Abbildung 5: Darstellung der Richtung von Mausbewegungen durch Farbverläufe Mausklicks werden durch Kreise visualisiert. Technisch unterteilen sich Mausklicks in das Ereignis des Herunterdrückens einer Taste (unter Windows WM_xBUTTONDOWN mit x {L, M, R}; dies steht für die Maustasten links, in der Mitte befindlich und rechts) und des Loslassens (unter Windows WM_xBUTTONUP mit x {L, M, R}). Optional kann auf das Herunterdrücken einer Taste auch das Bewegen in diesem Zustand folgen, etwa wenn das sogenannte Draging genutzt werden kann. Abbildung 5 zeigt in beiden Bildern dreiphasige Mausereignisse: Das Markieren beginnt mit einem Klick auf den Anfang des Bereiches, der markiert werden soll. Danach wird der Mauszeiger an einen Endpunkt geführt und zuletzt wird der Mauszeiger losgelassen. Rechts wird der Mauszeiger zunächst an das Ende des Absatzes geführt, um mit dem Markieren beginnen zu können. Um die Visualisierung zu effektivieren bietet ObSys die Möglichkeit, den Hintergrund in Form von Screenshots einzubinden. Es ist somit nicht erforderlich, die Mausmaps und die Bildschirmmasken in separaten Phototools manuell über Ebenen oder ähnliche Techniken zusammenzubringen. Abbildung 6 (oben links und oben rechts) zeigt die Mousmaps aus Abbildung 5 mit einem Abbild dessen, was der Anwender zur Ausführung gesehen hat. Hier sind deutlich die Textpassagen zu erkennen, die markiert wurden. Die unteren beiden Darstellungen aus Abbildung 6 enthalten Mousemaps des gesamten Mini-Szenarios. Links unten ist zu sehen, wie der Text markiert

7 wird und das Menü angewählt wird, während rechts unten auch die Aktionen auf dem Dialog zu den Zeichenattributen zu erkennen sind. Abbildung 6: Hinterlegung der Abläufe mit Screenshots Ein Problem bei der bisher gezeigten Standard-Darstellung der Mousemaps ist das Übermalen von Ereignissen durch später an ähnlichen Positionen aufgetretenen Ereignisse. Abbildung 7 zeigt in beiden Darstellungen die Aufzeichnung des vorne geschilderten Mini-Szenarios. Auf der linken Seite sind einige Mausklicks jedoch von Linien verdeckt, während rechts die einzelnen Kreise und Linien eindeutig voneinander unterschieden werden können. Abbildung 7: Verbesserung der Übersichtlichkeit durch Variation der Linienbreite

8 Für die in Usability Evaluationen üblichen Szenarios von einigen Minuten Dauer kann hier über das in ObSys mögliche Manipulieren der Strichdicke Abhilfe geschaffen werden. Bei Beobachtungen über längere Zeiträume, etwa im Rahmen von Feldversuchen, kann mit schwarzen Hintergründen und dünnen weißen Linien gearbeitet werden. Hierbei entsteht dann bei häufig genutzten Mauswegen der Seheindruck, die Linien werden umso heller, je öfter die Maus bestimmte Pfade verfolgt hat (siehe Abbildung 8). Abbildung 8: Visualisierung von Daten zur quantitativen Analyse Aus unseren frühen Testreihen lässt sich bislang die These ableiten, dass das Bewegen der Maus in Richtung einer zu benutzenden Schaltfläche meist in Form von Ellipsenabschnitten und nur wenig linear erfolgt (siehe die vorherstehenden Abbildungen). (2) zum Format-Menü (3) zur Farbwahl (1) Markieren des Absatzes (4) Beendigung der Dialogbox Abbildung 9: Mausbewegungen wie aufgezeichnet (links) und linearisiert (rechts). ObSys erlaubt es, die Darstellungen in Mousemaps von Klick zu Klick zu linearisieren, d.h. alle abweichenden Kurven und Haken zu ignorieren. Dies ist ohne weiteres möglich, da es sich bei den Mousemaps lediglich um die Visualisierung protokollierter Daten und nicht um aufgezeichnete Bilder handelt. Die linearisierte Klick-zu-Klick-Folge zu Abbildung 9 links ist in Abbildung 9 rechts wiedergegeben. Zu unterscheiden ist hier zwischen dem Anwählen von Bedienelementen (siehe die Punkte 2, 3, 4 aus Abbildung 9, links) und»erzwungenen«bewegungen wie etwa dem Markieren von Text (siehe Punkt 1, Abbildung 9, links). Während es bei ersteren Operationen möglich und scheinbar üblich ist, sich mit einer schwingenden Bewegung anzunähern, erfordern letztere das saubere Verfolgen imaginärer Pfade (wie etwa der Unterkante eines Absatzes), da sonst eine falsche Markierung entsteht oder geometrische Figuren falsche Maße haben bzw. falsch positioniert sind.

9 5 Ausblick Mousemaps ermöglichen neue Einblicke in das Verhalten von Anwendern. Nach unseren ersten Untersuchungen können auch unbewusste Aspekte indiziert werden, die sonst nur mit Hardwareintensiven Techniken wie dem Eye-Tracking erkennbar sind. Ein Beispiel sind etwa die viertelellipsenartige Schwingungen, die Anwender um die Zielschaltflächen herum machen, ehe der beabsichtigte Mausklick ausgelöst wird. Diese Verhaltensweise indiziert unseren ersten Beobachtungen nach normale Arbeitsflüsse bzw. entspannte Normalzustände und verändert sich bei mentalen Belastungen, wie sie z.b. Zeitdruck oder Unübersichtlichkeit auslösen, in Richtung linearer Bewegungen ohne Verschnitt. Unsere ersten Versuche mit ObSys und den MouseMaps münden in folgender These: Es scheint eine mausbasierte Gestensprache vergleichbar der ebenfalls meist unbewussten»gesprochenen«körpersprache zu geben. Die erwähnten von Anwendern gezeigten Ellipsenabschnitte, die mutmaßlich mit einem entspannten Schwingen beim Gehen vergleichbar sind, bilden einen ersten Baustein. Es ergeben sich zahlreiche weitere bislang jedoch nicht untersuchte Ansatzpunkte: Die durchschnittliche Geschwindigkeit von Operationen in Verbindung mit zeitweiligen Abweichungen, das Verhältnis von Mausoperationen zu Tastenkürzeln und eine Veränderung dieser Quote, Abweichungen von den üblichen Radien, Annäherungen an Elemente von der»falschen«d.h. unüblichen Seite und mögliche individuelle Verhaltenskomponenten. Einfache Kausalitäten wie etwa Fitt s Law, die Steering Regel oder auch die Abschätzungen im Rahmen von GOMS-Modellen können ohne große Aufwände evaluiert und verfeinert werden. Bislang liefern diese Modelle lediglich Abschätzungen über die Zeit, die ein Anwender für eine Aktion benötigt dies ist gemessen an den aktuellen Ansprüchen an Software insbesondere bei Internetanwendungen trivial. Ein großer Bedarf besteht daran, Aussagen über den Fun of Use oder über die Selbstzufriedenheit eines Anwenders aus Messergebnissen ableiten zu können. Hierfür wären aus Gesten ableitbare Aussagen, die die inneren Zustände von Anwendern beschreiben, deutlich hilfreicher als aufwändige Analysen, an deren Ende lediglich steht, dass ein Anwender n Sekunden für eine Aktion benötigen könnte. Ein sich anschließender Schritt liegt in der Entwicklung von Erkennungsalgorithmen für Charakteristika auf Basis von Mousemaps oder Eventlisten, aus denen die Mousemaps erstellt werden. Hiermit kann dann eine Automation von Usability Evaluationen erreicht werden. Kontaktinformationen Michael Gellner Universität Rostock Institut für praktische Informatik Lehrstuhl für Softwaretechnik Albert-Einstein-Str Rostock mgellner@informatik.uni-rostock.de Tel.: ++49 (381)

10 6 Literatur Al-Qaimari, G.; McRosstie (1999): KALDI: A Computer-Aided Usability Engineering Tool for Supporting Testing and Analysis of Human-Computer Interaction. In: Vanderdonckt, J.; Puerta A. (Hrsg.), Computer Aided Desgin of User Interfaces II (Proceedings of the Third International Conference on Computer-Aided Design of User Interfaces), Kluwer Academic Publishers, Lovain-la-Neuve, S Ambler, S. W. (1998): Process Patterns: Building Large-Scale Systems Using Object Technology. New York: SIGS Books/Cambridge University Press. Balbo, S. (1995): ÉMA: Automatic Analysis Mechanism for the Ergonomic Evaluation of user interfaces. Technical report no 96/44, CSIRO Division of Information Technology. In: Anzai, Y.; Ogawa, K.; (Hrsg.) Proceedings of the 6 th International Conference on HCI, Pacifico Yokohama (Japan). Gellner, M. (2002): Automated Determination of Patterns for Usability Evaluations. Accepted paper at VikingPLoP 2002, , Helsingør, Dänemark. Gellner, M. (2000): Modellierung des Usability Testing Prozesses im Hinblick auf den Entwurf eines Computer Aided Usability Engineering (CAUE) Systems. In: Rostocker Informatik- Berichte, Nr. 24, S Rostock. Gray, W. D. und Salzman, M. C. (1998): Damaged Merchandise? A Review of Experiments That Compare Usability Evaluation Methods. In: Moran, T.D. (Hrsg.): Human-Computer Interaction, A Journal of Theoretical, Empirical and Methodological Issues of User Science and of System Design, Vol. 13, (3), S Henderson, S. (1995): A comparison of four prominent user-based methods for evaluating the usability of computer software. In: Ergonomics, Vol. 38 (10), S Hilbert, D.M. und Redmiles D.F. (1999): Extracting Usability information from user interface events. Technical Report UCI-ICS-99-40, Irvine: Department of Information and Computer Science, University of California. Ivory, M. Y.; Hearst, M. A. (2001): The State of the Art in Automating Usability Evaluation of User Interfaces. In: ACM Computer Surveys, Vol. 33, No. 4, S Lecerof, A.; Paternò, F. (1998): Automatic Support for Usability Evaluation. IEEE Transactions on Software Engineering, Vol. 24, Nr. 10, S Mayhew, D. J. (1999): The Usability Engineering Lifecycle. San Francisco: Morgan Kaufmann Publishers, Inc. Preece, J. (1994): Human-Computer-Interaction. Harlow: Addison-Wesley. Okada, H., Asahi, T. (1999): GUITESTER: A log-based usability testing tool for Graphical User Interfaces. In: IEICE Transactions on information and systems. Volume E82, S