Hochschule für Technik und Wirtschaft Dresden (FH ... · Mobiles Internet – Evaluation der Benutzerfreundlichkeit von Handybrowsern und Entwicklung eines optimierten Designs eingereicht

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


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


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


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.


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.


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]


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.


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.


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-


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.


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.


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


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


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-


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


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


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.


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.


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).


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]


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-


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


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.


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-


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


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


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


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.


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:


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.


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.


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.


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-


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.


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


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


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.


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


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.


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.


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


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.


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.


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.


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


56


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.


57


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.


58


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


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-


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“


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


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-


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.


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]


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.


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.


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


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


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.


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


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


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


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-


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.


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,


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.


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-


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


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


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.


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.


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


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-


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.


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.


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


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.


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.


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


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


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-


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


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“.


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-


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-


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.


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.


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).


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


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


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-


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


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.


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.


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.


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)


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


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.


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.


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


114



• 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


115



• 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


116



• 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“


117



• 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


118



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]


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.


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-


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


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.


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


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


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]

http://www.handys-mobile.de/lexikon

http://de.wikipeda.org/

http://www.bitkom.org/

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]

http://www.useit.com/papers/heuristic/severityrating.html

http://www.useit.com/alertbox/20010805.html

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]

http://www.dornhoff.net/wp-content/uploads/2006/01/operaminischeme1.png

http://www.dornhoff.net/wp-content/uploads/2006/01/operaminischeme1.png

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


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.: _______


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


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.


134


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.


135


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.)


136


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


Tabelle 6-2: Ergebnisse des Nutzertests vom Nokia-Browser


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.


138


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.


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.


139


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.


140


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.


141


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.


142


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).


143


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.


144


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.


145


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


Tabelle 6-3: Ergebnisse des Nutzertests vom TeaShark-Browser


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.


147


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.


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.


148


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.


149


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.


150


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.


151


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


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


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"


153

Browser



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) +


154

Browser



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


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.


156


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.


157


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


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?


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)


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?


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

Documents

Hochschule für Technik und Wirtschaft Dresden (FH ... · Mobiles Internet – Evaluation der Benutzerfreundlichkeit von Handybrowsern und Entwicklung eines optimierten Designs eingereicht