Projektdokumentation - Prof. Dr. GJ Veltink Hochschule ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Fachbereich Technik
Abteilung Elektrotechnik und Informatik
Projektdokumentation
im Studiengang Medientechnik
Entwicklung eines interaktiven
Multimediaprojektes und Veröffentlichung im
Internet mit „HTML 5“-Inhalten
Jannike Illing
Erstprüfer : Prof. Dr. Gerrit Jan Veltink
Zweitprüfer : Dipl.- Ing. Klaus Müller
Eingereicht am : I
Kurzfassung
Die Entwicklung multimedialer Anwendungen mit einer proprietären Technologie wie Adobe
Flash wird in Zukunft immer mehr an Bedeutung verlieren. Um multimediale Inhalte als native
Objekte in HTML einzubetten, wird stattdessen das Interesse neuer Web-Technologien wie die
Kombination aus HTML 5, Javascript und CSS immer größer. Diese Projektarbeit befasst sich mit
der Entwicklung einer multimedialen Anwendung für Kinder im Kindergarten- und Vorschulalter
mit „HTML 5“-Inhalten. Dabei werden die Einschränkungen und Möglichkeiten dieser neuen
Web-Technologie herausgestellt und mit Adobe Flash als Referenzsoftware verglichen. Die
Entwicklung soll im Anschluss im Internet zur Verfügung gestellt werden.
II
Danksagung
Im Rahmen dieser Projektentwicklung möchte ich mich vor allem bei Herrn Prof. Dr. Gerrit Jan
Veltink für die hervorragende Unterstützung bedanken. Ich danke ihm auch für die freundliche und
konstruktive Zusammenarbeit. Desweiteren möchte ich mich bei Herrn Dipl.- Ing. Klaus Müller
bedanken, der die Co-Betreuung übernommen hat.
Ein Dank gilt ebenfalls meinem Vater, der mir seine Stimme für viele Sprachausgaben zur
Verfügung stellte und mir, zusammen mit meinem Freund, den nötigen Halt gab.
III
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Projektarbeit bis auf die offizielle
Betreuung selbst und ohne Hilfe angefertigt habe und die benutzten Quellen und Hilfsmittel
vollständig angegeben sind.
Erklärung
Soweit meine Rechte berührt sind, erkläre ich mich einverstanden, dass die Projektarbeit
Angehörigen der Hochschule Emden/Leer für Studium/Lehre/Forschung uneingeschränkt
zugänglich gemacht werden kann.
Datum, Unterschrift
IV
Inhaltsverzeichnis
1. Einleitung.........................................................................................................................................1
1.1. Einführung in das Themengebiet..............................................................................................1
1.2. Motivation.................................................................................................................................2
1.3. Gliederung der Dokumentation................................................................................................3
2.Grundlagen........................................................................................................................................5
2.1. Vorgehensmodell.......................................................................................................................5
2.1.1. Analyse..............................................................................................................................6
2.1.2. Konzeption........................................................................................................................6
2.1.3. Assetproduktion................................................................................................................6
2.1.4. Medienintegration.............................................................................................................7
2.1.5. Test und Installation..........................................................................................................7
2.2. Verantwortlichkeit unterschiedlicher Browser-Darstellungen..................................................8
3. Grundvoraussetzungen.....................................................................................................................9
3.1. Bereitstellung des Webservers................................................................................................10
3.2. Auswahl der Animationssoftware...........................................................................................12
3.2.1. Animatron........................................................................................................................13
3.2.2. Sencha Animator.............................................................................................................13
3.2.3. Google Web Designer.....................................................................................................13
3.2.4. Adobe Edge Animate......................................................................................................14
3.2.5. Hippo Animator...............................................................................................................14
4. Projektplanung................................................................................................................................15
4.1. Anforderungsspezifikationen..................................................................................................15
4.1.1. Musskriterien..................................................................................................................16
4.1.2. Wunschkriterien..............................................................................................................17
4.1.3 Abgrenzungskriterien.......................................................................................................18
4.2. Flowchart................................................................................................................................18
4.3.1. Navigation.......................................................................................................................20
4.3. Storyboard...............................................................................................................................21
5. Projektdurchführung.......................................................................................................................22
5.1. Asseterstellung........................................................................................................................22
5.1.1. Audio-Dateiformat..........................................................................................................22
5.1.1.1 Automatische Soundwiedergabe..............................................................................24
5.1.2. Grafik-Dateiformat..........................................................................................................25
V
5.2. Schriftarten..............................................................................................................................27
5.3. Skriptfunktionen.....................................................................................................................29
5.3.1. Auswahl verwendeter Skriptfunktionen..........................................................................30
5.3.1.1. Steuerung der Sprachausgaben................................................................................30
5.3.1.2. Steuerung der Animationen.....................................................................................33
5.3.1.3. Umsetzung der Navigationsstruktur........................................................................35
6. Projektabschluss.............................................................................................................................35
6.1. Integration der Web-Applikation im Internet..........................................................................36
6.2. Testdurchführung....................................................................................................................37
6.3. Gegenüberstellung des Zeitaufwandes...................................................................................38
6.4. Meilensteintrendanalyse.........................................................................................................39
7. Fazit................................................................................................................................................40
Abbildungsverzeichnis..........................................................................................................................i
Tabellenverzeichnis.............................................................................................................................iii
Literaturverzeichnis.............................................................................................................................iv
A Anhang.............................................................................................................................................vi
A1. Inhaltsverzeichnis der CD........................................................................................................vi
VI
1. Einleitung
Diese Projektdokumentation befasst sich mit der Entwicklung einer multimedialen und interaktiven
Anwendung auf Basis von HTML 5. Die Zielgruppe dieses Multimediaprojektes sind Kinder im
Kindergarten- und Vorschulalter. Mit der Anwendung wird das Thema „Mythos Wolf“ in
passenden Unterkapiteln gegliedert und kindgerecht gestaltet.
Die Web-Applikation soll dem Benutzer im Internet mit einem passenden Domainnamen zur
Verfügung gestellt werden. Neben einer Desktop-Version soll eine Tablet-Version dieser
Anwendung angeboten und mit der Umsetzung von „Responsive Webdesign“ entwickelt werden.
Zum Schluss soll aufgezeigt werden, was im Moment mit „HTML 5“-Authoring-Tools möglich ist
und welche Merkmale aufgrund von HTML-Beschränkungen im Vergleich zu Adobe Flash noch
nicht umsetzbar sind.
Zur Einführung in das Themengebiet wird der Entstehungsprozess der neuen Web-Technologie
HTML 5 im Vergleich zu Adobe Flash analysiert. Es soll der Zusammenhang beleuchtet werden,
warum Adobe Flash als De-facto-Standard von Multimedia im Internet schließlich nicht mehr
alleine bestehen konnte und den Platz mit HTML 5 teilen musste.
Im weiteren Verlauf dieses Kapitels wird die Motivation dieser Arbeit beschrieben und der Grund
dieser Entwicklungsentscheidung beleuchtet. Zuletzt folgt eine kurze Übersicht der weiteren
Kapitel dieser Projektdokumentation.
1.1. Einführung in das Themengebiet
Die Verwendung von multimedialen Inhalten im Internet werden zunehmend bedeutender. Adobe
Flash war lange Zeit die beste Lösung zur Erstellung interaktiver Anwendungen und hat sich im
Laufe der Jahre zum De-facto-Standard für den Einsatz von Multimedia im Internet entwickelt.
Allerdings beruhte die Technik auf die Verwendung vom Browser-Plugin des Adobe Flash Players,
welcher nach einiger Zeit mit jedem Web-Browser mit ausgeliefert wurde. Aus diesem Grund
konnte Adobe Flash als Multimedialösung aus Entwicklersicht unbedenklich eingesetzt werden.
Bisher gab es keine praktikable Möglichkeit, multimediale Inhalte wie Animationen, Film und Ton
1
als native Objekte in HTML einzubetten.
Dennoch wurde das Interesse von neuen Web-Technologien wie „HTML 5“ immer größer. Dies
liegt daran, dass Adobe Flash eine proprietäre Technologie mit einem binären Dateiformat ist.
Steve Jobs prophezeite im Jahre 2010 den Untergang dieser proprietäre Technologie und lehnte die
künftige Verwendung dieser Multimedialösung für weitere Apple-Produkte ab. Aufgrund dessen
hat sich das Unternehmen Apple entschieden, offenen Standards wie „HTML 5“, CSS und
Javascript zu nutzen. Diese Standards werden von unabhängigen Stellen entwickelt und können von
allen genutzt werden [ Job10].
Adobe reagierte auf die Neuentwicklung und stellte im November 2011 die Weiterentwicklung des
Adobe Flash Players für mobile Endgeräte ein [Win11]. Außerdem wurde die Funktionalität vom
neuen Adobe Flash Pro CC um den Export von Flash-Animationen als „HTML 5“-Canvas
erweitert [Tra14].
Trotz der erhöhten Nutzung von HTML 5 muss beachtet werden, dass diese Entwicklung im
Aufbau ist und noch nicht alle Features von HTML 5 in jedem Web-Browser unterstützt werden.
1.2. Motivation
Im Rahmen des Bachelor-Studienganges Medientechnik an der Hochschule Emden/Leer konnte
die Autorin viele Einblicke in die Themengebiete der Softwareentwicklung nehmen. Mit dem
Modul „Autorensysteme“ und der anschließenden Wahl der Vertiefungsrichtung
„Informationssysteme“ wurde das Ziel gefestigt, den Abschluss mehr in Richtung
Medieninformatik zu lenken. Dabei hat das Modul „Autorensysteme“ mit der Entwicklung eines
Infoterminals und der multimedialen Umsetzung mit Adobe Flash CS5 einen bleibenden Eindruck
hinterlassen. Es entstand der Wunsch, die Technologie mit der Autorensoftware Adobe Flash CS5
und ActionScript 3.0 durch die Entwicklung einer eigenen interaktiven Applikation zu vertiefen.
Allerdings wurden im Laufe des Studiums die Möglichkeiten neuer Web-Technologien wie
HTML 5 in Verbindung mit CSS 3 und JavaScript immer größer. Mithilfe von Prof. Dr. Gerrit Jan
Veltink entstand eine Umstrukturierung der Projektidee mit der Verwendung eines „HTML 5“-
Authoring-Tools und der Entwicklung der multimedialen Inhalte auf „HTML 5“-Basis. Die
ursprüngliche Projektidee wird durch den Vergleich von Adobe Flash und HTML 5 als
Multimedialösungen wieder aufgegriffen.
2
Das Thema dieser Anwendung wurde von der Autorin aus persönlichen Gründen gewählt, da sie als
Hundebesitzerin viele Erfahrungen im Umgang mit Kindern und Hunden sammeln konnte.
Beobachtungen haben gezeigt, dass Kinder die Körpersprache eines Hundes oft fehlinterpretieren
und dadurch vermeidbare Situationen entstehen. Da Kinder beim Thema „Wolf“ allerdings eher
verunsichert und verängstigt reagieren, sollte mit der Anwendung eine Verbindung zwischen Wolf
und Hund geschaffen werden.
1.3. Gliederung der Dokumentation
Die Einleitung mit der Einführung des Themengebietes und der Motivation schließt mit einer
Übersicht über den Aufbau und Inhalt dieser Projektdokumentation ab.
Kapitel 2: Grundlagen
Kapitel 2 behandelt die für das Verständnis notwendigen Grundlagen des Praxisprojektes. Es wird
das Vorgehensmodell dieser Projektarbeit vorgestellt um die wesentlichen Prozesse der
Projektdurchführung nachzuvollziehen. Im Anschluss folgt eine Erklärung, wie es zu
unterschiedlichen Browser-Darstellungen von „HTML 5“-Inhalten kommen kann.
Kapitel 3: Grundvoraussetzungen
Vor dem Projektstart mussten Grundvoraussetzungen für die Bereitstellung der Anwendung im
Internet und die Auswahl eines geeigneten „HTML 5“-Authoring-Tools geklärt werden. Die
Organisation vorab zu klären war für die Projektdurchführung ein essentieller Bestandteil, weil
dadurch die notwendigen Mittel bereit standen.
Kapitel 4: Projektplanung
Kapitel 4 behandelt die notwendige Projektplanung als Teil des Projektes. Es wird aufgezeigt,
welche Produktfunktionen der multimedialen Anwendung festgelegt wurden. Außerdem wird die
festgelegte Navigationsstruktur mithilfe eines Flowcharts und die Realisierung des Storyboards
erläutert.
3
Kapitel 5: Projektdurchführung
Kapitel 5 behandelt die Projektdurchführung sowie aufgetretene Problemstellungen. Es folgt zudem
eine Erläuterung der Implementierung von eingebauten Elementen und ein anschließender kurzer
Überblick des verwendeten Funktionsumfanges der ausgewählten Animationssoftware.
Kapitel 6: Projektabschluss
Zum Schluss wird der Projektabschluss mit den gesammelten Erfahrungen in Kapitel 6 näher
beschrieben. Ein persönliches Fazit sowie die Aufführung des realen Zeitaufwandes schließen die
Projektdokumentation ab.
42 .G r u nd l age n
In diesem Kapitel werden die Grundlagen für das Praxisprojekt vorgestellt. Zunächst wird das
Vorgehensmodell des Multimediaprojektes beschrieben und die Phasen der Projektplanung
erläutert. Im Anschluss folgt ein Einblick der Verantwortlichkeit unterschiedlicher Browser-
Darstellungen von „HTML 5“-Inhalten.
2.1. Vorgehensmodell
Das Multimediaprojekt wurde anhand des Wasserfallmodells nach Winston Royce aus dem Jahr
1970 organisiert. Das Wasserfallmodell beschreibt ein lineares Vorgehensmodell, welches in fest
definierten Phasen organisiert wird [Roy70].
Dabei gehen die Ergebnisse einer Phase als Vorgabe für die nächste Phase ein.
Das Multimediaprojekt wurde in fünf Phasen organisiert. Diese Phasen beschreiben den
Projektablauf und sind fest definiert [Roy70]. Im Wasserfallmodell ist jede Phase mit eindeutigen
Ergebnissen vorgesehen, die in der nächsttieferen Phase als Basis benötigt werden. Aufgrund
dessen sind vordefinierte Start- und Endpunkte für jede Phase vorgesehen. Die einzelnen Phasen
werden in folgenden Unterkapiteln erläutert.
52.1.1. Analyse
Die Analyse beschreibt einen Teil des Systementwicklungsprozesses. In dieser Phase wurden
Vorabplanungen getätigt und geprüft. Bevor das Projekt startete, mussten die Rahmbedingungen
für die spätere Entwicklung sichergestellt werden. Dazu gehörten die Bereitstellung eines Web-
Servers, die Analyse eines Domainnamens und die Auswahl der geeigneten Animationssoftware.
Zum Ende dieser Phase wurde ein Pflichtenheft erstellt, welches die Realisierungsvorgaben des
Projektes genau spezifiziert. In diesem sind die nach IEEE 1 definierten Bereiche des „Requirements
Engineering„ festgelegt. Diese umfassen das Ermitteln, Analysieren, Spezifizieren und Validieren
aller Eigenschaften und Rahmenbedingungen eines Softwaresystems, die über seinen gesamten
Lebenszyklus relevant sind [PD14].
2.1.2. Konzeption
Aufbauend auf die Analysephase wird die Konzeptionsphase eingeleitet. Das Pflichtenheft wird
hier als Basis für die Entwicklung der weiteren Dokumente benötigt. In dieser Phase wurde das
Flowchart und das Storyboard erstellt. Diese Dokumente beschreiben, aufbauend zum
Pflichtenheft, den Entwurf des Systems. Nach Abschluss dieser Phase ist die dokumentarische
Grundlage für die Entwicklung der Multimediaanwendung geschaffen worden.
2.1.3. Assetproduktion
Nachdem die Dokumente fertiggestellt wurden, mussten die benötigten Assets erstellt werden.
Dazu gehören Grafiken, Audio-Dateien, Animationen und Texte. Der Entwicklungsprozess der
Asseterstellung beinhaltet die Aufnahme, Digitalisierung, Bearbeitung, Konvertierung und
Komprimierung [Vel13]. In diesem Praxisprojekt wurden alle Assets selbst erstellt, bearbeitet und
komprimiert abgespeichert.
1 Institute of Electrical and Electronics Engineers
62.1.4. Medienintegration
Die Medienintegration meint die Umsetzung des entworfenen Konzeptes. In dieser Phase wird auf
Basis des Flowcharts und des Storyboards die Anwendung entwickelt. Zum ersten Schritt dieser
Phase gehört die Entwicklung des Navigationsgerüstes. Dabei werden die Navigationsstrukturen
des Flowcharts umgesetzt und das Navigationsgerüst als eine Art „Click-Dummy“ entwickelt.
Anschließend wird dieses Navigationsgerüst als Basis für die weiter Entwicklung herangezogen. Es
folgt die Umsetzung des Storyboards, die Integration der Assets und die Implementierung von
Interaktionen.
2.1.5. Test und Installation
In dieser Phase wird die Testphase eingeleitet. Dabei wird ein Modultest, Integrationstest und
Systemtest vollzogen und protokolliert. Im Pflichtenheft wurden dabei die globalen Testszenarien
und Testfälle definiert.
72.2. Verantwortlichkeit unterschiedlicher Browser-Darstellungen
Aufgrund unterschiedlicher Browser in verschiedenen Einsatzbereichen, stellt sich bei der
Entwicklung von „HTML 5“-Inhalten die Frage nach der Browser-Kompatibilität. Hier lässt sich
schnell beantworten, dass HTML 5 und CSS 3 von keinem neueren Web-Browser vollständig
unterstützt werden. Diese Tatsache wird oft verschleiert, bildet aber ein ernstzunehmendes
Problem für die Entwicklung. Mithilfe von Online-Test-Tools lassen sich unterschiedliche Browser
auf ihre „HTML 5“-Unterstützung testen [Lee13]. Anhand dieser Online-Tools lässt sich
allerdings auch der Fortschritt der Browser-Kompatibilität von „HTML 5“ erkennen (Abb. 2.2).
In Abb. 2.2 ist deutlich erkennbar, dass der Internet Explorer von Microsoft in der
Weiterentwicklung im Vergleich zu den anderen Web-Browsern immer etwas hinterherhinkt und
somit weiterhin das „Sorgenkind“ in der Web-Entwicklung bleibt. Google Chrome bleibt weiterhin
auf den ersten Platz der „HTML 5“-Unterstützung.
Aufgrund der unterschiedlichen „HTML 5“-Kompatibilität der aktuellen Web-Browser kommt es
trotz Einhaltung der Webstandards immer noch zu Unterschieden zwischen den Browsern und
Browser-Versionen.
Verantwortlich für die Unterschiede sind die verschiedenen Rendering- und Layout-Engines der
jeweiligen Web-Browser. Moderne Web-Browser trennen dieses Software-Kernstück von den
8übrigen Software-Funktionen wie beispielsweise die Cache-Verwaltung. Die Rendering-Engine ist
für das Parsen von HTML verantwortlich und dient somit der Visualisierung von HTML
[GM14].
Zu den führenden HTML-Rendering-Engines zählen neben der Gecko- und Webkit-Engine die
Trident-, Presto- und KHTML-Engine. Diese lesen den Inhalt der HTML-Datei und deren
Referenzen zu weiteren Dokumenten (z. B. Stylesheets) ein und stellen das Ergebnis als formatierte
Ausgabe dar.
Die Rendering-Engines werden überwiegend, unabhängig von der Browser-Software,
weiterentwickelt. Durch die Verwendung unterschiedlicher Rendering-Engines der Web-Browser
und deren unabhängigen Weiterentwicklungen kommt es zu Diskrepanzen und somit auch zur
unterschiedlichen „HTML 5“-Kompatibilität zwischen den Web-Browsern.
3 . G r u nd vo r a us s e t z un gen
Bevor das Projekt beginnen konnte, wurden grundlegende Bedingungen vorab geklärt. Neben der
Besprechung des Projektumfanges, musste die Voraussetzungen einer anschließenden
Veröffentlichung der Anwendung im Internet geschaffen werden. Die Veröffentlichung der
Anwendung auf einem Webserver war für die Projektentwicklung ein sehr wichtiger Bestandteil. So
konnten Testszenarien durchgeführt werden um das Verhalten der Anwendung außerhalb des
lokalen Betriebes zu ermitteln. Außerdem war es möglich, ohne großen Datentransfer, den aktuellen
Projektstand zur Verfügung zu stellen um eine Diskussionsbasis zu schaffen.
Neben der Bereitstellung des Webservers wurden unterschiedliche „HTML 5“-Authoring-Tools vor
dem Projektstart analysiert um eine geeignete Animationssoftware für die spätere
Projektdurchführung herauszufiltern.
93.1. Bereitstellung des Webservers
Für das Projekt stand ein eigener Linux Server zur Verfügung. Um diesen Server im lokalen Netz
und im Internet betreiben zu können, wurde der zur Verfügung stehende Apache-Webserver
konfiguriert. Vor der Entwicklungsphase des Projektes wurde der Webserver auf das lokale System
beschränkt, um Zugriffe von außen zu vermeiden [Noi14].
Die Entwicklungsphase erforderte den Betrieb des Webservers im Internet um die Anwendung zu
testen und den aktuellen Projektstand zu kontrollieren.
Da sich die Anwendung allerdings im Aufbau befand, sollte ein Passwortschutz vor unbefugtem
Zugriff schützen. Dies wurde mithilfe einer htaccess-Datei gelöst. Diese Datei enthält die
Anweisungen für den Webserver. Diese referenziert auf eine htpasswd-Datei, die die Benutzer und
die zugehörigen Passwörter enthält [Mae07].
Die htaccess-Datei enthält folgende Zeilen um den Passwortschutz einzuleiten:
1 AuthType Basic
2 AuthName "Zugriff verweigert - Bitte User und Passwort eingeben"
3 AuthUserFile /var/www/html/waheela/.htpasswd
4 Require valid-user
Die erste Zeile beschreibt die Art der Authentifizierung. Die „Basic“-Methode wird vom Browser
unverschlüsselt an den Webserver übertragen. Eine Alternative wäre die „Digest“-Methode
gewesen, die eine verschlüsselte Übertragung ermöglicht. Diese wird allerdings von sehr wenigen
Browsern unterstützt.
Die zweite Zeile beschreibt den Titel des Abfragefensters im Browser. Dieses Fenster erfordert die
Eingabe der Authentifizierung.
Die dritte Zeile beschreibt den Pfad zur htpasswd-Datei, die die Benutzer- und
Passwortinformationen speichert.
Die vierte Zeile beschreibt, welche Benutzer aus der htpasswd-Datei Zugriff auf die Datei erhalten.
Dabei wurden allen Nutzern den Zugriff erlaubt, da nur zwei Benutzer in der htpasswd-Datei
definiert waren.
10Bei der Ausführung der HTML-Datei der Anwendung, gab es im lokalem Betrieb mit dem
Abspielen von Ton- und Animationswiedergaben in einigen Browsern Probleme [HIP13]. Dieses
Problem wurde mit der Verwendung von Firefox (Version 33.0) und Opera (Version 26.0)
festgestellt. Unter Google Chrome (Version 39.0) und Internet Explorer (Version 11.0) gab es keine
Probleme bei der Wiedergabe. Das Problem lag am Adobe Flash-Player, der den Aufruf als
unsichere Operation interpretierte. Um das Problem zu beheben, mussten die Einstellungen des
Flash-Players angepasst werden. Das Verzeichnis, in dem die Anwendung lag, wurde bei den
Einstellungen als „vertrauenswürdig“ gekennzeichnet (Abb. 3.1).
Neben der Bereitstellung des Webservers musste ein passender Domainname für die Anwendung
gefunden werden. Hier war zunächst wichtig, einen Namen zu finden, bei dem es keine
urheberrechtlichen Probleme gibt. Außerdem ist die Auswahl von passenden Domainnamen
begrenzt, da es wichtig war, dass dieser zum Thema passt. Viele passende Namen waren vergeben
und/oder fielen aus rechtlichen Gründen aus der Auswahl.
Nach einiger Recherche wurde der Domainname „waheela.de“ für die Anwendung ausgesucht und
registriert. Dieser Name war nicht vergeben und es waren keine rechtlichen Folgen zu erwarten.
Waheela beschreibt einen Riesenwolf, der im Norden Kanadas beheimatet ist. Seine Existenz wurde
nie nachgewiesen. Diese Fakten waren Anlass für die Wahl des Domainnamens, da er das Thema
„Mythos Wolf“ durch den fehlenden Existenzbeweis gut beschreibt.
113.2. Auswahl der Animationssoftware
Vor Projektbeginn wurden unterschiedliche „HTML 5“-Authoring-Tools analysiert um eine
geeignete Animationssoftware für die spätere Projektdurchführung zu ermitteln. Die Anzahl an zur
Verfügung stehender Animationssoftware war sehr groß und es wurden einige, nach vorheriger
Grobsortierung, ausgeschlossen.
Dazu gehörte zum Beispiel die Animationssoftware „A5 HTML5 Animator“ der Firma Data
Becker. Auf den ersten Blick wirkte diese Lösung ganz gut umgesetzt aber nach einiger Recherche
hat sich herausgestellt, dass die Firma Data Becker seinen Betrieb eingestellt hat und nicht mehr
existiert. Aufgrund dessen sind keine Weiterentwicklungen und Updates dieses „HTML 5“-
Authoring-Tools zu erwarten.
Zur näheren Auswahl kamen Animatron (Online-Tool), Sencha Animator, Google Web Designer,
Adobe Edge Animate und Hippo Animator. Jedes Authoring-Tool hatte seine eigenen Vor- und
Nachteile. Die folgende Abbildung zeigt tabellarisch die Qualitätskriterien, die bei der
Softwareauswahl herangezogen wurden:
Abb. 3.2: Bewertung Animationssoftware
123.2.1. Animatron
Das „HTML 5“-Online-Auhtoring-Tool Animatron wurde zu Beginn ausgeschlossen, da für die
Bearbeitung und Erstellung interaktiver Inhalte, die Zuverlässigkeit der Software als sehr wichtig
betrachtet wurde. Animatron wurde bei diesem Kriterium negativ bewertet, weil es die Online-
Verfügbarkeit des Entwicklers voraussetzt. Dieser Aspekt war für die Projektentwicklung zu
kritisch, da die Entwicklung beim Ausfall der Internetverbindung stillstehen würde. Außerdem
wurde in Betracht gezogen, dass eine komplizierte Anwendung mit viel Audio- und Grafikdateien
im Entwicklungsverlauf immer mehr Rechenleistung benötigt. Die Projektentwicklung würde dabei
von der Rechenleistung des Servers von Animatron abhängen.
3.2.2. Sencha Animator
Sencha Animator wurde sehr lange in Betracht gezogen, da dieses „HTML 5“-Authoring-Tool sehr
benutzerfreundlich ist, eine große Funktionspalette zur Verfügung stellt und zuverlässig arbeitet. Es
ist kompatibel mit Adobe-Dateiformaten wie AI-Dateien von Illustrator und PSD-Dateien von
Photoshop. So konnte man die Dateien ohne Probleme importieren und weiterbenutzen. Leider
musste diese „HTML 5“-Animationssoftware aufgrund der sehr hohen Kosten ausgeschlossen
werden. Es stand nur eine 5-Platz-Lizenz für $965.00 neben einer 20-Platz-Lizenz für $3,795.00
zur Verfügung. Eine Anfrage nach einer preiswerteren Studentenversion mit einer 1-Platz-Lizenz
für die Entwicklung eines studienbegleitenden Projektes wurde abgelehnt. Es folgte lediglich auf
unfreundliche Art und Weise ein Hinweis auf die 30-Tage Testversion der Software.
3.2.3. Google Web Designer
Google Web Designer kam ebenfalls bei der Softwareauswahl zum Einsatz und wurde ausgiebig
getestet. Dieses „HTML 5“-Authoring-Tool befindet sich allerdings noch in einer Beta-Version
und wurde daher aufgrund unzureichendem Funktionsumfang im Vergleich zu konkurrierenden
Produkten ausgeschlossen. Es blieb aber ein Augenmerk auf diese Software, weil sie frei zur
Verfügung steht und in Zukunft eine sehr gute Alternative für kostenpflichtige „HTML 5“-
Authoring-Tools darstellt. Die Analyse hat ergeben, dass Google Web Designer in Zukunft sehr
13viel Potential zeigt, da viele interessierte Entwickler an dieser kostenfreien Version arbeiten.
3.2.4. Adobe Edge Animate
Für die Projektentwicklung wurde Adobe Edge Animate zunächst ausgeschlossen, da diese
Software nur als kostenpflichtige Cloud-Abo-Version zur Verfügung steht und dieses auf Dauer zu
teuer ist. Mit der kostenlosen 30-Tage-Trial-Version konnte diese Software getestet werden. Sie lässt
sich, wie Adobe Flash, sehr gut mit den anderen Adobe-Produkten vereinen. Somit lassen sich
problemlos Dateien der unterschiedlichen Adobe-Anwendungen teilen. Zum Beispiel ist es in
Adobe Edge Animate nicht möglich, Inverse Kinematik (IK-Bones) zu realisieren. Dieses Problem
konnte allerdings durch die Kompatibilität der Adobe-Produkte umgangen werden. So war es
einfach möglich, eine Animation in Adobe Flash mit IK-Bones zu erstellen und diese als „Sprite-
Sheet“ für Adobe Edge Animate zu exportieren. Mit diesem „Sprite-Sheet“ konnte so problemlos in
Adobe Edge Animate weitergearbeitet werden.
3.2.5. Hippo Animator
Für die Projektentwicklung wurde schließlich entschieden, dass Hippo Animator 3 zum Einsatz
kommt. Dieses „HTML 5“-Authoring-Tool war finanziell tragbar und konnte mit den
konkurrierenden Lösungen mithalten. Allerdings stellte sich nach ausgiebigeren Tests heraus, dass
diese Animationssoftware sehr fehleranfällig war. Beim Import größerer Dateien kam es zu
unerklärlichen Programmabstürzen. Diese Abstürze ließen sich vorerst nicht beheben. Nach
mehreren Tests auf unterschiedlichen Computern, wurde das Problem ausschließlich der
Animationssoftware zugeordnet. Nach einem Update kam die langersehnte Fehlermeldung, die
besagte, dass der Arbeitsspeicher voll ist und es daher zum Absturz kommt. Dieser Meldung war
nicht so einfach zu glauben, da ein Computer mit 16 GB Arbeitsspeicher zum Einsatz kam und
dieser Speicher selbst bei rechenintensiven 3D-Animationsprogrammen nicht ansatzweise an die
Grenzen kam. Im weiteren Verlauf wurde der Projektentwicklerin die Adobe Creative Cloud als
Jahresabo zum Geburtstag geschenkt und so wurde Adobe Edge Animate wieder als
Animationssoftware herangezogen.
Die Abstürze und Probleme von Hippo Animator 3 waren allerdings nicht tragbar. Daher wurde
14dem Entwicklerteam eine Nachricht geschrieben, die den Fehler genau beschreibt. Nach kurzer
Zeit kam eine Entschuldigung und ein Update auf Hippo Animator 4. Die Fehler waren behoben
und Hippo Animator wurde neben Adobe Edge Animate eingesetzt.
Nach der Entwicklung des Navigationsgerüstes der interaktiven Anwendung wurde sich
ausschließlich für Hippo Animator 4 als „HTML 5“-Authoring-Tool entschieden. Der Grund für
die Entscheidung lag darin, dass Adobe Edge Animate zusammen mit Adobe Edge Reflow für jede
Seite eine eigene HTML- und CSS-Datei erstellt und somit die Ladezeiten des
Navigationsgerüstes deutlich höher waren. Hippo Animator 4 erstellte nur eine HTML-Datei.
Diese wird beim Start einmal geladen und lässt sich dann ohne weitere Ladezeiten abspielen.
4 . Proj e k t p l an u n g
Die Planung des Projektes war ein wichtiger Bestandteil des Projektverlaufes. Es wurde ein
Pflichtenheft erstellt, welches als Grundlage für die weitere Projektentwicklung erforderlich war.
Neben dem Pflichtenheft, wurde ein Flowchart zur Definition der späteren Navigationsstruktur
entwickelt. Um das Design des Graphical-User-Interfaces (GUI) festzulegen, wurde ein Storyboard
angefertigt, welches die GUI skizziert.
4.1. Anforderungsspezifikationen
Die Anforderungsspezifikationen der Multimediaanwendung wurden bereits im Pflichtenheft
definiert und festgelegt. Die Anwendung wurde in vier Unterkapitel aufgeteilt, die das Thema
„Mythos Wolf“ in die Unterthemen Einleitung, Märchen, Fabeln und Geschichten gliedert. Im
Folgenden werden die festgelegten Anforderungsspezifikationen in Muss-, Soll- und
Abgrenzungkriterien aufgeführt und erläutert.
154.1.1. Musskriterien
Die Musskriterien beschreiben, welche Anforderungen zwingend erforderlich sind. Im
Pflichtenheft wurden diese genau beschrieben und definiert. Um einen kurzen Überblick zu
erhalten, werden die jeweiligen Anforderungen grob aufgeführt und erläutert. Es wurden alle
Kriterien in der Projektentwicklung umgesetzt.
Erforderliche Anforderung Erläuterung
Dieses Kriterium war aufgrund urheberrechtlichen
Alle verwendeten Assets werden selbst erstellt. Standpunkten unabdingbar, da die Anwendung im
Internet zur Verfügung gestellt werden sollte.
Aufgrund der definierten Zielgruppe, musste
sichergestellt werden, dass auch Kinder im
Angezeigte Texte werden akustisch dargestellt. Kindergartenalter diese Anwendung benutzen können.
Daher konnte die Lese- und Schreibfähigkeit nicht
vorausgesetzt werden.
Die Anwendung „Mythos Wolf“ wird in vier Die Anwendung sollte ähnlich wie ein Buch aufgebaut
Unterkapitel aufgeteilt. sein. Daher wurden die Inhalte in Kapitel geteilt.
Das Unterkapitel wurde umgesetzt und behandelt die
Das erste Unterkapitel beinhaltet die Einleitung.
Einleitung des Themas „Mythos Wolf“
Das zweite Unterkapitel beinhaltet das Thema Das Unterkapitel wurde umgesetzt und zeigt
Märchen. unterschiedliche Märchen zum Thema „Wolf“.
Das dritte Unterkapitel beinhaltet das Thema Das Unterkapitel wurde umgesetzt und behandelt
Fabeln. unterschiedliche Fabeln zum Thema „Wolf“.
Das vierte Unterkapitel beinhaltet das Thema Das Unterkapitel wurde umgesetzt und behandelt das
Geschichten. Thema „Vom Wolf zum Hund“.
Die Inhalte wurden vereinfacht und mit Grafiken,
Inhalte werden spielerisch und kindgerecht
Animationen, Interaktionen und akustischer
vermittelt.
Hinterlegung umgesetzt.
Tabelle 1: Musskriterien
164.1.2. Wunschkriterien
Dieser Teil des Kapitels beschreibt, welche Anforderungen zusätzlich eingebaut werden können
aber nicht zwingend erforderlich sind. Hierbei handelt es sich um Zusatzfunktionen. Im
Pflichtenheft sind acht Wunschkriterien genau beschrieben. Bei der Projektentwicklung kam es
durch zeitlicher Begrenzung leider nicht zur Umsetzung von allen Wunschkriterien. In der
folgenden tabellarischen Ansicht ist dargestellt, welche Wunschkriterien erfüllt und nicht erfüllt
werden konnten:
Wunschkriterium Umsetzung
nicht erfüllt
Einbau einer Animation synchron zur Sprachausgabe (Film) im Kapitel Märchen.
Einbau Soundwiedergabe beim Öffnen des „Klapptürchens“ im Märchen „Die drei
nicht erfüllt
kleinen Schweinchen“.
Einbau einer klickbaren Animation vom Schweinchen anstatt einer Grafik im
erfüllt
Märchen „Die drei kleinen Schweinchen“.
Einbau einer klickbaren Animation bei den Pfannkuchen im Märchen „Der Wolf
erfüllt
und der Fuchs“.
Einbau einer Soundwiedergabe beim lachenden Fuchs im Märchen „Der Wolf und
erfüllt
der Fuchs“.
Einbau einer klickbaren Animation vom Brunnen anstelle einer Grafik im
erfüllt
Märchen „Der Wolf und die sieben Geißlein“.
Einbau einer klickbaren Soundwiedergabe anstatt einer Grafik der Standuhr im
erfüllt
Märchen „Der Wolf und die sieben Geißlein“.
Einbau eines Spiels zum Thema „Vom Hund zum Wolf I“. nicht erfüllt
Tabelle 2: Wunschkriterien
Das erste, zweite und letzte Wunschkriterium konnten leider nicht umgesetzt werden. Diese
fehlende Umsetzung lag am Zeitmanagement. Da es sich um Wunschkriterien handelte, wurden sie
in der Priorisierung der Projektdurchführung nicht an erster Stelle gesehen.
174.1.3 Abgrenzungskriterien
Die im Pflichtenheft definierten Abgrenzungskriterien beschreiben, auf welche Anforderungen
bewusst verzichtet wird. Dabei handelt es sich um Spezifikationen, die nicht dem Alter eines Kindes
entsprechen oder im Rahmen des Projektzeitraumes zu zeitaufwendig und schwierig sind.
Beispielsweise wurde in der Projektentwicklung bewusst auf englische Bezeichnungen in der GUI
verzichtet, da es nicht Projektbestandteil war, dem Kind eine Sprache zu lehren. Außerdem wurde
auf die Implementierung von Texteingaben verzichtet um Kinder im Kindergartenalter nicht zu
überfordern.
4.2. Flowchart
Das Flowchart wurde als wichtiger Bestandteil in die Projektplanungsphase aufgenommen. Dieses
ermöglichte, die Navigationsstruktur vorab zu planen und festzulegen. Auf dieser Basis ließen sich
weitere Projektinhalte wie das Storyboard oder das Navigationsgerüst schneller realisieren und
umsetzen.
Das erstellte Flowchart benötigte eine Dokumentengröße von 850 x 255 mm und passte somit
nicht mehr auf ein DIN A4-Dokument (297 x 210 mm) im Querformat. Außerdem war es sehr
komplex und schwierig zu überschauen (Abb. 4.1).
Mithilfe von Prof. Dr. Gerrit Jan Veltink konnte das Flowchart durch neue Konstrukte „kompakter“
und übersichtlicher realisiert werden (Abb. 4.2) mit dem endgültigen Ziel, die Dokumentengröße
auf ein DIN A4-Format zu reduzieren.
18Die neuen Konstrukte beinhalten die Sub-Charts und das Menü. Ein Sub-Chart (Abb. 4.3 links)
ermöglicht, Knoten zu gruppieren und diese Gruppe als Abstraktion darzustellen. Die Detailansicht
eines Sub-Charts wird auf einer weiteren Seite dargestellt (Abb. 4.3 rechts).
Ein Menü definiert eine feste Auswahl von Links und dient zur Darstellung expliziter
Navigationsmöglichkeiten zwischen allen Knoten eines Sub-Charts (Abb. 4.4). Anders als bei einer
impliziten Navigationsmöglichkeit, wird die explizite Navigation durch den Benutzer gesteuert.
194.3.1. Navigation
Im Folgenden soll die Navigation der Anwendung erläutert werden. Dem Hauptmenü folgt eine
Intro-Animation, die beim Start der Anwendung einmal ausgeführt wird.
Möchte der Anwender diese Animation erneut anschauen, muss dieser die Anwendung im Browser
neu laden. Vom Hauptmenü lässt sich zu jedem Kapitel navigieren. Die Kapitel der
Multimediaanwendung sind Einleitung, Märchen, Fabeln und Geschichten.
Klickt der Anwender auf ein Kapitel, erscheint das jeweilige Unterkapitel. Hier ist eine Art
Blätterfunktion wie im Buch vorhanden. Der Anwender kann vom Unterkapitel auf das nächste,
zum Kapitel passende, Unterkapitel navigieren. Es soll jederzeit möglich sein, sowohl vom Kapitel
als auch vom Unterkapitel zurück zum Hauptmenü zu gelangen. Der Anwender kann so jederzeit
auf die Bedienungsanleitung zurückgreifen ohne die Anwendung neu starten zu müssen.
Die Bedienungsanleitung soll vom Hauptmenü über einen Pop-Up-Link erreichbar sein.
204.3. Storyboard
Das Storyboard wurde auf Basis des definierten Flowcharts entwickelt. Um das Konzept der
Anwendung zu skizzieren, diente die Entwicklung des Storyboard zur Visualisierung des Graphical
User Interfaces (GUI) und der Benutzerschnittstellen. Es wurde eingesetzt um das Layout, die
Interaktionsmöglichkeiten und die Assets vor Projektdurchführung zu definieren.
Die Entwicklung des Storyboards war sehr zeitaufwendig, da dieses als Grundlage, zusammen mit
dem Flowchart, für die spätere Projektentwicklung eingesetzt werden sollte. Um diese Vorstellung
umzusetzen, musste das geplante Konzept sehr genau beschrieben werden. Außerdem war es
wichtig, die GUI möglichst detailliert zu skizzieren.
Mithilfe von Prof. Dr. Gerrit Jan Veltink wurde beim Storyboard ein neues Template umgesetzt.
Dieses Template gestaltete die Beschriftung des Storyboards wesentlich übersichtlicher, indem die
Auflistung der Assets unterteilt wurde in statische und dynamische Assets (Abb. 4.5).
Abb. 4.5: Beispielseite Storyboard
Das Storyboard bietet eine gute Diskussionsbasis von Auftraggeber und Auftragnehmer und ist
daher ein essentieller Bestandteil der Projektplanung.
215 . Proj e k td u rc h f ü hr u n g
Basierend auf dem zuvor entwickelten Konzept konnte die Implementierung der Anwendung
eingeleitet werden.
Zunächst wird die Erstellung der Assets mit der anschließenden Auswahl eines geeigneten
Dateiformats erläutert. Anschließend folgt eine Beschreibung der Problemstellung
unterschiedlicher Schriftarten im Internet. Dabei wird eine Lösungsmöglichkeit durch das
Einbinden sicherer Schriftarten mithilfe von Webfonts vorgestellt. Im letzten Abschnitt werden die
Skriptfunktionen von Hippo Animator in einem kurzen Vergleich zu Adobe Flash erläutert.
Anschließend wird eine Auswahl der verwendeten Skriptfunktionen bei der Entwicklung dieser
Web-Applikation aufgezeigt. An ausgewählten Stellen des Kapitels wird Adobe Flash als
Vergleichsobjekt zu Hippo Animator herangezogen.
5.1. Asseterstellung
Für die Applikation mussten eine Vielzahl von Assets wie Grafiken, Audio-Dateien und Texte
erstellt werden. Der Entwicklungsprozess der Asseterstellung beinhaltete die Aufnahme,
Digitalisierung, Bearbeitung, Konvertierung und Komprimierung der Dateien. Im Folgenden
werden die gewählten Dateiformate der Audio- und Grafikdateien begründet und erläutert. Im
Anschluss folgt eine Laufzeitanalyse der Ladezeiten unterschiedlicher Grafikformate.
5.1.1. Audio-Dateiformat
Die Applikation erforderte eine Vertonung von allen vorhanden Texten inklusive der beschrifteten
Buttons. Da einige Web-Browser mit dem Abspielen bestimmter Dateiformate Probleme
aufwiesen, musste zunächst analysiert werden, welches Format am häufigsten unterstützt wird.
Das Einbinden von Audiodateien in HTML 5 wird mithilfe von „HTML 5“-Audio-Tags gelöst.
Dabei stehen zwei Audio-Tags zur Verfügung (Abb. 5.1).
22Abb. 5.1: "HTML 5"-Audio-Tags [WWW14]
Eine Codedurchsuchung des erzeugten Quellcodes ergab, dass die Autorensoftware Hippo
Animator 4 das Audio-Tag zum Einbinden von Audio-Dateien verwendet.
Nach einigen Tests an unterschiedlichen Web-Browsern, stellte sich heraus, dass vor allem das
MP3-Format am häufigsten unterstützt wird. Die Untersuchungen wurden bei den gängigen und
aktuellen Web-Browsern wie Mozilla Firefox (34.0.5), Opera (26.0), Google Chrome (39.0.2),
Safari (8.0) und Internet Explorer (11.0.14) durchgeführt.
Das Ergebnis war, dass alle getesteten Web-Browser das MP3-Format unterstützen. Beim Test des
WAVE-Formates kam es beim aktuellen Internet Explorer und Safari zu Problemen.
Ein späterer Test bei einer veralteten Mozilla Firefox Version (18.0.1) unter Linux (Lubuntu 14.10)
zeigte, dass dieser sowohl beim WAVE- als auch beim MP3-Format Probleme hatte und die
Audio-Dateien nicht abspielte. Allerdings konnte hier mit einem Plug-In nachgeholfen werden um
das MP3-Format zu unterstützen. Anschließend wurde der Web-Browser aktualisiert und spielte
daraufhin beide Formate ab.
Der Test wurde anschließend nochmal genauer untersucht um sicherzustellen, dass keine
Betrachtung vergessen wurde und um die Validität des eigenen Ergebnisses zu überprüfen. Hier
stellt das W3C2 viele Statistiken zur Verfügung, die stetig aktualisiert werden. Anhand dieser
Statistiken (Abb. 5.2) konnten die eigenen Ergebnisse überprüft werden.
Abb. 5.2: HTML Audio - Browser Support [WWW14]
2 World Wide Web Consortium
235.1.1.1 Automatische Soundwiedergabe
Das Intro der Web-Applikation sollte neben der Animation vertont werden. Die Vertonung sollte
mit einer automatischen Soundwiedergabe zur Animation umgesetzt werden. Als Audio-Format
wurde auch hier das MP3-Dateiformat gewählt.
Am Ende der Projektentwicklung stellte sich heraus, dass diese Lösung bei mobilen Web-Browsern
zu Kompatibilitätsproblemen führt [Wij14]. Dabei erwarten die meisten mobilen Web-Browser
eine Benutzerinteraktion, wie das Betätigen eines Buttons, um eine Audio-Datei abzuspielen.
Abb. 5.3: Support von automatischer Soundwiedergabe mobiler Web-Browser [Wij14]
Abbildung 5.2 zeigt neben dem automatischen Abspielen auch den Support von
Schleifendurchläufen und der Stummschaltung von Audio-Dateien. Diese Features werden vor
allem von mobilen Geräten, die auf den mobilen Betriebssystemen Android und Apple iOS
aufbauen, nicht unterstützt. Da die meisten mobilen Geräte auf diesen Betriebssystemen basieren,
musste für die Tablet-Version der Web-Applikation die automatische Soundwiedergabe der Intro-
Animation angepasst werden.
245.1.2. Grafik-Dateiformat
Die Frage des richtigen Grafik-Dateiformates stellte sich bereits vor Beginn der Asseterstellung, da
einige Grafiken als Testobjekte dienten. Die Grafiken wurden mithilfe eines Grafik-Tablets in
Verbindung mit Adobe Illustrator und Adobe Photoshop erstellt. Für die Applikation sollten
skalierbare Vektorgrafiken verwendet werden, da diese in der Größe, ohne Qualitätseinbußen,
beliebig verändert werden können. Allerdings stellte sich heraus, dass die Ladezeiten bei einer
vergleichbaren Rastergrafik (PNG-Datei) geringer sind (Abb. 5.4). Dabei unterschieden sich die
unterschiedlichen Laufzeiten beider Grafikformate sowohl lokal als auch serverseitig. Allerdings
interessiert bei der Applikation vor allem die serverseitige Betrachtung, da diese im Internet zur
Verfügung stehen soll.
Abb. 5.4: Serverseitige Laufzeitanalyse zweier einfacher Grafikformate (SVG/PNG)
Die Dateigröße beider Grafikformate in Abbildung 5.4 war mit circa 400 Kilobyte vergleichbar. Die
SVG-Datei benötigte im Vergleich zur PNG-Datei ungefähr 400ms mehr Ladezeit (PNG-Datei
1258ms / SVG-Datei 1667ms). Der Grund hierfür sind die, im Format gespeicherten,
Referenzdaten.
Neben dem eigentlichen Dateiformat, spielte die Pinselwahl des Grafikprogrammes Adobe
Illustrator eine große Rolle. Je komplexer die Grafiken waren, desto länger dauerte die Ladezeit.
Hier ist allerdings anzumerken, dass die SVG-Datei im Vergleich zur PNG-Datei ein deutlich
höheres Datenvolumen aufwies und mit knapp 15 Megabyte ohnehin eine längere Ladezeit
benötigt als eine elfmal kleinere PNG-Datei mit 1,34 Megabyte. Beide Dateien wurden aus der
gleichen Grafik mit Adobe Illustrator berechnet. Abbildung 5.5 bildet die Laufzeiten beider
komplexen Grafiken ab. Dabei ist auf den unterschiedlichen Maßstab der Zeitskalen zu achten. Aus
diesem Test lässt sich schließen, dass eine so große SVG-Datei mit 48ms Ladezeit für eine
serverseitige Verwendung untragbar ist.
25Abb. 5.5: Serverseitige Laufzeitanalyse zweier komplexer Grafikformate (SVG/PNG)
Aufgrund der unterschiedlichen Laufzeiten, wurde das anfängliche Vorhaben, skalierbare
Vektorgrafiken zu benutzen, ausgeschlossen.
Ein weiterer Test sollte festlegen, welcher Grafikstil für die Applikation verwendet werden soll.
Hierfür wurden zwei Grafiken mit unterschiedlichen Pinseln angefertigt und als animierte GIF-
Datei auf den Server geladen. Trotz des heruntergerechneten GIF-Dateiformates, welches für seine
geringe Farbtiefe von bis zu 256 verschiedenen Farben pro Einzelbild bekannt ist und daher oft im
Online-Bereich Verwendung findet, ist die Dateigröße der komplexen Grafik mit 3,16 Megabyte
dreizehnmal größer als die der einfachen Grafik mit 246 Kilobyte.
Abb. 5.6: Serverseitige Laufzeitanalyse von zwei unterschiedlichen Pinseln (einfach/komplex)
In Abbildung 5.6 lässt sich ein deutlicher Unterschied der Laufzeiten erkennen. Auch hier muss auf
den unterschiedlichen Maßstab der Zeitskalen hingewiesen werden. Die Grafik, die mit dem
komplexen Pinsel erstellt wurde, benötigte eine knapp zwölfmal höhere Ladezeit.
Anhand der unterschiedlichen serverseitigen Laufzeitanalysen, wurde für die Applikation
schließlich der einfache Pinsel im PNG-Dateiformat gewählt.
Abbildung 5.7 zeigt eine Visualisierung der verwendeten Testgrafiken.
26Abb. 5.7: Unterschiedliche Pinselarten (links: komplex | rechts: einfach)
5.2. Schriftarten
Die Verwendung einer gewünschten Schriftart gestaltet sich im Bereich der Webentwicklung
schwierig. Wenn die Web-Applikation über das Internet auf eine Vielzahl von Computern
abgespielt wird, gibt es keine Garantie, dass die verwendete Schriftart auf diesen Computern
verfügbar ist.
In Adobe Flash war es möglich, eine Schriftart oder bestimmte Zeichenteilsätze einer Schriftart
einzubetten. Hierbei konnte Adobe Flash alle dazugehörigen Informationen in der erstellten
SWF3-Datei abspeichern. Damit wurde sichergestellt, dass eine Schriftart korrekt angezeigt wird,
auch wenn diese nicht auf dem Computer des Benutzers installiert ist.
In Hippo Animator gab es die Option der Schriftarteneinbettung nicht. Diese „HTML 5“-
Autorensoftware ließ allerdings zu, dass eine Schriftart in ein Bild konvertiert werden kann. Diese
Lösung wurde für diese Web-Applikation allerdings ausgeschlossen, da die Ladezeit aufgrund der
zahlreichen Assets ohnehin schon hoch genug war.
Auf Hinweis von Prof. Dr. Gerrit Jan Veltink wurde das Problem durch das Benutzen von „Google
Fonts“ gelöst. Über die Google Font API lassen sich eine Vielzahl von Schriftarten für eine
Internetseite nutzen. Mit dieser Möglichkeit wurde eine aufwendige Umwandlung und Einbindung
der Schriftart überbrückt.
3 Shockwave Flash Dateiformat
27Hippo Animator unterstützt die Möglichkeit, „Google Fonts“ zu nutzen. Dabei wird lediglich eine
Code-Zeile als erstes Element unterhalb des Head-Tags aufgerufen. Die erstellte HTML-Datei
von Hippo Animator ist sehr unübersichtlich und schwierig zu durchschauen. Daher sieht man in
Abbildung 5.8 die übliche Einbindung von „Google Fonts“ in einem HTML-Dokument und in
Abbildung 5.9 den Code-Abschnitt der erstellten HTML-Datei von Hippo Animator.
Abb. 5.8: Einbindung von „Google Fonts“ im Head-Tag eines HTML-Dokumentes
Abb. 5.9: Einbindung von „Google Fonts“ im HTML-Dokument von Hippo Animator (Code-Abschnitt)
Neben der Einbindung der Schriftart im Head-Tag des HTML-Dokumentes kann diese auch
mithilfe von Javascript oder per @import-Methode in der Stylesheet-Datei erfolgen [Aps14].
285.3. Skriptfunktionen
Für die Realisierung interaktiver Elemente stehen in Hippo Animator zahlreiche Skriptfunktionen
zur Verfügung. Diese lassen sich, vergleichbar mit den sogenannten Codefragmenten von Adobe
Flash, sehr leicht in die Applikation integrieren (Abb. 5.10).
Abb. 5.10: Vergleich der unterschiedlichen Realisierung von Skripfunktionen in Adobe Flash und Hippo Animator
Allerdings besteht der Unterschied, dass beide Authoring-Tools unterschiedliche Skriptsprachen
verwenden und sich daher die Funktionen in ihrer Syntax unterscheiden.
Adobe Flash verwendet dabei die eigens entwickelte Skriptsprache Actionscript. Diese ist aktuell in
der dritten Version vorzufinden. Actionscript ermöglicht einen programmierten Zugriff auf die
grafischen und technischen Möglichkeiten der Flash-Umgebung durch die Klassenbibliotheken von
Adobe.
Javascript hingegen ist zwar objektorientiert und dynamisch typisiert aber, im Gegensatz zu
Actionscript, klassenlos. Beide Skriptsprachen basieren dabei auf den ECMAScript-Standard 4, der
die Norm eines standardisierten Sprachkerns stellt [ECM11].
4 European Computer Manufacturers
295.3.1. Auswahl verwendeter Skriptfunktionen
Für die Realisierung der Web-Applikation wurden zahlreiche Skriptfunktionen benutzt. Diese
ließen unterschiedliche Zugriffe auf die eingebauten grafischen und technischen Elemente der
Entwicklungsumgebung von Hippo Animator zu.
Neben der Verwendung dieser Skriptfunktionen war der Einbau externer Javascript-Dokumente zur
Steuerung des Inhaltes zulässig. In der Projektrealisierung reichte oft die Kombination der
Skriptfunktionen für den vollen Funktionsumfang aus.
Im Folgenden werden die verwendeten Skriptfunktionen zur Steuerung der Sprachausgaben
mithilfe von Toggle-Buttons genauer betrachtet. Außerdem wird die Realisierung von Animationen
durch die Steuerung der Zeitleiste erläutert.
5.3.1.1. Steuerung der Sprachausgaben
In Hippo Animator wird zwischen einer Schaltfläche und Umschaltfläche unterschieden. Eine
Schaltfläche ist dabei als gewöhnlicher „Button“ definiert, der nach einen Klick oder „Mouseover“
eine bestimmte Aktion ausführt. Eine Umschaltfläche hingegen ist als Toggle-Button definiert und
kann dabei zwei unterschiedliche Zustände (aktiv/inaktiv) annehmen.
Abb. 5.11: Funktion eines Toggle-Buttons
30Sie können auch lesen
