Eine Einschätzung des Wertes einer Usability Studie am Beispiel der Evaluation von "neonion"

Inhaltsverzeichnis

1 Einleitung
1.1 Thema und Kontext
1.2 Zielsetzung und Vorgehen
1.3 Aufbau der Arbeit

2 Hintergrund
2.1 Existierende Evaluationsmethoden
2.1.1 User Testing
2.1.2 Inspektionsmethoden
2.1.3 Inquiry Methods
2.1.4 Analytical Modeling und Simulation Methods
2.1.5 Weitere Klassifizierungen
2.2 Defizite bei existierenden Evaluationsmethoden
2.2 ” U sabilityEvaluationMethodsfortheWeb:ASystema- tic Mapping Study “[FIA11]
2.3 Ziele

3 Umsetzung
3.1 Anwendungen
3.1.1 neonion
3.1.2 Morae
3.2 Methodologie der Studie
3.2.1 Testbedingungen
3.2.2 Testteilnehmer
3.3 Testdesign
3.3.1 Testziele und Variablen
3.3.2 Testaufgaben und -szenarien
3.3.3 Testablauf
3.4 Auswertung und Ergebnisse
3.4.1 Kategorisierung und Zusammenfassung der Beobachtungen
3.4.2 Ergebnisse der Usability Studie

4 Zusammenfassung und Ausblick

Literatur

Anhang

4.1 Tabellen
4.2 Screenshots
4.3 Flussdiagramme
4.4 Dokumente
4.5 Auswertung
4.5.1 Qualitative Beobachtungen
4.5.2 Zusammengefasste Beobachtungen
4.5.3 Grafiken

Abbildungsverzeichnis

4.1 Übersicht der Gruppendokumente von neonion

4.2 Annotationsmodus von neonion

4.3 Übersicht der Concept Tags von neonion

4.4 Übersicht der Concept Sets von neonion

4.5 Geöffnetes Aufgabenfenster (Morae)

4.6 Geschlossenes Aufgabenfenster (Morae)

4.7 Geöffneter Fragebogen (Morae)

4.8 Testablaufplan Deutsch (1)

4.9 Testablaufplan Deutsch (2)

4.10 Testablaufplan Deutsch (3)

4.11 Testablaufplan Englisch (1)

4.12 Testablaufplan Englisch (2)

4.13 Testablaufplan Englisch (3)

4.14 Checkliste Testablauf

4.15 Observer Form

4.16 Markierte Beobachtungen 1-24

4.17 Markierte Beobachtungen 25-52

4.18 Markierte Beobachtungen 53-82

4.19 Markierte Beobachtungen 83-113

4.20 Markierte Beobachtungen 114-142

4.21 Markierte Beobachtungen 143-168

4.22 Markierte Beobachtungen 169-198

4.23 Markierte Beobachtungen 199-230

4.24 Markierte Beobachtungen 231-253

4.25 Durch Affinity Matching zusammengefasste Beobachtungen (1)

4.26 Durch Affinity Matching zusammengefasste Beobachtungen (2)

4.27 Durch Affinity Matching zusammengefasste Beobachtungen (3)

4.28 Durch Affinity Matching zusammengefasste Beobachtungen (4)

4.29 ÜbersichtAufgabenerfolg

4.30 Übersicht zu Einzelantworten der SUS

4.31 Verbesserungsvorschläge

4.32 Allgemeiner Fragebogen - Auswertung Frage 2

4.33 Spezifischer Fragebogen - Auswertung Frage 2

4.34 Spezifischer Fragebogen - Auswertung Frage 3

4.35 Spezifischer Fragebogen - Auswertung Frage 4

4.36 Demografischer Fragebogen - Auswertung Frage 2

4.37 Aufgabenerfolg pro Aufgabe

Tabellenverzeichnis

4.1 Testziele

4.2 Bezeichnungen

4.3 Kriterien zur Kategorisierung der Beobachtungen

4.4 Zeitplan der Testsitzungen

4.5 Auswertung von vier Testzielen

Zusammenfassung

Diese Abschlussarbeit befasst sich mit der Evaluation von Usability im Bereich Human Computer Interaction. Am Beispiel der Webanwendung neonion wurde eine Usability Studie entwickelt, die das Tool Morae in den Gesamtablauf von der Vorbereitung bis hin zur Auswertung der Testsitzungen einbezieht. Mit dieser Arbeit soll anhand der Defizite existierender Methoden herausgefunden werden, ob eine solche Studie zur umfassenden Usability Evaluation zweckmä-ßig ist. Diesbezüglich wurden zunächst Hintergrundinformationen zu bereits existierenden Methoden und deren Defizite erläutert. Infolgedessen wurde die Usability Studie vorbereitet, durchgeführt und ausgewertet. Zur Vorbereitung gehörten u.a. die Inspektion der Anwendungen neonion und Morae, die Aus- arbeitung der Testziele sowie die Entwicklung eines ausführlichen Testplans. Nachdem die Testsitzungen vollständig vorbereitet waren, wurden Teilnehmer rekrutiert sowie Zeiten und Orte der Sitzungen geplant. Die während und nach der Durchführung ermittelten Beobachtungen, wurden zusammengefasst und hinsichtlich der Testziele ausgewertet. Diese Ergebnisse wurden anschließend evaluiert, um die Zweckmäßigkeit für Usability Studien zu bewerten.

Mittels Morae konnten mehrere Evaluationsmethoden miteinander kombiniert und so Usability-Probleme hinsichtlich aller Testziele identifiziert werden. Au-ßerdem war es möglich, Morae in alle Teilbereiche der Entwicklung einzube- ziehen. Mit der entwickelten Studie konnten allerdings nicht alle Defizite exis- tierender Methoden vermieden werden. Daraus folgt, dass auch diese Methode der Usability Evaluation weder für alle Arten von Anwendungen eingesetzt werden kann, noch eine ausreichende empirische Validierung der Ergebnisse bietet. Allerdings könnte der Aufbau der Studie mittels bisher unausgeschöpf- ter Funktionen von Morae und den in dieser Arbeit gesammelten Erkenntnissen erweitert werden.

1 Einleitung

1.1 Thema und Kontext

Im Bereich Human Computer Interaction (HCI) existieren eine Vielzahl un- terschiedlicher Evaluationsmöglichkeiten der Usability von Software. Die Wahl einer geeigneten Methode ist zumeist nicht einfach und hängt vom Testgegen- stand oder der Zielstellung der Evaluation ab. Es existiert kein universelles Vorgehen, das für jede Art der Usability Evaluation eingesetzt werden kann. Zudem greifen Forscher oftmals auf unterschiedliche Definitionen von Usability zurück. Die Mehrzahl der vorhandenen Evaluationsmethoden ist nicht für Test- produkte im frühen Stadium der Entwicklung geeignet und bieten außerdem weder eine empirische Validierung der Ergebnisse, noch Verbesserungsvorschlä- ge zu den identifizierten Problemen (siehe Abschnitt 2.2).

1.2 Zielsetzung und Vorgehen

In dieser Arbeit soll herausgefunden werden, ob mit Hilfe des Tools Morae eine Usability Studie entwickelt werden kann, die eine zweckmäßige Methode zur Evaluation der Usability einer Anwendung bietet. Mit Zweckmäßigkeit ist hier u.a. gemeint, dass die Methode keines der zuvor benannten Probleme aufweist. Es soll also der Wert einer, mit der Software Morae durchgeführten, Usability Studie eingeschätzt werden können.

Diesbezüglich wird eine beispielhafte Evaluation der Webanwendung neonion durchgeführt. Diese Usability Studie soll mit Hilfe von Morae geplant, durchgeführt und ausgewertet werden sowie mehrere Evaluationsmethoden vereinen. Außerdem sollte sie bestmöglich an neonion angepasst werden, um einen ausreichenden Praxisbezug zu gewährleisten. Nach Planung, Durchführung und Auswertung der Studie werden dessen Vor- und Nachteile hinsichtlich der zuvor definierten bestehenden Probleme eingeschätzt.

1.3 Aufbau der Arbeit

Zuerst wurden existierende Usability Evaluationsmethoden und deren Defizite, sowie grundlegende Definitionen (z.B. von Usability) recherchiert und zusam- mengefasst. Danach begann die Vorbereitung der Usability Studie am Beispiel von neonion. Diese beinhaltete u.a. die Inspizierung der Anwendungen Morae und neonion, die Festlegung der Testziele und die Auswahl der Evaluations- methoden basierend auf den Hintergrundinformationen. Außerdem wurden der Testplan konzipiert, Teilnehmer rekrutiert und die Testsitzungen geplant und

1.3. Aufbau der Arbeit

vorbereitet. Darauf folgten Durchführung und Auswertung der Testsitzungen, anhand der zuvor definierten Testziele. Mit Hilfe dieser Erkenntnisse konnten die zentralen Fragen beantwortet und hinsichtlich der Gesamtzielstellung der Arbeit ausgewertet werden.

Hinweise zur Gestaltung

Zu Gunsten besserer Lesbarkeit wurde für personenbezogene Ausdrücke die männliche Schreibweise verwendet, gemeint sind aber stets männliche und weibliche Form. Zudem werden mehrfach englische Bezeichnungen verwendet, da die Begrifflichkeiten der englischen Originalliteratur sowie der englischen Anwendungen nicht durch eine Übersetzung verfälscht werden sollen. Diese Begriffe sind vom herkömmlichen Text in kursiver Schrift unterschieden.

2 Hintergrund

Software kann auf unterschiedliche Arten und Weisen evaluiert werden. Im Bereich Human Computer Interaction (HCI) ist die Bewertung von Software durch Usability Tests verbreitet.

Usability Testing umfasst das Beobachten von Anwendern, während sie ein Produkt zur Erreichung eines realistischen Ziels verwenden, um unmittelbar Informationen über die Nutzer und deren Nutzung des Produkts zu erhalten (vgl. [Bar10, 6]). Mit Anwender oder Nutzer ist die Person gemeint, die das Produkt verwendet oder zukünftig verwenden wird und deren Erfahrungen mit dem Produkt wichtig für die Weiterentwicklung dessen sind (vgl. [Bar10, 6]). Das Produkt ist das Objekt, welches getestet wird, im Fall dieser Arbeit die Webanwendung neonion.

Jeder Usability Studie, welche die Gesamtheit der Testsitzungen umschreibt (vgl. [Bar10, 6]), liegt eine Definition von Usability zu Grunde. Im Bereich

HCI wird Usability oft als

”[...] theextenttowhichaproductcanbeusedby

specified users to achieve specified goals with effectiveness, efficiency and satis- faction in a specified context of use “[ISO98] beschrieben. Hier werden Effekti- vität, Effizienz und Zufriedenheit als die wesentlichen Merkmale der Usability (vgl. [Bar10, 11]) benannt. Durch die Spezifizierung von Nutzern, Zielen und des Nutzungskontextes wird betont, dass es sich um genau die Nutzer handelt, für die das Produkt entworfen wurde und die damit im vorgesehenen Kontext Ziele erreichen wollen (vgl. [Bar10, 11]). Diese Definition wird die Grundlage dieser Arbeit bilden.

Nielsen[usa16] hingegen definiert Usability als

”[...] qualityattributethatas-

sesses how easy user interfaces are to use “ und legt die fünf Qualitätskomponenten Learnability, Efficiency, Memorability, Errors and Satisfaction fest. Zu den sich überschneidenden Merkmalen Effizienz und Zufriedenheit werden Erlernbarkeit und Fehler in diese Arbeit einbezogen, ebenso wie Nielsen’s 10 Usability Heuristics for User Interface Design [heu16].

2.1 Existierende Evaluationsmethoden

Die Evaluation von Usability kann verschiedenartig erfolgen. In einer Mapping Studie von Fernandez et al. [FIA11] (siehe Abschnitt 2.2) wurden die unter- schiedlichen Evaluationsarten kategorisiert und zusammengefasst. Die Katego- rien User Testing, Inspection Methods, Inquiry Methods, Analytical Modeling und Simulation Methods werden in den folgenden Absätzen beschrieben.

2.1. Existierende Evaluationsmethoden

2.1.1 User Testing

Mit Hilfe von User Testing können laut Fernandez et al. [FIA11, 10] Usability- Probleme bestimmt werden, indem Teilnehmer mit einem User Interface in- teragieren und dabei von einem Evaluator beobachtet werden. In diese Kate- gorie werden die Arten Think-Aloud Protocol, Question-Asking Protocol, Per- formance Measurement, Log Analysis und Remote Testing von den Autoren eingeordnet.

Think-Aloud Protocol

Dieses Protokoll umfasst nach Fernandez et al. [FIA11, 14] das ”lauteDen- ken“ des Teilnehmers, während der Bearbeitung spezieller Aufgaben. Barnum [Bar[10],¹⁹ ] ergänzt dies durch den Fakt, dass der Teilnehmer ermutigt wird, seine Gedanken mitzuteilen, während er mit dem Produkt arbeitet. Sie betont außerdem, dass so nicht erraten werden muss, was Teilnehmer denken und somit deren Erfahrungen besser verstanden werden können. Dieses Prinzip wird in den Usability Test dieser Arbeit einbezogen.

Question-Asking Protocol

Bei diesem Protokoll werden die Teilnehmer während des Tests ausdrücklich vom Moderator befragt, z.B. nach der Interpretation eines Bildschirms oder dem Design eines spezifischen Bestandteils des Produktes (vgl. [glo16]).

Performance Measurement

Das Performance Measurement ist laut Barnum [Bar10, 137] ein quantitatives Verfahren, bei dem Nutzeraktionen (z.B. Zeit, Fehleranzahl, Hilfe) gemessen und aufgezeichnet werden. Diese Methode ist während des Usability Tests dieser Arbeit vertreten, denn die Zeit, die der Teilnehmer pro Aufgabe benötigt, wird mit Hilfe von Morae gemessen und aufgezeichnet.

Log Analysis

Die Log-Analyse ist laut Fernandez et al. [FIA11, 14] die Analyse von Nutzungsdaten durch den Tester oder einer Software. Barnum [Bar10, 226] spezifiziert die Nutzungsdaten u.a. als Zitate von Teilnehmern, Beschreibungen von Verhalten und Handlungen der Teilnehmer, sowie die Kommentare der Beobachter. Auch die Log-Analyse, der mit Hilfe von Morae aufgezeichneten Nutzungsdaten, wird in dieser Usability Studie eingesetzt.

Remote Testing

Hierbei existieren laut Barnum [Bar10, 41 ff.] zwei Grundkonzepte: moderier- tes (synchrones) und unmoderiertes (asynchrones) Remote Testing. Für die Autorin zeichnet das moderierte Testen aus, dass sich Moderator, Teilnehmer und Beobachter nicht am gleichen Ort befinden. Beim unmoderierten Remote Testing hingegen erfasst eine Anwendung Bildschirm, Tasteneingaben, Klicks usw. und sammelt diese Daten in einem Report.

2.1.2 Inspektionsmethoden

Die Evaluationsarten in dieser Kategorie haben laut Fernandez et al. [FIA11, 10] die Gemeinsamkeit, dass ein Experte das Produkt mit Hilfe verschiedener Kriterien bewertet und so potenzielle Usability-Probleme identifiziert. Sie ord- nen dieser Kategorie die Methoden Heuristische Evaluation, Cognitive Walkthrough, Perspective-based inspection und Guideline review zu. Keine der im Folgenden aufgeführten Inspektionsmethoden wird innerhalb dieser Arbeit eingesetzt. Da deren Einsatz zur Bestimmung von Usability jedoch sehr verbreitet ist, werden diese trotzdem in wenigen Worten beschrieben.

Heuristische Evaluation

Die Heuristische Evaluation ist wohl eine der bekanntesten Inspektionsmetho- den. Dabei evaluiert ein Experte das Produkt mit Hilfe bestimmter Heuristi- ken, z.B. 10 Usability Heuristics for User Interface Design von Jakob Nielsen. Normalerweise führt ein Usability-Experte die Inspektion durch, welcher mit- unter die zusätzliche Expertise im Bereich der Produkt-Domäne besitzt (vgl. [Bar10, 61 f.]).

Cognitive Walkthrough

Dabei repräsentiert ein Experte den Nutzer beim Erkunden des Produktes und geht ”denWegdesgeringstenkognititvenAufwands“[Heg[03],²⁴ ].

Perspective-based inspection

Bei dieser Inspektionsmethode führt der Experte laut Fernandez et al. [FIA11, 14] eine begrenzte Evaluation durch, die z.B. auf das Design oder Aufgaben zur Inspektion des Produktes ausgerichtet ist.

Guideline review

Der Guideline review wird laut Fernandez et al. [FIA11, 15] mit Hilfe verschiedener Usability Richtlinien durch einen Experten durchgeführt, um die Konsistenz des Produktes zu ermitteln.

2.1.3 Inquiry Methods

In der Studie von Fernandez et al. [FIA11, 10] werden den Inquiry Methods die Evaluationsarten zugeordnet, die subjektive Eindrücke (z.B. Gefühle) der

2.1. Existierende Evaluationsmethoden

Teilnehmer sammeln. Dieser Kategorie gehören Umfragen, Interviews und Fokusgruppen an.

Umfragen

Umfragen bestehen aus spezifischen Fragen, die die Teilnehmer beantworten (vgl. [FIA11, 15]). Barnum [Bar10, 173] erwähnt drei wichtige Typen: pre-test, post-task und post-test Umfragen, die angesichts des Einsatzzeitpunktes unterschiedliche Informationen zur Verfügung stellen. Die angeführten Umfragen werden ein Bestandteil der Usability Studie dieser Arbeit sein.

Interviews

Währenddessen diskutieren nach Fernandez et al. [FIA11, 15] der Teilnehmer (Nutzer) und ein Experte über die Einstellung des Teilnehmers bezüglich eines Aspekts des Produktes, welcher bewertet werden soll.

Fokusgruppen

Fokusgruppen hingegen sind Diskussionen mit mehreren Teilnehmern, die die Bewertung des Produktes oder eines Teils des Produktes zum Ziel haben (vgl. [FIA11, 15]). Hegner [Heg03, 29] definiert zudem, dass es sich um moderierte Diskussionen handelt, die mit ausgesuchten Teilnehmern durchgeführt werden.

2.1.4 Analytical Modeling und Simulation Methods

Analytical Modeling wird in der Studie von Fernandez et al. [FIA11, 10] als Engineering -Ansatz beschrieben, der die Vorhersage von Usability durch den Einsatz bestimmter Modelle (z.B. GOMS Analyse) ermöglicht. Laut derselben Studie umfassen Simulation Methods hingegen simulierte Nutzerinteraktionen oder die Analyse von Nutzungsdaten. Diese Kategorien werden für einen bes- seren Gesamteindruck benannt und haben keinen weiteren Bezug zur Usability Studie dieser Arbeit.

2.1.5 Weitere Klassifizierungen

Die Evaluationsmethoden können auch nach deren Einsatzzeitpunkt und -ziel systematisiert werden. Die sog. formative Evaluation findet während des Ent- wicklungsprozesses statt und hat das Ziel, Probleme zu finden und zu beheben (vgl. [Bar10, 14]). Summative Evaluation hingegen findet nach der Fertigstel- lung des Produktes statt, um das Produkt in seiner Gesamtheit zu erfassen oder zu prüfen, ob es die Anforderungen erfüllt (vgl.[Bar10, Heg03]). Diese Arbeit wird sich mit der formativen Evaluation von neonion beschäftigen, da vor der Fertigstellung der Anwendung dessen Usability-Probleme identifiziert werden sollen.

Weiterhin können Evaluationsmethoden auf Basis der

”[...]ArtderDatenerhe-

bung [...]“ [Heg[03], ¹⁵ ] klassifiziert werden. Die Erhebung von quantitativen Da- ten, welche den objektiven Methoden angehört, soll durch die Vermeidung von subjektiven Einflüssen erfolgen (vgl. [Heg[03], ¹⁵ f.]). Subjektive Methoden hin- gegen ermitteln Daten auf der Grundlage der Bewertung durch Benutzer (vgl. [Heg[03], ¹⁵ ]). Hierbei werden qualitative Daten gesammelt. Barnum [Bar[10], ¹³⁶ ] stellt fest, dass die Verwendung von sowohl qualitativen als auch quanti- tativen Feedbackverfahren während eines Usability Tests dazu beitragen kann, die Erfahrungen der Nutzer in der Gesamtheit besser zu erfassen. Deshalb wird die Usability Studie dieser Arbeit sowohl qualitative (Thinking-Aloud Protocol, Umfragen, Log Analysis) als auch quantitative Evaluationsmethoden (Perfor- mance Measurement) beinhalten.

2.2 Defizite bei existierenden Evaluationsmethoden

Wie im vergangenen Abschnitt beschrieben, existiert eine Vielzahl von Methoden zur Bewertung von Usability. Da die Usability Studie dieser Arbeit verschiedene Evaluationsarten beinhaltet, sollten die Defizite möglichst vielfältiger Evaluationsmöglichkeiten erfasst werden. Dafür eignete sich besonders die bereits zuvor angeführte Mapping Studie von Fernandez et al. [FIA11], die eine Vielzahl von Schwächen begründet zusammenfasst.

2.2.1 ”UsabilityEvaluationMethodsfortheWeb:ASystematic Mapping Study“[FIA[11]]

Fernandez, Insfran und Abrahão [FIA11] führten eine systematische Mapping Studie über die Art und den Einsatz von Usability-Evaluationsmethoden für das Web durch. Die Autoren haben als Mitglieder der ISSI Research Group der Universidad Politécnica de Valencia mehrfach gemeinsame Studien im Bereich Web Usability veröffentlicht [sch16].

Das Ziel dieser Studie war es, das bis 2009 gesammelte Wissen über die Evaluation von Web Usability zu kategorisieren und zusammenzufassen. So sollen Lücken in der vorherigen Forschung aufgedeckt und Empfehlungen für zukünftige Forschung abgegeben werden können (vgl. [FIA11, 5]). Insbesondere die ermittelten Mängel und Empfehlungen der Mapping Studie sind für diese Arbeit wertvoll, denn die Erkenntnisse werden als Referenzen zur Einschätzung der Zweckmäßigkeit einer Usability Studie herangezogen.

Die Mapping Studie war folgendermaßen aufgebaut:

1. Durchsuchen von digitalen Bibliotheken (automatisiert) und relevanten Tagesberichten und Zeitschriften (manuell) nach potenziellen Studien aus dem Zeitraum 1996 - 2009, mit Hilfe eines Suchstrings, der die Konzepte Web, Usability und Evaluation beinhaltete.

2.2. Defizite bei existierenden Evaluationsmethoden

2. Bewertung der Autoren von Titel, Abstract und Stichworten dieser Stu- dien bezüglich genau festgelegter Kriterien, um die Auswahl auf Primär- studien einzugrenzen.

3. Entwurf und Beantwortung eines Fragebogens zur Qualitätsbewertung der Primärstudien.

4. Entwurf und Beantwortung eines Fragebogens, um die Primärstudien hinsichtlich bestimmter Charakteristika (u.a. Evaluationsart und empi- rische Validierung) einschätzen zu können (Datenextraktion).

5. Auswertung der Fragebögen, Mapping der Resultate und Schlussfolge- rungen.

Aus 2703 potenziellen Studien wurden 206 Primärstudien selektiert. Die Aus- wertung der Studien erfolgte zunächst einzeln für jedes Charakteristikum. Da- nach erhielten Fernandez et al. zusätzliche Ergebnisse durch das Mappen der Resultate.

Die Autoren benennen folgende Einschränkungen ihrer Studie. Den Primärstudien lagen unterschiedliche Usability-Definitionen zu Grunde. Außerdem konnten Publikations- und Auswahlbias, Ungenauigkeiten bei der Datengewinnung, sowie Fehlklassifizierungen nicht mit Sicherheit ausgeschlossen werden. Folgende Defizite von existierenden Evaluationsmethoden in der Usability wurden von Fernandez et al. geschlussfolgert:

- Es existieren nur wenige Methoden, die in frühen Phasen des Entwicklungsprozesses effektiv eingesetzt werden können.
- Den Methoden liegen unterschiedliche Usability-Aspekte und -Konzepte zu Grunde.
- Mit einer einzelnen Evaluationsmethode können nicht alle Usability-Probleme identifiziert werden.
- Die Ergebnisse der Evaluation bestehen meistens aus einer Liste von Usability-Problemen und keinerlei Empfehlungen der Verbesserung die- ser Probleme.
- Die Ergebnisse der Evaluation werden nur selten empirisch validiert.

Diese Defizite wurden bei der Erstellung dieser Usability Studie berücksichtigt. Zudem bieten sie eine Grundlage zur Einschätzung der Zweckmäßigkeit einer solchen Usability Studie.

2.3 Ziele

Ziel ist es, den Wert einer mit der Software Morae durchgeführten Usability Studie einzuschätzen. Dazu wird eine beispielhafte Evaluation der Webanwen- dung neonion genutzt. Folgende zentrale Fragen lassen sich daraus ableiten:

- Inwiefern ist eine Usability Studie zur Evaluation von Software zweck- mäßig?

- Wie kann eine Usability Studie unter Einbeziehung der Software Morae durchgeführt werden?

Aus den zentralen Fragen können die Anforderungen an die Usability Studie gefolgert werden. Die Usability Studie sollte für einen ausreichenden Praxis- bezug bestmöglich an die zu testende Webanwendung neonion angepasst wer- den. Da eine formative Evaluation durchgeführt wird, sollten die Testbereiche sorgfältig ausgewählt werden, um geeignete Ergebnisse für die Weiterentwick- lung von neonion zu erzielen (vgl.[Bar10, 111]). Außerdem muss die Studie so konzipiert sein, dass die Funktionen des Tools Morae im größtmöglichen Um- fang genutzt werden können. Sowohl Vorbereitung und Durchführung, als auch die Auswertung der Usability Studie sollten von Morae begleitet werden. Die Zweckmäßigkeit der Studie soll anhand der Ergebnisse der Beispielevaluation und den zuvor definierten Defiziten eingeschätzt werden können.

2.3. Ziele

3 Umsetzung

Die Usability Studie war in drei Phasen eingeteilt: Vorbereitung, Durchführung und Analyse. Der erste vorbereitende Schritt war es, die Webanwendung neo- nion kennenzulernen. Durch das eigene Ausprobieren und Gespräche mit dem Entwicklerteam wurde herausgefunden, welche Aufgaben neonion zu bewerk- stelligen versucht und welche Bereiche bereits fertiggestellt und testbar waren. Danach wurde die als Grundlage der Usability Studie dienende Definition von Usability festgelegt (siehe Kapitel 2). Auf dessen Basis wurden die Testziele und messbaren Variablen definiert (siehe Tabellen 4.1, 4.2). Zudem schloss die Vorbereitung die Analyse bereits bestehender Testmethoden, sowie deren De- fizite (siehe Abschnitt2.2) ein. Danach wurden die Funktionen des Usability Tools Morae inspiziert, um herauszufinden, wie Morae in die drei Phasen der Testsitzung integriert werden kann. Danach konnte entschieden werden, welche Testmethoden in der Usability Studie eingesetzt werden.

Auf Basis all dieser Kenntnisse wurde der Testplan konzipiert. Dies beinhalte- te die Definition der Testszenarien und -aufgaben (siehe Abschnitt 3.3), sowie der Zielstellung für den Nutzer und der Studienziele. Hinsichtlich der Aufga- benstellung wurden Anpassungen in neonion vorgenommen, z.B. Hochladen und Annotieren von verschiedenen Texten. Danach wurden die Fragebögen entworfen und entschieden, dass die System Usability Scale (SUS) in den Test integriert wird. Die SUS ist laut Barnum [Bar10, 181 ff.] ein kurzer Fragebo- gen, der aus zehn Fragen, deren Antworten auf einer Fünf-Punkte-Lickert-Skala basieren, besteht. Nach der Beantwortung kann der sogenannte SUS-Score be- rechnet werden (automatisiert m.H. von Morae), eine Zahl, die laut Barnum ein Maß für die gesamte Usability des Systems ist.

Nach der Fertigstellung des Testplans wurden Testteilnehmer rekrutiert und die Testsitzungen innerhalb eines Zeitfensters von drei Tagen angesetzt. Zeit und Ort der Testsitzungen wurden an die Verfügbarkeit der Testteilnehmer an- gepasst. In der Zwischenzeit wurden Szenarien, Aufgaben und Fragebögen ins Englische übersetzt und in Morae Recorder, einer speziellen Anwendung von Morae, eingetragen und abgespeichert. Außerdem wurden die Eigenschaften der Testsitzung, z.B. das selbstständige Starten und Beenden einer Aufgabe durch den Teilnehmer, in Morae Recorder festgelegt. An dieser Testsitzung wurde ein Pilottest durchgeführt. Danach folgten letzte Anpassungen an den Eigenschaften der Testsitzung und die Vorbereitung von Einverständniserklä- rung, Beobachtungskriterien (siehe Tabelle 4.3), Observer Form (siehe 4.15) und der Checkliste (siehe 4.14) für den Testablauf.

Nach der Durchführung der Usability Tests wurden die Beobachtungen aus- gewertet. Die auf dem Observer Form notierten Ereignisse wurden in die An- wendung Morae Manager eingetragen. Außerdem wurden alle Testsitzungen

3.1. Anwendungen

noch einmal angesehen, um weitere Beobachtungen zu dokumentieren. Zu den zuvor definierten Kategorien (siehe Tabelle 4.3) wurden noch weitere hinzu- gefügt, um die qualitativen Beobachtungen genauer spezifizieren zu können. Anschließend wurden mit Hilfe von Affinity Matching einige Beobachtungen nochmals thematisch spezifiziert, um diese zusammenfassen zu können. Affi- nity Matching ist laut Barnum [Bar10, 244] eine Methode zum Sortieren und Kategorisieren von Beobachtungen, bei der die Daten auf Haftnotizen geschrie- ben, an die Wand geklebt und gruppiert werden. Danach werden die Gruppen benannt und priorisiert. Diese Ergebnisse wurden anschließend hinsichtlich der Testziele analysiert, zusammengefasst und mögliche Verbesserungen erarbeitet. Letztendlich wurden allgemeine Schlussfolgerungen bezüglich der Zweckmäßig- keit von Usability Studien gezogen.

3.1 Anwendungen

3.1.1 neonion

Die zu testende Webanwendung ist neonion. Die von der HCC-Gruppe der Freien Universität Berlin entwickelte Anwendung dient der gemeinschaftlichen Annotation von Texten. Annotationen können zwischen verschiedenen Tools und Projekten ausgetauscht und mit der Linked Data Cloud verknüpft wer- den. Außerdem können die Inhalte der Texte durch semantische Annotationen miteinander verbunden werden (vgl. zu diesem Abschnitt [neo16]).

Der Prototyp ist an einigen Stellen noch nicht vollständig implementiert. Von den existierenden Bereichen Documents, Annotations, Import, Vocabulary und Settings sind Settings und einige Funktionen in Annotations und der Textansicht nicht vollständig implementiert. Wenn ein Teilnehmer mit einer Fehl- oder unfertigen Funktion konfrontiert wurde, galt dieses Ereignis als Systemfehler dritter Art (siehe Tabelle 4.2).

Der Bereich Documents (siehe Abbildung 4.1) ist in die Teilbereiche My, Public und Groups eingeteilt. Hier findet der Nutzer die bereitgestellten Dokumen- te und kann diese per Klick öffnen. So gelangt der Nutzer zur Textansicht (siehe Abbildung 4.2), in der der Text hervorgehoben, kommentiert oder mit semantischen Metadaten versehen werden kann. Annotations stellt für jeden Annotationstyp eine Übersicht bereit, die alle erzeugten Annotationen anzeigt (siehe Abbildung 4.3). Unter dem Menüpunkt Import kann ein eigenes Doku- ment hochgeladen werden. Im Bereich Vocabulary (siehe Abbildung 4.4) kön- nen die semantischen Annotationen definiert, gruppiert und miteinander ver- knüpft werden. Alle Bereiche waren für die Teilnehmer zugänglich und konnten in der ersten Aufgabe exploriert werden. Die Aufgaben zwei bis vier zielten auf den Bereich Documents und die Textansicht ab. Der Bereich Vocabulary ist das Kernthema der fünften Aufgabe.

3.1.2 Morae

Die Usability Studie wird mit Hilfe des Tools Morae in der Version 3.3.4 vor- bereitet, durchgeführt und analysiert. Morae ist ein Usability-Tool, mit dem Anwender aufgenommen und beobachtet, sowie die Ergebnisse ausgewertet und präsentiert werden können (vgl. [mor16a]). Morae besteht aus den Anwendun- gen Morae Recorder, Morae Observer und Morae Manager, deren Funktionen im Folgenden kurz erläutert werden. Der Inhalt dieser Abschnitte beruht im Wesentlichen auf den Informationen der Website von Morae [mor16b].

Morae Recorder kann während einer Testsitzung Audio, Video, Bildschirmakti- vitäten und Mausbewegungen aufnehmen und speichern. Der Ablauf der Test- sitzung, z.B. Umfragen und Testaufgaben können ausgewählt, definiert oder abgespeichert werden. Außerdem stellt Morae Recorder einen Autopiloten be- reit, der während einer Testsitzung die Anweisungen anzeigen kann (siehe Ab- bildungen 4.5, 4.7).

Mit der Anwendung Morae Observer kann eine Testsitzung von Teammitgliedern beobachtet werden. Während dieser Sitzung können die Beobachter sowohl über eine Chat-Funktion miteinander kommunizieren, als auch Notizen machen. Außerdem können Zeit, Aufgabenerfolg und Fehlerraten während der Testsitzung gemessen und definiert werden.

Morae Manager stellt verschiedene Werkzeuge zur Analyse der Aufnahmen bereit. Mehrere Aufnahmen können gleichzeitig durchsucht und deren Daten dabei verglichen, gesichtet und bearbeitet werden. Morae Manager stellt außerdem eine automatische Datenanalyse bereit (beispielsweise die Berechnung des SUS-Scores) und eine Möglichkeit zur Erstellung und zum Exportieren von Grafiken, Videos und Datentabellen.

Zur Planung der Usability Studie wurde in dieser Arbeit Morae Recorder ver- wendet. Dort wurden Willkommenstext, Aufgaben und Fragebögen erstellt und gespeichert. Außerdem wurden die Autopilot-Funktionen eingerichtet, sodass der Teilnehmer Tasks eigenständig beginnen und beenden konnte (siehe Ab- bildungen 4.5, 4.6). Außerdem wurden alle Testsitzungen mit Hilfe von Morae Recorder aufgezeichnet. Im Morae Manager wurden alle Aufzeichnungen der Testsitzungen gesammelt und die Ereignisse geloggt, kategorisiert, sortiert und exportiert. Morae Observer wurde aufgrund mangelnder technischer Möglich- keiten nicht in diese Studie integriert.

3.2 Methodologie der Studie

Wie bereits im Kapitel Hintergrund erläutert, wird im Rahmen dieser Arbeit die Usability Evaluation von neonion mit Hilfe einer Usability Studie durch- geführt. Die Studie enthält einerseits Methoden aus der Kategorie User Tes- ting (Think-Aloud Protocol, Performance Measurement und Log-Analyse) und andererseits eine Inquiry Method (Umfrage). Während der Testsitzungen wer- den sowohl qualitative als auch quantitative Daten gesammelt und die Eva-

3.2. Methodologie der Studie

luationsmethode gehört der formativen Evaluation an. Außerdem werden die Testteilnehmer unter möglichst ähnlichen Bedingungen dabei beobachtet, wie sie bestimmte Aufgaben mit dem Testprodukt erfüllen.

3.2.1 Testbedingungen

Um vergleichbare Ergebnisse zu erhalten, sollten die Testbedingungen mög- lichst konstant gehalten werden. Testaufbau, Laptop und verwendete Software waren für alle Teilnehmer gleich. Jeder bekam die gleichen vier Aufgaben und drei Umfragen mit Hilfe des Autopiloten von Morae Recorder gestellt. Außer- dem starteten und beendeten die Teilnehmer die Aufgaben selbstständig via Klick auf den entsprechenden Button. Eine Testsitzung dauerte maximal 60 Minuten. Wenn das Überschreiten der Gesamtzeit drohte, sowie im Fall von Problemen mit Morae oder dem Browser, griff einer der Beobachter ein. Fra- gen zur Lösung der Aufgaben oder zu neonion selbst wurden nicht beantwortet. Der Laptop, mit dessen Hilfe alle Testsitzungen durchgeführt wurden, hat das Betriebssystem Windows 7 Enterprise. Darüber hinaus wurde der Browser Mo- zilla FirefoxESR (45.2.0) von allen Teilnehmern verwendet.

Fünf von acht Testsitzungen fanden im Foyer des Max-Planck-Institutes für Wissenschaftsgeschichte (MPIWG) an drei Wochentagen zwischen 10:30 Uhr und 15:15 Uhr statt. Die drei verbleibenden Testsitzungen fanden an einem Tag von 13:00 Uhr bis 17:45 Uhr im Exzellenzcluster der Humboldt-Universität zu Berlin (Cluster) statt (siehe Tabelle 4.4). Da die Räumlichkeiten auch für andere Personen während der Testsitzungen zugänglich waren, war der Laut- stärkepegel unterschiedlich. Jeder Teilnehmer wurde von zwei Personen be- grüßt, beobachtet und verabschiedet. Während aller Testsitzungen saßen die Beobachter schräg links hinter dem Teilnehmer. Nach jeder Testsitzung wurde neonion zurückgesetzt, sodass alle Teilnehmer mit der gleichen Version von neonion arbeiten konnten.

3.2.2 Testteilnehmer

Insgesamt acht Teilnehmer aus dem MPIWG bzw. Cluster konnten mittels E-Mail bzw. einer kurzen Präsentation rekrutiert werden. Gesucht wurden Wissenschaftler, denn bei diesen wurde vermutet, dass sie der regelmäßig Tex- te lesenden und Texte annotierenden Zielgruppe angehören. Außerdem sollten die Teilnehmer vertraut im Umgang mit dem Browser sein und neonion noch nicht kennen. Diese Kriterien wurden zuvor nicht erfragt, weil es Bestand- teil der ersten Aufgabe war (siehe Abbildung 4.8), Einsatzmöglichkeiten der Webanwendung neonion zu beschreiben. Um zu vermeiden, dass sich einige Teilnehmer zuvor über neonion informieren, wurden keine Informationen über den Testgegenstand bzw. das Thema bekanntgegeben.

Zwei von acht Teilnehmern sprachen während der Testsitzung deutsch und nutzten ausschließlich die deutschen Aufgabenstellungen. Ein Teilnehmer sprach vorwiegend englisch und nutzte hauptsächlich die englischen Aufgabenstellun- gen. Dieser Teilnehmer griff während des ”lautenDenkens“zweiMalaufei- ne deutsche Bezeichnung zurück und las einmal zusätzlich die deutsche Auf- gabenstellung. Die anderen fünf Teilnehmer sprachen ausschließlich englisch und nutzten die englischen Aufgabenstellungen. Einer dieser Teilnehmer über- sprang versehentlich die erste Aufgabe und bemerkte es nicht. Ohne vorherige Exploration waren die Ergebnisse nicht mit denen der anderen vergleichbar. Deshalb wurde dieser Datensatz zwar analysiert (qualitative Beobachtungen gekennzeichnet), aber bei der Auswertung nicht betrachtet. Die Testteilneh- mer beschrieben sich selbst in drei von vier Fragebögen, welche im Folgenden ausgewertet werden.

Allgemeiner Fragebogen (siehe Abb. 4.8)

Zu Beginn der Testsitzung wurde der allgemeine Fragebogen beantwortet, um Informationen zum Browsingverhalten der Teilnehmer (Fragen 1 und 2) und neonion (Fragen 3 und 4) zu erhalten. Diese Fragen wurden noch vor der Explo- ration gestellt, um einen nicht geeigneten Teilnehmer rechtzeitig herausfiltern zu können. Als nicht geeignet hätten sich Teilnehmer erwiesen, die sich un- sicher im Umgang mit dem Browser fühlen. Falls neonion einem Teilnehmer zuvor bekannt gewesen wäre, hätten die Datensätze anders betrachtet werden müssen. Sechs von sieben Teilnehmern stimmten der Aussage ”Ich bin sicher im Umgang mit dem Browser am Laptop oder am PC“ stark zu. Ein Teilneh- mer stimmte zu. Die Frage ”WelcheTätigkeitübenSiehauptsächlichmitdem Browser aus?“ beantworteten vier von sieben Teilnehmern mit Suche, zwei Teilnehmer mit Informationsportale und ein Teilnehmer mit E-Mail (siehe Abbildung 4.32). Die Fragen ”KennenSiedasProgrammneonion?“und ”Haben Sie schon einmal mit dem Programm neonion gearbeitet?“ beantworteten alle Teilnehmer mit nein.

Spezieller Fragebogen (siehe Abb. 4.8)

Dieser Fragebogen wurde nach der Exploration beantwortet, da das Thema der Webanwendung nun nicht länger verborgen bleiben musste. Einige Teilnehmer wussten zu diesem Zeitpunkt, um welche Art von Software es sich handelt, was ihre Antworten beeinflusst haben könnte. Hierbei sollte herausgefunden werden, inwieweit die Teilnehmer der Zielgruppe entsprechen. Vier von sieben Teilnehmern lesen mehrmals täglich Texte, die verbleibenden drei Teilnehmer lesen täglich Texte. Ebenfalls vier von sieben Teilnehmern lesen Texte haupt- sächlich mit dem Medium Laptop/PC. Zwei Teilnehmer lesen Texte haupt- sächlich mit dem Tablet/Smartphone und ein Teilnehmer liest hauptsächlich Printmedien (siehe Abbildung 4.33). Drei von sieben Teilnehmern lesen Texte vorwiegend online, weitere drei Teilnehmer lesen Texte online und offline zu gleichen Teilen und ein Teilnehmer liest Texte vorwiegend offline (siehe Abbil- dung 4.34).

[...]