Bachelor esis

User Experience in tastaturgesteuerten Text-Adventures

Alexander Kluge (s0518665)
Internationaler Studiengang Medieninformatik Fachbereich 4, Wirtschaswissenschaen II Hochschule für Technik und Wirtscha, Berlin

Wissenschaliche Betreuung
Erster Betreuer: Prof. omas Bremer Zweiter Betreuer: Prof. Dr.-Ing. Carsten Busch

Abschlussarbeit zur Erlangung des akademischen Grades »Bachelor of Science«

© 2010 Alexander Kluge

Eingereicht am 07.10.2010, Berlin

1

Bachelor esis

User Experience in tastaturgesteuerten Text-Adventures

Abstract: Diese Arbeit untersucht die Nutzerfahrung (User Experience) und Gebrauchstauglichkeit (Usability) in tastaturgesteuerten Text-Adventures in der Umgebung von modernen Web-Browsern. Unter der Nutzung aktueller Web-Technologien wird zur besseren Anschauung ein Text-Adventure in Zusammenarbeit mit Tommy Krüger und seiner esis »Konzeption und Untersuchung von text-gesteuerten Adventuregames« prototypisch in Teilen umgesetzt. Der Schwerpunkt der esis liegt auf der Konzeption des Prototypen.

2

»Before the first person shooter there was the second person thinker.«
– Jason Scott [Sco 10]

3

Danksagung
Ich möchte mich an dieser Stelle bei Tommy Krüger bedanken, der mit mir während der Entwicklungszeit viele kreative Stunden und Tage verbrachte. Weiterhin soll den Testpersonen, die so eifrig und manchmal auch geduldig die Tests über sich ergehen ließen, gedankt werden – auch wenn sie erst später erfuhren, dass es sich um einen Test und kein normales »Wie findest du das?« handelte. »Sorry, es war wichtig!« Ich danke meiner Familie und meinen Freunden für die Unterstützung, vor allem für die Ratschläge und die stets gut gemeinten Ablenkungsmanöver. Außerdem soll der gesunden Ernährung und dem mindestens einmal wöchentlich stattfindenden Fußball gedankt werden – ohne Beides wäre meine Nerven völlig durchgebrannt. Auch sei den vielen Filmen, der Filmmusik und Musik im Allgemeinen gedankt, die ich im Laufe der Entwicklung konsumiert habe. Sie half mir, Inspiration zu finden, um vor allem das Drehbuch zu schreiben.

4

Hinweis
Fachbegriffe und Eigennamen werden beim ersten Aureten kursiv, danach normal gesetzt. Wichtige Begriffe werden zur besseren Unterscheidbarkeit kursiv oder fett gesetzt. Explizit gemeinte Begriffe, Zitate und wörtliche Rede werden in französischen Anführungszeichen »« gehalten.

5

Inhaltsverzeichnis
Inhaltsverzeichnis...............................................6 Abbildungsverzeichnis...........................................10 Tabellenverzeichnis.............................................12 Vorwort.........................................................13 1. Einführung...................................................14 1.1. Einleitung...............................................15 1.2. Motivation...............................................16 1.2.1.Herausforderungen....................................16 1.3. Ziel.....................................................17 1.4. Grenzen des Prototypen...................................17 1.5. Kompetenzverteilung......................................17 1.6. Anhang...................................................18 1.7. Herangehensweise.........................................18 2. Was ist User Experience?.....................................20 2.1. Erstes Verständnis.......................................21 2.2. User-Centered Design.....................................22 2.3. Universal Usability......................................22 2.3.1.Klassische Usability.................................22 2.3.2.Accessibility........................................23 2.3.3.Universal Usability..................................23 2.3.4.Universal Design.....................................24 2.4. User Experience..........................................25 2.5. Adventure................................................29 2.5.1.Text-Adventure.......................................30 2.5.2.Interactive Fiction..................................30 3. Ideenfindung.................................................31 3.1. Herangehensweise.........................................32 3.2. Ideenverschmelzung.......................................32 4. Analyse......................................................33 4.1. Herangehensweise.........................................34 4.2. Projektmanagement........................................37 4.2.1.Tools................................................37 4.2.2.Zeit und Ressourcen..................................37
6

4.2.3.Iterativer Entwicklungszyklus........................38 4.2.4.Alternative Entwicklungsprozesse.....................38 4.3. Marktsituation...........................................39 4.3.1.Spiele-Auswahl.......................................39 4.3.2.Zielgruppe...........................................43 4.3.3.Typische Merkmale....................................43 4.3.4.Alleinstellungsmerkmale von Ambernstein..............45 4.3.5.SWOT-Analyse von Ambernstein.........................46 4.4. Wahl der Technologie.....................................46 4.4.1.Vorteile nativer Browser-Technologien................47 4.4.2.Nachteile nativer Browser-Technologien...............48 4.4.3.Status Quo – Stand der Technik.......................48 4.4.4.Alternativen.........................................49 4.5. Strategie................................................49 4.5.1.Definition der Anwendung.............................49 4.6. Anforderungen............................................49 4.6.1.Inhaltlich...........................................50 4.6.2.Funktional...........................................50 4.6.3.Technisch............................................53 4.7. Angestrebte Funktionen...................................53 4.7.1.Kernfunktionen.......................................53 4.7.2.Außerordentliche Funktionen..........................53 4.8. Fazit....................................................54 5. Konzept......................................................55 5.1. Herangehensweise.........................................56 5.1.1.Sieben Schritte......................................56 5.2. Storytelling.............................................57 5.2.1.UX und Storytelling..................................57 5.2.2.Analogie zu Film und Buch............................58 5.2.3.Drehbuch.............................................60 5.2.4.Charaktere...........................................61 5.2.5.Soundtrack...........................................62 5.3. Abstrakte Struktur.......................................63 5.3.1.Informationsarchitektur..............................63 5.3.2.Interaktionsdesign...................................67
7

5.4. Konkrete Struktur........................................69 5.4.1.Interface Design.....................................69 5.4.2.Navigationsdesign....................................79 5.4.3.Informationsdesign...................................81 5.4.4.Wireframes...........................................82 5.5. Spieldesign..............................................83 5.5.1.Elemente.............................................84 5.5.2.Ein Spiel wie ein Film...............................86 5.5.3.Kurzbeschreibung von Ambernstein.....................86 5.5.4.Spielkonzept.........................................86 5.5.5.Spielvorhaben........................................86 6. Umsetzung....................................................88 6.1. Herangehensweise.........................................87 6.1.1.Entwickler und Nutzer................................87 6.2. Drehbuch.................................................87 6.2.1.Erster Akt...........................................91 6.2.2.Zweiter Akt..........................................92 6.2.3.Dritter Akt..........................................92 6.3. Webseite.................................................92 6.3.1.Technisch............................................92 6.3.2.Visuelles Design.....................................94 6.4. Spiel....................................................96 6.4.1.Technisch............................................96 6.4.2.Visuelles Design.....................................96 6.5. Angewandte Datenstruktur.................................98 6.6. Eingesetzte Software.....................................99 6.7. Nicht umgesetzte Funktionen..............................99 6.8. Probleme und Herausforderungen..........................100 6.8.1.Lösungen für das Neuladen der Webseite..............100 6.8.2.Lösungen für deaktiviertes JavaScript...............101 7. Test.........................................................102 7.1. Herangehensweise........................................103 7.2. Testauswahl.............................................103 7.2.1.Browser-Tests.......................................103 7.2.2.Usability-Tests.....................................104
8

7.2.3.Benutzerbefragung...................................105 7.2.4.»Quick-Experience«..................................105 7.2.5.Forschungsbasierte Richtlinien......................105 7.2.6.Best Practices......................................105 7.2.7.Heuristiken.........................................106 7.3. Durchführung............................................107 7.3.1.Card-Sorting........................................107 7.3.2.Card-Sorting #2.....................................108 7.3.3.Web Usability.......................................108 7.3.4.Game Usability......................................113 8. Konklusion..................................................114 Nachwort.......................................................117 Glossar........................................................118 Literaturverzeichnis...........................................119 Kolophon.......................................................123 Anhang.........................................................124 I. Ambernstein – Die Vision...................................125 II. Technische Anforderungen an die UX.........................136 III.Sitemap (IA und IxD).......................................144 IV. Game Concept...............................................145 V. Game Proposal..............................................148 VI. Soundtrack.................................................150 VII.Style Guide................................................151 VIII.Drehbuch, inkl. Kurztreatment.............................152 IX. Ergebnisse der Usability-Tests.............................201 X. Anleitung zur Ausführung des Prototypen....................209 XI. Quellcode..................................................210 Eigenständigkeitserklärung.....................................230

9

Abbildungsverzeichnis
Abb. 1 – Die genormte Sicht auf Usability und User Experience.................21 Abb. 2 – Die Disziplinen der UX...............................................25 Abb. 3 – Die UX-Honigwabe.....................................................26 Abb. 4 – UX-Modell............................................................26 Abb. 5 – Die wesentlichen Elemente des Experience Design (Auszug).............27 Abb. 6 – Die UX-Hierarchie der Nutzerbedürfnisse (Auszug).....................27 Abb. 7 – Verarbeitung der UX durchs Gehirn....................................28 Abb. 8 – Die Wichtigkeit von UX...............................................29 Abb. 9 – Entwicklungsprozess für UX (UPA).....................................34 Abb. 10 – Usability als Schritt-Schritt-Anleitung.............................35 Abb. 11 – Elemente der UX (Auszug)............................................36 Abb. 12 – Zeitplan............................................................37 Abb. 13 – Iterative Entwicklungssequenz.......................................38 Abb. 14 – Colossal Cave per Java-Applet.......................................43 Abb. 15 – Zork 1 per Java-Applet..............................................43 Abb. 16 – Zork 1 per JavaScript...............................................44 Abb. 17 – Slouching Towards Bedlam............................................44 Abb. 18 – Stone Age Sam per Flash.............................................44 Abb. 19 – Typer Shark per Flash...............................................44 Abb. 20 – Blue Lacuna (Exzerpt) im Browser....................................45 Abb. 21 – Die sieben Handlungsschritte eines Nutzers nach Norman..............57 Abb. 22 – Greifbare UX-Elemente in Film und Webseite..........................59 Abb. 23 – Experience Theme....................................................60 Abb. 24 – Drei-Akt-Struktur eines Films.......................................60 Abb. 25 – Spannungsverlauf eines Films........................................61 Abb. 26 – Kreise der IA/UX....................................................63 Abb. 27 – Hierarchische Informationsstruktur..................................65 Abb. 28 – Sequenzielle und organische Informationsstruktur....................65 Abb. 29 – Ausbau einer hierarchischen Struktur................................65 Abb. 30 – Task Flow eines frühen Wireframes...................................68 Abb. 31 – Frühe Übersicht der UI-Elemente – teilweise mit Funktionsabläufen...69 Abb. 32 – Frühes Wireframe des Web UI Layouts.................................71 Abb. 33 – Web UI mit Footer als Funktionseinheit..............................71 Abb. 34 – Erwartung der Nutzer über den Ort der internen Navigation...........72 Abb. 35 – Erwartung der Nutzer über den Ort weiterer Navigationselemente......72 Abb. 36 – Web UI Elemente.....................................................74 Abb. 37 – Game UI.............................................................75 Abb. 38 – Farbpalette »Accessible«............................................76

10

Abb. 39 – Zweite Farbpalette »Accessible«.....................................76 Abb. 40 – Farbpalette eines Zeitungsartikels..................................76 Abb. 41 – Finale Farbpalette für den Web-Modus................................77 Abb. 42 – Finale Farbpalette für den Spiel-Modus..............................77 Abb. 43 – Elemente des Spiel-Modus............................................78 Abb. 44 – Anordnung der Erklärung zur Steuerung im Spiel-Modus................79 Abb. 45 – Navigationssysteme..................................................80 Abb. 46 – Navigationssysteme am Beispiel von IBM..............................81 Abb. 47 – Frühes Wireframe des Web-Modus......................................82 Abb. 48 – Frühes Wireframe des Spiel-Modus....................................82 Abb. 49 – Konzeptionelles Wireframe des Spiels-Modus..........................83 Abb. 50 – Etappen der Akte auf Zetteln........................................89 Abb. 51 – Strukturmodell des Drehbuchs nach Syd Field.........................90 Abb. 52 – Verlauf der Story in sechs Etappen..................................90 Abb. 53 – Pfad des ersten Akts (Ausschnitt)...................................53 Abb. 54 – Visuelles Design der Webseite.......................................94 Abb. 55 – Die Gestalt-Prinzipien der Nähe, Ähnlichkeit und Kontinuität........95 Abb. 56 – Das Gestalt-Prinzip der »uniformen Verbundenheit«...................96 Abb. 57 – Visuelles Design des Spiels.........................................97 Abb. 58 – Visuelle Verbindung von Game UI und Web UI..........................97 Abb. 59 – Farbpalette »Gentle Waves«..........................................98 Abb. 60 – Visueller Fortschritt im Footer.....................................98 Abb. 61 – Datenstruktur.......................................................99 Abb. 62 – Webseite für Testperson #1.........................................109 Abb. 63 – Webseite für Testperson #2, #3 und #4..............................110 Abb. 64 – Anpassung der Webseite mit Feedback von Testperson #1..............111 Abb. 65 – Anpassung #2 der Webseite mit Feedback von Testperson #1...........112 Abb. 66 – Finale Anpassung der Webseite mit Feedback von Testperson #1.......112

11

Tabellenverzeichnis
Tab. 1 – Kompetenzverteilung..................................................18 Tab. 2 – Colossal Cave und Zork 1 im Vergleich................................41 Tab. 3 – Slouching Towards Bedlam und Blue Lacuna im Vergleich................42 Tab. 4 – Stärken und Schwächen von Ambernstein................................46 Tab. 5 – Chance und Gefahren für Ambernstein..................................46 Tab. 6 – Mythische Muster in Filmen (Matrix, Star Wars).......................58 Tab. 7 – Lösungen für deaktiviertes JavaScript...............................101 Tab. 8 – Heuristiken für Game Usability (Auswahl)............................107 Tab. 9 – Ergebnisse des Usability-Tests......................................107 Tab. 10 – Ergebnisse des Card-Sorting........................................108

12

Vorwort
Nie hätte ich gedacht, dass ich jemals ein Spiel selbst schreiben würde. Es fing alles relativ harmlos mit einem Artikel aus dem GEE-Magazin [Nee 10a] an, der Tommy Krüger und mich von der Idee überzeugte, ein kleines eigenes Text-Adventures namens Ambernstein zu schreiben. Vergleicht man die Idee und Umsetzung von Ambernstein mit einer Pflanze, dann könnte man sagen, dass mit der Abgabe dieser esis die Pflanze gerade dabei ist, zu entstehen. Gute Voraussetzungen sind mit der Arbeit von Tommy Krüger und mir gegeben und müssen nun noch adäquat umgesetzt werden. Die vorliegende Arbeit soll den Entwicklungsprozess des Spiels beschreiben und die Vorstellungen, die dahinterstecken, erläutern. Ein Text-Adventure ist trotz seiner Reduktion auf Text als primäres Medium nicht weniger ein vollwertiges Spiel. Ich habe den Eindruck, der Aufwand für eine story-orientierte und interaktive Erzählung in Spielform wird gerne belächelt und unterschätzt. Die esis soll u.a. das Gegenteil beweisen und plausibel darlegen.

13

1
Einführung
Warum ich diese Thesis schreibe.

14

1 Einführung

1.1 Einleitung
Die Spiele der letzten zehn Jahre haben Vieles gemeinsam: Sie werden am PC überwiegend von Maus und Tastatur gesteuert, an der Spielkonsole per Gamepad oder – wie Nintendo zeigt – auch per Gestensteuerung mit Hilfe einer per Infrarot und Bluetooth betriebenen Fernbedienung. Spieleund Konsolenhersteller 1 setzen dabei im großen Stil auf imposante Grafik, die den Eindruck vermitteln soll, man sei wirklich dabei. Wie bei Kinofilmen von heute 2 täuschen diese optischen (und auch akustischen) Eindrücke 3 o über teilweise schwachbrüstige Geschichten und Inhalte hinweg. [Kos 05, S.176] Aktuelle Spiele wie Heavy Rain 4 (2010) oder auch etwas betagtere Titel wie Fahrenheit 5 (2005) beweisen, dass die Story für Spiele, die nachhaltig wirken wollen, wichtig ist. Dabei liegt das Erzählen von Geschichten dem Menschen so nahe. Seit mehreren Jahrhunderten dient es als Mittel der Unterhaltung. [She 04, S.3] Eine ganz besondere Stellung nehmen dabei TextAdventures ein. Durch Text präsentiert wie ein Buch und interaktiv wie ein Spiel, spricht man auch von einem gespielten Buch. In den 1970er und 1980er Jahren noch populär, erleben sie heutzutage eine Wiederauferstehung durch das Internet 6 – zum Herunterladen auf den Desktop oder als Online-Browser-Spiel. Letzteres soll vor allem in dieser esis von Belang sein. Auch wenn insgesamt das Angebot an (browser-basierten 7 ) Text-Adventures 8 vergleichbar klein ist, sind sie nach wie vor gefragt 9 und beliebt. Das zeigt die weltweite Entwicklung von Interactive Fiction (IF) vor allem in den USA, sowie entsprechende Wettbewerbe 10 . Darüber hinaus lassen individuelle Initiativen beispielsweise von Martin Kool 11 das Herz eines jeden Nostalgikers höher schlagen.

1 2 3

Nintendo sei hier ausgeschlossen Der Trend zum 3D-Kino

»Im Rausch der Töne und der Bilder sind diese Spiele allerdings mittlerweile untergegangen.« – http:// www.textfire.de/index.htm 04.10.2010
4 5 6 7 8 9

http://www.spiegel.de/netzwelt/games/0,1518,680010,00.html, 13.09.2010 http://www.spiegel.de/netzwelt/web/0,1518,374336,00.html, 13.09.2010 http://www.ehow.com/list_5801287_games-using-keyboard.html, 13.09.2010 http://www.google.com/Top/Games/Video_Games/Adventure/Browser_Based/, 13.09.2010 http://www.google.com/Top/Games/Video_Games/Adventure/Text_Adventures/, 13.09.2010 http://www.gamersglobal.de/meinung/neue-textadventures-bitte, 13.09.2010 Der »XYZZY-Award« und die »Interactive Fiction Competition« http://sarien.net, 13.09.2010 15

10 11

1 Einführung

Im Rahmen dieser Arbeit soll mit modernen Web-Technologien ein Prototyp für ein eigenes TextAdventure erstellt werden. Da es in diesem Genre üblich ist, liegt der Schwerpunkt auf der erzählten Geschichte.

1.2 Motivation
Die dem Verfasser zu Grunde liegende Motivation rührt vor allem aus dem Interesse an textbasierter Arbeit 12 und den mit der Zielsetzung verbundenen Herausforderungen.

1.2.1 Herausforderungen
Die sich aus der Erstellung des Spiels ergebenen Herausforderungen sind technologischer, anatomischer, inhaltlicher und moralischer Natur. Das Spiel ist technologisch herausfordernd, weil der zu verwendende HTML-Standard HTML5 noch immer recht neu ist und die finalen Spezifikationen des World Wide Web Consortium (W3C) bzw. der Web Hypertext Application Technology Working Group (WHATWG) noch nicht fertig sind. Die Frage ist also: Was ist mit aktuellen Browsern und HTML5 jetzt schon möglich 13 , wenn der HTML-Standard erst 2022 [Krö 10, S.29] bzw. 2012 [Kei 10, S. 7] fertig und abgeschlossen sein soll? Neben HTML5 werden CSS3 und jQuery für das Aussehen und Verhalten des Spiels verwendet. Es ist eine anatomische Herausforderung, weil der Autor noch nie selbst ein Spiel erstellt oder daran mitgewirkt hat. Das Schaffen eines Spiel-Erlebnisses – wenn auch prototypisch-experimentell – ist absolutes Neuland, deswegen auch umso spannender. Inhaltlich ist es herausfordernd, weil ein Drehbuch für das Spiel zum ersten Mal verfasst wird. Auch das selbst gewählte ema dieser Arbeit ist inhaltlich interessant, wurden die Grundlagen doch in bestimmten Kursen des Studiums gelegt: »Medien- und Wahrnehmungstheorie«, »Grundlagen interaktiver Medien«, der Kurs »Usability« und »Mensch-Computer-Interaktion«. Im Wesentlichen bilden diese Kurse die theoretische Grundlage zur Wahl dieses emas und den Enthusiasmus zur Verfassung dieser Arbeit. Auch moralisch gesehen ist das Spiel eine Herausforderung, weil zugängliche Webseiten – im Sinne der Accessibility – nicht zwangsläufig auch gebrauchstauglich sind – im Sinne der Usability. [Hor 05,

12 13

Web Development und Copywriting http://html5gallery.com/ – http://www.chromeexperiments.com/ 05.10.2010 16

1 Einführung

Preface] Ebenso generieren gebrauchstaugliche Webseiten nicht automatisch eine gute Nutzererfahrung – im Sinne der User Experience (UX). Es gilt im Rahmen dieser Arbeit, o.g. Herausforderungen konzeptionelle Lösungsansätze entgegenzubringen.

1.3 Ziel
Ziel dieser Arbeit ist, ein Proof of Concept 14 für ein rein tastaturgesteuertes Text-Adventure (IF) im Stil der 1970er und 1980er Jahre zu erstellen, das technisch auf HTML5, CSS3 und JavaScript basiert, besonderen Wert auf Usability und Accessibility legt und nur online im Browser gespielt wird. Dieses beinhaltet auch die Entwicklung eines ersten explorativen Prototypen. [Ber 09, S. 541 und Flo 84, S.6] Ziel ist es nicht, den in dieser esis gestellten Anforderungen im Prototypen gerecht zu werden. Sie stellen Idealvorstellungen dar, die für eine marktreife Web-Anwendung verbindlich sein sollten. Ziel ist es hingegen, Ansätze der dargelegten Anforderungen zu erfüllen und annäherungsweise umzusetzen.

1.4 Grenzen des Prototypen
Im Rahmen dieser esis wird kein Anspruch auf Vollständigkeit erhoben. Bei der beschriebenen Umsetzung handelt es sich um Teil-Implementierungen. Die esis behandelt die UX von rein tastaturgesteuerten Text-Adventures in Browsern. Dabei wird anhand der aus der Literatur gewonnenen Erkenntnisse ein User Interface (UI) unter Berücksichtigung von Gesichtspunkten der UX und Universal Usability prototypisch implementiert. Mit Browser-Spielen sind im Rahmen dieser Arbeit explizit für den Browser konzipierte Spiele gemeint – also keine Portierungen oder Einbettungen in den Browser.

1.5 Kompetenzverteilung
Das Spiel entstand in Zusammenarbeit mit Tommy Krüger. Dessen esis bezieht sich auf die Konzeption und Untersuchung von Text-Adventures. Der Autor dieser esis sieht die UX als einen integralen Bestandteil bei der Spielkonzeption.

14

engl. Machbarkeitsstudie 17

1 Einführung

Tommy Krüger kümmerte sich im Wesentlichen um die technische Implementierung – die Funktionalität. Der Autor dieser Arbeit war im Wesentlichen für das User-Centered Design (UCD) zuständig – also das Erlebnis des Spiels Ambernstein 15 zu erschaffen. In der folgenden Tabelle 1 sind die einzelnen Kompetenzen aufgelistet:

Tommy Krüger Ideenfindung und Spielentwurf

Alexander Kluge

Entwicklung der Grundstory und Mini-Spiele Designdokument Technisches Designdokument Implementierung des Spiels als Prototyp Implementierung der Mini-Spiele als Prototypen UI und UX Design Universal Usability Visual Identity und Style Guide Game Proposal und Game Concept Story (Drehbuch, Figuren, Dramatik, Soundtrack) Tab. 1, Kompetenzverteilung

Das Game Proposal und Game Concept dienten als Vorarbeit für das Designdokument. Bei der Visual Identity kam es darauf an, Ambernstein als Marke darzustellen.

1.6 Anhang
Im Anhang dieser Arbeit befinden sich ergänzende Dokumente, die für eine Implementierung des Spiels herangezogen werden können. Zusätzlich ist dieser Arbeit eine CD »Ambernstein« mit allen Quelldateien, Implementierungen, Grafiken und Dokumenten beigefügt.

1.7 Herangehensweise
Die esis ist in acht Inhaltsbereiche aufgeteilt: • Einführung • Was ist User Experience? • Ideenfindung • Analyse • Konzept

15

http://ambernstein.com 05.10.2010 18

1 Einführung

• Umsetzung • Test • Konklusion Der Schwerpunkt liegt auf den vier Teilen Analyse, Konzept, Umsetzung und Test: In der Analyse werden die aktuellen Text-Adventures untersucht und die Fähigkeiten von nativen Browser-Technologien abgewägt. Im zweiten Teil wird auf theoretischer Basis ein explorativer Prototyp auf Grundlage der in der Analyse gewonnenen Erkenntnissee entworfen. Im dritten Teil werden die praktischen Ergebnisse aus der Implementierung des zuvor theoretisch beschriebenen Prototypen erläutert. Außerdem wird gezeigt, als wie praxistauglich er sich erweist. Die Tests des vierten Teils erfolgten – wenn möglich – unter Einbeziehung von Testpersonen der entsprechenden Zielgruppe. Außerdem wurden forschungs- und studienbasierte Ergebnisse aus einschlägiger Literatur zu Rate gezogen. Alle vier Teile wurden iterativ vollzogen, d.h. während der Entwicklung änderten sich teilweise die Anforderungen, recht o die Entwürfe und auch der Prototyp selbst. Das begleitende Projekt Ambernstein wurde in Zusammenarbeit mit Tommy Krüger durchgeführt. Auf Grund unterschiedlicher Schwerpunkte in der praktischen und theoretischen Arbeit ergaben sich bei den Projektpartnern teilweise verschiedene Konzeptions- und Entwicklungszyklen. Hinweis: Da diese esis nur einen Teil des begleitenden Projekts widerspiegelt, bittet der Autor den geneigten Leser, ergänzende und vertiefende Inhalte der Abschlussarbeit »Konzeption und Untersuchung von text-gesteuerten Adventuregames« von Tommy Krüger zu entnehmen.

19

2
Was ist User Experience?
Komplexität von UX.

20

2 Was ist User Experience?

2.1 Erstes Verständnis
Vorweg sei gesagt, dass sich alle in dieser Arbeit genannten Begrifflichkeiten auf den Kontext des Web beziehen. Dem Autor ist bewusst, dass sich die UX als interdisziplinäres Feld auszeichnet, indem neben Informatik, auch Aspekte der Psychologie, des Designs, der Kultur, des Marketing und der Usability u.v.m. wichtig sind. Grundlage jeglichen Verständnisses für UX ist die Fokussierung auf den Nutzer mit dem Ansatz des UCD. [Usa o.J.] Ersten Aufschluss über eine Begriffsdefinition von UX liefert die internationale Norm ISO 9241, die in Europa als EN ISO 9241 und in Deutschland als DIN EN ISO 9241 übernommen wurde und die »Ergonomie der Mensch-System-Interaktion« behandelt. In deren Abschnitt 210 16 ist sie thematisiert. omas Geis [Gei 10] hat sich in Abbildung 1 der ISOSicht angenommen und verdeutlicht den Bezug zur Usability.

Abb. 1, Die genormte Sicht auf Usability und User Experience

Usability ist demnach eine Teilmenge von UX und bedarf einer weiteren Klärung. In den folgenden Abschnitten sollen außerdem die Bestandteile von UCD und Universal Usability beleuchtet werden. Ferner soll auf die Komplexität von UX eingegangen werden.

16

ISO 9241-210: »Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme« 21

2 Was ist User Experience?

2.2 User-Centered Design
UCD wird teilweise als Synonym zu Usability und UX genannt [Hor 05, Preface], bedeutet aber letztendlich, dass der Nutzer früh und o in den Entwicklungsprozess eingebunden wird. [Hor 05, Introduction] Laut Patrick Lynch [Lyn 09, 2.2] beinhaltet UCD folgende nutzerorientierte Methoden: • Aufgaben-Analyse • Fokus-Gruppen • Nutzertests Vor allem die Nutzertests dienen dazu, den Nutzer zu verstehen und die Entwürfe je nach Feedback des Nutzers weiterzuentwickeln. Außerdem soll mit Hilfe von UCD die vom Nutzer gewünschte Funktionalität bestimmt werden und die Art, wie er sie nutzen wird. Laut Lynch [Lyn 09, 2.2] und Garrett [Gar 03, S.38] wird iterativ entworfen, getestet und weiterentwickelt. Ganz anders kann UCD auch als ein Ansatz des Interaction Design gesehen werden, der neben dem Activity-centered, Systems und Genius Design existiert. [Saf 07, S.30ff.]

2.3 Universal Usability
2.3.1 Klassische Usability
Eindeutige Definitionen für Usability sind nur schwer zu finden. Begriffe wie Bedienbarkeit, Benutzbarkeit und Benutzerfreundlichkeit versuchen, dem Konstrukt Usability gerecht zu werden. [Eic 99] Als hilfreich erweist sich erneut die ISO-Norm 9241. Deren eler Teil kümmert sich um die »Anforderungen an die Gebrauchstauglichkeit«, welcher im englischen Original als »Guidance on usability« bezeichnet ist. Usability meint also die Gebrauchstauglichkeit. Gemäß ISO-Norm definiert sie sich als das »Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und mit Zufriedenheit zu erreichen.« Nach Steve Krug ist gute Usability dann gegeben, wenn man den Nutzer nicht denken lassen muss. [Kru 06, S.10ff.] Er spielt dabei auf die selbst erklärende Funktionsweise einer Webseite an. [Lyn 09, 10.3] Jakob Nielsen sieht in Usability ein Qualitätsmerkmal [Nie 03], das aus fünf Komponenten besteht: Learnability, Efficiency, Memorability, Errors und Satisfaction.
22

2 Was ist User Experience?

Learnability meint, wie einfach es dem Nutzer gelingt, einfache Aufgaben in einem bislang unbekannten System zu lösen. Efficiency heißt, wie schnell der Nutzer Aufgaben in einem ihm bereits bekannten System durchführt. Memorability bedeutet, wie einfach es dem Nutzer fällt nach einer Zeit der Nichtnutzung, die zuvor gewonnenen Fertigkeiten wieder abzurufen. Errors sagt aus, wie viele Fehler der Nutzer machen, wie schwerwiegend diese sind und wie einfach sie wieder rückgängig gemacht werden können. Satisfaction gibt wieder, wie gerne der Nutzer das System benutzt. Lynch [Lyn 09, 2.2] sieht die Usability wie Nielsen die Usability als qualitativ. Für ihn ist es aber auch ein Phänomen, das gemessen und in Zahlen ausgedrückt werden kann (quantitativ). Um eine gute Usability zu erreichen, erweist sich besagtes UCD als die gängigste Methode.

2.3.2 Accessibility
Gemäß W3C geht es bei Accessibility (Zugänglichkeit) darum, Menschen mit Einschränkungen im Hören, Bewegen, Sehen und der Kognition 17 die Möglichkeit zu geben, das Web wahrzunehmen, zu verstehen, sowie darin navigieren und interagieren zu können. [Hen 05] Das Ideal ist dabei, das Web für jeden Menschen – unabhängig von Hardware, Soware, Sprache, Kultur, Ort, körperlicher und geistiger Fähigkeit – zugänglich zu machen. [Hen oJ] Seitens der W3C gibt es eine spezielle Initiative zur Klärung von Gesichtspunkten der Accessibility – die Web Accessibility Initiative 18 (WAI). Sie sind Sie hauptverantwortlich für die Web Content Accessibility Guidelines (WCAG), die bereits als WCAG 2.0 in der zweiten Version veröffentlicht wurden. Interessant im Rahmen dieser Arbeit ist auch die Accessible Rich Internet Application Suite 19 (WAI-ARIA), die sich um interaktive Web-Applikationen mit dynamischen Inhalten kümmert. Laut Horton [Hor 05] ist man bei der Accessibility primär damit beschäigt, Inhalt und Funktionalität zugänglich zu machen. Patrick Lynch [Lyn 09, 2.2] definiert sie als kritisches Element der Universal Usability, die nachfolgend definiert wird.

2.3.3 Universal Usability
Universal Usability basiert genau wie »klassische« Usability auf dem weiten und einschließenden Blick gen Nutzer [Lyn 09, 2.2], schließt aber Aspekte der Accessibility mit ein.

17 18 19

Im weitesten Sinne die Aufnahme, Verarbeitung und Speicherung von Informationen aus der Umwelt http://www.w3.org/WAI/ 05.10.2010 http://www.w3.org/WAI/intro/aria 05.10.2010 23

2 Was ist User Experience?

Das heißt: Inhalte und Funktionen werden gebrauchstauglich – im Sinne der o.g. Definition – und zugänglich gemacht. Ben Shneiderman prägte den Begriff in Leonardo‘s Laptop (2002) als Mittel, um alle Bürger zu befähigen, mit Kommunikations- und Informationstechnologie erfolgreich ihre Aufgaben bewältigen zu können. Dabei sieht er Bürger als Nutzer mit neuen oder alten Computern, langsamen oder schnellen Netzwerkverbindungen, kleinen oder großen Bildschirmen. Diese sind jung und alt, Anfänger und Experten, eingeschränkt und uneingeschränkt. Es geht um diejenigen, welche sich nach Bildung sehnen, eigene Unsicherheiten überwinden wollen und mit verschiedenen Beschränkungen zurecht kommen müssen. [Shn 03b, S. 14f.] Universal Usability... ...unterstützt eine breite Palette von Technologien. ...gefällt vielen verschiedenen Nutzern. ...baut eine Brücke zwischen dem was Nutzer wissen und was sie wissen müssen. Nichtsdestotrotz ist Universal Usability laut Shneiderman eher einen Traum als eine wirklich umsetzbare Strategie. [Shn 03b, S. 15] Horton schlussfolgert aus den drei Herausforderungen, dass man drei Bereiche des Webdesigns besonders beachten muss: Funktion, Interface, Inhalt. [Hor 05, Preface] Der Vollständigkeit halber soll in diesem Zusammenhang auch der Begriff des Universal Design im Folgenden erläutert werden.

2.3.4 Universal Design
»Universal Design« wurde vom US-amerikanischen Center for Universal Design and der North Carolina State University’s College of Design entwickelt. Es besteht aus Prinzipien und Richtlinien, von denen die folgenden Vier für die Web-Umgebung am besten anwendbar sind: 1. Equitable Use 2. Flexibility in Use 3. Simple and Intuitive Use 4. Perceptible Information »Equitable Use« meint, dass das Design jedem Nutzer die gleichen Mittel zur Verfügung stellen sollte. Mit »Flexibility« ist gemeint, dass die Auswahl an Möglichkeiten, das Design zu nutzen,
24

2 Was ist User Experience?

vielfältig sein sollte. Das dritte Prinzip spricht die einfach und intuitive Nutzung des Design an, indem unnötige Elemente ausgeblendet werden. »Perceptible Information« umfasst Information, die unterschiedliche wahrnehmbar ist. [LYN 09, 2.3] Die beiden letzten Prinzipien sind mit Norman‘s Begriff der Affordances vergleichbar, der im späteren Verlauf dieser Arbeit definiert wird.

2.4 User Experience
Zuvor eher nach der ISO-Norm betrachtet, soll nun fernab der ISO-Sicht mit dem Wissen um die grundsätzlichen Begriffe der UX die folgende Informationsgrafik 20 (Abbildung 2) zeigen, wie umfangreich das Forschungs- und Arbeitsgebiet der UX bzw. end-user experience [KOS 05, S.160] wirklich ist.

Abb. 2, Die Disziplinen der UX

20

http://www.kickerstudio.com/blog/2008/12/the-disciplines-of-user-experience/ 04.10.2010 25

2 Was ist User Experience?

Im Rahmen dieser esis wird im späteren Verlauf auf einzelne UX-Disziplinen von Abbildung 2 genauer eingegangen.

Abb. 3, Die UX-Honigwabe

Abb. 4, UX-Modell

Um die UX auch qualitativ zu erfassen, eignet sich das Modell von Peter Morville [Mor 04] und Peter Dobr 21 – siehe Abbildung 3 und 4. Letztere sind vor allem auch dafür geeignet, um die Verbindung von UX und Usability zu verstehen. Hier herrscht teilweise noch Unklarheit. 22 Eine positive UX ist laut Wabenmodell dann generiert, wenn das benutzte System einen besonderen Wert für den Benutzer hat - es also valuable ist. Dies ist laut Morville dann gegeben, wenn es zielgruppenrelevant (useful), gebrauchstauglich (usable), gut auffindbar (z.B. IA), glaubha (z.B. Social Design, Stanford Guidelines for Web Credibility 23 ), zugänglich (Accessibility) sowie begehrenswert (z.B. Marke, Image, Identität) ist. Eine vereinfachte Version von Abbildung 3 ist im Konzeptteil dieser esis als Abbildung 26 zu finden. Sie bezieht sich auch auf die Informationsarchitektur (IA). Stephen P. Anderson [AND 09] beschreibt das (User) Experience Design, indem er sagt, dass sich Alles um Menschen, ihre Aktivitäten und den Kontext ihrer Aktivitäten dreht – siehe Abbildung 5.

21 22

http://upload.wikimedia.org/wikipedia/de/9/90/User-experience.svg 30.09.2010

http://blog.procontext.com/2010/03/usability-und-user-experience-unterscheiden.html – http:// www.uxbooth.com/resources/mark-boulton-on-defining-ux/ – http://www.usabilitynews.com/news/ article4636.asp – http://www.cs.tut.fi/ihte/CHI08_workshop/papers/Bevan_UXEM_CHI08_06April08.pdf 04.10.2010
23

http://credibility.stanford.edu/guidelines/index.html 04.10.2010 26

2 Was ist User Experience?

Abb. 5, Die wesentlichen Elemente des Experience Design (Auszug)

Fasst man UX allgemein zusammen, ist es das Nutzungserlebnis, das auch Freude und Spaß bereiten soll. Man geht dabei weg vom rein funktionalen (aufgaben-orientierten) Denken zum Erfahrungserlebnis. Die folgende Informationsgrafik (Abbildung 6) von Anderson zeigt dies sehr deutlich:

Abb. 6, Die UX-Hierarchie der Nutzerbedürfnisse (Auszug)

24

24

http://www.poetpainter.com/thoughts/article/a-user-experience-hierarchy-of-needs 04.10.2010 27

2 Was ist User Experience?

Das Verarbeiten dieser Erfahrung geschieht nach Norman [Nor 04, S.64ff.] im Menschen dabei auf drei emotionalen Ebenen (Abbildung 7 [Inc 10a]): Visceral, Behavorial, Reflective.

Abb. 7, Verarbeitung der UX durchs Gehirn

Visceral meint das was vor der bewussten Wahrnehmung stattfindet. Es geht um ersten Eindruck, die erste Erscheinung, sowie das erste Look and Feel des Produkts. Behavioral umfasst die Nutzung und das Erlebnis mit dem Produkt, wobei Letzteres die Funktion, Performance und Usability beinhaltet. Reflective steht dafür, dass die Auswirkungen von Gedanken und Gefühlen nun bewusst interpretiert werden. Die Verarbeitung auf diesem Level passiert vor allem auch nach dem eigentlichen Benutzen – es ist nicht an die jetzige Benutzung gekoppelt. Vielmehr entwickelt es sich durch die Erinnerung an die Vergangenheit und die Betrachtung der Zukun. [Nor 04, S.36ff.] Die Folgen positiver und negativer Ausführung von UX wird in dem Poster (Abbildung 8) von Experience Dynamics [Spi 06] gut dargestellt. Positive UX in Spielen ist eng verbunden mit Spaß, der laut Koster [KOS 05, S.46], nur ein anderes Wort für Lernen ist. Inwiefern das die esis begleitende Spiel Spaß und Lernen kombiniert, soll in der nachfolgenden Definition von »Adventure« gezeigt werden.

28

2 Was ist User Experience?

Abb. 8, Die Wichtigkeit von UX

2.5 Adventure
Da es auch beim Begriff des Adventures viele Varianten gibt, soll an dieser Stelle relative Klarheit darüber gebracht werden. Definition #1 Eine erste Definition eines Adventures sieht es als interaktive Geschichte über eine Figur, die von einem Spieler kontrolliert wird. [Rol 06, S.546] Die Figur besucht ein erforschbares Gebiet, das eine

29

2 Was ist User Experience?

Vielzahl von Puzzles und zu lösenden Problemen beinhaltet. [Rol 06, S.549] Eher selten sieht sich die Figur mit physischen Herausforderungen konfrontiert. [Rol 06, S.71] Definition #2 Der zweite Versuch sieht ein Adventure als deterministisches 25 und intellektuelles Problemlösen im Rahmen einer Geschichte. [Tan 08] Zusammenfassung Gemeinsam haben beide Definitionen, dass es im Kontext einer Story gilt, Probleme (Puzzles) zu lösen. Implizit haben beide Wortlaute auch gemeinsam, dass auf die körperliche Auseinandersetzung des Protagonisten verzichtet wird.

2.5.1 Text-Adventure
Ein Text-Adventure beinhaltet alle Elemente eines Adventures, nur keine grafische Ausgabe. Text ist das UI 26 . Neben einem Text-Parser, der die Tastatureingaben versteht und auswertet, muss der Spieler teilweise kreative Text-Befehle eingeben. Dies führt bei Misserfolg auch zu Frustration und ist ein möglicher Grund, warum Text-Adventures in Relation zu anderen Genres heutzutage nicht mehr so beliebt sind. [Sch 08, S.144]

2.5.2 Interactive Fiction
Interactive Fiction (IF) ist der genauere und sehr gängige Begriff für ein Text-Adventure. Er wurde von der Firma Infocom in‘s Leben gerufen. Sie verkauen die kommerziell erfolgreichsten TextAdventures. [Sco 10]

25 26

Im Gegensatz zu stochastisch (zufällig) ist etwas Vorbestimmtes gemeint http://www.useit.com/alertbox/twitter-iterations.html 04.10.2010 30

3
Ideenfindung
Wie es zu Ambernstein kam.

31

3 Ideenfindung

3.1 Herangehensweise
In freitäglichen Treffen wurden verschiedene Ansätze per Brainstorming skizziert und im Kopf durchgespielt. Zunächst wurde mit einer textbasierten Twitter-Applikation geliebäugelt, in der es um Eingaben per Tastatur gehen sollte. Andererseits sollte auch das spielerische Element eine Rolle spielen, um eine gewisse Interaktion zu gewährleisten. Der erste – recht komplexe – Ansatz war der, vom System eingegrenzte Eingaben von angemeldeten Nutzern in eine Warteschlange aufzunehmen und sie hintereinander zu verarbeiten. Diese Eingaben bezogen sich auf eine Spielfigur, die dementsprechend agieren sollte. Die Idee wurde recht bald verworfen, weil das Ergebnis zu willkürlich und unstrukturiert gewesen wäre. Es stellte sich heraus, dass Struktur und Vorgaben (Constraints) die wichtigsten Kriterien sein sollten. Ein Spiel ohne Regeln bedeutet Chaos. Der Weg zur finalen Idee war geebnet.

3.2 Ideenverschmelzung
Es wurde sich ein Spiel überlegt, das auf der komplexen Story eines Text-Adventures basiert, in Teilen aber auch grafisch repräsentiert wird. Gehalten von einem linearen Drehbuch, das auch schon in eateraufführungen 27 von LucasArts‘ e Secret of Monkey Island verwendet wurde, und einer dramatischen Geschichte sollte das Abenteuer »Ambernstein« heißen und im Stil eines TextAdventures (story-orientiert) entworfen werden.

27

http://www.worldofmi.com/features/miplay/ 04.10.2010 32

4
Analyse
Vorstudien, Projektplan, Marktsituation.

33

4 Analyse

4.1 Herangehensweise
Dieser Abschnitt befasst sich mit Vorstudien, dem Projektplan und der vorbereitenden Analyse. Vor allem Letzteres legt den theoretischen Grundstein für das darauf folgende Konzept und die Umsetzung. Ziel dieses Abschnitts ist, die Anforderungen zu definieren und mögliche Grenzen für ein Text-Adventure zu finden, das auf nativen Browser-Technologien basiert. Darüber hinaus soll das allgemeine Projektmanagement und die kollaborative Arbeitsweise mit modernen Webapplikationen nicht unerwähnt bleiben. Für den mit der Analyse beginnenden Entwicklungsprozess orientierte man sich in Teilen auch an dem Poster »designing the user experience« der UPA 28 (Abbildung 9).

Abb. 9, Entwicklungsprozess für UX (UPA)

28

http://www.upassoc.org/upa_publications/ux_poster.html 05.10.2010 34

4 Analyse

Außerdem dienlich für den Entwicklungsprozess war die Schritt-für-Schritt-Anleitung 29 des USGesundheitsministeriums (HHS) – in Abbildung 10 zu sehen.

Abb. 10, Usability als Schritt-für-Schritt-Anleitung

Darüber hinaus zeigte sich das Modell der UX-Elemente von Jesse James Garrett [Gar 00] als sehr hilfreich für die Entwicklung der UX. Es ist komplexer als das IA-Modell von Morville (Abbildung 26), das explizit auf Garrett Bezug nimmt. Garrett baut sich die UX aus fünf Ebenen zusammen: 1. Oberfläche 2. »Skelett« 3. Struktur 4. Scope (Anwendungsbereich) 5. Strategie In Abbildung 11 sind sie nochmals grafisch dargestellt. Auch wenn Garrett [Gar 03, S.1] das Modell nicht als Vorgehensweise bei der Entwicklung sieht, kann man sich an ihm gut grob orientieren.

29

http://usability.gov/methods/process.html 31.08.2010 35

4 Analyse

Abb. 11, Elemente der UX (Auszug)

Besagte Ebenen reichen von abstrakt zu konkret: • Visuelles Design (das »Look« in Look and Feel 30 ) • Schnittstellen-, Navigations-, und Informationsdesign • Interaktionsdesign und Informationsarchitektur (IA) • Inhalte und Funktionen • Benutzer-Bedürfnisse und Unternehmensziele Die mittleren drei Ebenen führen zudem eine Unterscheidung vom Verständnis des Web durch: [Gar 03, S.31] • Das Web als Soware-Schnittstelle • Das Web als Hypertext-System Garret sagt zwar selbst, dass es sich bei seinen Ebenen nur um ein Modell handelt, denn um einen methodischen Vorgang. [Gar 00] Dennoch zeigen sich in seinem holistischen Modell die wesentlichen Bestandteile des Vorgangs beim Auau einer Web-Anwendung. Dies ist auch der Grund warum sich im Rahmen dieser esis auf dieses Modell bezogen wurde.
»Design is not just what it looks like and feels like. Design is how it works.« Steve Jobs – http:// query.nytimes.com/gst/fullpage.html?res=9C02E7D8113BF933A05752C1A9659C8B63 05.10.2010
30

36

4 Analyse

4.2 Projektmanagement
Das Projektmanagement wurde über eine Mischung aus Präsenztreffen und Tools des Web 2.0 gelöst.

4.2.1 Tools
Google Docs & Spreadsheet Ideensammlung, Dokumentation und Zeitplan Aufgaben-Management im Stil eines Personal Kanban 31 Dropbox Datei-Management, Dokumentation und Kommunikation Diigo Web-Bookmarks in einer Liste kollaborativ sammeln Google Reader Ergänzend als Filter für die Bookmarks bei Diigo Remember e Milk Aufgaben-Management Evernote Notizen Etherpad teilweise für die öffentliche Darstellung des Fortschritts der Arbeit E-Mail / Skype / Persönliche Treffen essentiell für schnellen und direkten Austausch

4.2.2 Zeit und Ressourcen
Die ersten acht Wochen Die letzten sechs Wochen

••••••••••••••
• • • • • • Ideenfindung, erste Spielentwürfe Entwicklung der Grundstory, Drehbuch schreiben Entwicklung der Mini-Games Game und Web Design analysieren und konzipieren Literatur sichten Thesis strukturieren Abb. 12, Zeitplan

••••••••••••••
• Prototyp implementieren und testen • Literatur bearbeiten • Thesis schreiben und gegenlesen lassen

31

http://imgriff.com/2010/02/12/personal-kanban-to-dos-auf-japanisch/ 05.10.2010 37

4 Analyse

Etwa in der ersten Häle der Bearbeitungszeit trafen wir uns einmal pro Woche (jeden Freitag), um unsere Arbeit zu synchronisieren. In der restlichen Zeit gingen wir dazu über, jeden zweiten Tag mal kurz und mal intensiver Kontakt zu haben. Die Treffen geschahen per einstündigen Skype-Sitzungen oder mehrstündigen Face-to-Face-Treffen. Dies half uns, gegenseitig Druck, positiven Stress und Motivation aufzubauen. Natürlich gingen die einzelnen Bestandteile ineinander über, sodass wir z.B. auch in den ersten Wochen schon an unserer esis schrieben bzw. Literatur bearbeiteten. Das in Abbildung 12 erwähnte Drehbuch liegt im Anhang als erste Rohversion vor. Zur endgültigen Verwendung müsste es mindestens noch einmal überarbeitet werden.

4.2.3 Iterativer Entwicklungszyklus

Abb. 13, Iterative Entwicklungssequenz

Der während der Arbeit verwendete Zyklus ist angelehnt an zuvor genannte Vorgehensweisen. Außerdem orientierte man sich an den in Abbildung 13 [Lyn 09, 2.6] dargestellten Entwicklungsprozess, sowie an dem Vorgehen von Stocks [Sto 09] und Garret [Gar 03].

4.2.4 Alternative Entwicklungsprozesse
Apple bietet in seinem iOs Dev Center 32 einen Ansatz [Hop 09], der etwas holistischer an die Entwicklung geht und in vier Abschnitte unterteilt ist: 1. Familiarize 2. Conceptualize 3. Realize 4. Finalize

32

http://developer.apple.com/ 05.10.2010 38

4 Analyse

Ähnlich einfach beschreibt es Unger [Ung 09, S.62ff] beschrieben, bei dem es zur Vorgehensweise im Kern einfach heißt: 1. Define 2. Design 3. Develop 4. Deploy Alle Schritte erfolgen dabei in Iterationen.

4.3 Marktsituation
Im Folgenden soll in einer kurzen Analyse festgestellt werden, welche Spiele für den Markteintritt von Ambernstein interessant sein könnten, welche Merkmale sie besitzen und inwiefern sie sich von Ambernstein unterscheiden.

4.3.1 Spiele-Auswahl
Kriterien
Um nachvollziehen zu können, welche Spiele für die Marktanalyse verwendet wurden, sollen MussKriterien für die Auswahl genannt werden: • online im Browser spielbar • mit Tastatur steuerbar Außerdem wurden flexible Kann-Kriterien aufgestellt. Diese lauten: • gewisse Textlastigkeit • Steinzeit thematisiert • geringe Grafiknutzung

Die Auswahl
Letztendlich wurde sich für folgende Titel entschieden: • Adventure / Colossal Cave (1976) • Zork 1 (1980) • Slouching Towards Bedlam (2003) • Blue Lacuna (2009) • Stone Age Sam (2008)
39

4 Analyse

• Typer Shark (2009) Teilweise musste von den Muss-Kriterien (z.B. »online im Browser spielbar«) abgewichen werden, um die Güte des Spiels bzw. das Spiel überhaupt beurteilen zu können. Adventure »Adventure« wurde 1975 programmiert und im Folgejahr veröffentlicht. 33 Es gilt als das erste und wegweisende Adventure, das dem Genre seinen Namen gab. Wegen der starken Orientierung an einem Höhlengang bezeichnete man es auch als interaktive Karte. Es wurde in einer speziell für Mac OSX bereitgestellten Version 34 angespielt. Zork 1 »Zork 1« gilt als das kommerziell erfolgreichste Text-Adventure der Firma Infocom. [Sco 10] Es wurde unter Mac OSX in der DOSBox 35 als MS-DOS-Version 36 angespielt. Slouching Towards Bedlam »Slouching Towards Bedlam« wurde wegen seiner vielen Auszeichnungen und dem Gewinn 37 der Interactive Fiction Competition im Jahr seines Erscheinens gewählt. Es wurde in Inform 6 geschrieben. Angespielt wurde es im Z5-Format 38 unter Spatterlight 39 für Mac OSX.. Blue Lacuna »Blue Lacuna« ist deswegen gewählt worden, weil es ebenfalls vielfach ausgezeichnet wurde und 2009 den Gewinn der Interactive Fiction Competition für sich verbuchen kann. Es wurde in Inform 7 geschrieben. Das Spiel wurde in einer Auszugs-Version 40 im Browser angespielt. Stone Age Sam »Stone Age Sam« wurden vor allem wegen des Steinzeit-emas gewählt. Es ist ein in Adobe Flash realisiert. Es wurde trotz reiner Steuerung per Maus im Browser 41 angespielt.

33 34 35 36 37 38 39 40 41

http://akira.ruc.dk/~new/tekster/Adventure.pdf 06.10.2010 http://www.lobotomo.com/products/Adventure/index.html 05.10.2010 http://www.dosbox.com/ 05.10.2010 http://www.infocom-if.org/downloads/downloads.html 05.10.2010 http://ifcomp.org/comp03/results.html 05.10.2010 http://www.peccable.com/if/slouching/ 05.10.2010 http://ccxvii.net/spatterlight/ 05.10.2010 http://www.lacunastory.com/excerpt/ 05.10.2010 http://www.2dplay.com/stoneage-sam/stoneage-sam-play.htm 05.10.2010 40

4 Analyse

Typer Shark »Typer Shark« wurde wegen des intensiven Tippens per Tastatur gewählt. Der Kern des Spiels basiert also auf reiner Tastatursteuerung. Das Spiel ist ebenfalls in Flash realisiert und im Browser gespielt worden.42

Features
Zunächst sollen Colossal Cave und Zork 1 verglichen werden, weil sie am ehesten zusammenpassen was Umfang und Komplexität angeht. Später werden Slouching Towards Bedlam und Blue Lacuna mit gleicher Begründung verglichen. Zork 1 Die Daten für Zork 1 43 aus Tabelle 2 stammen von Jascon Scott [Sco 10], der inoffiziellen Webseite
44

zu Infocom, dem Department of Computer Science der University of Western Ontario, US und dem

Artikel 45 von Matt Barton bei Gamasutra.

Colossal Cave (1975) Erstes Text-Adventure Programmiersprache: FORTRAN Crowther: 79 Orte, 193 Worte Woods: 140 Orte, 293 Worte, 53 Objekte Nur ersten vier Buchstaben werden berücksichtigt

Zork 1 (1980) Kommerziell erfolgreichstes Text-Adventure Programmiersprache: MDL 110 Räume, 600 Worte, 60 Objekte

komplexe Befehle wie »KILL TROLL WITH SWORD« Inventar

Punktesystem beinhaltet einen Antagonisten (Dieb) Tab. 2, Colossal Cave und Zork 1 im Vergleich

Colossal Cave Für die Daten von Colossal Cave 46 musste sich wegen Mangel an Alternativen und um überhaupt einen Vergleich mit Zork 1 anstellen zu können, auf Wikipedia berufen werden. Generelle Informationen fand man zusätzlich auf der Webseite von Rick Adams. 47
42 43 44 45 46 47

http://games.yahoo.com/game/typer-shark 05.10.2010 http://www.csd.uwo.ca/Infocom/zork1.html 06.10.2010 http://www.infocom-if.org/more/glossary.html#mdl 06.10.2010 http://www.gamasutra.com/view/feature/1499/the_history_of_zork.php?print=1 06.10.2010 http://en.wikipedia.org/wiki/Colossal_Cave_Adventure 06.10.2010 http://www.rickadams.org/adventure/ 06.10.2010 41

4 Analyse

Slouching Towards Bedlam Die Daten zu Slouching Towards Bedlam (Tabelle 3) stammen von Peccable Productions 48 , dem Artikel von John Bardinelli 49 , dem Review von Paul O‘Brian 50 . Blue Lacuna Die Daten für Blue Lacuna (Tabelle 3) stammen von der Webseite des Autors Aaron Reed 51 und dem Interactive Fiction Wiki 52.

Slouching Towards Bedlam (2003) Plattform: Inform 6 (Z-machine) 2003 XYYZY Awards: Bestes Schreiben, Beste NPCs, Bester individueller PC, Beste Nutzung des Mediums 2003 Interactive Fiction Competition: Bestes Spiel, Beste Story, Bestes Setting, Bester individueller NPC Fünf Enden, drei zeitliche Phasen

Blue Lacuna (2009) Plattform: Inform 7 (Glulx) 2009 XYZZY Awards: Bestes Spiel, Beste Story, Bestes Setting, Beste Nutzung des Mediums

Dynamische Raumbeschreibungen, abhängig von Tageszeit, Wetter und Wellengang und dem Wissen des Spielers (Protagonisten) Komplexe Charaktere Einsteigerfreundliche Schlüsselwort-Navigation Kompass-Navigation Drama-Manager Zwei Spielmodi: Story- oder Puzzle-Modus

Konversation z.B. per ASK <person> ABOUT <topic> Zeitreisen per RESTART, RESTORE und UNDO

Tab. 3, Slouching Towards Bedlam und Blue Lacuna im Vergleich

Auf eine Gegenüberstellung der beiden Flash-Spiele wird verzichtet, wer deren Tiefgang relativ überschaubar ist.

Big Player
Neben erwähnter Wichtigkeit von Adventure / Colossal Cave und Zork 1 soll e Hitchhiker's Guide to the Galaxy (Infocom) erwähnt werden, das sich kommerziell hinter Zork auf Platz zwei der Verkaufsliste einreihen kann. [Sco 10] Außerdem einflussreich für Aaron Reeds Blue Lacuna war die
48 49 50 51 52

http://www.peccable.com/if/slouching/ 06.10.2010 http://jayisgames.com/archives/2009/06/slouching_towards_bedlam.php 06.10.2010 http://spot.colorado.edu/~obrian/03rev3.html#slouch 06.10.2010 http://www.lacunastory.com/about.html 06.10.2010 http://ifwiki.org/index.php/Blue_Lacuna 06.10.2010 42

4 Analyse

bis zum Erscheinen von e Sims (2002) kommerziell erfolgreichste Reihe »Myst« [Wal 06]. Myst ist ein stark grafisch orientiertes Adventure. Es gilt als das berühmteste Grafik-Adventure von allen. [Rol 06, S. 553]

4.3.2 Zielgruppe
Browser-Spiele sprechen i.d.R. Gelegenheitsspieler an. Ambernstein tut das auch. In dem Zusammenhang spricht man auch von Casual Gamer bzw. Casual Game Player. Diese Zielgruppe reicht von 25 bis 50 Jahre. [Sch 08, S.101] Da Gelegenheitsspieler nicht lange warten wollen und recht bequem spielen möchten, soll auch das Charakteristikum der »Faulheit« der Menschen berücksichtigt werden. [KOS 05, S.130] Weiterführende Informationen zur Behandlung der Zielgruppe ist im Anhang zu finden – siehe »Ambernstein – Die Vision«.

4.3.3 Typische Merkmale
Bei allen betrachteten Spielen gibt es Gemeinsamkeiten, auch wenn sie sich teilweise besser als herunter geladene Version spielen und die Online-Version nur einen Bruchteil des Spiels oder eine nur beschränkte Immersion bietet. Das führt zu den Merkmalen von diesen Spielen. Die Webseite »hält« das Spiel. Webseite und Spiel bilden keine Einheit. Es ist kein Bezug von Webseite zum Spiel zu erkennen. Im Folgenden sollen die zuvor ausgewählten Spiele auf dieses Merkmal – also ihre Erscheinung im Browser – betrachtet werden. Colossal Cave macht dabei als Java-Applet in Abbildung 14 den Anfang. Durch den braunen Rahmen ist es nur bedingt stimmungsvoll.

Abb. 14, Colossal Cave per Java-Applet

53

Abb. 15, Zork 1 per Java-Applet 54

53 54

http://www.astrodragon.com/zplet/advent.html 05.10.2010 http://www.xs4all.nl/~pot/infocom/zork1.html 05.10.2010 43

4 Analyse

Zork 1 gibt es bereits in verschiedenen Online-Ausführungen: ganz einfach auf einer Webseite mit weißem Hintergrund und schwarzer Eingabebox (Abbildung 15) oder etwas aufwändiger per JavaScript (Abbildung 16).

Abb. 16, Zork 1 per JavaScript 55

Abb. 17, Slouching Towards Bedlam

56

Richtig toll ist das Spielerlebnis in Abbildung 16 nicht, wenn man eine Fehlerkonsole neben dem eigentlichen Spielfenster zu sehen bekommt. Etwas besser macht es Slouching Towards Bedlam (Abbildung 17), das die Webseite ganz in Schwarz hüllt und damit den Weiß auf Schwarz gefärbten Text recht immersiv abbildet.

Abb. 18, Stone Age Sam per Flash

Abb. 19 Typer Shark per Flash

55 56

http://zorkonline.net/zengine-0.4.3/ & http://zorkonline.net/ 05.10.2010 http://www.digital-eel.com/if/adv56.htm 05.10.2010 44

4 Analyse

Beinahe »typisch« präsentieren sich die beiden Flash-Spiele (Abbildung 18 und 19) als kleine Fenster in einem Rahmen mit Werbung, Links zu anderen Spielen und Links, die das aktuelle Spiel Freunden aus sozialen Netzwerken (Facebook, Twitter, etc.) empfehlen sollen.

Abb. 20, Blue Lacuna (Exzerpt) im Browser

In der Vorschau von Blue Lacuna im Browser (Abbildung 20) ist die Verbindung von Spiel besser gelöst. Da das Spiel mit der IF-Programmierumgebung Inform 7 erstellt wurde, ist ein einfacher Export in eine HTML-Datei möglich. Es zeigt sich, dass eine reine Auslegung auf den Browser bei allen Spielen (außer der JavaScriptVersion von Zork 1) nicht vorgesehen ist – die gezeigten Flash-Spiele sind damit auch gemeint, weil sie auch außerhalb [sic!] des Browsers lauffähig sind. Das liegt bei allen Titeln an der Technologie, die für die Programmierung genutzt wurde. Die beiden jüngeren IF-Titel nutzten Inform und den HTML-Export (Portierung), die Flash-Spiele machten Gebrauch von gleichnamiger Technologie, die in einem HTML-Dokument eingebettet wird.

4.3.4 Alleinstellungsmerkmale von Ambernstein
Spiel- und Webdesign werden ganzheitlich betrachtet. Statt die Webseite nur als Auffangbehälter oder Container mit Inhalt, nämlich dem Spiel an sich, zu sehen, wurde vom Entwickler darauf Wert gelegt, dass Webseite und Spiel miteinander interagieren und konsistent daherkommen. Da das Spiel eine maximale Verfügbarkeit für die Menschen etablieren soll, wurde entschieden, das Spiel explizit online im Browser anzubieten – programmiert mit nativen Browser-Technologien (HTML, CSS und JavaScript), die jeder Browser versteht!

45

4 Analyse

Weitere Merkmale zu Ambernstein sind im Abschnitt 4.1 von Tommy Krügers esis zu finden.

4.3.5 SWOT-Analyse von Ambernstein
Als Bilanz aus den Erfahrungen des aktuellen Markts können Stärken und Schwächen, sowie Möglichkeiten und Gefahren eruiert werden. Man spricht dabei von der SWOT-Analyse[Ung 09, S. 61]: Strengths, Weaknesses, Opportunities, Threads.

Stärken

Schwächen Linearer Verlauf der Story – drehbuchbasiert Geringe Interaktion – Einwirkung des Spielers ändert den Spielverlauf nicht

Holistische Betrachtung von Web und Game Design Web und Game Design interagieren miteinander Einfacher Einstieg in das Spiel durch geringe Eingabefrequenz per Tastatur Dient als Einstieg in die IF für Gelegenheitsspieler Anregung der Fantasie des Spielers Dramatik der Story Tab. 4, Stärken und Schwächen von Ambernstein

Chancen Blue Lacuna als Beispiel für ein potenziell gutes und kurzweiliges Spiel

Gefahren Zu viel Textausgabe könnte Spieler langweilen und ermüden

Tab. 5, Chancen und Gefahren für Ambernstein

4.4 Wahl der Technologie
Für Ambernstein wurde auf native Browser-Technologie gesetzt: eine Mischung aus HTML5, CSS3 und JavaScript in Karnation von jQuery. Für den dynamischen Auau der Webseite wurde »serverseitiges« PHP schlank eingesetzt. HTML5 wurde deswegen gewählt, weil es von sich aus multimedialer und stärker auf Webseiten als Anwendung gerichtet ist. Die Unterstützung 57 durch gängige Browser ist jetzt schon gegeben.

57

http://html5readiness.com/ 05.10.2010 46

4 Analyse

JavaScript wurde wegen der geplanten Ajax-Nutzung und der nativen Unterstützung in Browsern gewählt. Es nicht nötig, ein Add-on, Plugin o.ä. zu installieren. Speziell wurde jQuery gewählt, weil es browser-übergreifend kompatibel und relativ schlank ist (~24 KB). Es unterstützt CSS1 bis 3, und arbeitet kompakter durch kürzer geschriebenen JavaScript-Code. Außerdem ist die Community im Web mittlerweile sehr gewaltig und kompetent. CSS3 ist die neueste Version der Cascading Stylesheets. Sie sind das Standardwerkzeug eines Webdesigners, wenn es um die visuelle Präsentation der Webseite geht. Keine moderne Webseite kommt ohne CSS aus.

4.4.1 Vorteile nativer Browser-Technologien
Um die Vorteile nativer Technologien im Browser zu sehen, ist es wichtig zu erkennen, welcher Technologie-Einsatz noch möglich wäre: Flash von der Firma Adobe oder Silverlight von Microso. Es wird klar, dass einzelne Firmen mit entsprechenden kommerziellen Interessen dahinterstehen. Wie Apple-Chef Steve Jobs in seinen »oughts on Flash« richtig sagt 58 , ist Flash 100% proprietär. Nicht anders ist bei Silverlight. Es sind keine offenen Standards, sie wurden nicht von der Community geschaffen. Da besagte proprietäre Plugins bisher die fehlende Möglichkeit, multimediale Elemente wie Video und Audio in Webseiten einzubauen, wettmachten, schickt sich HTML5 nun an, selbst nativ diese Lücke zu schließen [Kei 10, S. 23] – per <audio> und <video> Tag. Patrick J. Lynch, Jakob Nielsen und Craig Hockenberry sprechen sich unterschiedlich explizit für native Browser-Technologien aus. Laut Lynch 59 verführt Flash dazu, Aufmerksamkeit um jeden Preis generieren zu wollen. Nielsen betrachtet Flash 2000 60 , 2005 61 und 2006 [Nie 06, 11] als »99% schlecht« und dessen Einsatz als einen der größten Fehler im Webdesign. Konsequenterweise hat er deswegen 2002 117 Usability-Richtlinien 62 für Flash-basierte Web-Anwendungen veröffentlicht. Hockenberry fasst in seinem Artikel »Apps vs. the Web« 63 bei A List Apart im August 2010 u.a. zusammen, warum es sich lohnen kann, auf Web-Standards zu setzen: Speed, Data Management, Animation.

58 59 60 61 62 63

http://www.apple.com/hotnews/thoughts-on-flash/ 05.10.2010 http://www.webstyleguide.com/wsg3/8-typography/7-signal-to-noise-ratio.html 05.10.2010 http://www.useit.com/alertbox/20001029.html 05.10.2010 http://www.useit.com/alertbox/designmistakes.html 05.10.2010 http://www.nngroup.com/reports/flash/RIA-usability.pdf 05.10.2010 http://www.alistapart.com/articles/apps-vs-the-web/ 05.10.2010 47

4 Analyse

Er räumt ein, dass JavaScript als interpretierte Programmiersprache zwar langsamer als eine kompilierte Programmiersprache wie C++ sei, dessen Geschwindigkeit aber kräig zugenommen habe. Dank HTML5 gibt es laut Peter Kröner [Krö 10, S.154] die Möglichkeit, Daten seiner Anwendung offline per Application Cache zu speichern oder in einer Web SQL Database 64 abzulegen. Bezüglich CSS3 nennt Hockenberry als Weg Animationen zu bauen, sieht die im Artikel verglichenen nativen (in Objective-C) programmierten iPhone-Animationen aber weiter vorne. Alex Kessinger 65 sieht den Vorteil von HTML5 darin, dass HTML-Code bereits bekannt ist und nach ein wenig Umgewöhnung an die neuen Tags – z.B. <header>, <footer>, <section> – HTML5Anwendungen schnell zu schreiben sind.

4.4.2 Nachteile von nativen Browser-Technologien
Um die multimedialen Eigenschaen von HTML5 auskosten zu können, ist nicht nur zunehmend das <canvas> Element gefragt, sondern auch JavaScript. Das ist deswegen der größte Nachteil, weil man es im Browser deaktivieren kann. Im Sinne der Accessibility ist dies natürlich gefährlich. Auch die Indizierung dynamischer durch Ajax-generierter Inhalte durch Suchmaschinen ist einer der Nachteile solcher Technologien. [Lyn 09, 10.2] Um der Entwicklung sogenannter Rich Internet Applications (RIA) Herr zu werden, hat die W3C entsprechende Richtlinien 66 verfasst. Auch Adobe selbst hat sich der Problematik der Accessibility unter Flash 67 angenommen.

4.4.3 Status Quo – Stand der Technik
So vorteilha native Technologien im Browser auch sind, sieht die Realität für Browser-Spiele anders aus. Flash-Spiele sind in der Überzahl. Es gibt erste Experimente 68 mit HTML5 und CSS3, die u.a. an frühe Flash-Animationen erinnern 69 . Nichtsdestotrotz finden sich erste Sammlungen 70 von HTML5-Spielen – wenn auch teilweise vielversprechend 71 , fallen sie noch übersichtlich aus.

64 65 66 67 68 69 70 71

http://dev.w3.org/html5/webdatabase/ 05.10.2010 http://net.tutsplus.com/tutorials/html-css-techniques/html5-apps-what-why-and-how/ 05.10.2010 http://www.w3.org/WAI/intro/aria 05.10.2010 http://www.adobe.com/accessibility/products/flash/tutorial/ 05.10.2010 http://www.chromeexperiments.com/, http://html5demos.com/ 05.10.2010 http://www.optimum7.com/css3-man/animation.html 05.10.2010 http://html5games.com/ 05.10.2010 http://web.appstorm.net/roundups/browsers/10-html5-games-paving-the-way/ 05.10.2010 48

4 Analyse

4.4.4 Alternativen
Technologische Alternativen sind wie teilweise bereits erwähnt: • Adobe Flash • Microso Silverlight • Java-Applets

4.5 Strategie
Das Dokument »Ambernstein – die Vision« hält die Strategie [Gar 03, S.38] fest. Im Wesentlichen enthält sie die Ziele der Entwickler und die Bedürfnisse der Nutzer. Gleichzeitig dient es aber auch als Projekt-Charter [Lyn 09, 1.8] und geht auf das Ökosystem eines Projekts [Ung 09, S.9ff] ein. Dieser Abschnitt bezieht nur sich in Auszügen auf besagtes Dokument – die komplette Ausführung ist im Anhang zu finden. Sie zeigt einen ersten Ansatz, da eine vollständige Unternehmensstrategie den Rahmen dieser Arbeit sprengen würde. Um eine klare Vorstellung davon zu bekommen, was vom Produkt erwartet wird, formuliert man in einem Satz das Application Definition Statement [Hop 09], das aussagt, welches Problem das Produkt löst und für wen es gedacht ist.

4.5.1 Definition der Anwendung
»Ambernstein ist ein leichtgewichtiges, einfach nutzbares, tastaturgesteuertes Browser-Spiel für nicht mobile 72 Gelegenheitsspieler.«

4.6 Anforderungen
Basierend auf den Ausarbeitungen und Erkenntnissen des vorigen Abschnitts zur Strategie, werden nun spezifische Anforderungen an die Funktionalität und den Inhalt gestellt, die der Nutzer abrufen kann. Man spricht dabei von dem Scope und meint damit einen zweckdienlichen Prozess, der ein gut nutzbares Produkt ergibt. [Gar 03, S. 62] Die Beweggründe für Erstellung des Produkte (das Warum) ist in der Strategie festgehalten. Dieser Abschnitt kümmert sich darum, was konkret erstellt wird. [Gar 03, S. 65] Bei der Anforderungsanalyse beru man sich auf die Erfahrungen aus dem Brainstorming. Der Vorgang fand bewusst nicht nach dem Prinzip des UCD statt, da ein größtmöglicher Überraschungsmoment generiert werden sollte. Die Nutzer zu fragen, was sie inhaltlich und
72

im Sinne von: nicht für Browser mobiler Endgeräte entwickelt 49

4 Analyse

funktionell in einem Spiel erwarten, funktioniert nur bedingt. Ambernstein sollte ohne diese Option auskommen. Um die Testpersonen zu verallgemeinern, entwickelte man einzelne Personas, die einen bestimmten Typen repräsentieren. Diese lässt man bestimmte Szenarios durchlaufen – siehe Anhang.

4.6.1 Inhaltlich
Im Stil eines Adventures
Ursprünglich als zweiteiliges Spiel geplant, das einen Action- und Story-Modus innehat, entschied man sich im Verlauf dazu, beide Modi miteinander zu kombinieren, um ein adäquates Spiel für Gelegenheitsspieler zu entwerfen. Mit Hilfe eines selbst verfassten Drehbuchs wird die Spielzeit sehr stark reglementiert und der Verlauf recht linear gehalten, was angesichts der Zielgruppe für sinnvoll und vernünig gehalten wird. Das Spiel dauert je nach Implementierung etwa 30 bis 60 Minuten.

Content-Management
Getreu dem in der Strategie verfassten Leitsatz, Dinge einfach zu halten, entschied man sich gegen ein Content-Management-System (CMS). Stattdessen wurde XML genutzt – ein im Web und auch im Desktop-Bereich sehr gängiges, weil universelles Datenformat. Im Wesentlichen handelt es sich um die Handhabung von Drehbuchtexten, also die Beschreibungen von Ort, Zeit und Handlung des allwissenden Erzählers aus dem Off in der dritten Person. Weiterhin relevant waren die Gedanken und Gefühle der handelnden Person – üblicherweise in Klammern dargestellt. Darüber hinaus bedeutsam waren Dialoge, sowie Bilder und der Soundtrack (einschließlich der Sound-Äquivalente zum visuell dargestellten Text – in Rücksichtnahme auf Aspekte der Accessibility), der der Untermalung der Situation dient. Der Umfang der nötigen Dateien wird relativ schlank sein – siehe Abschnitt 5.3.

4.6.2 Funktional
Interaktion: Nutzer und UI
Der Begriff des UI legt es bereits nahe, dass die Interaktion zwischen Spieler und Schnittstelle (Spiel) effektiv verlaufen muss. Für das UI-Design wird sich deshalb auf die wichtigsten Designprinzipien von Donald A. Norman [Nor 02, Preface] berufen: • Conceptual models

50

4 Analyse

• Feedback • Constraints • Affordances Conceptual models helfen dem menschlichen Verstand, Dinge und Gegenstände intuitiv in ihrer Funktion zu verstehen. Das Endgerät dient dabei als Kommunikationsmittel zwischen Designer und Nutzer. Scheitert dieser Prozess, ist es dem Designer nicht gelungen, sein Produkt selbsterklärend zu machen. Das sogenannte natürliche Abbilden (natural mapping) ist fehlgeschlagen und der Nutzer muss sich das Gerät selbst erklären. Nicht selten entstehen dabei Fehler und Frustration. Feedback ist zwar selbsterklärend, deswegen aber nicht weniger entscheidend. Es meint die Rückmeldung, die nach dem Durchführen einer Aktion, gezeigt wird. Constraints bedeutet wörtlich übersetzt »Einschränkungen«. Im Design meint Norman damit, dass Fehler in der Bedienung vermieden werden sollen, indem die Möglichkeiten zur Nutzung eingeschränkt werden. Affordances meint visuelle Mittel, die passende Aktionen wahrnehmbar und unpassende Aktionen unsichtbar machen.

Interaktion: Web UI und Game UI
Das Web UI reagiert mit verschiedenfarbigen Plättchen, die sich bei einem Wechsel zu einer anderen Subwelt und dem Wechsel zu einer anderen (besonderen) Situation färben, z.B. bei Flashbacks des Protagonisten. Ziel ist es, ein ganzheitliches Browser-Erlebnis zu generieren, bei dem Web und Game UI interaktiv miteinander umgehen; sprich: Elemente, die normalerweise außerhalb des »Spielfelds« liegen, werden auf bestimmte Art mit einbezogen. Beispiele dafür sind die Ansätze der Browser-Spiele Quake Live 73 und Legends of Zork 74 .

Accessibility
Im Folgenden sollen die Anforderungen an die Zugänglichkeit ausformuliert werden:

73 74

http://www.quakelive.com/ http://legendsofzork.com/ 51

4 Analyse

1. Ambernstein orientiert sich an den Richtlinien der WCAG 2.0 75 der WAI 76 2. Ambernstein orientiert sich an den Richtlinien der US Section 508 77 . 3. Ambernstein orientiert sich an den Richtlinien der WAI-ARIA 78. 4. Ambernstein orientiert sich an den vier Aspekten der Web Accessibility für den Geschäsbereich: sozial, technisch, finanziell, rechtlich. 79 5. Ambernstein berücksichtigt folgende Beschränkungen: motorisch, kognitiv, visuell, akustisch. [Lee 10] 6. Ambernstein berücksichtigt Tests mit einem Screenreader, wird diese aber nur bedingt implementieren. Die genannten und folgenden Anforderungen werden im Sinne eines Prototypen teilweise implementiert. Im Sinne der Spielerfahrung sind die Anforderungen zur Zugänglichkeit immer in einem Kompromiss zu eruieren. Es ist nicht ausgeschlossen, dass Teilaspekte nicht berücksichtigt werden können. Die Richtlinien der WCAG 2.0, die vom W3C explizit empfohlen 80 werden, lauten: • Wahrnehmbar • Bedienbar • Verständlich • Robust Lesbarkeit, Erkennbarkeit und Immersion In Spielen, auf entsprechenden Webseiten zum Spiel oder auch direkt in Browser-Spielen ist es nicht unüblich, dass z.B. in einem mittelalterlichen Spiel auch eine adäquate Schriart benutzt wird. Es ist teilweise fraglich, ob man diese gut lesen kann. Die Frage, die sich im Rahmen dieser Arbeit stellt, ist die nach der Immersion – also dem Abtauchen und Eintauchen in ein Spiel. Diese muss in einem Kompromiss zur Lesbarkeit und Erkennbarkeit von Text gesehen werden. Für Ambernstein setzte man auf optimale Lesbarkeit und wählte Helvetica – gemäß Experten-Umfrage die »beste Schri aller Zeiten«. 81

75 76 77 78 79 80

http://www.w3.org/Translations/WCAG20-de/ http://www.w3.org/WAI/ http://www.section508.gov/ & http://www.hhs.gov/web/508/index.html http://www.w3.org/WAI/intro/aria.php http://www.w3.org/WAI/bcase/Overview

»[...] W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.« – http://www.w3.org/TR/WCAG20/ 05.10.2010
81

gemäß einer internationalen Jury im Januar 2007 – http://100besteschriften.de/ 52

4 Analyse

Auf den Kompromiss von Immersion (Groking) [KOS 05, S.28] und Accessibility wird im folgenden Abschnitt näher eingegangen.

4.6.3 Technisch
Die technischen Anforderungen für Ambernstein sind ausführlich argumentiert und mit entsprechenden Quellen untermauert. Aufgrund des Umfangs wurden sie ausgelagert in das separate Dokument »Ambernstein – Technische Anforderungen an die UX« – siehe Anhang.

4.7 Angestrebte Funktionen
4.7.1 Kernfunktionen
Tastatursteuerung
Tastatursteuerung ist das Kernelement eines Text-Adventures. Es ist ein glücklicher Zufall und ein Ausdruck des modernen Anspruchs von Ambernstein, dass für 2010 die Keypress Navigation als Trend vorausgesagt wurde. Es gibt bereits einige Beispiele, die erfolgreich z.B. die Cursor-Tasten zur Navigation benutzen. [Fri 10]

Textdarstellung
Es liegt nahe, in einem Text-Adventure Text darzustellen. Dennoch soll das Kriterium als explizite Kernfunktion erwähnt sein.

4.7.2 Außerordentliche Funktionen
Gemeint sind Funktionen und Paradigmen, die man bisher in der Form bei einem Text-Adventure noch nicht gesehen hat 82 . Dazu zählen: • eine Story, die auf einem filmischen Drehbuch basiert • eine rein auf den Web-Browser abgestimmte Spiel-Erfahrung • eine betriebssystemunabhängige Erfahrung • ein UI, das Web- und Spieldesign ganzheitlich betrachtet

82

gemäß der Recherche des Autors 53

4 Analyse

4.8 Fazit
Kern- und Knackpunkt bei der Entwicklung von Ambernstein ist JavaScript. Für die UX ist es unerlässlich, weil das Spielerlebnis – insbesondere die Mini-Spiele – ohne aktiviertes Client-Side JavaScript (CSJS) nicht generiert werden kann. Es ist also ein Dilemma: Einerseits möchte man höchst zugänglich sein, andererseits soll eine maximale UX geschaffen werden. Der nun folgende Konzeptteil soll beschreiben, wie eine mögliches Lösung dieses Dilemmas aussehen kann.

54

5
Konzept
Storytelling, Webdesign, Spieldesign.

55

5 Konzept

5.1 Herangehensweise
Die Ergebnisse aus der Analyse und den Anforderungen zeigen, wie Text-Adventures von heute aussehen und wie Ambernstein als Text-Adventure mit leichter grafischer Orientierung aussehen kann. Das Konzept thematisiert nun das Storytelling, sowie das Web- und Spieldesign. Im Drehbuch wird die Story so geschrieben, dass man Ambernstein zwar geradlinig aber auch mit gewollten Höhepunkten in der Dramatik erleben kann. Das Spieldesign wird im Wesentlichen in der esis von Tommy Krüger aufgegriffen und beschreibt die prototypische Implementierung in JavaScript sowie strukturelle Angelegenheiten. Das Webdesign liegt wiederum im Schwerpunkt des Autors dieser Arbeit. Dieser Abschnitt hingegen soll mit generellen Entwurfsüberlegungen beginnen und dann zu ersten Papier-Prototypen führen, die die Anforderungen der Analyse berücksichtigen. Im besagten iterativen Prozess werden diese Entwürfe zum ersten UI und Information Design führen. Anhand begleitender Usability-Tests für das Web Interface sollen Schritt für Schritt mögliche Unzulänglichkeiten erkannt und verbessert werden, um einen ersten Eindruck vom Spielgefühl zu bekommen.

5.1.2 Sieben Schritte
Im Hinterkopf behalten sollte man die sieben Schritte der Aktion eines Nutzers: Davon ist ein Schritt aufs Ziel der Aktion, sind drei auf die Ausführung und wiederum drei auf die Auswertung der Aktion bezogen: [Nor 02, S.48] 1. Forming the goal 2. Forming the intention 3. Specifying an action 4. Executing the action 5. Perceiving the state of the world 6. Interpreting the state of the world 7. Evaluating the outcome In Abbildung 21 83 sind besagte Schritte nochmals schematisch abgebildet.

83

http://upload.wikimedia.org/wikipedia/en/6/6e/Seven_Stages_of_Action.JPG 05.10.2010 56

5 Konzept

Abb. 21, Die sieben Handlungsschritte eines Nutzers nach Norman

5.2 Storytelling
Das Spiel sollte sehr story-orientiert entwickelt werden. Deshalb sollte als erster Schritt, das Drehbuch geschrieben werden. Laut Rouse III ist dies eine der drei validen Startmöglichkeiten für Spiele. [Rou 05, S45f.] Dessen bewusst, dass Drehbücher eigentlich für Filme gedacht sind, die linear ablaufen, war es auch für das Spiel passend, weil die Zielgruppe (Gelegenheitsspieler) nicht zu vielen Hürden begegnen sollte. Potenziell ist der Text und das relativ viele Lesen eine mögliche Barriere, aufgrund der Genrewahl aber unabdingbar. Der relativ hohe Textkonsum soll durch ein flüssiges Gameplay 84 und schnelle Erfolgserlebnisse in Form von Feedback wett gemacht werden. Da das erste Mal ein Drehbuch verfasst wird, wurde professionelle Unterstützung in Form eines Handbuchs von Syd Field [Fie 98] zur Hilfe genommen.

5.2.1 UX und Storytelling
Dass nicht nur das Spiel von einer Geschichte profitiert, zeigt Francisco Inchauste, indem er die UX nutzt, um die scheinbar verloren gegangene menschliche Verbindung mit Storytelling-Methoden wieder aufzubauen. Für den Zweck der Story bedient man sich den Archetypen, die Carl Gustav Jung als »Grundpfeiler der Analytischen Psychologie« schuf. [Jun 09] Er vertrat die Vorstellung, dass

84

engl. Spielmechanik; teilweise auch als »Game Play« geschrieben 57

5 Konzept

wir unbewusst die Idee des Helden, Mentors und Quests innehaben. [Inc 10a] Joseph Campbell, der dieses Modell adaptierte, schildert in e Hero with a ousand Faces (1949) seine Erfahrungen zu Strukturen von Religion und Mythen. Vergleicht man nun Film-Reihen wie Matrix und ältere Reihen wie Star Wars, fallen die gleichen (mythischen) Muster auf, die Jung bzw. Campbell beschrieben:

Campbell Zwei Welten Der Mentor Das Orakel Die Prophezeiung Der gescheiterte Held Feindkleidung tragen Gestaltwandler Tier jagen

Matrix Realität und Die Matrix Morpheus Das Orakel Morpheus findet de Auserwählten Cypher (im frühen Script) Neo als Agent Cypher Neo folgt dem weißen Hasen

Star Wars Heimatplanet und Todesstern Obi-Wan Kenobi Yoda Luke stürzt das Imperium Biggs Luke und Han Solo als Stormtrooper Han Solo Luke folgt R2

Tab. 6, Mythische Muster in Filmen (Matrix, Star Wars)

Matrix und Star Wars spielen dabei gleichermaßen mit den Gefühlen der Zuschauers. Die Story baut besagte emotionale Verbindung auf. Ähnlich tut es auch Starbucks, die ihre Filialen in den Städten dieser Welt als dritten Ort nach dem Zuhause und der Arbeit sehen. Konsequenterweise sehen sie in ihrem Web-Auritt den vierten Ort. 85 Ambernstein positioniert sich als Spiel mit einfachem Zugang und einer etwas schrägen, selbstironischen und dennoch dramatischen Story. Storytelling ist bedingt durch die Entwicklung des Drehbuchs ein Bestandteil dieser Arbeit – siehe Abschnitt Drehbuch. Interessant wird Storytelling hinsichtlich Design, wenn man es als narratives Design 86 bezeichnet. Es erleichtert, die UX mit einer einheitlichen »Stimme« zu präsentieren – ähnlich wie es das Paradigma des konsistenten Designs tut. [Cha 09] Storytelling ist wichtig, weil es den Sinn und Zweck eines Ortes wiedergibt. 87

5.2.2 Analogie zu Film und Buch
http://blogs.reuters.com/shop-talk/2010/09/22/starbucks-ceo-says-building-fourth-place-online/ 05.10.2010
85 86 87

Curt Cloninger, [Inc 10b] Christian Saylor, [Inc 10b] 58

5 Konzept

Als filmisches Element wird für Ambernstein ein Drehbuch benutzt. Es ist die lineare Vorlage. Ambernstein ist aber ein Text-Adventure, das man auch als gespieltes (interaktives) Buch bezeichnet. Es sind also drei Elemente vereint: das Drehbuch des Films, die imaginäre Vorstellungskra eines Buchs, und die Interaktion eines Spiels.

Experience Theme
Als Mittel eine optimale UX zu generieren, rät Cindy Chastain [Cha 09] ein Experience eme zu schaffen. Wie in Abbildung 22 gezeigt, wird durch ein ganzheitliches ema der Film harmonisiert.

Abb. 22, Greifbare UX-Elemente in Film und Webseite

Es wird deutlich, dass die Story den Film zusammenhält und koordiniert. Dabei ist jede Szene zweckdienlich, um das Ziel der emotionalen Erfahrung zu schaffen. Eine klassische Webseite kann mit dieser Koordination nicht aufwarten. Um auch bei der Web-Entwicklung story-orientiert vorzugehen, ist besagtes Experience eme nötig, das alles zusammenhält. Die anfänglich wichtigsten Fragen sind: • Worum geht es bei der Webseite? • Welche Erfahrung ist die fesselndste und bedeutendste für unsere Nutzer?

59

5 Konzept

Das ema wird dann in einem Experience Brief festgehalten, das den Zweck des emas, die Umstände aufgrund dessen das ema entstand und die damit vermittelte Strategie (Experience Strategy). beinhaltet. Betrachtet man das ema als geografische Landscha, auf der man Ideen kreativ kultivieren kann und als Kompass, der für die Analyse und Auswertung der Lösungsvorschläge hinzugezogen wird, hat man ein hilfreiches Werkzeug für den UX-Designprozess und die Strategie (Abbildung 23) 88 . Dies kommt letztendlich dem Nutzer zugute.

Abb. 23, Experience Theme

Ein Experience eme wurde für Ambernstein nicht angefertigt, da das Dokument »Ambernstein – Die Vision« wesentliche Inhalte dieses formalen Dokuments enthält – siehe Anhang.

5.2.3 Drehbuch
Für Ambernstein hielt man sich an die typische Drei-Akt-Struktur 89 eines Films (Abbildung 24).

Abb. 24, Drei-Akt-Struktur eines Films

http://www.slideshare.net/cchastain/experience-themes-an-element-of-story-applied-to-design-1190389, S. 47
88 89

http://www.musik-therapie.at/PederHill/Structure&Plot.htm 60

5 Konzept

Auch der typische Spannungsverlauf 90 eines Films (Abbildung 25) wurde bei der Entwicklung des Drehbuchs berücksichtigt.

Abb. 25, Spannungsverlauf eines Films

Traditionelles (lineares) Storytelling wurde u.a. aus folgenden Gründen benutzt: [She 04, S.300] • Es ist lange erprobt und bewährt. • Es ist erfolgreich in einer Vielzahl von Medien. • Es ist dem Autor bekannt und behagt dem Spieler. • Es garantiert Kontrolle über den Verlauf der Story seitens des Autors. Weitere Ausführungen zum Drehbuch sind im folgenden Umsetzungsteil dieser esis zu finden. Die erste Rohversion des Drehbuchs, inklusive eines einseitigen Treatments, ist im Anhang zu finden.

5.2.4 Charaktere
Figuren
In Ambernstein treten in der jetzigen Version folgenden Figuren in Erscheinung: Relat, Rela, Rasmandal, Albugal, Haikun, Fennek und Mumbai. Das Drehbuch sieht noch mehr Figuren vor.

90

http://www.musik-therapie.at/PederHill/Structure&Plot.htm 06.10.2010 61

5 Konzept

Eine kurze Beschreibung ist in Tommy Krügers esis zu finden. Eine ausführlichere Beschreibung vom Protagonisten ist im Anhang zu finden. Mehr Hintergrundwissen zu der Entwicklung von Charakteren ist in [She 04] zu erfahren.

Archetypen
Bei den geschaffenen Figuren orientierte man sich an den Archetypen von Jung. [Jun 09] Dies tat auch Vogler [Vog 98, S.79ff.]. Bekannte und nützliche Archetypen sind laut ihm: • Held • Mentor • Schwellenhüter • Herold • Gestaltwandler • Schatten • Trickster Nicht jeder Archetyp wird von Ambernstein besetzt. Der Held der Geschichte ist Relat, da man sich ehesten mit ihm identifizieren wird. [Vog 98, S. 89] Wie Helden heutzutage von Spiele-Entiwcklern gesehen werden, ist in [Nee 10b] zu sehen. Rasmandal ist der Mentor, weil er den Helden unterstützt uns ausrüstet. [Vog 98, S.105] Mumbai nimmt die Rolle des Schwellenhüters ein, weil er vom Helden besiegt werden muss, um die »Pforte zu einer neuen Welt« zu erreichen. [Vog 98, S. 121] Haikun steht für den Herold, weil er den Helden mit einer Herausforderung konfrontiert. [Vog 98, S.127] Noch strittig ist die Besetzung der Figur der Rela, da sie zwar in Beziehung zu Relat steht, nichtsdestotrotz aber Züge eines Gestaltwandlers aufweist. [Vog 98, S.133] Fennek zählt mit seinen Absichten zum Archetypus des Schattens, weil er üblicherweise das Böse repräsentiert. [Vog 98, S. 143] Wenn auch nicht explizit als Figur vertreten, leistet der Erzähler des Dramas das was den Trickster ausmacht – er bringt das »Publikum beizeiten wieder auf den Boden der Wirklichkeit zurück« und sorgt für »Entspannung durch Komik. [Vog 98, S.151f.]

5.2.5 Soundtrack
Für Ambernstein wird ein Soundtrack gewählt, der Lieder unter der CC-Lizenz 91 beinhaltet. Musik, die vom Künstler selbst lizensiert und vermarktet werden kann, entspricht der Strategie von
91

Creative Commons Lizenz – http://creativecommons.org/ 62

5 Konzept

Ambernstein. Alternativ ist ein Soundtrack mit Liedern kommerziell vermarkteter Künstler vorgesehen, da deren Lieder teilweise besser zur Stimmung des Spiels passten oder es auf dem CCMarkt keine entsprechenden Äquivalente gab. Im Anhang sind erste Tracks zu finden - auf einen vollständigen Soundtrack wurde auf Grund des Umfangs des Drehbuchs verzichtet.

5.3 Abstrakte Struktur
Bereits während der Analyse wurde nach funktionalen und inhaltlichen Anforderungen unterteilt. Implizit wurde dabei die Unterscheidung zweier Sichtweisen auf das Web vorgenommen. Laut Garrett gibt es das Web als Soware-Interface und als Hypertext-System. [Gar 03, S.31] Im Hypertext-System geht es um die Bereitstellung von Information und welchen Nutzen sie für den Nutzer hat. Der Produzent dieser Information kann auch als Informationsarchitekt angesehen werden. [Gar 03, S.86f.] Im Web als Soware-Interface konzentriert man sich auf die mit der Webseite verbundenen Aufgaben und deren Lösung. Die Webseite wird als Werkzeug gesehen. Den Produzenten dieser Aufgaben und Lösungen bezeichnet man auch als Interaktionsdesigner. Im Folgenden werden diese beiden Sichtweisen explizit eingeführt.

5.3.1 Informationsarchitektur
Die Informationsarchitektur (IA) ist für Ambernstein nicht besonders komplex. Es werden die interne und öffentliche Architektur unterschieden. Gemäß Peter Morville hängen IA und UX zusammen. Insofern sind die »Kreise der Informationsarchitektur« in Abbildung 26 auch für die UX gültig. [Mor 04]

Abb. 26, Kreise der IA/UX 63

5 Konzept

Es ist also festzuhalten, das bei der Informationsarchitektur der Kontext, Inhalt und Nutzer ein großes Ganzes ergeben. Die in der Analyse beschriebenen inhaltlichen Anforderungen sollen nun mit Inhalt gefüllt werden: • Quelltext • Dateien im Format HTML, CSS, JS und PHP • Inhalts-Text • Dateien im Format XML und TXT • Dokumente • Dateien im Format PDF (eses) • Bilder • Dateien im Format JPG, PNG, GIF • Sound • Dateien im Format MP3 und OGG Der konkrete abschätzbare Umfang der Inhalte soll nun angegeben werden: Quelltext < 100 KB Inhalts-Text < 1 MB Dokumente < 10 MB Bilder < 10 MB Sound < 100 MB Die Handhabung der Dateien erfolgt über einen gesicherten FTP-Zugang, der nur den Entwicklern vorbehalten ist.

Architektonische Herangehensweisen
Dem Top-Down-Prinzip, bei dem ausgehend von der Strategie die Seiten-Hierarchie aufgebaut wird, steht das Bottom-Up-Prinzip entgegen, bei dem von den Anforderungen an Inhalt und Funktion ausgegangen wird. In der Regel findet man mit einer gesunden Mischung aus beiden Sichtweisen die richtige Architektur. [Gar 03, S.95] Hierarchie Die bereits angedeutete hierarchische Struktur meint die Eltern-Kind-Beziehung eines »Baums«. Jeder »Ast« des Baums wird als »Knoten« bezeichnet. Jeder Kind-Knoten hat zwar einen ElternKnoten, aber nicht immer weitere Kind-Knoten. [Gar 03, S.98ff.] Die Abbildung 27 zeigt diese hierarchische Struktur. [Pre 04]
64

5 Konzept

Abb. 27, Hierarchische Informationsarchitektur

Weitere denkbare Strukturen sind in Abbildung 28 zu sehen: [Pre 04] • eine Matrix • eine Sequenz • organisch / web-linked (vergleichbar mit einer Mind-Map)

Abb. 28, Sequenzielle und organische Informationsstruktur

Für Ambernstein soll eine hierarchische Struktur aufgebaut werden. Auch wenn nur zwei Hierarchiestufen vorgesehen sind, ist diese Struktur für den Ausbau weiterer Seiten bestens gerüstet (Abbildung 29). [Pre 04]

Abb. 29, Ausbau einer hierarchischen Struktur

Organisationsprinzipien
Die Organisation der Inhalte ist ein wesentlicher Bestandteil der Informationsarchitektur. Gemäß Garrett [Gar 03, S.101] gibt es fünf verschiedene Prinzipien, Inhalte zu organisieren:
65

5 Konzept

• nach Zielgruppen • nach der Zeit • nach Orten • nach Kategorien • nach gewissen Größen (z.B. Gewicht) Auch eine alphabetische Organisation kann Sinn machen. Richard Saul Wurman geht in Information Anxiety (1989) auf ähnliche Formen der Organisation ein. Für Ambernstein wurde die Methode des Card-Sorting verwandt, um eine intuitive Organisation der Navigation zu gewährleisten. [Lyn 09, 3.2]

Nomenklatur
Verständliche Begriffe auf der Webseite sind wichtig, um die vom Nutzer erwartete Information auch wirklich zufriedenstellend liefern zu können. Insofern ist für Ambernstein eine starke Anlehnung an die natürliche Sprache – ohne Fachjargon – vorgesehen. [Gar 03, S.103]

Meta-Daten
Um es gemäß der internen Philosophie auch in der internen Verwaltung nicht allzu kompliziert zu machen, werden entsprechende »Informationen über Informationen« [Gar 03, S. 105] sehr übersichtlich verwendet. Dementsprechend gibt es als Meta-Angaben: • den Namen der Seite • das Datum der Erstellung • das Datum der letzten Änderung • den Verantwortlichen für die Erstellung und die letzte Änderung • und ggf. die Versionsnummer

Interne Architektur
Es sollen die Ordner und Dateien, die die Struktur, Inhalte und Funktionen beinhalten, im Folgenden schematisch aufgezählt werden. Dabei wird generell in drei Bereiche unterschieden: den Informations-Bereich (»web«), den Interaktions-Bereich (»game«) und den Bereich (»global«), der Elemente funktionalen Ursprungs für eben genannte Bereiche beinhaltet:

66

5 Konzept

•/ • /global • /game bzw. /web • /structure • /layout • /content • /behavior

Öffentliche Architektur
Es soll nun die öffentlich sichtbare Sitemap dargestellt werden: • Home + Link: Spiel starten • Ambernstein • Hintergrund • Beteiligte • Motivation • Mission • eorie Eine schematische Ansicht des Architekturdiagramms 92 , die mit dem Visual Vocabulary von Jesse James Garrett erstellt wurde, ist im Anhang zu finden. Auf eine Suchfunktion wurde verzichtet, weil der Umfang der Seite dieser Funktion nicht gerecht werden würde. [Lyn 09, 3.3] Idealerweise sollte das Diagramm die Dateien und Verzeichnisse auf dem Server strukturell ähnlich widerspiegeln. [Lyn 09, 3.4]

5.3.2 Interaktionsdesign
Das Interaktionsdesign beschreibt das mögliche Nutzerverhalten, definiert wie die Anwendung dieses Verhalten aufnimmt und darauf reagiert. Die Vorstellung davon, wie eine interaktive Anwendung reagiert, wird in den konzeptionellen Modellen des Nutzers festgelegt. [Gar 03, S.87ff.] Das darauf folgende Nutzerverhalten lässt sich in sogenannten Task Flows darstellen. [Ung 09, S. 178]

Task Flow
92

interne Bezeichnung einer Sitemap [Gar 03, S.107] 67

5 Konzept

Eine schematische Ansicht des Task Flows ist im Anhang zu finden. Eine früher Task Flow ist in Abbildung 30 zu sehen.

Abb. 30, Task Flow eines frühen Wireframes

Konzeptionelle Modelle
Da sich der Nutzer auch Gedanken macht, wie die Seite strukturell aufgebaut ist und wo er Funktionen erwartet, baut er sich im Unterbewusstsein ein Verständnis dafür auf. Sowohl für die Informationsarchitektur [Lyn 09, 3.3] als auch für das Interaktionsdesign [Gar 03, S.89] ist es ratsam, sich an diesen Erwartungen zu orientieren. Werden diese Erwartungen nicht erfüllt, neigt der Nutzer dazu, Fehler zu machen und frustriert zu werden. [Nor 02, S.xi] Laut Norman sind konzeptionelle Modelle eine Untergruppe der mentalen Modelle. [Nor 02, S.17]

Fehlerbehandlung
Fehler zu begehen ist menschlich. [Nor 02, S.105] Daher müssen sie in entsprechenden Situationen verhindert, abgefangen und rückgängig gemacht werden können. [Gar 03, S.92ff.] Das Design der Anwendung muss also präventiv (pro-aktiv), progressiv (aktiv) und retrospektiv [Shn 03a, S.190] (reaktiv) mit Fehlern umgehen können. 93 Die Fehlerbehandlung arbeitet wie ein Filter. Was der Präventionsfilter nicht behandelt, übernimmt der Korrekturfilter. Kann der Fehler nicht unmittelbar korrigiert werden, ist es eigentlich schon zu spät. Hier hil, den Fehler rückgängig zu machen – die bekannte Undo-Funktion ist gemeint. [Coo 07, S.335]

93

http://www.olev.de/r/reaktiv_usw.htm 05.10.2010 68

5 Konzept

5.4 Konkrete Struktur
Nachdem nur bedingt anschaulich die Struktur der Web-Anwendung dargestellt wurde, soll nun weniger abstrakt gezeigt werden, wie konkret Ambernstein aussehen kann. Die Anforderung an die konkrete Struktur ist wie auch zuvor schon, einen Kompromiss zu finden aus maximaler Zugänglichkeit, Lesbarkeit, Immersion in das Urzeit-ema des Spiels und die tragische Story.

5.4.1 Interface Design
Ambernstein ist eine Mischung aus grafischer Benutzeroberfläche (GUI) 94 und einer der Kommandozeile ähnlichen Oberfläche (CLI) 95, die aus Text aufgebaut wird (TUI) 96.

Benötigte Elemente
In Abbildung 31 sind die benötigten Elemente für das Interface Design des Spiels aufgelistet: • Grid (Hintergrund) • Header (Grafik, Text) • Footer (Text) • Navigation (Buttons) • Informationsflächen (Text)

Abb. 31, Frühe Übersicht der UI-Elemente, teilweise mit Funktionsabläufen
94 95 96

GUI: Graphical User Interface CLU: Command-Line Interface TUI: Text User Interface 69

5 Konzept

Die benötigten Element unterscheiden sich beim Informations- und Interaktionsmodus von Ambernstein. Im Folgenden wird auf die Spezifika beider Layouts eingegangen. Zunächst soll aber die gemeinsame Menge an benötigen Elementen des User Interface beleuchtet werden. Header Der Kopf-Bereich der Webseite wird bei beiden Modi vorhanden sein – im Web-Modus deutlich präsenter als im Spiel-Modus. Footer Der Fuß-Bereich als unterster Teil der Webseite wird im Web-Modus nur als Halter für die Copyright-Informationen dienen. Im Spiel-Modus ist der Footer als interaktives Element für den Fortschritt im Spiel zu sehen. Je weiter der Spieler voranschreitet, desto mehr offenbart der grafische Footer. Layout Während im Web-Modus das Gitter-Layout nur angedeutet wird, ist es beim Spiel-Modus klarer Layout-Bestandteil. Die Andeutung des Gitter-Bereichs wurde während des Usability-Tests von einer Testperson erkannt. Diese gab zu verstehen, dass dort Inhalt zu erwarten sei. Informationsbereiche Vorab und während des Spiels wird der Spieler mit Informationen versorgt. Ob es im Web-Modus die allgemeinen Informationen zur Entstehung des Spiels sind oder die Informationen, die direkt während des Spiel serviert werden.

Web UI Layout
Zunächst war vorgesehen, Web UI und Game UI gleichaussehend zu gestalten. Der Nutzer sollte nicht merken, ob er noch auf der Webseite (zur Informationsbeschaffung über das Spiel) oder schon im Spiel (dem eigentlichen Text-Adventure) ist. Die Idee war dem Nutzer mitzuteilen, er sei einfach in »Ambernstein«. Im Sinne der Konsequenz war vorgesehen, für ein rein tastaturgesteuertes Text-Adventure auch ein tastaturähnliches Gitter-Layout (Grid) für das Interface zu benutzen – Abbildung 32. Es sollte das Gefühl stärken, dass bei dieser Webseite die Tastatur wirklich im Vordergrund steht. Die Tasten waren im Vergleich zu einer echten Tastatur in ihrer Anordnung nachvollziehbar verteilt. Man könnte sich daran stören, dass in der Mitte das Nummernfeld erscheint. Es sollte der Navigation zu den einzelnen Seiten dienen.
70

5 Konzept

Abb. 32, Frühes Wireframe des Web UI Layouts

Etwas weiter ging die Skizze der Web UI (Abbildung 33), die die unterschiedliche Funktion des Footers im Web- und Spiel-Modus mit einbezieht.

Abb. 33, Web UI mit Footer als Funktionseinheit

71

5 Konzept

Konzeptionell war es aber nicht ganz zu Ende gedacht, weil die Navigation zu dominant war und keinen Raum mehr für Inhalte ließ. Inhalts- und Navigationsdesign müssen natürlich in einem gesunden Verhältnis zueinander stehen. Die Nutzer gehen nach wie vor nicht wegen toller Funktionen oder Navigationen auf Webseiten [Gar 03, S.36], sondern wegen der Inhalte. [Ung 09, S. 135f.] Darüber hinaus ist die Mitte auch nicht der typische Ort an dem Menschen die Navigation erwarten – Abbildung 34 [Lyn 09, 3.4]. Bernard [Ber 01] bestätigt dies.

Abb. 34, Erwartung der Nutzer über den Ort der internen Navigation

Die Erwartung der Nutzer weiterer für Ambernstein relevanter Links sind der Home-, der Hilfeund About-Link, sowie die Links zu externen Seiten. Abbildung 35 verdeutlicht diese Erwartungen. [Lyn 09, 3.4]

72

5 Konzept

Abb. 35, Erwartung der Nutzer über den Ort weiterer Navigationselemente

Für die esc-Taste war neben dem Abbrechen einer Aktion auch das Zurückgehen auf die Home-Seite vorgesehen. Laut Studie wäre dieser Platz ideal gewesen. In diesem frühen Layout war noch vorgesehen, dass die Webseite auf den Informationsseiten nur per Tastatur gesteuert werden sollte. Die Maussteuerung sollte komplett ausgeschaltet werden. Dass das nicht W3C-konform, ist im Abschnitt 4.6 nachzulesen. Spezielle Elemente Wie bereits bei den benötigten Elemente gesagt, gibt es sowohl für den Web- als auch Spiel-Modus verschiedene Elemente. Im Web-Modus sind folgende Elemente des Interface Designs (Abbildung 36) relevant: • Umschalten der Ansicht: Desktop, Mobil, Druck, Nur Text • Navigations-Links • Informationen zur Tastatur-Navigation (als Ergebnis des Web Usability-Tests) • Verändern der Schrigröße • Verändern des Farbschemas

73

5 Konzept

Abb. 36, Web UI Elemente

Es wird deutlich, dass für das Erstellen des User Interfaces die Disziplinen des Interface, Navigation und Information Design implizit enthalten sind. [Gar 03, S. 115] An dieser Stelle sollen diese Begriffe in einer kurzen Definition auseinandergehalten werden. Navigation Design ist dann wichtig, wenn der Nutzer an bestimmte Plätze gehen will. Um eine optimale Wegfindung (Wayfinding) des Nutzers zu gewährleisten, muss die darunter liegende Informationsarchitektur gut ausgebaut sein – siehe Abschnitt 5.3. Interface Design ist immer dann gemeint, wenn es darum geht, etwas zu tun. Es hängt also mit den funktionalen Anforderungen und der Struktur des Interaktionsdesigns zusammen. Information Design spielt eine Rolle, wenn Ideen kommuniziert werden müssen. Da eine Webseite schwerpunktmäßig der Kommunikation dient, ist die Information entsprechend wichtig. Als umfassendster Bereich schließt er sowohl Aspekte des Navigationsdesigns (Informationsarchitektur) als auch die des Interface Design (Interaktionsdesign) ein.

Game UI Layout
Wie für das Web UI gelten auch für das Game UI bestimmte Elemente, die nur dort zu finden sein werden:

74

5 Konzept

• Ausführliche Hilfe / Informationen zur Tastaturnavigation – hier ist Tastaturnavigation zwingend im Gegensatz zum Web-Modus • Eingabefeld als Einstieg in die Tastaturwelt und als Gewöhnung (dient der Immersion) • Bestätigungsbutton für die Eingabe • Statistikbereich für Spielfortschritt, Fitness des Protagonisten, Anzahl der Bernsteinstücken, Anzahl der erreichten Punkte • Grafikausgabe-Bereich • Textfeld für die Textausgabe • Bereich für die Darstellung der Aktionen (Benutzen, Gucken, Reden) • Bereich für die Darstellung der Steuerung • Bereich für das Inventar

Abb. 37, Game UI

Look and Feel
Farben Farben sind wichtig. O überstrapaziert soll die Farbwahl nicht unangenehm ins Auge fallen. Es soll eine Wirkung aus »angenehm« und »modern« beim Betrachten der Farben entstehen. Weiterhin soll
75

5 Konzept

es besondere Farbakzente (Highlights) geben. Für den Hintergrund soll eine helle Farbe gewählt werden, die mit einer dunkleren Vordergrundfarbe einen ausreichenden Kontrast bietet. [Gar 03, S. 146] Die Farbwahl ist auch im Sinne der Accessibility zu gewährleisten. 97 Die Farbpaletten in Abbildung 38, 39 und 40 sind für Ambernstein interessant.

Abb. 38, Farbpalette »Accessible«

98

Abb. 39, Zweite Farbpalette »Accessible«

99

Abb. 40, Farbpalette eines Zeitungsartikels

Die in Abbildung 40 gezeigten Farben der Informationsgrafik eines Zeitungsartikels zur Höhlenmalerei 100 in der Steinzeit wurden mit Hilfe von PHOTOCOPA 101 herausgefiltert.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audiocontrast-contrast-techniques-head 05.10.2010
97 98 99

http://de-de.colourlovers.com/palette/1089601/Accessible 05.10.2010 http://de-de.colourlovers.com/palette/880191/Accessible 05.10.2010 Geheimnis Höhlenmalerei, von Manuela Peitz, Welt Kompakt, 16.08.2010 Eine Anwendung von http://colourlovers.com 76

100 101

5 Konzept

Genannte Farben wurden als Inspiration genommen und ließen eine Palette aus Beige-Tönen, Dunkel-Grau und mattem Blau entstehen – siehe Abbildung 41.

Abb. 41, Finale Farbpalette für den Web-Modus

Die Farbpalette dient der Konsistenz in der Wahrnehmung und der Wiederkennung. Teilweise werden für eine bessere und eindeutigere UX Farbnuancen der Palette verwandt, um z.B. Elemente zu betonen oder als aktiv zu kennzeichnen. Insofern dient die Palette als Übersicht von Richtwerten. Beispielsweise wird Grau in seinem Palettenwert #333 102 auch als #000, #444 103 und #666 in Erscheinung treten. Die oben genannte Farbpalette stellt die Standard-Farbpalette dar. Sie wird beim erstmaligen Begehen der Webseite zu sehen sein. Die Funktion des Wechselns des Farbschemas ändert die Farbpalette entsprechend radikal. Die finalen Farben der Abbildung 41 von links nach rechts sind: 1. Hintergrundfarbe 2. Hintergrundfarbe #2 3. Passive Hervorhebung 4. Aktive Textfarbe – als Kontrast zur Hintergrundfarbe 5. Aktive Text-Hintergrundfarbe – als Kontrast zur Textfarbe 6. Aktive Hervorhebung – als Kontrast zu den ersten drei Beige-Nuancen Für den Spiel-Modus sollte eine davon abgeleitete Palette erstellt werden. Sie ist in Abbildung 42 zu sehen.

Abb. 42, Finale Farbpalette für den Spiel-Modus
102 103

http://twitter.com/zeldman/status/11790694779 05.10.2010 http://twitter.com/H_FJ/statuses/11800719859 05.10.2010 77

5 Konzept

Die Farben sind wesentlich kräiger und intensiver. Das liegt daran, dass der Hintergrund diesmal dunkel ist. Dies generiert beim Spieler eine bessere Immersion ins Spiel und fokussiert (im Sinne der Accessibility) besser den in Weiß dargestellten Text. Die finalen Farben der Abbildung 42von links nach rechts sind: 1. Hintergrundfarbe 2. Hintergrundfarbe #2 3. Passive Hervorhebung 4. Aktive Textfarbe – als Kontrast zur Hintergrundfarbe 5. Aktive Textfarbe #2 6. Aktive Hervorhebung – als Kontrast zu den ersten beiden Grau-Nuancen Formen & Elemente Wie in den entsprechenden Layouts schon zu sehen war, sind die Formen überwiegend mit leichten Abrundungen versehen. Im Folgenden soll in Abbildung 43 und 44 ein genauerer Blick auf die möglichen Elemente und deren Form geworfen werden.

Abb. 43, Elemente des Spiel-Modus

Die Elemente des Spiel-Modus (Abbildung 43) enthalten abrundete »Container«-Bereiche 104 für Text, Grafik und sowie den Statistikbereich für Piktogramme (Icons), die in handgezeichneter Digitalversion ins Spiel eingebaut werden.

104

weil sie etwas aufbewahren, z.B. Text oder Grafik 78

5 Konzept

Abb. 44, Anordnung der Erklärung zur Steuerung im Spiel-Modus

In Abbildung 44 wird gezeigt wie die Darstellung der wichtigsten Tastaturkombinationen nach dem Betätigen der H-Taste für »Hilfe« aussehen kann. Die erste Darstellung ordnet sie um den Spielbereich herum an. Die zweite Darstellung hingegen überlagert den Spielbereich und dunkelt ihn mit einer Lightbox 105 ab.

5.4.2 Navigationsdesign
Navigation ist ein ganz bedeutender Bestandteil der Webseite. Es geht nicht nur darum, Links zu setzen, um den Nutzer von A nach B gehen zu lassen. Steve Krug formuliert Navigation als die Webseite selbst. Ohne sie gäbe es keine Webseite. [Kru 06, S.59] Garrett sieht drei Aufgaben, die das Navigationsdesign gleichzeitig erfüllen muss: [Gar 03, S.125f.] • von A nach B gelangen mit gezielter Platzierung von Links • Kommunikation der Beziehung von Links • Kommunikation der Beziehung der aktuellen Seite und dem darin enthaltenen Inhalt

105

eine Technik, den Inhaltsbereich einer Webseite komplett zu überlagen – z.B. bei Bildergalerien. 79

5 Konzept

Damit die vielfältigen Bedürfnisse des Besuchers erfüllt werden können, gibt es auch entsprechend viele Arten von Navigationssystemen – siehe Abbildung 45: [Pre 04] • Globale Navigation • Lokale Navigation • Hilfsnavigation (supplementary) • Inline-Navigation (contextual) • Gefälligkeits-Navigation (courtesy)

Abb. 45, Navigationssysteme

Das folgende Beispiel zeigt die IBM-Webseite 106 auf ihr Navigationsdesign hin untersucht – siehe Abbildung 46. [Pre 04]

106

http://www.ibm.com/ 80

5 Konzept

Abb. 46, Navigationssysteme am Beispiel von IBM

5.4.3 Informationsdesign
Wie bereits erfahren ist das Informationsdesign wesentlich für die Art der Darbietung von Information zuständig. Dies hat den Zweck, dass der Besucher sie einfacher nutzen und verstehen kann. [Gar 03, S.131] Das optimale Informationsdesign ist dann gefunden, wenn die gruppierten und arrangierten Informationselemente der Vorstellung und dem Denken vom Nutzer entsprechen. Optimales Informationsdesign unterstützt den Nutzer zielführend auf seinem Weg zur Erfüllung seiner Aufgabe und Ziele. [Gar 03, S.134]

Wayfinding
Im Navigationsdesign bereits angedeutet, spielt die Wegfindung auch im Informationsdesign eine wichtige Rolle. Es umfasst diejenigen Elemente, die nicht der Navigation dienen, z.B. durch die Nutzung von Farben, Piktogrammen, Beschriungen 107 und spezieller Typografie. [Gar 03, S.135] Gemäß Lynch muss das Informationsdesign verschiedene Merkmale des Wayfinding 108 berücksichtigen. [Lyn 09, 4.2] Dazu gehören: • Orientierung • Routenplanung
107 108

Labelling systems nach Kevin Lynch, The Image of the City (1960) 81

5 Konzept

• Kognitives Abbilden (mental mapping) • Abschluss Die »Orientierung« meint den aktuellen Standort. Die »Routenplanung« oder Routenentscheidung bezieht sich auf die Frage, ob man den Weg findet, nach dem man auf der Suche ist. Die sogenannte »mentale Karte« bezieht sich auf die bereits gesammelten Erfahrungen im Raum und die Prognosen der weiteren Wegfindung. Mit dem »Abschluss« ist gemeint, dass ein Ort erfolgreich gefunden wird.

5.4.4 Wireframes
Basierend auf dem Wissen über Informations-, Interface- und Navigationsdesign können die Layouts zu Web UI und Game UI nun als Wireframes weiterentwickelt werden. Es begann – wie beschrieben – mit der Idee eines konsistenten Grid-Layouts im Stil einer Tastatur.

Abb. 47, Frühes Wireframe des Web-Modus

Abb. 48, Frühes Wireframe des Spiel-Modus

In Abbildung 47 ist die Weiterentwicklung der UI des Web-Modus aus Abbildung 32 zu sehen. Es verdeutlicht umso mehr, dass kein Platz für Inhalte gegeben ist, weil die Navigation zu massiv Platz einnimmt. Abbildung 48 demonstriert den gleichen Stil wie Abbildung 47. Es zeigt, wie besagte UI-Konsistenz von Web UI und Game UI aussehen könnte. Die mittlere Ziffern-Navigation und die Return-Taste ist dem Inhalt des Spiels (in dem Fall das Cover des Spiels) gewichen. Die Leertaste diente in Web und Game UI universell als Funktionstaste, um den den Ton an- und auszuschalten. Auch die esc-Taste blieb erhalten, weil sie das Abbrechen bzw. Beenden einer Aktion bedeuten sollte. Im Web-Modus sollte ursprünglich mit dem zweifachen Drücken einer Zifferntaste sichergestellt werden, dass wirklich diese Taste gedrückt wurde und es kein Versehen war – im Sinne
82

5 Konzept

der Fehlerbehandlung aus Abschnitt 5.3. Die esc-Taste war im Spiel-Modus für das Beenden des Spiels und das Zurückgehen auf den Startbildschirm gedacht.

Abb. 49, Konzeptionelles Wireframe des Spiels-Modus

Das in Abbildung 48 gezeigte Wireframe 109 sah in seiner mit Balsamiq Mockups 110 erstellten UrVersion zunächst so aus wie Abbildung 49 illustriert.

5.5 Spieldesign
Zum Verständnis des Spieldesigns sind im Wesentlichen folgende Dokumente aus dem Anhang erforderlich: • Game Concept • Game Proposal • Designdokument – die »Spielbibel« • Technisches Designdokument
109 110

teilweise auch als Mock-Up bezeichnet, meint er einen frühen vorzeigbaren Prototypen http://www.balsamiq.com/products/mockups 05.10.2010 83

5 Konzept

Für die weitergehende Konzeption von Ambernstein wird empfohlen, ergänzend die Bachelorarbeit von Tommy Krüger hinzuzuziehen – Abschnitt 4 »Spielkonzeption«.

5.5.1 Elemente
Die wesentlichen Elemente des Gameplay (ludemes 111 ) sind [KOS 05, S.118ff.]: • Rewards • Preparation • A sense of space • A solid core mechanic • A range of challenges • A range of abilities required to solve the encounter • Skill required in using the abilities • A variable feedback system • e Mastery Problem must be dealt with • Failure must have a cost Weitere Paradigmen lauten: [KOS 05, S.70] • »Get to the other side« • »Visit every location« Die letzten beiden Elemente waren eine der ersten Best Practices für Spiele: In Pac-Man kam es darauf, die Spielfigur überall hinzubewegen, während man in Frogger auf die wortwörtliche andere Seite gelangen musste. Ambernstein übernimmt als Adventure-Spiel auf jeden Fall das Paradigma, jede Ecke der Welt zu erkunden. Das Abenteuer, das der Protagonist erlebt, könnte man im Ganzen als »Get to the other side« bezeichnen. Die ersten sieben Elemente von oben nach unten Weiterhin setzt Ambernstein Rewards ein, indem Bernsteinstücke (sogenannte »Ambies«) gesammelt werden. Die Preparation 112 passiert, indem der Protagonist – ohne zu viel zu verraten – von seinem Großvater versorgt wird.

111 112

nach Ben Cousins engl. Vorbereitung 84

5 Konzept

Der Sinn für den Raum wird durch die textuelle Beschreibung der Umgebung erreicht. Die Kernmechanik des Spiels lässt sich dadurch beschreiben, dass durch Tastaturnavigation und allgemein bekannte Minispiele eine durch Text beschriebene Welt erkundet wird. Die Menge an Herausforderungen ist gemäß Drehbuch recht vielfältig, wenn auch beschränkt auf die Tastaturnavigation und den Kontext der aktuellen Szene. Dadurch sind die Fähigkeiten zur Lösung und allgemein die Lösungsmöglichkeiten relativ beschränkt. Die Story soll diese beiden Lücken füllen. Von den genannten Elementen sind sieben von neun in Ambernstein vorhanden. Die Fähigkeiten zur Lösung einer Aufgabe können durch einen höheren Schwierigkeitsgrad in den Minispielen bedient werden. Die Lösungsmöglichkeiten sind durch den linearen Verlauf des Spiels nach wie vor nicht zu erweitern. Im besten Fall kann Ambernstein also acht von neun Elemente zufriedenstellend umsetzen. Die letzten drei Elemente von oben nach unten Um nun aus der Spiel-Erfahrung eine Lern-Erfahrung zu machen, muss ein variables FeedbackSystem verwendet werden – Ambernstein kommt zunächst mit statischem Feedback aus. Weiterhin muss das Mastery-Problem betrachtet werden: Erfahrene Spieler 113 dürfen nicht von Siegen über Anfänger oder von dem Erreichen von einfachen Zielen profitieren. Andersherum darf es Anfängern nicht unmöglich gemacht werden, das Ziel zu erreichen. Die Erfahrung des Spielers muss im Spiel – egal ob Single- oder Multi-Player – Auswirkungen haben. Genauso muss Misserfolg entsprechend kosten. Auch wenn Ambernstein das Mastery-Problem nicht berücksichtigt, werden zumindest Misserfolge klar gekennzeichnet. Das Drehbuch sieht hierfür vor, dass Misserfolge mit keiner Erhöhung der Punktezahl bestra wird – dies geschieht aber wiederum absehbar (weil dem linearen Verlauf des Drehbuchs folgend). Ambernstein als Lern-Erfahrung zu bezeichnen, wäre zu viel des Guten. Es zielt mit seiner Strategie klar auf kurzweilige Unterhaltung ab, die dem Gelegenheitsspieler gefallen soll.

113

Spieler mit einer hohen Levelzahl im Spiel 85

5 Konzept

5.5.2 Ein Spiel wie ein Film
Ambernstein ist durch seine Art als Text-Adventure nicht nur ein gespieltes Buch, sondern auch ein gespielter Film, denn es entsteht aus einem filmischen Drehbuch und wird getragen von einen offiziellen Soundtrack.

5.5.3 Kurzbeschreibung von Ambernstein
Ambernstein ist ein rein tastaturgesteuertes Spiel für den Web-Browser, das technisch auf HTML5, CSS3 und JavaScript basiert und besonderen Wert auf Web Usability und Accessibility legt. Die klassischen Text-Adventures der 1970er und 1980er Jahre zum Vorbild nehmend, spielt es etwas stärker grafisch orientiert in der fiktiven prähistorischen Steinzeit, in der Neandertaler und CroMagnon-Menschen parallel existierten (zw. 40.000 und 30.000 vor heute, im Jungpaläolithikum). Die Story nimmt eine tragende Rolle in Ambernstein ein. Deswegen wurde als Startpunkt die Verfassung der Story in Angriff genommen – laut Rouse III eine der drei validen Methoden, ein Spiel zu beginnen. [Rou 05, S.45ff.] Im Dokument »Ambernstein – Die Vision« des Anhangs finden sich weitere Ausführungen zum Spielverlauf.

5.5.4 Spielkonzept
Für die Erstellung des ersten Spielkonzepts wurde ein entsprechender Artikel von Tim Ryan [Rya 99a] hinzugezogen. Die dort herausgearbeiteten Informationen fanden ihren Weg ins Designdokument zum Spiel – siehe Anhang. Es besteht formell aus: • einer Einführung • Hintergrundinformationen • einer Beschreibung • wichtigen Spielmerkmalen • dem Genre • den Plattformen, für die es entwickelt wird • Konzeptstudien

5.5.5 Spielvorhaben
Auch für das Spielvorhaben (Proposal), das als Erweiterung des Spielkonzepts gilt, wurde [Rya 99a] zu Rate gezogen. Darüber hinaus war [Rya 99b] hilfreich. Das Proposal enthält im Wesentlichen:

86

5 Konzept

• ein überarbeitetes Konzept • eine Marktanalyse • eine technische Analyse • eine rechtliche Analyse • eine Kosten-/Nutzen-Rechnung • Artwork Der technische Teil fand vor allem seinen Platz im technischen Designdokument zum Spiel – siehe Anhang.

87

6
Umsetzung
Drehbuch, Webseite, Spiel.

88

6 Umsetzung

6.1 Herangehensweise
Wie auch in der Konzeptphase soll dieser Abschnitt das Drehbuch, die Webseite und das Spiel an sich beleuchten. Dem explorativen Denken folgend wurde sich dafür entschlossen, das Spiel aus der Sicht eines Entwicklers und aus der Sicht eines Konsumenten zu entwickeln, um die Unterschiede zu erkennen. Streng genommen gibt es noch die Sicht aus der geschälichen Perspektive. [Ung 09, S. 154]

6.1.1 Entwickler und Nutzer
Nach den Erfahrungen von Richard Rouse III [Rou 05, Kap.11] hinsichtlich einer »Designer‘s story« und einer »Gamer‘s story« und denen von Raph Koster [Kos 05, S.130, 138, 142], dass Menschen faul seien, Spieldesigner weniger spielen als Spieler und Spieler Spiele hacken 114 , war klar, das es offensichtlich eine Diskrepanz zwischen dem Produzenten und dem Konsumenten gibt. Aus empirischen Interesse lag es nahe, seitens der Entwickler beide Rollen zu besetzen und auszuleben. Tommy Krüger übernahm die Sicht des Entwicklers. Alexander Kluge übernahm die Sicht des Konsumenten, als »Advokat der Nutzer«. Da auch die Vision des geschälichen Interesses von Belang ist, übernahm Kluge auch zu Teilen die Sicht des Unternehmens und Projektmanagers. Dies sollte sich in den Ergebnissen, besonders bei der UX und dem UI widerspiegeln.

6.2 Drehbuch
Die Ausführungen zur Umsetzung des Drehbuchs zeigen nicht den vollen Inhaltsumfang, um nicht zu viel von der Story zu offenbaren und die esis nicht als Spoiler 115 zu positionieren. Die Umsetzung des Drehbuchs geschah viel in Papierform – siehe Abbildung 50.

Abb. 50, Etappen der Akte auf Zetteln

114 115

dem Spiel einen neuen »Sinn« geben, der nicht in der Absicht des Entwicklers lag eine vor der Veröffentlichung einer Sache offenbarte Information, die deren Konsum verderben kann 89

6 Umsetzung

Abbildung 50 zeigt, dass für jeden Akt eine Menge aus 14 Zetteln angefertigt wurde, die die jeweils wichtigsten Stationen im Akt in wenigen Worten zusammenfasst. Für den zweiten Akt wurde wegen der doppelten Länge zweimal 14 Zettel beschrieben. Dem Strukturmodell von Syd Field folgend wurde die Story in mehreren Schritten in drei Akte aufgebaut (Abbildung 51).

Abb. 51, Strukturmodell des Drehbuchs nach Syd Field

Abb. 52, Verlauf der Story in sechs Etappen

90

6 Umsetzung

Darauf folgte der grobe Verlauf der Story, der in Abbildung 52 zu sehen ist. Es wird darauf hingewiesen, dass das Wissen um die Etappen der Story in Ambernstein den Spielspaß eindämmen kann. Insofern wird geraten, die Abbildung nicht zu lange zu betrachten bzw. sie vor dem Spielen nicht zurück ins Gedächtnis zu holen. Basierend auf diesem Verlauf entstand der Pfad für den ersten Akt, der in Abbildung 53 ausschnittsweise dargestellt wird.

Abb. 53, Pfad des ersten Akts (Ausschnitt)

Ohne den intensiven (mehrwöchigen) Schöpfungsprozess des Drehbuchschreibens zu sehr vertiefen zu wollen, sollen die Inhalte der drei Akte und allgemeine Struktur zusammengefasst werden. Für das Schaffen der Akte war Fields Paradigma sehr dienlich, da es half, die Dramaturgie aufzubauen – also die »lineare Verbindung von [...] Ereignissen, die zusammenhängen und zu einer dramatischen Auflösung führen.« [Fie 98, S.48]

6.2.1 Erster Akt
Der erste Akt etabliert die Geschichte, führt die Hauptfiguren ein und macht ihre dramatischen Absichten klar. Sie ist Grundstein für die folgenden Szenen und Sequenzen. Alles geschieht im dramatischen Kontext des Setup. [Fie 98, S.40f.]

91

6 Umsetzung

6.2.2 Zweiter Akt
Nachdem der erste Akt mit dem ersten Plot Point 116 endet, wird der etwa doppelt so lange zweite Akt eingeführt. Geprägt vom dramatischen Kontext der Konfrontation reicht er bis zum zweiten Plot Point, wo erneut eine Wendung zu erwarten ist. Hier finden sich Hindernisse, Konflikte und Konfrontationen, die bewältigt werden müssen. [Fie 98, S.43f.]

6.2.3 Dritter Akt
Nach der Wendung durch den zweiten Plot Point, findet die Auflösung der Story – als dramatischer Kontext – im dritten Akt statt. [Fie 98, S.47]

6.3 Webseite
Um den Kern einer Webseite zu erfassen, definiert man sie als UI – also eine Schnittstelle, die mit einem Nutzer (Menschen) interagiert. Die Arbeit am UI basiert auf Vorgaben in der Literatur, User-Testing, praxiserprobten Guidelines und sogenannten Best Practices. [Lyn 09, 2.5] Best Practices finden sich z.B. bei der Firma Isobar 117 . Als sehr hilfreiche Literatur erwies sich –  neben erwähnter anderer Literatur – auch der Web Style Guide [Lyn 09] von Patrick J. Lynch und Sarah Horton.

6.3.1 Technisch
Für die Umsetzung von Ambernstein wird unter Windows und Mac OSX entwickelt. Dabei kam TextMate 118 (Mac) und Aptana Studio119 (Windows) zur Anwendung. Da die Entwicklung vorrangig in HTML5 und CSS3 entstand, wurden entsprechend fähige Browser
120

für die Arbeit benutzt, die diese Technologien gut unterstützen:

• Chrome 5 • Safari 5

116 117 118 119 120

Ein Ereignis, das die Handlung vorantreibt, eingreift und ggf. dreht. http://molecularvoices.molecular.com/standards/ 05.10.2010 http://macromates.com/ 05.10.2010 http://www.aptana.com/ 05.10.2010 http://html5readiness.com/ 05.10.2010 92

6 Umsetzung

Interessant ist dabei, dass beide Browsern auf WebKit 121 basieren.

HTML5 Boilerplate
Als Startpunkt für die UI-Entwicklung diente HTML5 Boilerplate. Dieses u.a. von Paul Irish veröffentlichte Template, dient als Kick-Start eines jeden HTML5-Projekts. Seine Vorteile sind: • Browserübergreifende Kompatibilität (inkl. Internet Explorer 6) • IE-spezifische Klassen, um separate Stylesheet-Dateien zu vermeiden Außerdem enthält es: • eine HTML5-Erweiterung 122 des CSS Resets 123 von Eric Meyer • Modernizr 124 Modernizr dient der Erkennung von HTML5-Elementen und deren Aktivierung. CSS Resets setzen die Standardinterpretationen der Browser zurück. Das ist nötig, weil Browser das CSS unterschiedlich interpretieren und entsprechend ausgeben. Mit CSS Resets können CSSDefinitionen auf einer gemeinsamen Basis geschehen.

Alternativen
Alternativ zu HTML5 Boilerplate ist auch möglich, HTML5 Reset 125 einzusetzen. Es hat einen ähnlichen Ansatz und setzt auch auf ähnliche Best Practices. Es ist Geschmacksache. Für Ambernstein empfahl sich HTML5 Boilerplate, weil der Einstieg per Video einfacher war.

jQuery
Wesentlich für die Entwicklung ist auch jQuery – ein Javascript-Framework, dass eine gute BrowserUnterstützung bietet und kürzeren Code benötigt als natives JavaScript. Weitere Soware und technische Belange für Ambernstein sind Tommy Krügers esis im Abschnitt »Umsetzung« zu entnehmen.

121 122 123 124 125

http://webkit.org/ 05.10.2010 http://html5doctor.com/html-5-reset-stylesheet/ 05.10.2010 http://meyerweb.com/eric/tools/css/reset/ 05.10.2010 http://www.modernizr.com/ 05.10.2010 http://html5reset.org/ 05.10.2010 93

6 Umsetzung

6.3.2 Visuelles Design
Die Weiterentwicklung des Konzepts für den Web-Modus ist in Abbildung 54 zu sehen.

Abb. 54, Visuelles Design der Webseite

Wie in Abbildung 54 zu sehen, wurde für Ambernstein eine Auswahl von vier Prinzipien der Gestalt-Psychologie verwandt. [Lyn09, 7.4] Konkret lauten diese: • Proximity • Similarity • Continuity • Uniform connectedness

Die Gestalt-Prinzipien bei Ambernstein
»Proximity« meint, dass Elemente, die nahe beieinander liegen, auch miteinander in Relation stehen. In Ambernstein sind dies von oben nach unten: • der Bereich »Ansicht wechseln« • der Hinweis »Navigiere per Tastatur« • die Überschri samt Beschreibung

94

6 Umsetzung

• die bezifferten Navigationsflächen • der Bereich für die Änderung von Textgröße und Farbschema

Abb. 55, Die Gestalt-Prinzipien der Nähe, Ähnlichkeit und Kontinuität

Die »Similarity« wird besonders bei den bezifferten Navigationsflächen deutlich. Durch den starken Kontrast von weißer Hintergrundfarbe und dunkelgrauem Text wird Gleichheit dieser Elemente sofort deutlich. Die »Continuity« ist in Ambernstein nur indirekt berücksichtigt worden. Gemeint ist der Hintergrund, der als Grid [Gar 03, S.148] den dunkleren Hintergrund ausmacht. Die dortigen Gitterlinien sind streng genommen allerdings nicht – wie gefordert – kontinuierlich. Da das Gitter nicht primär – wenn überhaupt – aktiv wahrgenommen wird, scheint ein Befolgen dieses Prinzips für Ambernstein nicht allzu große Konsequenzen zu haben. Das Prinzip der »Uniform connectedness« meint Elemente, die von anderen Elementen eingeschlossen werden. In Ambernstein ist dies bei den bezifferten Navigationsflächen zu sehen. Die Fläche »Spiel starten – 1« umschließt mit seiner Länge bzw. Breite die darunter liegenden in Dreiergruppen angeordneten uniformen Elemente. Abbildung 55 fasst die ersten drei Prinzipien grafisch zusammen. In Abbildung 56 wird das vierte Prinzip schematisch illustriert und wie in Abbildung 55 mit einer kurzen Erklärung versehen.

95

6 Umsetzung

Abb. 56, Das Gestalt-Prinzip der »uniformen Verbundenheit«

6.4 Spiel
6.4.1 Technisch
Für die technische Umsetzung des Spiels soll auf Abschnitt 5 »Umsetzung« der Arbeit von Tommy Krüger verwiesen werden. Dort wird die Umsetzung des Text-Parsers, sowie die der Mini-Spiele so detailliert wie nötig erklärt. Unter anderem wird auf die Umsetzung von Sokoban und dem Bilderrätsel Rebus eingegangen. Darüber hinaus wird die Ajax-Architektur und die Verwendung von PHP erläutert.

6.4.2 Visuelles Design
Das  visuelle  Design  für  den  Spiel-­‐Modus  ist  angelehnt  an  den  Web-­‐Modus.  Abbildung  57  zeigt  den   aktuellen  Stand  des  Prototypen  in  einem  einfachen  Farbschema.  Die  für  das  Spiel  gedachte   FarbpaleDe  findet  in  späteren  Versionen,  die  außeruniversitär  entwickelt  werden,   BerücksichLgung.  In  der  Abbildung  soll  zu  erkennen  sein,  dass  der  KopOereich  ganz  oben   schlanker  geworden  ist  und  den  Titel  »Ambernstein«  in  anderer  Form  darstellt  als  zuvor.  Zum   Zwecke  des  Spielerlebnisses  und  des  Wechsels  von  InformaLons-­‐  in  Spiel-­‐Modus  soll  der  SchriTzug   ganz  klar  zeigen,  in  welchem  Bereich  (Modus)  von  Ambernstein  man  sich  gerade  befindet. Die  in  den  vorigen  AbschniDen  angesprochene  Verbindung  von  Game  UI  und  Web  UI  wird  in   Abbildung  58  dargestellt.  Die  Verbindung  baut  sich  dadurch  auf,  dass  sonst  passive  Elemente  der   Webseite  eine  FunkLon  bekommen,  also:  Header  126,  Hintergrund  und  Footer   127.  Die  Abbildung  
126 127

Kopfbereich einer Webseite ganz oben Fußbereich einer Webseite ganz unten 96

6 Umsetzung

illustriert,  dass  je  nach  geografischem  Ort  und  besonderer  SituaLon  des  Protagonisten  in  der  Story   sich  besagte  Elemente  einfärben.

Abb. 57, Visuelles Design des Spiels

Abb. 58, Visuelle Verbindung von Game UI und Web UI

97

6 Umsetzung

Die für die Abbildung 58 verwendete Farbpalette nennt sich »Gentle Waves« 128 . Sie ist in Abbildung 59 dargestellt und steht optisch für die Flusslandscha in der Story.

Abb. 59, Farbpalette »Gentle Waves«

In Abbildung 60 ist der Fortschritt das Spiels zu sehen. Anhang von zu den sechs Subwelten passenden Icons wird dem Spieler gezeigt, wie weit er im Spiel ist. Dies dient als Hilfsmittel der Orientierung in zeitlicher Hinsicht und als Motivation, weiterzuspielen.

Abb. 60, Visueller Fortschritt im Footer

6.5 Angewandte Datenstruktur
Die angewandte Datei- und Ordnerstruktur ist relativ einfach gehalten und hält sich in ihren Grundzügen an die Architektur, die im Konzeptteil der esis festgehalten wurde – siehe Abbildung 61.

128

http://de-de.colourlovers.com/palette/475875/Gentle_Waves 05.10.2010 98

6 Umsetzung

Abb. 61, Datenstruktur

In der esis von Tommy Krüger ist im Abschnitt »Umsetzung« die Struktur ebenfalls erwähnt. Er geht dabei auf die Struktur, die sich im Ordner »game« der Abbildung 61 befindet, ein.

6.6 Eingesetzte Software
In diesem sechsten Abschnitt der esis wurden genutzte Soware und Frameworks bereits erwähnt. Tommy Krüger geht in seiner theoretischen Arbeit im Abschnitt 5.4 »Verwendete Programmiersprachen und Bibliotheken« noch genauer auf den XML-Parser, das Format XML und die Verbindung mit JavaScript ein.

6.7 Nicht umgesetzte Funktionen
Ziel dieser theoretischen Arbeit mit begleitendem Praxisprojekt war es, einen explorativen Prototypen zu erstellen, der als Proof-of-Concept dient. Dementsprechend sind die für das theoretische Verständnis des Spiels nötigen Funktionen und Inhalte umgesetzt worden. Dennoch soll zunächst gezeigt werden, was im Rahmen der Bachelorarbeit erarbeitet wurde. Umgesetzt wurden: • ein Drehbuch, das der halben Länge eines Kinofilms entspricht • inklusive Soundtrack • ein Strategiedokument mit der internen Vision des Spiels, sowie den Nutzerzielen • inklusive einer Visual Identity • ein Designdokument für das Spiel • ein UI für den Web-Modus, das in einem iterativen Prozess mit begleitenden Usability-Tests entwickelt wurde • erste Entwürfe für das UI des Spiel-Modus Was nicht umgesetzt wurde, ist in Tommy Krügers esis – Abschnitt 5.7 – nachzulesen.

99

6 Umsetzung

6.8 Probleme und Herausforderungen
Es bestand vor allem die Schwierigkeit, zu klären, ob wir ein Spiel oder eine Webseite bauen. Da wir vorrangig von einem Browser-Spiel sprachen, einigten wir uns darauf, dass wir ein Spiel bauen, dass eben im Kontext einer Webseite funktioniert. Webseiten und Spiele sind i.d.R. verschieden. Andersherum betrachtet könnte man allerdings sagen, dass Webseiten immer mehr zu WebApplikationen werden und somit der Grad der Interaktivität – sprich die Domäne der Spiele – steigt. Insofern ist die Zielsetzung küniger Webseiten interaktive Erfahrungen – wie in Spielen – auf Webseiten zu generieren. Das Spiel wir zur Webseite, die Webseite zum Spiel. Außerdem kamen die folgenden Fragen auf: • Was passiert mit dem Spielstand, wenn der Spieler die Seite neu lädt? • Was passiert, wenn JavaScript deaktiviert ist?

6.7.1 Lösungen für das Neuladen der Webseite
Um den Spielstand des Spiels nicht zu verlieren, könnte man per Cookie die nötigen Informationen speichern. Diese würden dann dauerha oder bis zum Time-Out auf dem Rechner des Nutzers liegen. Alternative wäre die Anbindung an eine Datenbank denkbar, indem der aktuelle Stand der IP-Adresse des Spielers gespeichert wird – dies wäre noch zeitsensitiver als die Lösung per Cookie, weil sich die IP i.d.R. beim Normalverbraucher mit jeder neuen Verbindung zum Internet dynamisch (DHCP) ändert. Es könnte außerdem über ein System zur Nutzerverwaltung nachgedacht werden. Dabei würde ein Spieler sich per Nutzername und Passwort anmelden und könnte am gewünschten Spielstand weiterspielen. Angesichts der Kürze der Spielzeit, müsste über den Sinn eines solchen Systems nachgedacht werden. Nicht jeder Spieler möchte sich für das Spielen eines Text-Adventures anmelden. Demnach wäre die Lösung ein optionales Login: Wer seinen Spielstand speichern möchte, hinterlegt seine Daten. Wer das Spiel in einer Sitzung durchspielt oder beim nächsten Besuch der Webseite von vorne beginnen möchte, ignoriert diese Option. Die zuvor beschriebenen Lösungen funktionieren serverseitig bzw. mit einer Mischung aus serverseitiger (PHP) und clientseitiger (Cookie) Funktion. Die Alternative wäre die rein clientseitige Lösung, das Neuladen-Funktion eines Browsers z.B. per F5 zu verhindern. Dies funktioniert mit nur wenigen Zeilen JavaScript 129 und ist ein geringer, wenn auch nicht unumstrittener, Aufwand.
http://stackoverflow.com/questions/3527041/prevent-any-form-of-page-refresh-using-jquery-javascript 06.10.2010
129

100

6 Umsetzung

6.7.2 Lösungen für deaktiviertes JavaScript
Da laut W3C-Vorgabe Ambernstein auch ohne aktiviertes JavaScript (CSJS) gespielt werden sollte, werden sich nun Ansätze überlegt, diese Anforderung zu erfüllen. Da das Spiel von Eingaben, die per JavaScript empfangen werden, abhängt, müsste man auf native Mittel wie den Tab-Index setzen. Ein flüssiges Gameplay wäre dann aber nicht mehr garantiert. Wie im Fazit der Analyse bereits erwähnt, läu ohne CSJS nichts in Ambernstein so wie es von den Entwicklern gewollt ist. Statt sich mit diesem Umstand abzufinden, sollen denkbare Lösungen für das Problem betrachtet werden. Das ist zum einen Server-side JavaScript (SSJS) wie z.B. CommonJS 130 oder zum anderen eine PHP-basierte Lösung. In beiden Lösungen ist ohne aktiviertes CSJS der Tab-Index oder die browser-spezifische Tastenkombination für den Accesskey nötig – z.B. unter Mac OSX im SafariBrowser per Tastenkombination von Ctrl, Alt und der Ziffer des Accesskeys. Die Tabelle 7 fasst denkbare Lösungsansätze zusammen.
Lösung Spiel-Engine mit PHP serverseitig implementieren Anmerkung Eingaben im Browser durch den Spieler müssen durch JavaScript passieren Fazit +/– Inhaltsdarbietung möglich / Interaktion nicht – Verstößt gegen die selbst auferlegte Vorgabe, native Browser-Technologien zu nutzen – Löst das Problem nicht Spiel-Engine mit SSJS serverseitig implementieren Eingaben im Browser durch den Spieler müssen durch JavaScript passieren + Berücksichtigt die selbst auferlegte Vorgabe, native Browser-Technologien zu nutzen +/– Inhaltsdarbietung möglich / Interaktion nicht +/– Unterstützung durch den Web Server muss gewährleistet sein – Löst das Problem nicht Spiel-Engine serverseitig implementiert und -Eingaben serverseitig gesteuert (ferngesteuert) Eingaben geschehen nicht im Browser durch den Spieler – Keine Interaktions-Möglichkeit durch den Spieler – Spieler entmündigt und evtl. frustriert – Spiel ist wie ein autarker selbstablaufender Film Tab. 7, Lösungen für deaktiviertes JavaScript
130

http://www.commonjs.org/ 101

7
Test
Heuristiken, Usability, Browser.

102

7 Test

7.1 Herangehensweise
Zum Test der Webseite wurden Usability-Tests durchgeführt, bei dem vier 131 Testpersonen ihre Gedanken und Handeln laut aussprechen sollten (inking Aloud). Vor dem eigentlichen Test wurde per Card-Sorting – eine der möglichen benutzerorientierten Methoden [Har 00, S.62] – herausgefunden, wie die Anordnung der Navigation am Intuitivsten ist. Basierend auf diesen Erkenntnisse wurden vier 132 Personas erstellt, die für eine bestimmte Nutzergruppe stehen. Das USGesundheitsministeriums (HHS) stellt auf seiner Webseite noch weitere Methoden 133 vor. Einen guten Einstieg in die Usability liefert auch der »Arbeitsbereich Usability Engineering« der Universität des Saarlandes. 134 Die Testkandidaten waren 24 und 25 sowie 49 und 50 Jahre alt – ein weiblicher Kandidat und drei männliche Kandidaten. Die Testumgebung für den Usability-Test war Mac OSX 10.6.4, Safari Browser in der Version 5.0.2, so wie ein Browser-Viewport von 934 x 720 Pixel.

7.2 Testauswahl
Im Folgenden sollen mögliche Tests gezeigt werden, die für Ambernstein relevant sind und in Zukun werden. Für die spätere Durchführung der Tests wurde nur ein Teil der hier vorgestellten Auswahl berücksichtigt, da der zeitliche Aufwand sonst zu groß gewesen wäre.

7.2.1 Browser-Tests
Browser-Tests finden mit den Web-Browsern statt, auf denen später die Webseite dargestellt werden soll. Dabei richtet man sich nach aktuellen Nutzungstrends und unterstützten Technologien im Browser selbst.

Screenreader
Eine ganz besondere Form des Browser ist der Screenreader 135 . Er spricht den Inhalt der Webseite aus, um Menschen mit Sichteinschränkungen des Surfen im Web zu ermöglichen. [Mcb 10, HTML Presentation]

131 132 133 134 135

Nielsen empfiehlt fünf Testpersonen [Nie 00] Shneidermann empfiehlt drei bis Personas [Shn 03a, S. 8] http://usability.gov/methods/index.html 05.10.2010 http://usability.is.uni-sb.de/ 05.10.2010 engl. Bildschirmleseprogramm 103

7 Test

7.2.2 Usability-Tests
Zur Auswertung der Usability unterscheidet man zwei grundsätzliche Verfahren: expertenzentrierte Methoden (z.B. Heuristische Evaluation) und nutzerzentrierte Methoden (z.B. Usability Testing mit lautem Denken) [Har 00, S.62]

Thinking Aloud
Lautes Denken meint während der Testphase, dass jedes Handeln und Denken laut ausgesprochen wird. [Har 00, S.63] In der späteren Durchführung dieser Methode erwies sie sich als sehr brauchbar und praxistauglich.

Task-Analysis
Task-Analysis meint, dass jede Interaktion vom Nutzer mit der Webseite in dem Kontext einer Aufgabe geschieht. Bei dieser Analyse werden die Schritte dokumentiert, die für das Lösen der Aufgaben nötig waren. Dabei hält man Interviews oder beobachtet den Nutzer in seiner »gewohnten Umgebung«. [Gar 03, S.52] Diese Methode ist stark verbunden mit dem sogenannten Contextual Inquiry, das eine Menge von Vorgehen beinhaltet, um Menschen im Kontext des alltäglichen Lebens zu verstehen. [Ung 09, S.92]

Card-Sorting
Beim Card-Sorting werden Testpersonen gebeten, mit bestimmten Titeln beschriete Zettel so zu sortieren, dass sie für die Person einen Sinn ergeben. [Ung 09, S.93]

Personas
Personas sind Dokumente, die typische Nutzer der Zielgruppe beschreiben. [Ung 09, S.113] In der Regel umfassen diese Dokumente Namen, Alter, Job, Ort, eine kurze Biographie sowie ein charakteristisches Zitat. [Lyn 09, 2.5]

Eye-Tracking
Eye-Tracking 136 gilt als eine der einfachsten Usability-Tests, weil es naheliegt, dem Auge zu »folgen«, um dadurch herauszufinden, wo die größte Aufmerksamkeit beim Nutzen der Webseite liegt. [Gar 03, S.144]

136

http://www.useit.com/eyetracking/ 06.10.2010 104

7 Test

7.2.3 Benutzerbefragung
Neben Interviews und Umfragen [Ung 09, S.92] gibt es den System Usability Scale (SUS), der mit Hilfe eines Fragebogens die Usability von Systemen bewertet. [Mei 10]

7.2.4 »Quick-Experience«
Die Verbesserung der Usability ist auch von wirtschalichem Interesse. Insofern verwundert es nicht, dass es Firmen wie eparo 137 gibt, die Kunden der freien Marktwirtscha Usability-Tests anbieten. Sie nennen ihren Test »Quick Experience«. Vor allem die einfache und schnelle Integration dieser Methode in laufende Prozesse des Unternehmen wird u.a. als Vorteil herausgestellt.

7.2.5 Forschungsbasierte Richtlinien
Forschungsbasierte Richtlinien können zum Testen der Usability eingesetzt werden, im besten Fall als Ergänzung zu speziellen Tests der Zielgruppe. Hierzu sind die Richtlinien des USGesundheitsministeriums (HHS) empfehlenswert. [Shn 03a] Sie werden auch von Steve Krug explizit empfohlen. [Kru 06, S.191]

7.2.6 Best Practices
Erfahrungswerte und tatsächliche Umsetzungen anderer Menschen und Unternehmen des Umfelds sind auch sehr gut geeignet, um diese für seinen eigenen Projekte oder Kunden anzuwenden. Die Firma Isobar (vormals Molecular) hat ihre de-facto Code-Standards 138 veröffentlicht, um vor allem die Teamarbeit zu erleichtern und eine »gleiche Sprache» beim Schreiben von Quell-Code zu sprechen. Weniger auf Code abzielend, hat Sarah Horton [Hor 05] eine Anleitung zu Universal Usability erstellt, die sich ähnlich anschaulich darstellt wie Lynch [Lyn 09]. Als Einstieg in Usability und Accessibility ist diese Literatur sehr ratsam und empfehlenswert. Bezüglich der Accessibility gibt es außerdem die von Mark Pilgrim verfasste Anleitung Dive Into Accessibility 139 (2002) , welche verspricht in 30 Tagen eine Webseite mit höherer Zugänglichkeit zu haben.

137 138 139

http://www.eparo.de/services#usabilitytests 06.10.2010 http://molecularvoices.molecular.com/standards/ 06.10.2010 http://diveintoaccessibility.org/ 06.10.2010 105

7 Test

7.2.7 Heuristiken
Jakob Nielsen formulierte 2005 zehn Heuristiken, die für die Gebrauchstauglichkeit eines UI wichtig sind: [Nie 05] 1. Visibility of system status 2. Match between system and the real world 3. User control and freedom 4. Consistency and standards 5. Error prevention 6. Recognition rather than recall 7. Flexibility and efficiency of use 8. Aesthetic and minimalist design 9. Help users recognize, diagnose, and recover from errors 10. Help and documentation Anhand dieser Daumenregeln kann die bisherige Usability analysiert werden. Zum Nachlesen über Usability-Heuristiken eignet sich Jens Meierts Blogeintrag 140 sowie [Dan 01].

Spiel-Heuristiken
Melissa A. Federoff stellt in ihrer Studie [Fed 02] recherchierte Heuristiken und UsabilityRichtlinien zur Erstellung und Auswertung von Spaß in Videospielen zusammen und beru sich dabei auch auf die zehn Heuristiken von Nielsen. [Fed 02, S. 16ff.] Für Ambernstein sind diese während und nach der Entwicklung interessant und relevant. Die drei Bereiche, die man hinsichtlich der Game Usability verbessern kann, lauten: [Fed 02, S. 10f.] • Game Interface • Game Mechanics • Game Play Besagte Heuristiken sollen nun in Bezug die drei Bereiche auszugsweise aufgeführt werden: [Fed 02, S. 41ff.]

Bereich Game Interface
140

Heuristiken intuitiv, Konsistenz in visueller Erscheinung, minimale Menüs

http://meiert.com/de/publications/articles/20051218/ 05.10.2010 106

7 Test Bereich Game Mechanics Game Play Heuristiken natürlich, schnelles und einfaches Involvieren ins Spiel »easy to learn, hard to master« Nolan Bushnell Tab. 8 – Heuristiken für Game Usability (Auswahl)

Bezüglich des Gameplay sind Parallelen zu den Elementen in Abschnitt 5.5.1 dieser esis festzustellen.

Alternative Test-Methoden
• FiveSecondTest 141 • »Silverback« 142 • Eye-Tracking • AttrakDiff 143

7.3 Durchführung
7.3.1 Card-Sorting
Die Testpersonen wurden gebeten, sieben ungeordnete Zettel 144 so anzuordnen, wie es ihnen intuitiv erschien. Ihnen war das ema, das Spiel und der Name des Spiels nicht bekannt. Für CardSorting empfiehlt Nielsen zwar mehr als fünf Nutzer [Nie 04] – für den Anteil der Testteils an dieser Arbeit wurden vier Tester allerdings als genug Aufwand angesehen.

Ergebnisse
25 J. männlich 24 J. männlich 49 J. männlich 50 J. weiblich Ambernstein, Beteiligte, Motivation, Theorie lesen, Hintergrund, Spiel starten, Mission Motivation, Theorie lesen, Hintergrund, Spiel starten, Beteiligte, Ambernstein, Mission Mission, Beteiligte, Theorie lesen, Motivation, Ambernstein, Hintergrund, Spiel starten Ambernstein, Hintergrund, Motivation, Mission, Beteiligte, Theorie lesen, Spiel starten Tab. 9, Ergebnisse des Usability-Tests

141 142 143 144

http://fivesecondtest.com/ 05.10.2010 http://silverbackapp.com/ 05.10.2010 http://www.attrakdiff.de/ 05.10.2010 alternativ auch per Web-Software – http://websort.net/ 05.10.2010 107

7 Test

Fazit
Fasst man die Ergebnisse nun zusammen, könnte die Reihenfolge als Kompromiss so aussehen: 1. Ambernstein 2. Beteiligte 3. Motivation 4. Mission 5. eorie lesen 6. Hintergrund 7. Spiel starten

7.3.2 Card-Sorting #2
Für zwei der Kandidaten wurde der Test wiederholt. Sie wussten nach dem Usability-Test nun über das Spiel Bescheid. Zwischen den einzelnen Test lagen jeweils einige Tage, um die Erinnerung schwach zu halten.

Ergebnisse
#1: 49 J. männlich #2: 50 J. weiblich Ambernstein, Spiel starten, Beteiligte, Mission, Motivation, Hintergrund, Theorie dahinter Ambernstein, Theorie dahinter, Hintergrund, Motivation, Mission, Beteiligte, Spiel starten Tab. 10, Ergebnisse des Card-Sorting

Fazit
Es ist wie beim ersten Card-Sorting schwierig, einen Kompromiss zu finden, weil Kandidat #1 bis auf die erste Position genau entgegensetzt zu Kandidat #2 die Reihenfolge als intuitiv sieht. Sie beginnen beide »Ambernstein«.

7.3.3 Web Usability
Nach ISO-Definition gelten für Web Usability momentan drei Eigenschaen: • Effektivität • Effizienz • Zufriedenheit

108

7 Test

Zunächst sollte die Webseite, auf der man sich über Ambernstein informieren kann, auf ihre Usability getestet werden. Den Testpersonen wurde gesagt, dass sie laut sagen sollen, was sie denken, sehen und was sie intuitiv machen würden und es machen. Es wurde so vorgegangen, dass die Person – nach persönlicher Befragung der Person und Einschätzung des Testers – mit der geringsten Erfahrung von der Bedienung des Computers und des Webs zuerst getestet wurde. Dass es ein Test sei, wurde ihr nicht ausdrücklich zu verstehen gegeben. Weitere Information zu den Ergebnissen dieses Tests sind im Anhang zu finden. Im Folgenden sollen nur kurze Zusammenfassungen gegeben werden.

#1: 50 J. weiblich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person nicht bekannt.

Abb. 62, Webseite für Testperson #1

Die Testperson bekam die in Abbildung 62 dargestellte Version der Webseite zu sehen. Bei der Person gab es vor allem Probleme bei der Wahl der richtigen Tasten, z.B. hielt sie die Leertaste für die Tab-Taste. Nach einem Hinweis des Testers, wurden die Tasten aber erkannt. Die Gesamtwirkung der Webseite empfand die Person als seriös und wie »Urlaub« aussehend. Das selbst gezeichnete Eye-Tracking der Testperson verlief ideal!

109

7 Test

#2: 24 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person bekannt.

Abb. 63, Webseite für Testperson #2, #3 und #4

Die folgenden drei Testpersonen bekamen die in Abbildung 63 dargestellte Version der Webseite zu sehen. Auch bei dieser Person gab es Probleme beim Erkennen der richtigen Tasten, vor allem »Ctrl« und »Shi«. Insgesamt empfand die Person die Webseite als gefällig was die Farben anging. Er hat verstanden was es mit Ambernstein auf sich hat – mit dem Begriff konnte er zuvor beim CardSorting nichts anfangen. Interessant war, dass die Person erkannte, dass der dunkle Bereich für das Spiel reserviert war. Das gezeichnete Eye-Tracking verlief beinahe ideal – die Person las allerdings von oben nach unten, statt zu scannen. 145

#3: 25 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person nicht bekannt. Die Testperson zeigte erneut Schwächen beim Erkennen der Tab- und Shi-Taste. Die Webseite gefiel ihr insgesamt nicht so gut. Sie empfand sie als »langweilig«, weil sie nicht wusste, was sie dort machen könne. Es war zu viel Text dargestellt, der sie laut eigener Aussage »nervte«. Allerdings erkannte sie, dass es ein Spiel ist und kam dann auch mit der Tab-Navigation zurecht. Das EyeTracking verlief ähnlich wie bei Testperson #3 – den eigenen Augenverlauf zeichnete sie allerdings auf einer zeitlichen Achse. Außerdem scannte die Person – im Gegensatz zu Person #3 – die
145

http://www.useit.com/alertbox/9710a.html 06.10.2010 110

7 Test

Webseite, ohne auf den Inhalt zu achten. Das Ergebnis aus diesem Test war eins der Wichtigsten, weil sie guten Aufschluss über das Denken und Verhalten der Zielgruppe gab.

#4: 50 J. männlich
Vorbemerkung: Die Steuerung per Tastatur auf Webseiten war der Person bekannt. Die Tab-Taste war der Person klar, die Shi-Taste allerdings nicht. Insgesamt war für die Testperson auch nach längerem Betrachten der Webseite das Fazit »unbekanntes Objekt«. Dennoch bekundete er explizit Interesse für das was dahinterstecken möge – ohne inking Aloud wäre diese Information verborgen geblieben. Die Webseite sprach ihn insgesamt »normal« an. Das EyeTracking sah auf der Zeichnung der Testperson wie ein Schneckenhaus aus.

Abb. 64, Anpassung der Webseite mit Feedback von Testperson #1

Maßnahmen
Nach den Erfahrungen der Tests und den ersten Anpassungen nach dem Ergebnis von Person #1, sollten nun weitere Anpassungen an das UI stattfinden. Die Auswertung der ersten Anpassung fand wiederum mit Person #1 statt. Sie gab ihr Feedback, was die Basis für die weitere Feinabstimmung bildetet. In Abbildung 64 und 65 ist die herausgearbeitete Version der Webseite zu sehen. Testperson #1, #2 und #4 äußerten sich dann zu der Anpassung und befanden es als »einfacher«, »eindeutiger« und »übersichtlicher«, vor allem in Bezug auf die Navigation. Interessant war allerdings das Feedback von Person #1, als die Schaltfläche »Spiel starten – 0« nicht Weiß auf Blau,
111

7 Test

sondern Dunkelgrau auf Weiß dargestellt war. Ersteres leitet das Auge laut eigener Aussage der Person direkt auf die Schaltfläche, Letzteres hingegen lässt den Blick auf den Titel »Ambernstein« schweifen.

Abb. 65, Anpassung #2 der Webseite mit Feedback von Testperson #1

Abb. 66, Finale Anpassung der Webseite mit Feedback von Testperson #1

112

7 Test

Diese Erkenntnis war wichtig, da zunächst erkannt werden soll, um welches Spiel es sich handelt. Außerdem wurde die Textfarbe von »Textgröße« und »Farbschema« reinem Weiß angenähert, da die Texte sonst drohten, nicht erkannt zu werden. Daraus ergab sich die in Abbildung 54 des vorigen Abschnitts gezeigte Version der Webseite. Sie spiegelt den aktuellen Stand der Entwicklung wieder. Abbildung 66 illustriert wie die Darstellung dem dem Klicken bzw. Drücken auf »Wie du diese Seite per Tastatur steuerst:«.

7.3.4 Game Usability
Im Gegensatz zur Web Usability kann man Effektivität und Effizienz nur bedingt in der Game Usability anwenden. Typischerweise misst man damit die Produktivität von Soware. In einem Spiel geht es aber o darum, aus der Produktivität zu flüchten. [Fed 02, S. 8] Nach Raph Koster erfolgt – streng genommen – der beste Test des Spielspaßes, indem auf die Ausgabe von Grafik, Musik, Sound und Story verzichtet wird. Der Test ist ohne Weiteres für Ambernstein machbar. Übrig bleiben dann noch die Mini-Games, die ohne Grafik als einfache Klötzchen oder eben gar nicht dargestellt würden. Wenn Letzteres Spaß macht, dann werden alle weiteren Elemente dazu dienen, das Spielerlebnis zu fokussieren, zu verfeinern und insgesamt zu vergrößern.[KOS 05, S.166] Der zeitliche Rahmen dieser Arbeit ließ keine umfangreichen Tests der Game Usability zu. Insofern, ist es möglich sich an bekannten Usability-Heuristiken für Spiele [Fed 02, S. 41ff.] zu orientieren.

113

8
Konklusion
Zusammenfassung, Fazit, Ausblick.

114

8 Konklusion

Während der Entwicklung von Ambernstein wurde klar, dass Text-Adventures ihren Platz in Bereich der Spiel und Historie haben. Erwähnter Artikel über »Wortspiele« [Nee 10a], diverse Webseiten, Archive und nicht zuletzt die erst im August 2010 erschienene DVD-Dokumentation »GET LAMP« von Jason Scott [Sco 10] zeigen, dass das Interesse 146 an interaktiver Fiktion, gespielten Büchern und Spaß an »Fantasie im Kopf« vorhanden ist. Ambernstein wird 2010 wohl nicht den Weg an die Öffentlichkeit finden, weil es für 2011 geplant ist, dennoch ist das Fundament gebaut und darf nun »bebaut« werden. Hinsichtlich der User Experience ist zu sagen, dass dank zeitgemäßer Web-Technologien, TextAdventures von dem multimedialen Umfang des HTML5-Standards profitieren können. Nie war es so einfach, Audio- und Video-Dateien einzubinden. Text-Adventures leben zwar ausschließlich von Text, eine gesunde Mischung aus Text und »aufwändigeren« Medienarten wäre aber für die relative große Menge an Gelegenheitsspielern durchaus denkbar. Dass »alte« Spiele in einer modernen Zeit Fuß fassen können, zeigt die iPad-Version von »Adventure« 147 oder die iPhone-Version von »Monkey Island«. 148 Text-Adventures haben das Potenzial auf neuen Endgeräten wiederentdeckt zu werden. Es liegt nun an den Entwicklern, entsprechende die Allgemeinheit ansprechende Spiele zu entwickeln – ob z.B. als native »App« oder in W3C-konformer Art (HTML, CSS, JavaScript). 149 Genauso wenig wie Bücher aussterben, wird es auch mit Interactive Fiction in Form eines Text-Spiels sein – Text kann was Audio und Video nicht können, es ist zeitlich unabhängig zu konsumieren, kann inhaltlich durchsucht werden und ist deswegen das wohl zugänglichste Medium. Ob Mitchell Stephens mit seinem »the rise of the image the fall of the word« (1998) Recht hat, darf nach dem Lesen dieser esis bezweifelt werden. Gespannt darf man auf neue Entwicklungen im Browser-Bereich sein. Jüngst kündigte Microso eine neue Version seines »Internet Explorer« 150 an. Außerdem sieht z.B. Google den Browser als Zentrum des Betriebssystem bzw. als das Betriebssystem (Chrome OS). Das Spiele für dieses Betriebssystem scheint naheliegend und macht die Entwicklung von Ambernstein umso sinnvoller, weil technologisch gesehen dem aktuellen Trend entsprechend.

146 147 148 149 150

http://www.gamersglobal.de/meinung/neue-textadventures-bitte 05.10.2010 http://iadventure.antonfleig.com/ 06.10.2010 http://www.netzwelt.de/news/83299-monkey-island-2-neuauflage-iphone-ipad.html 06.10.2010 http://www.alistapart.com/articles/apps-vs-the-web/ 06.10.2010 http://www.beautyoftheweb.com/ 05.10.2010 115

8 Konklusion

Interessant ist auch welche Trends im Webdesign zu erwarten sind. Man hört von gender-specific web design 151 , dem Einfluss von Printdesign, sowie von ausdrucksstarker Typographie, dem horizontalism und der keypress navigation 152 (wie in Ambernstein umgesetzt). Abgesehen von Text-Adventures sind im Browser auch momentan schon wesentlich rechenintensivere Spiele möglich – Quake Live beweist, dass auch aufwändiges 3D per BrowserPlugin dargestellt werden kann. Dass auch mit nativen Browser-Technologien etwas möglich ist, zeige einige HTML5-Webseiten, die sich momentan noch als Experimente 153 darstellen. Interessant in dem Zusammenhang ist die HTML5-Funktion des Offline-Storage, bei der es effektiv um die »Beschwerung» des Clients geht - sprich: Daten werden auf den Client-Rechner ausgelagert und zwischengespeichert. Google arbeitet momentan an einer derartigen HTML5-Lösung. 154 Aktuell wird die Auslagerung auf den Client schon von Google Docs und als Browser-Plugin Google Gears 155 angeboten. Interessant ist auch ob und inwiefern Multi-reading 156 im Web erfolgreich sein wird – Web Workers 157 ist zumindest ein erster Ansatz der WHATWG. Eine Vielzahl der vorgestellten Entwicklungen sind technischer und technologischer Natur. Sie helfen, umfangreichere und »reichere« Web-Anwendungen zu erstellen und den Browser als den Zugangspunkt zum Web zu etablieren. Die Entwicklung ist gut und vor allem im Sinne der Usability und Accessibility. Sind diese beiden Säulen als »Muss« für Web-Anwendungen etabliert, steht mit Hilfe einer nutzerzentrierten Denke einer optimalen User Experience nicht mehr so viel im Wege. Web, Browser, Tastatur und Text haben eine Gemeinsamkeit: sie zielen alle darauf ab, zugänglich und benutzbar zu sein. Vor allem sollen sie aber im Idealfall Spaß bei der Benutzung bringen.

151 152 153 154

http://www.demystifyingusability.com/2010/07/gender-differences-in-web-usability.html 06.10.2010 http://www.smashingmagazine.com/2010/05/04/web-design-trends-2010/ 06.10.2010 http://www.chromeexperiments.com/ 06.10.2010

http://www.googlewatchblog.de/2010/04/12/google-docs-offline-wird-am-demnaechst-deaktiviert/ 06.10.2010
155 156 157

http://gears.google.com/ 06.10.2010 das parallele Ausführen von Prozessen (Threads) http://www.whatwg.org/specs/web-workers/current-work/ 06.10.2010 116

Nachwort
Storytelling ist aktueller denn je. Momentan wird es von der HORNBACH-Baumarkt-AG in dem »grenzenlosen Haus« 158 betrieben. Dabei wird per TV-Werbung Aufmerksamkeit und Interesse geweckt, indem mit wenig Impressionen im TV recht konsequent auf die Webseite verwiesen wird. Der zweite Teil des AIDAPrinzips wird auf der Webseite selbst durchgeführt, indem ein Mann beim Bau seines eigenen Hauses gezeigt wird, das vor Funktionen strotzt, die man selten so gesehen hat. Die Funktionen des Hauses wurden entsprechend kreativ in Szene gesetzt, sodass der Wunsch nach solch einem Eigenheim groß wird. Subtil wird »Hornbach« eingeblendet, bei dem die Materialien für den Bau eines solchen Hauses verfügbar sind. Damit Storytelling auch im Bereich der Spiele vorangetrieben werden kann, gibt es das Werkzeug Inform. Aaron Reed hat es für Blue Lacuna Inform 7 benutzt und ich bin mir sicher, dass es einige Menschen geben wird, die ihm nacheifern werden. Für Ambernstein wäre also eine Inform 7 Version schön sowie eine »Ambernstein App« für das iPhone. 159 Die Vision Ambernstein wurde in dieser esis ansatzweise gezeigt. Ich bin gespannt, wie sie sich weiterentwickelt. In diesem Sinne, ein freundliches »XYZZY«.

158 159

http://das-grenzenlose-haus.de/ 05.10.2010 http://www.phonegap.com/ – http://www.appcelerator.com/ 06.10.2010 117

Glossar
AIDA
AIDA steht für Attention, Interest, Desire, Action und ist vor allem in der Werbebranche ein gerne eingesetztes Prinzip.

IA
Information Architecture.

IF
IF steht Interactive Fiction und ist die genauere Bezeichnung für Text-Adventures. Sie stammt von der Firma »Infocom« – ihres Zeichens der kommerziell erfolgreichste Entwickler von interaktive Fiktion. [Sco 10]

IxD
Interaction Design.

UX
User Experience.

UI
User Interface.

118

Literaturverzeichnis
[And 09] Stephen P. Anderson. e Fundamentals of Experience Design (Web, Artikel), PoetPainter, LLC, 2009, http:// www.poetpainter.com/thoughts/article/ia-summit-2009-the-fundamentals-of-experience-design- zuletzt abgerufen am 15.09.2010 [Ber 01] Michael Bernard, Ashwin Sheshadri. Preliminary Examination of Global Expectations of Users‘ Mental Models for E-Commerce Web Layouts (Web, Studie), http://psychology.wichita.edu/surl/usabilitynews/62/web_object_international.htm zuletzt abgerufen am 22.09.2010 [Boc 09] Gisela Reineking von Bock. Bernstein: Das Gold der Ostsee (Print, Buch), Callwey Verlag München, 1981 [Cal 08] Ben Caldwell u.a. Keyboard Accessible, Understanding Guideline 2.1 - Understanding WCAG 2.0 (Web, Guideline), 2008, http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation.html zuletzt abgerufen am 20.09.2010 [Cas 10] Earle Castledine, Craig Sharkie, jQuery: Novice to Ninja (Print), SitePoint Pty. Ltd., 2010 [Cha 09] Cindy Chastain. Experience emes: How a storytelling method can help unify teams and create better products (Web, Artikel) ,Boxes and Arrows, 2009, http://www.boxesandarrows.com/view/experience-themes zuletzt abgerufen am 01.10.2010 [Coo 07] Alan Cooper, Robert Reimann, David Cronin. About Face 3: e Essentials of Interaction Design (Print, Buch), Wiley Publishing, Inc., 2007 [Dan 01] Nicky Danino, Heuristic Evaluation - a Step By Step Guide, 2001, http://articles.sitepoint.com/article/heuristic-evaluationguide zuletzt abgerufen am 25.08.2010 [Ber 09] Mario Bernhart, omas Grechenig, Sowaretechnik: Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson Education, 2009 [Eic 99] Armin Eichinger. Usability - Definition, Usability, 1999, http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/ Doktoranden/absolventen/eichinger_armin/u-definition.html zuletzt abgerufen am 12.09.2010 [Fed 02] Melissa Federoff. Heuristics and Usability Guidelines for the Creation and Evaluation of Fun in Video Games (Web, Master esis), 2002, http://melissafederoff.com/thesis.html zuletzt abgerufen am 25.08.2010 [Fie 98] Syd Field, Das Handbuch zum Drehbuch (Print, Buch), 1998 [Flo 84] Christiane Floyd. A Systematic Look at Prototyping, http://www.piapetersen.dk/rhs/floyd-prototyping.pdf zuletzt abgerufen am 11.09.2010. - In: R. Budde, K. Kuhlenkamp, L. Mathiassen, H. Züllighoven (Hrsg.): Approaches to Prototyping. Proceedings of the Working Conference on Prototyping, Springer Verlag, Berlin, Heidelberg, 1984, S. 1-18 [Fri 10] Vitaly Friedman, e Current State of Web Design: Trends 2010 (Web, Artikel), Smashing Magazine, http:// www.smashingmagazine.com/2010/05/04/web-design-trends-2010/ zuletzt abgerufen am 25.08.2010 [Gar 00] Jesse James Garrett. e Elements of User Experience (Web, Informationsgrafik), Eigenproduktion, 2000, http://www.jjg.net/ elements/pdf/elements.pdf zuletzt abgerufen am 12.09.2010

119

[Gar 03] Jesse James Garrett. e Elements of User Experience (Print, Buch), New Riders, 2003 [Gei 10] omas Geis. Usability und User Experience unterscheiden (Web, Artikel), ProContext Consulting GmbH, 2010, http:// blog.procontext.com/2010/03/usability-und-user-experience-unterscheiden.html zuletzt abgerufen am 14.09.2010 [Har 00] Ilse Harms, Werner Schweibenz. Testing Web Usability, (Web, Artikel), IM - Die Fachzeitschri für Information Management & Consulting (Ausgabe 3/2000), http://usability.is.uni-sb.de/beitrag/testwebu.pdf zuletzt abgerufen am 02.09.2010 [Hen 05] Shawn Lawton Henry u.a. Introduction to Web Accessibility, W3C Web Accessibility Initiative (WAI), 2005, http:// www.w3.org/WAI/intro/accessibility.php zuletzt abgerufen am 14.09.2010 [Hen oJ] Shawn Lawton Henry, Liam McGee. Accessibility, W3C, o.J., http://www.w3.org/standards/webdesign/accessibility zuletzt abgerufen am 14.09.2010 [Hop 09] Eric Hope, iPhone User Interface Design (iTunes University, Video), Apple Inc., 2009 [Hor 05] Sarah Horton. Access by Design: A Guide to Universal Usability for Web Designers (Web, Buch), New Riders Press, 2005, http://universalusability.com zuletzt abgerufen am 13.09.2010 [Inc 10a] Francisco Inchauste. Better User Experience With Storytelling – Part One (Web, Artikel), Smashing Magazine, http:// www.smashingmagazine.com/2010/01/29/better-user-experience-using-storytelling-part-one/ zuletzt abgerufen am 26.08.2010 [Inc 10b] Francisco Inchauste. Better User Experience With Storytelling, Part 2 (Web, Artikel), Smashing Magazine, http:// www.smashingmagazine.com/2010/02/11/better-user-experience-through-storytelling-part-2/ zuletzt abgerufen am 26.08.2010 [Jun 09] C.G. Jung, Archetypen (Print, Buch), 2009 [Kei 10] Jeremy Keith. HTML5 for Web Designers (Print, Buch), A Book Apart, 2010 [Kos 05] Raph Koster. A eory of Fun for Game Design (Print, Buch), Paraglyph Press, 2005 [Krö 10] Peter Kröner. HTML5 (Print, Buch), Open Source Press, 2010 [Kru 06] Steve Krug. Don't Make Me ink! A Common Sense Approach to Web Usability, Second Edition (Print, Buch), New Riders, 2006 [Lee 10] Ed Lee. Future Media Standards & Guidelines - Accessible Games Standard v1.0 (Web, BBC Online Standards and Guidelines), BBC Guidelines, 2010, http://www.bbc.co.uk/guidelines/futuremedia/accessibility/games.shtml zuletzt abgerufen am 07.09.2010 [Luk 10] Jenn Lukas. JavaScript and Web Standards Sitting in a Tree (Web, Präsentation). Happy Cog / SlideShare, 2010 http:// www.slideshare.net/JennLukas/javascript-and-web-standards-sitting-in-a-tree zuletzt abgerufen am 20.09.2010 [Lyn 09] Patrick J. Lynch, Sarah Horton. Web Style Guide, 3rd Edition (Web, Buch), Yale University Press, 2009, http:// www.webstyleguide.com/ zuletzt abgerufen am 08.09.2010 [Mcb 10] Sean McBride, Lindsey Simon. HTML, CSS, and Javascript from the Ground Up (Web, Videos), Google Code University, http://code.google.com/intl/de-DE/edu/submissions/html-css-javascript/ zuletzt abgerufen am 02.09.2010

120

[Mei 10] Jens O. Meiert. SUS: How to Easily Grad Your Site‘s Usability (Web, Artikel), Jens O. Meierts Blog, 2010 http://meiert.com/en/blog/20091127/sus-how-to-grade/ zuletzt abgerufen am 06.10.2010 [Mor 04] Peter Morville. User Experience Design (Web, Kolumne), Semantic Studios, 2004, http://semanticstudios.com/publications/ semantics/000029.php zuletzt abgerufen am 12.09.2010 [Nee 10a] Christian Neeb, Story: Wortspiele (S. 54, Print, Artikel), GEE Magazin, Ausgabe Mai/Juni 2010 [Nee 10b] Christian Neeb, Wie sind Helden (Web, Artikel), GEE Magazin, 2010, http://www.geemag.de/2010/06/06/wie-sind-helden/? hetag=GEE%2054 zuletzt abgerufen am 25.08.2010 [Nie 97] Jakob Nielsen, How Users Read on the Web (Web, Kolumne), Jakob Nielsen‘s Alertbox, 1997, http://www.useit.com/alertbox/ 9710a.html zuletzt abgerufen am 24.09.2010 [Nie 00] Jakob Nielsen. Why You Only Need to Test with 5 Users (Web, Kolumne), Jakob Nielsen‘s Alertbox, 2000, http:// www.useit.com/alertbox/20000319.html zuletzt abgerufen am 02.09.2010 [Nie 03] Jakob Nielsen. Usability 101: Introduction to Usability (Web, Kolumne), Jakob Nielsen‘s Alertbox, 2003, http://www.useit.com/ alertbox/20030825.html zuletzt abgerufen am 13.09.2010 [Nie 04] Jakob Nielsen. Card Sorting: How Many Users to Test (Juli 2004), useit.com: Jakob Nielsen's Website, http://www.useit.com/ alertbox/20040719.html (Abruf: 20.1.2010). [Nie 05] Jakob Nielsen, 10 Heuristics for User Interface Design (Web, Essay), useit.com, 2010, http://www.useit.com/papers/heuristic/ heuristic_list.html zuletzt abgerufen am 28.09.2010 [Nie 06] Jakob Nielsen, Hoa Loranger. Prioritizing Web Usability (Print, Buch), New Riders, 2006 [Nor 02] Donald A. Norman, e Design of Everyday ings (Re-Print, Buch), Basic Books, 2002 [Nor 04] Donald A. Norman, Emotional design: why we love (or hate) everyday things (Print, Buch), basic Books, 2004 [Pre 04] Jenny Preece, Information Architecture and Web Navigation (Web, Paper), University of the West of Scotland, 2004, http:// hamilton.bell.ac.uk/btech/hci/hcinotes11.pdf zuletzt abgerufen am 03.10.2010 [Rol 06] Andrew Rollings, Ernest Adams, Fundamentals of Game Design (Print, Buch), Prentice Hall, 2006 [Rou 05] Richard Rouse III. Game Design - eory & Practice (Second Edition, Print, Buch), Wordware Publishing, 2005 [Rya 99a] Tim Ryan, e Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept und Proposal (Web, Artikel), Gamasutra, 1999, http://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php?print=1 zuletzt abgerufen am 29.09.2010 [Rya 99b] Tim Ryan, e Anatomy of a Design Document, Part 2: Documentation Guidelines for the Functional and Technical Specifications (Web, Artikel), Gamasutra, 1999, http://www.gamasutra.com/view/feature/3411/ the_anatomy_of_a_design_document_.php?print=1 zuletzt abgerufen am 29.09.2010

121

[Saf 07] Dan Saffer, Designin for Interaction: Creating Smart Applications and Clever Devices (Print, Buch), New Riders, 2007 [Sch 08] Jesse Schell, e Art of Game Design (Print, Buch), Morgan Kaufmann, 2008 [Sco 10] Jason Scott, GET LAMP - a documentary about adventures in text (DVD), Eigenproduktion, 2010 [She 04] Lee Sheldon, Character Development and Storytelling for Games (Print, Buch), omson Course Technology PTR, 2004 [Shn 03a] Ben Shneiderman u.a. Research-Based Web Design & Usability Guidelines (Print, Buch), U.S. Department of Health and Human Services, 2003, http://usability.gov/guidelines/index.html zuletzt abgerufen am 06.10.2010 [Shn 03b] Ben Shneiderman. Leonardo's laptop: human needs and the new computing technologies (Print, Buch), MIT Press, 2003 [Spi 06] Frank Spillers. e Importance of User Experience (Web, Diagramm), Experience Dynamics, 2006, http://www.flickr.com/ photos/bryce/106972762/ zuletzt abgerufen am 30.09.2010 [Sto 09] Elliot Jay Stocks. Sexy Webdesign (Print, Buch), dpunkt.verlag, 2009 [Tan 08] David Tanguay, A guide to create the ideal adventure game (Web, Artikel), 2008, http://www.adventureclassicgaming.com/index.php/site/features/105/ zuletzt abgerufen am 25.08.2010 [Ung 09] Russ Unger, Carolyn Chandler. A Project Guide to UX Design: For user experience designers in the field or in the making (Print, Buch), New Riders, 2009, [Usa oJ] o.V. What is User-Centered Design? (Web, Artikel), Usability Professionals‘ Association, o.J. http:// www.usabilityprofessionals.org/usability_resources/about_usability/what_is_ucd.html zuletzt abgerufen am 14.09.2010 [Vog 98] Christopher Vogler, Die Odyssee des Drehbuchschreibers, Zweitausendeins, 1998 [Wal 06] Trey Walker, e Sims overtakes Myst (Web, Artikel), 2002, http://www.gamespot.com/pc/strategy/simslivinlarge/ news_2857556.html zuletzt abgerufen am 25.08.2010

122

Kolophon
Der Fließtext wurde in Minion Pro (Robert Slimbach, 2000) gesetzt. Überschrien, Fußnotentext, sowie Kopf- und Fußzeilen wurden in Lucida Sans – dem serifenlosen Komplement von Lucida, das 1985 von Kris Holmes und Charles Bigelow geschaffen wurde – gesetzt.

123