View
5
Download
0
Category
Preview:
Citation preview
Hochschule für Technik und Wirtschaft Dresden (FH)
Fachbereich Informatik/Mathematik
Diplomarbeit
im Studiengang Medieninformatik
Mobiles Internet –
Evaluation der Benutzerfreundlichkeit von Handybrowsern und Entwicklung
eines optimierten Designs
eingereicht von: Annett Schulz
eingereicht am: 30. Juni 2008
Betreuer: Prof. Dr. Teresa Merino,
Hochschule für Technik und Wirtschaft (FH), Dresden
Dipl. Ing. Markus Jordans,
P3 Solutions GmbH, Aachen
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Abbildungsverzeichnis................................................................................................. IV
Tabellenverzeichnis.....................................................................................................VII
Abkürzungsverzeichnis ............................................................................................ VIII
Einleitung.........................................................................................................................1
1 Mobiles Internet ........................................................................................................3
1.1 Begriffe ................................................................................................................3
1.1.1 Handy ............................................................................................................3
1.1.2 Smartphone ...................................................................................................3
1.1.3 Browser .........................................................................................................4
1.1.4 Handybrowser ...............................................................................................4
1.1.5 Mobile Webseite ...........................................................................................5
1.1.6 WAP..............................................................................................................5
1.1.7 WAP 2.0........................................................................................................7
1.1.8 i-mode ...........................................................................................................8
1.2 Arten von Browsern .............................................................................................8
1.3 Meilensteile in der Entwicklung der mobilen Browser........................................9
1.4 Zahlen und Organisationen ................................................................................10
1.5 Verwendungsmöglichkeiten...............................................................................13
1.6 Gründe für die zurückhaltende Nutzung des mobilen Internets.........................14
2 Usability ...................................................................................................................17
2.1 Begriffe ..............................................................................................................18
2.1.1 Usability-Evaluation ...................................................................................18
2.1.2 Usability-Problem .......................................................................................20
2.2 Arten von Usabilitytests.....................................................................................21
2.2.1 Nutzertest ....................................................................................................22
2.2.2 Expertentest.................................................................................................29
2.2.3 Gegenüberstellung Nutzertest und Expertentest .........................................33
2.2.4 Discount Usability Engineering ..................................................................34
2.2.5 Usabilitytest mit mobilen Endgeräten.........................................................35
2.3 Usabilityanforderungen an mobile Anwendungen ............................................37
2.3.1 Interface Guidelines für mobile Endgeräte .................................................38
Inhaltsverzeichnis
II
2.3.2 Usabilityanforderungen an mobile Browser ...............................................46
3 Nutzertest zur Evaluation der Handybrowser .....................................................48
3.1 Planung des Nutzertests .....................................................................................48
3.1.1 Methodik .....................................................................................................49
3.1.2 Testnutzer....................................................................................................50
3.1.3 Aufgabengestaltung.....................................................................................52
3.1.4 Testumgebung.............................................................................................58
3.1.5 Handymodell ...............................................................................................59
3.1.6 Browser .......................................................................................................61
3.1.6.1 Nokia-Browser .....................................................................................64
3.1.6.2 Opera Mini-Browser ............................................................................64
3.1.6.3 TeaShark-Browser................................................................................65
3.1.7 Pilottest........................................................................................................65
3.2 Durchführung des Nutzertests............................................................................66
3.3 Ergebnisse und Auswertung des Nutzertests .....................................................70
3.3.1 Was lief gut? ...............................................................................................71
3.3.2 Schwierigkeiten bei der Testdurchführung .................................................72
3.3.3 Strukturierung der Ergebnisse.....................................................................75
3.3.4 Abgeleitete Anforderungen an die Gestaltung eines Handybrowsers.........79
3.3.5 Bewährte Eigenschaften der Browser .........................................................91
3.3.6 Browserunabhängige Ergebnisse ................................................................94
4 Experteninspektion zur Evaluation der Handybrowser .....................................97
4.1 Planung der Experteninspektion ........................................................................97
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion................99
5 Entwicklung eines optimierten Designs ..............................................................107
5.1 Ausgangspunkt.................................................................................................107
5.2 Lösungsempfehlungen zu den zentralen Usability-Problemen........................109
5.3 Vorstellung des optimierten Browsers .............................................................112
6 Fazit ........................................................................................................................119
6.1 Zusammenfassung der Ergebnisse ...................................................................119
6.2 Guidelines für mobile Browser ........................................................................122
Literaturverzeichnis....................................................................................................124
Inhaltsverzeichnis
III
Internetquellen ............................................................................................................126
Anhang .........................................................................................................................129
Selbständigkeitserklärung..........................................................................................165
Abbildungsverzeichnis
IV
Abbildungsverzeichnis
Abbildung 1-1: Easy to use [www01]...............................................................................1
Abbildung 1-1: Smartphone Nokia N95 [www03]...........................................................4
Abbildung 1-2: Smartphone Sony Ericsson P1i mit QWERTZ-Tastatur und Eingabestift [www04] .................................................................................................4
Abbildung 1-3: Typischer WAP-Browser mit Startseite und URL-Eingabe [www05] ...6
Abbildung 1-4: Funktionsweise WAP und WAP 2.0 .......................................................7
Abbildung 1-5: Microsoft Mobile Explorer 3.0 mit Suchmaske und Ergebnis [www07]...............................................................................................................10
Abbildung 1-6: UMTS-Anschlüsse in Deutschland [www09] .......................................11
Abbildung 1-7: Nutzung des mobilen Internets sowie E-Mail in Deutschland (DE) [www10] ...............................................................................................11
Abbildung 2-1: Gefundene Bedienprobleme in Abhängigkeit von der Anzahl der Tester [www16] ...............................................................................................23
Abbildung 2-2: Abhängigkeit der gefunden Usability-Probleme von der Anzahl der Gutachter [www19]...............................................................................30
Abbildung 2-3: Path of reasoning (verändert [nach Keinonen2003]).............................38
Abbildung 2-4: Aufmerksamkeitsspanne in verschiedenen mobilen Situationen [Oulasvirta2005] ...................................................................................42
Abbildung 3-1: Planungsschritte des Nutzertests ...........................................................48
Abbildung 3-2: Verwendungsmöglichkeiten des mobilen Internets [www09] ..............53
Abbildung 3-3: Testraum bei P3 Solutions.....................................................................59
Abbildung 3-4: Testhandy Nokia 6500 slide ..................................................................60
Abbildung 3-5: Web'n'walk-Browser von T-Mobile mit Opera Mini als Basis [www24]...............................................................................................................62
Abbildung 3-6: Opera Mini-Browser im Original ..........................................................62
Abbildung 3-7: Funktionsweise des Opera Mini über einen Proxyserver [www26]......64
Abbildung 3-8: Testsetup während der Durchführung ...................................................67
Abbildung 3-9: Aufzeichnung des Tests per Videokamera ............................................69
Abbildung 3-10: Wahrnehmung von Bedienstrategien durch den Nutzer......................70
Abbildung 3-11: Strukturierung der Findings mittels Klebezettel..................................76
Abbildung 3-12: Finding mit Browserreihenfolge (rechts oben) und Häufigkeit (rechts unten).....................................................................................................76
Abbildung 3-13: Clusterbildung der Findings ................................................................77
Abbildung 3-14: Aggregation allgemeiner Problemfelder .............................................80
Abbildungsverzeichnis
V
Abbildung 3-15: TeaShark – Menübalken nicht sichtbar ...............................................82
Abbildung 3-16: Opera Mini - Eingabeleiste für URLs .................................................84
Abbildung 3-17: TeaShark – Suchleiste von Google......................................................84
Abbildung 3-18: Nokia - Ladestatus ...............................................................................85
Abbildung 3-19: Opera Mini - Zoomübersicht der normalen Webseite kicker.de .........86
Abbildung 3-20: TeaShark – Zoomübersicht der mobilen Webseite mobil.bahn.de......86
Abbildung 3-21: Nokia – Option „Ändern“ bei der Formulareingabe ...........................88
Abbildung 3-22: Nokia – Bestätigung per „OK“ bei der Formulareingabe nötig ..........88
Abbildung 3-23: TeaShark – grafischer Verlauf („List“) ...............................................89
Abbildung 3-24: TeaShark - Verlauf als Liste („Visited“) .............................................89
Abbildung 3-25: Klebezettel inklusive positiver Kommentare ......................................92
Abbildung 3-26: TeaShark - Auto-Vervollständigen von Internetadressen ...................94
Abbildung 3-27: Nokia - Symbol der GPRS-Verbindung ..............................................95
Abbildung 4-1: Nokia – Bezeichnung „Cookie-Einstellungen“ ...................................101
Abbildung 4-2: Nokia – Bezeichnung „Cookies“.........................................................101
Abbildung 4-3: Nokia - horizontales Scrollen erforderlich ..........................................104
Abbildung 4-4: Opera Mini - Mobil-Ansicht................................................................104
Abbildung 4-5: Opera Mini - Auflistung der Tastaturkürzel ........................................105
Abbildung 5-1: Platzierung der Browser nach Gefallen...............................................107
Abbildung 5-2: „Wie hat dir der generelle Umgang mit dem Browser gefallen?“.......108
Abbildung 5-3: „Wie oft hattest du Probleme die Bezeichnungen im Menü zu deuten?“.............................................................................................................108
Abbildung 5-4: Opera Mini - Menü „Extras“ ...............................................................113
Abbildung 5-5: Optimierte Version - Menü „Extras“...................................................113
Abbildung 5-6: Opera Mini - Menü „Einstellungen“ ...................................................113
Abbildung 5-7: Optimierte Version - Menü „Einstellungen“ .......................................113
Abbildung 5-8: Opera Mini - Menü „Lesezeichen“......................................................114
Abbildung 5-9: Optimierte Version - Menü „Lesezeichen“ .........................................114
Abbildung 5-10: Opera Mini – Übersicht Lesezeichen ................................................114
Abbildung 5-11: Optimierte Version - Übersicht Lesezeichen.....................................114
Abbildung 5-12: Opera Mini - Hyperlinks schlecht erkennbar ....................................115
Abbildung 5-13: Optimierte Version - Hyperlinks blau markiert.................................115
Abbildung 5-14: Opera Mini - Eingabemaske für Formulardaten................................115
Abbildung 5-15: Optimierte Version - direkte Eingabe von Formulardaten ................115
Abbildungsverzeichnis
VI
Abbildung 5-16: Opera Mini - Bild gespeichert ...........................................................116
Abbildung 5-17: Optimierte Version - Speicherort für Bild wählbar ...........................116
Abbildung 5-18: Optimierte Version - Statusmeldung „Seitenaufbau abgebrochen“ ..116
Abbildung 5-19: Opera Mini - Eingabemaske für URLs..............................................117
Abbildung 5-20: Optimierte Version - Funktion Auto-Vervollständigen ....................117
Abbildung 5-21: Optimierte Version - integrierte Suchfunktion..................................117
Abbildung 5-22: Optimierte Version - Statusmeldung „Lesezeichen gespeichert“......118
Tabellenverzeichnis
VII
Tabellenverzeichnis
Tabelle 1-1: Unterschiede zwischen WAP- und Web-Browser........................................9
Tabelle 2-1: Stufen der Ernsthaftigkeit von Usability-Problemen [nach Schweibenz2003].......................................................................................21
Tabelle 2-2: Gegenüberstellung der Guidelines für mobile Geräte von Gong & Tarasewich sowie Weiss ............................................................................39
Tabelle 3-1: Priorisierung der Browserfunktionen (Auszug)..........................................54
Tabelle 3-2: Aufgaben des Nutzertests inklusive Zweck................................................55
Tabelle 3-3: Verteilung der Browserreihenfolge auf die Testnutzer ..............................68
Tabelle 3-4: Verteilung der Prioritätsstufen auf die Findings beim Browser TeaShark (Auszug).....................................................................................................78
Tabelle 3-5: Verteilung der Usability-Probleme aus dem Nutzertest auf die einzelnen Browser......................................................................................................79
Tabelle 4-1: Verteilung der Usability-Probleme aus der Experteninspektion auf die einzelnen Browser....................................................................................100
Tabelle 5-1: Schwere Usability-Probleme aus Nutzer- und Expertentest mit Empfehlungen für den Opera Mini ..........................................................109
Tabelle 5-2: Gegenüberstellung der originalen und der optimierten Version des Opera Mini..........................................................................................................113
Tabelle 6-1: Ergebnisse des Nutzertests vom Opera Mini-Browser.............................133
Tabelle 6-2: Ergebnisse des Nutzertests vom Nokia-Browser......................................137
Tabelle 6-3: Ergebnisse des Nutzertests vom TeaShark-Browser ................................146
Tabelle 6-4: Bewährte Eigenschaften der Handybrowser aus dem Nutzertest .............152
Tabelle 6-5: Browserunabhängige Ergebnisse aus Nutzertest und Experteninspektion.................................................................................................................155
Abkürzungsverzeichnis
VIII
Abkürzungsverzeichnis
AJAX Asynchronous Javascript and XML
BITKOM Bundesverband Informationswirtschaft, Telekommunikation und neue
Medien e.V.
cHTML Compact HTML
CSS Cascading Style Sheets
DIN Deutsches Institut für Normung
DSL Digital Subscriber Line
EN Europäische Norm
GPRS General Packet Radio Service
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
ISO Internationale Organisation für Normung
JAVA ME Java Micro Edition
N Nokia-Browser
OM Opera Mini-Browser
OMA Open Mobile Alliance
PDA Personal Digital Assistant
SMS Short Message Service
TS TeaShark-Browser
UMTS Universal Mobile Telecommunications System
UNCTAD United Nations Conference on Trade and Development
URL Uniform Ressource Locator
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WML Wireless Markup Language
WSP Wireless Session Protocol
WWW World Wide Web
XHTML Extensible HyperText Markup Language
XML Extensible Markup Language
Einleitung
1
Abbildung 1-1: Easy to use [www01]
Einleitung
In der heutigen Zeit hört mal überall die Begriffe Internet, WAP 2.0 oder mobiles Inter-
net. Was aber bedeutet „mobiles Internet“? Es beschreibt genau genommen den Zugang
zum World Wide Web über mobile Endgeräte wie Handys oder PDAs. Durch den Ein-
satz dieser kabellosen und damit mobilen Geräte ist die Internetnutzung allerorts mög-
lich und gestattet damit ein allgegenwärtiges Internet. Das klingt nach ungeahnten Mög-
lichkeiten: zum Beispiel auf dem Weg zur Arbeit noch schnell die neuesten Nachrichten
lesen. Plötzlich ertönt die Durchsage, dass sich der Zug verspätet. Kein Problem, denn
Dank der mobilen Bahnauskunft erfährt man direkt die neue Ankunftszeit und kann im
Büro Bescheid geben. Oder beim Wanderausflug am Wochenende kann der Vater sich
die neuesten Sportergebnisse anschauen und trotzdem die Zeit mit den Kindern genie-
ßen. Gleichzeitig kann er den Wetterbericht aufrufen und nachschauen, ob das Picknick
noch verlängert werden kann oder ob man aufgrund des angekündigten Regenschauers
sich lieber schnell auf den Rückweg machen sollte. Das hört sich nach vielfältigen
Möglichkeiten und breiten Einsatzgebieten an. Trotzdem wird das mobile Internet viel
weniger genutzt als erwartet. Einer der mutmaßlichen Gründe soll in dieser Diplomar-
beit näher untersucht werden: die mangelnde Benutzerfreundlichkeit des Browsers auf
dem Handy.
Gegenstand dieser Diplomarbeit ist die Untersuchung der Usability drei verschiedener
Handybrowser. Die Evaluation der Benutzerschnittstellen erfolgt mithilfe eines Nutzer-
tests. Anschließend wird eine Experteninspektion zur Ergänzung der Ergebnisse durch-
geführt. Die aufgetretenen Usability-Probleme werden analysiert und mit Lösungsvor-
Einleitung
2
schlägen versehen. Zum Abschluss wird anhand der Lösungen eine optimierte Nutzer-
schnittstelle in Hinblick auf Design und Funktionalität entworfen.
Das erste Kapitel behandelt das Thema des mobilen Internets. Es stellt verschiedene
Begriffe vor, beschreibt die Verwendungsmöglichkeiten und zeigt diverse Gründe auf,
warum das mobile Internet noch nicht effektiv genutzt wird. Das zweite Kapitel geht
auf das Thema Usability ein. Es stellt die wichtigsten Testmethoden sowie die speziel-
len Usabilityanforderungen an mobile Anwendungen vor. Daraus werden Anforderun-
gen an mobile Browser abgeleitet und präsentiert. Das dritte Kapitel beschäftigt sich
detailliert mit dem Nutzertest der drei Handybrowser Nokia, Opera Mini und TeaShark.
Dabei werden alle Phasen, angefangen von der Planung über die Durchführung bis hin
zu den verschiedenen Ergebnissen und deren Auswertung, vorgestellt. Im viertel Kapi-
tel wird die Umsetzung der theoretischen Grundlagen der Interface Guidelines mithilfe
einer Experteninspektion an den drei Handybrowsern überprüft. Die Planung des Exper-
tentests, die verwendeten Heuristiken sowie die Ergebnisse werden beschrieben. Das
fünfte Kapitel befasst sich mit der Optimierung des Browserdesigns und stellt die ver-
besserte Version anhand von grafischen Szenarien dar. Das letzte Kapitel beinhaltet
eine Zusammenfassung der Ergebnisse und eine Sammlung der erstellten Guidelines für
mobile Browser.
Die vorliegende Diplomarbeit entstand in dem Unternehmen P3 Solutions GmbH1.
P3 Solutions wurde 2001 als erste von mittlerweile acht Tochterfirmen der P3 Ingeni-
eurgesellschaft in Aachen gegründet. Das Geschäftsfeld der P3 Solutions ist die Tech-
nologieberatung und das Qualitätsmanagement in Mobilfunknetzen. Internationalen
Kunden bietet die P3 Solutions weltweite Dienstleistungen und Outsourcing in den Be-
reichen Network Testing und Netzoptimierung sowie das Testen von Endgeräten, Zube-
hör und Applikationen aus einer Hand an.
1 im Internet zu finden unter: www.p3-solutions.de
1.1 Begriffe
3
1 Mobiles Internet
„Fundamentally ‚mobile’ refers to the user, and not the device or the application.“
Barbara Ballard [zitiert nach www02]
Der Begriff „mobiles Internet“ oder auch „Mobile Web“ bezeichnet den drahtlosen Zu-
gang zum Internet via Mobiltelefon, PDA und ähnlichen mobilen Endgeräten. Meist
spricht man vom mobilen Internet, wenn man den Zugriff auf das World Wide Web per
Handy meint. Genau genommen bezeichnet der Begriff nicht nur den Zugang zum In-
ternet, sondern auch zu Services wie WAP oder i-mode. Da WAP nur eine abgespeckte
Form des Internets darstellt, sprechen Marketingstrategen oft vom „echten Internet“,
wenn sie das World Wide Web meinen.
1.1 Begriffe
1.1.1 Handy
Der Begriff Handy bezeichnet ein tragbares, batteriebetriebenes Mobiltelefon. Zur
Sprach- und Datenübertragung kommuniziert es per Funk über ein Telefonnetz. Es gibt
verschiedene Arten von Mobiltelefonen. In der vorliegenden Arbeit wird der Begriff
Handy unter der Definition eines handlichen, ortsunabhängigen Telefons verwendet. Zu
den sogenannten Mobiltelefonen zählen neben dem Handy auch das fest installierte Au-
totelefon und das Satellitentelefon. Handys besitzen im Gegensatz zu Smartphones kein
erweiterbares Betriebssystem und können lediglich Java-Applikationen ausführen. Ein
Handy kann vielfältig benutzt werden, zum Telefonieren, SMS verschicken, um Fotos
zu machen, als Wecker oder um im Internet zu surfen.
1.1.2 Smartphone
Der Begriff Smartphone bezeichnet wörtlich übersetzt ein intelligentes Mobiltelefon.
Intelligent deshalb, weil es die Funktionalität eines Handys mit den Organizerfunktio-
nen eines PDAs vereint. Im Gegensatz zu einem Handy ist ein Smartphone mit einem
Betriebssystem, z.B. Windows Mobile, Symbian oder Linux Embedded, ausgestattet.
Dadurch ist es möglich den Funktionsumfang durch zusätzliche Software zu erweitern.
Äußerlich gesehen besteht oft kein Unterschied zu einem Handy. Die Übergänge sind
1.1 Begriffe
4
fließend. In einigen Fällen verfügen Smartphones jedoch über alternative Eingabemög-
lichkeiten, wie z.B. Touchscreen oder eine QWERTZ-Tastatur (Abbildung 1-2).
Abbildung 1-1: Smartphone Nokia N95 [www03] Abbildung 1-2: Smartphone Sony Ericsson P1i mit QWERTZ-Tastatur und Eingabestift [www04]
1.1.3 Browser
Die Bezeichnung Browser stammt aus dem Englischen und bedeutet soviel wie „blät-
tern“. Der Browser ist ein Programm, welches dazu benutzt wird, um im Internet zu
surfen. Mit diesem Programm können die unterschiedlichsten HTML-Dokumente von
Text bis Multimedia dargestellt werden. Zusätzlich können Java-Applets (bewegte Gra-
fiken und interaktive Elemente) angezeigt werden. Die bekanntesten Web-Browser sind
der Internet Explorer, Mozilla Firefox und Opera. Im weiteren Verlauf wird dieser
Browser unter dem Begriff „PC-Browser“ verwendet, damit keine Verwechslungen mit
dem Handybrowser auftreten.
1.1.4 Handybrowser
Ein Handybrowser wird oft als „kleiner Bruder“ des PC-Browsers bezeichnet. Dies
rührt daher, dass er erstens aus den PC-Browsern hervorgegangen ist und zweitens eine
in der Funktionalität reduzierte Version seines „großen Bruders“ darstellt. Folglich tritt
er häufig unter den Begriffen „Microbrowser“, „Minibrowser“ oder „mobiler Browser“
1.1 Begriffe
5
auf. Die Aufgabe eines mobilen Browsers ist die Darstellung von Internetseiten auf mo-
bilen Geräten wie Handys oder PDAs. Durch das spezielle Umfeld gelten andere An-
forderungen als an PC-Browser. Handybrowser müssen sich auf die kleine Speicherka-
pazität und die geringe Bandbreite der Mobiltelefone einstellen. Auf den meisten aktu-
ellen Handys ist bereits ein Browser, wie der Nokia Series 40-Browser oder der Opera
Mini, installiert. Im weiteren Verlauf werden die Begriffe „Handybrowser“ und „Brow-
ser“ synonym verwendet.
1.1.5 Mobile Webseite
Viele Webseitenbetreiber entwickeln spezielle mobile Webseiten, sozusagen eine mobi-
le Version der Homepage. Der Vorteil der mobilen Internetseiten liegt in der Anpassung
an die Darstellung auf mobilen Geräten. Das heißt, die Webseiten sind in der Seitengrö-
ße angepasst und Bilder werden eher sparsam verwendet. Zusätzlich wird oft die Navi-
gation an die kleinen Bildschirme von mobilen Endgeräten angepasst. Es ergibt sich
eine geringere Datenmenge, im Vergleich zu einer normalen Webseite, und die Über-
tragung läuft schneller und damit kostengünstiger ab. Für die Erstellung mobiler Web-
seiten hat das World Wide Web Consortium (W3C) im Jahr 2006 eine Sammlung von
Guidelines unter dem Namen „Mobile Web Best Practices 1.0“ veröffentlicht. Diese
sind im Internet erhältlich unter: http://www.w3.org/TR/mobile-bp.
Mobile Internetseiten können anhand ihrer URL recht einfach erkannt werden. Sie hei-
ßen „mobil.bahn.de“, „mobile.google.com“ oder „spiegel.mobi“. Die Endung „.mobi“
(sprich: dotMobi) ist eine Top Level Domain (ähnlich wie .de oder .com), die Internet-
seiten speziell für mobile Geräte darstellt. Damit wird im Internet quasi ein eigener Be-
reich für mobile Webseiten geschaffen. Der größte Vorteil einer .mobi-Domain besteht
darin, dass die Besucher einer .mobi-Seite sicher sein können, dass die Webseite auf
ihrem mobilen Endgerät korrekt dargestellt wird. Denn die Betreiber einer derartigen
Domain müssen den von .mobi entwickelten Styleguide für die Erstellung von mobilen
Inhalten einhalten. Dieser Styleguide entspricht den Standards des W3C.
1.1.6 WAP
WAP steht für „Wireless Application Protocol“ und ähnelt dem WWW. Die Benutzer
können Webseiten abrufen und über Hyperlinks navigieren. Der Unterschied ist, dass
1.1 Begriffe
6
die WAP-Seiten speziell für die Darstellung auf Handydisplays entwickelt wurden.
�Zur Darstellung der Inhalte dient die Beschreibungssprache WML (Wireless Markup
Language). WML lässt sich mit dem HTML des WWW vergleichen, besitzt gegenüber
HTML jedoch nur einen limitierten Sprachumfang und ist speziell für mobile Endgeräte
ausgelegt [Roth2005].
Die erste Version WAP 1.0 wurde 1997 vom WAP-Forum (heute Open Mobile Allian-
ce) als Standard festgelegt. Dieser war jedoch technisch noch nicht ausgereift und es
fehlte die nötige Browsersoftware. Daher konnte sich WAP 1.0 nicht durchsetzen. Im
Jahr 1999 wurde der Standard 1.1 veröffentlicht. Diese WAP-Version konnte sich dann
auf dem Markt etablieren. Somit war bald jedes mobile Endgerät mit einem WAP-
Browser (Abbildung 1-3) ausgerüstet. Kurze Zeit später folgte die Version 1.2, die je-
doch nur eine geringfügige Verbesserung ihres Vorgängers darstellte.
Abbildung 1-3: Typischer WAP-Browser mit Startseite und URL-Eingabe [www05]
Der Abruf von Webseiten mit einem WAP-fähigen Handy funktioniert folgendermaßen:
Der Nutzer tippt eine URL in den WAP-Browser, z.B. wap.bahn.de. Der Browser sen-
det eine Anforderung per WSP (Wireless Session Protocol) an den WAP-Server. Dieser
Server schickt die Anforderung per HTTP weiter zum Webserver. Dort liegen sowohl
HTML- als auch WML-Dateien. Der Webserver schickt die gewünschte WML-Datei
per HTTP zurück an den WAP-Server. Dieser konvertiert die WML-Datei in ein binäres
Format, welches das übertragene Volumen deutlich reduziert und damit die Übertra-
gung zum Handy beschleunigt. Dann schickt der WAP-Server die binäre WML-Datei
1.1 Begriffe
7
per Mobilfunknetz zurück an das Handy. Der Handybrowser stellt schließlich die emp-
fangene WML-Seite dar (vgl. Abbildung 1-4).
Die Umwandlung in ein binäres Format erklärt, warum Bilder per WAP nur reduziert
und in schwarz/weiß dargestellt werden können. Eingebettete Objekte, wie Java-Applets
oder JavaScript-Programme können gar nicht ausgeführt werden.
1.1.7 WAP 2.0
Im Jahr 2001 wurde WAP 2.0 als neuer Standard festgelegt. Der größte Unterschied zur
vorherigen Version liegt darin, dass WAP 2.0 als Seitenbeschreibungssprache neben
WML auch XHTML zulässt. Diese Auszeichnungssprache unterstützt Farbgrafiken und
Cascading Style Sheets (CSS) [Roth2005]. Ein WAP-Browser, welcher WAP 2.0 nutzt,
kann auch „normale“ Webseiten darstellen und wird daher ebenfalls als „Web-Browser“
bezeichnet.
Durch die Verwandtschaft zu HTML kann WAP 2.0 auch HTTP verwenden. Somit
wird der WAP-Server und die Binärumwandlung überflüssig (vgl. Abbildung 1-4). Mo-
bile Dienste in Kombination mit schnellen Übertragungsstandards wie GPRS oder
UMTS können nun noch effektiver genutzt werden.
Abbildung 1-4: Funktionsweise WAP und WAP 2.0
WAP 2.0 wird häufig auch als das „echte Internet“ bezeichnet, weil auch „normale“
Internetseiten darstellbar sind. Aktuelle Webseiten nutzen zusätzlich zu HTTP auch
1.2 Arten von Browsern
8
Java, Flash und andere Technologien. Da viele Handymodelle diese Inhalte ohne spe-
zielle Software nicht darstellen können, können nicht alle Funktionen des „echten Inter-
nets“ genutzt werden. Als Lösung für dieses Problem werden HTML-Seiten oft durch
einen Proxyserver bearbeitet und somit auf die Handydarstellung angepasst (z.B. beim
Opera Mini).
1.1.8 i-mode
Kurz genannt sei hier noch „i-mode“. Dieser Dienst wurde 1999 von dem japanischen
Mobilfunkbetreiber NT DoCoMo eingerichtet. Zum 01.04.2008 wurde der Dienst in
Deutschland jedoch wieder eingestellt [www06]. Der Internetzugriff funktionierte ähn-
lich wie WAP. Als Beschreibungssprache wurde cHTML verwendet. Da dies eine Un-
termenge von HTML darstellt, mussten existierende Webseiten nicht überarbeitet wer-
den. Durch die Weiterentwicklung von WAP zu WAP 2.0 sind viele Alleinstellungs-
merkmale von i-mode (z.B. Farbgrafiken) hinfällig geworden. Ein Benutzer musste sich
beim Kauf eines Mobiltelefons auf eines der beiden Protokolle festlegen, da der i-mode-
bzw. WAP-Browser fest in das Software-Paket des Endgeräts integriert war
[Roth2005].
1.2 Arten von Browsern
Es existieren viele verschiedene Browser, die unterschiedlich klassifiziert werden kön-
nen:
1. nach Darstellungsform:
textbasiert (z.B. Lynx) oder grafisch (z.B. Firefox)
2. nach Hersteller:
proprietär (z.B. Internet Explorer) oder Open Source (z.B. Firefox)
3. nach Plattform:
Multiplattform (z.B. Opera), Linux/Unix (z.B. Konqueror), Mac (z.B. Safari)
oder Windows (z.B. Internet Explorer)
4. nach Verwendung:
online (z.B. Internet Explorer ) oder offline (z.B. HTTrack2)
2 Dieser Offlinebrowser speichert eine lokale Kopie der Seiten auf dem Rechner. Folglich ist zum
Surfen kein Internetzugang mehr erforderlich.
1.3 Meilensteile in der Entwicklung der mobilen Browser
9
5. nach Nutzungsumgebung:
PC-Browser (z.B. Opera) oder mobile Browser (z.B. Opera Mini)
Die mobilen Browser können nochmals unterteilt werden und zwar in WAP- und Web-
Browser:
Tabelle 1-1: Unterschiede zwischen WAP- und Web-Browser
WAP-Browser Web-Browser
existiert auf jedem WAP-fähigem Mobiltelefon weiterentwickeltes Betriebssystem oder Java nötig, dann als zusätzliche Software bzw. Ja-vaanwendung installierbar
kann nur WML-Seiten darstellen kann WML- und HTML-Seiten sowie Java-Inhalte darstellen
kann nur Text und einfache Bilder (schwarz/weiß) darstellen kann zusätzlich bunte Grafiken darstellen
Inhalte und Struktur der WAP-Seiten sind extra für das Handy aufbereitet
kann alle „Standardinhalte“ des WWW dar-stellen
Beispiel-URL: - wap.sonyericsson.de - www.wapbibel.de/index.wml
Beispiel-URL: - www.sonyericsson.de - www.wapbibel.de/index.html
Portale der Netzbetreiber sind meist standardmä-ßig als Startseite eingestellt, z.B. Vodafone-live! oder t-zones von T-Mobile
Startseite oft personalisierbar
kann nur durch ein Upgrade des Betriebssystems oder Hardwareaustausch aktualisiert werden kann per Softwareupdate aktualisiert werden
1.3 Meilensteile in der Entwicklung der mobilen Browser
Nachdem die verschiedenen Browserarten vorgestellt wurden, folgen einige Meilenstei-
le in der Entwicklung der mobilen Browser. Die Zeiten, in denen ein Handy nur zum
Telefonieren benutzt wurde, sind längst vorbei. Der erste offizielle Handybrowser na-
mens „HitchHiker“ wurde 1997 von der Firma STNC veröffentlicht. Zwei Jahre später
wurde das Unternehmen von Microsoft aufgekauft und HitchHiker wurde als „Micro-
soft Mobile Explorer 2.0“ auf den Markt gebracht. Dies war der erste Handybrowser,
der sowohl WML- als auch HTML-Seiten darstellen konnte (= Web-Browser). Dieser
1.4 Zahlen und Organisationen
10
Browser wurde von Microsoft weiterentwickelt und 2001 in der Version 3.0 auf den
Markt gebracht (Abbildung 1-5.)
Abbildung 1-5: Microsoft Mobile Explorer 3.0 mit Suchmaske und Ergebnis [www07]
Die mobilen Browser haben sich stetig weiterentwickelt und an die gegenwärtigen In-
ternettechnologien angepasst. Fast alle aktuellen mobilen Browser für Smartphones
stehen den PC-Browsern in nichts mehr nach. Sie unterstützen sowohl HTML, CSS und
AJAX als auch die mobilen Technologien WML und XHTML [www08]. Eine absolute
Neuerung bei der Entwicklung der Handybrowser schaffte die Firma Opera Software
mit ihrem sogenannten Small Screen Rendering. Der Opera Browser ist durch ein vor-
heriges Rendern auf einem Proxyserver in der Lage die Webseite exakt an die Display-
maße des Handys anzupassen (vgl. Abschnitt „3.1.6.2 Opera Mini“). Heute existieren
viele verschiedene mobile Browser und es gibt fast kein Handy mehr auf dem kein
Browser vorinstalliert ist.
1.4 Zahlen und Organisationen
Im Unterschied zum „echten Internet“ erfolgt der Zugang zum mobilen Internet über
verschiedene mobile Endgeräte wie Handys, PDAs oder Blackberrys. Laut einer Studie
des Bundesverbands Informationswirtschaft, Telekommunikation und neue Medien e.V.
(BITKOM) wurde die Zahl der Mobilfunkanschlüsse in Deutschland zum Jahresende
2007 auf über 97 Millionen geschätzt [www09]. Das heißt, es existieren mehr An-
schlüsse als Einwohner in Deutschland und der Verband prognostiziert bis Ende 2008
eine Steigerung auf rund 107 Millionen Mobilfunkanschlüsse.
1.4 Zahlen und Organisationen
11
Nach der Verbreitung von DSL im PC-Bereich setzen sich die schnellen Internetverbin-
dungen auch im Mobilfunk durch. Ende 2007 gab es über 10 Millionen UMTS-
Anschlüsse in Deutschland (Abbildung 1-6). „Mit der zunehmenden Verbreitung von
UMTS-fähigen Handys steigt auch die Nutzung mobiler Datendienste.“ sagt BITKOM-
Präsident Prof. Dr. August-Wilhelm Scheer [www09].
Abbildung 1-6: UMTS-Anschlüsse in Deutschland [www09]
Der Bundesverband BITKOM gibt außerdem an, dass die Netzbetreiber derzeit über elf
Prozent ihres Umsatzes durch das mobile Surfen im Internet und E-Mails erwirtschaf-
ten. Im Verlauf dieses Jahres soll der Anteil noch um drei Prozent auf insgesamt
14 Prozent wachsen.
Das amerikanische Marktforschungsinstitut M:Metrics berichtet unter einem anderen
Fokus (Abbildung 1-7).
Abbildung 1-7: Nutzung des mobilen Internets sowie E-Mail in Deutschland (DE) [www10]
1.4 Zahlen und Organisationen
12
Laut deren Vergleichsstudie vom Februar 2008 nutzen nur 5,9 Prozent der Deutschen
den mobilen Internetzugang um aktuelle Nachrichten zu lesen oder Informationen ein-
zuholen. Das heißt, Deutschland liegt deutlich unter dem europäischen Durchschnitt
von 9,5 Prozent. Ähnlich sieht es bei der Nutzung von E-Mails aus. Lediglich
7,1 Prozent der deutschen Mobiltelefonbesitzer nutzen ihr mobiles Gerät für E-Mails.
Das ist nur etwas mehr als die Hälfte der amerikanischen Nutzer mit 12,2 Prozent.
Das mobile Internet in Deutschland besitzt demnach noch deutliches Wachstumspoten-
tial. Die Förderung der mobilen Internetnutzung in Deutschland und weltweit wird von
verschiedenen Organisationen unterstützt. Diese werden im Folgenden näher beleuchtet.
Das World Wide Web Consortium ist ein internationales Industriekonsortium, welches
sich mit der Entwicklung von Web-Standards und Richtlinien beschäftigt. Im Mai 2005
gründete das W3C die Arbeitsgruppe „Mobile Web Initiative“ mit dem Ziel, den Zu-
gang zum mobilen Internet zu vereinfachen. Der Zugang über mobile Endgeräte zum
Internet sollte genauso einfach wie per PC werden. Um dies zu gewährleisten arbeiten
verschiedene Gruppen der Mobilfunkindustrie vom Mobiltelefonhersteller über Brow-
serentwickler hin zu Netzbetreibern zusammen. Als eines der ersten Ergebnisse dieser
Arbeitsgruppe wurden 2006 die bereits erwähnten „Mobile Web Best Practices 1.0“
veröffentlicht [www11].
Eine weitere Organisation, die sich mit dem mobilen Internet befasst, ist die Open Mo-
bile Alliance (OMA). Diese ging 2002 aus der Zusammenführung der Open Mobile
Architecture Initiative und des WAP-Forums hervor. Heute befinden sich über 300
Dienstleistungs- und Produktanbieter aus dem Mobilfunksektor in der OMA. Deren
oberste Ziele sind die Interoperabilität länderübergreifend zwischen Netzbetreibern und
Endgeräten zu sichern sowie weltweit gültige Standards zu entwickeln. Die offenen
Standards sollen die Entwicklung von mobilen Diensten ermöglichen, welche den An-
forderungen der Nutzer entsprechen, demnach benutzerfreundlich sind. Zwei dieser
Standards sind das Digitale Rechtemanagement sowie die Auszeichnungssprache
XHTML Mobile Profile als Unterform von XHTML [www12].
1.5 Verwendungsmöglichkeiten
13
1.5 Verwendungsmöglichkeiten
In bestimmten Situationen ist die Nutzung des mobilen Internets im klaren Vorteil zum
regulären Zugang per PC oder Laptop. Dies betrifft vor allem die Verwendung auf Rei-
sen. Ein PC wäre zum Beispiel auf einer Zugfahrt sehr unpraktisch. Ein Laptop kann in
dem Fall Abhilfe schaffen. Jedoch kann es vorkommen, dass der Laptop keinen mobilen
Zugang zum Internet (per UMTS-Karte o.ä.) besitzt. In diesem Szenario kann der Zu-
gang per Mobiltelefon gewählt werden, da die Mobilfunknetze fast flächendeckend in
Deutschland vorhanden sind und ein Zugang zum Internet somit nahezu permanent ge-
währleistet ist.
Ein weiterer Einsatz des mobilen Internets findet sich vor allem in den sogenannten
Entwicklungsländern, wie beispielsweise Indien. Dessen Einwohner besitzen oft nicht
die finanziellen, infrastrukturellen oder energietechnischen Ressourcen um einen Lap-
top oder sogar einen PC betreiben zu können. Durch die Nutzung des mobilen Internets
wird der Zugang zum „Netz der Netze“ somit auch für diesen Bevölkerungsteil mög-
lich.
Laut einer Studie der Welthandels- und Entwicklungskonferenz der Vereinten Nationen
(UNCTAD) kommen 58 Prozent der weltweiten Mobiltelefonnutzer aus Entwicklungs-
ländern. In den letzten fünf Jahren hat sich dort die Anzahl der Handyanschlüsse fast
verdreifacht [www13]. Vor allem der Bereich des Mobile Commerce sowie Mobile
Banking wächst beständig. Dies liegt daran, dass viele Einwohner von Entwicklungs-
ländern kein Bankkonto oder eine Kreditkarte besitzen. Das Mobiltelefon wird über die
Telefonrechnung oder die Abrechnung per Prepaid-Karte als Zahlungsmittel eingesetzt.
Neben den bereits genannten Möglichkeiten des Mobile Banking sowie dem Online
Shopping (Mobile Commerce) wird das mobile Internet auch zur Unterhaltung (Mobile
Entertainment) oder zum Lernen (Mobile Learning) benutzt. Die Unternehmen haben
das mobile Internet als Werbeinstrument entdeckt (Mobile Marketing).
Auf Verbraucherseite dient das mobile Internet hauptsächlich zur Informationsbeschaf-
fung. Die gesuchten Informationen sind verschiedenster Natur, von den aktuellen Nach-
richten über das Wetter hin zu Begriffsdefinitionen und Preisrecherche. Ein Student
1.6 Gründe für die zurückhaltende Nutzung des mobilen Internets
14
kann mithilfe seines Handys zum Beispiel während einer Vorlesung einen Begriff nach-
schlagen ohne den Vortrag des Professors unterbrechen zu müssen oder Angst zu haben
sich zu blamieren. Ein anderes Beispiel befasst sich mit der Preisrecherche im mobilen
Internet. Dadurch kann der Verbraucher direkt im Geschäft vergleichen, ob die Konkur-
renz eventuell dasselbe Produkt günstiger anbietet.
Sehr nützlich ist die Verwendung von Servicediensten wie Wegbeschreibung und Navi-
gation mithilfe des mobilen Internets. Somit ist es einem Touristen möglich mit weni-
gen Klicks ein Hotel in der Umgebung zu finden, ein Zimmer zu reservieren und
gleichzeitig ein Restaurant in der Nähe zu suchen ohne einen Stadtplan kaufen zu müs-
sen. Weiterhin kann er für die Theatervorstellung am Abend ein Ticket buchen oder im
Veranstaltungskalender der Stadt erfahren, was außerdem geboten wird.
Durch das mobile Internet kann parallel der Kontakt nach Hause gepflegt werden. Eini-
ge Möglichkeiten dafür sind das Schreiben und Abfragen von E-Mails, Chatten oder
auch die Pflege von sozialen Kontakten über Online-Netzwerke. Eine besondere Teil-
form dieses Mobile Social Computing ist der Austausch innerhalb von Sportgemein-
schaften. Mithilfe des mobilen Internets lassen sich sogar von unterwegs aus, z.B. wäh-
rend des Joggings, noch Trainingspartner finden oder man kann Erfahrungen wie Wet-
ter oder Streckenbehinderungen austauschen.
Die Nutzungsmöglichkeiten des mobilen Internets sind folglich sehr vielseitig und noch
lange nicht ausgeschöpft. Der folgende Abschnitt beschäftigt sich mit den Gründen,
weshalb das mobile Internet zurzeit eher verhalten genutzt wird.
1.6 Gründe für die zurückhaltende Nutzung des mobilen Internets
Nahezu jedes aktuelle Mobiltelefon unterstützt den Zugang zum mobilen Internet. Die
vorgestellten Verwendungsmöglichkeiten sind vielfältig und hilfreich. Trotzdem zeigen
die aktuellen Nutzerzahlen (vgl. Abschnitt „1.4 Zahlen und Organisationen“), dass die
Möglichkeiten des mobilen Internets noch nicht effektiv genutzt werden. In der Litera-
tur sowie im Gespräch mit (potentiellen) Nutzern werden verschiedenste Gründe ge-
nannt, warum das mobile Internet noch keinen Durchbruch erlebt habt.
1.6 Gründe für die zurückhaltende Nutzung des mobilen Internets
15
Die Aussagen lassen sich in drei Hauptgründe einteilen:
1. Technikprobleme
2. zu hohe Kosten
3. mangelnde Usability
Die Probleme mit der Technik kann man in zwei Unterkategorien aufteilen. Zum einen
spielt die ungenügende Sicherheit beim Umgang mit sensiblen Daten, die für Bankge-
schäfte und Mobile Commerce extrem wichtig ist, eine Rolle. Vor allem bei der Nut-
zung von Browsern, die mit einem Proxyserver arbeiten. Dabei werden alle Daten auf
diesem Proxyserver bearbeitet und sind damit nur begrenzt gesichert. Zum anderen sind
es die Internetseiten, die technische Probleme verursachen. Eine Vielzahl an verwende-
ten Technologien wie Flash, AJAX oder Frames kann durch die Handybrowser (noch)
nicht dargestellt werden. Bei den mobilen Browsern für Smartphones sieht das anders
aus. Durch deren Betriebssystem hat der Browser andere technische Möglichkeiten.
Weiterhin ist die Mehrzahl der Webseiten nicht an die Bedingungen von mobilen Gerä-
ten angepasst und eine fehlerhafte Darstellung erzeugt beim Nutzer Irritation und Frust.
Die Kosten für die mobile Internetnutzung sind von Netzbetreiber zu Netzbetreiber un-
terschiedlich und oftmals befindet sich der Kunde in einem Tarifdschungel. Es existie-
ren einige wenige Flatrates, teilweise jedoch mit einschränkenden Rahmenbedingungen.
Beispielsweise gilt die Flatrate nur, wenn die Inhalte über das Portal des Netzbetreibers,
z.B. t-zones von T-Mobile, aufgerufen werden. Wenn der Nutzer andere Webseiten auf-
rufen möchte oder seine E-Mails abfragen will, fallen weitere Kosten an. Da viele Nut-
zer bereits eine Internet-Flatrate über ihren PC oder Laptop besitzen, ist die Ausgabe
von Mehrkosten (außer in mobilen Situationen) nicht nachvollziehbar. Der mobile In-
ternetzugang muss demnach einen Mehrwert für die Nutzer bieten. Eine sinnvolle Nut-
zung des Internets in Verbindung mit dem Mobiltelefon ist beispielsweise das Anrufen
per Klick auf eine Telefonnummer auf einer Webseite um zum Beispiel eine Reservie-
rung im Restaurant vorzunehmen.
Der dritte Grund für die zurückhaltende Nutzung des mobilen Internets ist die mangeln-
de Usability. Diese lässt sich hauptsächlich auf verschiedene Technikaspekte zurück-
1.6 Gründe für die zurückhaltende Nutzung des mobilen Internets
16
führen. Die aktuelle Hardwareausstattung der Handys (keine Smartphones) beinhaltet
ein kleines Display, geringen Arbeitsspeicher und zwölf Tasten zur Eingabe. Die Be-
dienung ist damit deutlich umständlicher als am PC mit QWERTZ-Tastatur, Maus und
großem Monitor. Einige Nutzer bauen daher den Zugang zum mobilen Internet per
Handy auf, surfen dann jedoch mit ihrem Laptop durch das Web.
Dazu kommt, dass Handys (im Gegensatz zu Smartphones) nicht mit verteilten Anwen-
dungen arbeiten können. Auf dem Handydisplay ist jeweils nur eine Applikation oder
eine Webseite sichtbar. Bei mobilen Geräten ist jedoch der schnelle Wechsel von An-
wendungen von Vorteil. In dem Fall könnte das Usability-Problem zum Beispiel durch
eine Darstellung der Webseiten im Handybrowser per Tabs behoben werden. Ein ande-
res Usability-Problem entsteht, wenn man die Vielzahl der angebotenen Funktionen von
Handys betrachtet. Damit erhöht sich die Komplexität für die Nutzer. Einige Nutzer
möchten daher überhaupt keinen mobilen Internetzugang, sondern einfach nur telefonie-
ren können.
Ob die aktuellen Handybrowser nutzerfreundlich sind oder ob die fehlende Usability
dazu beiträgt, dass das mobile Internet noch nicht im vollen Umfang genutzt wird, soll
mit dieser Diplomarbeit überprüft werden. Dazu werden im folgenden Kapitel einige
Grundlagen zur Nutzerfreundlichkeit sowie zu den speziellen Usabilityanforderungen
an mobile Anwendungen vorgestellt.
2 Usability
17
2 Usability
„It is not the utility but the usability of a thing that is in question.”
Thomas de Quincey [www14]
Der Begriff „Usability“ wird im deutschen Sprachraum meist mit „Gebrauchstauglich-
keit“ oder „Benutzerfreundlichkeit“ übersetzt. Er bezeichnet die vom Nutzer erlebte
Nutzungsqualität bei der Interaktion mit einem System. Eng verwandt mit dem Usabili-
ty-Engineering ist die Softwareergonomie, welche die Angepasstheit eines Computer-
programms an die menschlichen Bedürfnisse beschreibt.
Ein Produkt kann man als benutzerfreundlich bezeichnen, wenn es die folgenden drei
Merkmale erfüllt:
• Effektivität = Ist das vollständige und genaue Erreichen der Ziele möglich?
• Effizienz = Ist das Erreichen für den Nutzer aufwändig?
• Zufriedenheit = Ist der Benutzer mit dem Angebot zufrieden?
Diese Definition findet man in erweiterter Form in der Normenreihe DIN EN ISO 9241.
In Teil 11 dieser Norm wird die Gebrauchstauglichkeit wie folgt definiert: „Das Aus-
maß in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskon-
text genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend
zu erreichen“ [DIN1999].
Dumas & Redish betonen, dass bei der Usability der Benutzer im Mittelpunkt steht. Die
Nutzer verwenden ein Produkt, um produktiv zu sein sowie Aufgaben zu erledigen,
nicht zum Selbstzweck des Produkts. Im Endeffekt entscheiden deshalb die Anwender
darüber, ob ein Produkt einfach zu benutzen ist („ease of use“). Benutzerfreundliche
Produkte können also nur entwickelt werden, wenn man die Benutzer kennt, versteht
und gemeinsam mit ihnen arbeitet [Dumas1999].
Usability besitzt auch einen wirtschaftlichen Nutzen. Produktdesign, welches per Usabi-
lity-Evaluation entwickelt wurde, vermeidet Kundenanrufe beim Support und erhöht die
Nutzerzufriedenheit insgesamt. Die zufriedenen Benutzer werden letztendlich zu treuen
2.1 Begriffe
18
Kunden und bei der Vielzahl an angebotenen Produkten auf dem Markt kann die Benut-
zerfreundlichkeit ein entscheidender Faktor bei der Auswahl eines Produkts sein
[Weiss2002].
2.1 Begriffe
2.1.1 Usability-Evaluation
Der allgemeine Begriff „Evaluation“ beschreibt eine systematische Untersuchung und
Bewertung über die Qualität oder den Nutzen eines Gegenstands. Der folgende Ab-
schnitt beschäftigt sich mit dem Teilgebiet der Usability-Evaluation, auch allgemein als
Usabilitytest bezeichnet. Usability-Evaluationen stellen nur einen Teil des Prozesses des
Usability-Engineering dar.
Oftmals werden Usabilitytests erst am Ende einer Produktentwicklung durchgeführt.
Ziel dabei ist, dass die Nutzer eventuelle Designfehler und Usability-Probleme aufde-
cken. Diese Methodik hat sich bewährt, wenn man beispielsweise mehrere Produkte
oder Versionen miteinander vergleichen möchte. Bei der Entwicklung eines neuen Pro-
dukts oder wenn ein Hersteller großen Wert auf Benutzerfreundlichkeit legt, sollten
Usabilitytests iterativ durchgeführt werden. Das heißt, man entwickelt einen Prototyp,
lässt diesen von Nutzern testen und verarbeitet die Testergebnisse in das weitere Pro-
duktdesign. Anschließend testet man nach einigen Weiterentwicklungen nochmals. Da-
bei ist es nicht relevant, ob der Test als „Discount-Test“ gestaltet wird (vgl. Abschnitt
„2.2.4 Discount Usability Engineering“) oder ob der Test mit viel Aufwand unter Real-
bedingungen durchgeführt wird. Um eine hohe Usability zu erreichen ist es vor allem
wichtig bereits in einem frühen Entwicklungsstadium zu testen und dies mehrmals zu
wiederholen. Zusammenfassend sind hier die Worte von Steve Krug wiedergegeben:
„Testing one user early in the project is better than testing 50 near the end.”
[Krug2000].
Laut Schweibenz & Thissen [Schweibenz2003] ist eine Usability-Evaluation durch drei
Kennzeichen definiert:
1. Ziel und Zweck: etwas zu überprüfen, zu verbessern oder über etwas zu ent-
scheiden
2.1 Begriffe
19
2. Bewertung von Handlungsalternativen sowie Instrument zur Planungs- und Ent-
scheidungshilfe
3. Verwendung von aktuellen Techniken und Forschungsmethoden
Usabilitytests können während des gesamten Produktlebenszyklus durchgeführt werden.
Je nach Zeitpunkt kann man zwei verschiedene Evaluationsformen unterscheiden:
a. Die formative Evaluation findet während der Entwicklung des Produkts statt und
ist damit Teil eines iterativen Designprozesses, da die Ergebnisse direkt in die
Weiterentwicklung einfließen. Als Testmethode im Bereich der Usability-
Evaluation werden vor allem Nutzertests (Abschnitt „2.2.1 Nutzertest“) und Ex-
perteninspektionen (Abschnitt „2.2.2 Expertentest“) verwendet.
b. Die summative Evaluation hingegen erfolgt erst nach Fertigstellung der Ent-
wicklung, d.h. als abschließende Bewertung. Mit dieser Methode ist es möglich
mehrere Produkte oder Anwendungen direkt zu vergleichen. Als Testmethode
bei Usability-Evaluationen werden vorrangig quantitative Verfahren, wie zum
Beispiel Fragebögen, verwendet.
Mithilfe einer Usability-Evaluation ist es möglich bereits in einem frühen Stadium der
Entwicklung den Markterfolg eines Produkts vorherzusagen. Dies kann dabei helfen
(unnötige) Entwicklungskosten zu sparen. Zur näheren Erklärung dient ein Beispiel der
Firma Nokia. Der Handyhersteller wollte im Jahr 1999 ein Handy mit einem neuartigen
Bedienkonzept, einer einzeiligen Tastatur anstatt 3 x 4 Tasten, auf den Markt bringen.
Doch schon im zweiten Usabilitytest stellte sich heraus, dass die Nutzer mit der neuen
Tastatur schlechter zurechtkamen als mit dem bisherigen Bedienkonzept. Dieses Feed-
back war für Nokia von unschätzbarem Wert, denn daraufhin wurde die Weiterentwick-
lung des einzeiligen Bedienkonzepts gestoppt und die gesparten Entwicklungskosten
konnten in andere Projekte fließen [Silfverberg2003].
Oft werden Usabilitytests nicht durchgeführt, weil das Management eines Unterneh-
mens annimmt, dass diese zu teuer und zu aufwändig sind. Zugegebenermaßen funktio-
niert eine Usability-Evaluation nicht ohne ein Mindestmaß an Aufwand, Zeit und finan-
ziellen Mitteln. Andererseits können dadurch Kosten an anderer Stelle, z.B. beim Sup-
2.1 Begriffe
20
port, eingespart werden. Weiterhin existieren verschiedene Möglichkeiten, um die Kos-
ten für eine Usability-Evaluation auf ein Minimum zu beschränken. Man kann zum Bei-
spiel die Anzahl der Teilnehmer in einem Nutzertest begrenzen.
2.1.2 Usability-Problem
Es existiert keine allgemein anerkannte Definition, was ein Usability-Problem darstellt
oder ausmacht. In der Praxis wird anhand verschiedener Kriterien von Experten beur-
teilt, was ein Problem ist und was nicht.
In Abhängigkeit von der Anzahl der Testnutzer in einer Usability-Evaluation können
unterschiedlich viele Usability-Probleme entdeckt werden. Wenn man mit zu wenigen
Testern arbeitet, können eventuell Usability-Probleme übersehen werden. Wenn man im
Gegensatz dazu zu viele Tester befragt, kann es im seltenen Fall passieren, dass man
große Usability-Probleme aus den Augen verliert, da man von kleineren Ergebnissen
überhäuft wird.
Auch Jakob Nielsen [www15] unterscheidet zwischen schweren (großen) und weniger
schweren (kleinen) Usability-Problemen. Die Ernsthaftigkeit eines Problems ergibt sich
aus den drei Faktoren:
• Häufigkeit: Tritt das Problem häufig oder selten auf?
• Einfluss auf den Benutzer: Kann der Benutzer das Problem einfach oder nur mit
Anstrengung bewältigen?
• Hartnäckigkeit des Problems: Ist es ein einmaliges Problem, welches der Nutzer
nach dem ersten Auftreten einfach überwinden kann oder wird der Nutzer wie-
derholt mit dem Problem konfrontiert?
Anhand dieser Faktoren kann man aufgetretene Usability-Probleme je nach Schwere-
grad in fünf Stufen nach einer Skala von Nielsen [www15] einteilen. In Anlehnung an
Nielsens Severity Rating klassifizieren Schweibenz & Thissen [Schweibenz2003] Usa-
bility-Probleme wie folgt und geben Empfehlungen zum weiteren Vorgehen:
2.2 Arten von Usabilitytests
21
Tabelle 2-1: Stufen der Ernsthaftigkeit von Usability-Problemen [nach Schweibenz2003]
Prioritätsstufe Beschreibung des Problems
0 Dieses Problem stellt aus meiner Sicht kein Problem für die Benutzerfreundlichkeit dar.
1 Dieses Problem ist lediglich kosmetisch. Es muss nicht unbedingt behoben werden, außer wenn genügend Zeit dazu bleibt.
2 Dieses Problem ist nicht schwerwiegend. Es sollte behoben werden, hat aber eine niedere Priorität, was die Beseitigung betrifft.
3 Dieses Problem ist schwerwiegend. Es sollte dringend behoben werden und hat eine hohe Priorität, was die Beseitigung betrifft.
4 Dieses Problem ist katastrophal. Es muss unbedingt behoben werden, bevor die An-wendung öffentlich verfügbar ist. Es hat deshalb höchste Priorität, was die Beseiti-gung betrifft.
Scott Weiss erklärt, dass die Schwere von Usability-Problemen auch mit der Anzahl der
Usabilitytests während der Produktentwicklung korreliert [Weiss2002]. Das heißt, am
Anfang werden die schwerwiegenden Probleme entdeckt und im Idealfall durch den
Entwickler behoben. Dies hat zur Folge, dass bei einer späteren Evaluation nur noch
kleinere Probleme gefunden werden.
2.2 Arten von Usabilitytests
Es gibt viele verschiedene Arten und Methoden um die Benutzerfreundlichkeit zu tes-
ten:
• qualitativ oder quantitativ (Fragebogen, Log file Analyse)
• Expertentest (Inspektion, Cognitive Walkthrough) oder Nutzertest (Card Sort-
ing, Think Aloud)
• Prototyping (Paper Prototyping) oder abschließende Bewertung der funktionsfä-
higen Software
Im Folgenden werden einige allgemeine Aussagen zu Nutzer- und Expertentests vorge-
stellt. Zusätzlich wird jeweils eine der wichtigsten Methoden näher erläutert, da diese
im weiteren Verlauf dieser Diplomarbeit praktisch angewendet werden.
2.2 Arten von Usabilitytests
22
2.2.1 Nutzertest
Die verschiedenen Methoden des Nutzertests werden in der Literatur oft mit dem all-
gemeinen Begriff des „Usability Testing“ bezeichnet. Dabei beschreiben benutzerorien-
tierte Methoden viel mehr. Sie kennzeichnen, dass der Nutzer mit seinem Feedback im
Vordergrund des Tests steht.
Aufgrund der direkten Einbindung von Nutzern in den Test entstehen verschiedene Vor-
und Nachteile. Durch die Arbeit mit echten Nutzern an realen Aufgaben können viele
(größere) Usability-Probleme entdeckt werden. Das heißt, die spätere Zielgruppe wird
direkt in die Produktentwicklung einbezogen. Dadurch bestimmt nicht der Designer das
Produkt, sondern das Produkt wird für die Nutzer und deren Anforderungen gestaltet.
Dieser Vorteil verlangt jedoch, dass die Auswahl der Testpersonen sowie die Gestaltung
der Testaufgaben besonders sorgfältig erledigt wird [Schweibenz2003]. Die Teilnehmer
sollten so repräsentativ wie möglich sein, damit die reale Welt bestmöglich nachemp-
funden werden kann. Am Beispiel des Erfahrungsstands der Tester kann man das gut
verdeutlichen. Wenn die Testteilnehmer weniger Erfahrungen in einem bestimmten
Bereich als die späteren Benutzer haben, können Usability-Probleme sichtbar werden,
welche bei erfahrenen Nutzern nicht auftreten. Die Probleme werden behoben, verbes-
sern jedoch die Usability für die eigentliche Zielgruppe nicht. Im umgekehrten Fall,
wenn man Testteilnehmer mit mehr Erfahrung als die zukünftigen Nutzer einsetzt, kann
es passieren, dass Probleme nicht auftreten, weil sie übersehen werden [Dumas1999].
Daher ist es wichtig, auf eine repräsentative Auswahl der Tester aus der Produktziel-
gruppe zu achten. Aus dieser Anforderung heraus gestaltet sich die Rekrutierung der
Testnutzer oft als sehr aufwändig. Daraus entstehen die Nachteile der hohen Komplexi-
tät sowie des hohen zeitlichen und finanziellen Aufwands eines Nutzertests [Schwei-
benz2003].
Der Nutzertest gehört zu den qualitativen Testmethoden, da meist schon eine geringe
Anzahl an Testern für ein aussagekräftiges Ergebnis ausreicht. Scott Weiss empfiehlt
eine Anzahl von sechs Testpersonen [Weiss2002]. Jakob Nielsen beschreibt, dass ab-
hängig von der Komplexität des Testgegenstandes bei einer abschließenden Evaluation
2.2 Arten von Usabilitytests
23
bereits fünf Nutzer 85 Prozent der Usability-Probleme aufdecken (Abbildung 2-1)
[www16].
Abbildung 2-1: Gefundene Bedienprobleme in Abhängigkeit von der Anzahl der Tester [www16]
Insgesamt ist sich die Literatur uneinig, wie viele Tester idealerweise benötigt werden.
Daher besteht noch Forschungsbedarf auf dem Gebiet der optimalen Testeranzahl. Zu-
sätzlich ist die Einhaltung der Repräsentativität aufgrund der verschiedenen (selbst ge-
wählten) Anforderungen an die Testpersonen nicht immer einfach zu bewältigen. Oft
gestaltet es sich schwierig überhaupt geeignete Testpersonen zu rekrutieren, sodass man
häufig die Testeranzahl auf eine Menge beschränkt, die gerade noch wissenschaftlich
vertretbar ist [Schweibenz2003].
Nutzerorientierte Methoden werden oft als die wichtigsten Usability-Verfahren be-
zeichnet, da letztendlich der Nutzer über die Usability und damit die Akzeptanz eines
Produkts entscheidet. Die verwendeten Methoden sind vielfältig. Man kann den klassi-
schen Produkttest mit der Methode des lauten Denkens (Think Aloud) verwenden. Oder
der Testleiter befragt die Testnutzer anhand von direkten Fragen zum Produkt (Frage-
bögen). Weiterhin existiert die Methode des Card Sorting. Dabei werden verschiedene
Funktionen des Produkts auf Karteikarten übertragen und die Nutzer gruppieren diese
nach unterschiedlichen Kategorien, z.B. Wichtigkeit oder logische Reihenfolge. Eine
interessante Methode des Nutzertests ist das sogenannte Eyetracking. Hierbei werden
die Augenbewegungen der Nutzer analysiert, um beispielsweise herauszufinden wel-
chen Teil eines Produkts die Nutzer genauer bzw. häufiger betrachten. Oft werden auch
2.2 Arten von Usabilitytests
24
mehrere Methoden kombiniert, indem die Nutzer während des Produkttests erst beo-
bachtet und anschließend gebeten werden das Produkt zu bewerten. Jakob Nielsen
[Nielsen1993] empfiehlt die Methode des lauten Denkens als die wertvollste Technik
eines Nutzertests.
Bei einem Think Aloud-Test kann der Testleiter die Vorgehensweise des Nutzers direkt
nachvollziehen. Dies wird dadurch möglich, dass der Tester laut äußert, was er denkt
und sieht. Er teilt mit, was er zu tun beabsichtigt und der Beobachter kann darauf ach-
ten, wie der Tester tatsächlich handelt. Damit erhält man Einblicke über:
a. Wohin schaut der Nutzer?
b. Was will er als nächsten Schritt tun?
c. Verhält sich das Produkt wie erwartet?
Durch die Artikulation der Gedanken und Handlungen des Nutzers können die indivi-
duelle Interaktion und eventuelle Probleme des Nutzers mit dem Produkt beobachtet
werden.
Der Produkttest mit Think Aloud wird gewöhnlich in einem Usability-Labor durchge-
führt. Usabilitytests können jedoch auch als Feldstudie angelegt werden, z.B. der Test
eines Handys während dem Laufen in einer Fußgängerzone. In einem Labor wird der
Testnutzer meist von einem oder mehreren Beobachtern (oft hinter halbdurchlässigen
Spiegeln) betrachtet. Gleichzeitig wird der Test per Videokamera für eine genaue Aus-
wertung aufgezeichnet.
Für die meisten Testpersonen fühlt sich die Methode des lauten Denkens unnatürlich an.
Denn der Testleiter und der Beobachter dürfen während des Tests nicht reden. Demnach
entsteht der Eindruck eines „Selbstgesprächs“ beim Tester. Das laute Denken kann man
jedoch an einer Beispielaufgabe üben und dem Testnutzer anschließend Feedback ge-
ben. Trotzdem haben einige Personen Probleme das laute Denken konsequent anzuwen-
den. Daher kann der Testleiter durch Nachfragen unterstützen, wie z.B. „Was denken
Sie gerade?“ oder „Was möchten Sie gerade tun?“. Zusätzlich kann der Testleiter wäh-
2.2 Arten von Usabilitytests
25
rend des Tests indirektes Feedback durch das Murmeln von „hmhm“ geben, aber direkte
Antworten sollte er vermeiden [Schweibenz2003].
In einem Usabilitytest können aufgrund der Zeit sowie der Kosten nicht alle Funktionen
eines Produkts getestet werden, sodass die Aufgabengestaltung wohlüberlegt sein muss.
Im Normalfall werden die wichtigsten Funktionen zu Aufgaben zusammengefasst. Der
Nutzer erhält folglich vordefinierte Aufgaben, die er mit dem Produkt ausführen soll.
Bei der Gestaltung der Aufgaben müssen laut Schweibenz & Thissen [Schwei-
benz2003] verschiedene Aspekte berücksichtigt werden:
• Die Aufgaben sollten so realistisch wie möglich sein, d.h. nicht zu trivial, aber
auch nicht zu anspruchsvoll (vgl. [Nielsen1993]).
• Gleichzeitig muss man die eingeschränkte Umgebung des Testlabors beachten
und damit die zur Verfügung stehende Zeit.
• Außerdem sollten alle wesentlichen Teile des Produkts durch den Test abge-
deckt werden.
Bereits diese Anforderungen machen die Aufgabengestaltung sehr aufwändig. Dazu
kommt, dass die Aufgaben klar und präzise formuliert werden müssen, damit keine
Verständnisprobleme auftauchen. Zusätzlich sollten die Aufgaben für die Darstellung
einer realen Situation in einer logischen Reihenfolge angeordnet sein.
Um den Nutzern einen angenehmen Einstieg in den Test zu ermöglichen, kann ein psy-
chologischer Trick angewandt werden. Dabei wird die erste Aufgabe bewusst sehr ein-
fach gehalten und der Tester durch die erfolgreiche Bewältigung zur weiteren Durch-
führung motiviert. Ähnlich gestaltet es sich mit der letzten Testaufgabe. Durch eine
einfache Schlussaufgabe erhält der Nutzer ein Erfolgserlebnis und beendet den Test mit
dem Gefühl, etwas erreicht zu haben [Nielsen1993].
Nicht nur die Aufgabengestaltung, sondern auch den restlichen Nutzertest sollte man
genau planen, da er aufgrund des hohen Aufwands nicht einfach wiederholt werden
kann. Den Testablauf teilt Nielsen [Nielsen1993] in vier verschiedene Phasen ein:
1. Vorbereitung
2. Einführung
2.2 Arten von Usabilitytests
26
3. Durchführung
4. Nachbereitung
Während der Vorbereitung wird das gesamte Testsetup inklusive Aufgaben, Unterlagen
für Testleiter, Fragebögen und technischem Equipment zusammengestellt. Zum Schluss
der Vorbereitungsphase sollte das gesamte Testsetup in einem Pilottest überprüft wer-
den. Dessen Testnutzer muss nicht zur Zielgruppe gehören. Ziel des Pilottests ist die
Überprüfung von mehreren Aspekten. Zum einen sollen die Aufgaben auf mögliche
Verständnisprobleme untersucht werden. Zum anderen kann durch den Pilottest das
Funktionieren der technischen Ausstattung sichergestellt werden und schließlich kann
durch die Durchführung eines vollständigen Tests eine Einschätzung zur Zeitdauer des-
selben getroffen werden.
Für die drei Phasen nach der Vorbereitung hat der Usability-Experte Jakob Nielsen ei-
nige ethische Richtlinien für den Testleiter verfasst, die wie folgt lauten [Nielsen1993]:
Einführung
• Hab alle Vorbereitungen abgeschlossen, bevor der Nutzer eintrifft.
• Betone, dass das System getestet wird, nicht der Nutzer.
• Erkläre, dass der Nutzer jederzeit aufhören kann.
• Erkläre, dass der Test auf Video aufgenommen wird.
• (Erfrage, ob Zitate genutzt werden dürfen.)3
• Erkläre, dass die Ergebnisse anonymisiert werden.
• Vermeide Störungen: Schließe die Tür und hänge ein „Nicht Stören“-Schild dar-
an.
• (Erkläre die Think Aloud-Methode.)
• Beantworte alle Fragen des Nutzers, bevor du fortfährst.
Durchführung
• Ermögliche dem Nutzer ein anfängliches Erfolgserlebnis.
3 Angaben in Klammern beschreiben eigene Ergänzungen bei Nutzung der Think Aloud-Methode
2.2 Arten von Usabilitytests
27
• Zeige immer nur die aktuelle Aufgabe.
• Bewahre eine angenehme Atmosphäre (Getränke anbieten, Tisch sauber halten).
• Deute nie an, dass der Nutzer Fehler in irgendeiner Art macht oder zu langsam
ist.
• Halte die Anzahl der Beobachter gering.
• Falls der Testnutzer gleichzeitig ein Angestellter des Unternehmens ist: Vermei-
de es, dass ein Vorgesetzter als Beobachter fungiert.
• Falls nötig, lass den Testleiter den Test anhalten, wenn die Situation unange-
nehm für den Nutzer wird.
• (Erinnere an die Think Aloud-Methode.)
Nachbereitung
• Danke dem Benutzer, dass er dir dabei geholfen hat, das Produkt zu verbessern.
• Berichte über die Ergebnisse nur in anonymisierter Form.
• Zeige die Videoaufnahmen außerhalb der Testgruppe nur mit dem Einverständ-
nis des Testnutzers.
Mit der Befolgung dieser ethischen Richtlinien ergibt sich gleichzeitig der grobe Ablauf
eines Nutzertests. Die Einführung dient dazu dem Nutzer den Zweck und das Ziel des
Tests kurz zu erläutern. Anschließend wird der weitere Verlauf erklärt und der Nutzer
sollte, wie bereits erwähnt, die Methode des lauten Denkens an einer Beispielaufgabe
üben. Wenn der Tester anschließend keine Fragen mehr hat, kann der eigentliche Test
beginnen. Damit der Testleiter keinen der genannten Punkte vergisst, kann ein Begleit-
skript als eine Art Checkliste erstellt werden. Diese führt den Testleiter auch durch den
weiteren Verlauf.
Nachdem der Nutzer die Testaufgaben erhalten hat, beginnt die eigentliche Durchfüh-
rung. Der Nutzer löst die ihm gestellten Aufgaben mit dem Produkt. Gleichzeitig äußert
er seine Gedanken mit der Think Aloud-Methode und wird dabei beobachtet. Das Be-
gleitskript kann den Testleiter beispielsweise daran erinnern, dass er nicht direkt mit
dem Nutzer kommuniziert. Nachfragen um den Nutzer zum lauten Denken zu animieren
sind natürlich erlaubt.
2.2 Arten von Usabilitytests
28
Nach der erfolgreichen Durchführung wird der Tester gebeten, dass Produkt in Form
eines Fragebogens zu bewerten. Dabei sollte ihm auch die Möglichkeit gegeben werden
eigene Verbesserungsvorschläge zu äußern. Diese Hinweise müssen nicht zwangsweise
in der Weiterentwicklung des Produkts umgesetzt werden, können jedoch als wertvolle
Anregung dienen [Nielsen1993]. In der Nachbereitungsphase kann der Testleiter dem
Nutzer Fragen stellen, falls z.B. während des Tests Äußerungen des Nutzers unklar wa-
ren. Abschließend dankt der Testleiter dem Nutzer und der Testnutzer erhält seine ver-
einbarte Aufwandsentschädigung. Für den Testleiter endet die Nachbereitung damit,
dass er das gesammelte Material wie Fragebögen, Videoaufnahmen und Notizen sorg-
fältig unter einer Teilnehmernummer archiviert. Zum Schluss wird das Testsetup in den
Ausgangszustand zurückgesetzt, damit der nächste Durchlauf starten kann.
Die abschließende Auswertung des Nutzertests erfolgt auf Grundlage aller Datenquel-
len. Das heißt die Kommentare des Testers, die Notizen des Testleiters, die Lösung der
Testaufgaben, Fragebögen und natürlich die Videoaufnahmen werden betrachtet. Je
nach Ziel des Produkttests kann die Auswertung statistisch (Zeit für Aufgabenlösung,
Klicks, etc.) und somit performanceorientiert durchgeführt werden. Oder der Fokus der
Auswertung liegt auf den subjektiven Ergebnissen wie der Zufriedenheit des Nutzers
[Schweibenz2003]. Diese kann man beispielsweise über Kommentare per lautem Den-
ken sowie Mimik und der Bewertung per Fragebogen feststellen.
Bei der Auswertung ist es wichtig darauf zu achten, dass man den beobachteten Ergeb-
nissen mehr Vertrauen schenkt als den Aussagen oder Bewertungen der Nutzer. Jakob
Nielsen unterstützt diese These durch seinen Kolumnenartikel „First Rule of Usability?
Don't Listen to Users“ [www17]. Dort beschreibt er, dass die Aussagen von Nutzern oft
unzuverlässig sind und nennt dafür die folgenden drei Gründe:
a. Beim Beantworten von Fragen orientieren sich die Nutzer daran, was man von
ihnen hören will bzw. was sozial akzeptiert ist.
b. Beim Berichten geben die Nutzer an, an was sie sich erinnern. Sie erzählen, was
sie meinen getan zu haben. Dadurch können wichtige Details verloren gehen.
2.2 Arten von Usabilitytests
29
c. Die Tester versuchen ihr Verhalten zu rationalisieren und damit im Nachhinein
zu erklären. Ob die Beweggründe jedoch der Wahrheit entsprechen, kann nicht
mehr verifiziert werden.
Daher sollten die Aussagen der Testteilnehmer kritisch betrachtet werden. Trotzdem
sollte ihnen auf jeden Fall die Möglichkeit zur Bewertung gegeben werden, damit sie
ihre Erfahrungen und Kommentare mitteilen können. Diese Informationen sollten je-
doch nur als Ergänzung zur direkten Beobachtung in die Auswertung einfließen
[Schweibenz2003].
Zum Abschluss eines Nutzertests verfasst der Testleiter einen Testbericht. Dieser bein-
haltet das Ziel des Nutzertests, die Beschreibung der Methodik, des Testsetups und die
Ergebnisse sowie Empfehlungen für die Weiterentwicklung.
Bei einem Nutzertest wird immer mit realen Nutzern der Zielgruppe gearbeitet. Dies
stellt auch den größten Unterschied zum Expertentest dar. Dort sind keine Nutzer invol-
viert, sondern die Evaluation wird komplett durch Experten durchgeführt. Eine nähere
Darstellung des Ablaufs sowie der Vor- und Nachteile eines Expertentests befindet sich
im nächsten Abschnitt.
2.2.2 Expertentest
Alle expertenorientierten Methoden werden, wie der Name schon sagt, von Experten
durchgeführt. Die Gutachter untersuchen dabei die Benutzerschnittstelle auf Gebrauchs-
tauglichkeit. Daher werden Expertentests in der englischsprachigen Literatur oft als
„inspection“ bezeichnet.
Das Ergebnis eines Expertentests basiert auf dem Urteil des gesamten Expertenteams.
Daher hängt der Erfolg des Ergebnisses von der Erfahrung und der Anzahl der Gutach-
ter ab. Je nach Expertise kann man die Experten in vier verschiedene Gruppen einteilen:
• Nicht-Experten besitzen keine Erfahrung im Bereich der Usability. Sie stammen
jedoch aus der Zielgruppe der Anwendung und besitzen damit die nötige Fach-
kenntnis zur Beurteilung (z.B. Mobilfunk).
2.2 Arten von Usabilitytests
30
• System-Experten sind Entwickler oder Designer, die Erfahrungen im Gebiet der
Produktgestaltung aufweisen (z.B. Softwareentwickler).
• Usability-Experten sind auf den Bereich Usability spezialisiert und besitzen viel
Erfahrung im Bereich der Usability-Evaluation.
• Doppel-Experten sind Usability-Experten mit bereichsspezifischen Fachkennt-
nissen (z.B. Online-Marketing).
Doppelexperten erscheinen auf den ersten Blick für jede Evaluation am besten geeignet.
Jedoch existieren in der realen Welt nur wenige Doppelexperten. Daher wird in der Pra-
xis oft auf eine Mischung aus verschiedenen Experten zurückgegriffen. Dies führt zum
Thema der Größe eines Expertenteams. Die Anzahl der benötigten Gutachter hängt vom
dem Ziel des Expertentests ab [www18]:
• Wenn eine Potenzialabschätzung durchgeführt werden soll, reicht ein Experte.
• Sollen grobe Mängel aufgedeckt werden, genügen ein bis drei Experten.
• Für eine detaillierte Analyse sollten drei bis fünf Experten eingesetzt werden.
Diese Aussage unterstützt auch Jakob Nielsen. Über sechs Untersuchungen hinweg fand
er heraus, dass ein einziger Gutachter nur 35 Prozent der Usability-Probleme erkennt
(Abbildung 2-2). Durch den Einsatz verschiedener Experten werden verschiedene Prob-
leme aufgedeckt. Daher sollten mindestens drei, am besten jedoch fünf, Gutachter für
ein aussagekräftiges Ergebnis eingesetzt werden [Nielsen1993].
Abbildung 2-2: Abhängigkeit der gefunden Usability-Probleme von der Anzahl der Gutachter [www19]
2.2 Arten von Usabilitytests
31
Die Experten überprüfen die Benutzerschnittstelle auf bestimmte Richtlinien. Jeder
Gutachter besitzt einen anderen Hintergrund und die überprüften Richtlinien werden
damit immer subjektiv interpretiert. Dies führt abermals zu dem Schluss, dass der Ein-
satz mehrerer Experten sinnvoll ist. Nachdem jeder Experte seine Evaluation durchge-
führt hat, können sich die Gutachter beraten, ihre Ergebnisse diskutieren sowie Empfeh-
lungen daraus ableiten.
Experteninspektionen haben den Vorteil, dass sie relativ schnell, kostengünstig und
ohne großen Aufwand durchführbar sind. Es werden keine speziellen Testräume, Aus-
stattungen oder Testpersonen, die aufwändig rekrutiert werden müssen, benötigt. Der
Nachteil dieser Methode ist, dass keine echten Nutzer involviert sind und daher einige
Usability-Probleme eventuell nicht auftreten. Ein weiterer Nachteil ist, dass die Ergeb-
nisse subjektiver Natur sind, da diese immer von der persönlichen Meinung der Gutach-
ter abhängig sind [Schweibenz2003].
Es gibt verschiedene Arten von Expertentests. Zum Beispiel überprüfen die Gutachter
die Benutzerschnittstelle auf die Übereinstimmung mit anerkannten Usability-Normen
oder Gestaltungsrichtlinien (Heuristische Evaluation). Die Experten können auch auf-
gabenweise einzelne Funktionen eines Produkts betrachten, z.B. Ablauf einer Onlinebe-
stellung. Diese Methode nennt man Cognitive Walkthrough. Weiterhin existiert die ex-
pertenorientierte Methode der Checkliste. Dabei wird die Benutzerschnittstelle ähnlich
zur Heuristischen Evaluation unter verschiedenen Kriterien betrachtet. Während die
Heuristiken jedoch eher abstrakt gestaltet sind und viel Spielraum zur Interpretation
erlauben, werden Checklisten eher individuell auf die Inspektion angepasst und sind
daher praxisbezogener. Die am häufigsten verwendete Expertenmethode ist die Heuris-
tische Evaluation, die nachfolgend näher beschrieben wird.
Bei der Heuristischen Evaluation überprüft der Experte eine Benutzerschnittstelle auf
die Übereinstimmung mit anerkannten Designrichtlinien, den Heuristiken. Nielsen defi-
niert die Heuristiken als generelle Regeln, welche die Eigenschaften einer benutzer-
freundlichen Nutzerschnittstelle beschreiben [Nielsen1993]. Bei der Form der Richtli-
2.2 Arten von Usabilitytests
32
nien gibt es keine Vorschrift. Sie können sehr detailliert und damit umfangreich sein
sowie von unterschiedlicher Qualität.
Eine der bekanntesten Heuristiken stammt vom Usability-Experten Jakob Nielsen, wel-
che er zusammen mit seinem Kollegen Rolf Molich im Jahr 1990 entwickelt und später
erweitert hat. Diese zehn Heuristiken lauten [www20]:
1. Sichtbarkeit des Systemstatus
2. Übereinstimmung zwischen System und Wirklichkeit
3. Benutzerkontrolle und -freiheit
4. Konsistenz und Standards
5. Fehlervermeidung
6. Wiedererkennen statt Erinnern
7. Flexibilität und Effizienz der Benutzung
8. Ästhetik und minimalistisches Design
9. Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern
10. Hilfe und Dokumentation
Diese Heuristiken kann man allgemein für jede Evaluation verwenden. Ferner existieren
noch bereichsspezifische Richtlinien, z.B. für das Design von Handyanwendungen von
Jun Gong & Peter Tarasewich oder Scott Weiss (vgl. Abschnitt „2.3.1 Interface Guide-
lines für mobile Endgeräte“).
Nachdem die Richtlinien für die Heuristische Evaluation ausgewählt und die Experten
rekrutiert worden sind, betrachtet jeder Gutachter die Anwendung für sich allein. Da-
durch wird eine gegenseitige Beeinflussung vermieden. Die Anwendung wird im Nor-
malfall mehrmals durchlaufen. Bei jedem Durchlauf liegt der Fokus auf einem anderen
Aspekt der Heuristik, z.B. Konsistenz oder Fehlervermeidung. Falls die realen Nutzer
Hilfe in Form eines Handbuchs oder einer Onlinehilfe nutzen können, sollten diese Hil-
festellungen auch von dem Experten untersucht werden. Die Ergebnisse der Evaluation
können vom Experten schriftlich festgehalten werden, aber es ist ebenfalls möglich,
dass ein Beobachter anwesend ist und der Experte ihm seine Ergebnisse verbal mitteilt.
Anschließend treffen sich die verschiedenen Gutachter und tauschen ihre Ergebnisse
2.2 Arten von Usabilitytests
33
untereinander aus. Das Gesamtergebnis beinhaltet eine Liste aller gefundenen Abwei-
chungen von den Heuristiken mit passenden Lösungsvorschlägen.
Eine Heuristische Evaluation kann während des gesamten Entwicklungsprozesses
durchgeführt werden. Sie eignet sich vor allem zur Überprüfung in einem frühen Ent-
wicklungsstadium, wenn die Anwendung noch nicht bereit für einen Nutzer ist (Proto-
typ) oder um leistungsorientierte Ergebnisse wie Zeitdauer pro Aufgabe oder Anzahl
der Klicks zu erhalten. Auch wenn die Heuristische Evaluation Teil des Discount Usabi-
lity Engineering ist (vgl. Abschnitt „2.2.4 Discount Usability Engineering“) können
damit in relativ kurzer Zeit qualitativ hochwertige Ergebnisse erzielt werden.
2.2.3 Gegenüberstellung Nutzertest und Expertentest
In den vorherigen Abschnitten wurden bereits die Einsatzmöglichkeiten sowie die je-
weiligen Vor- und Nachteile von Nutzer- sowie Expertenevaluationen beschrieben.
Durch die Verwendung von nutzer- und expertenorientierten Methoden können unter-
schiedliche Problemarten aufgedeckt werden. Während bei Nutzertests hauptsächlich
größere Probleme entdeckt werden, werden in Expertentests eher kleinere Probleme
identifiziert, dafür jedoch mehr in der Anzahl. Größere (vor allem kritische) Probleme
behindern den Nutzer erheblich in seiner Arbeit und frustrieren ihn oder halten ihn so-
gar ganz von der Aufgabenbewältigung ab [Dumas1999]. Kleinere Probleme bezeich-
nen Mängel, die den Nutzer nicht erheblich frustrieren, ihn aber an einer schnellen Auf-
gabenerledigung hindern und insgesamt einen negativen Eindruck hinterlassen, „weil
sie das Gefühl erzeugen, die Designer hätten bei der Produktentwicklung schlampig
gearbeitet.“ [Schweibenz2003].
Beide Testmethoden decken folglich Usability-Probleme auf, die auch durch das jeweils
andere Verfahren gefunden werden. Dies führt zum doppelten Auftreten von einigen
Usability-Problemen und zeigt auf die Notwendigkeit der Beseitigung dieses Problems
hin. Demnach wendet man idealerweise beide Testmethoden in Kombination an und
erweitert durch die Stärken von beiden das gesamte Evaluationsergebnis.
2.2 Arten von Usabilitytests
34
2.2.4 Discount Usability Engineering
Die Durchführung einer Usability-Evaluation ist immer mit finanziellem und zeitlichem
Aufwand verbunden. Vor allem wenn man die intensive Vorbereitung für einen Nutzer-
test betrachtet, schrecken viele Unternehmen vor diesem Aufwand zurück und führen
aus verschiedenen Gründen keine Evaluation durch. Die häufigsten Gründe sind, dass es
den Firmen zu lang dauert bis Testergebnisse vorliegen oder dass durch den Einsatz
eines Usability-Experten und die Rekrutierung einer statistisch relevanten Anzahl an
Testpersonen das Budget überzogen werden würde. Damit trotzdem Usabilitytests
durchgeführt werden, kann man die wissenschaftlichen Testmethoden vereinfachen.
Durch eine Vereinfachung werden keine „perfekten“ Ergebnisse erzielt, jedoch erhält
man immer noch „gute“ Aussagen, die für die meisten Fälle ausreichen. Diese Verein-
fachungen fasst Nielsen unter dem Begriff „Discount Usability Engineering“ zusam-
men. Speziell macht er drei Vorschläge [www21]:
• Anstatt kompletter Prototypen sollten Szenarios eingesetzt werden. Ein Szenario
beschreibt einen Prototyp, der in Bezug auf die Anzahl und Tiefe seiner Funkti-
onen reduziert wurde. Dieser minimalistische Prototyp stellt nur einen bestimm-
ten Weg durch das User Interface dar. Durch die reduzierte Größe kann das Sze-
nario schnell angepasst und daher auch in mehreren Versionen getestet werden.
• Die Methode des Think Aloud wird vereinfacht. Traditionell finden Think A-
loud-Studien unter Anleitung eines Psychologen oder Usability-Experten in ei-
nem Usability-Labor statt, werden per Video aufgenommen und anschließend
aufwändig ausgewertet. Diese wissenschaftliche Anordnung kann für die Praxis
vereinfacht werden, indem Informatiker durch eine vorherige Schulung den Part
des Testleiters einnehmen. Gleichzeitig wird die Anzahl der Nutzer verringert
und die Videoaufzeichnung durch die Notizen des Testleiters ersetzt.
• Durch die Nutzung von einigen wenigen, gut gestalteten Heuristiken anstatt
Hunderten von Usability-Prinzipien kann sowohl der Designprozess als auch die
Evaluation vereinfacht werden. Der Entwickler muss weniger Usability-
Prinzipien beachten und die Heuristiken können dem Experten schneller erklärt
werden. Sogar Laien können damit viele Usability-Probleme aufdecken und die
restlichen Probleme werden durch einen vereinfachten Think Aloud-Test offen-
2.2 Arten von Usabilitytests
35
gelegt. Nielsen verweist dabei vor allem auf seine zehn Heuristiken und die Me-
thode der Heuristischen Evaluation.
Die Methoden des Discount Usability Engineering sind umstritten, da die Wissenschaft-
lichkeit der Methoden, z.B. durch den Einsatz von Laien anstatt (Usability-)Experten,
verringert wird. Durch die einfachere Handhabung dominiert in der Praxis jedoch die
Anwendung der vereinfachten Methoden im Gegensatz zu traditionellen Testmethoden.
Die traditionellen Testmethoden müssen auch für die Evaluation von mobilen Endgerä-
ten angepasst werden. Welche Besonderheiten dabei beachtet werden müssen, be-
schreibt der folgende Abschnitt.
2.2.5 Usabilitytest mit mobilen Endgeräten
Die Größe und Mobilität von mobilen Endgeräten erfordert eine besondere Herange-
hensweise bei der Beobachtung, der Testmethode und der Auswahl der Testumgebung.
Daher gelten bei der Untersuchung der Benutzerfreundlichkeit von mobilen Geräten,
wie z.B. Handys, besondere Bedingungen.
Beim Testen einer Desktopanwendung auf einem PC wird die zu testende Applikation
per Kamera gefilmt. Da Handys jedoch einen sehr kleinen Bildschirm aufweisen, gestal-
tet sich dies bei mobilen Anwendungen schwieriger. Für dieses Problem gibt es ver-
schiedene Lösungsansätze:
a. Man kann eine Minikamera direkt am Gerät montieren. Damit wird jedoch das
Handy selbst unhandlicher und eventuell ein Teil des Displays verdeckt. Zusätz-
lich ist es mit dieser Lösungsmethode nicht möglich gleichzeitig die vom Tester
benutzten Tasten per Kamera aufzunehmen.
b. Man kann den Tester mit einer sogenannten Kopfkamera ausstatten. Das heißt,
der Nutzer bekommt eine Vorrichtung auf seinen Kopf gesetzt an der eine Ka-
mera montiert ist. Dies hat den Nachteil, dass sich bei jeder Kopfbewegung des
Testers die Aufnahme vom Handydisplay wegbewegt.
c. Als dritte Alternative bietet sich an, dass eine stationäre Kamera einen festen,
abgesteckten Bereich filmt. Der Nutzer darf nun während des Tests das Handy
2.2 Arten von Usabilitytests
36
nur innerhalb dieses Bereichs bewegen. Dies führt zu einer eingeschränkten
Mobilität, ist jedoch die beste Möglichkeit um sowohl das Display als auch die
Tastennutzung zu filmen.
Eine weitere Überlegung bei Usabilitytests von mobilen Anwendungen betrifft die
Testumgebung. Mobile Applikationen sind dafür entwickelt, um in einem mobilen Kon-
text angewendet zu werden, z.B. um von unterwegs im Internet zu surfen. Jedoch ist in
einem solchen Umfeld die Testaufzeichnung und -beobachtung weit schwieriger zu
realisieren. Daher sollte man sich überlegen, ob der Nutzertest unter quasi realen Be-
dingungen, z.B. in einer Fußgängerzone, oder in einem Usability-Labor durchgeführt
wird.
Im Jahr 2004 hat Kjeldskov et. al. eine Studie [Kjeldskov2004] durchgeführt und ver-
schiedene Techniken überprüft, um mobile Geräte in einem kontrollierten Umfeld eva-
luieren zu können. Die getesteten Techniken sollten die physische Bewegung und die
benötigte Aufmerksamkeit simulieren, die entstehen, wenn man sich während der Han-
dynutzung bewegt. Ein Szenario beinhaltete die Benutzung eines Hometrainers während
der Tester gleichzeitig ein Handy bedient. Parallel wurden als Referenz die Nutzerauf-
gaben beim Spazieren durch eine Fußgängerzone getestet. Jedoch war bei keiner der
entworfenen Techniken die mentale Auslastung des Nutzers so hoch wie in der Fußgän-
gerzone. Ein weiteres Ergebnis zeigte, dass bei keinem getesteten Szenario so viele U-
sability-Probleme entdeckt werden wie beim normalen Sitzen an einem Tisch. Daher
sollte man sich bei der Ausarbeitung des Testsetups Gedanken darüber machen, ob die
Priorität des Nutzertests auf der Bedienung der Anwendung in einer mobilen Situation
oder auf dem Auffinden von generellen Usability-Problemen liegt.
Der letzte Abschnitt behandelte die Besonderheiten einer Usability-Evaluation mit mo-
bilen Endgeräten. Durch die Mobilität gelten auch spezielle Anforderungen an die Be-
nutzerfreundlichkeit einer mobilen Anwendung. Diese werden im nächsten Abschnitt
näher beleuchtet.
2.3 Usabilityanforderungen an mobile Anwendungen
37
2.3 Usabilityanforderungen an mobile Anwendungen
Der entscheidende Vorteil von Handys liegt in deren Mobilität. Damit ist der Nutzer
räumlich unabhängig und kann überall sein mobiles Endgerät bedienen. Dieser Vorteil
führt zu einer Herausforderung an die Usability des Geräts. Durch die kompakte Größe
des Geräts wird auch die Größe der User Interface Elemente beeinflusst. Sowohl die
Hardware wird durch die Anzahl und Größe der Tasten limitiert, als auch die Software,
die unter Berücksichtigung des menschlichen Sehvermögens nur eine begrenzte Anzahl
an Daten auf dem Display darstellen kann.
Die Mehrheit der Usabilityanforderungen und -erfahrungen wurde im Umgang mit
Desktopanwendungen für PCs gesammelt. Deren Nutzerschnittstellen arbeiten mit der
Methode der direkten Manipulation. Das heißt, der Nutzer sieht jederzeit die Objekte,
z.B. Ordner und Dateien, arbeitet mit diesen und bekommt das Ergebnis ebenso in visu-
eller Form repräsentiert, z.B. per Drag and Drop. Durch das entsprechend große Bild-
schirmformat ist dies möglich. Bei kleineren Displays sieht das ganz anders aus. Es ist
nicht möglich einfach die Logik von Desktopanwendungen zu übertragen, da die An-
forderungen an kleine Bildschirme wesentlich anders sind [Keinonen2003].
Desktop Interfaces bedienen sich einer Technik namens paralleler Darstellung. Das
heißt, dass viele verschiedene Optionen (Fenster, Ordner, Menüs, etc.) gleichzeitig dar-
gestellt werden können. Auf einem kleinen Bildschirm funktioniert diese Technik nicht,
daher arbeitet man dort mit einer sequenziellen Darstellung. Das bedeutet, dass nur eine
geringe Anzahl von Optionen gleichzeitig abgebildet werden kann und der Nutzer folg-
lich mehr im Menü suchen muss. Bei der parallelen Darstellung ist es möglich, auf ver-
schiedenen Wegen zum Ziel zu kommen. Als Beispiel wird das Ausschneiden und Ein-
fügen einer Datei betrachtet. Dies kann auf drei verschiedene Arten geschehen:
1. über die Menüpunkte „Ausschneiden“ und „Einfügen“ der Anwendung
2. über die Tastenkombination Strg + X und Strg + V oder
3. die Datei wird per Drag and Drop verschoben
Dadurch kann jeder Nutzer seine favorisierte Methode wählen, wobei alle zum gleichen
Ergebnis führen. Mit einem Handy besteht diese Auswahl nicht. Der Nutzer muss das
2.3 Usabilityanforderungen an mobile Anwendungen
38
Handymenü in der vorgegebenen Reihenfolge durchsuchen. Daher ist es extrem wich-
tig, dass oft benutzte Funktionen am Anfang eines Menüs zu finden sind. Der Handy-
hersteller Nokia hat dafür eine eigene Theorie („path of reasoning“) entwickelt
(Abbildung 2-3), welche die Priorisierung von Handyfunktionen verdeutlicht.
Abbildung 2-3: Path of reasoning (verändert [nach Keinonen2003])
Die Theorie erklärt, dass bedingt durch die Mobilität der Geräte Handys nur einen klei-
nen Bildschirm besitzen. Auf kleinen Displays können Menüs und Anwendungen nur
nacheinander präsentiert werden (sequenzielle Darstellung). Daraus folgt, dass die Me-
nüpunkte nach Wichtigkeit sortiert werden müssen (Priorisierung), damit die Anforde-
rungen des Nutzers erfüllt werden. Anhand dieser speziellen Anforderungen wurden
verschiedene Richtlinien für die Gestaltung von mobilen Anwendungen entwickelt, die
im nachfolgenden Abschnitt vorgestellt werden.
2.3.1 Interface Guidelines für mobile Endgeräte
Der Bereich Designrichtlinien für mobile Endgeräte ist noch recht wenig erforscht. Für
das Design von Desktop Interfaces existieren deutlich mehr Richtlinien. Neben den ver-
schiedenen Usability-Normen, die als ISO-Standards formuliert sind z.B. DIN EN I-
SO 9241-110 „Grundsätze der Dialoggestaltung“, gibt es noch diverse Designer-
Empfehlungen, z.B. die Acht Goldenen Regeln von Ben Shneiderman oder die zehn
Usability-Heuristiken von Jakob Nielsen (vgl. Abschnitt „2.2.2 Expertentest“). Um die
Lücke zu den mobilen Geräten zu schließen, haben im Jahr 2004 Jun Gong und Peter
Tarasewich die „Guidelines for handheld mobile device interface design“ veröffentlicht.
2.3 Usabilityanforderungen an mobile Anwendungen
39
Diese Guidelines entstanden durch die Übernahme von vier der Acht Goldenen Regeln
von Shneiderman und wurden durch weitere spezifische Richtlinien ergänzt. Im Jahr
2002 hat sich bereits Scott Weiss mit der Erstellung von Designrichtlinien für mobile
Geräte beschäftigt und in seinem Buch „Handheld Usability“ publiziert. Beide Samm-
lungen an Guidelines geben einige übereinstimmende Empfehlungen an und ergänzen
sich gegenseitig durch die Betrachtung verschiedener Designaspekte (Tabelle 2-2).
Tabelle 2-2: Gegenüberstellung der Guidelines für mobile Geräte von Gong & Tarasewich sowie Weiss
Guidelines for handheld mobile device interface design [nach Gong2004]
User Interface Design Guidelines for Handheld Devices [nach Weiss2002]
Aussagekräftiges Feedback geben Feedback
Benutzerkontrolle Nutzerkontrolle
Geräteübergreifende Konsistenz Plattformübergreifende Konsistenz
Umkehrbarkeit bei begrenzten Ressourcen Umkehrbarkeit, Designstabilität
Eingeschränkte und geteilte Aufmerksamkeit Design für mobile Nutzer
Shortcuts für Vielnutzer anbieten
Abgeschlossenheit
Fehlervermeidung
Kurzzeitgedächtnis entlasten unter Ablenkung
Design für vielfältige und dynamische Umgebungen
Größenbedingte Faktoren
Schneller Wechsel von Anwendungen
Top-Down-Interaktion
Personalisierung
Ästhetik (Design for enjoyment)
Konsistenz
Auswahl statt Eingabe
Icons zur Konzeptdarstellung
Metaphern
Klickbare Grafiken sollten klickbar aussehen
Im Folgenden werden zuerst die übereinstimmenden Richtlinien von Gong & Tarase-
wich [nach Gong2004] sowie Scott Weiss [nach Weiss2002] kurz erläutert und an-
schließend durch die einzelnen Empfehlungen beider Seiten ergänzt:
2.3 Usabilityanforderungen an mobile Anwendungen
40
Aussagekräftiges Feedback geben
Der Nutzer sollte jederzeit wissen in welchem Zustand sich die Anwendung befindet.
Dafür sollte die Applikation Feedback, z.B. durch Statusmeldungen oder Töne, ausge-
ben. Das Feedback muss verständlich für den Nutzer sein. Beispielsweise sagen die
beiden Statusmeldungen „HTTP 404 Error“ und „The page can not be found“ das glei-
che aus, jedoch ist letztere Meldung für den Nutzer verständlicher.
Benutzerkontrolle
Kein Mensch möchte von der Technik beherrscht werden, sondern die Steuerung und
Kontrolle über die Technik besitzen. Daher sollte der Nutzer Aktionen aktiv starten
können (anstatt nur darauf zu reagieren) und vor allem jederzeit beenden können. Man
denke zum Beispiel an einen ungewollten Tastendruck in der Hosentasche.
Durch die Anordnung des Handymenüs als Liste beschränkt sich die Interaktion des
Nutzers auf das Aufrufen von vordefinierten Menüeinträgen. Ein Handymenü kann je-
doch interaktiv gestaltet werden. Zum Beispiel indem es sinnvolle Verlinkungen zwi-
schen verschiedenen Anwendungsbereichen bzw. unterschiedlichen Anwendungen
selbst anbietet. Eine solche Verknüpfung bietet bereits jedes herkömmliche Handy an:
Wenn man einen Kontakt im Telefonbuch auswählt, kann der Nutzer auswählen, ob er
diesen Kontakt anrufen, bearbeiten oder eine Mitteilung schreiben möchte.
Geräteübergreifende Konsistenz
Beim Design von mobilen Anwendungen sollte man beachten, dass viele Nutzer regel-
mäßig zwischen verschiedenen Geräten wie Handy, PDA oder Laptop wechseln. Eine
Applikation, die auf verschiedenen Plattformen läuft, sollte daher durch eine einheitli-
che Verwendung von Begriffen, Dialogen und des gesamten Erscheinungsbilds konsi-
stent gestaltet werden. Dadurch wird auch der Wiedererkennungswert innerhalb einer
Produktfamilie über sämtliche Produkte hinweg gesichert. Als positives Beispiel sei hier
der Opera Mini genannt. Er weist vergleichbare Funktionen sowie Ähnlichkeiten in
Menüführung und Aussehen mit seinem „großen Bruder“ dem Opera-Browser für PCs
auf.
2.3 Usabilityanforderungen an mobile Anwendungen
41
Umkehrbarkeit bei begrenzten Ressourcen und Designstabilität
Wenn ein Nutzer einen Fehler begeht, sollte er diesen auch wieder rückgängig machen
können. Eine Möglichkeit zur Umsetzung ist zum Beispiel die „Zurück“-Taste des Mo-
biltelefons oder ein entsprechender Menüpunkt. Dabei muss man jedoch beachten, dass
die Umkehrbarkeit durch die eher geringe Speicherkapazität sowie Rechenleistung der
Handys sich nicht ohne weiteres realisieren lässt. Die Wiederherstellung von älteren
Systemzuständen stellt jedoch eine wichtige Funktion dar, denn drahtlose Verbindungen
sind störanfälliger als drahtgebundene. Man stelle sich vor, ein Nutzer kauft ein Bahnti-
cket per mobilem Internet und die Netzverbindung wird unterbrochen. Innerhalb einer
stabilen Anwendung sollte der Nutzer den Prozess ohne erneute Dateneingabe (Mehr-
aufwand) fortführen können.
Eingeschränkte und geteilte Aufmerksamkeit
Oft erledigen die Nutzer von mobilen Geräten mehrere Dinge gleichzeitig und widmen
damit ihre Aufmerksamkeit mehr als einer Aufgabe. Der Nutzer befindet sich zum Bei-
spiel in einer Warteschlange oder einem Gespräch. Ein Handy, welches viel Aufmerk-
samkeit beansprucht, kann den Nutzer daher von seiner eigentlichen, eventuell wichti-
geren Aufgabe, z.B. Auto fahren, ablenken. Deshalb muss bei der Gestaltung einer mo-
bilen Anwendung bedacht werden, dass die Anwendung selbst so wenig wie möglich
Aufmerksamkeit fordert. Dies kann beispielsweise durch eine Freisprechfunktion er-
reicht werden.
Nachdem alle ähnlichen Guidelines für mobile Anwendungen von Gong & Tarasewich
sowie Weiss kurz dargestellt wurden, folgen die zusätzlichen Richtlinien des Entwick-
lerduos Peter Gong und Jun Tarasewich [nach Gong2004]:
Shortcuts für Vielnutzer anbieten
Zeit ist ein kritischer Faktor für den mobilen Nutzer. Durch die Einführung von Tasta-
turkürzeln für oft verwendete Aufgaben können die Interaktionsschritte reduziert und
folglich die Schnelligkeit der Anwendungen erhöht werden.
2.3 Usabilityanforderungen an mobile Anwendungen
42
Abgeschlossenheit
Falls eine Aktion aus zusammenhängenden Operationen besteht, sollte dies auch dem-
entsprechend dargestellt werden, z.B. durch eine Übersicht aller Schritte.
Fehlervermeidung
Anders als bei Desktopanwendungen muss man bei der Fehlervermeidung und Fehler-
behandlung von mobilen Applikationen noch umfassender sein. Denn bei mobilen Ge-
räten spielt auch das physische Design eine Rolle. Durch zu kleine oder falsch angeord-
nete Tasten können Fehler entstehen. Dies kann man zum Beispiel durch eine entspre-
chende Tastenbelegung der Menüpunkte verhindern.
Kurzzeitgedächtnis entlasten unter Ablenkung
Ein mobiler Nutzer besitzt je nach Situation eine eher geringe Aufmerksamkeitsspanne
(Abbildung 2-4). Zusätzlich kann unser Kurzzeitgedächtnis nur maximal 7 ± 2 Einhei-
ten verarbeiten. Daher sollte eine mobile Anwendung so gestaltet sein, dass der Nutzer
sich möglichst wenig merken muss. Beim Aufbau einer Menüstruktur sollten daher
breite statt tiefe Menübäume verwendet werden [Dahm2006].
Abbildung 2-4: Aufmerksamkeitsspanne in verschiedenen mobilen Situationen [Oulasvirta2005]
Es kann sein, dass die mobile Applikation nicht das Hauptaugenmerk des Nutzers ist. Es
kann sogar vorkommen, dass der Nutzer seine aktuelle Beschäftigung nicht unterbre-
chen kann um mit dem mobilen Gerät zu interagieren, z.B. beim Auto fahren. Daher
sollten alternative Interaktionsmöglichkeiten, wie z.B. Sound, verwendet werden.
2.3 Usabilityanforderungen an mobile Anwendungen
43
Design für vielfältige und dynamische Umgebungen
Der Vorteil von mobilen Geräten liegt in deren Mobilität. Daraus erwächst jedoch
gleichzeitig der Nachteil, dass die Umgebung, in der das Mobiltelefon verwendet wird,
nicht vorhergesagt werden kann. Umgebungsbedingungen wie Helligkeit, Geräuschpe-
gel oder Wetter ändern sich je nach Ort, Tages- und Jahreszeit. Kleine Schriftgrößen
funktionieren gut in geschlossenen Räumen, werden aber eher unleserlich bei hellem
Sonnenschein. Je nach Umgebung muss sich daher das Handy anpassen können, z.B.
könnten Nutzer sich unwohl fühlen in der Anwesenheit von Fremden laut zu sprechen
oder bestimmte Plätze (z.B. Bibliotheken) erlauben keine Spracheingabe. Zusätzlich
verwendet der Nutzer eventuell eine Hand oder sogar beide, während er mit dem mobi-
len Gerät interagiert. Eine Lösung des Problems der dynamischen Umgebung kann
durch kontextabhängige und selbstanpassende Funktionen realisiert werden. Beispiels-
weise durch die Implementierung eines Lichtsensors, der automatisch die Displayhel-
ligkeit regelt, kann die Usability einer Handyanwendung erhöht werden.
Größenbedingte Faktoren
Mobile Geräte besitzen eine eher geringe Größe. Dadurch entstehen physische Begren-
zungen (kleines Display, kleine Tasten, etc.), die wiederum neue Ein- und Ausgabeme-
chanismen erfordern. Spracheingabe ist zum Beispiel eine alternative Möglichkeit.
Schneller Wechsel von Anwendungen
Oft steht der mobile Nutzer aufgrund der verschiedenen Umgebungen unter Zeitdruck
und muss schnell eine Anwendung starten oder beenden können. Gleichzeitig muss er
schnell und sicher seine bereits getane Arbeit speichern und später ohne Datenverlust
wieder aufrufen können. Daher müssen Handys in der Lage sein schnell in eine andere
Anwendung und wieder zurück wechseln zu können, z.B. wenn beim Schreiben einer
SMS jemand anruft.
Top-Down Interaktion
Mobile Geräte besitzen kleine Bildschirme auf denen nur eine begrenzte Menge an In-
formationen dargestellt werden kann. Um Ablenkung zu vermeiden sollten die Funktio-
2.3 Usabilityanforderungen an mobile Anwendungen
44
nen durch Menüs sinnvoll hierarchisch gegliedert werden, damit der Nutzer sich ein
mentales Modell der Navigation bilden kann.
Personalisierung
Computer werden oft von verschiedenen Nutzern bedient. Ein mobiles Endgerät wird
normalerweise nur von einer Person genutzt. Verschiedene Nutzer besitzen unterschied-
liche Vorlieben und Fertigkeiten. Deshalb ist es wichtig, dass mobile Anwendungen
einfach an die individuellen Bedürfnisse, z.B. Schriftgröße oder Design, angepasst wer-
den können. Hilfreich ist es auch, wenn der Nutzer eigene Tastaturkürzel festlegen
kann.
Ästhetik (Design for enjoyment)
Funktionalität und Benutzerfreundlichkeit sind zwei Aspekte auf dem Weg zur erfolg-
reichen mobilen Anwendung. Ästhetik ist ein weiterer Faktor. Wenn die Funktionalität
und Usability gleichwertig sind, wird eine Anwendung oder ein Gerät nur herausragen,
wenn es auf irgendeine Art und Weise, z.B. durch Farben, interessant ist und die Bedie-
nung Spaß macht. Man denke zum Beispiel an den Erfolg des iPhones. Es besitzt nicht
die neueste Technik, wie beispielsweise UMTS. Das iPhone überzeugt jedoch den Nut-
zer durch den spielerischen Umgang und den damit verbundenen Spaß beispielsweise
dem Scrollen mit zwei Fingern.
Alle Guidelines für mobile Anwendungen von Gong & Tarasewich wurden im letzten
Abschnitt kurz erläutert. Diese Guidelines werden im Folgenden durch weitere Empfeh-
lungen von Scott Weiss ergänzt [nach Weiss2002]:
Konsistenz
Analog zur geräteübergreifenden Konsistenz sollte die Anwendung auch in sich konsi-
stent sein. Das heißt, innerhalb der Applikation sollten die gleichen Begriffe und Inter-
aktionsmuster verwendet werden. Ferner sollte man sich an bewährte Designelemente
und Bedienstrategien halten, da diese schon bekannt sind und somit kein zusätzlicher
Lernaufwand für den Nutzer entsteht.
2.3 Usabilityanforderungen an mobile Anwendungen
45
Auswahl statt Eingabe
Die Eingabe von Daten auf einem Handy gestaltet sich durch das Fehlen einer „richti-
gen“ Tastatur umständlich. Soweit möglich sollte eine Anwendung daher eine über-
schaubare Auswahl, z.B. durch eine Drop-Down-Liste, anbieten. Eine weitere Verbes-
serung der Benutzerfreundlichkeit wird erreicht, wenn die Anwendung Abkürzungen
unterstützt, wie z.B. KFZ-Kennzeichen bei Ortseingaben.
Icons zur Konzeptdarstellung
Beim Design von mobilen Anwendungen sollte man darauf achten, aussagekräftige I-
cons zu verwenden. Diese lassen sich schneller erfassen als Text und benötigen oft we-
niger Platz. Die besten Icons stellen einfache Repräsentationen der realen Welt dar, z.B.
eine Alarmglocke für die Weckfunktion. Gleichzeitig muss die Bedeutung des Icons
klar erkennbar sein. Ein Briefumschlag beispielsweise ist ein mehrdeutiges Zeichen. Er
kann für „Kurzmitteilungen“ (SMS) aber auch für „E-Mail“ stehen. Ein guter Kompro-
miss wäre es, beide Funktionen an einer Stelle anzubieten.
Metaphern
Durch die Verwendung von Metaphern aus der realen Welt kann das Nutzerverständnis
erhöht werden. Die „Desktop“-Metapher funktioniert auf dem PC, lässt sich jedoch
nicht ohne weiteres auf ein Handy übertragen. Das Display eines Handys ist viel zu
klein, als das ein Nutzer es ernsthaft mit dem Begriff „Desktop“ verbinden würde. Des-
halb sollte man bei der Gestaltung darauf achten nur sinnvolle Metaphern zu verwen-
den.
Klickbare Grafiken sollten klickbar aussehen
Hyperlinks oder verlinkte Bilder sollten so gestaltet sein, dass der Nutzer erkennt, dass
es sich um eine Verknüpfung handelt. Das heißt, Bilder sollten klare Ränder und soweit
möglich einen hohen Kontrast zum Hintergrund aufweisen.
Zusammengefasst kann man sagen, dass die Unterschiede zwischen PCs und mobilen
Endgeräten verschiedene Herangehensweisen beim Design erfordern. Mobile Geräte
2.3 Usabilityanforderungen an mobile Anwendungen
46
mit ihrer erhöhten Bewegungsfreiheit, begrenztem Speicher und Leistung sowie klei-
nem Display bringen Herausforderungen, aber auch Chancen mit sich.
2.3.2 Usabilityanforderungen an mobile Browser
Aus den vorangegangenen Guidelines sowie diverser Literatur und eigenen Überlegun-
gen wurden einige konkrete Ideen für die Erhöhung der Benutzerfreundlichkeit von
mobilen Browsern formuliert. Diese spezifischen Empfehlungen gelten vor allem für
die mobilen Browser, können jedoch auch teilweise für PC-Browser angewandt werden.
Die Vorschläge sind im Folgenden aufgelistet:
• Bei Formularfeldern sollte der Browser erkennen, welches Datenformat das
Eingabefeld verlangt, z.B. Uhrzeit, Datum, etc. Daraufhin sollte er den passen-
den Eingabemodus, z.B. Zahlen anstatt Buchstaben, direkt öffnen [Rischpa-
ter2000].
• Idealerweise passt der Browser die aufgerufene Webseite automatisch an die
Displaybreite des Handys an. Damit wird horizontales Scrollen verhindert und
der Lesefluss des Nutzers wird nicht gestört.
• Einige Webseiten gestalten ihre Bilder als Hyperlinks und manche Browser bie-
ten die Funktion an, dass Bilder (aus Kostengründen) nicht geladen werden.
Wenn diese Funktion aktiviert ist, sollte der Browser trotzdem im Stande sein
den Link ordnungsgemäß aufzurufen.
• Auf jeden Fall sollte ein mobiler Browser analog zu den PC-Browsern die Me-
tapher des „Lesezeichens“ verwenden. Erstens ist diese sehr aussagekräftig und
zweitens durch die Verwendung von PC-Browsern bereits bekannt.
• In Bezug auf die Personalisierung sollte sich der Browser an die Vorlieben und
Bedürfnisse des Nutzers anpassen. Dies kann beispielsweise dadurch realisiert
werden, dass der Nutzer eigene Lesezeichen per selbst gewähltes Tastaturkürzel
aufruft oder der Browser bei Bedarf alle Passwörter speichert, damit die müh-
same Eingabe entfällt [Korzenek2007].
• Wie in den Guidelines erwähnt, muss eine mobile Anwendung auch bei geringer
Aufmerksamkeit des Nutzers ausreichend und schnelles Feedback anbieten.
Sonst nimmt die Konzentration des Nutzers ab und er kann Fehler verursachen.
Falls das Feedback nicht schnell genug gegeben wird, neigt der Nutzer zu der
2.3 Usabilityanforderungen an mobile Anwendungen
47
Annahme, dass sein Befehl nicht angenommen wurde. Demzufolge bricht er den
Vorgang ab oder ruft die Funktion wiederholt auf [Korzenek2007]. Zur Lösung
des Problems sollte daher der Prozessfortschritt immer visuell dargestellt wer-
den, z.B. durch einen Ladebalken [Chan2002]. Die Reaktion des Browsers darf
jedoch nicht zu schnell für den Nutzer erfolgen. Das Scrollen einer Webseite
sollte beispielsweise in Echtzeit passieren, damit der Nutzer dem Ablauf folgen
kann [Nielsen1993].
• Damit der Nutzer die Kontrolle über den Browser behält, sollte dieser eine um-
fangreiche Zurück-Funktionalität anbieten. Scott Weiss zieht dafür einen schö-
nen Vergleich heran: „The ‚Back’ button is the most popular control in desktop
Web browsing, but only a small fraction of the dozens of Internet-enabled hand-
sets has one. Using the Web without the ‚Back’ button is like using a word proc-
essor without being able to ‚Undo’.“ [Weiss2002]
• Ein Handybrowser sollte die Verlaufsfunktion in Listenform darstellen. Das
heißt, der Browser sollte die besuchten Seiten in der Reihenfolge des Aufrufs
anzeigen [Chan2002].
• Ein mobiler Browser sollte den Nutzer durch vorausschauende Funktionen un-
terstützen. Das heißt, für vorhersehbare Aktionen sollten entsprechende Funkti-
onen angeboten werden. Wenn der Nutzer zum Beispiel eine Telefonnummer
auf einer Webseite ausgewählt hat, kann der Browser die Option „Anrufen“ an-
zeigen oder die Option „E-Mail schreiben“, wenn der Nutzer einen Text mar-
kiert hat, der ein „@“-Zeichen enthält.
Dieses Kapitel behandelte allgemein die Vorstellung einzelner Methoden zur Evaluie-
rung der Usability sowie die besonderen Anforderungen, die an das Design von mobilen
Anwendungen gestellt werden. Dafür wurden verschiedene Guidelines vorgestellt und
daraus spezielle Anforderungen an mobile Browser abgeleitet. Das folgende Kapitel
beschäftigt sich mit der praktischen Umsetzung der vorgestellten Think Aloud-
Methode. In einem Nutzertest werden verschiedene Handybrowser auf ihre Usability
überprüft. Anschließend wird im vierten Kapitel durch eine Experteninspektion unter-
sucht, wie gut die vorgestellten Interface Guidelines bei den ausgewählten Handybrow-
sern bereits eingehalten werden.
3.1 Planung des Nutzertests
48
3 Nutzertest zur Evaluation der Handybrowser
„I have always wished for my computer to be as easy to use as my telephone; my wish
has come true because I can no longer figure out how to use my telephone.“
Bjarne Stroustrup [www22]
Die Aufgabe einer Benutzerschnittstelle ist die übersichtliche Darstellung von Informa-
tionen sowie das Angebot an Funktionen und Nutzungsmöglichkeiten korrekt zu ver-
mitteln. Mit dieser Untersuchung soll erforscht werden, wie intuitiv das User Interface
von drei verschiedenen Handybrowsern bedienbar ist („ease of use“). Wie schnell kann
ein Nutzer eine Aufgabe bewältigen? Findet er eine passende Funktion zur Aufgabe?
Verhält sich die Funktion wie erwartet? Wie einfach ist die Bedienung? Zusammenfas-
send gesagt, es soll die Benutzerfreundlichkeit der Handybrowser untersucht werden.
Dies geschieht mithilfe eines Nutzertests, dessen theoretisches Vorgehen im Abschnitt
„2.2.1 Nutzertest“ bereits detailliert beschrieben wurde.
3.1 Planung des Nutzertests
Bevor ein Nutzertest erfolgreich durchgeführt werden kann, muss dieser sorgfältig vor-
bereitet werden. Daher ist in die Planung dieses Nutzertests viel Vorarbeit eingeflossen.
Die einzelnen Planungsschritte sind in der Abbildung 3-1 dargestellt. Sie werden in den
folgenden Abschnitten näher erläutert.
Abbildung 3-1: Planungsschritte des Nutzertests
Bevor eine Testmethode ausgewählt wurde, wurde neben einem intensiven Literaturstu-
dium zum Thema Nutzertest eine Task-Analyse für Handybrowser durchgeführt.
Eine Task-Analyse hilft, um im Vorfeld der Produktentwicklung so viel wie möglich
über den Nutzer und seine typischen Nutzungsvorgänge mit einem Produkt zu erfahren.
Bei der Analyse werden durch verschiedene Methoden wie Beobachtung, Befragung
3.1 Planung des Nutzertests
49
oder Informationsrecherche so viele Nutzerdaten wie möglich erfasst. Durch die ge-
sammelten Daten erhält man einen „gläsernen Nutzer“, der dem Entwickler bei der Pro-
dukterstellung hilft.
Für die Erstellung einer Task-Analyse empfiehlt Röse die Beantwortung von zehn Leit-
fragen [Röse2003]:
1. Wer sind die Nutzer des Produkts?
2. Welche Aufgaben führen die Nutzer tatsächlich durch?
3. Wie häufig wird welche Aufgabe durchgeführt?
4. Unter welcher Zeitvorgabe müssen welche Aufgaben erledigt werden?
5. Welches Wissen benötigen die Nutzer, um ihre Aufgabe zu bewältigen?
6. In welcher Umgebung wird das Produkt zur Aufgabenerfüllung genutzt?
7. Wie stellt sich der Datenzugriff für den Nutzer dar?
8. Welche weiteren Produkte bzw. Hilfsmittel verwendet der Nutzer?
9. Wenn es mehrere Nutzer gibt, wie kommunizieren diese unter-/miteinander?
10. Wie ist das Vorgehen im Fehlerfall bzw. bei Zwischenfällen?
Durch eine Informationsrecherche wurden diese zehn Leitfragen beantwortet und damit
der Nutzertest besonders in Hinblick auf die Aufgabengestaltung, die Nutzerauswahl
und die Testumgebung vorbereitet.
3.1.1 Methodik
Um die Usability eines Produkts zu überprüfen, existieren verschiedene Testmethoden.
Zur Überprüfung der Benutzerfreundlichkeit erscheint eine alleinige Evaluation durch
Experten unter der vorliegenden Aufgabenstellung nicht angebracht. Denn nach Hein-
sen [Heinsen2003] basiert eine Bewertung durch Experten immer auf allgemein aner-
kannten Gestaltungsrichtlinien (Kriterien oder Heuristiken). Für neue Anwendungsbe-
reiche, wie z.B. mobile Geräte (Handy, PDA), existieren noch keine festgelegten Stan-
dardrichtlinien. Ansatzweise entwickeln sich aber erste Vorschläge, wie z.B. die vorge-
stellten Interface Guidelines (vgl. Abschnitt „2.3.1 Interface Guidelines für mobile End-
geräte“). Trotzdem wird bei der Evaluation von mobilen Endgeräten und deren Anwen-
dungen empfohlen Nutzertests einzusetzen.
3.1 Planung des Nutzertests
50
Wie bereits erwähnt ergänzen sich Nutzertest und Experteninspektion sehr gut und kön-
nen auch in Kombination angewendet werden. Jakob Nielsen empfiehlt dies ebenfalls
[Nielsen1993]. Aus diesen Gründen wurde bei der folgenden Untersuchung ein Nutzer-
test mit anschließender, vereinfachter Experteninspektion durchgeführt.
Als Testmethode bei der Evaluation durch die Nutzer wird das Think Aloud-Verfahren
angewendet. Laut einschlägiger Usabilityliteratur werden mit dieser Methode durch die
laute Artikulation der Gedanken und Erwartungen des Nutzers die besten Ergebnisse bei
einer Evaluation erzielt (vgl. [Nielsen1993]).
3.1.2 Testnutzer
Die Anwendung „Handybrowser“ besitzt keine speziell definierte Nutzergruppe, son-
dern wird von vielen verschiedenen Benutzergruppen verwendet. Die Applikation wur-
de zum Surfen im Internet entwickelt und somit für eine breite und vielfältige Zielgrup-
pe gestaltet. Im Gegensatz dazu weist eine Finanzsoftware für Buchhalter eine klar de-
finierte, überschaubare Zielgruppe auf.
Im Fall einer breiten Nutzerschaft, wie beim Handybrowser, schreibt Lorenzen-
Schmidt, dass bei einer Evaluation vor allem zentrale Usability-Aspekte und das Nut-
zungsverhalten relevant sind. Dies hat zur Folge, dass eine „gewisse Aufweichung der
Quoten“ möglich ist und damit die Rekrutierung von Testnutzern vereinfacht wird [Lo-
renzen-Schmidt2003]. Trotzdem wurde bei der Rekrutierung der Testpersonen im vor-
liegenden Nutzertest versucht soweit wie möglich eine repräsentative Auswahl an Tes-
tern zu schaffen.
Bei der Auswahl der Tester wurde auf folgende Kriterien geachtet:
• Insgesamt acht Tester sollten am Nutzertest teilnehmen, damit möglichst viele
Usability-Probleme entdeckt werden.
• Alle Tester mussten bereits Erfahrung mit dem „normalen“ Internet aufweisen,
damit das grundlegende Bedienkonzept eines Browsers bekannt ist.
• Die Auswahl von Nutzern, welche bereits Erfahrungen mit Nokia-Handys ha-
ben, wurde bevorzugt, damit gerätebezogene Bedienprobleme vermindert wer-
den konnten.
3.1 Planung des Nutzertests
51
• Ungefähr die Hälfte der Testnutzer sollte weiblich sein.
• Die Tester sollten sowohl aus einem Technikumfeld als auch aus nicht-
technischen Bereichen stammen.
• Ein weiteres Ziel war es, sowohl Anfänger als auch versierte Benutzer des mobi-
len Webs zu finden, um Bedienprobleme einerseits bei der ersten Benutzung als
auch bei fortgeschrittener Nutzung aufzudecken. Da der Testfokus auf der Intui-
tivität der Bedienung liegt, sollten mehr Anfänger als Fortgeschrittene getestet
werden.
Im Jahr 2007 führten die beiden Marktforschungsunternehmen Telephia und comScore
eine Vergleichsstudie zum mobilen Internet durch. Die sogenannte „MobileWeb Me-
trix“ hat gezeigt, dass die Hauptnutzer des mobilen Internets in Großbritannien und den
USA (für Deutschland lagen leider keine Zahlen vor) Männer zwischen 15 und 34 Jah-
ren sind [www23]. Daher wurde versucht, sich im Nutzertest auf diese Hauptnutzer-
gruppe zu konzentrieren. Für eine umfassende Betrachtung sollten jedoch auch Männer
über 34 Jahre sowie Frauen verschiedenen Alters am Nutzertest teilnehmen.
Unter Beachtung der genannten Kriterien gestaltete sich die Umsetzung der Rekrutie-
rung wie folgt: Es wurden insgesamt zehn Testnutzer rekrutiert. Diese wurden lokal im
Raum Aachen per E-Mail, Telefon oder persönlich kontaktiert. Das Ziel war es insge-
samt acht Testnutzer zu erhalten. Es wurden sicherheitshalber zwei Tester mehr akqui-
riert um bei Terminproblemen flexibel sein zu können. Diese Vorsichtsmaßnahme er-
wies sich als sinnvoll, als tatsächlich zwei Personen aufgrund von kurzfristigen, termin-
lichen Schwierigkeiten nicht teilnehmen konnten.
Die genaue Zusammensetzung der acht Testnutzer gestaltete sich wie folgt:
• Drei der Tester waren weiblich und fünf Tester waren männlichen Geschlechts.
• Das Alter variierte von 24 bis 35 Jahren. Das Durchschnittalter lag bei 28,8 Jah-
ren.
• Alle Tester wiesen eine höhere Ausbildung vor. Fünf Teilnehmer besaßen einen
Hochschulabschluss (Diplom, Bachelor oder Master). Die verbleibenden drei
3.1 Planung des Nutzertests
52
Tester befanden sich noch im Studium, strebten demnach einen Hochschulab-
schluss an.
• Die Mehrzahl der Tester kam aus einem technischen Umfeld (Informatik, Tele-
kommunikation, Maschinenbau, Wirtschaftsingenieurwesen und Elektrotech-
nik). Die nicht-technischen Bereiche wurden jeweils durch eine Person aus dem
Umfeld Unternehmensberatung sowie Logopädie vertreten.
• Bis auf eine Ausnahme haben alle Tester bereits ein Nokia-Handy benutzt.
• Alle Tester nutzten das Internet per PC oder Laptop.
• Es wurden insgesamt sechs Anfänger und zwei fortgeschrittene Nutzer des mo-
bilen Internets getestet.
• Einer der fortgeschrittenen Nutzer arbeitete seit über einem Jahr mit dem mobi-
len Internet, der andere seit circa einem halben Jahr. Die Nutzungsintensität va-
riierte von monatlich bis selten.
• Einer der fortgeschrittenen Nutzer benutzte hauptsächlich den Nokia-
Standardbrowser in der Version S40 zum Surfen im mobilen Internet und der
andere versierte Nutzer verwendete den T-Mobile-Standardbrowser.
Auf die geringen Unterschiede zwischen den geplanten Testnutzern und den tatsächli-
chen Testteilnehmern wird im Abschnitt „3.3.2 Schwierigkeiten bei der Testdurchfüh-
rung“ eingegangen.
3.1.3 Aufgabengestaltung
Wie bereits in Abschnitt „2.2.1 Nutzertest“ beschrieben, nimmt die Aufgabengestaltung
in einem Nutzertest eine wichtige Rolle ein. Mithilfe der Task-Analyse wurden typische
Verwendungsmöglichkeiten des mobilen Internets identifiziert und bereits in Abschnitt
„1.5 Verwendungsmöglichkeiten“ beschrieben. In der Abbildung 3-2 (linke Spalte) sind
die fünf interessantesten Nutzungsmöglichkeiten aus einer Umfrage von BITKOM und
Forsa nochmals grafisch dargestellt.
3.1 Planung des Nutzertests
53
Abbildung 3-2: Verwendungsmöglichkeiten des mobilen Internets [www09]
Die Studie „MobileWeb Metrix“ kommt für den englischen und amerikanischen Raum
zu einem ähnlichen Ergebnis. Dort wird die Liste der meistbesuchtesten Webseiten im
mobilen Internet von Nachrichtenseiten (BBC, SKY), Suchdiensten (Google, Yahoo!)
und Wetterdiensten (The Weather Channel) angeführt [www23].
Um den Nutzertest unter möglichst realen Bedingungen durchzuführen, wurden bei der
Gestaltung der Testaufgaben diese typischen Nutzungen mit einbezogen, z.B. indem die
Nutzer sich eine Fahrplanauskunft geben lassen oder eine Nachrichtenseite besuchen.
Zusätzlich zu den identifizierten Verwendungsmöglichkeiten wurde eine Analyse der
Funktionen von Handybrowsern vorgenommen. Diese Analyse umfasste eine Internet-
recherche bei den Browserherstellern, Gespräche mit Nutzern von Handybrowsern so-
wie die direkte Untersuchung eines Handybrowsers selbst. Das Ergebnis war eine Fülle
an verschiedenen Funktionen, die anschließend nach der Nutzungshäufigkeit sortiert
wurden (vgl. Leitfrage 3 der Task-Analyse). Das bedeutet, jeder Funktion wurde eine
Priorität zwischen 1 (oft genutzt, Routineaufgabe) und 3 (selten genutzt) zugewiesen.
Einen Auszug der Priorisierung zeigt die Tabelle 3-2.
3.1 Planung des Nutzertests
54
Tabelle 3-1: Priorisierung der Browserfunktionen (Auszug)
Funktion Priorität
Webseite darstellen (Text, Bilder ...) 1
Formular ausfüllen 1
Formular abschicken 1
Vertikal scrollen 1
Links aufrufen/verfolgen 1
Daten downloaden (Bild, ...) 2
Synchronisation mit PC-Browser 2
Zurück blättern (letzte Seite aufrufen) 1
... ...
Anschließend wurden die Funktionen auf ihre Relevanz hinsichtlich eines Nutzertests
überprüft. Das heißt, bei jeder Funktion wurde hinterfragt, ob es sinnvoll ist diese in
einem Nutzertest zu überprüfen oder ob es nicht besser ist diese nur in der ergänzenden
Experteninspektion zu testen. Als Beispiel sei hier die Fehlerbehandlung beim Aufruf
von nicht vorhandenen Webseiten genannt. Diese Funktion wird normalerweise eher
selten benötigt (= Priorität 3). Zusätzlich würde das bewusste Aufrufen einer nicht exis-
tierenden Webseite beim Testnutzer zu Enttäuschung führen. Spätestens beim nochma-
ligen Ausführen der Aufgabe beim zweiten Browser würde der Tester den Sinn der
Aufgabe hinterfragen, da er das Ergebnis (Webseite existiert nicht) bereits kennt.
Einige Browserfunktionen existieren nicht bei allen Browsermodellen, z.B. URL einer
Webseite per SMS verschicken. Diese Funktion bietet nur der Nokia-Browser an. Da es
sich um eine sinnvolle Verknüpfung von mobilen Internet und Handy handelt, erschien
diese Funktion so interessant, dass sie auf ihre Benutzerfreundlichkeit überprüft werden
sollte. Dieser Spezialfall trat noch mehrmals auf. In der anschließenden Auswertung
wurden diese einzeln auftretenden Funktionen jedoch wie jede andere auch behandelt.
Aus der Vielzahl an Browserfunktionen wurden dann insgesamt 21 Funktionen für die
Überprüfung mittels Aufgaben im Nutzertest ausgewählt.
3.1 Planung des Nutzertests
55
Es wurden bewusst keine technischen Spezifikationen wie Flash-Unterstützung oder
ähnliches untersucht, sondern die Hauptaufgaben eines Browsers während der Nutzung
(Navigieren, Formulare ausfüllen, Lesezeichen aufrufen, etc.) getestet.
Bei der Auswahl der Webseiten für den Nutzertest wurde versucht, möglichst bekannte
Webseiten zu wählen. Ziel dabei war, dass die Navigation innerhalb der Webseiten be-
kannt ist und somit fast keinen Einfluss auf den Usabilitytest hat. Weiterhin lag der Fo-
kus auf der Verwendung von mobilen Seiten. Erstens sind diese kleiner und haben da-
mit geringe Ladezeiten. Zweitens sind mobile Webseiten gezielt für die mobile Brow-
serdarstellung optimiert. Es wurde versucht, mit kurzen URLs und soweit möglich mit
Lesezeichen zu arbeiten, da die Eingabe sehr umständlich ist und der Nutzertest so kurz
wie möglich sein sollte. Um die Vergleichbarkeit der Ergebnisse bei der Auswertung zu
sichern, wurde darauf verzichtet, dass die Nutzer sich die Webseiten selbst auswählen
konnten.
Die Aufgaben wurden so gestaltet, dass mittels einer Aufgabe möglichst viele Funktio-
nen des Browsers getestet werden konnten (vgl. Tabelle 3-2, Aufgabe 2: Lesezeichen
aufrufen, Formulareingabe, navigieren, zurück blättern, ...). Zusätzliches Ziel dabei war
es, soweit wie möglich unnötige Zwischenschritte für den Nutzer zu vermeiden.
Für das Testen der Formulareingabe wurden kurze Daten ausgewählt, damit die Eingabe
so wenig Zeit wie möglich in Anspruch nimmt. Die Reihenfolge der Aufgaben wurde so
bestimmt, dass Funktionen, die eine hohe Priorität besitzen und damit sehr oft genutzt
werden, am Anfang getestet wurden. Denn die Aufmerksamkeit des Nutzers ist zu Be-
ginn eines Tests sehr hoch. Die Aufgabenbeschreibung wurde präzise, aber knapp
gehalten. Der Nutzer sollte genau wissen, was er tun soll, ohne abgelenkt zu werden.
In der folgenden Übersicht werden alle Aufgaben sowie deren Zweck im Nutzertest
aufgelistet:
Tabelle 3-2: Aufgaben des Nutzertests inklusive Zweck
Nr. Beschreibung Zweck
Aufgabe 1: Webseite aufrufen und Bild speichern
1.1 Starte den Handybrowser! leichte Einstiegsaufgabe
3.1 Planung des Nutzertests
56
Nr. Beschreibung Zweck
1.2 Rufe die Internetadresse „ama-zon.de“ auf!
Findet der Nutzer intuitiv ein Feld bzw. eine Funktion zur URL-Eingabe im Handybrowser?
1.3 Suche ein Buch mit den folgenden Suchwörtern „Welt retten“!
Die Nutzer sollen die Formulareingabe testen.
1.4 Öffne das Buch von Christian Berg!
Die Navigation durch Hyperlinks soll überprüft werden.
1.5 Lass dir anschließend das Buch-cover in voller Größe anzeigen!
Die Navigation durch Hyperlinks wird ein weiteres Mal über-prüft.
1.6 Speichere das Bild auf deinem Handy im Ordner „Fotos“! (nur bei Nokia sowie Opera Mini, TeaShark unterstützt diese Funk-tion nicht)
Es soll überprüft werden, wie die Download-Funktionalität (speziell bei Bildern) vom Browser umgesetzt wird. Findet der Nutzer intuitiv den richtigen Menüpunkt? Kann er das Bild im Ordner „Fotos“ speichern?
Aufgabe 2: Navigieren und Formularbedienung
2.1 Bitte ruf das Lesezeichen „Bahn Auskunft“ auf!
Es soll überprüft werden, ob der Nutzer Lesezeichen einfach aufrufen kann. Findet er direkt den richtigen Menüpunkt dafür?
2.2 Finde eine Bahnverbindung, die von Aachen („AC“) nach Bonn („BN“) am 15.3. ab 14 Uhr fährt!
Hier soll noch einmal die Eingabe in Formulare getestet wer-den; diesmal jedoch mit mehreren Eingabefeldern.
2.3 Blättere zurück! Finde heraus, wie viel eine Verbindung kostet, wenn man eine BahnCard50, 2. Klasse hat!
Die Aufgabe soll testen, ob die Nutzer intuitiv einen Weg fin-den um zurück zu blättern.
2.4 Verschicke die URL der Verbin-dung per SMS an die Telefon-nummer 0160 5707688! (nur bei Nokia, TeaShark und Opera Mini unterstützen diese Funktion nicht)
Hier soll überprüft werden, ob die Funktion für das Verschicken der URL schnell gefunden wird. Bei richtiger Ausführung wird die SMS an das Handy des Beobachters geschickt und der Test-nutzer erhält ein akustisches Erfolgserlebnis, welches ihn zur weiteren Durchführung motiviert.
Aufgabe 3: Lesezeichen
3.1 Ruf bitte die Nachrichtenseite „spiegel.mobi“ auf und leg dafür ein Lesezeichen an!
Findet der Nutzer eine der verschiedenen Menüfunktionen um ein Lesezeichen anzulegen?
3.2 Leg jetzt bitte einen Lesezeichen-Ordner „News“ an! (nur bei Nokia, TeaShark und Opera Mini unterstützen diese Funktion nicht)
Mit dieser Aufgabe soll überprüft werden, ob der Nutzer ohne Schwierigkeiten einen neuen Lesezeichen-Ordner anlegen kann.
3.1 Planung des Nutzertests
57
Nr. Beschreibung Zweck
3.3 Verschiebe das Spiegel-Lesezeichen in den „News“-Ordner! (Nokia)
bzw.
Verschiebe das Spiegel-Lesezeichen um einen Punkt nach oben in der Lesezeichen-Liste! (alternativ für TeaShark und Opera Mini)
Kann der Nutzer das eben angelegte Lesezeichen einfach in einen Unterordner verschieben?
bzw.
Kann er es alternativ in der Liste nach oben verschieben?
Aufgabe 4: Schrift vergrößern und Suchen
4.1 Geh zurück auf die Spiegel-Seite und klicke auf den ersten Artikel!
Zwischenschritt um sich wieder auf einer Webseite zu befinden sowie Überprüfung der Navigation mit Hyperlinks
4.2 Vergrößere die Schriftart um den Text besser lesen zu können! (nur bei Nokia sowie Opera Mini, TeaShark unterstützt diese Funk-tion nicht)
Es soll getestet werden, ob die Einstellung zum Vergrößern der Schriftart auf Anhieb gefunden wird.
4.3 Lade die Seite neu! Die Funktion zum Aktualisieren von Webseiten soll überprüft werden. Findet der Nutzer einen passenden Menüpunkt?
4.4 Klicke auf den Link „Impressum“ unten auf der Seite! (nur für den TeaShark benötigt, s. 4.5)
Zwischenschritt um in den Bereich Impressum zu gelangen, da dieser Bereich auf Internetseiten selten geändert wird. Ziel der nächsten Aufgabe ist das Auffinden des Begriffes „Kultur“ und die Wahrscheinlichkeit, dass im Laufe der gesamten Testdurch-führung dieser Begriff aus dem Impressum der Webseite ver-schwindet, ist sehr gering.
4.5 Zoome rein und suche mit der Suchfunktion des Browsers das Wort „Kultur“! (nur bei TeaShark, Nokia und Opera Mini unterstützen diese Funktion nicht)
Mit dieser Aufgabe wird überprüft, ob die Suchfunktion des Browsers einfach gefunden und ebenso leicht bedient werden kann.
Aufgabe 5: Interaktion mit Handyanwendungen
5.1 Öffne das Lesezeichen „private Homepage“! (nur bei Nokia und Opera Mini benötigt, s. 5.2)
Zwischenschritt um auf eine speziell für den Nutzertest angeleg-te Webseite4 zu gelangen
5.2 Dort findest du eine Telefon-nummer. Ruf diese Telefonnum-mer an! (nur bei Nokia sowie Opera Mini, TeaShark unterstützt diese Funk-tion nicht)
Hier soll getestet werden, ob der Nutzer eine Möglichkeit fin-det, nur mithilfe des Browsers eine Telefonnummer auf einer Webseite anzurufen. Bei korrekter Ausführung ruft der Tester auf dem Handy des Testleiters an und erhält ein akustisches Erfolgserlebnis, welches ihn zur weiteren Durchführung moti-viert.
4 Auf der Webseite steht eine Telefonnummer, die zum Handy des Testleiters führt.
3.1 Planung des Nutzertests
58
Nr. Beschreibung Zweck
Aufgabe 6: Verlauf
6.1 Nutze die Verlaufsfunktion um auf die Hauptseite „amazon.de“ zurück zu kehren!
Mit dieser Aufgabe wird die Verlaufsfunktion des Browsers getestet. Findet der Nutzer einen schnellen Weg zurück zu sei-ner ersten aufgerufenen Seite? Kann er die Funktion intuitiv bedienen?
6.2 Als nächstes testen wir die Funk-tion „Abbrechen“: Klicke auf den Link „Hilfe?“ am Seitenende und brich den Ladevorgang direkt wieder ab!
Hier soll überprüft werden, ob der Nutzer ohne Schwierigkeiten eine Möglichkeit findet, um den Ladevorgang einer Webseite abzubrechen.
6.3 Bitte lösche zum Schluss noch den Lesezeichen-Ordner „News“! (Nokia)
bzw.
Bitte lösche zum Schluss noch das von dir angelegte Lesezeichen der Spiegel-Seite! (alternativ für TeaShark und Opera Mini)
Diese Aufgabe dient zur Überprüfung, ob der Nutzer eine Funk-tion zum Löschen seines angelegten Lesezeichen-Ordner ohne Probleme findet
bzw.
ob er das Lesezeichen wieder löschen kann.
6.4 Beende den Browser! Zum Abschluss noch eine leichte Aufgabe, damit der Nutzer den Test mit einem Erfolgserlebnis beenden kann. Gleichzeitig wird überprüft, ob die Funktion zum Verlassen des Browsers auf Anhieb gefunden wird.
Den Testnutzern wurde bewusst kein Zeitlimit für die Aufgabenbewältigung vorgege-
ben, damit alle Aufgaben gelöst und keine Frustration auftreten konnte. Für sehr hartnä-
ckige Nutzer, die bei einer schwierigen Aufgabe eventuell nicht aufgeben wollen und
deshalb viel Zeit benötigen, wurde mit dem Moderator vereinbart, dass dieser dann im
Notfall abbricht, um den Testzeitplan nicht zu gefährden.
Dieser Abschnitt befasste sich mit der wichtigen Planungsphase zur Auswahl und Ges-
taltung der Aufgaben des Nutzertests. Die nachstehenden Abschnitte beschreiben die
weiteren Planungsschritte bevor die Evaluation durch die Nutzer beginnen kann.
3.1.4 Testumgebung
Ziel dieses Nutzertests war das Auffinden von generellen Bedienproblemen. Die Über-
prüfung der Anwendung in einer mobilen Situation, z.B. Spazieren gehen, stand dabei
nicht im Vordergrund. Daher wurde als Testumgebung eine laborähnliche Atmosphäre
in einem ruhigen Raum gewählt. Denn, wie bereits beschrieben, können durch einen
3.1 Planung des Nutzertests
59
stationären Test mehr Usability-Probleme als bei einem mobilem Test aufgedeckt wer-
den. Durch die unveränderliche Testumgebung wurde auch die Beobachtung und Auf-
zeichnung des Nutzerverhaltens vereinfacht.
Die Tests wurden in einem Büroraum bei der P3 Solutions GmbH in Aachen durchge-
führt (Abbildung 3-3). Der Raum war ruhig, hell und ohne große Ablenkungsmöglich-
keiten durch Bilder oder ähnliches. Zusätzlich wurde versucht durch das Anbieten von
Getränken und Snacks eine angenehme Atmosphäre zu schaffen.
Abbildung 3-3: Testraum bei P3 Solutions
3.1.5 Handymodell
Bei der Auswahl eines Testgeräts für den Nutzertest wurde nur der Bereich der Handys
betrachtet. Das heißt Smartphones oder PDAs waren nicht relevant. Der Hauptgrund,
warum in dieser Untersuchung auf Smartphones verzichtet wurde, liegt in deren erwei-
terter Funktionalität. Smartphones besitzen ein leistungsstärkeres Betriebssystem als
normale Handys und erlauben damit die Installation von weiteren Anwendungen. Im
Gegensatz dazu verfügen einfache Handys nur über eine vordefinierte Programmober-
fläche, welche keine Installation von fremden Applikationen unterstützt. Sie lassen sich
nur durch javabasierte Anwendungen erweitern.
Durch die Verwendung eines Handys in diesem Test soll die Usability des vorhandenen
Standardbrowsers bzw. der wenigen existierenden, javabasierten Browser getestet wer-
3.1 Planung des Nutzertests
60
den. Das Augenmerk dieser Untersuchung richtete sich auf „Otto-Normalverbraucher“,
die kein Smartphone nutzen und damit auch nur bedingt die Möglichkeit haben über
einen alternativen Browser im mobilen Internet zu surfen.
Als Handymodell wurde das Nokia 6500 slide (Abbildung 3-4) benutzt. Dieses Telefon
zählt zu den Handys. Zusätzlich wurde darauf geachtet, dass keine QWERTZ-Tastatur
vorhanden ist, da die meisten Handys eine Standardtastatur besitzen, welche eine um-
ständlichere Texteingabe verlangt.
Abbildung 3-4: Testhandy Nokia 6500 slide
Eine Übersicht der technischen Daten des Nokia 6500 slide ist hier aufgelistet:
• Displaygröße: 240x320 Pixel
• 5-Wege Navigationsbutton
• zwei Softkeys (obere blaue Tasten)
• unterstützt WAP 2.0, XHTML, WML 2.0 und Java
• Betriebssystem: proprietär (Series 40, 5th edition)
• ungebrandet5, da nur in dieser Version der original Nokia-Browser vorhanden ist
Die Entscheidung für ein einziges Handymodell wurde bewusst unter dem Aspekt ge-
wählt, dass die Handybedienung keinen Einfluss auf die Testergebnisse haben soll und
5 d.h. ohne vorm Verkauf vom Netzbetreiber verändert worden zu sein, vgl. Abschnitt „3.1.6 Browser“
3.1 Planung des Nutzertests
61
alle Browser unter den gleichen Bedingungen getestet werden können. Einer der zu tes-
tenden Browser sollte der proprietäre Nokia-Browser sein, daher musste das Handymo-
dell von diesem Hersteller stammen.
Zur Übertragung wurde das Mobilfunknetz von Vodafone gewählt, da Vodafone als
einer der Marktführer gilt und damit eine gute Datenübertragung sichergestellt ist.
GPRS wurde als Übertragungsstandard benutzt. Da für den Nutzertest eine ständige
Internetverbindung erforderlich ist, sind die Reaktionszeiten des Browsers von der Ge-
schwindigkeit des Vodafone-Netzes abhängig.
3.1.6 Browser
Bei der Vielzahl an vorhandenen Browsern für Mobiltelefone musste eine Auswahl für
die Evaluation getroffen werden. Durch die Beschränkung auf Handys fiel direkt ein
Großteil der mobilen Browser aus der Auswahl, da viele Browser nur auf Smartphones
lauffähig sind. Daher reduzierte sich die Auswahl auf die vorinstallierten Standardbrow-
ser der Hersteller (Nokia, SonyEricsson, ...) bzw. Netzbetreiber (T-Mobile, Vodafo-
ne, ...) sowie die freien, javabasierten Browser.
Das Angebot an vorinstallierten Standardbrowsern ist hersteller- bzw. netzbetreiberab-
hängig. Die Zuordnung zwischen Browser und Handyhersteller ist jedoch nicht immer
eindeutig, da dies teilweise modellabhängig ist. Die nachfolgende Übersicht gibt des-
halb nur einen groben Überblick. Nach Herstellern sortiert hat man die Wahl zwischen
folgenden Handybrowsern: Nokia (Nokia Series 40), SonyEricsson und Samsung (Ac-
cess NetFront), Motorola (Obigo Browser), LG und Sagem (beide Openwave). Die mei-
sten Handyhersteller entwickeln ihre Browser demnach nicht selbst, sondern kaufen die
Applikation bei großen Browserentwicklern ein.
Anschließend werden die verschiedenen Netzbetreiber betrachtet. In Deutschland exis-
tieren vier Mobilfunkbetreiber, nämlich T-Mobile, Vodafone, E-Plus und O2. Die Netz-
betreiber verkaufen „gebrandete“ Handys, das heißt diese Modelle haben zusätzliche
beziehungsweise weniger Funktionen als das Originalmodell. Die Anpassung erfolgt in
Zusammenarbeit zwischen Hersteller und Netzbetreiber, z.B. Nokia und T-Mobile. Ein
3.1 Planung des Nutzertests
62
gebrandetes Handy erkennt man oft am Logo-Aufdruck des Netzbetreibers auf dem
Modell (Abbildung 3-5), daher stammt auch der Ausdruck „gebrandet“.
Häufig werden gebrandete Handys mit (teuren) Zusatzdiensten versehen, die mit einem
Tastendruck aktiviert werden. Als Beispiel sei der „Live!“-Button von Vodafone ge-
nannt, welcher direkt das Vodafone-WAP-Portal öffnet. Beim Branding durch den
Netzbetreiber wird meist auch der Browser angepasst. Entweder der Netzbetreiber
tauscht den Originalbrowser durch seinen eigenen Browser aus (z.B. Vodafone) oder
der Hersteller modifiziert seinen Browser in Design und Funktion je nach Wunsch des
Netzbetreibers. In der Abbildung 3-5 kann man sehr gut erkennen, dass unter dem
web’n’walk-Browser von T-Mobile eigentlich der Opera Mini (Abbildung 3-6) steckt.
Nur das Design wurde von T-Mobile verändert.
Abbildung 3-5: Web'n'walk-Browser von T-Mobile mit Opera Mini als Basis [www24]
Abbildung 3-6: Opera Mini-Browser im Original
Nokia ist einer der führenden Hersteller auf dem Mobilfunkmarkt. Laut Kiljander [Kil-
jander2003] ist etwa jedes zweite von fünf verkauften Mobiltelefonen ein Nokia-Handy.
Zusätzlich gilt der finnische Handyhersteller als Vorreiter beim Thema Usability und
bestätigt dies durch die Veröffentlichung des interessanten Buchs „Mobile Usability –
How Nokia changed the face of the mobile phone“. Laut den Autoren wird die Usability
jedoch selten als marketingtechnisches Verkaufsargument von Nokia aus genannt.
Vielmehr legt der Hersteller Wert auf Mund-zu-Mund-Propaganda, um seine Glaub-
3.1 Planung des Nutzertests
63
würdigkeit in Sachen Benutzerfreundlichkeit zu sichern [Lindholm2003]. Um die Vor-
reiterrolle von Nokia im Bereich Usability zu überprüfen, sollte daher der Nokia Series
40 Standardbrowser evaluiert werden.
Es gibt diverse freie Handybrowser. Der NetFront Browser von Access zum Beispiel
existiert als vorinstallierter Browser auf Handys von SonyEricsson und als freie Version
zum Download, allerdings nur für Smartphones. Da die zu testenden Browser auf einem
Nokia-Handy funktionieren mussten, kam der NetFront Browser nicht in Frage. Die
Auswahl beschränkte sich demnach auf javabasierte Browser, die auf dem Nokia-Handy
installiert werden konnten.
Der Opera Mini vom Browserhersteller Opera Software ist laut aktuellen Downloadzah-
len mit über 40 Millionen Downloads einer der beliebtesten Handybrowser im Bereich
der frei verfügbaren Programme [www25]. Durch eine Evaluation dieses Browsers soll
untersucht werden, ob die hohen Downloadzahlen sich eventuell auf die gute Usability
zurückführen lassen.
Als dritter im Bunde soll ein weiterer javabasierter Browser getestet werden um zu ü-
berprüfen, ob alternativ angebotene Browser im Gegensatz zu dem vorinstallierten
Standardbrowser besser zu bedienen sind. Für einen Nutzer ist der Umstieg auf einen
freien Browser mit Arbeit verbunden. Deshalb soll mit dieser Diplomarbeit überprüft
werden, ob die Usability freier Browser höher als bei einem Standardbrowser ist und ob
sich damit der Umstieg rentiert.
Ein javabasierter Browser heißt TeaShark. Alternativ stand noch der Browser WebVie-
wer der Firma Reqwireless zur Auswahl. Allerdings wurde der Hersteller im Jahr 2005
von Google übernommen und seitdem wurde der Browser nicht mehr weiterentwickelt.
Da in dieser Untersuchung mit aktuellen Daten gearbeitet werden sollte, fiel die Ent-
scheidung für den dritten Handybrowser im Test auf den aktuellen TeaShark-Browser.
In den folgenden Abschnitten werden die drei ausgewählten Handybrowser näher be-
schrieben.
3.1 Planung des Nutzertests
64
3.1.6.1 Nokia-Browser
Der Nokia-Browser kann sowohl WAP als auch XHTML-Seiten darstellen. Der Brow-
ser wird umgangssprachlich als „S40-Browser“ bezeichnet. Dies rührt daher, dass er auf
allen Nokia-Handys der Serie 40 standardmäßig installiert ist. Dies war bei dem Test-
handy Nokia 6500 slide ebenso der Fall.
3.1.6.2 Opera Mini-Browser
Der Opera Mini entstand im Jahr 2005 als mobiler Ableger des PC-Browsers Opera.
Ursprünglich diente er dazu einen Internetzugang für Handys, auf denen normalerweise
keine Browseranwendung vorhanden ist, zu ermöglichen [www08]. Dies war nur durch
die spezielle Funktionsweise des Opera Mini möglich, die im Folgenden beschrieben
wird.
Die Verbindung ins Internet führt der Opera Mini über einen Proxyserver. Bevor die
Daten zum Handy zurück gelangen, werden sie auf einem Proxyserver von Opera bear-
beitet. Der HTML-Code wird komprimiert und Bilder werden auf eine frei wählbare
Auflösung heruntergerechnet. Durch dieses Rendering kann die übertragene Datenmen-
ge um etwa 20 Prozent verringert werden. Damit ist eine schnellere und somit kosten-
günstigere Übertragung möglich. Zusätzlich wird durch das sogenannte Small Screen
Rendering die Webseite automatisch an die Größe des Handydisplays angepasst
(Abbildung 3-7).
Abbildung 3-7: Funktionsweise des Opera Mini über einen Proxyserver [www26]
3.1 Planung des Nutzertests
65
Der Opera Mini läuft auf jedem Mobiltelefon, welches JAVA ME6 unterstützt. Das
heißt, der Browser kann auf fast allen Handys, die nicht älter als zwei Jahre sind, instal-
liert werden. Im Internet kann man den Browser kostenfrei unter www.operamini.com
herunterladen. Zum Testzeitpunkt im März 2008 existiert der Opera Mini in der Versi-
on 4.0 und wurde daher in dieser Version für den Nutzertest verwendet.
3.1.6.3 TeaShark-Browser
Der freie Browser TeaShark funktioniert ähnlich wie der Opera Mini, indem er Bilder
und HTML-Code vor der Anzeige auf dem Handydisplay auf einem eigenen Proxyser-
ver komprimiert. Unter anderem durch diese Ähnlichkeit wird er als direkter Konkur-
rent zum Opera Mini betrachtet.
Der TeaShark läuft ebenso auf jedem Mobiltelefon, welches JAVA ME unterstützt, und
steht im Internet gratis unter www.teashark.com zum Download bereit. Aktuell ist nur
eine englische Sprachversion verfügbar, was für die Nutzer aufgrund ihres Bildungs-
stands jedoch kein Problem darstellte.
Für die Evaluation stand die Version alpha 0.8 des TeaShark zur Verfügung. Da mehre-
re Tests im Internet, z.B. der Zeitschrift connect7, die Stabilität dieser Entwicklungsver-
sion bestätigten, bestanden keine Bedenken für den Nutzertest.
3.1.7 Pilottest
Ein Nutzertest ist sehr aufwändig und daher umständlich zu wiederholen, falls Probleme
jeglicher Art auftreten. Um dieses Risiko zu minimieren und eine erfolgreiche Test-
durchführung zu gewährleisten, fand einige Tage vor dem eigentlichen Test ein Pilottest
statt. Der gesamte Nutzertest wurde in voller Länge durchgeführt und per Kamera auf-
gezeichnet. Bei diesem Pilottest agierte der spätere Moderator als Testnutzer und das
gesamte Testsetup wurde auf Verständnis- sowie Technikprobleme überprüft. Gleich-
zeitig konnte der Moderator in der Testerrolle die Methode des lauten Denkens selbst
ausprobieren und sich damit vertraut machen. Zusätzlich konnte er seine späteren Auf-
gaben als Moderator beobachten und erlernen.
6 spezielle Umsetzung der Programmiersprache Java für mobile Endgeräte 7 abrufbar unter: http://www.connect.de/themen_spezial/Teashark_554912.html
3.2 Durchführung des Nutzertests
66
Der Pilottest erwies sich aus mehreren Gründen als sinnvoll. Erstens konnten kleinere
Probleme bei der Kameraaufnahme erkannt und beseitigt werden. Zweitens konnten
bereits häufige Usability-Probleme identifiziert werden, sodass daraus Checkboxen mit
typischen Problemen für den Notizvordruck des Beobachters (Anhang A) erstellt wer-
den konnten. Drittens konnte durch den Pilottest eine Gesamtzeit pro Testperson von
zwei Stunden ermittelt und damit eingeplant werden. Schließlich zeigte sich, dass die
Aufgabenbeschreibung durch kleine Verbesserungen noch verständlicher und einfacher
werden konnte (Ordner „News“ anstatt „Nachrichten“, Eingabe der Daten zur Bahnver-
bindung an Reihenfolge des Bahn-Formulars anpassen, Funktion „Abbrechen“ um Ein-
leitung ergänzen). Nachdem alle Verbesserungen eingearbeitet und das Testsetup nach-
justiert wurde, konnte eine Woche später der Nutzertest starten.
3.2 Durchführung des Nutzertests
Der Nutzertest wurde vom 10.-14. März 2008 in den Räumlichkeiten der P3 Solutions
GmbH in Aachen durchgeführt. Auf dem Nokia Handy 6500 slide wurden drei Handy-
browser getestet: der proprietäre Standardbrowser von Nokia und die beiden freien
Browser Opera Mini und TeaShark – jeweils in der aktuell verfügbaren Version. Inge-
samt testete jeder der acht Nutzer die verschiedenen Browser. Pro Tester dauerte die
Evaluation etwa zwei Stunden. Es wurden Videoaufnahmen von jedem Test angefertigt,
wobei aus Gründen des Datenschutzes darauf geachtet wurde, dass nur das Handydis-
play abgefilmt wurde.
3.2 Durchführung des Nutzertests
67
Es gab einen Moderator (links in Abbildung 3-8) und ich als Testleiter nahm die Beob-
achterrolle ein (in der Bildmitte). Der Moderator saß dem Nutzer (rechts im Bild) ge-
genüber und der Beobachter saß an der Seite.
Abbildung 3-8: Testsetup während der Durchführung
Vor dem Test wurde jedem Testnutzer mithilfe des Begleitskripts (Anhang A) das Ziel
der Untersuchung sowie der Ablauf der Evaluation erklärt. Der Moderator wies beson-
ders darauf hin, dass die Anwendung und nicht der Nutzer getestet wird. Es wurde das
Einverständnis des Testers zu Video- und Fotoaufnahmen eingeholt und anschließend
musste er eine Einstiegsübung zur Vorbereitung absolvieren. Bei dieser Übung wurden
alle Testaufgaben probeweise mit dem Firefox-Browser an einem Laptop durchgeführt.
Dadurch hatte der Tester die Möglichkeit, etwaige Verständnisfragen zur Aufgabenstel-
lung zu klären. Gleichzeitig konnte er sich mit den späteren Webseiten und der Methode
des lauten Denkens vertraut machen. Während der Einstiegsübung durfte der Moderator
auch Hinweise oder Feedback geben, z.B. zur Umsetzung der Think Aloud-Methode.
Bevor der erste Browsertest startete, hatte der Tester noch Zeit sich mit der Bedienung
des Testhandys vertraut zu machen, damit Bedienungsprobleme durch das Mobiltelefon
vermieden werden konnten.
Anschließend bat der Moderator den Testnutzer, die definierten Aufgaben mit dem
Handybrowser zu erledigen. Parallel dazu sollte der Tester mit der Methode des lauten
Denkens kommentieren, was er tut und warum er so handelt. Der Moderator hat den
Tester regelmäßig mit Zwischenfragen aus dem Begleitskript an dieses Verfahren erin-
nert, sollte der Testnutzer dieses nicht konsequent angewendet haben. Besonderheiten
3.2 Durchführung des Nutzertests
68
im Vorgehen (Abbruch der Aufgabe, nicht erfüllte Erwartung des Nutzers, ...) sowie
interessante Kommentare der Testnutzer wurden vom Beobachter notiert. Diese Auf-
zeichnungen dienten als Ausgangspunkt für die spätere Auswertung.
Im Anschluss an den ersten Browsertest wurde der Browser mithilfe eines Bewertungs-
bogens (Anhang B) durch den Tester evaluiert. Dabei hatte der Tester die Möglichkeit,
zusammenfassend zu beschreiben, was ihn beim Umgang mit dem Browser gestört hat
(„Gab es unklare Begriffe? Fehlten dir Informationen?“) sowie was ihm positiv aufge-
fallen ist („Was hat dir am meisten gefallen?“). Nachdem die Bewertung abgeschlossen
war, wurde der gesamte Test mit den beiden anderen Browsern wiederholt.
Zum Abschluss des Nutzertests wurde der Tester gebeten, auf einem Fragebogen Anga-
ben zu seiner Person zu machen (Anhang A). Dies erfolgte unter dem Hinweis, dass die
Daten nur anonymisiert verwendet werden. Daraufhin erhielt der Tester ein kleines In-
centive, wurde verabschiedet und das Testsetup wurde für den nächsten Testnutzer vor-
bereitet.
Das gesamte Testverfahren wurde weitere sieben Mal wiederholt, wobei jeweils alle
drei Browser jedoch in verschiedener Reihenfolge getestet wurden. Durch eine wech-
selnde Browserreihenfolge je Testperson sollte vermieden werden, dass sich Lerneffek-
te zwischen den einzelnen Browsern im Gesamtergebnis widerspiegeln. Die Verteilung
der Reihenfolge (Tabelle 3-3) wurde möglichst ausgewogen nach Nutzungsstatus und
Geschlecht gestaltet.
Tabelle 3-3: Verteilung der Browserreihenfolge auf die Testnutzer
Nr. Nutzungsstatus Geschlecht Browser 1 Browser 2 Browser 3
1 Anfänger männlich Nokia TeaShark Opera
2 Anfänger männlich Opera Nokia TeaShark
3 Anfänger weiblich Opera TeaShark Nokia
4 Anfänger männlich TeaShark Opera Nokia
5 Anfänger männlich TeaShark Nokia Opera
6 Anfänger weiblich TeaShark Nokia Opera
3.2 Durchführung des Nutzertests
69
Nr. Nutzungsstatus Geschlecht Browser 1 Browser 2 Browser 3
7 Fortgeschrittener weiblich Nokia Opera TeaShark
8 Fortgeschrittener männlich Opera TeaShark Nokia
Jeder Test wurde mit einer handelsüblichen Videokamera digital mithilfe des Pro-
gramms iMovie auf einem Laptop aufgezeichnet. Dadurch konnte man als Beobachter
direkt auf dem Laptop das Geschehen innerhalb des Handydisplays mitverfolgen. Da
nur das Handydisplay gefilmt wurde, wurden die Tester aufgefordert, dass Handy nur in
einem markierten Bereich zu benutzen, was aber keine Schwierigkeit darstellte.
Abbildung 3-9: Aufzeichnung des Tests per Videokamera
Durch die laute Artikulation der Gedanken und Intentionen durch die Testperson war es
für den Beobachter möglich, die Interaktion mit dem Handybrowser genau zu analysie-
ren und festzustellen, wann die Erwartungen des Nutzers erfüllt wurden und wo Prob-
leme auftraten. Zur näheren Erläuterung wird das ganze am Beispiel der Bedienstrate-
gien des Browsers erklärt. Jeder Nutzer verfolgt im Kopf eine bestimmte Bedienstrate-
gie. Jeder Browser bietet eine Vielzahl an Bedienstrategien an, z.B. Menüpunkte oder
Tastaturkürzel (Abbildung 3-10). Durch das laute Denken kann der Beobachter die er-
wartete Strategie mit der tatsächlich vorgefundenen Bedienstrategie vergleichen und
damit herausfinden, welche Strategie der Nutzer wahrgenommen hat.
3.3 Ergebnisse und Auswertung des Nutzertests
70
Abbildung 3-10: Wahrnehmung von Bedienstrategien durch den Nutzer
Generell konnte beobachtet werden, dass die Nutzer sehr unterschiedliche Strategien bei
der Aufgabenbewältigung anwendeten. Einige Tester durchsuchten akribisch das Menü.
Andere Testnutzer probierten verschiedene Punkte mithilfe von Versuch und Irrtum aus.
Zum Beispiel bei der Aufgabe „Browser beenden“ wurden insgesamt drei unterschiedli-
che Strategien festgestellt:
• Einige Tester nutzten mehrmals hintereinander die „Zurück“-Funktion des
Browsers um zum Ausgang zurück zu kehren.
• Andere Testnutzer wussten aus Erfahrung, dass sie durch Betätigen der roten
Hörer-Taste die Anwendung schließen können.
• Die dritte Gruppe durchsuchte das Menü nach einem Punkt mit der Beschriftung
„Exit“ oder „Beenden“.
Die Vielfalt an angebotenen Bedienstrategien zeigt, dass die Browserentwickler auf die
Bedürfnisse der Nutzer geachtet haben und diesen Usability-Aspekt bereits gut umset-
zen. Im folgenden Abschnitt werden die weiteren Ergebnisse des Nutzertests noch de-
taillierter vorgestellt.
3.3 Ergebnisse und Auswertung des Nutzertests
Dieser Abschnitt stellt die verschiedenen Ergebnisse des Nutzertests dar. Begonnen
wird mit einem Bericht über die positiven Ergebnisse sowie die Schwierigkeiten bei der
Testdurchführung. Anschließend wird die Strukturierung der gefundenen Ergebnisse
beschrieben. Daraus werden Empfehlungen für die Browsergestaltung abgeleitet. Diese
Empfehlungen werden detailliert vorgestellt bevor die bewährten Browsereigenschaften
3.3 Ergebnisse und Auswertung des Nutzertests
71
erläutert werden. Zum Schluss dieses Abschnitts werden noch Ergebnisse, die unabhän-
gig vom Browsermodell auftraten, erwähnt.
3.3.1 Was lief gut?
Nach jeder gründlichen Nutzerevaluation erfolgt eine Auswertung in Hinblick auf die
Durchführung des Tests. Was ist gut gelaufen? Welche Schwierigkeiten traten auf? Was
sollte beim nächsten Test anders gemacht werden? Nachfolgend werden die positiven
Aspekte der Testdurchführung kurz aufgelistet, bevor anschließend die Schwierigkeiten
aufgezeigt werden.
Bereits während des Pilottests konnten einige Usability-Probleme entdeckt werden, so-
dass sich schon zu diesem Zeitpunkt abzeichnete, dass die Testeranzahl mit acht Perso-
nen ausreichend ist. Dies hat sich auch im Nachhinein bestätigt. Viele Ergebnisse wur-
den durch wiederholtes Auftreten bestätigt. Trotzdem konnten selbst im achten und so-
mit letzten Test noch wertvolle Anregungen gesammelt werden, die vorher noch nicht
auftraten.
Durch die Übungsrunde mit dem Browser am Laptop klärten die Nutzer Verständnis-
probleme mit den Aufgaben und übten gleichzeitig die Methode des lauten Denkens.
Durch die Nutzung der späteren Testwebseiten machten sich die Tester mit den Websei-
ten vertraut und eine spätere Beeinflussung des Tests durch webseitenbedingte Naviga-
tionsprobleme konnte weitestgehend ausgeschlossen werden. Diese Übungsrunde ver-
längerte den Nutzertest. Die Tester konnten sich jedoch dadurch besser auf die eigentli-
che Browserevaluation vorbereiten und insgesamt damit mehr Ergebnisse liefern.
Alle Tester waren schnell mit der Think Aloud-Methode vertraut und mussten nur sehr
selten durch den Moderator daran erinnert werden. Weiterhin waren alle Tester pünkt-
lich und haben die Räumlichkeiten aufgrund der Anreisebeschreibung per E-Mail direkt
gefunden.
Wie bei der Aufgabengestaltung geplant, klingelte bei der erfolgreichen Bewältigung
der Aufgaben 2.4 „URL per SMS verschicken“ und 5.2 „Telefonnummer anrufen per
3.3 Ergebnisse und Auswertung des Nutzertests
72
Klick“ das Handy des Testleiters. Den Testern konnte man die Freude über das Erfolgs-
erlebnis ansehen und sie schritten motiviert zur nächsten Aufgabe.
Durch die Unterstützung eines Moderators konnte sich der Beobachter direkt auf die
Tester und deren Interaktionsverhalten mit den Handybrowsern konzentrieren. Zusätz-
lich hat der Moderator ebenso auf Usability-Probleme geachtet und nach jedem Tester
gab es eine informelle Auswertung zwischen Moderator und Beobachter.
Mithilfe des vorgefertigten Notizvordrucks des Beobachters (Anhang A) konnten häufi-
ge Probleme einfach angekreuzt werden und es blieb mehr Zeit zum Notieren von Be-
sonderheiten oder Zitaten der Testnutzer.
Zwischen dem zweiten und dritten Browsertest war eine kurze Erholungspause für den
Tester eingeplant. Jedoch zogen es fast alle Testnutzer vor, den Test fortzusetzen und
verzichteten auf ihre Pause.
3.3.2 Schwierigkeiten bei der Testdurchführung
Kein Nutzertest läuft perfekt ab. Im Folgenden werden daher Schwierigkeiten bei der
Durchführung thematisiert, damit die Erkenntnisse für zukünftige Untersuchungen be-
rücksichtigt werden können.
Zuerst werden die Schwierigkeiten bei der Rekrutierung der Testpersonen beleuchtet.
Da die Testpersonen hauptsächlich aus dem persönlichen Umfeld in Aachen rekrutiert
wurden, war es sehr schwer Personen ab 40 Jahre zu erreichen. Daher wird diese Nut-
zergruppe durch den vorliegenden Nutzertest auch nicht repräsentiert. Da die typische
Nutzergruppe aus Personen zwischen 15 und 34 Jahren besteht (vgl. Abschnitt
„3.1.2 Testnutzer“), stellte das kein Problem dar.
Schwieriger gestaltete sich das Auffinden von weiblichen Testpersonen, welche fortge-
schrittene Erfahrungen mit der Nutzung des mobilen Internets aufweisen konnten. Ein
Grund dafür könnte sein, dass die weibliche Nutzergruppe noch zu klein ist. Denn laut
der „MobileWeb Metrix“-Studie sind nur 37 Prozent der mobilen Internetnutzer in
3.3 Ergebnisse und Auswertung des Nutzertests
73
Großbritannien weiblich und in den USA sind auch nur 40 Prozent der „Mobile Web“-
Anwender Frauen.
Ähnlich mühsam gestaltete sich die Suche nach fortgeschrittenen Nutzern des mobilen
Internets, die nicht aus einem technischen (Arbeits-)Umfeld stammen. Für diese Unter-
suchung wurden daher nur fortgeschrittene Nutzer mit technischem Hintergrund rekru-
tiert. Wahrscheinlich sind Personen aus einem technischen Bereich gegenüber neuen
Technologien eher aufgeschlossen und daher zahlreicher vertreten als die nicht-
technischen Internetnutzer.
Pro Testperson wurde eine Zeitdauer von zwei Stunden veranschlagt. Demzufolge
konnten maximal drei Tests pro Tag durchgeführt werden. Bei einer höheren Anzahl
von Durchgängen wäre die volle Aufmerksamkeit des Moderators sowie des Beobach-
ters nicht mehr gewährleistet. Folglich waren die Zeiträume zum Testen begrenzt und
die Terminfindung mit den Testnutzern gestaltete sich als aufwändiger als gedacht.
Ein weiterer Punkt bei dem Schwierigkeiten auftraten, war die Aufzeichnung per Vi-
deokamera. Die direkte, digitale Aufnahme von Filmmaterial erfordert sehr viel Spei-
cherplatz. Im vorliegenden Fall belegten die Videodaten pro Tester ca. 20 Gigabyte.
Nach dem Rendering des Materials belegte das Filmmaterial immer noch etliche Giga-
byte. Daher wird empfohlen eine große Festplatte mit ausreichend Speicherplatz zu
verwenden bzw. die Aufnahme direkt nach Testende zu rendern.
Das Rendering der Videodaten dauerte jedoch immer mindestens 45 Minuten. Wäh-
renddessen konnte man leider keine neue Aufnahme starten. Glücklicherweise waren
die Zeiten zwischen den einzelnen Testpersonen so verteilt, dass daraus kein Problem
entstand. Zum Beheben dieser Schwierigkeiten sollte man verschiedene Programme
vorab testen, um ein geeignetes Programm auswählen zu können.
Die verwendete Videokamera war so konzipiert, dass bei einer Aufnahme trotz der digi-
talen Speicherung das analoge Videoband mitbewegt wurde. Das Band der Kamera war
nur für 1,5 Stunden ausgelegt und nach deren Ablauf schaltete sich automatisch der
Aufnahmemodus ab. Folglich konnten nur maximal 1,5 Stunden der Testdurchführung
aufgenommen werden. Da die Aufzeichnung erst mit dem ersten Browser (nach Einfüh-
rung und Einstiegsübung) startete, stellte dies eigentlich kein Problem dar. Zweimal
dauerte der Test jedoch länger als 90 Minuten und das Testende konnte leider nicht auf-
3.3 Ergebnisse und Auswertung des Nutzertests
74
gezeichnet werden. Da das Videomaterial jedoch nur zu Ergänzungszwecken aufge-
nommen wurde, war das kein Problem. Durch die Verwendung eines Videobands mit
längerer Aufnahmekapazität kann diese Schwierigkeit schnell behoben werden.
In einem Browsertest (13.03.2008) war die Übertragungsgeschwindigkeit im Vergleich
zu den restlichen Testdurchgängen aus unerfindlichen Gründen extrem langsam. Da die
Reaktionszeit des Browsers von der Geschwindigkeit des verwendeten Netzes abhängt,
verliefen die Ladevorgänge der Webseiten nur schleppend und der Testperson entstan-
den unnötige Wartezeiten. Dies konnte jedoch nicht beeinflusst werden.
Jakob Nielsen schreibt in seiner Kolumne, dass man bei einem Think Aloud-Test nicht
(nur) auf die Nutzer hören sollte, sondern der Beobachtung mehr Bedeutung zumessen
soll [www17]. Zu einem ähnlichen Ergebnis kommen auch Schweibenz & Thissen
[Schweibenz2003]. Die Gründe für die Relevanz der Beobachtung wurden schon in
Abschnitt „2.2.1 Nutzertest“ näher erläutert und werden noch mal kurz zusammenge-
fasst.
Die Nutzer erzählen nur dass,
• was sie denken, was jemand hören möchte
• an was sie sich erinnern oder
• sie versuchen ihr Verhalten rational zu erklären.
Diese Aussagen können durch den vorliegenden Nutzertest bestätigt werden. Es war
sehr interessant zu beobachten, dass fast alle Tester offensichtlich Probleme mit der
Navigation innerhalb des Nokia-Browsermenüs hatten. In dem anschließenden Bewer-
tungsbogen beurteilten einige Tester die Menüführung jedoch mit „sehr einfache Menü-
führung“, „einfach zu bedienen“ oder „intuitiv“. Dies widersprach stark dem beobach-
teten Ergebnis und in diesem Fall konnte eindeutig erfasst werden, dass die Tester
nachweislich Probleme mit dem Menü hatten. Die Menüstruktur des Nokia-Browsers
wurde demnach als Usability-Problem eingestuft. Für die nachfolgende Auswertung der
Ergebnisse war es daher wichtig, gleichwohl schwierig, der Beobachtung mehr Rele-
vanz als den Kommentaren der Testnutzer zu zuweisen.
3.3 Ergebnisse und Auswertung des Nutzertests
75
Zusammenfassend betrachtet traten bei der Durchführung des Nutzertests keine größe-
ren Schwierigkeiten auf und alles funktionierte wie geplant. Nachfolgend werden die
Ergebnisse des Nutzertests in Bezug auf die Usability beschrieben.
3.3.3 Strukturierung der Ergebnisse
Während der Beobachtung des Nutzertests wurden sehr viele Notizen zum Interaktions-
verhalten zwischen Nutzer und Handybrowser gesammelt. Diese Notizen sowie die
Kommentare aus den abschließenden Bewertungsbögen mussten derart strukturiert
werden, dass eine weitere Auswertung möglich wurde.
Die Strukturierung fand mithilfe eines Affinitätsdiagramms statt. Alle Notizen wurden
auf verschiedenfarbige Klebezettel (Post-Its) übertragen und somit als Usability-
Problem klassifiziert. Jeder Klebezettel beinhaltete ein Usability-Problem (Finding).
Die Findings waren unterschiedlicher Herkunft. Zum einen äußerten die Nutzer durch
die Think Aloud-Methode ihre Erwartung an den Browser. Wenn die Erwartung mit
dem tatsächlichen Ergebnis nicht übereinstimmte, musste ein Problem vorliegen. Diese
Art von Usability-Problem, z.B. direkte Eingabe von Formulardaten funktioniert nicht,
stellte eine Sorte von Findings dar.
Des weiteren wurde als Finding notiert, wenn die Nutzer Probleme hatten eine passende
Funktion zur Lösung der Aufgabe zu finden. Dies konnte sich darin äußern, dass die
Nutzer die Funktion unter einem „falschen“ Unterpunkt im Menü suchten oder die ge-
eignete Funktion unter einer anderen Bezeichnung vermuteten (z.B. bei Suche den Beg-
riff „Search“ anstatt „Find text“ erwarteten). Weiterhin wurde als Finding festgehalten,
wenn die Nutzer im schlimmsten Falle eine bestimmte Funktion überhaupt nicht finden
konnten oder Probleme bei deren Bedienung hatten. Zusätzlich wurden alle sonstigen
negativen Kommentare der Nutzer aus den Notizen zum Test übertragen, z.B. zum La-
destatus des Browsers: „man sieht nicht, ob er lädt“, und als Finding formuliert: „Lade-
status ist durch sehr kleines Symbol (drehende Weltkugel) nicht erkennbar“.
Zusätzlich wurden noch die Ergebnisse der Fragen „Gab es unklare Begriffe? Fehlten
dir Informationen?“ sowie „Was hat dich am meisten gestört?“ aus den Bewertungsbö-
gen übertragen. Zur besseren Unterscheidung zwischen den einzelnen Browsern wurden
Klebezettel in verschiedenen Farben verwendet: Nokia = weiß, Opera Mini = gelb,
3.3 Ergebnisse und Auswertung des Nutzertests
76
TeaShark = pink (Abbildung 3-11). Das heißt alle Usability-Probleme, die im Nutzer-
test beim Nokia-Browser auftauchten, wurden auf weißen Klebezettel notiert.
Abbildung 3-11: Strukturierung der Findings mittels Klebezettel
Zusätzlich wurde bei jedem Finding festgehalten, bei wie vielen Nutzern das Problem
auftrat (Häufigkeit) sowie an welcher Stelle in der Browserreihenfolge (I, II oder III) es
bemerkt wurde (Abbildung 3-12).
Abbildung 3-12: Finding mit Browserreihenfolge (rechts oben) und Häufigkeit (rechts unten)
Wenn ein Finding auf dem abschließenden Bewertungsbogen unter der Frage „Was hat
dich am meisten gestört?“ genannt wurde, wurde das Problem als besonders schwer-
wiegend eingestuft. Das betreffende Finding wurde mit einem zusätzlichen Minuszei-
chen (-) als Symbol für den Schweregrad gekennzeichnet. Je nachdem wie viele Perso-
nen dieses Usability-Problem auf dem Bewertungsbogen als besonders störend einstuf-
ten, konnte ein Finding auch mehrere Minuszeichen aufweisen.
3.3 Ergebnisse und Auswertung des Nutzertests
77
Nach der Übertragung der Findings sowie der Zusatzinformationen wie Browserreihen-
folge, Häufigkeit und Schweregrad auf die Klebezettel erfolgte eine Zuordnung der Er-
gebnisse zu den einzelnen Aufgabenkategorien (Abbildung 3-13).
Abbildung 3-13: Clusterbildung der Findings
Die Kategorien, z.B. Formulareingabe, Lesezeichen aufrufen, Menü, etc., wurden auf
orangefarbenen Klebezetteln notiert und fungierten als Überschrift. Die Findings wur-
den anschließend spaltenweise darunter angeordnet. Es wurde darauf geachtet, dass
gleiche Findings von verschiedenen Browsern räumlich nah aneinander angeordnet
werden (Clusterung). Damit konnte auf einen Blick erfasst werden, welche Usability-
Problemen bei mehreren Handybrowsern auftraten. Auf diese browserübergreifenden
Usability-Probleme wird näher im Abschnitt „3.3.4 Abgeleitete Anforderungen an die
Gestaltung“ eingegangen.
Insgesamt wurden im Nutzertest 76 Usability-Probleme gefunden. Einige davon traten
bei mehreren Browsern auf, sodass die Anzahl der unterschiedlichen Usability-
Probleme kleiner ist als die Gesamtsumme der aufgetretenen Probleme. Nachdem die
Sortierung und Kategorisierung der Findings beendet war, wurden die Daten nach
Browsern sowie Kategorien sortiert in eine Tabelle übertragen. Anschließend erfolgte
die Zuweisung von Prioritätsstufen nach Schweibenz (vgl. Tabelle 2-1: Stufen der
Ernsthaftigkeit von Usability-Problemen [nach Schweibenz2003], S. 21). Je nach aufge-
3.3 Ergebnisse und Auswertung des Nutzertests
78
tretener Häufigkeit, Schweregrad, Hartnäckigkeit des Problems und unter Beachtung
des Einflusses auf den Nutzer wurden die Prioritätsstufen von 0 (kein Usability-
Problem) bis 4 (katastrophales Problem) vergeben. Die Tabelle 3-4 zeigt einen Auszug
dieser Verteilung beim Browser TeaShark.
Tabelle 3-4: Verteilung der Prioritätsstufen auf die Findings beim Browser TeaShark (Auszug)
Usability-Problem Häufigkeit Schwere-grad8
Prioritäts-stufe
Menü ist nicht ständig sichtbar, sondern verschwindet nach Benutzung
8 3
Browser lädt trotz „Cancel“ weiter und stellt Webseite anschließend fehlerhaft dar
1 1
direkte Eingabe erwartet 2 - - 4
Cursor bewegt sich unstetig (in Sprüngen) 3 - - 4
... ... ... ...
Bei der Auswertung des Nutzertests lag das Hauptaugenmerk auf einer qualitativen Be-
trachtung der Ergebnisse. Die Form sowie die Inhalte der Notizen und Kommentare
wurden dabei ausgewertet. Weiterhin sind die subjektiven Ergebnisse wie Zufrieden-
heit, Frustration oder Konfusion der Nutzer, die durch die Think Aloud-Methode er-
sichtlich wurden, in die Priorisierung der Ergebnisse eingeflossen. Die Anzahl der
Kommentare wurde in Bezug zu den Inhalten gesetzt, sodass gleichzeitig der quantitati-
ve Faktor in der Auswertung berücksichtigt wurde. Wenn beispielsweise mehrere Nut-
zer eine Design-Eigenschaft des Browsers als schwer verständlich bewerteten, stieg die
Prioritätsstufe an.
8 Nennung bei der Frage „Was hat dich am meisten gestört?“ im Bewertungsbogen
3.3 Ergebnisse und Auswertung des Nutzertests
79
Die beobachteten Usability-Probleme verteilen sich demnach wie folgt auf die ver-
schiedenen Browser sowie Prioritätsstufen:
Tabelle 3-5: Verteilung der Usability-Probleme aus dem Nutzertest auf die einzelnen Browser
Alle Findings im Detail inklusive Screenshots sowie Zitate der Testpersonen befinden
sich nach Browsern geordnet im Anhang C, D und E.
Es fällt auf, dass kein Ergebnis mit der Prioritätsstufe 0 bewertet wurde. Der Grund da-
für ist, dass die Auswertung von einer Einzelperson vorgenommen wurde und daher nur
„echte“ Usabilityfehler als Findings klassifiziert wurden. Sonstige Auffälligkeiten wer-
den im Abschnitt „3.3.6 Browserunabhängige Ergebnisse“ behandelt. Alle weiteren
Ergebnisse des Nutzertests werden in den folgenden Abschnitten näher behandelt.
3.3.4 Abgeleitete Anforderungen an die Gestaltung eines Handybrowsers
Durch die strukturierte Anordnung der Klebezettel mit den Findings wurde die Auswer-
tung vereinfacht. Aufgrund der Übersichtlichkeit konnten schwerwiegende Usability-
Probleme (Kennzeichnung durch Minuszeichen) schnell erfasst werden. Weiterhin
konnte durch die räumliche Anordnung bei einer Häufung der Klebezettel festgestellt
werden, wenn ein browserübergreifendes Usability-Problem auftrat.
Falls eine Kategorie viele Findings beinhaltete, wurde untersucht, ob für die einzelnen
Findings eventuell ein dahinterliegendes Prinzip verantwortlich ist. Diese Methode ist in
Abbildung 3-14 dargestellt und heißt Aggregation allgemeiner Problemfelder.
Prioritätsstufe Browser
0 1 2 3 4 Summe
Nokia 0 6 7 10 10 33
Opera Mini 0 3 8 3 3 17
TeaShark 0 5 4 5 12 26
GESAMT 0 14 19 18 25 76
3.3 Ergebnisse und Auswertung des Nutzertests
80
Abbildung 3-14: Aggregation allgemeiner Problemfelder
Zum besseren Verständnis sei hier ein Beispiel zum Thema Navigation aufgeführt. Bei
der Auswertung der Ergebnisse zeigte sich, dass viele Usability-Probleme in Bezug auf
die Navigation im Menü des Nokia-Browsers auftraten. Die Nutzer bemängelten, dass
die Unterpunkte nicht auf einen Blick ersichtlich sind, sondern sich in weiteren, bild-
schirmfüllenden Fenstern öffnen. Die Nutzer durchsuchten somit oft das Menü. Denn
die Untermenüs, wie „Andere Optionen“, „Seitenoptionen“ oder „Browsereinstellun-
gen“, klingen ähnlich und wurden daher häufig verwechselt. Oft benötigte Funktionen,
z.B. Internetadresse eingeben, werden am Anfang des Menüs erwartet, befinden sich
aber in der Mitte des Menüs. Diese und weitere Ergebnisse konnten im Nutzertest fest-
gestellt werden. Die einzelnen Findings lassen sich größtenteils auf das gleiche Haupt-
problem zurückführen: die unübersichtliche Navigation im Menü des Nokia-Browsers.
Zum Beheben der einzelnen Usability-Probleme müssen also nicht nur die Menübe-
zeichnungen stärker differenziert oder die Reihenfolge der Menüpunkte geändert wer-
den, sondern die gesamte Menüstruktur sollte flacher und klarer gestaltet werden.
Anhand der Aggregation solcher allgemeiner Problemfelder, dem Auftreten browser-
übergreifender Ergebnisse und unter besonderer Berücksichtigung schwerwiegender
Probleme wurden mehrere Hauptergebnisse im Nutzertest identifiziert. Aus diesen
wichtigen Ergebnissen wurden Empfehlungen für die Gestaltung eines Handybrowsers
formuliert. Nachfolgend werden diese Anforderungen aufgelistet und anschließend ein-
zeln erläutert.
3.3 Ergebnisse und Auswertung des Nutzertests
81
Abgeleitete Anforderungen an die Gestaltung eines Handybrowsers:
1. Der Menübalken sollte ständig sichtbar sein.
2. Die Menüstruktur sollte übersichtlich und intuitiv zu bedienen sein.
3. Lieber weniger Menüfunktionen anbieten, aber dafür eine übersichtliche Darstel-
lung gewährleisten.
4. Zur Eingabe von Internetadressen (URL) sollte eine grafische Darstellung einer
Eingabeleiste (ähnlich PC-Browser) auf der Startseite vorhanden sein.
5. Der Ladevorgang sowie dessen Fortschritt sollten deutlich erkennbar sein.
6. Die Navigation mit der Maus sollte kontinuierlich, d.h. stetig, funktionieren.
7. Eine Zoomübersicht sollte nur auf nicht-mobilen Webseiten erscheinen und die
Möglichkeit zum schnellen Umschalten zwischen Zoom und normaler Ansicht
sollte bestehen.
8. Der Nutzer sollte nach der Auswahl eines Formularfelds direkt Daten eingeben
können sowie mit den Navigationstasten zwischen den einzelnen Formularfeldern
navigieren können.
9. Formulardaten sollten gespeichert und soweit möglich übernommen werden (Au-
to-Ausfüllen).
10. Bereits besuchte Webseiten (Verlauf) sollte der Browser in Listenform darstellen.
11. Ein schneller Zugang zur Funktion „Bilder herunterladen“ sollte ermöglicht wer-
den.
12. Der Browser sollte eine ausreichende Anzahl an Statusmeldungen anbieten.
zu 1. Sichtbarkeit des Menüs
Der Menübalken mit der Beschriftung für die Softkeys wird beim TeaShark standard-
mäßig nur angezeigt, wenn man sich im Browserbereich selbst aufhält (Start page,
Bookmarks, Visited pages, ...). Falls man sich auf einer Internetseite befindet, ist der
Menübalken ausgeblendet (Abbildung 3-15). Dies hatte zur Folge, dass die Testnutzer
das Menü suchten und nicht wussten, wie sie es aufrufen sollten. Nach kurzer Orientie-
rungslosigkeit haben die Tester durch wahlloses Drücken der Handytasten entweder die
Zurück-Funktion (rechter Softkey, „jetzt hab ich zurück geblättert, das war aber eher
Zufall“) oder das Menü (linker Softkey) gefunden.
3.3 Ergebnisse und Auswertung des Nutzertests
82
Abbildung 3-15: TeaShark – Menübalken nicht sichtbar
Bis auf einen Tester (vgl. Abschnitt „3.3.5 Bewährte Eigenschaften der Browser“) ga-
ben alle Testnutzer die fehlende Sichtbarkeit des Menüs als Problem an. Ein Tester äu-
ßerte bei dem darauffolgenden Browser: „hier sehe ich die ganze Zeit das Menü - wie
praktisch“. Daher sollte der Menübalken zur Orientierung immer sichtbar sein, z.B. am
unteren Bildschirmrand.
zu 2. Übersichtliche Menüstruktur
Wie bereits erwähnt traten viele Probleme bei der Navigation innerhalb des Nokia-
Browsers auf. Dies hat mehrere Gründe. Erstens besitzen die Menüpunkte ähnliche Be-
zeichnungen. Funktionen werden demnach im falschen Untermenü gesucht („muss
doch in ‚Seitenoptionen’ sein“). Zweitens ist das Menü sowohl breit als auch tief gestal-
tet. Damit kann die Menüstruktur nicht auf einen Blick erfasst werden. Wenn man sich
auf einer Webseite befindet, enthält das Hauptmenü insgesamt elf Einträge, die sich
teilweise noch weiter verzweigen. Viele Testnutzer hatten aus diesen Gründen Probleme
auf Anhieb die gewünschte Funktion zu finden. Die Nutzer verirrten sich in den Unter-
menüs oder fanden aufgrund der scheinbar willkürlichen Menüstruktur die gewünschte
Menüfunktion überhaupt nicht.
Bei den beiden anderen Browsern Opera Mini (OM) und TeaShark (TS) gibt es ein
Hauptmenü sowie ein (OM) bzw. maximal drei (TS) Untermenüs. Die Untermenüs des
Browsers TeaShark sind in Form eines Fly-Outs realisiert und daher auf einen Blick
erfassbar. Zusätzlich ist die Schriftgröße im Gegensatz zum Nokia-Browser deutlich
3.3 Ergebnisse und Auswertung des Nutzertests
83
kleiner, aber dennoch lesbar, sodass ein größerer Anteil des Menüs sichtbar ist. Die
Menüstruktur des Nokia-Browsers wird zusätzlich vertieft, indem jede de-/aktiviert-
Entscheidung im Bereich „Einstellungen“ eine eigene Hierarchieebene erfordert (An-
hang J). Bei den beiden anderen Browsern wird diese Entscheidung über Checkboxen
oder Drop-Down-Menüs geregelt. Zusammenfassend traten sowohl beim TeaShark als
auch beim Opera Mini im Hinblick auf die Menüs wesentlich weniger Usability-
Probleme auf. Darum sollte die Menüstruktur eines Handybrowsers so flach wie mög-
lich gestaltet werden, um eine gute Übersichtlichkeit zu gewährleisten.
zu 3. Anzahl an Menüfunktionen
Die beiden Browser Opera Mini und TeaShark bieten im Gegensatz zum Nokia-
Browser weniger Funktionen und Einstellungen an. Sie besitzen keine Funktion zum
Verschicken einer URL per SMS oder halten keine Einstellung zum Textumbruch oder
zur Zeichenkodierung bereit. Dadurch wurden die Nutzer nicht von einer Vielzahl an
Funktionen überlastet, sondern konnten aus einem überschaubaren Angebot mit weni-
gen Untermenüs („geht alles über 'Extras'“) auswählen. Die begrenzte Funktionsliste
und damit einhergehende Übersichtlichkeit im Gegensatz zum Nokia-Browser wurde
zweimal explizit als sehr positiv in der Browserbewertung erwähnt.
zu 4. Eingabeleiste
Als die Testnutzer bei der ersten Aufgabe im Nutzertest die Amazon-Webseite aufrufen
sollten, haben sozusagen alle Nutzer nach einer grafischen Eingabeleiste ähnlich zum
PC-Browser gesucht. Da die Eingabe von Internetadressen eine der wichtigsten Aufga-
ben von Browsern darstellt, erwarten die Nutzer, dass sich diese Funktionalität auf der
Startseite befindet. Eine grafische Eingabeleiste ist jedoch nur auf der Startseite des
Opera Mini vorhanden (Abbildung 3-16). Beim Browser TeaShark existiert eine ähnlich
gestaltete Leiste. Diese ist jedoch mit einer Suchfunktionalität von Google hinterlegt
(Abbildung 3-17). Durch die äußerliche Ähnlichkeit haben einige Nutzer diese Such-
leiste fälschlicherweise mit einer Adressleiste verwechselt. Sie haben daher mit Google
gesucht, anstatt die gewünschte Internetadresse aufzurufen. Erst nachdem die Nutzer
erkannten, dass der TeaShark keine grafische Eingabeleiste anbietet, haben sie das Me-
3.3 Ergebnisse und Auswertung des Nutzertests
84
nü durchsucht („Irgendwie fehlt mir die Eingabezeile für URLs. Dann such ich mal
herum.“).
Abbildung 3-16: Opera Mini - Eingabeleiste für URLs
Abbildung 3-17: TeaShark – Suchleiste von Google
Beim Nokia-Browser existiert keine Startseite mit einer Übersicht über die wichtigsten
Funktionen, sondern nur das Menü. Daher hatte ein Nutzer die Hoffnung, dass beim
Aufruf einer Internetseite sich eine Eingabeleiste öffnet („ich öffne einfach mal ne Seite
und hoffe, dass ich dort was eingeben kann“). Dies ist leider nicht der Fall. Da die Nut-
zer eine Eingabeleiste erwarten, sollte zur Verbesserung der Usability eine solche Leiste
auf der Startseite jedes Handybrowsers angeboten werden.
zu 5. Ladestatus
Ob der Browser eine Webseite lädt, kann man beim Nokia-Browser nur durch das Sym-
bol einer kleinen, drehenden Weltkugel rechts oben erkennen (Abbildung 3-18). Wenn
der Ladevorgang beendet ist, verschwindet die Weltkugel.
3.3 Ergebnisse und Auswertung des Nutzertests
85
Abbildung 3-18: Nokia - Ladestatus
Zwei der Testteilnehmer äußerten, dass der Ladestatus schlecht bis gar nicht erkennbar
ist („man sieht nicht, ob er lädt“). Denn das Symbol der Weltkugel ist so klein, dass es
leicht übersehen werden kann. Durch das drehende Symbol ist der Fortschritt des Lade-
vorgangs nicht erkennbar. Das heißt, es ist nicht abschätzbar, wie viel Prozent der Web-
seite schon geladen wurden und wie lange es eventuell noch bis zur Fertigstellung dau-
ert. Beim Opera Mini sowie beim TeaShark wird der Ladevorgang durch einen Lade-
balken mit Prozentangaben sowie den Worten „Verbinde“ (OM) bzw. „Loading“ (TS)
visualisiert. Diese Art der Darstellung empfanden drei der Tester als informativer sowie
deutlicher und bemängelten die Symboldarstellung im darauffolgenden Test des Nokia-
Browsers.
zu 6. stetige Mausbewegung
Die beiden Browser TeaShark und Opera Mini besitzen einen kleinen Cursor zur Navi-
gation. Beim TeaShark erfolgt die Reaktion des Cursors in Sprüngen, d.h. nicht stetig.
Für den Nutzer ist damit keine kontinuierliche Steuerung möglich. Die Testnutzer konn-
ten aus diesem Grund einige Links schlecht ansteuern („mit Mauszeiger nach unten
geht nicht“). Zwei Nutzer bewerteten die unstete Steuerung als sehr negativ und ein
Tester würde aufgrund dieses Bedienproblems den TeaShark in der Praxis nicht nutzen
(„würde jetzt schon abbrechen und Browser deinstallieren“). Das Problem der unsteten
Cursorsteuerung wurde demnach als so behindernd empfunden, dass es unbedingt durch
eine kontinuierliche Steuerung ersetzt werden sollte.
3.3 Ergebnisse und Auswertung des Nutzertests
86
zu 7. Zoomübersicht
Sowohl der Opera Mini als auch der TeaShark bieten eine Zoomfunktion an, die beim
Aufruf einer Internetseite den Inhalt verkleinert und in einer Art Miniansicht darstellt.
Zur selben Zeit erhält der Nutzer die Steuerung über einen farbigen Rahmen (Zoom-
fenster) mit dem er zu einem beliebigen Abschnitt der Webseite navigieren und diesen
Ausschnitt vergrößern kann. Durch diese Übersichtsdarstellung ist die Schriftgröße der
Webseite verkleinert und für den Nutzer nicht lesbar (Abbildung 3-19). Daher äußerte
die Mehrzahl der Testnutzer beim ersten Kontakt mit der Zoomübersicht ähnlich nega-
tive Kommentare: „Das kann ich gar nicht lesen.“ oder „ein Rechteck zum Vergrößern,
aber ich weiß doch noch gar nicht wo ich hin will“. Einige Tester betrachteten diese
Funktion daher nur dann als nützlich, wenn man die Webseite bereits kennt und demzu-
folge weiß, welchen Ausschnitt man vergrößern möchte („Vorwissen nötig um Aus-
schnitt zu vergrößern“ oder „ich gehe auf den Abschnitt, wo ich weiß, dass die Suche
beginnt, aber wenn ich das nicht wüsste...“). Falls die Nutzer die Webseite noch nicht
kannten, empfanden die Tester die Zoomübersicht als nicht förderlich. Im Gegenteil, ein
Tester meinte „ins Blaue hinein eine Stelle anklicken ist abschreckend“. Es sollte daher
die Möglichkeit bestehen, dass der Nutzer bei Bedarf schnell von der Zoomübersicht
zur Normalansicht (und umgekehrt) wechseln kann, zum Beispiel durch einen Tasten-
druck.
Abbildung 3-19: Opera Mini - Zoomübersicht der normalen Webseite kicker.de
Abbildung 3-20: TeaShark – Zoomübersicht der mobilen Webseite mobil.bahn.de
Ein Tester empfand die Zoomfunktion besonders negativ auf mobilen Webseiten, z.B.
auf mobil.bahn.de (Abbildung 3-20). Deren Darstellung ist normalerweise schon an die
3.3 Ergebnisse und Auswertung des Nutzertests
87
Handydimensionen angepasst, z.B. Displaybreite. Dem Nutzer erschien die Zoomfunk-
tion in diesem Fall als überflüssig, da er erst klicken musste, um zur Normalansicht zu
gelangen. Aus diesem Grund kann auf die Zoomfunktion beim Aufruf von mobilen
Webseiten verzichtet werden, beziehungsweise sollte mindestens eine Option zur Deak-
tivierung der Zoomübersicht, wie beim Opera Mini, vorhanden sein.
zu 8. Direkte Eingabe
Als im Test Formulardaten eingegeben werden sollten, begann der Großteil der Nutzer
direkt mit der Eingabe von Zeichen. Es folgte ein kurzes Innehalten der Tester, weil die
Eingabe bei den Browsern TeaShark und Opera Mini nicht übernommen wurde („ein-
fach los schreiben ist nicht“). Daraufhin erkannten die meisten Nutzer, dass man das
ausgewählte Formularfeld zusätzlich bestätigen muss, bevor eine Eingabe getätigt wer-
den kann: „Ah! Reinklicken.“ oder „denke, dass ich klicken muss, um dort was eintip-
pen zu können“. Die anfängliche Erwartung (Bedienstrategie) der Tester stimmte dem-
nach nicht mit dem Bedienkonzept des Browsers überein („obwohl [ich] auf Feld [bin],
muss ich erst klicken zum Eingeben“). Ein Nutzer machte für dieses Usability-Problem
nicht den Browser verantwortlich, sondern suchte die Schuld bei sich selbst: „hab ver-
gessen es anzuklicken“.
Obwohl der Nokia-Browser im Gegensatz zu den anderen beiden eine direkte Eingabe
akzeptiert, kam es auch dort zu Usability-Problemen. Wenn der Nutzer ein Formularfeld
auswählt, bietet der Nokia-Browser per Softkey die Option „Ändern“ an (Abbildung
3-21). Demzufolge nahmen einige Tester fälschlicherweise an, dass auch bei diesem
Browser keine direkte Eingabe möglich ist. Zum Abschluss der Formulareingabe kam
es zu ähnlichen Problemen. Die Tester versuchten mithilfe der Navigationstasten ins
nächste Formularfeld oder zum nächsten Button zu springen. Dies funktioniert bei allen
drei Browsern nicht, sondern die Eingabe muss durch eine Bestätigung per Softkey
(„OK“) abgeschlossen werden (Abbildung 3-22). Die Nutzer äußerten sich wie folgt
dazu: „Zweimal ‚OK’ für Eingabe - das ist doof“ oder „’Los’ muss extra angeklickt
werden, nur ‚Return’ funktioniert nicht“. Damit eine Steuerung mit den Navigationstas-
ten möglich ist, muss die Eingabe im gleichen Fenster erfolgen und es darf keine zusätz-
liche Eingabemaske, wie beim Opera Mini oder beim TeaShark, geöffnet werden.
3.3 Ergebnisse und Auswertung des Nutzertests
88
Abbildung 3-21: Nokia – Option „Ändern“ bei der Formulareingabe
Abbildung 3-22: Nokia – Bestätigung per „OK“ bei der Formulareingabe nötig
Sowohl im Test als auch bei der anschließenden Bewertung hegte die Mehrzahl der
Nutzer den Wunsch nach einer direkten Eingabe, ohne das Formularfeld gesondert auf-
zurufen oder bestätigen zu müssen („ständig reinklicken war nicht so der Hammer“
oder „wenn man das gelernt hat, sind das Klicks, die man sparen würde, aber die nicht
kriegsentscheidend sind“).
zu 9. Auto-Ausfüllen
Bei der zweiten Aufgabe im Nutzertest sollten die Nutzer herausfinden, wie hoch der
Preis einer bestimmten Bahnverbindung ist. Nachdem sie die Optionen für die Preisbe-
rechnung auf der Webseite geändert hatten, waren die Formulardaten (Start, Ziel, Da-
tum und Uhrzeit) bei den beiden Browsern Opera Mini und TeaShark gelöscht. Dies
verstimmte die Nutzer, da die Eingabe aufwändig war und sie jetzt nochmals alle Daten
eingeben mussten („muss alles neu eingetippt werden, was mich ziemlich ärgert“). Eine
Funktion zum Auto-Ausfüllen, wie sie der Nokia-Browser anbietet, wäre in dem Fall
hilfreich. Dabei erscheinen die zuletzt eingegebenen Daten automatisch im Formular-
feld, sei es bei der Bahnverbindung oder der Suche nach einem Buch auf der Amazon-
Webseite. Da das Handy ein persönlicher Gegenstand ist, wird es normalerweise nur
von seinem Besitzer benutzt und die Gefahr der Ausnutzung von persönlichen Daten ist
gering. Durch das Anbieten einer Funktion zum Auto-Ausfüllen kann die Nutzerzufrie-
denheit und folglich die Usability erhöht werden.
3.3 Ergebnisse und Auswertung des Nutzertests
89
zu 10. Verlauf als Liste
Die sechste Aufgabe des Nutzertests beinhaltete das Testen der Verlaufsfunktion der
Handybrowser. Die Nutzer sollten auf die erste aufgerufene Seite zurückkehren. Beim
TeaShark wählte die Hälfte der Tester die Funktion „List“ aus dem „History“-Menü zur
Lösung der Aufgabe. Sie erwarteten, dass sich eine Liste mit den besuchten Webseiten
öffnet. Die Erwartung wurde nicht erfüllt. Der TeaShark-Browser öffnet die zuletzt be-
suchte Webseite und kennzeichnet diese mit einem blauen Rahmen, dessen linke Seite
blinkt. Zusätzlich wird eine Zahlenangabe wie „7/7“ angezeigt (Abbildung 3-23). Mehr
Informationen erhält der Nutzer nicht.
Abbildung 3-23: TeaShark – grafischer Verlauf („List“)
Abbildung 3-24: TeaShark - Verlauf als Liste („Visited“)
Die Tester warteten irritiert, ob noch eine Erklärung folgt und ein Testnutzer stellte la-
pidar fest „da blinkt was“. Das Problem war, dass die Nutzer erstens aufgrund der Be-
zeichnung „List“ eine Auflistung erwartet hatten und zweitens die Steuerung dieser gra-
fischen Verlaufsdarstellung nicht erläutert wurde. Zusätzlich war erneut das Menü aus-
geblendet und die Bedeutung der Softkeys konnte nur durch Experimentieren herausge-
funden werden. Alternativ besteht beim TeaShark die Möglichkeit bereits besuchte
Webseiten über die Funktion „Visited“ im View-Menü aufzurufen. Diese Darstellung
des Verlaufs entspricht der erwarteten Listenform (Abbildung 3-24) und jene Hälfte der
Testnutzer, die diese Alternative wählten, hatten keine Usability-Probleme mit der Ver-
laufsfunktion. Daher sollte entweder die Umsetzung der grafischen Verlaufsfunktion
beim TeaShark-Browser deutlich verbessert werden oder nur die Listenform, wie bei
3.3 Ergebnisse und Auswertung des Nutzertests
90
den beiden anderen Browsern, verwendet werden. Die Darstellung als Liste empfiehlt
auch Chan [Chan2002].
zu 11. Bilder herunterladen
Die Funktion „Bilder herunterladen“ wurde nur vom Opera Mini und vom Nokia-
Browser unterstützt. Alle Tester versuchten anfangs das gewünschte Bild auszuwählen
bzw. zu markieren. Dies funktioniert jedoch bei beiden Browsern nicht. Es muss ein
spezieller Modus (N) bzw. eine Option (OM) aufgerufen werden. Diese Bedienstrategie
erwarteten die Tester nicht. Sie stellten fest, dass man das Bild nicht markieren kann
(„auf Bild selber komm ich nicht drauf“) und ein Nutzer zog daraus die Schlussfolge-
rung, dass man das Bild nicht speichern kann („was nicht markierbar ist, ist nicht
abspeicherbar“). Die Nutzer hatten die Erwartung, dass die Funktion zum Bilder spei-
chern sich unter einer ähnlichen Bezeichnung irgendwo im Hauptmenü befindet.
Beim Opera Mini wird die Funktion zum Bilder herunterladen erst sichtbar, wenn man
sich die Seiteninformationen anzeigen lässt. Sechs der acht Tester hatten Probleme die
Funktion überhaupt zu finden („keine Idee auf was ich klicken sollte“ oder „muss im
Menü sein, gibt nix Anderes“). Nachdem der Großteil schließlich die gewünschte Funk-
tion entdeckte, gaben die Tester an, dass sie mit der Benutzerführung nicht zufrieden
waren („geht.. aber mehr so Zufall“ oder „extrem schlecht... ich glaube, ich könnte das
gar nicht noch mal machen“).
Ein ähnliches Szenario gestaltet sich beim Nokia-Browser. Dort verbirgt sich die Funk-
tion „Bildmodus“ im Hauptmenü unter dem Unterpunkt „Seiten-Informationen“. Einige
Nutzer vermuteten den Punkt im Hauptmenü, d.h. in einer der oberen Hierarchieebenen.
Daher durchsuchten sie auf gut Glück das Hauptmenü, welches über „Optionen“ aufge-
rufen wird („‚Optionen’ - nee, ich glaube nicht“ [klickt auf „Andere Optionen“] „Das
sind alles Internetoptionen, wie kann man denn da ein Bild speichern?“ oder „’Optio-
nen' hilft mir nicht weiter“). Eine Testperson zweifelte sogar daran, ob sie die Aufgabe
erfüllen kann („ob das wohl [überhaupt] geht?“). Ebenso wie beim Opera Mini fanden
die meisten Tester die Funktion schließlich doch, waren aber unzufrieden mit der An-
ordnung des Menüpunkts („nicht intuitiv“ oder „aber ich weiß nicht mehr, wie ich da-
hin gekommen bin, wenn ich das noch mal machen sollte“). Die Funktion zum „Bilder
3.3 Ergebnisse und Auswertung des Nutzertests
91
herunterladen“ sollte daher im Hauptmenü oder maximal eine Hierarchieebene tiefer
angeordnet sein.
zu 12. Statusmeldungen
Beim Schließen der beiden Browser TeaShark sowie Opera Mini wird der Nutzer je-
weils mit einer Statusmeldung gefragt, ob er den Browser wirklich beenden möchte.
Beim Nokia-Browser existiert keine Rückfrage. Dort erhält der Nutzer keinerlei Rück-
meldung, ob der Browser und damit die Internetverbindung beendet ist. Ein Nutzer
fragte sich deshalb bei der letzten Aufgabe: „[Ist der Browser]wirklich aus?“.
Beim Anlegen eines Lesezeichens beim Opera Mini erhält der Nutzer keine Statusmel-
dung, ob das Lesezeichen erfolgreich gespeichert wurde. Dies bemängelten zwei Tester
und wünschten sich eine Rückmeldung („Statusmeldung wäre schön“). Ein Handy-
browser sollte daher immer ausreichend Statusmeldungen anbieten, damit die Nutzer
über den aktuellen Zustand informiert sind.
Alles in allem konnten sehr viele Usability-Probleme im Nutzertest entdeckt werden. In
den Anhängen C, D und E werden alle aufgetretenen Usability-Probleme im Detail in-
klusive Screenshots dargestellt.
Im Allgemeinen wurde beobachtet, dass die Ähnlichkeit bzw. das Wiedererkennen von
Elementen eines PC-Browsers durch die Nutzer als positiv bewertet wurde. Je ähnlicher
der Handybrowser einem (bereits bekannten) PC-Browser war, desto besser schnitt der
Handybrowser ab. Als Beispiel sei die Navigation mit einem Cursor genannt. Durch die
bekannte Zeigen-und-Klicken-Technik ist eine direkte Manipulation der Objekte mög-
lich und die Navigation wird erleichtert. Das Vorhandensein eines Cursors bei einem
Handybrowser wurde ausnahmslos positiv betrachtet. Weitere bewährte Eigenschaften
stellt der nächste Abschnitt vor.
3.3.5 Bewährte Eigenschaften der Browser
Im Hinblick auf die spätere Optimierung des Browserdesigns wurden im Nutzertest
nicht nur Usability-Probleme, sondern auch positive Kommentare der Tester zu den
einzelnen Funktionen notiert. Eine Auflistung dieser Ergebnisse befindet sich in An-
3.3 Ergebnisse und Auswertung des Nutzertests
92
hang F. Bei der Auswertung wurden auch diese Ergebnisse, die keine Usability-
Probleme darstellen, auf grüne Klebezettel übertragen. Die einzelnen Klebezettel wur-
den dann, ähnlich wie die Usability-Probleme, den verschiedenen Aufgabenkategorien
zugeordnet. Zum Schluss der Auswertung ergab sich daher folgendes Bild:
Abbildung 3-25: Klebezettel inklusive positiver Kommentare
Teilweise konnten die positiven Kommentare (grün) direkt einigen Usability-Problemen
(weiß, pink oder gelb) zugeordnet werden. Dies erkennt man zum Beispiel in der
Abbildung 3-25 in der Spalte ganz rechts in der Mitte. Dort überlagern sich ein grüner
und ein pinker Klebezettel. Dies war dann der Fall, wenn im Nutzertest bei einem oder
mehreren Testern ein Usability-Problem auftrat und gleichzeitig ein anderer Tester sich
positiv zu dieser Funktion äußerte. Damit wurde das Finding nicht als Problem, sondern
als eine positive Eigenschaft identifiziert.
Als Beispiel sei hier das Menü des Browsers TeaShark angeführt. Wie bereits mehrfach
erwähnt, wird das Menü bei geöffneter Webseite standardmäßig ausgeblendet. Die mei-
sten Nutzer hatten Probleme damit, da sie für kurze Zeit orientierungslos waren. Ein
Tester äußerte sich über das Verschwinden des Menüs jedoch explizit positiv „gut, dass
Menü ausgeblendet wird, da sieht man mehr von der Seite“. Solch ein Fall kam nur
selten vor. Wenn es jedoch zu unterschiedlichen Aussagen kam, rührte die Entschei-
dung, ob Usability-Problem oder nicht daher, ob die Mehrzahl der dazu abgegebenen
3.3 Ergebnisse und Auswertung des Nutzertests
93
Kommentare eher positiver oder negativer Natur war. Einige Browsereigenschaften
wurden durch die Tester einstimmig als positiv bewertet und auf diese soll im Folgen-
den kurz eingegangen werden.
Die Funktion „Abbrechen“ wurde bei allen drei Browsern erst angezeigt, wenn eine
Seite geladen wurde. Die Funktion wurde unter den verschiedenen Begriffen „Stopp“
(OM) und „Abbrechen“ (N) beziehungsweise beim englischsprachigen TeaShark unter
„Cancel“ angeboten. Sie befand sich bei jedem Browser auf dem rechten Softkey. Die
Tester hatten somit keine Probleme mit der Bedienung und es wurden keine Findings in
diesem Bereich gefunden. Ein Tester äußerte dazu scherzhaft: „Destruktives geht immer
gut“.
Weiterhin positiv wurde durch die Tester erwähnt, dass die beiden Browser Opera Mini
und TeaShark einen Cursor anbieten, der sich bei Bedarf in eine Hand verwandelt bzw.
um eine Sanduhr ergänzt wird („toller Cursor, wie am Computer“ oder „kleine Hand
dabei - sehr schön“ ).
Der Browser TeaShark besitzt eine integrierte Suchfunktion, die es ihm ermöglicht ge-
öffnete Webseiten zu durchsuchen. Die Bedienung dieser Suche wurde mit einer Auf-
gabe im Nutzertest überprüft. Insgesamt wurde das Angebot einer solchen Suchfunktion
als sehr positiv von den Testern bewertet. Explizit gut umgesetzt war, nach Meinung der
Nutzer, dass die Suche direkt bei der Eingabe eines Buchstabens startet und nicht wartet
bis die Eingabe abgeschlossen ist.
Die Eingabe von Buchstaben ist durch die geringe Tastengröße und deren Mehrfachbe-
legung auf dem Handy sehr langwierig und umständlich. Die Homepage Heise.de gibt
an, dass man mit einer gewöhnlichen Handytastatur dreimal soviel Zeit zum Eingeben
einer Internetadresse wie mit einer QWERTZ-Tastatur benötigt [www27]. Der TeaS-
hark-Browser unterstützt den Nutzer bei der Eingabe. Wenn der Nutzer eine Internetad-
resse, z.B. „www.amazon.“, eingibt, schlägt der TeaShark automatisch die Endung
„com“ vor (Abbildung 3-26). Wenn der Nutzer jetzt ein „d“ (für „de“) eintippt, wechselt
der Vorschlag zu „de“.
3.3 Ergebnisse und Auswertung des Nutzertests
94
Abbildung 3-26: TeaShark - Auto-Vervollständigen von Internetadressen
Nachdem der Nutzer einige Internetseiten besucht hat und später ohne Zuhilfenahme
der Verlaufs-Funktion bereits besuchte Webseiten wiederholt aufrufen möchte, bietet
der TeaShark zusätzlich eine Auswahl der vorher eingegebenen Adressen an. Wenn
demnach der Nutzer in die Adresszeile „www.sp“ eingibt, schlägt der TeaShark die
bereits besuchten Webseiten „sport.de“, „sprachen.de“ und „spain.com“ vor. Vorausge-
setzt der Nutzer hat zwischendurch den Cache, welcher die Webseiten zwischenspei-
chert, nicht gelöscht. Alle Tester waren positiv überrascht, als sie bei der Eingabe uner-
wartet vom Browser durch die Funktion Auto-Vervollständigen unterstützt wurden.
Alle genannten bewährten Eigenschaften der verschiedenen Handybrowser wurden e-
benfalls als Gestaltungsempfehlung formuliert und befinden sich im Abschnitt
„6.2 Guidelines für mobile Browser“.
3.3.6 Browserunabhängige Ergebnisse
Bei der Auswertung der einzelnen Findings traten einige Ergebnisse auf, die sich kei-
nem Browser zuordnen ließen, da die Ursachen dafür übergeordneter Natur waren. Sie
ließen sich auf die Handysoftware oder die Gestaltung der Webseiten zurückführen.
Trotzdem sollen diese browserunabhängigen Ergebnisse hier nicht unerwähnt bleiben.
Erstens wird damit gezeigt, dass eine unabhängige Betrachtung des Browsers von des-
sen Umgebung nicht möglich ist und zweitens wird die Sensibilisierung für die zusätz-
3.3 Ergebnisse und Auswertung des Nutzertests
95
lich gefundenen Usability-Probleme erhöht. Eine Auflistung aller browserunabhängigen
Ergebnisse inklusive Screenshot und Empfehlung befindet sich in Anhang G.
Exemplarisch wird hier die Anzeige des Onlinestatus erklärt. Diese Anzeige gibt an, ob
das Handy mit dem Internet verbunden ist oder nicht. Bei dem vorliegenden Nokia-
Handy wurde dies durch ein schwarzes „G“ in einem weißen Rechteck symbolisiert
(Abbildung 3-27). Das Symbol tauchte bei jedem der getesteten Browser am oberen
Bildschirmrand auf. Viele Nutzer konnten es nicht recht deuten („was bedeutet 'G'? Hat
bestimmt irgendwas mit Nokia zu tun!?“).
Abbildung 3-27: Nokia - Symbol der GPRS-Verbindung
Dieses G-Symbol auf Nokia-Handys bedeutet, dass das Handy eine GPRS-Verbindung
hergestellt hat. Durch die kleine Darstellung des Symbols war es für die Nutzer schwer
erkennbar, ob eine Internetverbindung besteht. Dieses Symbol zeigt jedoch an, ob man
online ist und damit Daten empfangen oder verschicken kann. Im Offline-Modus kann
man den Browser nicht im vollen Umfang nutzen. Daher ist es von essentieller Wich-
tigkeit, dass der Online- bzw. Offlinestatus immer klar erkennbar ist.
In diesem Kapitel ging es um die Evaluation der drei Handybrowser mithilfe eines Nut-
zertests. Dargestellt wurden die Planung, die Durchführung und die verschiedenen Er-
gebnisse. Innerhalb der Ergebnisbeschreibung wurden auch einige Schwierigkeiten bei
der Testdurchführung kommentiert. Der Fokus dieses Kapitels lag jedoch auf den ge-
3.3 Ergebnisse und Auswertung des Nutzertests
96
fundenen Usability-Problemen im Nutzertest. Zusammenfassend gesagt entdeckten die
Testnutzer viele Usability-Probleme. Ein Großteil davon trat browserübergreifend auf.
Das bedeutet, dass die getesteten Browser Nokia, Opera Mini und TeaShark ähnliche
Bedienprobleme aufweisen. Gleichzeitig bemängelten die Tester je nach Browser auch
verschiedene Nutzungsprobleme. Zusätzlich zu den Usability-Problemen wurden auch
bewährte Eigenschaften der Browser als Ergebnis vorgestellt. Das bedeutet, dass die
Handybrowser bereits ein gewisses Maß an Benutzerfreundlichkeit besitzen. Anhand
der unterschiedlichen Summe der Usability-Probleme je nach Browser zeigte sich, dass
der Opera Mini insgesamt benutzerfreundlicher ist als die beiden anderen Handybrow-
ser. Ob dieses Ergebnis durch die Experteninspektion bestätigt werden kann, behandelt
das folgende Kapitel.
4.1 Planung der Experteninspektion
97
4 Experteninspektion zur Evaluation der Handybrowser
„Usability experts are from Mars, graphic designers are from Venus.“
Curt Cloninger [www28]
Das vorherige Kapitel hat sich ausführlich mit der Evaluation der Handybrowser durch
einen Nutzertest beschäftigt. Um die Ergebnisse zu überprüfen und zu vervollständigen,
wurde noch ein ergänzender Expertentest in Form einer Heuristischen Evaluation
durchgeführt. Die nachfolgenden Abschnitte beschreiben die Planung, Durchführung
und die Ergebnisse der Experteninspektion.
4.1 Planung der Experteninspektion
Eine Experteninspektion sollte laut Nielsen mit mindestens drei Experten durchgeführt
werden, da ein einziger Gutachter nur 35 Prozent der Usability-Probleme entdeckt
[Nielsen1993]. Dieser Expertentest sollte jedoch lediglich als Ergänzung zum Nutzer-
test dienen und fand daher nur mit einem Gutachter statt.
Wie bereits erwähnt existieren für die Evaluation von mobilen Geräten noch keine an-
erkannten Heuristiken oder Kriterien. Daher wurden für den vorliegenden Expertentest
eigene Heuristiken zusammengestellt. Diese basieren auf den Usabilityanforderungen
von Gong & Tarasewich sowie von Weiss (vgl. Abschnitt „2.3.1 Interface Guidelines
für mobile Endgeräte“). Zum Zeitpunkt der Experteninspektion war der Nutzertest noch
nicht ausgewertet, daher konnten die abgeleiteten Empfehlungen nicht verwendet wer-
den. Die Auswertung wurde bewusst erst nach dem Expertentest vorgenommen, damit
die Ergebnisse der verschiedenen Evaluationen sich nicht gegenseitig beeinflussen und
unabhängig voneinander betrachtet werden konnten.
4.1 Planung der Experteninspektion
98
Die erstellten 21 Heuristiken lassen sich in sechs verschiedene Bereiche einteilen und
werden hier kurz dargestellt:
Menü und Navigation
1. Abgeschlossenheit
2. Top-Down-Interaktion
3. Benutzerkontrolle
Konsistenz
4. Geräteübergreifende Konsistenz
5. Konsistenz innerhalb der Anwendung
Fehlerbehandlung und -vermeidung
6. Aussagekräftiges Feedback
7. Umkehrbarkeit bei begrenzten Ressourcen
8. Fehlervermeidung
9. Umkehrbarkeit
Anpassung
10. Design für vielfältige und dynamische Umgebungen
11. Größenbedingte Faktoren
12. Personalisierung
13. Shortcuts für Vielnutzer
Gestaltung
14. Ästhetik
15. Metaphern
16. Icons zur Konzeptdarstellung
Unterstützung der mobilen Anforderungen
17. Design für User in Bewegung
18. Auswahl statt Eingabe
19. Schneller Wechsel von Anwendungen
20. Eingeschränkte und geteilte Aufmerksamkeit
21. Kurzzeitgedächtnis entlasten
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
99
Die einzelnen Heuristiken wurden jeweils um mehrere Entscheidungsfragen erweitert,
die bei der genaueren Einschätzung helfen sollten. Teilweise wurden die Entscheidungs-
fragen so formuliert, dass gezielt bestimmte Browserfunktionen, die nicht im Nutzertest
überprüft wurden, genauer untersucht werden konnten (vgl. Abschnitt
„3.1.3 Aufgabengestaltung“). Bei Punkt 8 „Fehlervermeidung“ wurden beispielsweise
die drei folgenden Fragen verfasst:
a. Werden Fehler bereits durch die Menüanordnung vermieden?
b. Ist die Tastenbelegung der Softkeys konsistent?
c. Existiert eine Hilfe oder Dokumentation?
Eine komplette Liste der Heuristiken inklusive Entscheidungsfragen befindet sich im
Anhang H.
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspek-
tion
Bei der Durchführung der Experteninspektion nahm ich die Expertenrolle ein und be-
gutachtete die drei verschiedenen Handybrowser nacheinander unter Zuhilfenahme der
erstellten Heuristiken. Ich machte mir Notizen zu den jeweiligen Entscheidungsfragen
sowie sonstigen Auffälligkeiten.
Da lediglich ein Gutachter die Experteninspektion durchführte, können die Ergebnisse
nur subjektiv betrachtet werden. Bei mehreren Gutachtern werden die einzelnen Ergeb-
nisse, z.B. durch den Testleiter, objektiviert. Als Usability-Problem wurde in diesem
Expertentest alles betrachtet, was den Heuristiken widerspricht und damit den mobilen
Anforderungen nicht genügt.
Nach der Durchführung folgte die Auswertungsphase. Die Zuteilung der Prioritätsstufen
zu den einzelnen Usability-Problemen erfolgte nach einem ähnlichen Prinzip wie beim
Nutzertest. Die einzelnen Findings wurden unter Beachtung des Einflusses auf den Nut-
zer sowie der Hartnäckigkeit des Problems mit Prioritätsstufen von 0 (kein Usability-
Problem) bis 4 (katastrophales Problem) bewertet (vgl. Tabelle 2-1: Stufen der Ernst-
haftigkeit von Usability-Problemen [nach Schweibenz2003], S. 21).
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
100
Insgesamt wurden bei der Inspektion 73 Usability-Probleme entdeckt. Einige Ergebnis-
se traten auch browserübergreifend auf. Das heißt, die Anzahl der unterschiedlichen
Usability-Probleme ist kleiner als die Gesamtsumme der aufgetretenen Probleme. Diese
verteilen sich wie folgt auf die einzelnen Browser und Prioritätsstufen:
Tabelle 4-1: Verteilung der Usability-Probleme aus der Experteninspektion auf die einzelnen Browser
Alle Findings im Detail inklusive Screenshots sind im Anhang I zu finden.
Einige Ergebnisse aus dem Nutzertest tauchen auch in der Experteninspektion wieder-
holt auf, z.B. die beschränkte Kapazität der Verlaufsliste beim Nokia-Browser oder dass
Formulardaten erneut eingegeben werden müssen, weil keine Auto-Ausfüllen-Funktion
vorhanden ist. Das doppelte Auftreten dieser Fehler zeigt, dass die angewandten Heuris-
tiken die Probleme der realen Welt widerspiegeln und aussagekräftig gestaltet wurden.
Analog zum Nutzertest lag der Fokus bei der Auswertung der Ergebnisse hauptsächlich
auf den browserübergreifenden sowie schwerwiegenden Usability-Problemen. Aus den
Resultaten wurden ebenfalls Anforderungen an die Gestaltung eines Handybrowsers
formuliert. Diese Empfehlungen werden nachfolgend aufgelistet und anschließend kurz
erklärt.
Abgeleitete Anforderungen an die Gestaltung eines Handybrowsers:
1. Die Bezeichnungen sollten konsistent innerhalb der Anwendung verwendet
werden.
2. Fehlermeldungen sollten aussagekräftig sein und sinnvolle Lösungen anbieten.
3. Der Browser sollte eine Hilfefunktion bereitstellen.
Prioritätsstufe Browser
0 1 2 3 4 Summe
Nokia 0 11 11 9 4 35
Opera Mini 0 5 2 2 4 13
TeaShark 0 5 6 5 9 25
GESAMT 0 21 19 16 17 73
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
101
4. Eine Funktion, welche den Browser automatisch in den Offline-Modus versetzt,
sollte implementiert sein.
5. Der Browser sollte Webseiten in einer einspaltigen Ansicht darstellen können
(Mobil-Ansicht).
6. Mobile Internetseiten sollten bei der Darstellung immer bevorzugt werden.
7. Für die wichtigsten Funktionen sollte der Browser Tastaturkürzel anbieten.
zu 1. Konsistente Bezeichnung
Vor allem bei der Untersuchung des verzweigten Nokia-Menüs und bei der Betrachtung
des TeaShark-Menüs treten innerhalb der Browser unterschiedliche Bezeichnungen für
gleiche Funktionen auf. Beim Nokia-Browser ist dies oft der Fall, wenn das Menü in
verschiedenen Modi aufgerufen wird. Bei geöffneter Webseite tragen zwei Menüpunkte
in den Sicherheitseinstellungen die Bezeichnung „Cookie-Einstellungen“ bzw.
„WMLScript-Einstell.“ (Abbildung 4-1). Wenn jedoch keine Webseite geöffnet ist, sind
diese beiden Menüpunkte unter den Begriffen „Cookies“ und „WMLScr. ü. sich. Verb.“
(Abbildung 4-2) im Menü zu finden.
Abbildung 4-1: Nokia – Bezeichnung „Cookie-Einstellungen“
Abbildung 4-2: Nokia – Bezeichnung „Cookies“
Beim Nokia-Browser lassen sich noch weitere inkonsistente Bezeichnungen finden.
Zum Beispiel trägt der Punkt „Webseite öffnen“ im Hauptmenü später die Bezeichnung
„Zur Adresse“ oder alle Funktionen, die anfangs unter „Einstellungen“ zu finden sind,
befinden sich bei geöffneter Webseite unter dem Begriff „Andere Optionen“. Durch die
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
102
inkonsistente Bezeichnung wird die Navigation innerhalb der Menüstruktur für die Nut-
zer erschwert. Daher sollte eine konsistente Verwendung von Begriffen angestrebt wer-
den.
zu 2. Fehlermeldungen
Unter Punkt 6 der Heuristiken wurden die Browser in Hinblick auf verschiedene Feh-
lermeldungen und deren Aussagekraft untersucht. Beim Versuch die nicht vorhandene
Webseite „www.spiegel.mobil“ aufzurufen, präsentiert der Nokia-Browser folgende
Fehlermeldung „Server belegt. Versuch wiederholen.“. Das ist eine falsche Information.
Denn die Internetadresse existiert nicht und kann daher selbst bei einer Wiederholung
des Aufrufs nie erreicht werden. Eine bessere Fehlerbeschreibung wäre „Server konnte
nicht gefunden werden.“. Idealerweise ergänzt um einen Lösungsvorschlag ähnlich zum
PC-Browser, wie beispielsweise „Überprüfen Sie die Adresse auf Tippfehler.“.
Wenn man versucht beim Browser TeaShark eine nicht vorhandene Webseite zu öffnen,
fällt die Fehlerbehandlung noch schlechter aus. Die Statusmeldung „connecting...“ er-
scheint für etwa 75 Sekunden. Anschließend wird der „Ladevorgang“ ohne jegliche
Status- oder Fehlermeldung abgebrochen. Der Nutzer erhält keine weiteren Informatio-
nen und ist auf sich selbst angewiesen. Dies sollte durch eine aussagekräftige Fehler-
meldung verbessert werden.
Beim Opera Mini benennt beispielsweise eine Fehlermeldung zusätzlich die Javaklasse
(„Die Verbindung ins Internet konnte nicht hergestellt werden. 100 java.lang.Security-
Exception: Permission Denied“). Die genaue Beschreibung der Java-Ausnahme hilft
eventuell einem Entwickler. Für den Nutzer ist die Angabe der Javaklasse jedoch eher
verwirrend und sollte daher vermieden werden.
zu 3. Hilfefunktion
Von allen drei getesteten Handybrowsern bietet nur der Opera Mini-Browser eine Hilfe-
funktion an. Bei den Browsern Nokia sowie TeaShark ist der Nutzer auf sich allein ge-
stellt. Durch das Angebot einer Hilfefunktion kann der Nutzer bei Problemen im Be-
darfsfall nachschlagen. Da Handyanwendungen möglichst wenig Speicherplatz benöti-
gen sollen, kann eine Hilfefunktion zum Beispiel als Verknüpfung auf eine Webseite
realisiert werden (Onlinehilfe). Bei Problemen mit der Herstellung einer Internetverbin-
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
103
dung liegt die Ursache ohnehin meist beim Handy bzw. Netzbetreiber, sodass eine On-
linehilfe für einen Handybrowser eine sinnvolle Erweiterung darstellt.
zu 4. Automatischer Offline-Modus
Sehr auffällig ist, dass kein einziger der evaluierten Browser eine Funktion besitzt, die
es dem Browser erlaubt, nach einer bestimmten Zeit an Inaktivität die Internetverbin-
dung zu trennen. In der Experteninspektion wurde eine Internetseite geöffnet und an-
schließend der Browser für zehn Minuten nicht benutzt. Keiner der Handybrowser zeig-
te daraufhin eine Reaktion. Weder erhält der Nutzer eine Mitteilung, dass der Browser
noch online ist, noch wird die Internetverbindung automatisch getrennt. Durch die ge-
ringe Aufmerksamkeitsspanne und den hohen Ablenkungsfaktor während der Handybe-
dienung, kann es passieren, dass der Nutzer plötzlich abgelenkt wird, z.B. Bus kommt
oder jemand ruft an. Er vergisst, dass er mit seinem Handy online ist und durch die wei-
terhin bestehende Datenverbindung entstehen ihm unnötige Kosten. Daher sollte der
Browser in diesem Punkt unbedingt die mobilen Anforderungen beachten und nach bei-
spielsweise sieben Minuten Inaktivität des Nutzers die Internetverbindung automatisch
trennen und damit in den Offline-Modus wechseln.
zu 5. Mobil-Ansicht
Ein Handydisplay ist viel kleiner als ein Computerbildschirm, daher sollten die Websei-
ten an die veränderte Umgebung angepasst werden. Dies kann dadurch realisiert wer-
den, dass die Entwickler der Webseiten zusätzlich eine mobile Version anbieten, die
kleinere Abmessungen hat und somit für ein Handydisplay optimiert wurde. Eine mobi-
le Webseite ist jedoch mit Aufwand verbunden und nur wenige Webseitenbetreiber bie-
ten diesen zusätzlichen Service an. In dem Fall kann der Handybrowser behilflich sein.
Die Aufgabe eines Browsers ist die Darstellung von Internetseiten, daher könnte der
Browser die Darstellung an das jeweilige Handydisplay anpassen.
Speziell das horizontale Scrollen stört den Lesefluss (Abbildung 4-3) und wird daher
von den Nutzern als sehr hinderlich empfunden. Darum empfehlen einschlägige Usabi-
lity-Richtlinien soweit wie möglich auf horizontales Scrollen zu verzichten [www29].
Der Opera Mini setzt diese Empfehlung durch die Einstellung „Mobil-Ansicht“ um.
Wenn diese aktiviert ist, werden alle aufgerufenen Webseiten mithilfe des Small Screen
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
104
Rendering genau auf die Breite des Handydisplays angepasst (Abbildung 4-4). Durch
die resultierende einspaltige Darstellung wird die Webseite zwar länger, jedoch muss
der Nutzer nicht horizontal scrollen und kann die Webseite daher einfacher lesen. Um
die Usability eines Handybrowsers zu erhöhen, sollte daher unbedingt eine vorherige
Anpassung der Webseitenmaße durch den Browser vorgenommen werden.
Abbildung 4-3: Nokia - horizontales Scrollen er-forderlich
Abbildung 4-4: Opera Mini - Mobil-Ansicht
zu 6. Mobile Internetseiten
Wie bereits erwähnt sind mobile Webseiten gezielt für die Darstellung auf mobilen Ge-
räten konzipiert. Beim TeaShark-Browser tritt das Problem auf, dass er selbst beim ex-
pliziten Aufruf einer mobilen Webseite (www.spiegel.mobi) die normale Webseite
(www.spiegel.de) lädt. Dies darf eigentlich nicht passieren, denn damit wird die Benut-
zerfreundlichkeit für den Nutzer erheblich verringert. Innerhalb der Experteninspektion
konnte der TeaShark von den getesteten, mobilen Webseiten nur die mobile Seite der
Deutschen Bahn (mobil.bahn.de) korrekt darstellen. Bei allen anderen Webseiten zeigte
er stattdessen die normale Webseite an. Ein Handybrowser sollte beim direkten Aufruf
auf jeden Fall die mobile Webseite laden und in allen anderen Fällen die mobile Versi-
on einer Webseite der normalen Webseite bevorzugen. Dies wurde sehr schön bei den
beiden Browsern Nokia sowie Opera Mini umgesetzt. Wenn man die URL
„www.amazon.de“ eintippt, erhält man eine reduzierte Darstellung und weiß, dass man
sich auf der mobilen Version befindet.
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
105
zu 7. Tastaturkürzel
Tastaturkürzel dienen dazu, dass vor allem fortgeschrittene Nutzer schnell bestimmte
Funktionen aufrufen und damit das Handy an ihre Bedürfnisse anpassen können. Be-
sonders im Hinblick auf das mobile Umfeld und dem daraus resultierenden schnellen
Wechsel von Anwendungen sollte der Nutzer durch ein Angebot an Tastaturkürzeln
unterstützt werden. In der Experteninspektion zeigte sich, dass nur der Opera Mini Tas-
taturkürzel unterstützt. Die Tastenbelegung kann man im Hilfe-Menü des Browsers
nachlesen (Abbildung 4-5). Die beiden anderen Browser Nokia und TeaShark bieten
keine Tastaturkürzel an. Für eine schnellere Bedienung sollte jedoch jeder Handybrow-
ser Tastaturkürzel für die wichtigsten Funktionen, z.B. Aufruf eines Lesezeichens oder
Eingabe einer URL, präsentieren.
Abbildung 4-5: Opera Mini - Auflistung der Tastaturkürzel
Dieses Kapitel befasste sich mit der Heuristischen Evaluation der drei Handybrowser.
Als Grundlage für die verwendeten Heuristiken dienten die Interface Guidelines für
mobile Endgeräte, welche noch etwas modifiziert wurden. Die Auswertung zeigte, dass
viele Usability-Probleme in der Experteninspektion auftraten, die bereits im Nutzertest
entdeckt worden. Weiterhin wurden jedoch auch neue Usability-Probleme identifiziert.
Die meisten Usability-Probleme traten in den Kategorien „Fehlerbehandlung und Feh-
lervermeidung“ sowie „Gestaltung“ auf. Wie für Expertentests üblich dominierten auch
in dieser Untersuchung eher die kleineren Mängel. Das beweist, dass sich Nutzer- und
Expertentest gut ergänzen.
4.2 Durchführung, Ergebnisse und Auswertung der Experteninspektion
106
Auch bei der Experteninspektion zeigte sich anhand der Anzahl der Usability-Probleme,
dass der Opera Mini in Bezug auf die Benutzerfreundlichkeit besser als die beiden Ver-
gleichsbrowser abschneidet. Das gute Ergebnis aus dem Nutzertest konnte damit bestä-
tigt werden. Daher dient der Opera Mini als Basis für die Designoptimierung, die im
folgenden Kapitel beschrieben wird.
5.1 Ausgangspunkt
107
5 Entwicklung eines optimierten Designs
„Design is not just what it looks and feels like. Design is how it works.“
Steve Jobs [www30]
Sowohl im Nutzer- als auch im Expertentest wurden wichtige Usability-Probleme auf-
gedeckt. Um nicht nur die Fehler zu offenbaren, sondern auch zu zeigen, wie man die
Probleme beheben und damit die Benutzerfreundlichkeit verbessern kann, wird in die-
sem Kapitel exemplarisch ein optimiertes Browserdesign entwickelt.
5.1 Ausgangspunkt
Als Basis für die Erstellung eines optimierten Designs wurde der Opera Mini 4.0 ge-
wählt. In den beiden durchgeführten Evaluationen zeigte dieser Browser die besten Er-
gebnisse. Beim Nutzertest wurden im Vergleich mit den anderen beiden Browsern ins-
gesamt die wenigsten Usability-Probleme (17) festgestellt. Gleichzeitig erreichte der
Opera Mini auch in der Bewertung durch die Nutzer das beste Ergebnis. Bei der Angabe
einer Reihenfolge nach dem Gefallen wurde der Opera Mini viermal auf Platz eins und
viermal auf Platz zwei genannt (Abbildung 5-1).
Abbildung 5-1: Platzierung der Browser nach Gefallen
Die Testnutzer wurden auch gebeten, die Browser in Bezug auf die Frage: „Wie hat dir
der generelle Umgang mit dem Browser gefallen?“ zu bewerten. Die Skala erstreckte
sich von sehr gut (=1) bis schlecht (=5). Das Diagramm in Abbildung 5-2 zeigt, dass der
5.1 Ausgangspunkt
108
Opera Mini mit einer durchschnittlichen Bewertung von 2,125 am bedienerfreundlichs-
ten eingeschätzt wird. Knapp gefolgt vom Nokia Browser (2,25) und mit einigem Ab-
stand bildet der TeaShark (3,375) das Schlusslicht.
Abbildung 5-2: „Wie hat dir der generelle Umgang mit dem Browser gefallen?“
Bei der zweiten Frage im Bewertungsbogen „Wie oft hattest du Probleme die Bezeich-
nungen im Menü zu deuten?“ konnten die Nutzer aus einer Skala von nie (=1) bis stän-
dig (=5) auswählen. Dabei konnte abermals der Opera Mini mit seinen einfachen Beg-
riffen eine Durchschnittswertung von 1,5 erzielen (Abbildung 5-3) und somit den ersten
Platz verteidigen. Die beiden anderen Browser waren mit einer Bewertung der Bezeich-
nung durch die Nutzer mit 2,25 gleichauf.
Abbildung 5-3: „Wie oft hattest du Probleme die Bezeichnungen im Menü zu deuten?“
5.2 Lösungsempfehlungen zu den zentralen Usability-Problemen
109
Die Experteninspektion bestand der Opera Mini mit insgesamt 13 Fehlern erneut als
bester Browser der Vergleichsgruppe. Die Auswertung der Ergebnisse ergab, dass der
Opera Mini als Vorbild für die anderen beiden Browser dienen kann. Er bietet für viele
der aufgetretenen Usability-Probleme bereits Lösungen zur Umsetzung an, z.B. eine
Eingabeleiste für Internetadressen. Bezüglich dieser Eingabeleiste äußerte ein Tester im
Nutzertest: „meine Leiste“, nachdem er in den ersten beiden Browsertests eine solche
vermisst hatte. Aufgrund der verschiedenen positiven Resultate wurde als Ausgangs-
punkt für die Designoptimierung der Opera Mini 4.0 gewählt.
5.2 Lösungsempfehlungen zu den zentralen Usability-Problemen
Ingesamt wurden bei der Evaluation des Browsers Opera Mini 30 verschiedene Usabili-
ty-Probleme entdeckt. Diese setzen sich aus 17 Findings im Nutzertest und 13 Findings
aus der Experteninspektion zusammen. Bei dieser Summe an aufgetretenen Usability-
Problemen konzentrierte sich die Optimierung der Benutzeroberfläche des Opera Mini
auf die schwersten Fehler aus den beiden Evaluationen. In der Tabelle 5-1 werden daher
nur die Usability-Probleme mit der Prioritätsstufe 3 bzw. 4 inklusive Empfehlungen zur
Optimierung aufgelistet.
Tabelle 5-1: Schwere Usability-Probleme aus Nutzer- und Expertentest mit Empfehlungen für den Opera Mini
Nr. N/E9 Usability-Problem Empfehlung Stufe 1 E Nach dem Auftreten einer Feh-
lermeldung erscheint diese per-manent im Hintergrund. Die Startseite ist daher nicht mehr sichtbar und das Problem kann nur durch einen Neustart beho-ben werden.
Eine Fehlermeldung bzw. Statusmel-dung sollte vier Sekunden zum Lesen verharren und anschließend vollstän-dig verschwinden, damit der Nutzer die Fehlerbehebung starten kann.
4
2 E Hyperlinks sind nicht direkt als solche auf der Webseite erkenn-bar. Sie erscheinen wie normaler Text bis beim Erreichen ein blauer Rahmen erscheint und der geübte User weiß, dass er darauf klicken kann.
Hyperlinks sollten von Anfang an als solche erkennbar sein, z.B. farblich gekennzeichnet durch eine blaue, unterstrichene Darstellung.
4
9 Auftreten des Usability-Problems im Nutzertest (N) oder/und bei der Experteninspektion (E)
5.2 Lösungsempfehlungen zu den zentralen Usability-Problemen
110
Nr. N/E9 Usability-Problem Empfehlung Stufe 3 E Der Browser geht innerhalb von
zehn Minuten Inaktivität nicht automatisch in den Offline-Modus über.
Eine Funktion im Hintergrund sollte nach mindestens sieben Minuten Inaktivität automatisch in den Offli-ne-Modus wechseln.
4
4 N Bei ausgewähltem Formularfeld beginnen die Tester direkt mit der Eingabe. Dies funktioniert jedoch nicht, da das Formular-feld erst bestätigt werden muss. (direkte Eingabe erwartet)
Direkte Eingabe für alle Formularfel-der anbieten, d.h. Feld muss nicht gesondert bestätigt werden, sondern wenn der Cursor sich darin befindet, ist eine Eingabe möglich.
4
5 N + E Formulareingaben müssen nach Änderung einer Option oder Seitenwechsel wiederholt einge-geben werden, da die Daten gelöscht wurden.
Eine Funktion zum Auto-Ausfüllen sollte als Option im Bereich „Einstel-lungen“ angeboten werden. Somit werden Formulardaten gespeichert und stehen auch später noch zur Ver-fügung.
4
6 N Die Nutzer suchen eine Funktion zum Bild speichern unter einem ähnlichen Begriff („Bild spei-chern“ o.ä.) im Hauptmenü. Die Funktion verbirgt sich jedoch im Punkt „Extras“ „Seiteninfor-mation“ „Bilder herunterla-den“.
Der Menüeintrag „Bilder herunterla-den“ sollte direkt im Punkt „Extras“ angeboten werden, damit die Nutzer diesen schneller finden.
4
7 N Zum Speichern eines Bildes versuchen die Nutzer das Bild zu markieren. Dies funktioniert nicht, da der Cursor jegliche Bilder übergeht.
Wenn die Funktion zum Bild spei-chern schneller gefunden wird (vgl. vorherige Empfehlung), muss das Bild nicht markiert werden können. (Falls ein Bild markiert werden könn-te, würde dieses ähnlich wie jeder Hyperlink bei der Navigation ausge-wählt werden. Im Endeffekt würde damit die gesamte Navigation ver-langsamt werden.)
3
8 N Die Nutzer versuchen ein Lese-zeichen anzulegen, indem sie den Lesezeichenbereich durch-suchen. Die Funktion befindet sich im Menü, jedoch hat keiner der Tester das Menü mit der Bezeichnung „Verwalten“ ge-öffnet.
Die Menübezeichnung „Verwalten“ sollte durch „Optionen“ ersetzt wer-den, da dieser Begriff mehr Funktio-nen als nur „Verwalten“ vermuten lässt.
3
9 N Die Nutzer werden nicht gefragt, wo ein zu speicherndes Bild abgelegt werden soll und verlie-ren damit die Nutzerkontrolle.
Den Nutzern sollte ein Speicherort angeboten werden, z.B. „Bilder“, den sie aber nach Belieben ändern kön-nen. Somit erhalten die Nutzer wieder die Kontrolle über ihr Handeln.
3
5.2 Lösungsempfehlungen zu den zentralen Usability-Problemen
111
Nr. N/E9 Usability-Problem Empfehlung Stufe 10 E Es erscheint keine Statusmel-
dung, wenn der Aufruf einer Webseite abgebrochen wird und eine unvollkommene Webseite erscheint als Ergebnis.
Die Statusmeldung „Seitenanforde-rung abgebrochen“ sollte für vier Sekunden erscheinen, damit die Nut-zer eine Bestätigung über ihr Vorge-hen erhalten. Anschließend sollte die alte Ausgangswebseite wieder ange-zeigt werden.
3
11 E Der Browser bietet keine Unter-stützung bei der Eingabe von Internetadressen an.
Durch die Implementierung einer Funktion zum Auto-Vervollständigen bei der Eingabe von Internetadressen wird das umständliche Eintippen verringert und der Nutzer spart Zeit. Der Browser zeigt automatisch be-reits besuchte Seiten an und kann Endungen wie „.de“ oder „.com“ vervollständigen.
3
Bei der Optimierung des Designs wurden hauptsächlich die Usability-Probleme des
Browsers Opera Mini betrachtet, da dieser als Grundlage dient. Die abgeleiteten Anfor-
derungen an das Browserdesign wurden ebenfalls betrachtet. So ist ein Teil der Empfeh-
lungen (vgl. Abschnitt „6.2 Guidelines für mobile Browser“) in die Optimierung einge-
flossen. Zusätzlich wurden bewährte Eigenschaften der beiden Browser Nokia und
TeaShark in die Optimierung einbezogen. In der folgenden Übersicht sind diese zusätz-
lich eingeflossenen Verbesserungen nochmals detaillierter dargestellt:
Empfehlungen aus dem Nutzertest:
• Der Browser sollte eine ausreichende Anzahl an Statusmeldungen anbieten.
• Durch eine integrierte Suchfunktion kann der Nutzer schneller auf einer Websei-
te navigieren.
• Der Online- bzw. Offline-Status sollte ständig und klar sichtbar sein.
Bewährte Eigenschaften der Browser Nokia (N) und TeaShark (TS):
• Das erste Formularfeld auf der Webseite wird automatisch ausgewählt, z.B. auf
der Bahn-Webseite. (N)
• Lesezeichen können mit selbst erstellten Lesezeichen-Ordnern sortiert werden.
(N)
5.3 Vorstellung des optimierten Browsers
112
• Der Cursor wird beim Ladevorgang zur Sanduhr bzw. beim Auswählen zu einer
Hand. (TS)
• Die vollständige Internetadresse wird beim Rollover im Lesezeichenmenü als
Vorschau angezeigt. (TS)
• Die Statusmeldung „Bookmark saved“ erscheint beim Anlegen eines Lesezei-
chens. (TS)
• Durch die Nutzung einer Fly-Out-Darstellung im Menü wird das Menü für den
Nutzer noch übersichtlicher. (TS)
In welcher Form diese Anregungen bei der Designoptimierung umgesetzt wurden, zeigt
der folgende Abschnitt.
5.3 Vorstellung des optimierten Browsers
Bevor die Designoptimierung begann, wurde die Menüstruktur des Opera Mini anhand
der Testergebnisse optimiert und befindet sich als überarbeitete Version im Anhang J.
Im Anschluss erfolgte die Umsetzung des optimierten Designs durch die Erstellung ein-
zelner Szenarien mit dem Grafikprogramm Adobe Illustrator CS3. Ziel dabei war es,
unter Verwendung der abgeleiteten Empfehlungen und Ergebnisse die Nutzerschnitt-
stelle in Bezug auf die Usability zu verbessern. In der Tabelle 5-2 wird jeweils ein
Screenshot des Opera Mini mit der optimierten Version verglichen.
5.3 Vorstellung des optimierten Browsers
113
Tabelle 5-2: Gegenüberstellung der originalen und der optimierten Version des Opera Mini
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
• Menü „Extras“ wurde um die Punkte „Bilder herunterladen“ und „Seite durchsu-chen“ erweitert (6, 7)
• Menü „Extras öffnet sich direkt beim Rollover (Fly-Out)
• Online/Offline-Status ist ständig durch Weltkugel rechts oben ersicht-lich (online = Weltkugel, offli-ne = keine Weltku-gel)
Abbildung 5-4: Opera Mini - Menü „Extras“
Abbildung 5-5: Optimierte Version - Menü „Extras“
• Funktion Auto-Ausfüllen wurde als Option dem Menü „Einstellun-gen“ hinzugefügt (5)
(Die optimierte Dar-stellung wurde im Gegensatz zum Opera Mini größer gewählt. Dadurch sind weniger Menüpunkte sichtbar, können jedoch per Scrollbalken sichtbar gemacht werden)
Abbildung 5-6: Opera Mini - Menü „Einstellungen“
Abbildung 5-7: Optimierte Version - Menü „Einstellungen“
10 Nr. des Usability-Problems aus Tabelle 5-1, welches behoben wurde
5.3 Vorstellung des optimierten Browsers
114
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
• Lesezeichen-Menü wurde um die Punkte „Ordner an-legen“ sowie „Ver-schieben“ erweitert (dieser beinhaltet die vorherigen Funktionen „Nach oben“ bzw. „Nach unten“)
Abbildung 5-8: Opera Mini - Menü „Lesezeichen“
Abbildung 5-9: Optimierte Version - Menü „Lesezeichen“
• Menübezeichnung „Verwalten“ wurde durch „Optionen“ ersetzt (8)
• Internetadresse des Lesezeichens wird beim Rollover in einer Voransicht oben rechts ange-zeigt
Abbildung 5-10: Opera Mini – Über-sicht Lesezeichen
Abbildung 5-11: Optimierte Version - Übersicht Lesezeichen
5.3 Vorstellung des optimierten Browsers
115
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
• Erkennen von Hyperlinks wurde durch blauen Un-terstrich verein-facht (2)
• wenn der Browser lädt, ändert sich auch der Cursor zu einem Zeiger mit Sanduhr
Abbildung 5-12: Opera Mini - Hyper-links schlecht erkennbar
Abbildung 5-13: Optimierte Version - Hyperlinks blau markiert
• Durch das Vermei-den einer separaten Eingabemaske (O-riginal) wird die direkte Eingabe ermöglicht (4). Die Eingabe erfolgt di-rekt im Formular (optimierte Versi-on) und der Einga-bemodus wird durch ein Stiftsym-bol rechts oben er-kenntlich.
• Damit wird eine Bestätigung durch „OK“ überflüssig und der Nutzer kann direkt mit Hilfe der Tasten ins nächste Feld sprin-gen
Abbildung 5-14: Opera Mini - Einga-bemaske für Formulardaten
Abbildung 5-15: Optimierte Version - direkte Eingabe von Formulardaten
5.3 Vorstellung des optimierten Browsers
116
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
• Beim Speichern von Bildern ist der Speicherort „Fo-tos“ schon ausge-wählt, kann aber vom Nutzer geän-dert werden (9)
• Der Cursor ändert seine Form bei der Auswahl zu einer Hand
Abbildung 5-16: Opera Mini - Bild gespeichert
Abbildung 5-17: Optimierte Version - Speicherort für Bild wählbar
• Nach dem Abbruch eines Ladevor-gangs erscheint die Statusmeldung „Seitenaufbau ab-gebrochen“ für vier Sekunden sowie anschließend die alte Ausgangsweb-seite
keine Statusmeldung, daher kein Screenshot verfügbar
Abbildung 5-18: Optimierte Version - Statusmeldung „Seitenaufbau ab-gebrochen“
5.3 Vorstellung des optimierten Browsers
117
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
• Durch das Vermei-den einer separaten Eingabemaske ist die Webseite im Hintergrund stän-dig sichtbar
• Durch die Funktion Auto-Vervollständigen werden bereits be-suchte Seiten, die zur Adresse passen (hier mit „sp“), an-gezeigt und der Nutzer muss nur noch Auswählen statt Eingeben (11)
Abbildung 5-19: Opera Mini - Einga-bemaske für URLs
Abbildung 5-20: Optimierte Version - Funktion Auto-Vervollständigen
• Eine Suchfunktion innerhalb der Web-seite wurde dem Browser hinzuge-fügt: Suchleiste er-scheint am unteren Rand, Eingabemo-dus wieder durch Stiftsymbol ersicht-lich, Suche beginnt direkt bei der Ein-gabe
Funktion war vorher nicht vorhan-den, daher kein Screenshot
Abbildung 5-21: Optimierte Version - integrierte Suchfunktion
5.3 Vorstellung des optimierten Browsers
118
Was wurde opti-miert? (Nr.)10
originale Version optimierte Version
Nach dem Speichern eines Lesezeichens erscheint die Status-meldung „Lesezei-chen gespeichert“ für vier Sekunden
keine Statusmeldung, daher kein Screenshot verfügbar
Abbildung 5-22: Optimierte Version - Statusmeldung „Lesezeichen gespei-chert“
Dieses Kapitel befasste sich mit der Erstellung eines optimierten Browserdesigns. Dazu
wurde der Opera Mini als nutzerfreundlichster seiner Vergleichsgruppe als Ausgangs-
punkt gewählt. Darauf aufbauend wurden die schwerwiegendsten Usability-Probleme
des Opera Mini aus den beiden Evaluationen sowie die positiven Eigenschaften der bei-
den anderen Browser in die Optimierung einbezogen. Das resultierende Design wurde
anschließend anhand von grafischen Szenarien vorgestellt.
6.1 Zusammenfassung der Ergebnisse
119
6 Fazit
„The mobile user experience will be influenced by user interface, the application in the
terminal, the operator’s solutions, the service provider’s way of presenting service
content, and the quality of the content itself.“
Turkka Keinonen [Keinonen2003]
6.1 Zusammenfassung der Ergebnisse
Die vorliegende Diplomarbeit beschäftigt sich mit der Überprüfung der Benutzerfreund-
lichkeit von verschiedenen mobilen Browsern sowie der exemplarischen Optimierung
der Benutzerschnittstelle eines Browsers.
Zur Einführung in das Thema wurde die theoretischen Grundlagen zum mobilen Inter-
net und zur Usability erläutert. Besonders wurde dabei auf die speziellen Usabilityan-
forderungen an mobile Anwendungen eingegangen. Hauptgegenstand der Diplomarbeit
war die Durchführung eines Nutzertests zur Evaluierung der mobilen Browser. Im Nut-
zertest kam es vor allem darauf an, die wichtigsten Funktionen eines Handybrowsers zu
untersuchen. Anschließend wurde eine ergänzende Experteninspektion in Form einer
Heuristischen Evaluation durchgeführt. Als Grundlage für die verwendeten Heuristiken
dienten die Interface Guidelines für mobile Endgeräte, welche für den Expertentest
noch etwas modifiziert wurden.
Insgesamt zeigte sich in den Ergebnissen, dass im Nutzertest eher größere und bei der
Experteninspektion eher kleinere Fehler aufgedeckt wurden. Zusammenfassend traten
viele Usability-Probleme bei zwei oder sogar allen drei Browsern auf. Das zeigt, dass
die getesteten Browser allgemein mit ähnlichen Bedienproblemen hadern. Das doppelte
Auftreten einzelner Usability-Probleme sowohl im Nutzer- als auch im Expertentest
belegt, dass die angewandten Guidelines sich gut als Heuristiken eignen, da sie die An-
forderungen der Nutzer widerspiegeln. Alles in allem führen die Ergebnisse zu der
Schlussfolgerung, dass die Usability der verwendeten Browser besser als erwartet ist
und demnach eine untergeordnete Rolle für die eher zurückhaltende Nutzung des mobi-
len Internets darstellt.
6.1 Zusammenfassung der Ergebnisse
120
Sowohl im Nutzertest als auch in der Experteninspektion schnitt der Opera Mini in Be-
zug auf die Benutzerfreundlichkeit als bester seiner Vergleichsgruppe ab. Anhand der
gesammelten Ergebnisse wurden für alle aufgetretenen Usability-Probleme Lösungsvor-
schläge entworfen und auf der Basis des Opera Mini eine optimierte Version erstellt.
Die Optimierung umfasste das Design und die Funktionalität der Nutzerschnittstelle. In
einem idealen Entwicklungsprozess müsste das optimierte Design einem weiterem Nut-
zertest unterzogen werden, damit überprüft werden kann, ob das neue Design tatsäch-
lich benutzerfreundlicher ist.
Innerhalb der Diplomarbeit wurde auch überprüft, ob die freien, javabasierten Handy-
browser eine höhere Usability als der Standardbrowser aufweisen. In der vorliegenden
Untersuchung wurden der Standardbrowser Nokia und die beiden freien Browser Opera
Mini und TeaShark getestet. Sowohl im Nutzertest als auch in der Experteninspektion
konnte der Opera Mini die wenigsten Usability-Probleme aufweisen. Dahinter folgte der
Browser TeaShark und die meisten Usability-Probleme traten beim Nokia-Browser auf.
Die Auswertung der Fragebögen ergab, dass die Tester im Durchschnitt den TeaShark-
Browser im generellen Umgang schlechter als die beiden anderen bewerteten. Bei den
Fragen nach der Verständlichkeit der Bezeichnungen sowie der Bewertung der allge-
meinen Zufriedenheit erzielten die beiden Browser Nokia und TeaShark durchschnitt-
lich das gleiche Ergebnis (vgl. Abbildung 5-1 ff.), obwohl beim Nokia-Browser nach-
weislich die meisten Usability-Probleme auftraten. Dies könnte daran liegen, dass die
Bewertungen nur auf den Aussagen der Nutzer aus den Fragebögen beruhen, während
bei den Usability-Problemen auch die Notizen durch den Beobachter betrachtet wurden.
Das bestätigt die Aussage, dass die Beobachtung eine wichtige Rolle in einem Nutzer-
test einnimmt.
Anhand dieser Diplomarbeit lässt sich daher keine allgemeine Schlussfolgerung über
die unterschiedliche Usability von Standardbrowsern und freien Handybrowsern ziehen.
Man kann jedoch sagen, dass die Benutzerfreundlichkeit der freien Browser keineswegs
schlechter ist als bei den vorinstallierten Browsern. Die Usability kann demnach nur
modellabhängig betrachtet werden. Persönlich empfehle ich den Umstieg auf einen frei-
6.1 Zusammenfassung der Ergebnisse
121
en Browser, da diese Version einfacher und schneller aktualisiert werden kann als ein
vorinstallierter Browser.
Dass die Entwicklung der freien Browser ständig voranschreitet, zeigt auch der folgen-
de Bericht. Am 24.03.2008 wurde eine neue Version des TeaShark (0.9 Beta) veröffent-
licht. Kurze Zeit später am 02.04. folgte Opera ebenfalls mit einer neuen Version des
Opera Mini (4.1 beta). Beide Versionen wurden erst nach Abschluss des Nutzertests
veröffentlicht, sodass diese leider nicht getestet werden konnten. Ein interessanter As-
pekt ist, dass die Hersteller in ihren neuen Versionen auch Funktionen anbieten, deren
Fehlen in diesem Nutzertest bemängelt wurde. Das heißt, die Softwareentwickler müs-
sen zu ähnlichen Ergebnissen wie in dieser Diplomarbeit gelangt sein und setzen diese
in ihren neuen Versionen um. Als Beispiel sei das Auto-Vervollständigen von Adressen
oder die integrierte Suche auf Webseiten beim neuen Opera Mini genannt. Die neue
Version des TeaShark bietet inzwischen eine direkte Eingabe sowie die Option zum
Auto-Ausfüllen von Formulardaten an. Die Entwicklungen der Browserhersteller bestä-
tigen demnach die Ergebnisse dieser Diplomarbeit.
Eine Anmerkung zum Browser TeaShark soll nicht unerwähnt bleiben. Weder auf des-
sen Webseite noch in der Browsersoftware selbst lässt sich erkennen, welches Unter-
nehmen hinter der Entwicklung des TeaShark steckt. Da bei diesem Browser ähnlich
wie beim Opera Mini alle Daten auf einem Proxyserver vorverarbeitet werden, sollte
man den TeaShark vor allem im Umgang mit sensitiven Daten Vorsicht kritisch be-
trachten.
Diese Diplomarbeit hat durch das Auffinden von browserunabhängigen Ergebnissen
gezeigt, dass die Usability eines mobilen Browsers nicht unabhängig vom Kontext be-
trachtet werden kann. Schlussendlich ist die Benutzerfreundlichkeit einer mobilen An-
wendung ein Zusammenspiel verschiedener Faktoren. Sie setzt sich aus der Usability
der Anwendung, der Benutzerfreundlichkeit des Handys sowie der mobilen Inhalte
(Webseiten) zusammen.
6.2 Guidelines für mobile Browser
122
6.2 Guidelines für mobile Browser
Alle abgeleiteten Anforderungen aus Nutzertest und Experteninspektion sowie die be-
währten Eigenschaften der Browser und die browserunabhängigen Ergebnisse werden
im Folgenden zusammengefasst und als Guidelines für die Gestaltung eines mobilen
Browsers vorgeschlagen.
Nutzertest
1. Der Menübalken sollte ständig sichtbar sein.
2. Die Menüstruktur sollte übersichtlich und intuitiv zu bedienen sein.
3. Lieber weniger Menüfunktionen anbieten, aber dafür eine übersichtliche Dar-
stellung gewährleisten.
4. Zur Eingabe von Internetadressen (URL) sollte eine grafische Darstellung einer
Eingabeleiste (ähnlich PC-Browser) auf der Startseite vorhanden sein.
5. Der Ladevorgang sowie dessen Fortschritt sollten deutlich erkennbar sein.
6. Die Navigation mit der Maus sollte kontinuierlich, d.h. stetig, funktionieren.
7. Eine Zoomübersicht sollte nur auf nicht-mobilen Webseiten erscheinen und die
Möglichkeit zum schnellen Umschalten zwischen Zoom und normaler Ansicht
sollte bestehen.
8. Der Nutzer sollte nach der Auswahl eines Formularfelds direkt Daten eingeben
können sowie mit den Navigationstasten zwischen den einzelnen Formularfel-
dern navigieren können.
9. Formulardaten sollten gespeichert und soweit möglich übernommen werden
(Auto-Ausfüllen).
10. Bereits besuchte Webseiten (Verlauf) sollte der Browser in Listenform darstel-
len.
11. Ein schneller Zugang zur Funktion „Bilder herunterladen“ sollte ermöglicht
werden.
12. Der Browser sollte eine ausreichende Anzahl an Statusmeldungen anbieten.
bewährte Eigenschaften
13. Die Funktion zum Abbrechen eines Ladevorgangs sollte nur dann angeboten
werden, wenn ein Ladevorgang stattfindet.
14. Ein Cursor erleichtert die Navigation innerhalb der Webseiten.
6.2 Guidelines für mobile Browser
123
15. Durch eine integrierte Suchfunktion kann der Nutzer schneller auf einer Websei-
te navigieren.
16. Die Eingabe von Webseiten sollte soweit wie möglich durch automatisches Ver-
vollständigen von Adressen unterstützt werden.
browserunabhängige Ergebnisse
17. Der Online- bzw. Offline-Status sollte ständig und klar sichtbar sein.
Experteninspektion
18. Die Bezeichnungen sollten konsistent innerhalb der Anwendung verwendet
werden.
19. Fehlermeldungen sollten aussagekräftig sein und sinnvolle Lösungen anbieten.
20. Der Browser sollte eine Hilfefunktion präsentieren.
21. Eine Funktion, welche den Browser automatisch in den Offline-Modus versetzt,
sollte implementiert sein.
22. Der Browser sollte Webseiten in einer einspaltigen Ansicht darstellen können
(Mobil-Ansicht).
23. Mobile Internetseiten sollten bei der Darstellung immer bevorzugt werden.
24. Für die wichtigsten Funktionen sollte der Browser Tastaturkürzel anbieten.
Literaturverzeichnis
124
Literaturverzeichnis
Chan2002 Chan, S., Fang, X., Brzezinski, J., Zhou, Y., Xu, S. & Lam, J.: „Usability for mobile commerce across multiple form factors“ In: Journal of Electronic Commerce Research, Vol. 3, No. 3, 2002 Abrufbar unter: www.csulb.edu/web/journals/jecr/issues/20023/paper7.pdf
Dahm2006 Dahm, Markus: Grundlagen der Mensch-Computer-Interaktion. München: Pearson Studium, 2006
DIN1999 DIN EN ISO 9241-11:1999: Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten. Teil 11: Anforderungen an die Gebrauchstauglichkeit. 1999
Dumas1999 Dumas, Joseph & Redish, Janice: A Practical Guide to Usabil-ity Testing. Exeter: Intellect Books, 1999
Gong2004 Gong, Jun & Tarasewich, Peter: Guidelines for Handheld Mo-bile Device Interface Design, College of Computer and Infor-mation Science, Northeastern University, Boston, 2004 Abrufbar unter: http://www.ccs.neu.edu/home/tarase/GuidelinesGongTarase.pdf
Heinsen2003 Heinsen, Sven & Vogt, Petra: „Usability – darum geht’s“ In: Heinsen, Sven & Vogt, Petra (Hrsg.): Usability praktisch um-setzen. München, Wien: Hanser Verlag, 2003
Keinonen2003 Keinonen, Turkka: „Introduction – Mobile Distinctions“ In: Lindholm, Christian & Keinonen, Turkka & Kiljander, Harri (Hrsg.): Mobile Usability: How NOKIA changed the Face of the Mobile Phone. McGraw-Hill Professional, 2003
Kiljander2003 Kiljander, Harri & Järnström, Johanna: „User Interface Styles“ In: Lindholm, Christian & Keinonen, Turkka & Kiljander, Har-ri (Hrsg.): Mobile Usability: How NOKIA changed the Face of the Mobile Phone. McGraw-Hill Professional, 2003
Kjeldskov2004 Kjeldskov, Jesper & Stage, Jan: „New Techniques for Usabil-ity Evaluation of Mobile Systems“ In: International Journal of Human-Computer Studies, Vol. 60, No. 5-6, May 2004
Korzenek2007 Korzenek, Christoph: Usability-Anforderungen für mobile An-wendungen. Universität Leipzig, Institut für Informatik, Semi-nararbeit, 2007
Krug2000 Krug, Steve: Don’t make me think! A Common Sense Approach to Web Usability. Pearson Education, 2000
Literaturverzeichnis
125
Lindholm2003 Lindholm, Christian & Keinonen, Turkka & Kiljander, Harri: „Usability für mobile Anwendungen“ In: Lindholm, Christian & Keinonen, Turkka & Kiljander, Harri (Hrsg.): Mobile Us-ability: How NOKIA changed the Face of the Mobile Phone. McGraw-Hill Professional, 2003
Lorenzen-Schmidt2003 Lorenzen-Schmidt, Olde: „Testpersonen rekrutieren“ In: Hein-sen, Sven & Vogt, Petra (Hrsg.): Usability praktisch umsetzen. München, Wien: Hanser Verlag, 2003
Nielsen1993 Nielsen, Jakob: Usability Engineering. San Diego: Morgan Kaufmann, 1993
Oulasvirta2005 Oulasvirta, Antti: The Fragmentation of Attention in Mobile Interaction, and What to Do with It. Interactions, Vol. 12, No. 6, 2005. Abrufbar unter: http://www.hiit.fi/u/oulasvir/scipubs/p16-oulasvirta.pdf
Rischpater2000 Rischpater, Ray: WAP und WML. Bonn: Galileo Press GmbH, 2000
Röse2003 Röse, Kerstin: „Task-Analyse“ In: Heinsen, Sven & Vogt, Pet-ra (Hrsg.): Usability praktisch umsetzen. München, Wien: Hanser Verlag, 2003
Roth2005 Roth, Jörg: Mobile Computing. Heidelberg: dpunkt.verlag GmbH, 2005
Schweibenz2003 Schweibenz, Werner & Thissen, Frank: Qualität im Web: Be-nutzerfreundliche Webseiten durch Usability Evaluation. Ber-lin, Heidelberg: Springer-Verlag, 2003
Silfverberg2003 Silfverberg, Miika: „The One-Row Keyboard – A Case Study in Mobile Text Input“ In: Lindholm, Christian & Keinonen, Turkka & Kiljander, Harri (Hrsg.): Mobile usability: how No-kia changed the face of the mobile phone. McGraw-Hill Pro-fessional, 2003
Weiss2002 Weiss, Scott: Handheld Usability. Chichester: John Wiley & Sons Ltd, 2002
Internetquellen
126
Internetquellen
www01 Dilbert Comic http://web.mit.edu/is/usability/IAP/2003/Session1/slide2-0.html [Stand 20.05.2008]
www02 Mobile Web Design http://mobilewebbook.com [Stand 21.05.2008]
www03 New launches http://www.newlaunches.com/archives/nokia_n95_is_offic-ial.php [Stand 21.05.2008]
www04 HandysMobile http://www.handys-mobile.de/lexikon [Stand 06.06.2008]
www05 My Docs Online http://www.mydocsonline.com/wap_phone.html [Stand 09.06.2008]
www06 Heise-Artikel: i-mode ist am Ende http://www.heise.de/newsticker/i-mode-ist-am-Ende--/meldung/105380� [Stand 04.06.2008]
www07 Inside Windows http://microsoft.apress.com/asptodayarchive/72935/the-vsnet-command-window [Stand 03.06.2008]
www08 Wikipedia http://de.wikipeda.org [Stand 05.02.2008]
www09 BITKOM-Presseinformation: UMTS-Anschlüsse http://www.bitkom.org [Stand 21.02.2008]
www10 M:Metrics http://www.mmetrics.com/press/PressRelease.aspx?article=20080415-malestats [Stand 21.05.2008]
www11 World Wide Web Consortium http://www.w3.org [Stand 16.04.2008]
Internetquellen
127
www12 Open Mobile Alliance http://www.openmobilealliance.org [Stand 16.04.2008]
www13 United Nations Conference on Trade and Development http://www.unctad.org/Templates/webflyer.asp?docid=9479&intItemID=1397&lang=1&mode=downloads [Stand 29.05.2008]
www14 Fachhochschule für Technik und Wirtschaft Berlin – Internationale Medieninformatik http://www.f4.fhtw-berlin.de/~weberwu/MMA1/links.shtml [Stand 06.06.2008]
www15 Nielsen, Jakob Alertbox „Severity Ratings for Usability Problems“ http://www.useit.com/papers/heuristic/severityrating.html [Stand 27.03.2008]
www16 Nielsen, Jakob Alertbox „Why you only need to test mit 5 users“ http://www.useit.com/alertbox/20000319.html [Stand 20.05.2008]
www17 Nielsen, Jakob Alertbox „First Rule of Usability? Don't Listen to Users“ http://www.useit.com/alertbox/20010805.html [Stand 07.04.2008]
www18 Handbuch Usability http://www.handbuch-usability.de [Stand 08.06.2008]
www19 Nielsen, Jakob Papers & Essays „How to Conduct a Heuristic Evaluation“ http://www.useit.com/papers/heuristic/heuristic_evaluation.html [Stand 08.04.2008]
www20 Nielsen, Jakob Papers & Essays „Ten Usability Heuristics“ http://www.useit.com/papers/heuristic/heuristic_list.html [Stand 02.06.2008]
www21 Nielsen, Jakob Alertbox „Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier“ http://www.useit.com/papers/guerrilla_hci.html [Stand 08.04.2008]
www22 Wikiquote http://en.wikiquote.org/wiki/Bjarne_Stroustrup [Stand 09.05.2008]
Internetquellen
128
www23 MobileWeb Metrix http://www.comscore.com/press/release.asp?press=1693 [Stand 31.03.2008]
www24 T-Mobile http://www.t-mobile.de [Stand 10.05.2008]
www25 Opera Mini http://www.operamini.com/beta/tour/ [Stand 19.05.2008]
www26 Opera Mini – Small Screen Rendering http://www.dornhoff.net/wp-content/uploads/2006/01/operaminischeme1.png [Stand 03.06.2008]
www27 Heise-Artikel: Ab ins Web – Browser für Handys und Smartphones http://www.heise.de/mobil/Browser-fuer-Handys-und-Smartphones--/artikel/92414/6 [Stand 15.05.2008]
www28 A List Apart Magazine http://www.alistapart.com/topics/userscience/usability/ [Stand 06.06.2008]
www29 Nielsen, Jakob Alertbox „Scrolling and Scrollbars“ http://www.useit.com/alertbox/20050711.html [Stand 20.05.2008]
www30 World Usability Day Quotation Posters http://www.userfocus.co.uk/resources/posters.html [Stand 06.06.2008]
Anhang
129
Anhang
Anhang A – Dokumente zum Nutzertest ..................................................................130
Anhang B – Bewertungsbogen zum Browser ...........................................................131
Anhang C – Ergebnisse Nutzertest Opera Mini.......................................................133
Anhang D – Ergebnisse Nutzertest Nokia.................................................................137
Anhang E – Ergebnisse Nutzertest TeaShark ..........................................................146
Anhang F – bewährte Eigenschaften der Browser ..................................................152
Anhang G – browserunabhängige Ergebnisse .........................................................155
Anhang H - Heuristiken .............................................................................................158
Anhang I – Ergebnisse der Experteninspektion.......................................................162
Anhang J – Menüstruktur der Browser ...................................................................163
Anhang K – Inhaltsverzeichnis CD ...........................................................................164
Anhang A – Dokumente zum Nutzertest
130
Anhang A – Dokumente zum Nutzertest
Dieser Anhang befindet sich auf der beiliegenden CD in dem Ordner „Nutzertest“.
Dazu gehören folgende Dokumente:
• Begleitskript für Testleiter und Moderator (Begleitskript.pdf)
• Fragebogen zu den soziodemografischen Daten der Nutzer (Fragebogen.pdf)
• Notizenvordrucke für den Beobachter aufgeteilt nach Browsern:
- Nokia (Notizenvordruck_Nokia.pdf)
- Opera Mini (Notizenvordruck_Opera Mini.pdf)
- TeaShark (Notizenvordruck_TeaShark.pdf)
Anhang B – Bewertungsbogen zum Browser
131
Anhang B – Bewertungsbogen zum Browser
Browser: ________________________________
getestet als Nr.: 1 2 3
Schlecht Sehr gut
Wie hat dir der generelle Umgang mit dem Browser gefallen?
Nie Ständig
Wie oft hattest du Probleme die Be-zeichnungen im Menü zu deuten?
Welche Funktionen hast du vermisst? Was würdest du dir noch wünschen?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Gab es unklare Begriffe? Fehlten dir Informationen?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Testperson Nr.: _______
Anhang B – Bewertungsbogen zum Browser
132
Was hat dir am meisten gefallen?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Was hat dich am meisten gestört?
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
Danke für’s Ausfüllen!
Anhang C – Ergebnisse Nutzertest Opera Mini
133
Anhang C – Ergebnisse Nutzertest Opera Mini
Tabelle 6-1: Ergebnisse des Nutzertests vom Opera Mini-Browser
Finding Zitate Screenshot Stufe Empfehlung
Webseite aufrufen
für die Adress- & For-mulareingabe öffnet sich ein separates Fens-ter, welches die aktuelle Webseite verdeckt
2 Anstatt einem neuen Fens-ter sollte ein Eingabemo-dus auf der Webseite ge-öffnet werden (direkte Eingabe).
Cursor steht bei Einga-be von Internetadressen am Anfang des Formu-larfelds
2 Cursor sollte sich nach dem „www.“ befinden, damit der Nutzer direkt eingeben kann.
Formulareingabe
Bei ausgewähltem Formularfeld beginnen die Tester direkt mit der Eingabe. Dies funktio-niert jedoch nicht, da das Formularfeld erst bestätigt werden muss. (direkte Eingabe erwar-tet)
„einfach los schreiben ist nicht“ „Ah – reinkli-cken“ „ständig reinkli-cken war nicht so der Hammer“ „wenn man das gelernt hat, sind das Klicks, die man sparen wür-de, aber die nicht kriegsentschei-dend sind“
4 Direkte Eingabe für alle Formularfelder anbieten, d.h. Feld muss nicht ge-sondert bestätigt werden, sondern wenn der Cursor sich darin befindet, ist eine Eingabe möglich.
Die Eingabe muss im-mer bestätigt werden. Nutzer erwarten, dass sie mit den Navigati-onstasten zum nächsten Feld springen kann.
„zweimal 'OK' für Eingabe - das ist doof“
2 Die Eingabe muss nicht extra bestätigt werden. Bei Nutzung der Navigations-tasten springt der Cursor in das nächste Formularfeld bzw. den nächsten Button an.
Anhang C – Ergebnisse Nutzertest Opera Mini
134
Finding Zitate Screenshot Stufe Empfehlung
Formulareingaben müs-sen nach Änderung einer Option oder Sei-tenwechsel wiederholt eingegeben werden, da die Daten gelöscht wurden.
„muss alles neu eingetippt werden, was mich ziemlich ärgert“
4 Eine Funktion zum Auto-Ausfüllen sollte als Option im Bereich „Einstellun-gen“ angeboten werden. Somit werden Formularda-ten gespeichert und stehen auch später noch zur Ver-fügung.
Navigation auf und zwischen Webseiten
Cursor befindet sich ganz unten auf der Webseite mobil.bahn.de
2 Da die wichtigsten Infor-mationen und Felder oben auf der Webseite erschei-nen, sollte der Cursor dort platziert werden. In sol-chen Fällen ist es für den Nutzer zeitsparend, wenn sich der Cursor direkt im ersten Eingabefeld befin-det, vor allem da diese spezielle Webseite nur diese Funktion (der Bahn-auskunft) anbietet.
Bedeutung der „Vor“-Funktion ist für den Nutzer unklar
2 Damit die Vor-Funktion zum Blättern zwischen Seiten erkannt wird, sollte sie in unmittelbarer Nähe der „Zurück“-Funktion angeboten werden.
Zoom-Übersicht er-scheint bei nicht-mobilen Webseiten unerwartet
„oh, solche Scherze hatte ich nicht erwartet“
2 In einem obligatorischen Anfangstutorial sollten die wichtigsten Funktionen kurz erläutert werden. Tutorial kann später auch über den Menüpunkt „Hil-fe“ „Tutorial“ aufgeru-fen werden.
Verlauf
in der Verlaufsliste ist nicht der komplette Webseiten-Titel er-kennbar (nur 28 Zei-chen möglich)
1 Eine Erweiterung der Ti-telanzeige auf max. 30 Zeichen sichert gleichzei-tig die Lesbarkeit ab.
Anhang C – Ergebnisse Nutzertest Opera Mini
135
Finding Zitate Screenshot Stufe Empfehlung
Leszeichen aufrufen
Menüpunkt „Lesezei-chen aufrufen“ wird im Lesezeichen-Menü erwartet
1 Die Funktion „Aufrufen“ sollte im Lesezeichen-Menü alternativ zum Klick angeboten werden.
Lesezeichen anlegen
Die Nutzer versuchen ein Lesezeichen anzu-legen, indem sie den Lesezeichenbereich durchsuchen. Die Funk-tion befindet sich im Menü, jedoch hat keiner der Tester das Menü mit der Bezeichnung „Verwalten“ geöffnet.
„Lesezeichen anlegen geht hier auch, könnte man mir auch eher anzeigen“ „Lesezeichen [Menü] - das hilft nicht“
3 Die Menübezeichnung „Verwalten“ sollte durch „Optionen“ ersetzt werden, da dieser Begriff mehr Funktionen als nur „Ver-walten“ vermuten lässt.
Daten downloaden (Bild)
Die Nutzer suchen eine Funktion zum Bild speichern unter einem ähnlichen Begriff („Bild speichern“ o.ä.) im Hauptmenü. Die Funktion verbirgt sich jedoch im Punkt „Ex-tras“ „Seiteninfor-mation“ „Bilder herunterladen“.
„extrem schlecht... ich glaube, ich könnte das gar nicht noch mal machen“ „keine Idee auf was ich klicken sollte“ „geht.. aber mehr so Zufall“ „wie speichere ich Bild?“
4 Der Menüeintrag „Bilder herunterladen“ sollte direkt im Punkt „Extras“ angebo-ten werden, damit die Nutzer diesen schneller finden.
Zum Speichern eines Bilds versuchen die Nutzer das Bild zu markieren. Dies funkti-oniert nicht, da der Cursor jegliche Bilder übergeht.
„was nicht mar-kierbar ist, ist nicht speicher-bar“ „auf Bild selber komm ich nicht drauf“
3 Wenn die Funktion zum Bild speichern schneller gefunden wird (vgl. vorhe-rige Empfehlung), muss das Bild nicht markiert werden können. (Falls ein Bild markiert werden könnte, würde dieses ähn-lich wie jeder Hyperlink bei der Navigation ausge-wählt werden. Im Endef-fekt würde damit die ge-samte Navigation verlang-samt werden.)
Anhang C – Ergebnisse Nutzertest Opera Mini
136
Finding Zitate Screenshot Stufe Empfehlung
bis ein ausgewähltes Bild auf dem Handy gespeichert werden kann, müssen die Nut-zer dies anhand von fünf verschiedenen Schritten bestätigen
2 Die Bestätigung zum Her-unterladen sollte auf ein Minimum reduziert wer-den.
Die Nutzer werden nicht gefragt, wo ein zu speicherndes Bild abge-legt werden soll und verlieren damit die Nutzerkontrolle.
3 Den Nutzern sollte ein Speicherort angeboten werden, z.B. „Bilder“, den sie aber nach Belieben ändern können. Somit erhalten die Nutzer wieder die Kontrolle über ihr Handeln.
Statusmeldungen
Statusmeldung, dass Lesezeichen gespei-chert wurde, wird er-wartet
„Statusmeldung wäre schön“
1 Die Statusmeldung „Lese-zeichen gespeichert“ sollte für 2 Sekunden auf dem Display angezeigt werden.
Menü
bei ausgewählter Tele-fonnummer auf einer Webseite ist die Funk-tion Anrufen nicht als Menüpunkt vorhanden, sondern nur durch die grünen Hörer-Taste oder Bestätigen-Taste aufrufbar (keine Be-schriftung)
2 Wenn eine Telefonnum-mer auf einer Webseite ausgewählt wurde, sollte der Menüpunkt „Anrufen“ in der Mitte (für Bestäti-gen-Taste) angeboten werden.
Anhang D – Ergebnisse Nutzertest Nokia
137
Anhang D – Ergebnisse Nutzertest Nokia
Tabelle 6-2: Ergebnisse des Nutzertests vom Nokia-Browser
Finding Zitate Screenshot Stufe Empfehlung
Webseite aufrufen
Nutzer erwarten grafische Eingabe-leiste für Internetad-ressen auf der Start-seite
„'Abbrechen' wird direkt angeboten, aber keine Einga-beleiste“
4 Eine grafische Leiste zur Eingabe von URLs sollte auf der Startseite geboten werden.
Zum Aufrufen einer bestimmten Websei-te wählt der Nutzer die Funktion „Start-seite“, da dies der zweite Punkt im Hauptmenü ist. Als Ergebnis wird je-doch die Portalseite des Netzbetreibers Vodafone gestartet.
„ich öffne einfach mal ne Seite und hoffe, dass ich dort was eingeben kann“
4 Menüpunkt „Adresse einge-ben“ sollte zusätzlich zur grafischen Eingabeleiste als erster Menüpunkt erschei-nen, da diese Funktion eine der wichtigsten Browser-funktionen ist.
Formulareingabe
ausgewähltes For-mularfeld ist nur gering markiert und daher ist aktuelle Auswahl schlecht erkennbar
2 Formularfeld könnte farbig umrandet werden.
obwohl der Cursor sich in einem For-mularfeld befindet und eine direkte Eingabe möglich ist, wird dem Nutzer die Funktion „Ändern“ angeboten, sodass der Eindruck ent-steht, dass keine direkte Eingabe möglich ist
„obwohl auf Feld muss ich erst kli-cken zum Einge-ben“
2 Die Beschriftung „Ändern“ kann entfernt werden, da der Test gezeigt hat, dass die Nutzer ohnehin davon aus-gehen, dass eine direkte Eingabe möglich ist.
Anhang D – Ergebnisse Nutzertest Nokia
138
Finding Zitate Screenshot Stufe Empfehlung
Eingabe muss immer bestätigt werden. Die Nutzer erwarten, dass sie mit den Navigationstasten zum nächsten Feld springen können.
„’Los’ muss extra angeklickt werden, nur ‚Return’ funk-tioniert nicht“
2 Die Eingabe muss nicht extra bestätigt werden. Bei Nutzung der Navigationstas-ten springt der Cursor in das nächste Formularfeld bzw. zum nächsten Button.
Bei der Auswahl der BahnCard-Optionen auf der Bahn-Webseite öffnet sich ein eigenes Fenster (im Gegensatz zu anderen Formular-feldern). Dort ist die Darstellung so groß gewählt, dass die Optionen nicht auf eine Zeile passen und zur korrekten Ansicht gescrollt werden muss.
3 Die Schriftgröße sollte auf ein akzeptables Minimum reduziert werden, sodass mehr Zeichen pro Zeile (z.B. 30) dargestellt werden können.
Navigation auf und zwischen Webseiten
Die Webseite mo-bil.bahn.de erscheint erst in größerer An-sicht, springt aber direkt auf die kleine mobile Darstellung (ca. 0,5s) um.
1 Der Browser sollte eine Webseite erst anzeigen, wenn die Zielversion (hier die mobile) geladen ist. Das vermeidet Irritationen beim Nutzer.
Die Nutzer erwarten eine einspaltige Ansicht (Mobil-Ansicht) bei Websei-ten, die keine mobile Version besitzen.
3 Der Browser sollte nicht-mobile Webseiten automa-tisch auf eine einspaltige Darstellung anpassen, da somit umständliches hori-zontales Scrollen verhindert wird.
Anhang D – Ergebnisse Nutzertest Nokia
139
Finding Zitate Screenshot Stufe Empfehlung
Der Prozess des Ladevorgangs ist durch sehr kleines Symbol (drehende Weltkugel) nicht erkennbar.
„man sieht nicht, ob er lädt“
4 Das Symbol der Weltkugel sollte durch einen Fort-schrittsbalken mit Prozent-Angaben ersetzt werden.
Lesezeichen anlegen
beim Anlegen eines Lesezeichens kann der Nutzer den Na-men nicht festlegen, sondern der Nokia-Browser macht dies automatisch (Nut-zerkontrolle nicht gegeben)
„ich nehme an, dass war das Le-sezeichen der Seite, die ich auf-gerufen hatte“ „hätte gern Na-men vergeben wollen“
2 Den Nutzern sollte automa-tisch der Seitentitel der Webseite als Lesezeichen-Titel vorgeschlagen werden, den sie jedoch nach Belie-ben ändern können. Somit erhalten die Nutzer wieder die Kontrolle über ihr Han-deln.
Lesezeichen ordnen
Beim Verschieben des Lesezeichens in einen Unterordner ist nur der Hauptordner „Lesezeichen“ sicht-bar. Die Tester ver-suchen den Unter-ordner per Klick auf den Hauptordner zu öffnen und erhalten die Fehlermeldung „Verschieben in Zielordner nicht möglich“. Der Un-terordner muss erst über das Optionen-Menü geöffnet wer-den, bevor das Lese-zeichen verschoben werden kann.
„[News-Ordner] wird nicht ange-zeigt - vielleicht liegt ‚News’ unter ‚Lesezeichen’?“ „durch Windows Doppelklick und nicht Befehl ge-wöhnt“ „sehe aber nur einen Ordner 'Lesezeichen'“
4 Durch eine listenähnliche Auflistung aller Ordner inklusive Unterordner ist jeder Zielordner sichtbar und kann somit leicht aus-gewählt werden.
Anhang D – Ergebnisse Nutzertest Nokia
140
Finding Zitate Screenshot Stufe Empfehlung
Daten downloaden (Bild)
Die Nutzer suchen eine Funktion zum Bild speichern unter einem ähnlichen Begriff („Bild spei-chern“ o.ä.) im Hauptmenü sowie unter den Menü-punkten „Andere Optionen“ und „Downloads“. Die Funktion verbirgt sich jedoch unter „Seiten-Optionen“
„Bildmodus“.
„nicht intuitiv“ „ob das wohl [überhaupt] geht?“ „’Optionen’ - nee, ich glaube nicht [klickt auf ‚Andere Optionen’] Das sind alles Inter-netoptionen, wie kann man denn da ein Bild spei-chern?“ „aber ich weiß nicht mehr, wie ich dahin gekom-men bin, wenn ich das noch mal machen sollte“ „ 'Optionen' hilft mir nicht weiter“
4 Der Menüpunkt „Bild spei-chern“ sollte direkt im Hauptmenü angeboten wer-den.
Begriff „Bildmodus“ ist unklar, Tester versucht daher die Funktion „Detail verwenden“
„’Bildmodus’ hört sich gut an, aber ‚Detail verwen-den’ klingt bes-ser“
s. vorheriger Screens-hot
1 Der Begriff „Bildmodus“ sollte durch die aussagekräf-tigere Bezeichnung „Bild speichern“ ersetzt werden.
wenn der Bildmodus aktiviert wird, ist trotz der Überschrift „Bildmodus“ schwer erkenntlich, dass dieser Modus einge-schaltet ist
3 Man könnte einen Hinweis anzeigen z.B. „Zum Spei-chern bitte ein Bild auswäh-len“.
Im aktiven Bildmo-dus werden Bilder nur mit einem sehr dünnen, blauen Auswahlrahmen markiert , sodass die Auswahl teilweise überhaupt nicht erkannt wurde. Beim Test kam erschwe-rend hinzu, dass das auszuwählende Bild auch komplett blau war.
„aber ich hab Angst, dass ich dann irgendwas speichere“ „ich glaube, ich hab die ganze Seite gespeichert, weil ich nichts auswählen konn-te“
3 Man kann den Auswahl-rahmen breiter gestalten oder/und mit einem Blinken versehen.
Anhang D – Ergebnisse Nutzertest Nokia
141
Finding Zitate Screenshot Stufe Empfehlung
Zum Speichern eines Bilds versuchen die Nutzer das Bild zu markieren. Dies funktioniert nicht, da der Cursor jegliche Bilder übergeht.
„geht nicht zu markieren“
3 Wenn die Funktion zum Bild speichern schneller gefunden wird (vgl. vorhe-rige Empfehlung), muss das Bild nicht markiert werden können. (Falls ein Bild mar-kiert werden könnte, würde dieses ähnlich wie jeder Hyperlink bei der Navigati-on ausgewählt werden. Im Endeffekt würde damit die gesamte Navigation ver-langsamt werden.)
Verlauf
in der Verlaufsliste werden nur unvoll-ständige Seitentitel angezeigt (nur 18 Zeichen möglich)
3 Die Schriftgröße sollte ver-kleinert und die Titelanzeige auf max. 30 Zeichen ausge-weitet werden, damit die Lesbarkeit noch gesichert ist.
die Verlaufsliste besitzt eine sehr beschränkte Kapazi-tät, sodass am Tes-tende die erste be-suchte Seite bereits wieder aus der Liste gefallen war
3 Die Kapazität der Verlaufs-liste sollte man auf mindes-tens 20 Seiten erhöhen und gleichzeitig die Schriftgröße für eine kompaktere Darstel-lung anpassen.
Darstellung anpassen (Schriftgröße)
nach Auswahl einer neuen Schriftartgrö-ße muss der Nutzer erst dreimal auf „Zurück“ drücken bis die aktuelle Webseite wieder sichtbar ist (bedingt durch tiefe Menü-struktur)
2 Die Menüstruktur sollte insgesamt flacher gestaltet werden.
Anhang D – Ergebnisse Nutzertest Nokia
142
Finding Zitate Screenshot Stufe Empfehlung
Schriftgröße „groß“ ist für den Tester immer noch zu klein
1 Man sollte die „große“ Schriftgröße in der Darstel-lung nochmals vergrößern.
Telefonnummer anrufen per Klick
Der Nutzer versucht bei einer Telefon-nummer auf einer Webseite anzurufen, indem er nur die Taste mit dem grü-nen Hörer betätigt. Da nur eine Tele-fonnummer auf der Webseite vorhanden ist, erwartet er, dass der Browser diese automatisch erkennt. Die Nummer muss jedoch erst markiert sein, bevor der An-ruf funktioniert.
1 Beim Betätigen der grünen (Hörer)Taste sollte sich eine Liste mit allen anrufbaren Nummern der Webseite öffnen.
Menü
Die Menüstruktur, speziell die Unter-punkte, ist nicht auf einen Blick ersicht-lich.
4 Die Menüstruktur sollte insgesamt flacher gestaltet werden, d.h. auf wenige Unterpunkte konzentrieren, Schriftgröße der Menüein-träge verringern und an-schließend Menübaum dar-stellen (z.B. als Fly-Out).
Anhang D – Ergebnisse Nutzertest Nokia
143
Finding Zitate Screenshot Stufe Empfehlung
Der Unterschied zwischen den Beg-riffen „Seitenoptio-nen“, „Andere Opti-onen“ und „Brow-sereinstellungen“ ist unklar. Die Nutzer wissen nicht, welche Inhalte sich dahinter verbergen und durchsuchen das gesamte Menü um per Trial and Error das richtige Unter-menü zu finden.
4 Die einzelnen Funktionen aus der „Optionen-Vielfalt“ sollten in die zwei Unter-punkte „allg. Einstellungen“ und „Seitenoptionen“ ge-trennt werden. Alle weiteren Einstellungen, z.B. browser-relevante Einstellungen wie Bilder zeigen, Textumbruch, JavaScript sollten zusam-mengefasst und in einem separaten Menüpunkt ange-boten werden. Dies verrin-gert die webseitenrelevanten Funktionen („Seitenoptio-nen“) und sorgt für mehr Klarheit im Menü.
Die Funktion „Web-Adresse senden“ wird als Punkt im Hauptmenü erwartet. Sie befindet sich jedoch unter „Seiten-Optionen“. Die Tes-ter durchsuchen daher das Unterme-nü „Andere Optio-nen“, aber auch unter „Adressbuch“, „Zur Adresse“ und „Detail verwenden“.
4 Wenn insgesamt aussage-kräftigere Bezeichnungen verwendet werden und die Menüstruktur flacher wird, wird der Menüpunkt „Web-Adresse senden“ bestimmt eher unter den „Seiten-Optionen“ gefunden.
Bei der Aufgabe „URL versenden“ wählen die Tester den Menüpunkt „Adresse anzeigen“ anstatt „Web-Adresse senden“ einen Punkt darun-ter, weil sie noch nicht bis dahin gele-sen haben.
„wer lesen kann, ist klar im Vor-teil“
1 Wenn die Funktion „Web-Adresse senden“ statistisch gesehen von allen Handy-nutzern öfter genutzt wird als der Punkt „Adresse an-zeigen“, sollte die Reihen-folge der beiden Punkte getauscht werden. Da aber keine Aussagen zur Häufig-keit der Nutzung vorliegen, sollte die aktuell logische Reihenfolge der beiden Menüpunkte bestehen blei-ben.
Untermenüs werden im Nokia-Style (so wie das Handymenü auch) dargestellt und benötigen daher viel Platz
2 Aktuell können maximal sieben Menüeinträge über-einander dargestellt werden. Zur besseren Übersicht kann die Schriftgröße der einzel-nen Einträge jedoch deutlich verringert werden.
Anhang D – Ergebnisse Nutzertest Nokia
144
Finding Zitate Screenshot Stufe Empfehlung
Die Funktion „Schriftgröße än-dern“ erwarten die Nutzer im Unterme-nü „Seiten-Optionen“, da sich dort alle Einstellun-gen zur Seite befin-den. Sie befindet sich jedoch unter „Andere Optionen“
„Browser-Einstellung“.
„muss doch in ‚Seitenoptionen' sein“
3 Da die Nutzer die Einstel-lung der Schriftgröße der Webseite und nicht dem kompletten Browser zuord-nen, sollte der Punkt „Schriftgröße ändern“ unter den seitenrelevanten Optio-nen („Seitenoptionen“) präsentiert werden.
Menüpunkte im Hauptmenü werden vom Nutzer als Le-sezeichen interpre-tiert (Icons vorhan-den, Nokia.com als erster Eintrag)
2 Die Icons sind in dem Fall nicht zielführend und kön-nen entfernt werden. Somit können mehr Menüpunkte angezeigt werden, z.B. „Ad-resse eingeben“ als erster Menüpunkt.
Hauptmenü und alle Untermenüs erschei-nen in einem neuen Fenster, sodass die Webseite komplett verdeckt wird
1 Das gesamte Menü sollte in Komplexität und Schrift-größe so reduziert werden, dass die Webseite maximal zur Hälfte verdeckt wird.
Die Menüstruktur ist sehr verzweigt und damit nicht intuitiv, d.h. sie muss erlernt werden.
4 Die Menüstruktur sollte insgesamt flacher gestaltet werden, d.h. auf wenige Unterpunkte konzentrieren, Schriftgröße der Menüein-träge verringern und an-schließend Menübaum dar-stellen (z.B. als Fly-Out).
Nutzer erwarten den Menüpunkt „Zur Adresse“ als ersten Eintrag im Haupt-menü.
3 Menüpunkt „Adresse einge-ben“ sollte (zusätzlich zur grafischen Eingabeleiste) als erster Menüpunkt erschei-nen, da diese Funktion eine der wichtigsten Browser-funktionen ist.
Anhang D – Ergebnisse Nutzertest Nokia
145
Finding Zitate Screenshot Stufe Empfehlung
Der Menüpunkt „Beenden“ ist im Menü nicht schnell auffindbar, daher beendet der Nutzer den Browser (um-ständlich) durch das mehrmalige Betäti-gen der „Zurück“-Taste.
4 Der Menüpunkt „Beenden“ sollte von jedem Punkt des Browsers aus schnell er-reicht werden, d.h. er sollte im Hauptmenü als letzter Punkt angeboten werden. Gleichzeitig sollte das Hauptmenü immer mit ma-ximal einem Klick erreich-bar sein. Weiterhin beinhal-tet das Hauptmenü aktuell elf Einträge, d.h. der Punkt „Beenden“ ist schwer zu finden. Daher sollte das Hauptmenü unbedingt redu-ziert werden.
Statusmeldungen
Der Nutzer erhält keine Information, ob der Browser (respektive die In-ternetverbindung) beendet wurde.
„wirklich aus?“ 3 Die Statusmeldung „Inter-netverbindung wurde been-det“ sollte erscheinen.
Anhang E – Ergebnisse Nutzertest TeaShark
146
Anhang E – Ergebnisse Nutzertest TeaShark
Tabelle 6-3: Ergebnisse des Nutzertests vom TeaShark-Browser
Finding Zitate Screenshot Stufe Empfehlung
Webseite aufrufen
Nutzer erwarten grafi-sche Eingabeleiste für Internetadressen auf der Startseite
„Irgendwie fehlt mir die Eingabe-zeile für URLs. Dann such ich mal herum.“ „Eingabefeld, welches man häufig braucht, muss umständ-lich aufgerufen werden“
4 Eine grafische Leiste zur Eingabe von URLs sollte auf der Startseite geboten werden.
Der Browser bietet eine Google-Suchleiste an, die als Adresseingabe-leiste verstanden wird. Das heißt, der Nutzer sucht mit Google.
„aber ich be-fürchte, dass er in Google sucht“
4 Es sollte eine grafische Eingabeleiste als erstes Element auf der Startseite angeboten werden. Zusätz-lich kann ein „www.“ zur besseren Unterscheidung zur Suchleiste voreingestellt sein. Weiterhin könnte die Suchleiste mit einer Lupe als Symbol ausgestattet werden.
Menüpunkt „Go to“ wird als Menütitel er-kannt und nicht zur Eingabe von Adressen verstanden
„’Go to’ nicht intuitiv“
3 Die Funktion zur Adress-eingabe kann durch die Bezeichnung „Enter Ad-dress“ besser verdeutlicht werden.
Abbrechen
Der Browser lädt trotz Aufruf von „Cancel“ weiter und stellt die Webseite anschließend fehlerhaft dar.
1 Der Seitenaufruf sollte direkt abgebrochen werden und der Browser die zuletzt aufgerufene Webseite dar-stellen.
Anhang E – Ergebnisse Nutzertest TeaShark
147
Finding Zitate Screenshot Stufe Empfehlung
Formulareingabe
Bei ausgewähltem For-mularfeld beginnen die Tester direkt mit der Eingabe. Dies funktio-niert jedoch nicht, da das Formularfeld erst bestätigt werden muss. (direkte Eingabe erwar-tet)
„hab vergessen es anzuklicken“
4 Direkte Eingabe für alle Formularfelder anbieten, d.h. Feld muss nicht geson-dert bestätigt werden, son-dern wenn der Cursor sich darin befindet, ist eine Ein-gabe möglich.
Formulareingaben müs-sen nach Änderung einer Option oder Sei-tenwechsel wiederholt eingegeben werden, da die Daten gelöscht wurden.
4 Eine Funktion zum Auto-Ausfüllen sollte als Option im Bereich „Einstellungen“ angeboten werden. Somit werden Formulardaten ge-speichert und stehen auch später noch zur Verfügung.
bei der Formulareinga-be öffnet sich ein sepa-rates Fenster, welches die aktuelle Webseite verdeckt
2 Anstatt einem neuen Fenster sollte ein Eingabemodus auf der Webseite geöffnet wer-den (direkte Eingabe).
Die Auswahl innerhalb der BahnCard-Optionen auf der Webseite mo-bil.bahn.de kann nicht direkt übernommen werden (kein Bestäti-gen-Feld), sondern muss über „Optionen“
„OK“ umständlich bestätigt werden.
„'Auswählen' geht nicht, erst mit links 'OK' bestätigen. Das war umständlich für mich.“
3 Durch die Darstellung der BahnCard-Optionen als Drop-Down-Menü entfällt das unnötige Bestätigen.
Navigation auf und zwischen Webseiten
Die Steuerung von Cursor und Zoomüber-sicht ist nicht einheit-lich geregelt. Die Tester wollten zum Beispiel den Cursor bewegen, aber die Zoomübersicht hat die Bewegung aus-geführt.
„ist ganz verwir-rend“ „Wie bewege ich Fenster und wie Cursor?“
3 Es sollte eine klare Tren-nung zwischen beiden Steu-erungen existieren. Das Zoomfenster wird bewegt, wenn es aktiv ist (und hat dabei die Rolle des Cursors inne) und wenn der Zoom inaktiv ist, bewegen die Navigationstasten den Cur-sor.
Anhang E – Ergebnisse Nutzertest TeaShark
148
Finding Zitate Screenshot Stufe Empfehlung
Cursor bewegt sich unstetig (in Sprüngen)
„mit Mauszeiger nach unten geht nicht“ „würde jetzt schon abbrechen und Browser deinstallieren“
4 Der Browser sollte eine kontinuierliche Cursorsteue-rung, ähnlich wie beim PC, ermöglichen.
Der Browser lädt trotz explizitem Aufruf keine mobile Seite, z.B. spie-gel.mobi, sondern öff-net die normale Version (außer bei mo-bil.bahn.de).
4 Der Browser sollte soweit existent immer die mobile Version eine Webseite dar-stellen.
bei der Suche erwarten die Nutzer den Begriff „Search“ anstatt "Find text"
„Wo ist die Such-funktion? 'Find text' vielleicht?“
1 Die Bezeichnung „Find text“ kann durch den Beg-riff „Search“ ersetzt werden.
das Suchergebnis bei der Funktion „Find text“ ist nicht lesbar, falls die Zoomübersicht eingeschaltet ist
„wo [ist die der Cursor] hinge-hüpft? Scheint was gefunden zu haben, aber was?“
4 Wenn die Suche ein Ergeb-nis gefunden hat, sollte automatisch die Zoomüber-sicht verlassen und das erste Ergebnis angezeigt werden.
Suchfunktion muss umständlich über das Optionen-Menü mit „Edit“ und „Cancel“ bedient werden
3 Bei der Eingabe eines Suchbegriffs sollten die Funktion „OK“ sowie „Back“ per Softkeys reali-siert werden. Wenn die Eingabe bestätigt wurde, sollten die Funktionen „Menü“, „Find next“ und „Stop“ per Softkey angebo-ten werden.
Anhang E – Ergebnisse Nutzertest TeaShark
149
Finding Zitate Screenshot Stufe Empfehlung
Zoomübersicht wurde als überflüssig angese-hen, da der Text nicht lesbar ist ist
„Vorwissen nötig um Ausschnitt zu vergrößern“ „ins Blaue hinein eine Stelle ankli-cken ist abschre-ckend“ „ich gehe auf den Abschnitt, wo ich weiß, dass die Suche be-ginnt, aber wenn ich das nicht wüsste...“ „ein Rechteck zum Vergrößern, aber ich weiß doch noch gar nicht wo ich hin will“
4 Durch ein manuelles Um-schalten zwischen Zoom-übersicht („Zoom out“) und normaler Darstellung („Zoom in“) kann der Zoomfunktion ein sinnvol-ler Zweck gegeben werden.
Zoomübersicht bewegt sich nicht kontinuierlich (macht teilweise Sprün-ge)
2 Der Browser sollte eine kontinuierliche Steuerung der Zoomübersicht ermögli-chen.
Die Zoomübersicht erscheint auf mobilen Seiten (z.B. mo-bil.bahn.de) und wird dort vom Nutzer als lästig empfunden.
4 Auf mobilen Webseiten sollte die Zoomübersicht automatisch ausgeschaltet sein, da diese bereits für kleine Bildschirme opti-miert wurden.
Lesezeichen aufrufen
Menüpunkt „Lesezei-chen aufrufen“ wird im Lesezeichen-Menü erwartet
1 Die Funktion „Aufrufen“ sollte im Lesezeichen-Menü alternativ zum Klick ange-boten werden.
Anhang E – Ergebnisse Nutzertest TeaShark
150
Finding Zitate Screenshot Stufe Empfehlung
Zum Aufruf des selbst angelegten Lesezei-chens wurde dies auf der Startseite unter „Bookmarks“ gesucht. Dort werden jedoch nur die ersten fünf Lesezei-chen angezeigt. Da-durch dachte der Nut-zer, dass sein Lesezei-chen gelöscht wurde bzw. zwei verschiedene Arten von „Book-marks“ existieren.
„Bookmark er-scheint nicht auf Startpage. Gibt’s da noch mehr?“„völlig ohne Sinn und Verstand suche ich hier und versuche etwas zu finden, was mich an meinen heimi-schen Webbrow-ser erinnert“ „Bookmark ist weg“
2 Innerhalb der Abschnitts-überschrift auf der Startseite kann man verdeutlichen, dass noch mehr Lesezeichen als die angezeigten vorhan-den sind, z.B. durch das Hinzufügen von drei Punk-ten („Bookmarks...“).
Verlauf
beim Öffnen des Menü-punkts „History“ „List“ erscheint keine Liste der besuchten Webseiten, sondern unerwartet eine grafi-sche History-Funktion
3 Um die grafische Realisie-rung hervorzuheben, sollte der Begriff „List“ durch „View“ ersetzt werden.
Beim Aufruf der grafi-schen History-Funktion („List“) werden keine Begriffe zur Navigation angeboten. Es erscheint nur ein blauer Rahmen, welcher blinkt und dessen Funktion unklar ist.
„da blinkt was“ 4 Der rechte und der linke Softkey sollten zur Naviga-tion beschriftet werden, z.B. „Back“ und „Forward“. Der mittlere Softkey könnte „Cancel“ für das Verlassen des Historymodus anbieten.
Beim Aufruf der Histo-ry-Funktion werden leere Webseiten ange-zeigt. Nur der Seitenti-tel wird angeboten. In einem Testfall war dies zufällig die Bahnseite mit dem Titel „Verbin-dungen - Anfrage...“ und darunter „from Network“. Der Nutzer nahm an, dies sei eine Statusmeldung des Browsers.
2 Der Browser sollte die be-suchten Webseiten im Ca-che speichern, damit sie schnell aus der History geladen werden können. Falls dies aufgrund der geringen Leistung und Speicherkapazität nicht möglich ist, sollte nur eine Liste des Verlaufs (ähnlich Visited-Funktion) angebo-ten und auf die grafische Variante verzichtet werden.
Anhang E – Ergebnisse Nutzertest TeaShark
151
Finding Zitate Screenshot Stufe Empfehlung
Menü
Das Menü bzw. die Beschriftung der Soft-keys ist nicht ständig sichtbar, sondern ver-schwindet nach der Benutzung. Die Nutzer suchten daher (teilweise verzweifelt) eine Funk-tion um das Menü auf-zurufen.
„Was macht der denn?“ „ich glaube, dass war die rechte Taste“ „jetzt hab ich zurück geblättert, das war aber eher Zufall“
4 Aus Orientierungsgründen sollte das Menü und jegli-che Beschriftung der Soft-keys ständig am Bild-schirmrand sichtbar sein.
Das Menü „Book-marks“ befindet sich als Unterpunkt im Menü „View“. Die Nutzer erwarten jedoch den Menüpunkt bereits im Hauptmenü.
1 Lesezeichen sind eine der am meisten benutzten Funk-tion eines (Han-dy)Browsers, daher sollte dieses wichtige Feature auch durch einen eigenen Menüpunkt im Hauptmenü präsentiert werden.
Begriff „Feeds“ ist für den Nutzer nicht ver-ständlich
1 Diese Funktion kann durch den genaueren Begriff „RSS-Feeds“ bezeichnet werden. Zusätzlich kann in der Hilfe eine kurze Erläute-rung dargestellt werden.
Sonstiges
Während dem Nutzer-test tauchten ständig Darstellungsfehler auf der Bahn-Webseite sowie auf der Startseite auf. Zusätzlich stürzte der Browser mehrere Male ab. Das hinterließ einen negativen Ein-druck bei den Testern.
„scrollt obwohl Seite zu Ende“
4 Die Darstellungsfehler soll-ten unbedingt beseitigt werden.
Anhang F – bewährte Eigenschaften der Browser
152
Anhang F – bewährte Eigenschaften der Browser
Tabelle 6-4: Bewährte Eigenschaften der Handybrowser aus dem Nutzertest
Browser
N OM TS Beschreibung der bewährten Eigen-schaft
Bewertung extra positiv Zitat
Webseite aufrufen
x grafische Eingabeleiste (auf Startseite) vorhanden + „meine Leiste”
x „www.“ in Adresseingabe voreingestellt
x kann automatisch Adressen (falls bereits besucht) vervollständigen
x vervollständigt automatisch Endungen wie „.com“ oder „.de“
x zwei Eingabemöglichkeiten für Internet-adresse vorhanden (Leiste und Menü)
x x „Adresse eingeben“ erscheint als erster Menüpunkt „’Go to' als erster Punkt -
sehr schön“
Formulareingabe
x direkte Eingabe auf der Webseite möglich + +
x Links sind farblich gut (blau) unterlegt und damit erkennbar +
x wenig Klicks nötig um zwischen Formu-larfeldern zu navigieren
x bei der Funktion „Lesezeichen anlegen“ steht der Cursor direkt auf dem Button „Save“
x erstes Formularfeld wird direkt ausge-wählt
Navigation auf und zwischen Webseiten
x x mobile Webseiten werden angezeigt „erscheint auf ersten Blick sehr übersichtlich“
x zeigt keine mobilen Webseiten an + „Seiten wie zuhause ge-wünscht“
x einspaltige Ansicht (Mobil-Ansicht) vor-handen ++ „wunderbar - eindimensiona-
le Möglichkeit“
x x „Zurück“ als eigener Softkey + „’Zurück’ - das war einfach“
x x Mauszeiger vorhanden „toller Cursor, wie am Com-puter"
Anhang F – bewährte Eigenschaften der Browser
153
Browser
N OM TS Beschreibung der bewährten Eigen-schaft
Bewertung extra positiv Zitat
x x Cursor wird zur Sanduhr bzw. Hand
„kleine Hand dabei - sehr schön“ „er sucht – Sanduhr“
x „Zoom“ ist eine intelligente Übersichts-funktion, falls Webseite bekannt ++++
x kein Zoom „kein Miniausschnitt“
x Scrollleiste gut ersichtlich
x x springt Links direkt an ++
x „Zurück“-Funktion auf zwei Wege er-reichbar (Softkey und Menü)
x Suchfunktion innerhalb der Webseite ++
x Suchfunktion beginnt direkt und wartet nicht erst bis Eingabe beendet ist
Verlauf
x x Verlauf als Liste (auf Startseite) +++
x Verlauf auch nach Beenden noch sichtbar (bei Nokia nicht, obwohl Cache nicht gelöscht wurde)
Lesezeichen aufrufen
x URL wird beim Markieren als Vorschau angezeigt
Download von Daten (Bild)
x Bildmodus wird nach Speichern automa-tisch verlassen
Statusmeldungen
x Statusmeldung „Bookmark saved“ er-scheint
x beim Lesezeichenordner löschen: Status-meldung „Ordner nicht leer“ erscheint „Ordner nicht leer ist ne gute
Aussage“
x x
zur Darstellung des Ladevorgangs er-scheinen „Verbinde“ (OM) bzw. „con-necting“ und „loading + Prozentangabe“ (TS)
„'Verbinde' wird die ganze Zeit angezeigt, da weiß man wenigstens, dass er was macht“
Menü
x x Menü erscheint nur am unteren Rand (nicht bildschirmfüllend) +
Anhang F – bewährte Eigenschaften der Browser
154
Browser
N OM TS Beschreibung der bewährten Eigen-schaft
Bewertung extra positiv Zitat
x Menü ist nicht ständig sichtbar, d.h. man sieht mehr von der Webseite
„gut, dass Menü ausgeblendet wird, da sieht man mehr von der Seite“
x Menü ist ständig sichtbar +
x einfache Begriffe +
x BahnCard-Optionen passen auf eine Zeile „ganzer Eintrag lesbar“
x Lesezeichen-Menü kann direkt im Hauptmenü aufgerufen werden
x gute Startseite (Übersicht über Lesezei-chen und grafische Adresseingabe)
x x intuitives Menü +++++
x einfache Menüführung +++
x Browser ist leicht zu bedienen +
x x
überschaubares Menü, da nur ein Unter-punkt existiert
+
„muss irgendwo in 'Extras' sein“ „geht alles über 'Extras'“ „kann eigentlich nur 'Tools' sein“
x Fly-Out-Menü spart Zeit
x begrenzte Funktionsliste (weniger Funk-tionen als Nokia-Browser) ++
Sonstiges
x Größe der Schriftart wirkt sich auch auf Browsermenü aus
x beim Starten des Browsers wird man nicht direkt mit dem Internet verbunden
x Optik der Benutzerschnittstelle +
x ähnliches Feeling wie am PC +++
x x x „Abbrechen“ funktioniert super „funktioniert hervorragend"
Anhang G – browserunabhängige Ergebnisse
155
Anhang G – browserunabhängige Ergebnisse
Tabelle 6-5: Browserunabhängige Ergebnisse aus Nutzertest und Experteninspektion
Finding Zitate Screenshot Empfehlung
Formulareingabe
willkürlicher Wechsel zwischen T9 und ABC-Modus
Der Eingabemodus sollte immer der Gleiche sein. Falls der Nut-zer den Modus ändert, sollte sich das global auf die anderen Ein-gaben auswirken.
Bei Eingaben, die ein be-stimmtes Format erfordern, z.B. Datum, wird der Nut-zer nicht durch einen pas-senden Eingabemodus unterstützt.
Das Datenformat eines Formu-larfelds kann nur durch den Webseitendesigner bestimmt werden. Die Formularfelder sollten daher so gestaltet werden, dass sie automatisch das richtige Eingabeformat (z.B. Datum) übermitteln und der Browser den entsprechenden Eingabemodus (z.B. Zahlen) direkt anbieten kann.
Verlauf
In der Verlaufsliste werden die jeweiligen Seitentitel der Webseiten angezeigt. Teilweise besitzen alle Unterseiten den gleichen Titel (z.B. bei www.dw-world.de) und der Nutzer erkennt keinen Unterschied zwischen den Webseiten.
„viele Amazon-Pages, aber welche?“
Die Webdesigner sollten auf eine genaue Beschreibung der Web-seite durch den Seitentitel ach-ten.
Telefonnummer anrufen per Klick
Nach dem Rufaufbau wird dem Nutzer keine Mög-lichkeit zum Beenden des Anrufs angeboten. Aus Erfahrung drückt er (län-ger) auf die rote Taste und beendet damit ungewollt den Browser.
„wenn ich Anruf beende, wird dann Browser geschlossen?“
Das Handy sollte ein Interface zur Behandlung von Anrufen anbieten, die online getätigt werden.
Anhang G – browserunabhängige Ergebnisse
156
Finding Zitate Screenshot Empfehlung
Statusmeldungen
Statusmeldungen erschei-nen im unteren Drittel des Displays und über dieses hinaus, sodass der Nutzer scrollen muss um die Mel-dung vollständig lesen zu können.
Statusmeldungen können weiter oben im Display beginnen, so-dass der Inhalt auf einen Blick erkenntlich ist.
Die Bedeutung des „G“ als Statussymbol ist den Nut-zern nicht klar.
„was bedeutet 'G'? Hat be-stimmt irgend-was mit Nokia zu tun?!“
Das Statussymbol für den Onli-ne/Offline-Modus sollte durch eine Weltkugel ersetzt werden, die nur erscheint falls eine Inter-netverbindung besteht.
Das Statussymbol „G“ überlagert den Seitentext bzw. Seitentitel.
Die Webseite muss noch lesbar sein, daher muss je nach Telefon und Browser ausreichend Platz für die Statusinformationen re-serviert werden. Eine Einführung von Standards wäre dabei hilf-reich.
Der Telefonhörer als Sta-tussymbol beim Anrufen ist sehr klein gestaltet und somit sehr schwer für den Nutzer erkennbar.
„höre nur Ton, aber sehe nichts“ „irgendwie geht das nicht“
Das Symbol des Telefonhörers sollte vergrößert werden, sodass auf einen Blick ersichtlich ist, ob eine Telefonverbindung aufge-baut wird bzw. besteht. Jedoch sollte trotzdem noch die Websei-te lesbar sein, damit der Nutzer dort eventuelle Informationen nachschlagen kann.
Obwohl die Gegenstelle den Anruf abweist, bleibt der grüne Telefonhörer im Display bestehen. Folglich dachte der Nutzer, dass er immer noch anruft.
Falls keine Verbindung zustande kommt, sollte dies auch deutlich signalisiert werden, z.B. durch eine Statusmeldung wie „Anruf abgewiesen“ oder „Anruf been-det“. Weiterhin sollte das Sym-bol des Telefonhörers ausge-blendet werden.
Anhang G – browserunabhängige Ergebnisse
157
Finding Zitate Screenshot Empfehlung
Statusmeldungen, die vom Handy initiiert werden und eine „Ja/Nein“-Option anbieten, erscheinen halb transparent. Dadurch ver-schmilzt die Statusmel-dung mit dem Hintergrund und ist sehr schwer lesbar.
Die Statusmeldung sollte opak gestaltet werden, damit die Aus-wahlmöglichkeiten gut zu lesen sind.
Anhang H - Heuristiken
158
Anhang H - Heuristiken
Menü und Navigation
1. Abgeschlossenheit
a. Sind die Menüs vollständig, z.B. wenn ich etwas anlegen kann, kann ich es
dann auch wieder löschen?
b. Sind verschiedene Anwendungen sinnvoll miteinander verknüpft? (z.B.
Abbrechen, falls Seite geladen wird oder Anrufen-Option bei Telefonnr.)
c. Ist das Menü dynamisch, d.h. passt es sich an den jeweiligen Menü-
punkt/Umgebung an? (durch Ausgrauen oder Funktionen tauchen erst in
einem bestimmten Kontext auf)
2. Top-Down-Interaktion
a. Existieren hierarchische Menüs und weiß der Nutzer jederzeit wo er sich
befindet?
b. Wie komplex ist das Menü? (Menütiefe)
3. Benutzerkontrolle
a. Kann der Benutzer Aktionen starten anstatt nur darauf zu reagieren?
b. Ist der Datenverbrauch sichtbar?
Konsistenz
4. Geräteübergreifende Konsistenz
a. Ist eine Synchronisation mit dem PC-Browser möglich?
b. Werden bekannte Konzepte/mentale Modelle vom PC-Browser verwen-
det? (soweit für kleine Bildschirme geeignet)
c. Werden bekannte Begriffe vom PC-Browser verwendet? (soweit für
kleine Bildschirme geeignet)
5. Konsistenz innerhalb der Anwendung
1. Werden die Bezeichnungen innerhalb der Anwendung konsistent ver-
wendet?
Anhang H - Heuristiken
159
Fehlerbehandlung und -vermeidung
6. Aussagekräftiges Feedback
a. Erhält der Benutzer aussagekräftige Status- und präzise Fehlermeldungen
inkl. Lösungsvorschlag?
i. Zu große Webseite
ii. Webseite nicht vorhanden
iii. Sichere/unsichere Datenverbindung
iv. Abbrechen der Seite
7. Umkehrbarkeit bei begrenzten Ressourcen
a. Werden Informationen nach einem Verbindungsverlust automatisch wie-
derhergestellt? Oder sind doppelte Eingaben erforderlich?
b. Wie viele Einträge speichert die Verlaufsfunktion?
c. Ist ein Vorblättern zwischen den einzelnen Homepages möglich?
8. Fehlervermeidung
a. Werden Fehler schon durch die Menüanordnung vermieden?
b. Ist die Tastenbelegung der Softkeys konsistent?
c. Existiert eine Hilfe oder Dokumentation?
9. Umkehrbarkeit
a. Wie umfangreich ist die „Zurück“-Funktionalität?
b. Komme ich jederzeit in den Anfangszustand der Anwendung zurück?
Anpassung
10. Design für vielfältige und dynamische Umgebungen
a. Kann das Design an die jeweilige Situation angepasst werden? (Schrift-
größe, Helligkeit, lautlos, eine Hand)
11. Größenbedingte Faktoren
a. Kann zur besseren Darstellung zwischen Hoch- und Querformat gewech-
selt werden?
b. Wird die Seitendarstellung automatisch an den Handybildschirm ange-
passt? (Mobil-Ansicht mit einer Spalte, mobile Seiten werden geladen)
c. Werden die Informationen auf das nötigste reduziert? (keine irrelevan-
ten)
Anhang H - Heuristiken
160
12. Personalisierung
a. Kann die Anwendung den persönlichen Wünschen und Bedürfnissen an-
gepasst werden, z.B. durch eine personalisierte Startseite?
13. Shortcuts für Vielnutzer
a. Werden dem Benutzer Shortcuts angeboten? (Tastaturkürzel, Lesezei-
chen an sich)
Gestaltung
14. Ästhetik
a. Weist die Anwendung ein ansprechendes und lesbares Design auf? (Far-
ben und Formen)
b. Sind die verwendeten Bezeichnungen sinnvoll und verständlich?
15. Metaphern
a. Sind die verwendeten Metaphern sinnvoll und gut adaptiert? (z.B. Lese-
zeichen)
16. Icons zur Konzeptdarstellung
a. Wurden sinnvolle Symbole gewählt?
b. Sind diese gut erkennbar? (Größe)
Unterstützung der mobilen Anforderungen
17. Design für User in Bewegung
a. Ist der Zweck und die Navigation (Anfang/Ende) der Anwendung jeder-
zeit ersichtlich?
b. Findet der Nutzer schnell eine Lösung für sein Problem? Sind oft benutz-
te Funktionen schnell erreichbar?
c. Kann das „www“ in der Eingabeleiste weggelassen werden?
18. Auswahl anstatt Eingabe
a. Wird bevorzugt der Auswahl-Mechanismus verwendet, z.B. Drop-
Down-Menüs, Checkboxen?
b. Gibt es Default-Werte, die standardmäßig eingestellt sind?
c. Existieren Eingabebegrenzungen, z.B. Zahlen oder Datums-Format vor-
eingestellt?
Anhang H - Heuristiken
161
19. Schneller Wechsel von Anwendungen
a. Wie schnell ist der Startvorgang?
b. Wechselt der Browser nach Inaktivität automatisch in den Offline-
modus?
20. Eingeschränkte und geteilte Aufmerksamkeit
a. Besteht die Möglichkeit Bilder auszublenden?
b. Welche Methoden der Fehlervermeidung existieren?
c. Welche Techniken tragen dazu bei, dass der Nutzer auch bei einge-
schränkter Aufmerksamkeit sein Ziel erfüllen kann?
21. Kurzzeitgedächtnis entlasten
a. Gibt es die Möglichkeit Seiteninfos (Titel, Adresse, Größe, ...) anzeigen
zu lassen?
b. Kann der Seitentitel permanent eingeblendet werden?
c. Kann die Anwendung Logindaten (Namen und Passwörter) speichern?
(Cookies)
d. Gibt es Eingabehilfen für den Nutzer (Auto-Vervollständigen in Formu-
laren oder Adressen)?
e. Ist das Menü ständig sichtbar?
Anhang I – Ergebnisse der Experteninspektion
162
Anhang I – Ergebnisse der Experteninspektion
Dieser Anhang befindet sich auf der beiliegenden CD in dem Ordner „Experteninspek-
tion“.
Dazu gehört folgendes Dokument:
• Ergebnisse aller Browser sowie browserunabhängige Ergebnisse
(Ergebnisse Experteninspektion.xls)
Anhang J – Menüstruktur der Browser
163
Anhang J – Menüstruktur der Browser
Dieser Anhang befindet sich auf der beiliegenden CD in dem Ordner „Menüstruktur der
Browser“.
Dazu gehören folgende Dokumente:
• Menüstruktur des Browsers Nokia (Menüstruktur_Nokia.pdf)
• Menüstruktur des Browsers TeaShark (Menüstruktur_TeaShark.pdf)
• Menüstruktur des Browsers Opera Mini (Menüstruktur_Opera Mini.pdf)
• optimierte Menüstruktur des Browsers Opera Mini (Menüstruktur_Opera Mi-
ni_optimiert.pdf)
Anhang K – Inhaltsverzeichnis CD
164
Anhang K – Inhaltsverzeichnis CD
Auf der beiliegenden CD befinden sich die Diplomarbeit, alle Anhänge sowie die grafi-
schen Szenarien des optimierten Browsers. Zusätzlich enthält die CD alle weiteren Do-
kumente, die im Rahmen dieser Diplomarbeit, erstellt wurden.
Selbständigkeitserklärung
Ich versichere hiermit, dass ich die Diplomarbeit selbständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel genutzt habe.
Aachen, den 28. Juni 2008 Annett Schulz
Recommended