Einsatz von WebGL zur Erstellung von Websites mit indexierbaren

Transcription

Einsatz von WebGL zur Erstellung von
Websites mit indexierbaren Inhalten
Christian Gerhards
MASTERARBEIT
eingereicht am
Fachhochschul-Masterstudiengang
Interactive Media
in Hagenberg
im September 2015
© Copyright 2015 Christian Gerhards
Diese Arbeit wird unter den Bedingungen der Creative Commons Lizenz
Namensnennung–NichtKommerziell–KeineBearbeitung Österreich (CC BYNC-ND) veröffentlicht – siehe http://creativecommons.org/licenses/by-ncnd/3.0/at/.
ii
Erklärung
Ich erkläre eidesstattlich, dass ich die vorliegende Arbeit selbstständig und
ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt
und die den benutzten Quellen entnommenen Stellen als solche gekennzeichnet habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner
anderen Prüfungsbehörde vorgelegt.
Hagenberg, am 28. September 2015
Christian Gerhards
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
1 Einleitung
1.1 Motivation . . . .
1.2 Problemstellung . .
1.3 Zielsetzung . . . .
1.4 Inhaltlicher Aufbau
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
2 Verwandte Arbeiten
2.1 Probleme und Lösungsmöglichkeiten
2.1.1 Performanz . . . . . . . . . .
2.1.2 Ontologien . . . . . . . . . .
2.2 WebGL . . . . . . . . . . . . . . . .
2.2.1 Geschichte . . . . . . . . . . .
2.2.2 Browser Plugins . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
5
5
6
6
6
3 Grundlagen
3.1 Ursprung von WebGL . . . . . . .
3.2 User-Experience und UI’s . . . . .
3.3 Suchmaschinenoptimierung . . . .
3.3.1 SEO Analyse . . . . . . . .
3.3.2 Onsite Optimierung . . . .
3.3.3 Offsite Optimierung . . . .
3.3.4 Controlling und Anpassung
3.3.5 Bekannte SEO Tools . . . .
3.3.6 Über Google . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
11
12
13
17
19
20
23
4 Stand der Technik
.
.
.
.
.
.
.
.
.
26
iv
Inhaltsverzeichnis
4.1
4.2
Frameworks und API’s für WebGL
4.1.1 Auflistung der Technologien
4.1.2 Unity . . . . . . . . . . . .
4.1.3 Unreal . . . . . . . . . . . .
4.1.4 Three.js . . . . . . . . . . .
4.1.5 X3DOM . . . . . . . . . . .
Weitere Technologien . . . . . . . .
4.2.1 Server Sent Events . . . . .
4.2.2 WebSockets . . . . . . . . .
4.2.3 WebRTC . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
26
29
29
30
30
30
30
31
5 Konzept
32
5.1 Gewähltes Szenario . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Identifizierte Anforderungen und Funktionen . . . . . . . . . 33
6 Realisierung
34
6.1 Technologieentscheidung . . . . . . . . . . . . . . . . . . . . . 34
6.2 Konzept zur Implementierung des Szenario . . . . . . . . . . 35
7 Implementierung
7.1 Implementierung in Unity . . . . . .
7.1.1 Scene Manager . . . . . . . .
7.1.2 Article Information Manager
7.1.3 UI Manager . . . . . . . . . .
7.1.4 Helper . . . . . . . . . . . . .
7.2 Implementierung in JavaScript . . .
7.3 Screenshots des Prototyps . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Ergebnisse
8.1 Responsive Webdesign . . . . . . . . . . . . . . . .
8.2 Mobile Devices . . . . . . . . . . . . . . . . . . . .
8.2.1 Akkulaufzeit . . . . . . . . . . . . . . . . .
8.2.2 Allgemeine Probleme . . . . . . . . . . . . .
8.3 User Experience . . . . . . . . . . . . . . . . . . .
8.3.1 Look . . . . . . . . . . . . . . . . . . . . . .
8.3.2 Feel . . . . . . . . . . . . . . . . . . . . . .
8.3.3 Usability . . . . . . . . . . . . . . . . . . .
8.4 Indexierungskriterien . . . . . . . . . . . . . . . . .
8.4.1 Geschwindigkeit . . . . . . . . . . . . . . .
8.4.2 Bereitstellung der Inhalte durch JavaScript
8.4.3 Crawling von Links . . . . . . . . . . . . . .
8.4.4 Gesamtergebnis . . . . . . . . . . . . . . . .
8.5 Besonders geeignete Inhalte . . . . . . . . . . . . .
8.6 Vergleich der Techniken . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
39
39
40
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
48
48
49
49
49
50
50
50
50
51
52
53
54
54
Inhaltsverzeichnis
vi
9 Resümee
56
9.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A Technische Informationen
A.1 Aktuelle Dateiversionen . . . . . . . . . . . . .
A.2 Details zur aktuellen Version . . . . . . . . . .
A.2.1 Allgemeine technische Voraussetzungen
A.2.2 Verwendung unter Windows . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
59
59
B Inhalt der DVD
60
B.1 Masterarbeit (PDF) . . . . . . . . . . . . . . . . . . . . . . . 60
B.2 Projekt Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Quellenverzeichnis
61
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Online-Quellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Vorwort
Diese Masterarbeit ist während des Studiengangs Interactive Media an der
Fachhochschule Oberösterreich - Campus Hagenberg entstanden.
Danken möchte ich vor allem meiner Freundin Lisa Müller, welche mir
mit Ratschlägen, Tipps und vielen Korrekturlesungen sehr geholfen hat.
Auch für das große Maß an Geduld möchte ich mich bei ihr bedanken.
Weiterhin möchte ich meiner Familie für Ihr Verständnis und ihre Geduld
danken, die sie mir während der Arbeit entgegengebracht hat.
Zudem danke ich FH-Prof. Mag. DI Dr. Andreas Stöckl für die Betreuung
während der Arbeit und seine investierte Zeit.
vii
Kurzfassung
In dieser Masterarbeit, werden unterschiedliche Möglichkeiten untersucht,
Inhalte die mit WebGL dargestellt werden, für Suchmaschinen indexierbar
zu machen. Ziel ist es, aufzuzeigen welche Technologien für diesen Zweck
sinnvoll eingesetzt werden können und wie effektiv, effizient und zufriedenstellend diese Ansätze sind.
Hierzu werden Informationen zu Frameworks, API’s und Technologien
aus dem Bereich WebGL und anderen 3D-Web-Bibliotheken recherchiert
und untersucht. Dadurch soll ein erster grober Einblick in den aktuellen
Stand der Technik und die Möglichkeiten, die diese Technologien bieten,
aufgezeigt werden.
Anschließend wird mit ausgewählten Technologien aus diesem Bereich,
eine beispielhafte Prototypen-Anwendung zu dem Szenario eines Online
Shops, mit WebGL umgesetzt. Anhand dieser Umsetzung soll gezeigt werden, welche Möglichkeiten die gewählten WebGL Technologien bieten, um
die Indexierung von WebGL Inhalten zu ermöglichen.
Nach einer Einführung in den Bereich der SEO1 Grundlagen, User Experience im Bereich 2D, 3D und der zugrunde liegenden Technologie von
WebGL, werden einzelne WebGL Frameworks vorgestellt. Dann wird ein
Konzept der umzusetzenden Beispielanwendung erstellt und die Implementierung dieser beschrieben.
Die Ergebnisse aus dem umgesetzten Szenario werden anschließend, in
Bezug auf wichtige Aspekte der heutigen Webentwicklung, erläutert.
1
Search Engine Optimization.
viii
Abstract
In this master thesis different possibilities are going to be tested, how to
make content indexable for search engines which is generated by WebGL.
Finally it should be shown which technology is the best and how effective,
efficent and satisfying these possibilities are.
Therefore information about frameworks, API’s and technologies around
the topics WebGL and other 3D-web-libraries is going to be collected and
tested. This should show the state of the art and the possibilities of these
technologies.
Moreover one technologie of the researched ones is going to be chosen
to develop an example application for a different scenario of an online shop
with WebGL. On the basis of these example it should be shown what the
WebGL technologies offer to index WebGL content.
After a short excursion to the basics of SEO, user experience in the field
of 3D and WebGL, different WebGL frameworks are going to be presented.
Afterwards a concept of the example application should be created and the
implementation described.
The results of the example scenario are finally going to be evaluated
depending on important aspects of todays web development.
ix
Kapitel 1
Einleitung
1.1
Motivation
In der heutigen Zeit müssen Websites nicht nur ansprechend aussehen, sondern auch semantisch gut ausgezeichneten Inhalt enthalten. Die Anforderungen des Web 3.01 spielen bereits eine wichtige Rolle. Diese Art von Content
ist aber nicht nur hierfür relevant, sondern ist auch ein wichtiger Bestandteil
einer guten Suchmaschinenoptimierung. Weiterhin nimmt die Zahl der Nutzer von mobilen Endgeräten immer weiter zu und somit auch die Nutzung
von mobilen Websites.
Um Websites auch auf diesen Geräten effektiv und effizient zur Verfügung zu stellen, ist Responsive Webdesign eine beliebte Herangehensweise.
Der Nachteil ist jedoch, dass Websites mit einem flexiblen Raster, oft 12spaltig, sich häufig sehr ähneln und die gestalterische Einzigartigkeit, Individualität und Wiedererkennbarkeit daher verloren gehen. Mit WebGL besitzt
das Web eine vollwertige Grafikpipeline, die ein starkes Werkzeug sein kann,
um Websites auf ein neues interaktives Niveau zu heben und zudem innovative gestalterische Möglichkeiten erlaubt, welche zuvor nur mit externen
Plugins möglich waren. Ein Problem, stellt hier jedoch der Inhalt dar, der
mit einer solchen Grafik-API dargestellt wird. Der Inhalt wird nach außen
hin gekapselt und ist somit nicht maschinenlesbar, was an alte Flash Zeiten
erinnert, da auch hier die Inhalte für Suchmaschinen uneinsehbar waren.
Ein konkretes Szenario, für einen interessanten Einsatz dieser Technologie, könnte beispielsweise ein Online-Store bieten. In der Regel geben Kunden auf einem solchen Portal einen Suchbegriff ein und erhalten eine Auflistung mit verschiedenen Artikeln mit Bildern und Preisen, und entscheiden
sich dann ob sie diesen Artikel kaufen möchten. Ein spielerischer EchtzeitEinkauf, in einem 3-dimensional gerenderten Einkaufszenario würde eine
interessante und neue Alternative darstellen. Zudem gibt es mit neuartiger
Hardware, wie beispielsweise der Oculus Rift, die Möglichkeit in diese neuen
1
Semantic Web.
1
1. Einleitung
2
Einkauflandschaften durch virtuelle Realität, vollständig einzutauchen. So
könnten neue interaktive, virtuelle, themenbasierte Einkaufslandschaften geschaffen werden, welche atmosphärisches einkaufen ermöglichen. Interessant
sind auch die Fortschritte im Bereich der Augmented Reality, welche durch
Technologien, wie der HoloLens oder der MagicLeap, das erweitern der Realität um virtuelle Gegenstände, auf ein völlig neues Level heben. Beispielsweise könnten Möbelstücke somit für den Benutzer sichtbar in den Raum
projiziert werden, um so einen optischen Vergleich mit der Realität zu erlauben und einen realeren Eindruck zu vermitteln.
1.2
Problemstellung
Inhalte in WebGL werden durch die GPU2 gerendert und sind dadurch nicht
interpretierbar für externe Ressourcen. Suchmaschinen-Roboter benötigen
die Informationen in Form von HTML, um diese indexieren zu können. Daher befinden sich grundsätzlich alle Inhalte in WebGL in einer Blackbox,
die nach außen keine Möglichkeiten zur Interpretation bereitstellt. Weiterhin tritt das Problem auf, dass mobile Endgeräte eine relativ schwache GPU
aufweisen und daher Probleme mit dem rendern von WebGL Szenen aufweisen.
1.3
Zielsetzung
Ziel dieser Arbeit ist es, Möglichkeiten und Ansätze von Technologien, für die
Bereitstellung der relevanten Informationen einer WebGL Szene, zu untersuchen und zu erläutern. Hierzu wird ein Szenario, mit einer vorher spezifizierten Technologie, umgesetzt. Diese Beispielanwendung wird anschließend
nach aktuellen Kriterien der Webentwicklung bewertet. Hierdurch können
die Möglichkeiten, die diese Technologie bietet, aufgezeigt und auf ihre Vorzüge und Defizite, für die Bereitstellung von indexierbaren Informationen
für WebGL, evaluiert werden.
Das gewählte Szenario befasst sich mit der Umsetzung eines prototypischen Online-Shops in WebGL. Hierbei sollen die typischen Möglichkeiten,
die eine Standard Webanwendung bietet, in einer WebGL Umgebung umgesetzt werden, um dann überprüfen zu können, welche Informationen und
Inhalte von einer Suchmaschine erfolgreich indexiert werden können.
Konkret untersucht wird:
• Welche aktuellen Technologien für die Darstellung von 3D Inhalten im
Web existieren?
• Welche aktuellen Frameworks, API’s, Engines, Bibliotheken existieren
für WebGL?
2
graphics processing unit – Grafikprozessor.
1. Einleitung
3
• Welche allgemeinen Features und Nachteile bieten diese Technologien?
• Welche Technologien, Technologie Stacks/Kombinationen eignen sich
für die Bereitstellung von indexierbaren Informationen in Verbindung
mit WebGL am besten?
• Evaluierung der Technologien in Bezug auf aktuelle Aspekte der Webentwicklung.
• Wie ist die Zukunft von WebGL einzuschätzen?
Konkret umgesetzt wird: Eine WebGL Anwendung mit einer spezifizierten
Technologie für einen prototypischen Online Shop.
1.4
Inhaltlicher Aufbau
Die Arbeit unterteilt sich in 4 Abschnitte. Angefangen mit einer Einleitung
und den Grundlagen. Gefolgt von der Umsetzung des Szenario. Zuletzt erfolgt die Erläuterung der Ergebnisse, sowie ein Resümee und Ausblick.
Kapitel 1, enthält die Motivation, Problemstellung und konkrete Zielsetzungen der Arbeit. Welche Vorteile könnte WebGL dem Web bieten? Welche
Probleme existieren bei dem Einsatz von WebGL und wie sieht die konkrete
Zielsetzung dieser Arbeit aus?
Kapitel 2, erläutert bekannte Probleme und Lösungsmöglichkeiten und gibt
einen kurzen Überblick zu WebGL.
Kapitel 3, erklärt die Grundlagen zu Suchmaschinenoptimierung, den 3D
Technologien in Bezug auf WebGL und Grundwissen zu Usability in Bezug
auf 2D - 3D User Interfaces.
Kapitel 4, werden aktuell existierende Frameworks, API’s, Bibliotheken und
Engines für die Entwicklung von WebGL Anwendungen vorgestellt. Hier
werden bereits erste Features der Technologien und Unterschiede genannt.
Kapitel 5, erläutert das Szenario, das mit der gewählten Technologie umgesetzt wird. Anschließend werden hieraus die benötigten Funktionalitäten,
konkret für die benötigte Anwendung, abgeleitet.
Kapitel 6, erklärt wie das konzipierte Szenario umgesetzt werden soll. Hier
wird dargestellt, welche Technologie zum Einsatz kommt und warum diese
gewählt wurde.
Kapitel 7, zeigt die einzelnen Implementierungen des Szenario. Weiterhin
werden die Kernfunktionalitäten und deren Funktionsweise erläutert. Zudem
enthält es Abbildungen, welche die umgesetzte Anwendung zeigen. Anhand
kurzer Erläuterungen werden diese erklärt.
1. Einleitung
4
Kapitel 8, beschreibt die Ergebnisse des Szenarios. Hier werden die Vorteile
und Nachteile aufgezählt, die in Bezug auf die aktuellen Aspekte der Webentwicklung, auftreten. Zudem wird erklärt, als wie effektiv und effizient
sich die Lösungsmöglichkeiten, erweisen.
Kapitel 9, enthält das Resümee der gesamten Arbeit und einen Ausblick auf
zukünftige Möglichkeiten für WebGL.
Kapitel 2
Verwandte Arbeiten
Dieses Kapitel behandelt Ansätze zur semantischen Auszeichnung von 3D
Szenen, erklärt kurz bekannte Probleme und Lösungsmöglichkeiten und gibt
einen kurzen Überblick zu WebGL.
2.1
2.1.1
Probleme und Lösungsmöglichkeiten
Performanz
WebGL wird von der GPU der Grafikkarte ausgeführt. Berechnungen erfolgen demnach durch die Grafikkarte und nicht durch die CPU des Rechners.
Dies ist gleichzeitig ein Vorteil und ein Nachteil. Auf schnellen Rechnern
mit einer guten Grafikkarte wird hier die CPU entlastet und die Ressourcen
können anderweitig verwendet werden. Jedoch führt dies auf Systemen mit
schwächeren Grafikkarten zu Performanz Einbußen. Besonders die mobilen
Geräte sind hiervon betroffen. Smartphones und Tablets besitzen meist eine
deutlich leistungsschwächere GPU, als moderne Desktopsysteme. Das führt
dazu, dass Webanwendungen, die WebGL nutzen, meist nicht ordnungsgemäß auf dem mobilen Gerät funktionieren oder überhaupt nicht ausführbar
sind. Hierzu kommt noch hinzu, dass JavaScript durch einen Just-in-Time
Compiler kompiliert wird. Diese Technik ist grundsätzlich langsamer bei der
Ausführung, als eine Ahead-over-Time Kompilation. Lösungsmöglichkeiten
bietet hier bereits ein JavaScript Subset namens asm.js. Ein asm.js Programm verhält sich identisch, egal ob es in einer existierenden JavaScript
Engine oder einer ahead-of-time kompilierenden Engine für optimierte Geschwindigkeit ausgeführt wird [19].
2.1.2
Ontologien
Durch den Einsatz von Ontologien1 für die Beschreibung einer WebGL Szene, könnten sich effizient, semantische Informationen, über die 3D-Szene
1
Eine Ontologie ist ein formales Wissensmodel.
5
2. Verwandte Arbeiten
6
bereitstellen lassen. Um diese Informationen jedoch nutzen zu können, müssen Crawler existieren, die diese Inhalte auch interpretieren können. Da die
vorhandenen Suchmaschinen ein solches Feature nicht unterstützen, ist das
anbieten einer Ontologie aus Gründen der Suchmaschinenindexierung relativ
irrelevant. Mit dem Wachsen des Web 3.0 – Semantic Web, gewinnen diese Technologien jedoch immer weiter an Relevanz. Siehe die Rich Snippets
unter Abschnitt 3.3.2 von Google. Eine interessante Ontologie stellt die Multilayered Ontology von Walzcak dar [8]. Diese Ontologie ist in verschiedene
Schichten unterteilt, die je nach Art der 3D Szene, nur teilweise oder gesamt
genutzt werden. Einfache Szenen mit statischen Modellen benötigen hierbei
nur die untersten Schichten der Ontologie, während komplexere Szenen mit
Animationen alle Beschreibungsschichten beanspruchen. Eine weitere relevante Ontologie für diesen Bereich stellt der MPEG-7 ISO Standard dar,
dessen Erweiterung für die Annotation von komplexen Web 3D Szenen in
[13] beschrieben wird.
2.2
2.2.1
WebGL
Geschichte
WebGL ist eine Grafik-Bibliothek und Programmierschnittstelle für 2D- und
3D Elemente. Sie wurde für die Nutzung im Webbrowser entwickelt. Die ersten Anfänge fanden bei Mozilla 2006 statt, mit ersten Canvas-Experimenten
[20]. Seit 2009 besteht die Khronos Group, welche sich um die Weiterentwicklung und Festlegung der Standards zu WebGL kümmert. Mitglieder sind
unter anderem Mozilla, Pixar, Apple und Google.
WebGL nutzt das HTML Canvas Element um Inhalte darzustellen. Da
die Grafikschnittstelle JavaScript als Programmiersprache verwendet, besitzt sie ebenfalls einen Garbage Collector, der die Arbeit erleichtern kann.
2.2.2
Browser Plugins
Unity WebPlayer Plugin
Das Unity Webplayer-Plugin ist noch aus der Zeit vor WebGL und wurde
entwickelt um Programme, die mit der Unity Engine entwickelt wurden, im
Browser anzuzeigen.
X3DOM Browser Plugin
Das X3DOM Plugin für den Browser, ist mittlerweile veraltet und sollte
nicht mehr verwendet werden, da die aktuelle Version bereits WebGL verwendet.
Kapitel 3
Grundlagen
In diesem Kapitel werden die Grundlagen zu SEO, WebGL zugrunde liegenden Technologien und Historie, sowie relevante User Experience Aspekte
näher erläutert.
3.1
Ursprung von WebGL
In den Anfängen des Web bestand die einzige Möglichkeit darin, die GPU
mit dem rendern von 3D Inhalten zu beauftragen, in dem Einsatz von Java
Applets. Hierzu wurde die Java Bibliothek JOGL1 genutzt. Da Java jedoch
eine Virtuelle Maschine nutzt, worüber der Browser keine Kontrolle hat,
nahm die Nutzung über die Jahre ab. Eine neue Möglichkeit für die Darstellung von 3D Inhalten bot hier die Technologie Flash von der Firma Adobe.
Mit der Bibliothek Stage3D war es ebenfalls möglich die GPU mit dem rendern von Inhalten zu adressieren. Ein von Anfang an vorhandenes Problem
bei Flash war jedoch, dass die Software keine offene und freie Lösung war,
sondern ein geschütztes Produkt der Firma Adobe. Das diese Technologie
als valider Standard für das Web 2.0 akzeptiert werden würde, war daher
sehr unwahrscheinlich. Java und Flash waren demnach nicht geeignet als
Standard 3D-Technologie für das Web 2.0 [23].
Die ersten Experimente, die den Grundstein für das spätere WebGL
darstellten fanden 2006 statt. Damals entwickelte Vladimir Vukićević von
der Firma Mozilla einen ersten 3D Canvas Prototypen, der OpenGL ES 1.1
nutzte [20]. Nach diesem ersten Erfolg gründete die Khronos Group 2009 die
WebGL Working Group. Die Khronos Group ist ein nicht-profitorientiertes
Industriekonsortium, das sich mit der Erstellung von Open-Standard kostenfreien API’s für den Multimedia Bereich beschäftigt [28]. Unter anderem
gehören zu dessen Mitgliedern Mozilla, Apple, Google und Opera. Im Jahr
2011 wurde die erste Version von WebGL released [29]. Zum Zeitpunkt der
Arbeit stellt WebGL 2.0, basierend auf OpenGL ES 3.0, die aktuellste Ver1
Java OpenGL.
7
3. Grundlagen
8
sion dar. Diese Version befindet sich jedoch noch in der Entwicklungsphase.
Daher wird WebGL 1.0 bisher noch von mehr Browsern unterstützt. Ein
Unterschied zwischen diesen Beiden Versionen besteht beispielsweise in der
Anzahl an gleichzeitig renderbaren Texturen. WebGL 1.0 ist nur in der Lage
8 Texturen gleichzeitig zu rendern, wohingegen WebGL 2.0 diese Anzahl auf
32 erhöht [43].
3.2
User-Experience und UI’s
Usability2 ist ein wichtiger Faktor in der Entwicklung von Software-Anwendungen
jeglicher Art und spielt heutzutage eine wichtigere Rolle als je zuvor. Das
Ergebnis von guter Usability beeinflusst direkt die User-Experience3 .
Die Abbildung 3.1 zeigt, dass sich UX in 3 Bestandteile unterteilen lässt.
Jeder der Bestandteile besitzt unterschiedliche Kriterien, die bei der Erzeugung positiver UX eine entscheidende Rolle spielen [41].
• Look Ist das Anwendungs-Design ästhetisch ansprechend und wirkt
es vertrauensvoll?
• Feel Wie angenehm ist es für den Nutzer die Anwendung zu nutzen?
• Usability Ist die Bedienung intuitiv (Effizienz)? Kann das gewünschte
Ziel mit der Funktionalität erreicht werden (Effektivität)? Verhält sich
die Anwendung wie vom Nutzer erwartet (Zufriedenheit)?
UX spielt besonders bei Anwendungen auf mobilen Geräten eine entscheidende Rolle, da der Nutzer hier nur begrenzte Möglichkeiten hat mit der
Anwendung zu interagieren, i.d.R. antippen und wischen mit den Fingern.
Zudem sollen auch Nutzer diese Apps bedienen können, die keinerlei Erfahrung mit Informationstechnologien besitzen. D.h. die Bedienung der Software sollte soweit wie möglich intuitiv erfolgen können. Dieser Effekt kann
meistens erzeugt werden, indem bereits bekannte Bedienkonzepte aus der
Realität abgeleitet werden, um diese dann in der Software nachzubilden.
Besonders im Bereich der User-Interfaces4 von Software-Anwendungen
spielt die UX eine konkrete Rolle. User-Interfaces werden in den meisten Fällen im 2-dimensionalen Raum dargestellt, also vollständig mit 2D Elementen
(siehe Abb. 3.2).
Bessere Möglichkeiten könnte jedoch das Einsetzen von 3D Elementen
bieten, da diese die Wirklichkeit unserer 3-dimensionalen Welt genauer widerspiegeln. Wir lernen in unserem Leben, wie sich gewisse Dinge verhalten
2
Das Ausmaß, in dem ein Produkt durch bestimmte Benutzer, in einem bestimmten
Nutzungskontext, genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.
3
Auch Nutzererlebnis, umschreibt alle Aspekte der Erfahrungen eines Users bei der
Interaktion mit einem Produkt, Dienst, einer Umgebung, Software oder Einrichtung, kurz
UX.
4
Die Abkürzung lautet UI.
3. Grundlagen
9
Abbildung 3.1: User-Experience Bestandteile [22].
Abbildung 3.2: Android Lollipop Desktop.
3. Grundlagen
10
Abbildung 3.3: Beispiel für 2.5D auf einer Portfolio Website [16].
und funktionieren und können dieses Wissen so gezielter in Anwendungen
nutzen. Hierzu gibt es bereits erste Ansätze, jedoch stellen diese meist nicht
einen vollständigen 3-dimensionalen Raum dar, sondern das User Interface
besteht hier meistens aus 2.5D5 Komponenten. Ein Beispiel eines 2.5D Interface wird in Abbildung 3.3 dargestellt. Ein Video6 auf der Plattform
Youtube zeigt, wie die Navigation und Interaktion durch den Nutzer auf
einem Tablet mit einem 2.5D UI aussehen kann.
Erste Ansätze und Ideen wie ein vollständiges 3D Interface die Benutzerführung und die User-Experience, im Gegenzug zu normalen 2D Interfaces
verbessern kann, wird in einem Vortrag von Erik Mansson gezeigt. Hier werden unter anderem 3 Säulen genannt, die die Vorteile von 3-dimensionalen
Inhalten gegenüber 2-dimensionalen Inhalten verdeutlichen sollen [17].
Nach Mansson lauten diese 3 Säulen, die sogenannten „Pillars of 3D
Quality“ wie folgt:
• Flexible Information Visualization (FIV):
– skalierbare UI’s zum organisieren von kleinen bis riesigen Datensätzen (dots, cloud UI’s),
– umfangreichere Übersichtsmöglichkeiten, nutzen von intuitiven,
erlernten Navigationsmöglichkeiten/Metaphern,
5
6
2D Elemente die sich in einem 3D Raum befinden und sich 3-dimensional bewegen.
https://www.youtube.com/watch?v=FtR_zA9elrM
3. Grundlagen
11
– Inhalt selbst als UI.
• Naturalized Interaction (NI):
– baut auf dem menschlichen Verständnis von Raum und physikalischer Beschaffenheit von Objekten auf,
– Intuitive und leicht verständliche Interaktions Möglichkeiten,
– Kognitive Belastung des Nutzers wird reduziert, Nutzen und Verstehen ist intuitiver.
• Visual Style & Feedback (VSF):
– mehr Möglichkeiten für Design und Layout,
– stärkere Produktdifferenzierung und stärkere visuelle Ausdruckskraft, die funktionale Möglichkeiten und ästhetische Reize bieten.
Bei dem Einsatz von 3D Elementen im Interface sollte darauf geachtet werden, bei welchen Interaktionen es Sinn macht diese durch 3-dimensionale
Komponenten zu ermöglichen. Zudem spielt es auch eine Rolle, ob es für
die Anwendung überhaupt sinnvoll ist von einem 2-dimensionalen Interface
wegzugehen. Als schwierig erweist sich die Steuerung eines Objektes in einem
3-dimensionalen Raum, wenn diese nur mit Hilfe von Touchgesten durchgeführt werden kann. Auf einem Tablet und Smartphone sind dies die Einzigen
primären Interaktionsmöglichkeiten.
Die Abbildung 3.4 zeigt eine Anwendung, die bereits etwas über das 2.5D
Konzept hinaus geht und dessen Bedienung durchaus intuitiv erfolgt. Durch
das Verwenden von Shadern, Texturen und Bumpmaps7 entsteht eine realistische, visuelle Repräsentation von Interaktionselementen. Hierdurch und
zusammen mit der 3-dimensionalen Darstellung, weiß der Nutzer direkt wie
diese zu bedienen sind, da die Elemente aus der Realität sehr genau nachgebildet werden. Die Erfahrung, die der User in der Realität mit physischen
Bedienelementen bereits gemacht hat, kann somit einfacher wiederverwendet werden. Zudem fällt es dem Nutzer auch leichter, die Funktion einer
unbekannten Komponente zu erkennen, wenn diese sich visuell und vom
erwarteten Verhalten, in Bezug zur Realität weniger unterscheidet.
3.3
Suchmaschinenoptimierung
Bei der Optimierung einer Website für gängige Suchmaschinen sind mehrere Dinge zu beachten. Der Google Algorithmus berücksichtigt mehr als 200
Kriterien, die für die Bewertung einer Website und die damit verbundene
Darstellung in den SERPS8 eine Rolle spielen [9]. Nur zu einigen Kriterien hat sich Google bisher aktiv geäußert, dass diese der Google-Bot wirk7
Bumpmaps ist ein Sammelbegriff für Texturen, die Höhen und Tiefen auf 2dimensionalen Strukturen simulieren.
8
Search Engine Result Pages.
3. Grundlagen
12
Abbildung 3.4: 3D Zylinder mit 3D Interaktions-Komponenten [17].
lich berücksichtigt. Über die Restlichen können nur Vermutungen angestellt
werden. Im Folgenden wird genauer auf den Prozessablauf und die einzelnen Phasen einer SEO-Kampagne eingegangen und die damit verbundenen
Optimierungsmöglichkeiten, die für den Google-Algorithmus durchaus ein
Bewertungskriterium darstellen.
3.3.1
SEO Analyse
Es wird mit der Ermittlung der Zielgruppen begonnen, indem jede potenzielle Zielgruppe mehrere Ziele erhält, um anschließend jeder einzelnen Gruppe
eine Priorität zuordnen zu können. Bei der Wahl der Zielgruppen spielt die
Customer Journey ebenfalls eine wichtige Rolle. Darunter versteht man die
fünf Phasen die jeder Kunde durchläuft bis er sich zum Kauf eines Produktes
entscheidet.
Customer Journey [9]:
•
•
•
•
•
Phase
Phase
Phase
Phase
Phase
1: Awareness – Das Bewusstsein für das Produkt wird geweckt,
2: Favorability – Das Interesse für das Produkt wird verstärkt,
3: Consideration – Der Kunde erwägt den Kauf des Produktes,
4: Intent to purchase – Die Kaufabsicht wird konkret,
5: Conversion – Das Produkt wird gekauft.
Für jede einzelne Zielgruppe sollten ebenfalls Teilziele festgelegt werden, die
den einzelnen Phasen der Customer Journey entsprechen [9]. Anschließend
kann mit der Ermittlung der Keywords begonnen werden. Nach welchen
Wörtern und Phrasen suchen unsere potenziellen Zielgruppen? Für diese
Aufgabe kann das Tool Keyword-Planer von Google AdWords verwendet
3. Grundlagen
13
werden. Jenes gibt Aufschluss darüber, welche Suchwörter wie häufig in
die Google Suchmaschine eingegeben werden und gibt ebenfalls Vorschläge zu verwandten Suchanfragen. Ergänzend kann das Tool Google Trends
verwendet werden, um die Keywords hinsichtlich des Suchaufkommens für
bestimmte Regionen, Kategorien und Zeiträume zu ermitteln.
3.3.2
Onsite Optimierung
Wenn die Keywords bekannt sind, hinsichtlich denen unsere Website optimiert werden soll, kann mit der Onsite Optimierung begonnen werden.
Hierunter wird größtenteils die Optimierung der Inhalte verstanden, die sich
direkt auf dem Webserver befinden.
XML Sitemap
Die XML-Sitemap stellt eine strukturierte Auflistung aller Webpages der
Website dar. Sie ermöglicht es Suchmaschinen die Website mit allen vorhandenen Unterseiten schnell zu indexieren. Auch Änderungen an der WebsiteStruktur können Google so schneller mitgeteilt werden. Hierfür bietet Google
in der Anwendung Webmaster-Tools, die Möglichkeit an, die entsprechende
Sitemap per URL einzulesen, auf Fehler zu überprüfen und direkt an den
Index zu übermitteln.
robots.txt
Die robots.txt Datei ist ein Textfile, das angibt, welche Inhalte von Suchmaschinen indexiert werden dürfen. Hierbei können genaue Angaben dazu
gemacht werden, welche Suchmaschine welche Ordner oder Dateien durchsuchen darf oder welche nicht durchsucht werden dürfen. Hierbei ist zu erwähnen, dass die Suchmaschinen sich keinesfalls verpflichtend an diese Angaben
halten. Zu Google ist jedoch bekannt, dass diese durchaus die Angaben der
robots.txt beachtet. Beispielsweise sollte das Crawlen von Dateien wie 404Pages, Impressen und Ergebnis-Seiten von Formularen verneint werden.
Keywords
Eine Landing-Page, zu einem bestimmten Keyword, sollte dieses in der URL,
in der Überschrift ersten Grades, sowie in den Meta-Tags und Title-Tag
enthalten sein. Hierbei sollte das Keyword im Title-Tag direkt am Anfang
stehen. Die Überschrift ersten Grades, sollte pro Seite nur einmal verwendet
werden und ebenfalls das Keyword enthalten. Das Meta-Tag für die description sollte den Inhalt der Webpage kurz beschreiben und keinesfalls für
alle Unterseiten gleich sein [6]. Die Website-Description wird auch auf der
SERPS unter den jeweiligen Ergebnissen angezeigt.
3. Grundlagen
14
Images
Den Bildern auf Websites sollten entsprechende Namen vergeben werden, die
den Inhalt des Bildes beschreiben. Zusätzlich sollte zwingend ein alt-Attribut
vergeben werden, das kurz beschreibt, was auf dem Bild dargestellt wird.
Dieser beschreibende Text wird von Screenreadern gelesen und angezeigt
wenn die Bilder nicht dargestellt werden.
Ajax
Ajax kann für Suchmaschinen ein Problem darstellen, weil der Request durch
die Ajax-Engine ausgeführt wird und kein normaler Pageload stattfindet.
W3C Validität
Ob die W3C Validität eine der 200 Kriterien von Google ist, die für die
Platzierung der Website in den Suchergebnissen eine Rolle spielen, ist seitens Google noch nicht bestätigt worden. Aber eine Fehlerfreie Website, die
HTML konformen Code nach dem W3C Standard enthält, trägt dazu bei,
dass Suchmaschinen die Inhalte einwandfrei indexieren können [9].
Duplicate Content
Webpages die unter mehreren URLs erreichbar sind sollten vermieden werden, da Google z.b. eine Webpage die unter mehreren URL’s erreichbar ist
als Täuschung wertet, weil der gleiche Inhalt mehrmals angeboten wird. Um
den gleichen Effekt bei der Verwendung von mehreren Domains zu vermeiden, sollten sogenannte canonical-links eingesetzt werden. Hierdurch wird
Google mitgeteilt, welche URL zu Anzeige auf der SERP verwendet werden
soll.
Link Namen
Für die interne Verlinkung von internen oder externen Webpages sollten immer aussagekräftige Link-Namen vergeben werden, die den Inhalt der Zielseite beschreiben. Links wie hier oder klick mich sollten vermieden werden,
da Google den Namen und den Inhalt der Zielseite versucht miteinander in
Beziehung zu setzen. Das Keyword hier wird beispielsweise mit dem Adobe
Reader assoziiert, da viele Websites unter diesem Schlüsselwort den Adobe
Reader zum download anbieten [9].
NoFollow für Links
Matt Cutts hat 2009 bekannt gegeben, dass das Nutzen des rel-Attributes
mit NoFollow nicht länger zur Umverteilung des Linkwertes auf die übrigen ausgehenden Links führt, sondern das der Wert für diese Links und der
3. Grundlagen
15
Ankertext einfach verworfen wird [21]. Dennoch sollte bei Kommentarfunktionen und inhaltsfernen Verlinkungen, für die der Website-Inhaber keine
Verantwortung übernimmt, dieses Attribut verwendet werden.
Domain Trust
Je älter der Domain Name ist, desto höher ist der Trust den Google der
Website entgegen bringt. Der Trust-Wert spielt für die Platzierung einer
Website, in den Ergebnisseiten also eine Rolle. Daher brauchen auch optimierte Websites mit einer neuen Domain einiges an Zeit, bis diese in den
SERPs auf entsprechender Platzierung auftauchen.
Strukturierte Daten
Es gibt zwei Möglichkeiten wie Google mitgeteilt werden kann, das die Website strukturierte Daten enthält. Die einfache und schnelle Variante ist, die
Markierung der Inhalte auf der Website mithilfe des Data-Highlighter in
den Webmaster-Tools. Hier können die Textabschnitte direkt gewählt und
entsprechend gekennzeichnet werden. Die andere Variante besteht darin den
Inhalt im HTML-Code direkt mit Microdata9 oder RDFa10 auszuzeichnen.
Zum Zeitpunkt dieser Arbeit hat Google gerade den neuen Typ JSON-LD
eingeführt, mit dem jetzt ebenfalls die Website mit strukturierten Daten angereichert werden kann [26]. JSON-LD muss hierbei nicht, wie die anderen
Formate, mit dem HTML-Code verzahnt sein, sondern kann auch dynamisch
mittels JavaScript in die Seite integriert werden. Die Stelle an dem JSON-LD
ausgegeben wird, spielt dabei keine Rolle. Google nutzt die strukturierten
Daten unter anderem um Informationen direkt im Knowledge-Graph11 anzuzeigen und um die SERPs mit semantischen Informationen anzureichern.
Load Time
Zu lange Ladezeiten können das indexieren und crawlen der Seite verlangsamen und dazu führen, dass Google die Website niedriger rankt [11]. Um ein
schnelles Laden von Websites, vor allem für mobile Geräte zu ermöglichen,
kann auf folgende Dinge geachtet werden [38]:
• Lade device-spezifische Images mithilfe des Background properties und
css-media-queries.
• Verringere externe Style-Sheet Requests, besser ein großes externes
CSS-File.
9
Microdata ist eine WHATWG HTML Spezifikation um Metadaten in existierende
Websites zu platzieren.
10
Das Resource Description Framework in Attributes ist eine W3C Empfehlung, um
Metadaten in HTML, XHTML und xml einzubinden.
11
Stellte aufbereitete und kompilierte Suchergebnisse zu bestimmten Themengebieten
in den SERP’s dar.
3. Grundlagen
•
•
•
•
•
•
•
16
CSS3 Effekte anstatt Bilder nutzen.
Nutze die Möglichkeit von DATA-URI12 .
Nutzen von Inline-SVG’s13 .
Nutzen von CSS-Sprites.
Nutzen von Font-Icons.
Verringern der Anzahl an Redirects.
Reduziere Client-seitige Prozesse mit JavaScript.
Themenrelevanter Content
Inhalt, der direkt mit dem Thema bzw. den Keywords der Webpage zu tun
hat, ist die stärkste und effektivste Maßnahme der Onsite-Optimierung. Je
mehr Inhalt die Webpage zu einem bestimmten Thema oder Keyword bereitstellt, desto wahrscheinlicher ordnet Google die Website diesem Keyword
zu. Hierbei spielt die relative Termgewichtung eine wichtige Rolle [42]. Die
Gleichung für die Berechnung sieht wie folgt aus,
TW (𝑖) = WDF (𝑖) · IDF (𝑖),
(3.1)
und gibt an, zu welchem Verhältnis ein Wort innerhalb einer Website, in
Bezug zu allen indexierten Webpages, gewichtet wird. Generell berechnet
die Gleichung 3.1 also, in wie weit ein Wort in einem Dokument vorkommt
und wie relevant dieses zu dem Gesamtkorpus aller indexierten Dokumente
ist. Die Gleichung für die relative Termgewichtung setzt sich dabei aus zwei
Teilen zusammen. Die Within Document Frequency (Gl. 3.2),
WDF (𝑖) =
log2 (Freq(𝑖, 𝑗) + 1)
,
log2 (𝐿)
(3.2)
gibt an, wie häufig ein Term 𝑖 innerhalb eines Dokumentes 𝑗 vorkommt.
Demnach gibt der Ausdruck Freq(𝑖, 𝑗) die Häufigkeit des Wortes 𝑖 in Dokument 𝑗 an. Dieser Wert wird ins Verhältnis zum Vorkommen aller übrigen
Terme des Dokumentes gesetzt. Hierbei gibt 𝐿 die Gesamtzahl aller Wörter
im Dokument an. Somit erhält man die dokument-spezifische Wortgewichtung, mit Bezug auf alle im Dokument verwendeten Wörter. Die Inverse
Document Frequency (Gl. 3.3),
IDF (𝑖) = log
𝑁
,
𝑛𝑖
(3.3)
stellt ein Korrektiv dar, indem es die Häufigkeit an Dokumenten, zu einem
bestimmten Term miteinbezieht [42]. Sie setzt die Anzahl aller bekannten
Dokumente 𝑁 ins Verhältnis zur Zahl der Dokumente 𝑛, welche den Term 𝑖
12
13
Erlauben das einbinden von Bildern als Text.
Das Einbinden von SVG’s direkt als Text.
3. Grundlagen
17
enthalten. Beide Gleichungen miteinander multipliziert ergeben die relative
Termgewichtung eines Dokuments zu einem Wort, im Verhältnis zu allen
weiteren Dokumenten [42]. Ergänzend ist zu beachten, dass eine KeywordDensity von 2%–5% als optimal angesehen wird [9]. Höhere Werte können
als Keyword-Spaming angesehen werden und zum Abstrafen der Website
führen.
3.3.3
Offsite Optimierung
Bei der Offsite Optimierung geht es nicht mehr darum, die eigenen Quellcode Dateien zu optimieren, sondern den externen Linkaufbau zu verbessern.
Es geht darum, dass möglichst viele Links von externen Websites auf die
Zielwebsite verweisen. Dabei spielt der Kontext, in dem diese sogenannten
Backlinks auf den externen Websites auftauchen, eine wichtige Rolle. Der Inhalt, der verweisenden Webpages, sollte für den Nutzer einen Mehrwert bzw.
inhaltliche oder Themen relevante Überschneidungen mit der Zielseite aufweisen. Websites, die keinerlei inhaltliche Relevanz zu der verlinkten Website
haben, wirken kontraproduktiv und es besteht die Möglichkeit einer Abstrafung seitens Google. Im Folgenden werden Einige interessante Möglichkeiten
aufgezählt, die einen sinnvollen Linkaufbau darstellen und die auch für den
Benutzer einen tendenziellen Mehrwert aufweisen. Die sinnvolle Benennung
der Links spielt auch hier wieder eine entscheidende Rolle. Die Linknamen
sollten den verlinkten Inhalt beschreiben.
Page-Rank
Bei der Offsite Optimierung spielt der Page-Rank von Google eine wesentliche Rolle. Dieser gibt an, wie viele Websites auf die Zielseite verweisen und
wie wertvoll jeder einzelne Link dieser Seiten einzuschätzen ist. Hieraus wird
ein Rang errechnet, der die Relevanz einer Website allgemein wiedergeben
soll. Zwar wird der Page-Rank, nicht mehr von Google nach Außen kommuniziert, dennoch aber von Google angewendet. Die folgende Gleichung
PR(𝑖) = (1 − 𝑑) + 𝑑
∑︁ PR𝑗
𝑐𝑗
(3.4)
𝑗∈𝑀
stellt die Berechnung für den PageRank dar. Hierbei gibt die Variable 𝑀 ,
der Gl. 3.4, die Menge aller Websites an die auf 𝑖 zeigen. Demnach stellt
𝑖 die Zielwebsite des zu ermittelnden Pages-Ranks dar und 𝑗 eine Website
aus der Menge 𝑀 . Die Anzahl aller ausgehenden Links einer spezifischen
Website 𝑗 wird durch 𝑐 dargestellt und PR𝑗 stellt den PageRank von der
Website 𝑗 dar. Die Variable 𝑑 stellt einen Dumping Faktor zwischen 0 und
1 dar.
3. Grundlagen
18
Externe Landingpages
Neben den Landingpages auf dem eigenen Webserver, besteht auch die Möglichkeit der Nutzung von externen Landingpages. Social Media Plattformen
stellen eine kostenlose Möglichkeit dar, eine effektive Landingpage zu erstellen. Eine weitere Möglichkeit bieten die kostenlosen Blogsysteme. Jedoch
müssen diese externen Websites regelmäßig mit Inhalt gefüllt werden, der
auch Themen relevant ist.
Google News
Google News ist ein System, indem Inhalte nicht von Redakteuren gepflegt
werden, sondern das automatisiert Informationen aus News-Seiten pullt, um
diese dann auf den eigenen Plattformen anzubieten. Hierzu besteht die Möglichkeit, dass ein Website-Betreiber Google die URL seiner Website mitteilen
kann und Google dann entscheidet, ob diese Website in den Website-Pool
aufgenommen wird. Hierzu stellt der Konzern jedoch bestimmte Richtlinien bereit die eingehalten werden müssen. Dadurch, dass die News auf den
Google Plattformen einen Link zu der Original Website enthalten, entsteht
so eine effektive Backlink Struktur. Weiterhin rankt Google die Websites
automatisch höher, wenn die News auf der Website qualitativ hoch sind und
häufig geklickt werden.
Linkbaits
Der Begriff Linkbait bezeichnet einen Zustand oder eine Aktion, in dem
eine Website mehrmals von anderen Websites verlinkt wird, ohne dass die
Zielwebsite wiederum auf diese Websites verweist. Dieser Zustand kann erreicht werden, indem die Zielwebsite, den anderen Websites etwas anbietet
und diese dadurch auf die Zielwebsite verweisen. Beispielsweise monatliche
Auszeichnungen oder Prüf- und Testsiegel.
Linkwheels
Linkwheels gehören zu der Kategorie der Black-Hat Maßnahmen für SEO
Optimierungen und können daher zu der Entfernung der Website aus dem
Index führen. Hierbei werden mehrere Websites aufgebaut, die mit ihrer
Gegenseitigen Verlinkung eine Art kreisförmige Verkettung bilden. Website
A verlinkt auf Website B und Website B auf Website C usw. bis Website F
wiederum auf Website A verlinkt. Zusätzlich verlinken alle Websites auf die
eigentliche Zielseite.
SEO-Pyramiden
Diese Möglichkeit der Suchmaschinenoptimierung gehört ebenfalls zu den
Black-Hat Maßnahmen. Die zu optimierende Website steht hierbei an der
3. Grundlagen
19
Spitze der Link-Pyramide. Das Fundament der Pyramide bilden hierbei primitivere Inhaltstypen, wie beispielsweise Blog-Kommentare, Twittereinträge, Facebook-Kommentare usw. Diese unterste Ebene verlinkt auf eine mittlere Ebene von Websites, welche wiederum auf die Spitze, der eigentlichen
Zielseite verlinken.
3.3.4
Controlling und Anpassung
SEO ist ein fortwährender Prozess und muss daher permanent kontrolliert
werden. Hierzu können allgemeine Fragen gestellt werden.
•
•
•
•
•
•
Welche Auswirkungen hatten die einzelnen Maßnahmen?
Welche Ziele wurden erreicht?
Was kann verbessert werden?
Wie ist das Content-Quellcode-Verhältnis?
Wie ist die Keyword-Dichte?
Wie sind die internen Links und title-tags eingebunden?
Google Analytics
Google Analytics erlaubt das Kontrollieren wichtiger Indikatoren in Hinsicht auf den Website Erfolg. Diese sind die Benutzerquellen, Verhalten,
Zielgruppen und Conversions. Unter anderem können folgende Informationen festgestellt werden.
• Aus welchem Standort haben die Nutzer auf die Website zugegriffen?
• Von welcher Quellseite greifen die Nutzer zu?
• Mit welcher Technologie/Device/Provider greifen die Nutzer auf die
Website zu?
• Wie hoch ist die Anzahl der neuen und wiederkehrenden Besucher?
• Eingegebene Keywords der Nutzer?
• Zielvorhaben/Converions definieren und messen,
• Websitegeschwindigkeit,
• Zielseiten und Ausstiegsseiten, Verweildauer.
Google Alerts
Um Mitbewerber und potenzielle neue Konkurrenten im Auge behalten zu
können, kann das Tool Google Alerts verwendet werden. Dies ermöglicht die
Benachrichtigung per E-Mail, falls eine neue Webpage mit vorher definierten
Keywords von Google indexiert wird.
3. Grundlagen
20
Kontrollen automatisieren
Da eine manuelle Kontrolle des Rankings für alle Keywords relativ zeitaufwändig ist, sollte dieser Prozess automatisiert werden. Hierzu existieren
ebenfalls einige Tools, die das Anlegen von Keywords ermöglichen und diese
auf Suchmaschinenplatzierungen automatisiert überprüfen und protokollieren. Unter anderem existieren hier die Tools Free Monitor for Google und
cuteRank. Weiterhin sollte die Überprüfung der Keyword-Dichte mithilfe eines Programmes erfolgen. Hierzu kann das Tool Ranks.nl verwendet werden.
Eine Plattform, die die Features mehrere Tools vereint, ist Sistrix.
3.3.5
Bekannte SEO Tools
Sistrix
Sistrix vereint mehrere Techniken, die für SEO genutzt werden können. Unter anderem, wie viele Links, Domains oder Class-C Netze auf die eigene
Seite verweisen. Weiterhin kann die Toolbox ermitteln, zu wie vielen Keywords der Webauftritt im organischen Index steht. Es kann auch ermittelt
werden zu wie vielen gekauften Webanzeigen, mit vorkommenen Keywords,
die Website im Index von Google steht. Weitere Features stellen die Social
Signals dar. Diese geben an, wie stark die Domain in den sozialen Medien
geteilt oder geliked wurde. Das wichtigste Feature ist jedoch der Sichtbarkeitsindex [37]. Dieser Index gibt an, zu welchem Grad die Website in der
Suchmaschine Google sichtbar ist. Hierzu werden die Top 100 Ranks, zu
einem vordefinierter Pool an 250.000 Keywords14 , wöchentlich untersucht.
10% dieser Keywords sind abhängig von saisonalen Faktoren oder Ähnlichem. Bei einer Fussball Weltmeisterschaft beispielsweise, werden entsprechende Keywords durch Wörter wie „WM“ ersetzt. Jede Webpage des eigenen Webauftritts wird anschließend auf Position und potenziellem SearchTraffic bewertet. Steht die Seite zu einem Wort mit hohen Suchvolumen
im Index, ergibt dies eine höhere Punktzahl, als zu einem Wort mit niedrigerem Suchvolumen. Hinzu kommt noch die Punktzahl für die Position zu
dem Keyword auf der SERP. Je weiter die Webpage vorne liegt, desto mehr
Punkte erhält diese. Die resultierende Punktzahl wird anschließend für alle
Webpages der Website summiert und ergibt den Sistrix Sichtbarkeitsindex
[36]. Die Abbildung 3.5 zeigt einen Ausschnitt des Sistrix Dashboards, am
Beispiel für den Online-Händler Amazon15 .
SEOlyze
SEOlyze ist ein Tool für die Inhalts-Optimierung [34]. Zwar sind auch Features, wie die automatisierte Rangverfolgung zu den Google Suchergebnis14
15
Nur in Deutschland 250k, in anderen Ländern sind es 1.000.000 Keywords [36].
http://www.amazon.de.
3. Grundlagen
21
Abbildung 3.5: Sistrix Dashboard.
sen möglich, jedoch ist dies kein Alleinstellungsmerkmal. Interessanter sind
hier die Möglichkeiten für die WDF*IDF Analyse und einige LesbarkeitsAnalysen. Die Abbildung 3.3.5 zeigt ein Diagramm der genannten Analyse, für gegebene Keywords. Zu sehen sind hier die maximalen Werte, die
durchschnittlichen Werte und die Werte des Referenzprojektes. Dieses Referenzprojekt, dient als Keyword-Quelle und um Vergleichswerte zu erhalten.
Die Grundidee ist, somit einen Leitfaden zu erhalten, in welche Richtung
der Text verbessert werden muss, um ähnliche Ergebnisse wie das Referenzprojekt zu erzielen. Die Lesbarkeits-Analyse verwendet unter anderem
den Flesch-Grade und die Wiener Sachtextformel. Der Flesch-Grade ist für
mehrere Sprachen anwendbar und nutzt hierbei die Anzahl an Wörtern, die
Silbenlängen und die Satzlängen, um einen Wert zu ermitteln [7]. Dieser
Wert kann zwischen 0 – 100 liegen. Hierbei wird je nach Punktzahl dem
Text ein Alter in Jahren zugeordnet, welches der Nutzer haben sollte, um
den Text zu verstehen, siehe Tabelle reftab:flesch. Die Gleichung
FRE 𝑑𝑒 = 180 − ASL − (58, 5 · ASW ).
(3.5)
zeigt die Berechnung des Flesch-Grades. Hier steht die Variable 𝐴𝑆𝐿 für die
∅-Satzlänge (gesamt Anzahl Wörter/Gesamt Anzahl Sätze) und die Variable
𝐴𝑆𝑊 für die ∅-Silben Anzahl per Wort (gesamt Anzahl Silben/Gesamt
Anzahl Wörter). Die Wiener-Sachtextformel hingegen ist nur für deutsche
3. Grundlagen
22
Tabelle 3.1: Flesch Grade.
Punkte
Lesbarkeit
akademisches Jahr
0 – 30
sehr schwer
30 – 50
schwer
50 – 60 mittel schwer
60 – 70
mittel
70 – 80 mittel leicht
80 – 90
leicht
90 – 100
sehr leicht
akademisch
13 - 15 Jahre
11 Jahre
Abbildung 3.6: Diagramm von seolyze.com zur Word Document Frequency
und Inverse Document Frequency Analyse mit dem zusätzlichen Korrekturfaktor 𝑝.
.
Texte geeignet und teilt Texte in akademische Jahre ein, die der Nutzer
haben sollte [7].
onpage.org
Onpage.org stellt eine reines Tool für die Onsite-Optimierung dar. Es ermittelt eine Vielzahl an Key-Performance-Indikatoren und stellte diese übersichtlich dar [32]. Hierbei werden die KPI’s in 4 verschiedene Kategorien
eingeteilt. Die folgende Auflistung stellt diese mit einem Auszug von jeweiligen beispielhaften Indikatoren dar:
3. Grundlagen
23
• easy to implement KPI’s,
–
–
–
–
Header-Status,
Title Länge,
Robots.txt,
Meta-Tags,
• evaluation options,
–
–
–
–
Duplikate,
Kompression,
Sitemap,
css, js,
• structure and architecture,
–
–
–
–
img-Tags,
first-byte-time,
Ladezeit,
url-Länge,
• advanced optimization,
– Genutzte Links,
– Canonical.
Die Abbildung 3.7 zeigt einen Ausschnitt des onpage.org Dashboards, am
Beispiel für die Website16 der Fachhochschule Oberösterreich.
3.3.6
Über Google
Um einen optimalen Prozess der Suchmaschinenoptimierung zu gewährleisten müssen auch allgemeine Informationen über Google beachtet werden.
Hierzu gehören auch Informationen aus der Vergangenheit, um zukünftiges
Verhalten abschätzen zu können.
Google Updates
Google hat im Laufe der Zeit mehrere Updates zur Optimierung der Suchmaschine veröffentlicht. Größere Updates erhalten dabei immer einen Namen
als Bezeichner. Im folgenden sind die wichtigsten aufgeführt [9, 11, 35]. Diese Updates werden ständig aktualisiert, wobei in der folgenden Tabelle nur
die erstmaligen Updates und nicht deren Aktualisierungen aufgeführt sind.
16
http://www.fh-ooe.at/.
3. Grundlagen
24
Abbildung 3.7: onpage.org Dashboard.
3. Grundlagen
25
Tabelle 3.2: Google Updates.
Update
Florida-Update
Austin-Update
Brandy-Update
Allegra-Update
Bourbon-Update
Jagger Update
Big Daddy Update
Anti Google Bomben Update
Buffy-Update
Subdomain-AktualitätUpdate
Brand-Update
Mayday-Update
Panda-Update
Venice-Update
Penguin-Update
Hummingbird-Update
Mobile-Update
Phantom-Update
Jahr
2003
Änderung
Einführung der LocalRanks, Trustranks
2004 PageRank erhält themenrelevanten
Aspekt
2004 Erkennung Doppelter Inhalte, MirrorPages
2005 Verbesserung der Verarbeitung von
302-Redirects
2005 Neusortierung des Google Index
2005 Erkennung von Linknetzwerken, Spamseiten, Werbeseiten
2006 Problembehebung von CanonicalURLs, Hijacking
2007 Filter für Google Bomben
2007 Einführung verwandte Suchvorgänge,
Änderung der Gewichtung von Einwort
Anfragen
07/08 Subdomains werden wie Verzeichnisse
behandelt, Aktuelle Inhalte werden bevorzugt
2009 Suchverbesserung nach Markennamen
2010 Longtail-Keyword Ranking Veränderung
2011 Abstrafung von kopiertem Content
2012 Berücksichtigung
lokaler/regionaler
Ergebnisse (durch GPS, IP)
2012 Abstrafung von Keywordspaming, auffälligen Linkstrukturen
2013 Verständnis von komplexen Sätzen,
Sprachsteuerung
2014 Index für mobile Sites
2015 unbekannt,
Vermutung
ContentUpdate
Kapitel 4
Stand der Technik
In diesem Kapitel werden vorhandene Frameworks, API’s und technische
Ansätze für die Umsetzung von WebGL Anwendungen erläutert. Weiterhin
spielen auch Technologien eine Rolle, welche die Kommunikation von Server
zum Client ermöglichen.
4.1
4.1.1
Frameworks und API’s für WebGL
Auflistung der Technologien
Die Tabelle 4.1 zeigt eine Auflistung von WebGL Frameworks welche für die
Umsetzung von unterschiedlichen Anwendungsszenarien verwendet werden
können.
4.1.2
Unity
Die Unity Engine, von der Firma Unity Technologies mit Sitz in San Francisco, Amerika, ist eine vollwertige Game Engine. Sie nutzt ein Entity-System.
Diese Entities, können um vordefinierte oder selbst entwickelte Komponenten, ergänzt werden. Mit ihr können Anwendungen für die Plattformen Windows, Mac, iOS, Linux, Android, Blackberry, Tizen, Wii, WiiU, Xbox360,
XBox One, PS3, PS4, PSVita, Oculus Rift, Gear VR, Android TV, Samsung
SMART TV, sowie für den eigenen Unity Webplayer und Standalone Anwendungen für WebGL im Browser entwickelt werden. Neben digitalen Spielen
eignet sich die Engine auch für Anwendungen aus dem Bereich der digitalen
Medien. Durch die große Asset Pipeline, die sehr viele gängige 3D-Package
Formate aus den bekannten Modelierungsanwendungen, wie 3D Studio Max,
Maya, Cinema 4D, Lightwave, Blender, Cheetah 3D etc. unterstützt, wird
das Nutzen und Importieren komplexer 3D Modelle ermöglicht.
Die Benutzeroberfläche besteht aus einem Editor, in dem die aktuelle
Szenerie betrachet und bearbeitet werden kann. Als Skriptsprachen können
Javaskript, C# oder Boo verwendet werden. Da Unity hauptsächlich auf
26
4. Stand der Technik
27
Tabelle 4.1: WebGL Frameworks.
Kriterien
Beschreibung
Realismus
Physik
Editor
Sprache
Limitation
Doku,
Comm
Lernaufwand
Features
Unity
Unreal
X3Dom
Three.js
copperlicht
Crossplattform GameEngine
hoch
ja
ja
C#, js, boo
nicht
source-code
offen
super
Crossplattform GameEngine
hoch
ja
ja
c++
optimal für
AAA-titel
WebGL
Framework
für x3d
mittel
nein
nein
x3d
funktionsarm
JS Framework für
WebGL
mittel
nein
teils
js
funktionsarm
JavaScript
GameEngine
mittel
nein
teils
js
funktionsarm
schwach
schwach
mittel
schwach
mittel
hoch
gering
mittel
mittel
asm.js
asm.js
HTML
js library
/
Anwendungen abzielt, die etwas im 3-dimensionalen Raum darstellen, werden die Positions- und Rotationsdaten durch 3-dimensionale Vektoren und
Quaternionen repräsentiert. Die Einstellungen der Gameobjekte und Assets
innerhalb des Projektes, können durch den Inspector erfolgen. Dieses Toolkit
stellt eine grafische Benutzeroberfläche zur Verfügung, um Konfigurationen
an allen Elementen der Objekte vornehmen zu können [5]. Generell können
alle Einstellungen auch durch Skripte erfolgen, wodurch auch eine Manipulation der Objekte zur Laufzeit ermöglicht wird. Das Konzept der Prefabs1
erlaubt es GameObjects mit den entsprechenden Komponenten und der benötigten Programmlogik als wiederverwendbares Objekt abzuspeichern. Dies
ermöglicht eine automatisierte Instanzierung von Kopien dieses Objektes.
Die Spiellogik wird in der Regel in Klassen implementiert, die von der
Klasse „MonoBehaviour“ abgeleitet sind. Neben einer Kerninteraktionsschleife stellt diese Klasse auch Methoden für die Verwaltung von Gameobjekten und weiteren Operationen bereit. Zudem existieren sogenannte Event–
Funktionen, die in einer festgelegten Reihenfolge von dem System aufgerufen
werden [18].
Abbildung 4.1 zeigt den Lifecycle und die Reihenfolge der Aufrufe, der
unterschiedlichen Event-Funktionen.
1
Prefabrication.
Abbildung 4.1: Unity Lifecycle Flowchart [18].
28
4.1.3
29
Unreal
Die Unreal Engine von der Firma Epic Games, mit Sitz in Raleigh, North
Carolina, Amerika, ist eine Crossplatform für die Entwicklung von Computerspielen. Hauptsächlich wurde diese Engine für die Entwicklung von AAAGames2 genutzt. Mittlerweile kann für die Systeme Windows PC, Mac OS
X, iOS, Android, Oculus Rift, Gear VR, Linux, SteamOS, HTML5, XBox
One und PS4 entwickelt werden.
Der Source Code der Engine ist komplett quelloffen und kann nach Bedarf angepasst werden. Unreal Programmlogik wird in C++ geschrieben.
Eine alternative Möglichkeit bietet jedoch der Einsatz von sogenannten Blueprints, die in Unreal für visuelles Scripting verwendet werden. Hierdurch ist
es auch möglich ohne Programmierkenntnisse eigene Logik zu erstellen oder
bestehende C++ Klassen zu erweitern. Eine Besonderheit durch die Quelloffenheit stellt die Möglichkeit dar, die eigenen GameEngine Komponenten zu
erweitern [40, 15]. Das bedeutet die Grundlogik von Actors, welche primitive Objekte in Unreal darstellen, selbstständig nach den Projektbedürfnissen
anpassen zu können. Dies stellt zu der Unity Engine ein großen Unterschied
dar, da hier die GameObjects nur um zusätzliche Komponenten erweitert
werden können, aber die Grundstruktur unveränderbar ist.
Blueprint-Classes implementieren in Unreal das Konzept von wiederverwendbaren Objekten, ähnlich dem Konzept der Prefabs in Unity. Actors können um spezifische Komponenten erweitert werden und dann als
Blueprint-Class gesichert werden.
4.1.4
Three.js
Three.js ist ein JavaScript Framework für die Erstellung von WebGL Inhalten. Für das darstellen der 3D-Szenen bietet das Framework hierzu verschiedene Renderer an. Der WebGLRenderer stellt die 3D Inhalte mithilfe von
WebGL dar. Der CanvasRenderer nutzt kein WebGL, sondern die Canvas
2D Context API. Dieser kann als Fallback verwendet werden, falls der Browser kein WebGL unterstützt. Ein weiterer Render ist der CSS3DRenderer.
Dieser stellt die 3D-Objekte mithilfe von CSS3 Properties dar. Hier wird
das Property transform verwendet, um die Inhalte entsprechend mithilfe
von CSS3 zu skalieren, rotieren, translieren und die Perspektive entsprechend anzupassen. Es besteht die Möglichkeit der Kombination von einzelnen Rendern, um spezifische Inhalte unterschiedlich darstellen zu können [1,
2]. Komplexere 3D-Elemente können mithilfe des WebGLRenderers dargestellt werden, wie das Model eines Bildschirms. Dieses kann dann durch ein
Element überlagert werden, das durch den CSS3DRenderer dargestellt wird,
wie beispielsweise der Inhalt, der auf dem Bildschirm dargestellt werden soll
2
Klassifikation für Videospiele mit hohem Entwicklungsbudget bzw. hohe Bewertung
durch professionelle Redakteure.
30
[24]. Das ermöglicht das Darstellen von texturellen Informationen in HTML,
welche auch von Suchmaschinen aufgefunden werden können.
4.1.5
X3DOM
X3Dom ist ein open-source Framework für die Darstellung von WebGL Inhalten im Browser. Hierbei wird deklarativer 3D Inhalt in HTML5 integriert,
der dann durch das Framework und WebGL dargestellt werden kann. Das
Ziel des Frameworks ist es, die HTML5 Spezifikationen das W3C für deklarativen 3D Inhalt zu erfüllen. Hierbei werden die Informationen für die
3D-Szenen und Objekte als X3D Elemente im HTML5 DOM Tree hinterlegt.
Hierbei soll die Manipulation des 3D-Inhaltes durch hinzufügen, verändern
und löschen von DOM Elementen erfolgen [25].
4.2
Weitere Technologien
Die folgenden Technologien stellen verschiedene Funktionalitäten bereit, die
sich bei der Verwendung von WebGL als sinnvoll erwiesen haben. Besonders
in Bezug auf den Einsatz von Game-Engines zur Erstellung des WebGL
Contents, da diese den Inhalt weitaus stärker kapseln, als reine JavaScriptEngines. Technologien, wie Websockets, Server-Sent-Events, WebRTC ermöglichen Echtzeit Kommunikation mithilfe eines zwei-Wege request-response
Mechanismuses. In Single–Page–Anwendungen wird realtime-communicaton
dazu verwendet, Daten zwischen Server und Client auszutauschen. Anstelle
eines pollings auf der Clientseite können Push-Updates vom Server verwendet werden, um die Anwendungsdaten zu synchronisieren [10].
4.2.1
Server Sent Events
Server-Sent-Events erlauben das automatische Erhalten von Updates des
Clients durch den Server, ohne das Senden eines Requests durch den Client.
Beispiele für die Anwendung bieten Twitter, Facebook usw. Die EventSorce
API ist standartisiert als Teil der HTML5 Spezifikation durch das W3C.
4.2.2
WebSockets
Websockets ermöglichen eine bidirektionale, full-duplex Übertragung von
Daten zwischen Client und Server, über eine einzelne TCP Verbindung.
Hierbei startet der Client eine Anfrage an den Server, wobei nach der Datenübertragung jedoch die TCP-Verbindung bestehen bleibt. Damit sind
weitere Übertragungen in beide Richtungen möglich. Die Websocket API ist
durch das W3C standardisiert.
4.2.3
31
WebRTC
Web Real-Time Communication ist ein offener Standard, der sich noch in
der Standardisierungsphase durch das W3C befindet. Diese Technologie soll
Videokonferenzen, Filetransfer, Chat und Desktopsharing von Browser zu
Browser umfassen. Dadurch soll es auch ermöglicht werden, dass Daten
zwischen Smartphones, PCs und Smart-TVs über eine einzelne Plattform
ausgetauscht werden können. Die Übertragung von Dateien kann hierbei
Peer-to-Peer3 erfolgen.
3
Auch P2P genannt, dezentrales Konzept eines Rechnernetzes in dem alle Teilnehmer
gleichberechtigt sind, ohne zentralen Server.
Kapitel 5
Konzept
In diesem Kapitel wird das Konzept des gewählten Szenarios aufgeführt.
Anschließend werden hieraus die benötigten Funktionalitäten für die umzusetzende Anwendung abgeleitet.
5.1
Gewähltes Szenario
Für die Technologie wird ein Szenario für einen Möbel Online Shop gewählt.
Die Produkte sollen hierbei auf einer Webpage durch HTML Text und als
3D-Objekt in einer WebGL Szene dargestellt werden. Statt nur einem Bild
zu dem Produkt, steht dem Nutzer zusätzlich eine interaktive 3D-Szene zur
Verfügung, mit der interagiert werden kann. Dabei sollen die jeweiligen Szenen zu den gegebenen Kategorien, Living, Sleep, Bath, Cook und Other
fertig eingerichtete Räume mit den jeweiligen Möbeln darstellen. Der Aufbau einer Szene erfolgt durch das animierte hinaus bewegen von Objekten
der vorherigen Szene und dem anschließendem hinein bewegen, aller 3DObjekte, der aktuellen Szene.
Die Artikel werden ergänzend zu HTML auch in WebGL dargestellt.
Der Nutzer soll die Möglichkeit haben, entweder über den WebGL Kontext
mit der Website zu interagieren oder durch den HTML5 Inhalt. Hierbei soll
gezeigt werden, dass Kernfunktionalitäten der Standard Web-Technologien,
auch mit WebGL umgesetzt werden können. Da die Indexierung der Inhalte
durch Suchmaschinen nur über HTML erfolgen kann, müssen der aktuell
sichtbare HTML-Content und WebGL-Content synchron gehalten werden.
Navigiert der Nutzer innerhalb von WebGL zu einer bestimmten Kategorie, wird eine Szene dieser Kategorie geladen. Diese Informationen müssen
dann auch im HTML Kontext der WebPage angezeigt werden, indem der
aktuelle Inhalt aktualisiert wird. Umgekehrt soll ein Kategorie-Wechsel, im
HTML Teil der Webpage, ebenfalls eine Aktualisierung des WebGL Kontext
erzeugen.
Innerhalb der WebGL Szene soll ein Interface existieren, welches den
32
5. Konzept
33
Wechsel zwischen den Kategorien Living, Bath, Sleep, Cook und Other erlauben soll. Zudem existiert ein Button, der innerhalb einer aktuellen Kategorie die aktuelle Szene austauscht und durch eine neue Szene, der selben
Kategorie, ersetzt. Hierzu werden die 3D-Modelle dynamisch aus dem Viewport1 des Nutzers bewegt und die neuen Objekte wieder hineinbewegt. Ein
weiterer Button des Interfaces erlaubt das Wechseln zwischen einer fixen
Kamera-Perspektive und einer First-Person-Kamera Perspektive. Letztere
erlaubt das erkunden der Szene aus der Sicht einer Person.
5.2
Identifizierte Anforderungen und Funktionen
Im folgenden werden die identifizierten Funktionen dargestellt:
•
•
•
•
•
•
•
•
•
1
WebGL soll Kernfunktionalität beinhalten,
Kategorie-Navigation innerhalb von WebGL,
Kategorie-Navigation innerhalb von HTML,
Kommunikation zwischen WebGL und HTML zur Synchronisation,
Kategoriewahl stellt entsprechende Produkte der Kategorie in einer
Szene dar,
Szenen innerhalb einer Kategorie können gewechselt werden,
Fixe Kamera Perspektive,
First-Person-Camera Perspektive zur Erkundung der Szene,
Auswahl eines Produktes öffnet Label mit Produkt-Informationen.
Beschreibt das aktuelle Sichtfeld des Nutzers.
Kapitel 6
Realisierung
Im vorherigen Kapitel wurde das Konzept für das Anwendungsszenario, zum
WebGL System erstellt. Anschließend wurden die wichtigsten Funktionalitäten der Anwendungen herausgefiltert und aufgeführt. Nun wird gezeigt,
wie die Anwendung realisiert wurde, welche Technologie hierfür verwendet
wurde und die Gründe für die Technologieentscheidung werden erläutert.
6.1
Technologieentscheidung
Die Umsetzung des WebGL Teils des Prototyps erfolgt mit der Unity Engine.
Die aktuelle Version der Crossplatform erlaubt die Verteilung der entwickelten Anwendung auch auf WebGL. Der C# Sourcecode wird zunächst in
.NET Bytecode kompiliert. Während des Unity Build Prozesses compiliert
der IL2CPP-Compiler den .NET bytecode dann in C++ Code, welcher wiederum durch den emscripten-Compiler in asm.js compiliert wird. Asm.js hat
den Vorteil, dass es nahezu mit nativer Geschwindigkeit im Browser läuft.
JavaScript Engines AoT1 -kompilieren diesen Code in sehr performanten nativen Code. Dieser ist somit erheblich schneller, als normales JavaScript [31,
39]. Unity wurde vor allem gewählt, weil die Entwicklung von Anwendungen
sehr effizient möglich ist. Der Unity Editor ermöglicht das Betrachten der
aktuellen 2D oder 3D Szene während der Programmierung, wodurch wiederum sehr zielgerichtetes Debugging möglich ist. Weiterhin besitzt die Engine
Hilfmethoden, die u. a. nicht in Bibliotheken wie Three.js zu finden sind.
Ein Beispiel ist die Methode für Veränderungen von Vektoren, Float-Werten
und Rotationsdaten durch eine LERP-Smooth2 Funktion. Dies erlaubt das
schnelle Animieren von weichen Bewegungen und Rotationen ohne unnötige
Neuerfindungen des Rads.
Für die Umsetzung des HTML-Teils wurde kein spezielles PHP-Framework
1
2
Ahead-of-time-Compiler
lineare Interpolation durch eine weichere Kurve.
34
6. Realisierung
35
verwendet. Für die Frontend Entwicklung wurde allerdings Gulp3 mit npm4
und bower5 genutzt, da dies in manchen Fällen eine schnellere Entwicklung ermöglicht hat. Besonders die BrowserSync-Funktionalität hat sich als
nützlich erwiesen, da diese ein direktes streamen des veränderten Inhaltes
auf einen zweiten Bildschirm erlaubt. Bootstrap6 wurde verwendet um ein
grundlegendes flexibles Layoutverhalten für den Prototypen zu erzeugen.
6.2
Konzept zur Implementierung des Szenario
Da der WebGL Teil einige Zeit brauch bis er von der Browser Engine geladen
wurde, wurde hier die Entscheidung getroffen, den Prototypen als SPA7 umzusetzen. Dies hat den Vorteil, dass die JavaScript Bibliotheken, sowie der
in asm.js kompilierte Code nur ein einziges mal geladen werden muss. Einen
Pageload bei jeder Nutzeraktion zu initiieren, würde die User-Experience
sehr stark negativ beeinträchtigen. Dennoch muss darauf geachtet werden,
dass Google alle Inhalte indexieren kann. Es ist bekannt, dass ein wichtiges
Kriterium, für das Ranking auf Google’s SERP8 , die Ladezeit einer Website
ist. Websites, die zulange zum Laden benötigen, werden dementsprechend
im Ranking weiter unten eingestuft. Braucht der Ladevorgang extrem lange,
kann der Inhalt unter anderem nicht indexiert werden. Seit 2014 ist Google in der Lage nicht nur den Quellcode zu analysieren, sondern auch den
JavaScript-Teil selbstständig zu interpretieren und somit den veränderten
Inhalt zu rendern und zu indexieren [33].
Die Verwaltung der Szenen bzw. die Repräsentation einer Website wird
durch States realisiert. Für jede Seitenart gibt es einen State. Die benötigte
State-Maschine wird in C# implementiert und sorgt für den Wechsel der
einzelnen Szenen in dem WebGL Teil der Anwendung. Die Daten sollen per
Json9 String bereitgestellt werden und werden von einem externen Server
geladen. Durch, von dem Unity Framework initiierte Aufrufe von JavaScript
Funktionen, auf der Website und umgekehrte Aufrufe von Unity Funktionen
durch das JavaScript der Website, wird die Anwendung synchron gehalten.
Damit die Browser History aufrecht erhalten werden kann, wird die HTML5
History API genutzt. Die Anwendung pusht neue State’s automatisch zum
Browser oder lädt diese gegebenenfalls aus dem Browser Cache. Somit kann
die Browser Navigation genutzt werden, obwohl keine neuen Seiten geladen
3
Streaming- und Build-Tool für die Entwicklung mit Web Technologien.
node-package-manager.
5
Package Manager für das Web.
6
HTML, CSS, JS Framework für mobile Websites mit Responsive Webdesign.
7
Single Page Application.
8
Search Engine Result Pages.
9
Die JavaScript Object Notation, ist ein kompaktes Datenaustauschformat in Textform,
das auch vom Menschen leicht verständlich interpretiert werden kann. Vergleichbar mit
Xml.
4
6. Realisierung
36
wurden und die User Experience ist identisch zu einer Website, die nur durch
statische Seiten repräsentiert wird.
Kapitel 7
Implementierung
In diesem Kapitel wird die Implementierung der identifizierten Anforderungen und Funktionen aus Kapitel 5 erläutert, sowie des Konzept aus Kapitel
6 im Detail erklärt.
7.1
Implementierung in Unity
Die Implementierung erfolgte komplett in C#, da diese im Gegenzug zu
JavaScript, eine strengere Typisierung aufweist. Vorteile strengerer Typisierung sind u. a. frühzeitige Fehlererkennung, beispielsweise schon zur Übersetzungszeit.
7.1.1
Scene Manager
Der Kern der Anwendung stellt der SceneManager dar, der als StateMaschine implementiert wurde und nutzt das State-Pattern1 . Dieser enthält als
Komponente die Klasse SceneManager. Diese Klasse SceneManager enthält
eine Referenz auf die aktuelle Szene. Diese Szene ist eine Klasse, die von der
abstrakten Klasse SceneState erbt und Methoden zum wechseln der States
und laden von Objekten bereitstellt. Die State-Klasse enthält wiederum eine Referenz auf den SceneManager. Die Model Methoden befinden sich in
der Klasse SceneManager und werden von den jeweiligen States aufgerufen.
Hierdurch werden die Methodenaufrufe durch den State gekapselt und das
Verhalten des Systems hängt von dem jeweiligen State ab.
Der SceneManager enthält zu jeder Kategorie Art, Bath, Bed, Kitchen,
Living und Other, ein Array mit serialisierten Assets der Klasse Scene. Die
Klasse Scene enthält die aktuelle Kamera-Position und Rotation als Objekt
der Klasse CameraPosition, sowie ein Array, das Objekte der Klasse ObjectPosition beinhaltet. Die Klasse ObjectPosition speichert die Position,
1
Das State Pattern stellt die Implementierung eines endlichen Automaten dar, der sein
Verhalten abhängig vom aktuellen State ändern kann [3, 4, 12].
37
7. Implementierung
38
Abbildung 7.1: Klassendiagramm des SceneManagers ohne AnimationsMember.
Rotation und den Prefab-Namen eines einzelnen Objektes in der 3D-Szene.
Somit enthält ein Objekt der Klasse Scene alle relevanten Information für
den Aufbau einer 3D-Szene zu einer bestimmten Kategorie. Das Ändern einer Szene bewirkt auch das Senden eines Json String zur JavaScript Engine
des Browser, damit dieser den HTML-Inhalt entsprechend anpassen kann.
Wird nun eine neue Szene initiiert, werden die Informationen hierzu aus dem
Objekt der entsprechenden Szene extrahiert und bei einem Object-Pooler die
benötigten 3D-Modelle aktiviert.
Die Benutzung eines Object-Pools hat den Vorteil, dass die 3D-Modelle
nicht für jeden Wechsel einer Szene zerstört und neu instanziert werden müssen. Stattdessen werden sie deaktiviert und in einer Liste im Pool abgelegt.
Werden nun neue Objekte benötigt, kann beim Pool angefragt werden, ob
dieser noch genügend besitzt, ansonsten entscheidet dieser über eine neue
Instanzierung von den gefragten Objekten. Dies ist wesentlich performanter,
als reine Aufrufe von Destroy() und Instantiate().
Abbildung 7.1 zeigt ein Klassendiagramm des SceneManagers ohne AnimationsMember.
7. Implementierung
39
Abbildung 7.2: Klassendiagramm des ArticleInformationManagers.
7.1.2
Article Information Manager
Die Klasse ArticleInformationManager wurde als Singleton2 implementiert
und enthält eine Liste von Objekten der Klasse ArticleInformation. Die Klasse ArticleInformation beinhaltet alle relevanten Informationen über einen
Artikel. Der ArticleInformationManager stellt eine Verbindung zum Zielserver her, der die Daten für die Artikel als Json-String bereitstellt. Der String
wird dann deserialisiert und mit den erhalten Informationen wird ein neues
ArticleInformation Objekt angelegt und in die Liste eingefügt, falls dieser
Artikel nicht bereits schon in der Liste vorhanden ist.
Zudem besitzt der ArticleInformationManager eine Methode zum serialisieren von Objekten zu einem Json-String. Diese Methode wird benötigt um
dem Browser mitzuteilen, welche Artikel aktuell als HTML angezeigt werden
müssen, um den HTML und WebGL Kontext synchron halten zu können.
Sind alle Objekte deserialisiert worden und in die Liste eingefügt, werden
die Informationen als Json-String an eine entsprechende JavaScript Funktion des Browsers gesendet, welche wiederum dafür sorgt, dass der Inhalt in
HTML dargestellt wird.
Abbildung 7.2 zeigt ein Klassendiagramm des ArticleInformationManagers.
7.1.3
UI Manager
Die Klasse UIManager verwaltet die grafische Benutzeroberfläche und ist
als Singleton implementiert. Die Klasse beinhaltet Referenzen zu allen UIElementen, sowie dem Ladebildschirm und dem Produkt-Panel. Beim Start
der Anwendung aktiviert der SceneManager über den UIManager den Ladebildschirm und teilt dem UIManager mit, wie lange das Laden der Ob2
Das Singleton Pattern stellt sicher, dass es zu jeder Zeit nur eine Instanz der Klasse
gibt und diese einen globalen Zugriffsmodifizierer bereitstellt [4].
7. Implementierung
40
Abbildung 7.3: Der sichtbare Bereich einer Kamera, zwischen Near-Plane
und Far-Plane.
jekte dauern wird. Somit kann der UIManager nach Ablauf dieser Zeit die
FadeOut-Animation des Ladebildschirm starten. Zu einem Zeitpunkt kann
immer nur ein Button einer Kategorie aktiv sein. Weiterhin kümmert sich
der UIManager um das Austauschen der Sprites von Buttons, die Ihren Zustand ändern können.
Beim Klick des linken Mausbuttons wird ein Raycast3 von der Position der Maus aus gesendet, welcher senkrecht stehend von der Near-Plane
der Kamera aus, in Blickrichtung, in die Szene gesendet wird. Trifft dieser Raycast auf ein Objekt und es handelt sich um einen Artikel, wird der
Name des getroffenen Objektes ausgelesen und dem Produkt-Panel mitgeteilt. Die Abbildung 7.3 verdeutlicht den Aufbau eines Kamerasichtfeldes.
Der getroffene Artikel enthält eine Komponente der Klasse ProductPanel.
Die Klasse ProductPanel überprüft jedes Frame daraufhin, welchen Artikel
es anzeigen muss und besorgt sich die entsprechenden Informationen vom
ArticleInformationManager über eine statische Referenz. Anschließend werden die Informationen über referenzierte UI-Elemente dargestellt. Trifft der
Raycast auf kein Objekt wird das Product-Panel deaktiviert falls es aktiviert
sein sollte. Abbildung 7.4 zeigt ein Klassendiagramm des UIManagers.
7.1.4
Helper
Damit schnell 3D Szenen aufgebaut und die relevanten Informationen über
eine Szene schnell gespeichert werden konnten, wurde ein Unity-Plugin ge3
Aussenden eines Strahls zur Kollisionserkennung.
7. Implementierung
41
Abbildung 7.4: Klassendiagramm des UIManagers.
schrieben, in Form einer AssetCreator-Klasse, welche die Objekte einer
Szene traversiert und daraus automatisch ein Asset erstellt. Dieses Asset
wird im Resources Ordner abgespeichert und kann anschließend noch manuell bearbeitet werden, falls Informationen, wie Position usw. angepasst
werden müssen. Die folgende Auflistung zeigt die Informationen, die innerhalb des Assets zur Szene gespeichert werden:
• Kamera-Position,
• Kamera-Rotation,
• Objekte der Scene,
– Objekt-Position,
– Objekt-Rotation,
– Objekt-Name.
7.2
Implementierung in JavaScript
Die Anwendung wird vom JavaScript des Browsers beim Aufruf einer URL
und Laden der Website initialisiert. Hierbei teilt das JavaScript des Browsers der WebGL-Logik mit, welche Szene diese laden soll bzw. auf welcher
Unterseite sich der Nutzer gerade befindet. Zudem wird der aktuelle State
in den Cache des Browsers, mithilfe der HTML5-History API gepusht. Für
die Navigation, durch normales HTML werden an den Link-Elementen Listener angemeldet, die entsprechende C# Methoden in WebGL aufrufen und
die Szene aktualisieren. Jede Benachrichtigung der Listener sorgt auch für
das pushen eines weiteren States in den Browser Cache, damit die History konsistent bleibt. Da es sich um eine SPA handelt, ist es notwendig das
7. Implementierung
42
Abbildung 7.5: Klassendiagramm der Anwendung.
Standart-Event der Link-Elemente zu unterdrücken, da es sonst zu einem
neuen Pageload kommen würde und dadurch der komplette WebGL Teil
erneut geladen werden müsste.
Ein weiterer Listener muss an dem Window-Element des Browsers angemeldet werden. Dieser wird benachrichtigt sobald, ein PopState-Event auftritt und sendet den entsprechenden State der Seite an die WebGL-Logik.
Der WebGL Teil löst dann wieder eine Aktualisierung der Szene aus. Durch
dieses Vorgehen muss die Seite nur ein einmal komplett geladen werden,
was eine erhebliche Reduzierung der Ladezeit mit sich bringt und der Nutzer ein positiveres UX Erlebnis hat. Zudem wird die Usability-Experience
auch nicht eingeschränkt, da durch die Nutzung der HTML5-History API
das normale Verhalten der Website erhalten bleibt, als wäre es keine SPA.
Die gesamte Anwendung wird vereinfacht im Klassendiagramm der Abbildung 7.5 dargestellt.
7.3
Screenshots des Prototyps
Im folgenden Kapitel werden einige Bildschirmauszüge dargestellt, um einen
Eindruck von dem Prototypen zu erhalten.
7. Implementierung
43
Abbildung 7.6: Screenshot des ersten Prototyps.
Auf Abbildung 7.6 ist zum Vergleich der erste Prototyp zu sehen, der
noch eine stark experimentelle und düstere Szenerie beinhaltet.
Abbildung 7.7 zeigt eine Szene der Kategorie Living4 nach Klicken auf
ein Möbel mit aufgeklappten Label. Der obere Bereich der Navigation stellt
HTML dar, während der untere Teil sich im WebGL Bereich befindet. Der
linke Button aktiviert/deaktiviert die 3D Umsicht. Der rechte Button wechselt die Szene im aktuellen State bzw. der Kategorie. Die Button und Links
im mittleren unteren bzw. oberen Bereich, wechseln in die entsprechende
Kategorie.
Die Abbildung 7.8 zeigt eine Szene der Kategorie Living in der die FirstPerson-Kamera aktiviert ist und die Szene erkundet werden kann.
Abbildung 7.9 zeigt den HTML Teil der Website, der sich unterhalb des
WebGL Canvas befindet. Dieser Teil ändert sich je nach aktueller Szene.
4
Die 3D Modelle (Couch, Tisch, etc.) der gezeigten Szene stammen von der Firma
Unity Technologies und können frei verwendet werden.
7. Implementierung
Abbildung 7.7: Sceneview des zweiten Prototyps mit Product-Panel.
44
7. Implementierung
Abbildung 7.8: Sceneview des zweiten Prototyps mit aktivierter FirstPerson-Kamera.
45
7. Implementierung
Abbildung 7.9: HTML Teil des zweiten Prototyps.
46
Kapitel 8
Ergebnisse
Im folgenden Kapitel sollen die Erfahrungen mit dem Prototyp und die daraus resultierenden Ergebnisse aufgezeigt werden. Weiter noch, werden generelle Probleme erläutert, die sich aus der Fragestellung der Arbeit ergeben
haben. Die Erfahrungen sollen anhand von bestimmten Punkten aufgezeigt
werden, die sich als wichtig herausgestellt haben.
8.1
Responsive Webdesign
Responsive Webdesign ist ein Standard im Bereich der Webentwicklung geworden und sollte bei jedem Web-Projekt eine Rolle spielen. Mittlerweile
vertreten einige Webentwickler auch die Meinung, dass wenn Websites kein
flexibles Verhalten aufzeigen, auch nicht mehr von Webdesign gesprochen
werden kann. Templates wie Bootstrap erlauben eine schnelle und einfachere Integration von responsive Features innerhalb einer Website durch
HTML, CSS und JavaScript. Inhalte werden in vordefinierte Spalten unterteilt, die sich je nach Größe des Endnutzergerätes verändern und anpassen.
Auch Schriftgrößen, Bilder und Grafiken können so passend skaliert werden,
damit der Nutzer ein hohes Maß an UX erfährt. Das selbe Ergebnis innerhalb eines WebGL Blockes zu erreichen erweist sich jedoch als wesentlich
schwieriger.
Da im Laufe der Jahre die Technologien für die Webentwicklung ständig weiterentwickelt wurden, können Features, wie automatische Anpassung
von Breite und Höhe eines Containers innerhlab eines Browserfenster, sehr
einfach durch CSS realisiert werden. Die Browser-Engines interpretieren diese Layoutsprache und setzen das gewollte Verhalten des Webdesigners um.
Soll nun das selbe Verhalten von Containern, 3D-Elementen, Modellen und
weiteren WebGL Inhalten sich ebenfalls entsprechend ideal verhalten, muss
dieses Verhalten vom Entwickler programmiert werden. Auf ein mächtiges
Werkzeug, wie CSS und die jahrelang verbesserte Browserinterpretation dieser Sprache, muss verzichtet werden. Als ein starkes Werkzeug hat sich hier
47
8. Ergebnisse
48
Abbildung 8.1: Akkulaufzeit bei WebGL Anwendungen im Vergleich.
jedoch die Unity Engine erwiesen. Das UI System der Engine verfügt über
ein ähnliches Boxmodel, integriert float-Eigenschaften von Containern und
automatisches ausrichten in einem Layout. Hierdurch kann ein ähnliches
Verhalten, wie durch CSS Formatierung erzeugt werden. Dennoch bleibt
der Aufwand und die Testphase wesentlich aufwändiger, als es mit reinen
Standard Webtechnologien der Fall ist.
8.2
8.2.1
Mobile Devices
Akkulaufzeit
Getestet wurde auf den Geräten Nexus 4 und Nexus 9. Bei voll geladenem
Akku wurde auf den Geräten eine Standard Website geöffnet ohne WebGL
Inhalte und solange laufen gelassen bis sich die Geräte wegen dem geringen
Akkustand selbst ausschalteten. Diese Zeit wurde als normale Referenzzeit
genommen. Im zweiten Test wurde auf diesen Geräten bei selben Bedingungen eine WebGL Website geöffnet und erneut bis zum automatischen
ausschalten der Geräte, die Zeit gemessen. Somit kann die Akkulaufzeit gegenüber einer Standard Website und einer Website mit WebGL Inhalten, in
Referenz gesetzt werden. Abbildung 8.1 zeigt die errechnete durchschnittliche Akkulaufzeit der verwendeten Geräte, für die Browser Firefox und Chrome.
8. Ergebnisse
8.2.2
49
Allgemeine Probleme
Tablet und Smartphones haben momentan noch große Schwierigkeiten mit
dem korrekten darstellen von WebGL Inhalten. Getestet wurden Anwendungen von Three.js, Unity sowie Standard WebGL ohne Bibliotheken oder
Frameworks. Verwendet wurden die Browser Firefox und Chrome. In allen
Fällen konnten die Geräte die Websites und Anwendungen nicht fehlerfrei
darstellen. Ein Unterschied zwischen der mobilen Version von Chrome und
Firefox konnte nicht festgestellt werden. Bei Unity Anwendungen, die in
WebGL dargetellt werden und auf einem mobilen Gerät geöffnet werden,
meldet Unity direkt, dass die Engine noch nicht für mobiles WebGL ausgelegt ist. Texturen, Shader und Modelle werden nicht korrekt dargestellt,
sodass das es zu Effekten wie Transparenz, fehlenden Polygonen, Löschern
in Modellen und fehlenden Lichteffekten kommt.
8.3
User Experience
Im Folgenden wird die Prototypen Anwendung und allgemeine WebGL Funktionen im Hinblick auf die 3 Kriterien der User-Experience erläutert. Welche
Vor- und Nachteile konnten hier im Hinblick auf diese Punkte festgestellt
werden?
8.3.1
Look
In Bezug auf die Prototypen Anwendung erhält der Nutzer eine genaue Vorstellung von dem Aussehen des Möbelstücks bzw. des Accessoires. Die Darstellung als 3D-Model ermöglicht dem Nutzer das Objekt aus frei wählbaren
Perspektiven zu betrachten, mit jeweils unterschiedlichen Vergrößerungsstufen. Bilder zeigen stehts nur eine unveränderbare Perspektive. Auch bei
mehreren Bildern zu einem Produkt kann es vorkommen, dass dem Nutzer
gerade eine bestimmte Ansicht fehlt. Durch die Möglichkeit, dass sich der
Nutzer frei in der Szene bewegen kann, herrscht eine stärkere Immersion.
Hierdurch kann sich der User die Produkte besser vorstellen, was wiederum
das Vertrauen und die Glaubwürdigkeit stärkt.
Die Stimmung der Szenarien können durch die Art der Beleuchtung in
3D-Szenen schnell geändert werden. Bei Fotografien müssen hier ganz neue
Fotos aufgenommen werden und der Aufwand ist um einiges größer. Eyecatcher können durch WebGL wesentlich interessanter wirken, wodurch die
Aufmerksamkeit des Nutzers schneller auf bestimmte Inhalte gelenkt werden
kann. Allgemein bestehen größere Möglichkeiten visuelle Reize zu kreieren.
Neue Technologien, wie Physical-Based-Shader, ermöglichen das Darstellen
von real aussehenden Texturen. Objekte mit unterschiedlichen Ausführungen, Designs und Materialien können so einfach erstellt werden, ohne jede
Produktvariante einzeln neu fotografieren zu müssen.
8. Ergebnisse
8.3.2
50
Feel
Durch die freie Bewegungsmöglichkeit und freie Rundumsicht erhält der Nutzer einen ersten Eindruck der Möbel und kann bereits mit ihnen interagieren.
Das Anklicken der Objekte und das darauffolgende Erscheinen eines Informationslabels wirkt intuitiv.
WebGL Anwendungen erlauben dem Nutzer eine größere Möglichkeit an
Interaktionen und brechen aus dem normalen Web-Interaktionselementen
aus. Mit Hilfe der Darstellung von Inhalten im 3-dimensionalen Raum kann
der User auf bereits erlernte Navigationsmöglichkeiten zurückgreifen. So erfolgt die Navigation intuitiver.
8.3.3
Usability
Die Navigation in einem 3-dimensionalen Raum kann sich als ineffizienter
erweisen, als innerhalb eines reinen 2D User Interfaces. Wenn die Bedienung
eines 2D UI bereits erlernt wurde, ist die Interaktion meistens recht effizient. Durch die Verfügbarkeit der dritten Dimension können mehr Elemente
auf einem Bildschirm gleichzeitig platziert werden. Dies kann besonders bei
der Visualisierung von Daten hilfreich sein, wenn diese Verbindungen unter einander besitzen, die dargestellt werden sollen. Zudem kann diese Art
der Visualisierung auch dazu genutzt werden, um Muster in bestimmten
Datensätzen sichtbar zu machen.
8.4
8.4.1
Indexierungskriterien
Geschwindigkeit
Dadurch, dass WebGL Inhalte durch den Browser in der Regel eine längere
Ladezeit benötigen, weil eine Szene aus komplexen 3D Modellen besteht, eine
komplexere Programmlogik bereitgestellt oder das Framework einer Engine
erst vollständig geladen werden muss, ergeben sich einige Probleme. Normale
Ressourcen, wie HTML, CSS, JavaScript und PHP, können vom Browser
relativ schnell initiiert werden und stehen dann allen Nutzern und Agents,
die auf diese Inhalte zugreifen möchten, zur Verfügung.
Durch eine länger andauernde Verzögerung der Bereitstellung der Inhalte bei einem Ladevorgang der Website, könnten Suchmaschinen Probleme
beim Auffinden und Indexieren von Informationen haben. Dies kann vorallem dann auftreten, wenn es sich bei der Website um eine Single-PageApplication handelt. Hier werden die Inhalte in der Regel durch Ajax oder
ähnliche Technologien geladen. Hierbei wird eine HTTP Anfrage, in der
Regel durch eine JavaScript-Engine, an den Server gesendet. Diese Engine
stellt eine Zwischenschicht zwischen Server und User dar und ermöglicht die
asynchrone Datenübertragung ohne einen kompletten reload der Website zu
initiieren [14].
8. Ergebnisse
51
Tabelle 8.1: Ergebnisse: Start bei 1000 ms mit Intervall von 500 ms.
Timeout in ms
1000
1500
2000
2500
3000
3500
4000
4500
5000
...
10000
Rendered
Indexed
ja
ja
ja
ja
ja
ja
ja
ja
nein
...
nein
ja
ja
ja
ja
ja
ja
ja
ja
nein
...
nein
Das Verhalten der Suchmaschinen-Crawler bei solchen Inhalten wurde
durch 2 Testszenarien untersucht.
8.4.2
Bereitstellung der Inhalte durch JavaScript
In den folgenden Testszenarien wurden verschiedene Inhalte als HTML bereitgestellt. Diese Inhalte wurden nach bestimmten Zeitintervallen durch
JavaScript asynchron geladen und der Website hinzugefügt. Hier konnten
verschiedene Beobachtungen gemacht werden, betreffend der unterschiedlichen Zeitintervalle zwischen dem Einfügen der Inhalte und der Dauer der
Gesamtverzögerung beim Ladevorgang eines Inhaltes. Die Tests sind immer
bis 10000 ms gelaufen und wurden dann beendet. Aus Gründen der Übersicht
werden nicht immer alle Zeitschritte tabellarisch dargestellt.
Die Tabelle 8.1 zeigt die Ergebnisse bei einer Startverzögerung von 1000 ms
und anschließendem Einfügen von Testinhalt alle 500 ms.
und anschließendem Einfügen von Testinhalt alle 1 ms. Hier zeigt sich, dass
das Rendern durch Google und die Indexierung der Inhalte vollständig ausbleibt. Dies kann daran liegen, dass Google der Zeitintervall, indem der Inhalt auf der Website hinzugefügt wird, zu kurz ist und dann auf das interpretieren des JavaScript-Teils verzichtet wird oder es zu viele Methodenaufrufe
gibt.
und Ende der Aufrufe bei 1460 ms mit Einfügen von Testinhalt alle 1 ms. Nun
zeigt sich, dass der Zeitintervall in dem Inhalt durch JavaScript eingefügt
wird, keine Rolle spielt. Die Anzahl der Methodenaufrufe scheinen jedoch
begrenzt zu sein. Bei einem Aufrufende von 1461 ms, also 462 Methodenauf-
8. Ergebnisse
52
Timeout in ms
1000
1001
1002
...
10000
Rendered
Indexed
nein
nein
nein
...
nein
nein
nein
nein
...
nein
Timeout in ms
1000
1001
1002
...
1460
Rendered
Indexed
ja
ja
ja
...
ja
ja
ja
ja
...
ja
Tabelle 8.4: Ergebnisse: Start bei 4979 mit Intervall von 1ms.
Timeout in ms
...
4979
4980
...
10000
Rendered
Indexed
...
ja
nein
...
nein
...
ja
nein
...
nein
rufen, werden keinerlei JavaScript Inhalte indexiert und gerendert. Dies gilt
auch für Inhalte die vor dem 462. Methodenaufruf bereitgestellt werden.
Die Tabelle 8.4 zeigt wann der Google-Bot aufhört den Inhalt zu interpretieren. Nach 4979 ms wird kein Inhalt, der durch JavaScript bereitgestellt
wird, mehr gerendert und indexiert.
8.4.3
Crawling von Links
Weiterhin wurde ein Test aufgesetzt mit dem Ziel festzustellen, ob Google
Links zu Websites folgt, die wie oben gezeigt durch JavaScript erst mit einer
Verzögerung in die Website eingefügt werden. Hierzu wurden 2 Testszenarien mit unterschiedlichen Einstiegsseiten erstellt, welche beide dynamisch
nach 2000 ms einen Link zu einer jeweils weiteren Unterseite hinzugefügt
8. Ergebnisse
53
bekommen. Diese Unterseiten enthalten wiederum einen Link, der jeweils
zu einer weiteren Unterseite führt. Dieser Vorgang wurde bis zu einer Tiefe
von 10 wiederholt. Jede Startseite besaß also 10 weitere Unterseiten, von
denen jeweils nur der Vorgänger auf den Nachfolger verwies. In Testszenario
1 wurden jedoch relative Links verwendet und in Testszenario 2 absolute
URL’s mit einer vollständigen URL aus Scheme und Scheme-Specific-Part.
Zunächst wurden jeweils nur die Einstiegsseiten von Google indexiert und
aufgefunden. Nach 4 Tagen befanden sich auch die Unterseiten aller beiden
Testszenarios vollständig im Index.
8.4.4
Gesamtergebnis
Alles was nach 4979 ms erst durch JavaScript eingefügt wird, rendert und
indexiert der Google-Bot nicht. Weiterhin hat sich gezeigt, dass der Zeitintervall in dem die Inhalte geändert werden relativ bedeutungslos ist, da
bei einem Änderungsintervall von 1ms immer noch alles gerendert wird. Die
Anzahl an Methodenaufrufen scheint jedoch begrenzt zu sein. Es wurde in
einer Schleife alle 1ms eine JS-Funktion zum Einfügen von Inhalt aufgerufen.
Werden <=461 Methodenaufrufe durch die JavaScript-Engine getätigt, rendert Google die Inhalte nach wie vor. Bei >=462 Methodenaufrufen werden
jedoch keinerlei Inhalte, die durch JavaScript bereitgestellt werden, durch
den Google-Bot gerendert. Jedoch werden auch JQuery Aufrufe zum Erfassen des Containers für den Inhalt, zuvor getätigt, sodass nur von einer
ungefähren Grenze gesprochen werden kann, die bei ∼ 461 Methodenaufrufen liegt.
Es wurde zusätzlich auch getestet wie lange der WebGL Inhalt braucht
bis er bereit ist und vollständig geladen wurde. Hierzu wurde der Zeitunterschied zwischen dem kompletten Laden des DOM und dem ersten Aufruf
einer JavaScript-Methode durch den WebGL Teil der Website gemessen. Da
hier von einer unmittelbaren Bereitstellung des kompletten DOM auszugehen ist, wird die erste JavaScript Methode direkt aufgerufen, sodass der
Zeitunterschied zwischen den beiden Aufrufen die ungefähre Zeit angibt bis
der komplette WebGL Teil zur Verfügung steht. Beim erstmaligen Laden der
Website ist der WebGL Teil erst nach ∼ 72945 𝑚𝑠 vollständig geladen. Bei
weiteren Reloads der Website beträgt diese Zeit nur noch ∼ 10131 𝑚𝑠. Hier
wurde der WebGL Teil untersucht, der durch die Unity Engine bereitgestellt
wird. Dies bedeutet, dass auch das komplette Unity Framework in WebGL
bzw. asm.js zur Verfügung gestellt wird. Das Laden von Inhalten durch andere WebGL Bibliothen oder Framworks, wie beispielsweise Three.js fällt
entsprechend kürzer aus, da hier der Funktionsumfang des Frameworks wesentlich geringer ist.
Durch weitere Testszenarien wurde festgestellt, dass der Google-Crawler
durch JavaScript generierte Links, ebenfalls folgt und diese Seiten indexiert.
Auch Links die mit einer Verzögerung durch JavaScript generiert werden,
8. Ergebnisse
54
kann Google erfolgreich interpretieren und indexieren. Voraussetzung hierfür
ist jedoch, dass der Timeout bis zur Generierung der Links nicht die oben
genannte Zeitspanne überschreitet.
8.5
Besonders geeignete Inhalte
Theoretisch lassen sich alle Inhalte als 3D Elemente darstellen. Besonders
geeignet sind jedoch die Inhalte, die durch ihre Darstellung einen direkten
Mehrwert für den Nutzer bereithalten. Dieser Mehrwert kann durch die Art
der Navigation in der Szene oder durch den zusätzlich verfügbaren Platz,
der durch die Darstellung in 3 Dimensionen zu Verfügung steht, entstehen.
Eine weitere Möglichkeit des Mehrwerts kann durch die reine Darstellung
des Contents in 3D entstehen.
Als Beispiel sei hier die Visualisierung eines Auto’s auf einer Internetseite
eines Automobilherstellers oder Händler genannt. Potenzielle Kunden könnten hier jedes Detail des Auto in einem interaktiven Model betrachten.
Dieses Model, stellt im Gegenzug zu normalen Bildern, keine spezifischen
Ausschnitte bereit, sondern stellt das Objekt als Ganzes dar. So erhält der
Kunde einen besseren Eindruck und kann sich besser mit dem Auto identifizieren. Details, wie Armaturen, können ihre Features direkt simulieren und
der Kunde kann diese direkt ausprobieren.
Abbildung 8.2 zeigt eine Darstellung von identifizierten Features einer
WebGL Anwendung.
8.6
Vergleich der Techniken
WebGL Inhalte können nur durch Google und andere Suchmaschinen indexiert werden, wenn ihre Inhalte gleichzeitig auch in HTML zur Verfügung
stehen. Hier gibt es zahllose Varianten, wie dies technisch genau realisiert
werden kann. Im Fall des umgesetzten Prototypen wurde bereits in Kapitel 7
gezeigt, wie die Umsetzung als SPA aussehen kann. Die Umsetzung als SPA
hat sich als sinnvoll erwiesen, weil so das Framework nur einmal geladen
werden muss, siehe Abschnitt 8.4.4. In dieser Variante wurde die Verhaltenslogik komplett in asm.js gekapselt, welche für die komplette Steuerung
der Inhalte verantwortlich ist. Der Nachteil besteht darin, dass ohne aktiviertes JavaScript oder WebGL Unterstützung des Browsers, die Website
nicht funktionieren kann. Zudem müssen die Inhalte, da sie durch JavaScript
bereitgestellt werden, innerhalb von 4,9 sec zur Verfügung stehen, da ansonsten keine Indexierung durch Google erfolgt. Dies stellt somit ein großes
Problem dar, was eine Bereitstellung der Inhalte durch JS so gut wie unmöglich macht. Das liegt daran, dass die Inhalte zu lange benötigen, bis
sie initialisiert sind, wenn sie durch komplexere Frameworks, bereitgestellt
werden sollen. Kleinere Frameworks die keine große Ladezeit und einen ge-
8. Ergebnisse
55
Abbildung 8.2: Identifizierte WebGL Features.
ringeren Funktionsumfang besitzen, wären hierzu jedoch durchaus in der
Lage. Three.js nutzt kein asm.js und besitzt einen deutlich geringeren Funktionsumfang, als beispielsweise das Unity Framework. Hierdurch erfolgt die
Initialisierung der Inhalte nicht erst, wenn das komplette Framework zur
Verfügung steht und geladen wurde, da der Nutzer hier durch reines JavaScript genaue Kontrolle hat, wann er Features von Three.js nutzt bzw. wann
er die Inhalte mit JS initialisieren möchte.
Da momentan jedoch nur der Google-Bot in der Lage ist JS zu interpretieren und zu rendern, bleiben diese Inhalte für andere Suchmaschinen
verborgen. Daher sollten die Inhalte steht’s auch ohne JS zur Verfügung gestellt werden. Dies ist auch deshalb sinnvoll, weil einige Nutzer JavaScript
deaktiviert haben könnten. Prinzipiell bedeutet dies, dass somit serverseitige
Technologien zum Einsatz kommen sollten.
Kapitel 9
Resümee
In dieser Arbeit wurden die Grundlagen von SEO und die Möglichkeiten von
WebGL dargestellt. Es wurde ein WebGL Prototyp umgesetzt, um die momentanen Möglichkeiten aufzuzeigen die diese Technologie bietet. Es wurden
Möglichkeiten erläutert, wie Inhalte, die in WebGL dargestellt werden, am
effektivsten durch Suchmaschinen auffindbar gemacht werden können.
Auf Desktop Systemen mit aktuellem Browser kann WebGL ohne große
Probleme Einsatz finden. Jedoch haben sich Firefox und Chrome, als die
Browser erwiesen, bei denen es am wenigsten zu Problemen kommt. Dies
liegt unter anderem daran, dass sich die Mozilla Corporation und Google
Inc. sehr stark an der Entwicklung dieser Technologie beteiligen und auch
Unternehmen wie Unity Tehnologies, durch die Bereitstellung von Entwicklern, aktiv unterstützen. Zudem sind diese beiden Firmen Mitglieder der
Khronos Group und tragen damit zur Festlegung der Standards, dieser 3D
Technologie, bei.
Es wurden gängige Frameworks und Engines betrachtet, die in der Lage
sind WebGL Inhalte zu erzuegen. Die Unity Engine stellt zu diesem Zeitpunkt das mächtigste Entwicklungswerkzeug für WebGL dar. Vorteilhaft
gegenüber anderen Frameworks ist, dass der komplette Funktions-Stack des
Unity-Frameworks auch in WebGL Anwendungen verwendet werden kann.
Dies macht die Entwicklung wesentlich effizienter, weil sich der Entwickler
gezielt auf die Anwendung konzentrieren kann, da fehlende Features so gut
wie nicht vorhanden sind. Weiterhin wird der JavaScript Code in schnelles asm.js kompiliert, das die Performance zur Laufzeit gegenüber normalen
JavaScript enorm verbessert. Die große Feature Palette ist jedoch zugleich
auch ein Nachteil. Da das gesamt Framework in WebGL zur Verfügung gestellt wird, benötigt auch die einfachste Anwendung eine beträchtliche Ladezeit. Besonders im Bereich des Webs stellt dies ein großes Problem dar. Der
Google-Bot kann die Inhalte, welche durch JavaScript bereitgestellt werden,
nicht indexieren und Nutzer wandern in der Regel nach wenigen Sekunden
ab, wenn die Initialisierung der Website zu lange benötigt.
56
9. Resümee
57
Reine JavaScript Framewokrs wie Three.js sind in der Lage auch relativ
schnell WebGL Inhalte zur Verfügung zu stellen, wenn diese relativ einfach
gehalten werden. Die Ladezeit ist hier wesentlich geringer. Three.js besitzt
nicht die gleiche Performanz, wie das Unity Framework, da es nicht in asm.js
läuft. Weiterhin ist der Funktionsumfang, den das Framework von Haus aus
mit bringt, auf das Nötigste begrenzt. So stellt das Framework beispielsweise
keine eigenen Methoden zum Rendern einer Szene zur Verfügung. Entwickler
müssen direkt mit dem Methoden-Stack der Browser-Engine arbeiten. Ein
Vorteil stellt jedoch der CSS3-Renderer von Three.js dar. Dieser Renderer
nutzt die CSS-Transforms, um einfache geometrische Figuren zu erstellen.
Die so transformierten HTML Inhalte sind in der Lage komplexere Modelle,
die durch WebGL dargestellt werden, zu ergänzen. Dabei bleibt der volle
Funktionsumfang der HTML-Elemente erhalten. Diese Inhalte können von
dem Google-Bot auch problemlos indexiert werden.
Jedoch ist WebGL aus der momentanen Sicht noch sehr experimentell.
Der Firefox Browser und Google Chrome kommen bereits sehr gut mit den
Inhalten zurecht, während andere Browser noch mehr Probleme haben. Die
mobilen Browser versagen bei WebGL Inhalten jedoch noch völlig. Hierbei
spielt es auch keine Rolle, ob der Inhalt mit einer komplexen Engine oder
mit einem kleineren JavaScript Framework erstellt wurde. Momentan existierende kommerzielle Websites, die auf WebGL aufbauen, kommen aus dem
Bereich Werbung und Marketing. Ergänzend zu normalen Werbemaßnahmen, können solche interaktiven Werbebotschaften ebenfalls in Kampagnen
im Online Bereich eingesetzt werden. WebGL sollte momentan daher nur als
Ergänzung zu den Standard Webtechnologien betrachtet werden. Die Indexierung von Inhalten in WebGL ist nur möglich, wenn diese parallel auch in
Form von HTML bereitgestellt werden. Sinnvollerweise sollten Websites die
WebGL Inhalte anbieten, auch in der Lage sein ohne entsprechende Browser
Unterstützung, die relevanten Informationen in HTML darstellen zu können.
9.1
Ausblick
Das Potenzial, von im Browser laufenden 3D Anwendungen ist relativ groß.
Da momentan der Trend bei Softwareanwendungen immer weiter zu Cloudbasierten Diensten geht, werden auch die Anwendungen immer mehr als
reine Webanwendungen, direkt über das Internet bereitgestellt. Beispiele hierfür sind Cloud-Dienste wie, Drive1 von Google, Office Online2 und
OneDrive3 von Microsoft. Momentan stellen diese Webanwendungen jedoch
nur das Pondon zu ihren existierenden Client-basierten, nativen Anwendungen dar. Dementsprechend ist auch der Funktionsumfang bei den Online1
https://www.google.com/intl/de/drive/
https://www.office.com/
3
https://onedrive.live.com/about/de-de/
2
9. Resümee
58
Varianten noch etwas eingeschränkt. Ein interessante Entwicklung könnte
jedoch lauten, dass es in der Zukunft keine solchen installierbaren oder portable Anwendungen mehr gibt. Alle Anwendungen würden über den Browser
laufen und gleichzeitig eine direkte Authentifizierung des Nutzer durch eine vorherige Registrierung im entsprechenden Dienst verlangen. Hierdurch
würden auch die finanziellen Verluste der Firmen, durch raub-kopierte Software, verringert werden. Aktuell sind jedoch noch keine großen Varianten
von 3D Anwendungen aus dem Tools Bereich vorhanden. Beipielsweise ein
Version von Autodesk Maya oder 3DsMax als Online Version. Dies könnte
WebGL jedoch durchaus ermöglichen.
Momentan ist eine starke Entwicklung von Technologien aus dem Hardwarebereich zu beobachten, die sich mit Augmented Reality und Virtual
Reality beschäftigen. Als Beispiel seien hier die beiden Datenbrillen Oculus
Rift aus dem Hause Oculus und die HoloLens von Microsoft genannt [27, 30].
Erstere erlaubt das Eintauchen in virtuelle Welten und zweitere erweitert
die Realität um virtuelle Inhalte. Viele weitere Firmen, u.a. HTC, Sony, MagicLeap, Samsung u.v.w. forschen und entwickeln in diese Richtung. Erste
Prototypen sollen 2016 auf den Markt kommen. Erweist sich das Interesse der Nutzer an diesen neuen Hardwaregeräten als äußerst groß, ist die
Entstehung eines neuen Marktes im Bereich Virtual Reality und Augmented Reality sehr wahrscheinlich. WebGL könnte dann genau die Technologie
sein, die die Nutzung solcher Geräte auch am Browser ermöglicht und demnach jedem Webnutzer es erlauben würde, in virtuelle Welten, durch das
einfache aufrufen einer Website, einzutauchen.
Anhang A
Technische Informationen
A.1
Aktuelle Dateiversionen
Datum
2015/09/27
2015/06/19
A.2
A.2.1
Datei
Masterarbeit.pdf
Projektdateien
Details zur aktuellen Version
Allgemeine technische Voraussetzungen
Getestet unter einer aktuellen Windows-7 Installation mit
• xampp oder gleichwertige Serverumgebung,
• WebGL fähigem Browser, empfohlen wird Firefox in aktuellster Version.
A.2.2
Verwendung unter Windows
Im folgenden wird die Vorgehensweise für eine lokale xampp Serverumgebung erläutert. Der Ordner gerhards wird im Ordner htdocs abgelegt, womit
sich folgende Pfad-Struktur ergibt. htdocs/gerhards/spa/ Dies ist notwendig
da die WebGL Logik nach dem Json-String unter
http://127.0.0.1/gerhards/spa/json/index.html sucht.
59
Anhang B
Inhalt der DVD
Format:
DVD-ROM, Single Layer, ISO9660-Format
B.1
Masterarbeit (PDF)
Pfad:
/
Masterarbeit.pdf . . . .
Einsatz von WebGL zur Erstellung von
Websites mit indexierbaren Inhalten
B.2
Projekt Dateien
Pfad:
/Projektdateien
Source-Prototyp.rar . .
Website-Prototyp.rar . .
Gulp-Umgebung.rar . .
Enthält alle Assets und Source-Dateien des
Unity Projektes.
Enthält den kompilierten Prototypen als
lauffähige Website.
Enthält die Gulp-Umgebung.
60
Quellenverzeichnis
Literatur
[1]
Jos Dirksen. Learning Three.js: The JavaScript 3D Library for
WebGL. Livery Place: Packt Publishing Ltd., 2013 (siehe S. 29).
[2]
Jos Dirksen. Three.js Essentials. Livery Place: Packt Publishing Ltd.,
2014 (siehe S. 29).
[3]
Eric Freeman u. a. Head First Design Patterns. Sebastopol: O’Reilly,
2008 (siehe S. 37).
[4]
Erich Gamma u. a. Design Patterns – Elements of reusable ObjectOriented Software. 2. Aufl. Reading, MA: Addison Wesley, 2009 (siehe
S. 37, 39).
[5]
Will Goldstone. Unity 3.x, Game Development Essentials. 2. Aufl.
Packt, 2011 (siehe S. 27).
[6]
Google Inc. Einführung in die Suchmaschinenoptimierung. 2015. url:
http://static.googleusercontent.com/media/www.google.de/de/de/
webmasters/docs/einfuehrung-in-suchmaschinenoptimierung.pdf (siehe
S. 13).
[7]
Karl-Albrecht Immel. Regionalnachrichten im Hörfunk: Verständlich
schreiben für Radiohörer. Springer-Verlag, 2014 (siehe S. 21, 22).
[8]
Krzysztof Walczak Jakub Flotynski. „Semantic multi-layered design
of interactive 3d presentations“. In: Proceedings of the Federated Conference on Computer Science and Information Systems (FedCSIS)
(2013), S. 541–548 (siehe S. 6).
[9]
Weinand Kim. Top-Rankings bei Google und Co. 2. Aufl. Bonn: Galileo
Press, 2014 (siehe S. 11, 12, 14, 17, 23).
[10]
Sandeep Kumar Patel. Responsive Web Design with AngularJS. Livery
Place: Packt Publishing Ltd., 2014 (siehe S. 30).
[11]
Erlhofer Sebastian. Suchmaschinen-Optimierung - Das umfassende
Handbuch. 5. Aufl. Bonn: Galileo Press, 2011 (siehe S. 15, 23).
[12]
Florian Siebler. Design Patterns mit Java. München: Carl Hanser,
2014 (siehe S. 37).
61
Quellenverzeichnis
62
[13]
Patti Spala u. a. „Extending MPEG-7 for efficient annotation of complex web 3D scenes“. In: Multimedia Tools and Applications 59.2
(2012), S. 463–504 (siehe S. 6).
[14]
Maximilian Vollendorf und Frank Bongers. JQuery – Das umfassende
Handbuch. Bonn: Galileo Press, 2012 (siehe S. 50).
[15]
Sherif William. Learning C++ by Creating Games with UE4. Livery
Place: Packt, 2015 (siehe S. 29).
Online-Quellen
[16] url: https://www.artefactgroup.com/content/3d-ui-useful-usable-ordesirable/ (besucht am 09. 09. 2015) (siehe S. 10).
[17] url: http://people.csail.mit.edu/kapu/EG_09_MGW/EG2009_3D_
User_Interfaces.pdf (besucht am 09. 09. 2015) (siehe S. 10, 12).
[18] url: http://docs.unity3d.com/Manual/ExecutionOrder.html (besucht
am 08. 02. 2015) (siehe S. 27, 28).
[19]
asmjs.org. url: http://asmjs.org/faq.html/ (besucht am 01. 01. 2015)
(siehe S. 5).
[20] Canvas 3D: GL power, web-style. url: http://wayback.archive.org/
web/20110717224855/http://blog.vlad1.com/2007/11/26/canvas-3dgl-power-web-style/ (besucht am 09. 09. 2015) (siehe S. 6, 7).
[21]
Matt Cutts. PageRank sculpting. url: https://www.mattcutts.com/
blog/pagerank-sculpting/ (besucht am 15. 04. 2015) (siehe S. 15).
[22] Datei:User-Experience. url: https://de.wikipedia.org/wiki/Datei:Userexperience.svg (besucht am 09. 09. 2015) (siehe S. 9).
[23]
Johan Dorland und Willem den Besten. De opkomst van WebGL. url:
http : / / www . students . science . uu . nl / ∼3685632 / content / history. html
(siehe S. 7).
[24]
Jerome Etienne. Mixing HTML Pages Inside Your WebGL. url: http:
//learningthreejs.com/blog/2013/04/30/closing-the-gap-between-htmland-webgl/ (besucht am 15. 04. 2015) (siehe S. 30).
[25]
Fraunhofer IGD. x3dom - instant 3D the html way. url: http://www.
x3dom.org/?page_id=2 (besucht am 15. 04. 2015) (siehe S. 30).
[26]
Google Inc. Structured Data. url: https : / / developers . google . com /
structured-data/ (besucht am 15. 04. 2015) (siehe S. 15).
[27] holoLens. url: https://www.microsoft.com/microsoft- hololens/en- us
(besucht am 09. 09. 2015) (siehe S. 58).
Quellenverzeichnis
63
[28] Khronos Details WebGL Initiative to Bring Hardware-Accelerated 3D
Graphics to the Internet. url: https://www.khronos.org/news/press/
khronos-webgl-initiative-hardware-accelerated-3d-graphics-internet (besucht am 09. 09. 2015) (siehe S. 7).
[29] Khronos Releases Final WebGL 1.0 Specification. url: https://www.
khronos.org/news/press/khronos-releases-final- webgl- 1.0-specification
[30] Oculus Rift. url: https : / / www . oculus . com / en - us/ (besucht am
09. 09. 2015) (siehe S. 58).
[31] On the future of web publishing in unity. url: http://blogs.unity3d.
com/2014/04/29/on-the-future-of-web-publishing-in-unity (besucht am
01. 01. 2014) (siehe S. 34).
[32] onpage.org. url: https : / / de . onpage . org/ (besucht am 09. 09. 2015)
(siehe S. 22).
[33]
Orun Bhuiyan. Googles Crawler Now Understands JavaScript: What
Does This Mean For You? url: http : / / www . business2community.
com/seo/googles- crawler- now- understands- javascript- mean- 0898263
[34] SEOlyze Tool. url: https : / / www . seolyze . com/ (besucht am
09. 09. 2015) (siehe S. 20).
[35]
Sistrix. Google Updates und Algorithmus-Änderungen. url: http : / /
www.sistrix.de/frag- sistrix/google- algorithmus- aenderungen/ (besucht
am 15. 04. 2015) (siehe S. 23).
[36]
Sistrix. Was ist der SISTRIX Sichtbarkeitsindex? url: http://www.
sistrix.de/frag-sistrix/was-ist-der-sistrix-sichtbarkeitsindex/ (besucht am
15. 04. 2015) (siehe S. 20).
[37] Sistrix Toolbox. url: http://www.sistrix.de/ (besucht am 09. 09. 2015)
(siehe S. 20).
[38]
Smashing Magazine. How To Make Your Websites Faster On Mobile
Devices. url: http://www.smashingmagazine.com/2013/04/03/buildfast-loading-mobile-website/ (besucht am 15. 04. 2015) (siehe S. 15).
[39] The future of scripting in unity. url: http://blogs.unity3d.com/2014/
05/20/the-future-of-scripting-in-unity (besucht am 01. 01. 2014) (siehe
S. 34).
[40] Unreal Engine 4 For Unity Developers. url: https://docs.unrealengine.
com/latest/INT/GettingStarted/FromUnity/ (besucht am 28. 04. 2015)
(siehe S. 29).
[41] Usability vs. User Experience – Hauptsache Spaß!? url: http://www.
usabilityblog.de/2012/06/usability-vs-user-experience-hauptsache-spas/
Quellenverzeichnis
64
[42] WDFIDF. url: https://de.onpage.org/wiki/WDF*IDF (besucht am
09. 09. 2015) (siehe S. 16, 17).
[43] WebGL Unterschiede. url: https : / / blog . mozilla . org / futurereleases /
2015/03/03/an-early-look-at-webgl-2/ (besucht am 09. 09. 2015) (siehe
S. 8).
Messbox zur Druckkontrolle
— Druckgröße kontrollieren! —
Breite = 100 mm
Höhe = 50 mm
— Diese Seite nach dem Druck entfernen! —
65

Einsatz von WebGL zur Erstellung von Websites mit indexierbaren

Transcription

Similar documents

Farbe im Kino - Inhalt und Leseprobe

Sesam, öffne dich!

Software zur räumlichen Visualisierung geometrischer Objekte im

105 Vortrags-Charts zum

Technische Parameter von Leiterplatten, die durch Techno

Googles 200-Ranking Faktoren

Suchmaschinenoptimierung Glossar Suchmaschinenoptimierung

Major Projekt

Update für ZENworks 11 SP2 - Systemanforderungen

Schulwebseiten auf musin erstellen