Fakultät für Elektrotechnik, Informatik und Mathematik

Konzipierung und prototypischeImplementierung einer

Touchoberfläche der Experimentefür WeCaSo

Eine Lösung für Card Sorting auf Smartphones

Bachelorarbeitim Rahmen des Studiengangs Informatik

zur Erlangung des GradesBachelor of Science

vonJakob Harder

vorgelegt bei:Prof. Dr. Gerd Szwillus

undProf. Dr. Reinhard KeilPaderborn, 15. März 2018

ErklärungIch versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung andererals der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oderähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und vondieser als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen,die wörtlich oder sinngemäß übernommen worden sind, sind als solche gekenn-zeichnet.

Ort, Datum Signatur

iii

Inhaltsverzeichnis1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 32.1 Card Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Arten von Card Sorting Experimenten . . . . . . . . . . . 42.1.2 Aufbau eines Card Sorting Experiments . . . . . . . . . . 5

2.2 WeCaSo - Web Card Sorting . . . . . . . . . . . . . . . . . . . . . 52.2.1 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Experimentoberfläche . . . . . . . . . . . . . . . . . . . . . 6

3 Konzept 93.1 Ursprüngliches Design . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Sichbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Designziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Oberflächendesign . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5.1 Vertikales Design A . . . . . . . . . . . . . . . . . . . . . . 123.5.2 Vertikales Design B . . . . . . . . . . . . . . . . . . . . . . 143.5.3 Horizontales Design . . . . . . . . . . . . . . . . . . . . . . 163.5.4 Desktop-Design . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Implementierung 194.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Laravel 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.3 Responsive Design . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Konzeptauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.1 Bootstrap.css . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.2 Experiment-View . . . . . . . . . . . . . . . . . . . . . . . 22

5 Evaluation 235.1 Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3 Zusammenfassung der Evaluation . . . . . . . . . . . . . . . . . . 27

v

Inhaltsverzeichnis

6 Fazit 296.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Literaturverzeichnis 31

vi

Abbildungsverzeichnis2.1 Manuelles Card Sorting Experiment[4] . . . . . . . . . . . . . . . 32.2 Abfolge: Open Card Sorting[5] . . . . . . . . . . . . . . . . . . . . 42.3 Abfolge: Closed Card Sorting[2] . . . . . . . . . . . . . . . . . . . 52.4 Experimentoberfläche WeCaSo - Open Sorting . . . . . . . . . . . 7

3.1 Experimentoberfläche bei geringer Auflösung . . . . . . . . . . . . 103.2 Bsp.: Bedienungsschwierigkeiten des Experiments . . . . . . . . . 113.3 Design Vertikal A . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Design Vertikal B . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Design Horizontal . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Anwendung des MVC Prinzips bei Laravel . . . . . . . . . . . . . 20

5.1 Oberfläche: Evaluationsexperiment - Großansicht . . . . . . . . . 235.2 Experimentoberfläche: Ansicht der Testpersonen - vertikal . . . . 255.3 Experimentoberfläche: Ansicht der Testpersonen - horizantal . . . 27

vii

1 Einleitung

WeCaSo, kurz für Web Card Sorting, ist eine Webapplikation, die die Designme-thode des Card Sorting implementiert. Diese Arbeit befasst sich im Speziellen mitder von Herrn Kailaash Balachandran entwickelten Implementation von WeCaSo,die im Rahmen der Masterarbeit „Concept and Prototypical Re-Implementationof a Web-Based Card Sorting Application with Responsive Design - Can CardSorting be Done on a Smartphone?[7]“ erstellt wurde. Zentrales Thema dieser Ar-beit ist eine mögliche Lösung, um Card Sorting Experimente auf sehr begrenztenFlächen, speziell Touchscreens von Smartphones, zu erarbeiten und diese proto-typisch als neue Oberfläche der Experimente von WeCaSo zu implementieren.

1.1 MotivationDurch die nun allgemeine Verbreitung von Smartphones und Tablets mit Toucho-berflächen ist eine neue Umgangsart mit dem Internet entstanden. Handynutzersind heutzutage nahezu permanent mit dem Internet verbunden und navigierenauf Webseiten nicht mehr mit der traditionellen Maus und Tastatur. Dieser Um-stand verlangt nach neuen Designprinzipien bei der Gestaltung von Webseitenund Webapplikationen. Um die Benutzerfreundlichkeit stets optimal zu halten,müssen beim Design von Inhalt und Navigation die Eigenschaften im Bezug aufBildschirmgröße und Bedienung von Smartphones, Tablets und traditionellen Ge-räten beachtet werden.Um die Vorteile der allgegenwärtigen Erreichbarkeit von Webseiten mit Hil-

fe von Smartphones auf die Anwendung des Web Card Sorting zu übertragen,ist eine entsprechende Bedienungsoberfläche der Experimente von WeCaSo not-wendig. Ursprünglich ist Card Sorting eine manuelle Methode aus dem Bereichdes Prototyping. Mit dieser Methode ist es möglich Informationen über die Er-wartungshaltung von Zielgruppen zu sammeln und diese Informationen z.B. zumDesign von Webseiten oder grafischen Benutzeroberflächen zu nutzen.Card Sorting Experimente als Webapplikation zu realisieren wirft jedoch die

Frage der Arbeitsfläche auf. Bildschirme bzw. Browserfenster haben stets einebegrenzte Größe. Smartphones im Besonderen besitzen eine sehr begrenzte Bild-schirmfläche, die bei Anwendungen wie Card Sorting Experimenten eine großeHerausforderung darstellt.In der aktuellen Implementation von WeCaSo ist die Realisierung der Experi-

1

1 Einleitung

mentoberfläche zur Handhabung auf Smartphones extrem unpraktikabel. Es müs-sen also Konzepte entwickelt werden, die es möglich machen die Oberfläche derCard Sorting Experimente von WeCaSo auf Smartphones zu übertragen. Im Rah-men dieser Ausarbeitung sollen diese Konzepte dann auf Basis der vorhandenImplementierung von WeCaSo prototypisch implementiert und getestet werden.

1.2 Struktur der ArbeitIm Folgenden wird die restliche Struktur dieser Arbeit beschrieben.

• Kapitel 2 - Grundlegende Erläuterung von Card Sorting und der Imple-mentierung von WeCaSo durch Herrn Kailaash Balachandran.

• Kapitel 3 - Konzept der im Rahmen dieser Arbeit erstellten Implementie-rung.

• Kapitel 4 - Vorstellung der Implementierung und genutzten Komponenten.

• Kapitel 5 - Evaluation der Implementierung durch eine Testgruppe.

• Kapitel 6 - Zusammenfassung der Arbeit und Bewertung der Ergebnisse.

2

2 GrundlagenDieses Kapitel stellt die grundlegende Methode des Card Sorting sowie die zu-grunde liegende Implementierung von WeCaSo vor.

2.1 Card SortingDie Methode des Card Sorting findet seine Anwendung weitestgehend im Proto-typing. Das Ziel eines Card Sorting Experiments ist, eine Menge von Begriffenin möglichst intuitiv verstehbare Kategorien zu sortieren. In der ursprünglichenAnwendung werden die Begriffe auf Karten, z.B. Karteikarten, notiert. Jede Kartehält genau einen Begriff. Diese Karten werden dann einer Testpeson oder einerGruppe von Testpersonen ausgehändigt, die die Begriffe dann nach eigenem Er-messen in Gruppen sortieren.

Abbildung 2.1: Manuelles Card Sorting Experiment[4]

3

2 Grundlagen

2.1.1 Arten von Card Sorting Experimenten

Bei der Durchführung von Card Sorting existieren im groben zwei Sorten vonExperimenten: Open Card Sorting und Closed Card Sorting. Beim Open CardSorting erhalten die Testpersonen lediglich den Stapel mit Karten, der die einzu-sortierenden Begriffe enthält. Diese Karten sollen dann in Gruppen sortiert wer-den. Sobald die Testpersonen die Sortierung beendet haben, sollen die Gruppen,in die einsortiert wurde, noch benannt werden (Beispiel siehe Abbildung 2.2).

Abbildung 2.2: Abfolge: Open Card Sorting[5]

Die Variante des Closed Card Sorting unterscheidet sich in sofern, dass außerdem Stapel mit Begriffskarten den Testpersonen ebenfalls die möglichen Katego-rien für die Begriffe vorgegeben werden (siehe Abbildung 2.3). Beide Variantenbieten Vor- und Nachteile. Open Card Sorting erlaubt den Testpersonen Katego-rien frei zu benennen. Somit ist es möglich die Begriffe so zu sortieren, dass fürdie jeweilige Testperson eine am besten nachvollziehbare und zufriedenstellendeSortierung entsteht. Nachteil ist, dass in diesem Fall mit der Anzahl der Testper-sonen die Namen, Arten und Anzahl der einsortierten Kategorien stark variierenkönnen.Bei Anwendung der Closed Card Sorting Variante entfällt dieses Problem. Die

feste Vorgabe von Kategorien kann aber dazu führen, dass die Testpersonen nichtdazu in der Lage sind gewisse Begriffe eindeutig in eine der vorgegeben Kategori-en einzusortieren. Es muss also bei der Wahl der Experimentart darauf geachtetwerden, welche Art von Informationen und Ergebnissen man von dem Experimenterwartet.Eine weitere Möglichkeit ist es die Experimentarten nacheinander zu verwenden.

Mit Hilfe des Open Card Sorting lässt sich feststellen, welche Arten von Katego-rien die Testpersonen für natürlich halten. An dieser Stelle fasst man synonymeKategorien zusammen, entfernt kaum zugeordnete Kategorien und nutzt nun dieClosed Card Sorting Methode mit den zuvor erarbeiteten Kategorien.

4

2.2 WeCaSo - Web Card Sorting

Abbildung 2.3: Abfolge: Closed Card Sorting[2]

2.1.2 Aufbau eines Card Sorting ExperimentsUm ein Card Sorting Experiment korrekt durchzuführen sollten die folgendenSchritte beachtet werden (vgl. [8], S.8):

1. Entscheide welche Informationen das Experiment liefern soll.

2. Wähle die passende Card Sorting Methode (Open Sorting oder Closed Sor-ting).

3. Wähle die Begriffe aus.

4. Wähle die Testpersonen aus und lade sie zur Teilnahme ein.

5. Führe das Experiment durch und zeichne die Ergebnisse auf.

6. Analysiere die gefundenen Ergebnisse.

7. Nutze die Erkenntnisse der Analyse als Basis zum Design des Projekts.

2.2 WeCaSo - Web Card SortingDie im Rahmen der Masterarbeit von Kailaash Balachandran entwickelte Imple-mentation von WeCaSo stellt die Grundlage dieser Ausarbeitung dar, auf dessenBasis die Designkonzepte der neuen Touchoberfläche umgesetzt wurden. Für dieImplementierung wurde im Wesentlichen das Laravel PHP Framework, ergänztdurch Javascript und Responsive Designs durch Bootstrap genutzt (für detaillier-te, technische Ausführung siehe [7]) . Im Folgenden soll ein Überblick über diezentralen Funktionen von WeCaSo verschafft werden.

5

2 Grundlagen

2.2.1 DashboardWeCaSo implementiert die Methode des Card Sorting als Webapplikation undbesteht aus zwei wichtigen Bestandteilen. Der erste ist das sogenannte Dashboard,die Oberfläche mit dessen Hilfe Experimente verwaltet werden. Im Einzelnen bietetWeCaSo dabei folgende Funktionen:

• Experiment erstellenMit dieser Option werden Experimente angelegt und ihre grundlegendenParameter, wie Projektname, URL, Experimentart, usw. gesetzt. Nach demanlegen wird der Nutzer zur Ansicht der Experimentdetails weitergeleitet,um den konkreten Inhalt des Experiments zu definieren.

• Experiment verwaltenDies ist die Anzeige der bereits erstellten Experimente, entsprechend nachOpen Sorting und Closed Sorting getrennt. Hier ist das Bearbeiten undLöschen der vorhandenen Experimente möglich.

• AnalytikDies ist die Ansicht zum Aufrufen der Statistiken der einzelnen Experimente(u.a. Teilnehmerzahl, Anzahl beendeter Sortierungen, Anzahl gespeicherterKommentare).

• ExportierenWeCaSo bietet ebenfalls die Möglichkeit die Ergebnisse zur Auswertung inunterschiedliche Tabellenformate zu exportieren.

2.2.2 ExperimentoberflächeDie Experimentoberfläche ist der zweite, zentrale Teil der WeCaSo Applikation.Die Experimente werden durch das Aufrufen der entsprechenden Experiment-URLerreicht. Dies führt zunächst zur Anzeige der Willkommensnachricht. Durch ent-sprechende Fortsetzten-Buttons wird zum Fragebogen des Experiments und dannzur Anleitung weitergeleitet. Nach dem Anleitungstext des Experiments wird danndie eigentliche Experimentoberfläche präsentiert (siehe Abbildung 2.4).Die Organisation der Oberfläche ist übersichtlich gehalten. Direkt unter der Ti-

telzeile sind die Buttons zu finden, um die Anleitung wieder anzuzeigen, beimOpen Card Sorting weitere Kategorien hinzuzufügen und das Experiment zu be-enden. Im linken Viertel wird stets der Stapel der Grundbegriffskarten gezeigt.Der Rest der Oberfläche dient dem Anzeigen der Kategoriestapel. Die notwendigeInteraktion mit den Begriffskarten wird durch typisches Drag & Drop realisiert.Dabei ist darauf hinzuweisen, dass die Karten nur an der markierten Fläche aufder linken Seite die Drag & Drop-Funktion bedienen lassen.

6

2.2 WeCaSo - Web Card Sorting

Abbildung 2.4: Experimentoberfläche WeCaSo - Open Sorting

7

3 Konzept

In diesem Kapitel sollen zunächst die Probleme des vorhandenen Designs der Ex-perimentoberfläche von WeCaSo dargestellt werden. Darauf folgend werden daskonzeptuelle Design der neuen Experimentoberfläche erläutert und an Beispielenkonkretisiert. Dabei wird auf zentrale Fragen bezüglich der Designaspekte einge-gangen und mögliche Lösungen diskutiert.

3.1 Ursprüngliches DesignAbbildung 2.4 zeigt ein Beispiel der Experimentoberfläche vonWeCaSo, wie sie aufeinem Monitor mit entsprechend großer Auflösung erscheint. Die grundlegendenElemente eines Experiments sind bei dieser Ansicht alle gleichzeitig zu sehen undrepräsentieren so auch im übertragenen Sinn die manuelle Card Sorting Methodemit Karteikarten auf einer entsprechend großen Arbeitsfläche. Wird die Experi-mentoberfläche jedoch auf einem Bildschirm mit wesentlich kleinerer Auflösungaufgerufen, wie z.B. einem Smartphone, passt das Wesitedesign die Oberfläche soan, wie in Abbildung 3.1 zu sehen ist. Abbildung 3.1 zeigt dabei dasselbe Experi-ment wie in Abbildung 2.4.Bei kleiner Bildschirmauflösung greift das in WeCaSo implementierte Responsi-

ve Design. Dieses bewirkt jedoch, dass alle Einzelelemente der Oberfläche auf diemaximal mögliche Breite gesetzt werden. Daraus folgt, dass sich die Stapel derGrundbegriffe und die der Kategorien in einer vertikal ausgerichteten Liste anord-nen. Um nun Karten einsortieren zu können, muss die Testperson an das Endeder Kartenliste navigieren und besitzt nun nur noch die Möglichkeit, Begriffe ausdem unteren Ende der Kartenliste zu verschieben. Dabei sind ebenfalls nur wenigeKategorien überhaupt sichtbar, wie Abbildung 3.2 zeigt.Bei einem Experiment mit entsprechend vielen Begriffen ist es sogar möglich,

dass der gesamte Bildschirm durch den Inhalt einer einzelnen Kategorie belegtwerden kann, was das Umsortieren weiter erschwert. Weiterhin ist auffällig, dassder Stapel der Grundbegriffe eine freie Fläche erzeugt, wenn eine bestimmte An-zahl an beinhalteten Karten unterschritten wird (rot markiert in Abblidung 3.2).Dies ist das Resultat einer statischen Festlegung der Stapelgröße, welche sich nichtan die Auflösung der Anzeige anpasst. Bei entsprechend kleinen Auflösungen istes somit möglich, dass gar keine Kategorien erreichbar sind, sobald die wenigenletzten Karten im dem Kartenstapel verblieben sind.

9

3 Konzept

Abbildung 3.1: Experimentoberfläche bei geringer Auflösung

3.2 SichbarkeitEiner der Vorteile der Card Sorting Methode liegt in der Übersichtlichkeit derArbeitsfläche. Im optimalen Fall kann eine Testperson sämtliche Karten auf einergroßen Arbeitsfläche im Blick behalten. Dies erzeugt ein großes Maß an kontex-tuellen Informationen, welche es der Testperson erleichtern bestimmte Begriffeeinzuordnen. Beim Übertragen auf wesentlich kleinere Arbeitsflächen ergibt sichdie Schwierigkeit, dass die Testperson die Informationen, nämlich die Karten mitBegriffen und die vorhandenen Kategorien, nicht mehr gleichzeitig im Blick be-halten kann.Wie in Abbildung 2.4 zu sehen ist, sind die Begriffskarten, im linken Viertel

der Oberfläche, stets zu sehen. Überschreitet die Anzahl an sichtbaren Kartendie darstellbare Menge, wird durch einen Scrollbalken kenntlich gemacht, dassaußer den angezeigten Begriffskarten auch noch weitere existieren. Die Kategoriensind zu Beginn des Experiments leer, im Fall von Open Card Sorting gar nichtvorhanden. Sie nehmen daher nur wenig Platz auf der Oberfläche ein und sind imAllgemeinen alle zu sehen. Wird der Bereich der Kategorien zu groß, beginnt erautomatisch zu scrollen.

10

3.3 Navigation

Abbildung 3.2: Bsp.: Bedienungsschwierigkeiten des Experiments

Es ergibt sich folgende Frage: Welche dieser Informationen muss die Testpersonzu jeder Zeit sehen?

Zunächst kann man einen extrem minimalistischen Ansatz wählen. Um ein CardSorting Experiment durchzuführen, muss die Testperson zumindest immer zweibestimmte Objekte sehen können: 1. Mindestens einen Begriff, dessen Karte zukategorisieren ist. 2. Mindestens eine Kategorie, in die man eine Karte einsortie-ren kann. Dieser Ansatz erzeugt jedoch ein Problem bezüglich der kontextuellenInformationen, die der Testperson bei der Durchführung des Card Sorting Expe-riments eine große Hilfe bieten. Denn sie entfallen komplett. Somit ist es wichtigein gewisses Maß an kontextuellen Informationen sicherzustellen.

3.3 NavigationWeiterhin ist es notwendig, aufgrund der begrenzten Anzahl an sichtbaren Ele-menten, der Testperson eine möglichst einfach erschließbare Möglichkeit der Navi-gation zwischen sichtbaren und nicht sichtbaren Elementen des Experiments zurVerfügung zu stellen. Da es Ziel dieses Konzepts ist, Card Sorting Experimente aufSmart Devices mit sehr begrenzten Bildschirmen zu realisieren, gehe ich davon aus,dass eine Testperson in diesem Fall ein gewisses Maß an Erfahrung im Umgang

11

3 Konzept

mit Touchscreens besitzt. Die üblichste Form der Navigation auf solchen Gerätenbesteht aus Gesten, im speziellen der „Wischgeste“, mit dessen Hilfe die Testper-son die sichtbaren Elemente auf dem Bildschirm in die gewünschte Richtung ziehtund somit durch die Liste aller möglichen, vorhandenen Elemente navigiert.

3.4 DesignzieleEin minimalistisches Design sollte somit folgende Bedingungen erfüllen:

1. Es muss erkennbar sein, dass mehrere Karten mit Begriffen existieren.

2. Es muss erkennbar sein, dass Kategorien zur Einsortierung existieren.

3. Der Tester sollte intuitiv zwischen den sichtbaren und nicht sichtbaren Ele-menten navigieren können.

4. Außerdem sollte der Tester intuitiv erkennen, auf welche Art die Kartenverschoben werden können.

3.5 OberflächendesignUm die zuvor genannten Bedingungen zu erfüllen und dabei die Eigenschaften derTouchscreen-Bedienung von Smart Devices auszunutzen, sollen nun drei konzep-tuelle Designs vorgestellt werden.

3.5.1 Vertikales Design AAbbildung 3.3 zeigt das konzeptuelle Design einer Experimentoberfläche bei ver-tikaler Ausrichtung des Bildschrims. Die Oberfläche teilt sich im Wesentlichen indrei Bereiche: Die Titelzeile und Buttons, der Kartenstapel mit Begriffskarten unddie Stapel der Kategorien.

Verteilung der Bildschirmfläche

Jeder der drei Bereiche sollte eine gewisse Mindestgröße haben, um sicherzustellen,dass der Kartenstapel und die Kategorien als solche auch identifiziert werden kön-nen. Ebenfalls dürfen die einzelnen Bereiche jedoch nicht zu groß werden. Sonstbesteht die Gefahr, dass der Kartenstapel oder die Kategorien ab einer gewis-sen Menge an Karten den gesamten Bildschirm füllen und somit die Handhabungnahezu unmöglich machen. Um dem entgegenzuwirken, soll die Größe des Grund-begriffstapels und der Kategoriestapel abhängig von der Bildschirmgröße begrenztwerden. Die Höhe des Grundbegriffstapels und der Kategoriestapel sollten etwa30-40% der verfügbaren Bildschirmhöhe betragen. Somit bleiben noch 20-40% derBildschrimhöhe für die Titelzeile und Buttons. Das genaue Verhältnis zwischen

12

3.5 Oberflächendesign

Anleitung Ende

≡≡≡≡≡

Karteninhalt

Karteninhalt

Karteninhalt

Karteninhalt

Karteninhalt

WECASOExperiment: Titel

Karten

Kategoriename Kategoriename

≡≡

≡≡≡

Karteninhalt

Karteninhalt

Karteninha

Karteninha

Karteninha

≡ Karteninha

↓

↑

Scr

oll:

Kart

en

inhalt

↓

↑

Scr

oll:

Kart

en

inhalt

Scroll: Kategorien← →

Abbildung 3.3: Design Vertikal A

diesen Werten sollte nach entsprechenden Nutzertests festgelegt werden. Zunächstaber wird die Grundbegriffstapel- und Kategoriestapelhöhe auf 40% festgelegt.Auf diese Weise sollte der Kartenstapel und mindestens ein Kategoriestapel

immer sichtbar und somit die erste und zweite der Sichtbarkeitsbedingungen ausAbschnitt 3.4 erfüllt sein.

Navigation

Um der Testperson die Navigation zu vermitteln, wird sich einer Eigenschaft dertypischen Scrollfunktion bedient. Sobald ein Container, wie z.B. der Grundbe-griffstapel, mehr Elemente beinhaltet, als er darstellen kann, wird die Liste derElemente zwar fortgesetzt, aber das letzte Element ist in den meisten Fällen ab-geschnitten, wie in Abbildung 3.3 zu sehen ist. Dies suggeriert der Testperson,dass mehr als nur die angezeigten Elemente in der Liste existieren müssen. Soferndie Testperson ein gewissen Maß an Erfahrung mit Touchscreens besitzt, solltediese Tatsache dazu verleiten, die vorhandenen Elemente mit Hilfe der typischenWischgeste innerhalb Liste zu scrollen.Sollte dies nicht der Fall sein, existiert weiterhin das dynamische Anpassen des

Inhalts des Grundbegriffstapels. Da die Elemente des Grundbegriffstapels nach-rücken, sobald ein Element aus dem Stapel entfernt wurde, sollte der Nutzer fest-stellen können, dass mehr als die sichtbaren Karten im Kartenstapel zu finden sind,

13

3 Konzept

da automatisch neue Elemente erscheinen, sobald ein Begriff einsortiert wurde.Bei der Navigation zwischen den unterschiedlichen Kategorien, wird sich dersel-

ben Methode bedient. Die unterschiedlichen Stapel der Kategorien sind horizontalangeordnet und ihre maximale Breite auf ca. 60% der Bildschirmbreite festgelegt.Dadurch entsteht ein ähnlicher Effekt, wie bei der Anordnung der Karten imGrundbegriffstapel, so dass die zweite sichtbare Kategorie nicht vollständig ange-zeigt wird. Somit soll dies die Testperson darauf hinweisen, dass die Kategorienhorizontal angeordnet sind und ebenso unter ihnen gescrollt werden kann.Mit Hilfe dieser Navigationstechnik soll der Testperson der Wechsel zwischen

sichtbaren und nicht sichtbaren Elementen des Experiments ermöglicht und somitBedingung 3 aus Abschnitt 3.4 erfüllt werden.

Sortierfunktion

Die wohl zentralste Funktion eines Card Sorting Experiments ist das Verschiebender Karten aus dem Grundbegriffstapel in die entsprechenden Kategorien, auchoft als „Drag & Drop“ bezeichnet. Um diese Funktion zu realisieren, existierenmehrere Möglichkeiten. Die Verständlichste wäre, eine Karte an einer beliebigenStelle zu berühren und zu halten, um sie dann in den gewünschten Kategoriestapelzu ziehen. Bei der begrenzten Arbeitsfläche, die z.B. ein Smartphone bereitstellt,ist die Implementation einer solchen Funktionsweise jedoch nicht möglich. Wiebereits beschrieben, muss innerhalb der Arbeitsfläche des Experiments zwischensichtbaren und nicht sichtbaren Elementen navigiert werden. Wenn bei jeder Be-rührung eine Karte sofort in den Zustand des Verschiebens geführt wird, dannverkompliziert dies die Navigation. Gleichzeitig müssen die Karten eine entspre-chende Größe haben, so dass ihr Inhalt gut lesbar bleibt.Als Lösung liegt es Nahe nur einen bestimmten Bereich der einzelnen Karten

festzulegen, der die Drag & Drop Eigenschaft der Karten bedient. In der vorhan-denen Implementation von WeCaSo befindet sich dieser Bereich auf der linkenSeite jeder Karte und wird durch einen schwarz unterlegten Bereich mit einem ≡-Zeichen markiert. Im Folgenden wird dieser Bereich als „Drag-Button“ bezeich-net. Unter Umständen kann es vorkommen, dass eine Testperson die Funktiondieses Drag-Buttons nicht sofort erkennt. Ob dies ein Problem darstellt, welcheseiner besseren Lösung bedarf, ist an dieser Stelle nur schwer einzuschätzen. Zu-nächst wird in diesem Konzept davon ausgegangen, dass der Drag-Button einenzufriedenstellenden Kompromiss bildet, um innerhalb der Experimentoberflächezu navigieren und gleichzeitig Karten verschieben zu können.

3.5.2 Vertikales Design BAbbildung 3.4 zeigt ein alternatives Konzept Oberfläche der Experimente bei ver-tikaler Ausrichtung des Bildschirms. Ebenso wie bei Design A teilt sich der abge-bildete Bereich in Titelzeile mit Buttons, Grundbegriffstapel und Kategoriestapelauf.

14

3.5 Oberflächendesign

Anleitung Ende

Karteninhalt

KarteninhaKarteninhalt

Karteninha

WECASOExperiment: Titel

Karten

Kategoriename Kategoriename

≡≡

≡≡≡

Karteninhalt

Karteninhalt

Karteninha

Karteninha

Karteninha

Scroll: Kategorien← →

≡≡

≡≡

≡≡≡

Karteninha

Karteninha

Karteninha

← →Scroll: Karten

Scr

oll:

Kart

en

inhalt

↑

↓

Abbildung 3.4: Design Vertikal B

Im Wesentlichen implementiert dieses Design die gleichen Funktionen und Eigen-schaften, die bereits in Abschnitt 3.5.1 beschrieben wurden. Der zentrale Unter-schied zwischen Design A und B ist die Ausrichtung der Navigation und Verteilungder Bildschirmfläche zwischen dem Grundbegriffstapel und den Kategoriestapeln.Design B sieht vor die Karten des Grundbegriffstapels ebenfalls horizontal aus-zurichten. Dies soll erwirken, dass der Kartenstapel weit weniger Platz in derVertikalen benötigt. Der Vorteil an dieser Ausrichtung liegt darin, dass nun dieStapel der Kategorien im Verhältnis größer werden und somit mehr Elementegleichzeitig zeigen können. Dies gibt dem Tester mehr Informationen bezüglichdes Inhalts einer Kategorie, die er gleichzeitig sehen kann.

Der Nachteil dieses Designs ist jedoch auch eine höhere Komplexität in der Navi-gation. Bis auf die Einfärbung der Kopfzeile, sind die Stapel der Ursprungskartenund die Stapel der Kategorien in Design A visuell und funktional identisch. DesignB erzeugt eine Inkonsistenz in der Art der Navigation innerhalb der Stapel. Esbesteht die Möglichkeit, dass diese Inkonsistenz zu Verständnisschwierigkeiten beider Navigation der Experimentoberfläche führt. Die Ausrichtung und Navigationder Kategoriestapel sowie ihres Inhalts ist identisch zu Design A.

15

3 Konzept

3.5.3 Horizontales DesignDas horizontale Design soll die Ausrichtung des Bildschirm nutzen, um die Navi-gation zwischen den einzelnen Elementen des Experiments auf andere Weise zuunterstützen. Bis auf die Funktion des Drag-Buttons, sind die Eigenschaften derOberfläche, wie sie in Abschnitt 3.5.1 beschrieben wurden, angepasst. Abbildung3.5 zeigt das konzeptuelle horizontale Design.

Anleitung Ende

WECASOExperiment: Titel

Karten Kategoriename

≡ KarteninhaltKarteninhalt≡Karteninhalt≡Karteninhalt≡Karteninhalt≡Karteninhalt≡

Kategoriename

≡ Karteninhalt

≡ Karteninhalt

≡ Karteninhalt

Scr

oll:

Kate

gori

en

Scr

oll:

Kart

en

inhalt

↑↑

↓↓ {

10%← →Breite: 40% Breite: 50%← →

Abbildung 3.5: Design Horizontal

Verteilung der Bildschirmfläche

Zunächst sind der Grundbegriffstapel und die Stapel der Kategorien nun hori-zontal nebeneinander angeordnet. Dies ist die ersichtlichste, notwendige Anpas-sung, um sowohl die Stapel als auch ihre Inhalte möglichst sichtbar zu halten.Die Kategoriestapel sollen untereinander angeordnet werden. Wichtig ist hier dieGrößenverteilung der Stapel. Ihre Höhe soll hier zwischen 70-80% der Bildschirm-höhe betragen. Damit werden möglichst viele Elemente des Grundbegriffstapelsund der Kategorien gleichzeitig darstellbar. Um die konsistente Sichtbarkeit derKarten nicht unnötig zu beeinträchtigen, sollen der Grundbegriffstapel und dieKategoriestapel etwa die gleiche Breite besitzen. Ebenso ist jedoch ein gewisservisueller Unterschied zwischen diesen Stapeln unter Umständen hilfreich für dieTestperson, da so verständlich gemacht wird, dass der Grundbegriffstapel unddie Stapel der Kategorien unterschiedlichen Zwecken dienen. Außerdem sollte einbestimmter, leerer Bereich zwischen dem Grundbegriffstapel und der Kategorienbei der Navigation hilfreich sein, wie im Folgenden erläutert wird. Für die Vertei-lung der Breiten zwischen den Stapeln und des Leerbereichs wird zunächst eine

16

3.5 Oberflächendesign

Verteilung von 40% zu 10% zu 50% festgelegt (siehe Abbildung 3.5).

Navigation

Die Navigation zwischen den Elementen wird in dieser Ansicht nur durch vertika-les Scrollen realisiert. Auf diese Weise erhöht sich die Konsistenz in der Art derBedienung der einzelnen Elemente, da nun sowohl der linke als auch der rechteBereich der Oberfläche identische Handhabung aufweisen. Im Gegenzug ist es nunaber nicht mehr praktikabel die Größe der Kategoriestapel zu begrenzen. Die Ka-tegorien müssen zusammen mit ihrem Inhalt als gesamte, große Liste navigiertwerden. Dadurch ergibt sich zwangsläufig, dass ab einer bestimmten Anzahl anElementen innerhalb einer Kategorie der Kategoriename nicht mehr auf dem Bild-schirm angezeigt wird. Somit muss die Testperson an dieser Stelle, den Namen derKategorie aus den Elementen schließen, die bereits einsortiert worden sind odersich der Scrollfunktion bedienen, um sich des Kategorienamens zu vergewissern.

3.5.4 Desktop-DesignDas ursprüngliche Design, wie in Abschnitt 3.1 beschrieben, bietet alle notwendi-gen Funktionen, um Card Sorting Experimente durchzuführen und das grundsätz-liche Design sollte eine intuitive Navigation auf der Arbeitsfläche möglich machen.Somit sollen an diesem keine grundlegenden Änderungen vorgenommen werden.Einzig die statische Festlegung der Größe des Grundbegriffstapels wird nicht mehrnotwendig sein, sobald die Oberflächen für kleinere Bildschirme implementiertsind. Somit ist angedacht die Höhe des Grundbegriffstapels und des Bereichesder gesamten Kategoriestapel auf etwa 80% der möglichen Anzeigefläche zu set-zen. Dadurch sollten auch bei der Anzeige auf großen Monitoren möglichst vieleElemente des Grundbegriffstapels sichtbar sein. Bei entsprechend vielen Grundbe-griffen wird natürlich auch ein Monitor an Darstellungsgrenzen stoßen. In diesemFalls sollte die Navigation innerhalb und zwischen den Stapeln analog zur in Ab-schnitt 3.5.3 vorgestellten Navigationsmethode funktionieren.

17

4 ImplementierungDieses Kapitel stellt die technische Realisierung der Konzepte aus Kapitel 3 vor.

4.1 EntwicklungsumgebungWie bereits mehrfach erwähnt, wurden die konzeptuellen Designs der Card Sor-ting Experimentoberflächen auf Basis der vorhandenen WeCaSo Webapplikationimplementiert. An dieser Stelle werden die für die Implementation wichtigen Ele-mente der Entwicklungsumgebung beschrieben (für vollständige technische Detailsder WeCaSo-Implementierung siehe [7] S.23-55).

4.1.1 Laravel 5.1Laravel[3] ist ein open-source PHP-Framework, welches den Kern der Implemen-tierung von WeCaSo darstellt. Die Vorteile dieses Frameworks liegen u.A. in derfesten Strukturierung der erstellten Applikationen und dem Artisan-Tool zur Ver-waltung der Projektumgebung. Im Bezug auf diese Ausarbeitung unterstütze be-sonders das von Laravel genutzte Model-View-Controller Prinzip die Implementa-tion der neuen Experimentoberflächen.

Model-View-Controller

Ein zentrales Paradigma bei der Erstellung von Webseiten mit Hilfe von Laravelist das Model-View-Controller Prinzip. Diese Architektur der Webapplikation er-zeugt eine strikte Trennung zwischen Datenmodell, Controllern und Oberflächen.Abbildung 4.1 zeigt dabei den Informationsfluss zwischen den einzelnen Elementender Architektur. Da bei Durchführung eines Card Sorting Experiments die Test-person lediglich mit der Oberfläche der Webseite, also der View, interagiert, solltees möglich sein, die in Kapitel 3 vorgestellten Konzepte nur durch Modifikationder entsprechenden Views in WeCaSo zu implementieren. Das Datenmodell sowiedie Controller, die den Informationsaustausch mit der Oberfläche des Experimentssteuern, werden demnach im Rahmen dieser Arbeit nicht weiter betrachtet.

Blade

Blade ist die Laravel zugehörige Templating-Engine und ist somit zentraler Be-standteil der von Laravel erzeugten Views. Mit Hilfe von Blade ist es möglichLayouts von Webseiten zu erstellen, indem ein Master-Template definiert wird,

19

4 Implementierung

Abbildung 4.1: Anwendung des MVC Prinzips bei Laravel

welches die grundlegenden Informationen der angezeigten Webseite enthält. DiesesTemplate wird dann von den eigentlich aufgerufenen Seiten geerbt und erlaubt aufdiese Weise kohärent strukturierte Designs, während gleichzeitig Redundanzen desPHP-Quelltextes reduziert werden. Blade-View Dateien nutzen die Dateiendung.blade.php und sind typerischerweise im recources/views Ordner zu finden[3].

4.1.2 Bootstrap

WeCaSo implementiert ebenfalls das Bootstrap CSS-Framework[1]. Bootstrap bie-tet eine Vielzahl von HTML und CSS Designelementen, die die Entwicklung vonWebseiten mit respronsivem Design unterstützen.

4.1.3 Responsive Design

Responsive Design ist ein neuartiges Design Paradigma, dass durch die rasan-te Verbreitung von Smartphones, Tablets und anderen Smart Devices entstandenist. Die Fülle an unterschiedlichen Bildschirmformaten, die heutzutage Anwendungfindet, reicht von Smartphones mit 4-Zoll-Display bis hin internetfähigen, hoch-auflösenden TV-Geräten mit mehr als 50-Zoll-Bildschirmdiagonale. Die Anwen-dung eines responsiven Webseitendesigns bedeutet, die angezeigten Oberflächenabhängig von Rahmenbedingungen bezüglich der Größe des genutzten Bildschirmsanzupassen.

20

4.2 Konzeptauswahl

4.2 Konzeptauswahl

In Kapitel 3 wurden zwei mögliche Alternativen zum Design der Experimentober-fläche bei vertikaler Ausrichtung des Bildschirms vorgestellt. Das implementierenbeider Designs würde verlangen, dass statt der ausschließlichen Überarbeitungder View-Komponenten von WeCaSo zusätzliche Funktionen in die vorhandenenController integriert werden müssen. Weiterhin ergab sich, dass die Elemente derKarten Teil der JQuery-Bibliothek Nestable.js (vgl.[7] S.30) sind, die in der vor-handenen Implementation horizontale Anordnung von Elementen einer Liste nichtunterstützt. Anpassungen in der visuellen Darstellung der Elemente zur horizonta-len Anordnung führten dabei zu unerwünschten Effekten im Bezug auf das Formatder dargestellten Elemente.Aufgrund der minimalen Unterschiede zwischen den horizontalen Designs A

und B, wurde somit das Design B nicht implementiert. Realisiert wurden somitdas vertikale Design A, das horizontale Design und die Anpassungen des DesktopDesigns, die in Kapitel 3 vorgestellt wurden.

4.3 Komponenten

Grundlegende Überarbeitungen der Folgenden Komponenten von WeCaSo wurdenimplementiert:

4.3.1 Bootstrap.css

Die Bootstrap.css Datei ist ein umfangreicher CSS-Stylesheet, der die grundle-genden Parameter der responsiven Designs festlegt. Das ursprüngliche Problemder Experimentoberfläche, bestand zum Teil darin, dass in diesem Stylesheet dieAbfragen für unterschiedliche Bildschirmauflösungen bei Mindestbreiten von 768Pixel und 992 Pixel liegen. Diese Bedingungen sind jedoch für Smartphones ab-solut unzutreffend. Übliche Displaygrößen von Smartphones reichen von 320 bis400 Pixel in der Breite und 480 bis 640 Pixel in der Höhe (vgl.[6]). Um also dieerarbeiteten Konzepte von vertikalem, horizontalem und Desktop Design umzu-setzen, wurde zunächst die Mindestbreite für das horizontale Design auf 500 Pixelgesetzt. Eine Änderung der zweiten Grenze der Mindestbreite, welche die Nutzungdes Desktop Designs bedingt, erschien nicht als Notwendig.Somit wird standardmäßig das vertikale Design als Oberfläche genutzt und bei

horizontaler Ausrichtung des Smartphones sollte automatisch auf das horizontaleDesign gewechselt werden. Ebenfalls wurden an dieser Stelle die unterschiedlichenSichtbarkeitsgrenzen der Stapel festgelegt.

21

4 Implementierung

4.3.2 Experiment-ViewDie Experimentoberfläche von WeCaSo bedient sich der Layouting Technik vonBlade und besteht aus sechs Dateien.

experiment-master.blade.php

Dies ist das Master-Template der Experimentoberfläche und definiert lediglich diegenutzten CSS-Stylesheets, den Titelbereich der Webseite und die in jedem Fallnötigen Scriptanteile.

closed-sorting.blade.php und open-sorting.blade.php

Diese beiden Dateien bilden den wichtigsten Teil der Experimentoberfläche, dahier die HTML Elemente definiert werden, welche letztlich als die entsprechen-den Stapel und Karten dargestellt werden. In der ursprünglichen Implementationwurden die Elemente hier lediglich für Mindestbreiten einer Anzeige von 922 Pi-xel definiert und viele der Sytleparameter der genutzten CSS-Sytlesheets wurdenbei den jeweiligen Elementen ersetzt, was das ursprünglich mögliche, responsiveDesign durch das Bootstrap Framework nicht funktional machte.Dieser Stilbruch wurde an allen nötigen Stellen beseitigt. Dadurch werden nun

alle responsiven Elemente der Oberfläche durch die Definitionen in Bootstrap.cssgesteuert.

experiment.blade.phpquestionary.blade.phpinstructions.blade.php

Dies sind die entsprechenden Views, die die Willkommensnachricht, den Fragebo-gen und die Anleitung der Experimente anzeigen. Die Darstellung dieser Elementefunktioniert in der ursprünglichen Implementaion von WeCaSo vollkommen aus-reichend auf Smartphones und waren daher auch nicht Gegenstand der Überar-beitung. Während der Implementation der Experimentoberfläche fiel jedoch auf,dass die Darstellungselemente der Textfelder und Fragen derselben Klasse zuge-hören, wie die Stapel der Experimentoberfläche. Die unterschiedlichen Größenbe-schränkungen, welche im Zusammenhang mit der Experimentoberfläche festgelegtwurden, weiteten sich somit auch auf die Masken der Textfelder und Fragen aus.Zur Lösung dieses Effekts wurden die entsprechenden Elemente in diesem Fall

mit individuellen Style-Parametern versehen. Dies steht dem Prinzip der responsi-ven Designs zuwider. Da diese Elemente jedoch unabhängig von der Experimento-berfläche stets die selben Style-Parameter besitzen dürfen, ist dies eine funktionaleLösung.

22

5 Evaluation

5.1 TestaufbauZiel der Evaluation war es die Designentscheidungen aus Kapitel 3 zu prüfen undetwaige technische Schwierigkeiten bei der Bedienung auf dem Smartphone festzu-stellen. Der Inhalt des Card Sorting Experiments an sich war somit von geringerPriorität. Um sicherzustellen, dass die Testpersonen sich auf die Bedienung undSichtbarkeit der Oberfläche konzentrieren, wurde ein sehr simples Closed CardSorting Experiment (siehe Abschnitt 2.1) erstellt, bei dem es darum ging Tierna-men in entsprechende Kategorien ihrer Spezies zu sortieren. Abbildung 5.1 zeigtdas Experiment in Großansicht.

Abbildung 5.1: Oberfläche: Evaluationsexperiment - Großansicht

Im Einleitungstext des Experiments wurde den Testern lediglich erklärt, dass esdarum geht eine vorgegebene Menge an Begriffen in passende Kategorien einzu-ordnen und dass es Ziel des Tests ist, die Oberfläche zu bewerten, nicht die Begrifferichtig einzusortieren. An der Stelle des Anleitungstextes wurde den Testpersonenmitgeteilt, dass es gezielt keine Erklärung zu Benutzung der Oberfläche gäbe. DieExperimente wurden einzeln durchgeführt. Während des Experiments wurde dieTestperson vom Evaluator beobachtet und gezielt befragt. Die Fragen zum Beginn

23

5 Evaluation

des Experiments wurden gestellt, sobald die Testperson die Oberfläche des Expe-riments geöffnet und erste Interaktionsversuche unternommen hatte. Dies sollteerlauben Schlüsse bezüglich des Verständnisses der Sichtbarkeit und Bedienungzu ziehen. Die Fragen zum Ende des Experiments dienten der Feststellung vonspontanem Feedback der Testperson.

Tabelle 5.1: TestfragenFragen zu Beginn: Fragen zum Ende:Worum geht es bei dem Ex-periment?

Welche Probleme entstan-den bei der Benutzung?

Woraus besteht der das Ex-periment?

Gibt es Verbesserungsvor-schläge?

Wie bedient man die einzel-nen Elemente?Ist alles lesbar?

Die Gruppe der Testpersonen bestand aus fünf Personen. Drei davon im Altervon 24 bis 27 Jahren, zwei im Alter von 51 und 54 Jahren. Keine der Testpersonenbesaß Vorkenntnisse bezüglich der Card Sorting Methode oder Webdesign odersonstige Programmierkenntnisse. Die Tests wurden auf unterschiedlichen Smart-phones geführt, darunter sowohl Android als auch iOS Systeme.

5.2 ErgebnisseAbbildung 5.2 zeigt die Experimentansicht wie sie Testpersonen den Testpersonenzu Beginn vorlag. Die Fragen zu Beginn der Tests führten bei allen Testpersonenzu ähnlichen Antworten. Alle Testpersonen erkannten sofort, dass es sich um Be-zeichnungen für Tiere handelte und dass diese in Kategorien einzusortieren waren.Auf die zweite Frage nach den Bestandteilen des Experiments musste bei drei

der Testpersonen klarifiziert werden, dass es sich um die Einzelteile des Experi-ments handele, nach denen gefragt war. Nach dieser Klarifizierung wussten jedochalle Testpersonen die Begriffskarten, den Ursprungskartenstapel und die Katego-riestapel sowie die Buttons zum Beenden des Experiments aufzuzählen.Bei der Frage nach der Lesbarkeit wurde ebenfalls bei allen Testpersonen nichts

beanstandet. Diskrepanzen ergaben sich bei der Frage nach der Bedienung. DieNavigation innerhalb der Liste der Karten durch Scrollen mit der typischen Wisch-geste wurde von allen Testpersonen sofort erkannt.Eine Testperson jedoch erkannte die Möglichkeit des seitlichen Scrollens der

Kategoriestapel erst nachdem darauf hingewiesen wurde, dass es möglicherwei-se zusätzliche Kategorien gäbe. Weiterhin ergab sich, dass die Funktionalität desDragbuttons bei drei der fünf Testpersonen nicht offensichtlich war. In diesen Fäl-len wurde meist versucht, die Karten zu verschieben indem sie an einer beliebigen

24

5.2 Ergebnisse

Abbildung 5.2: Experimentoberfläche: Ansicht der Testpersonen - vertikal

Stellen gegriffen wurden, um sie dann per Drag & Drop zu verschieben. Dies wirdder fehlenden Erklärung zur Bedienung zu schulden sein. Jedoch haben auch dieseTestpersonen die Funktion des Drag-Buttons erkannt, nachdem anfängliche Be-dienungsversuche nicht die erwarteten Effekte erzeugten.

Nachdem die Testpersonen sich mit der Experimentoberfläche vertraut gemachthatten, wurden die Fragen nach Bedienungsproblemen und Verbesserungsvorschlä-gen gestellt. Wie zu erwarten war ergaben sich bei der Bedienung eine Vielzahl anProblemen, die im Folgenden beschrieben werden:

1. Die Größenverteilung der Experimentoberfläche wurde in der Implementie-rung so gewählt, dass die ursprüngliche Kartenstapel und die Kategoriesta-pel jeweils 40% der Bildschrimhöhe betragen. Dies erzeugt eine möglichstgroße Fläche für die Stapel. Es verlangt aber auch, dass eine Testperson er-kennt, dass die Seite als Ganzes scrollbar ist und dies auch getan wird, umdie Kategoriestapel vollständig anzuzeigen. Es ergab sich das Problem, dassunter Umständen sie gesamte Seite wieder zurück hochgescrollt wird, wenndie Testperson nicht die passende Fläche zum Scrollen eines gewünschtenElements trifft. Dies führte auch dazu, dass teilweise versucht wurde Kartenin Kategorien zu verschieben, indem sie auf der Titelzeile eines Kartenstapelsabgelegt wurden.

25

5 Evaluation

2. Die Titelzeile mit dem WeCaSo Logo und dem Experimenttitel wurde ineinem Fall als zu groß empfunden.

3. Um eine Karte richtig einzusortieren, war es nötig die Karte so in den Ka-tegoriestapel zu ziehen, dass der Dragbutton der aktuellen Karte über denlinken Bereich der weißen Fläche im Kategorietapel gezogen wird.

4. Beim Einsortieren der Karten in eine leere Kategorie existiert eine gewisseVerzögerung bis die umrandete Fläche angezeigt wird, die darauf hinweist,dass die aktuelle Karte an diese Stelle einsortiert werden kann. Sobald eineKarte in einem Stapel liegt, ist dies jedoch nicht mehr der Fall.

5. Die Oberfläche im horizontalen Format hat bei drei der fünf Smartphonesnicht funktioniert, da die Auflösung der Bildschirme niedriger war als ge-schätzt wurde.

6. Bei Benutzung des Chrome Browsers scheint es eine Funktion zu geben, diebei Markieren eines Wortes ein Popup am unteren Bildschirmrand erzeugt,um nach dem Wort per Suchmaschiene suchen zu lassen. Da man die Inhalteder Karten durch längeres Drücken markieren kann, erzeugt diese Funktionein Popup, das einen Teil der Experimentoberfläche verdeckt.

7. Auf dem iOS mit dem Safari Browser ergibt sich ein zusätzliches Designpro-blem. Eine große Wischgeste von links nach rechts über die Breite des Bild-schirms ersetzt hier die Zurück-Taste der Android Smartphones, welche esauf dem iPhone nicht gibt. Diese Geste wird aber bei vertikaler Ausrichtungdes Bildschirms auch zur Navigation der Kategoriestapel verwendet.

8. Beim im Test genutzten iPhone 7 entstanden Performanzprobleme. Zu Be-ginn war beim Drag & Drop der Karten deutliches Ruckeln zu erkennen,welches nach etwa einer Minute nachzulassen schien.

Nachdem die Testpersonen keine weiteren Probleme finden konnten, wurde auchauf die Möglichkeit hingewiesen das horizontale Format zu nutzen (siehe Abbil-dung 5.3). Dies funktionierte aber aufgrund der Auflösung nur bei drei Testper-sonen. Im Allgemeinen galten für das horizontale Format die bereits genanntenProbleme.Eine Testperson merkte an, es sei nicht offensichtlich, dass wie man die Seite im

gesamten scrollt, um die Titelzeile aus dem Sichtbereich zu schieben. Die Navi-gation im horizontalen Format wurde von allen drei Testpersonen sofort erkannt.Die Testpersonen wurden ebenfalls gefragt, welche der Varianten sie präferierten.Die Testpersonen hatten klare Vorlieben bei der Wahl des Formats, wobei zwei diehorizontale und eine die vertikale Ansicht bevorzugte. An dieser Stelle sei ebenfallsangemerkt, dass eine der Testpersonen, die die horizontale Ansicht nicht testenkonnte, als Verbesserungsvorschlag ein anderes Design vorschlug, welches dem hiervorgestellten horizontalen Design entsprach.

26

5.3 Zusammenfassung der Evaluation

Abbildung 5.3: Experimentoberfläche: Ansicht der Testpersonen - horizantal

Als Verbesserungsvorschläge wurden genannt:

• Die Reaktionsgeschwindigkeit des Einsortiermechanismus sollte verbessertwerden.

• Die Scrollbalken der Elemente sollten permanent angezeigt werden, um denTestpersonen deutlicher zu machen, wie große die unterschiedlichen Bereicheder Oberfläche tatsächlich sind.

5.3 Zusammenfassung der EvaluationZusammenfassend sind die Ergebnisse des Evaluationstest als durchaus positiv zubetrachten. Die Konzipierung der Oberflächen, im Bezug auf die Navigation zwi-schen den sichtbaren und nicht sichtbaren Elementen des Experiments, führte zueiner sehr schnellen Auffassung der Testpersonen, auch ohne explizite Anleitung.Nachdem die Testpersonen die Bedienung des Experiments und die vorhande-

nen Elemente verstanden hatten, war ein relativ problemloses beenden des Expe-riments bei allen Testpersonen möglich. Die Möglichkeit der Wahl zwischen dervertikalen und der horizontalen Ansicht der Oberfläche, ist ebenfalls eine wertvolleFunktion, da sich an dieser Stelle individuelle Vorlieben der Testpersonen zeigen.Verbesserungsvorschläge bezogen sich ausschließlich auf die Beseitigung vorhan-

dener technischer Probleme oder Optimierung der Große bestimmter Elemente.Das konzeptuelle Design der unterschiedlichen Oberflächen stieß somit auf sehrpositive Resonanz.

27

6 FazitDas Ziel dieser Arbeit war die Oberfläche der Card Sorting Experimente von We-CaSo neu zu konzipieren und zu implementieren, um damit zu ermöglichen, dassdie Vorteile der Mobilität und Allgegenwärtigkeit von Smartphones zur Durchfüh-rung von Card Sorting Experimenten genutzt werden können. Im Folgenden wirddie Ausarbeitung zusammengefasst und die Ergebnisse bewertet. Anschließendwird ein Ausblick auf mögliche Fortsetzungen der Arbeit präsentiert.

6.1 ZusammenfassungDrei zentrale Themen wurden mit dieser Ausarbeitung betrachtet. Mögliche Kon-zepte einer Touchoberfläche für WeCaSo Experimente, die Implementierung dieserKonzepte in die vorhandene Webapplikation und die Evaluation der Implementie-rung durch eine Testgruppe.

Die Entwicklung der Konzepte führte durch die Beantwortung der grundlegen-den Fragen von Sichtbarkeit und Navigierbarkeit zur Findung von Bedingungen,die die Oberflächen der Experimente zu erfüllen hatten, um ein möglichst großesMaß an Benutzerfreundlichkeit zu erreichen. Dabei wurde klar, dass beim Über-tragen von Card Sorting auf extrem begrenzte Arbeitsflächen stets Kompromissezu treffen sind. Hilfreiche Bedienelemente verlangen immer nach Platz um diesezu nutzen, während die Methode des Card Sorting ebenso durch möglichst großeSichtbarkeit der gesamten Kartenmenge komfortabler wird.

Die größte Schwierigkeit der Implementation bestand im Verständnis der gege-benen Implementation von WeCaSo. Die Webapplikation ist von großer Komple-xität und da es sich auch um eine prototypische Entwicklung handelte, war eineDokumentation des Quellcodes kaum vorhanden. Nach entsprechender Einarbei-tung wurde jedoch klar, dass vorhandenen Frameworks und Bibliotheken durchausausreichend waren, um die entwickelten Konzepte zu realisieren.

Die Evaluation lieferte viele, wichtige Erkenntnisse. Auch mit der begrenztenGröße der Testgruppe wurde eine Vielzahl an kleineren Programmschwächen ent-deckt, die größtenteils durch einfache Anpassungen zu beheben waren. Im Bezugauf die konzeptuellen Entwürfe zeigt die Evaluation, dass die grundlegende Be-dienung der neuen Touchoberfläche intuitiv verständlich war. Die Implementationvon sowohl horizontalem als auch vertikalem Design verbesserte ebenfalls die Zu-

29

6 Fazit

friedenheit der Testpersonen, da es unter den Testpersonen individuelle Vorliebenbei der Bedienung gab.

6.2 AusblickDie Evaluation ergab, dass die implementierten Oberflächendesigns die Durchfüh-rung von Card Sorting Experimenten auf dem Smartphone funktional und intuitivverstehbar gemacht haben. Die Testgruppe und damit Anzahl der Tests war je-doch sehr begrenzt. Um ein besseres Verständnis der Benutzerfreundlichkeit zuerhalten, wären in weiterer Arbeit wesentlich größer angelegte Tests nötig. DasFeedback dieser Test sollte im Bezug auf Bedienung und Sichtbarkeit ausgewertetwerden, so dass ein wesentlich größerer und besserer Eindruck über die notwen-digen Eigenschaften und gewünschten Funktionen der Card Sorting Experimentegewonnen werden kann.

30

Literaturverzeichnis[1] Bootstrap. http://getbootstrap.com/. Aufgerufen am: 15.03.2018.

[2] Closed card sorting. https://www.flickr.com/photos/rosenfeldmedia/3344341528. Aufgerufen am: 15.03.2018.

[3] Laravel. https://laravel.com/docs/5.1. Aufgerufen am: 15.03.2018.

[4] Manuelles card sorting experiment. https://www.flickr.com/photos/rosenfeldmedia/3343498557. Aufgerufen am: 15.03.2018.

[5] Open card sorting. https://www.flickr.com/photos/rosenfeldmedia/3344343842. Aufgerufen am: 15.03.2018.

[6] Responsive webdesign. http://be-responsive.de/statistiken/. Aufgeru-fen am: 15.03.2018.

[7] Kailaash Balachandran. Concept and prototypical re-implementation of a web-based card sorting application with responsive design. Master’s thesis, Uni-versität Paderborn, 2016.

[8] Donna Spencer. Card Sorting: Designing Usable Categories. Rosenfeld Media,2009.

31