Backups, Updates, Viren und Malwaretests für Webseiten

Bei den genannten Themen herrscht im Gespräch mit unseren Kunden häufig ein betretenes Schweigen. Bei den meisten Webseiten ist es tatsächlich ohne Fachkenntnisse fast nicht möglich, ein vollständiges, aktuelles Backup zu erstellen.
Dabei gilt für Webseiten eigentlich das gleiche wie für den Computer, mit dem man arbeitet: tages- oder zumindest wochenaktuelle Backups sollte es für den Fall der Fälle geben.

Aber von vorne angefangen: Warum haben so wenige Personen oder Unternehmen Backups von der ersten Visitenkarte, die ein neuer Kontakt als erstes zu sehen bekommt? Warum werden Webseiten für teils mehrere 10.000 Euro erstellt, diese dann jahrelang liebevoll mit Content gepflegt, die Seiten teilweise nochmal aufwändig erweitert und es existieren nur sporadische Backups?

Unsere Einschätzung ist, dass einfach das Angebot und das Bewusstsein fehlt. Mit beidem will ich hier aufräumen.

Das Internet ist ein gefährlicher Ort

Es werden nicht nur Drogen und Waffen über das Internet gehandelt, jeden Tag denken sich Hacker, Phracker, Cracker, Script Kiddies und andere Personengruppen neue Wege aus, Deine Webseite zu hacken. Dabei geht es schon lange nicht mehr rein um das destruktive Zerstören der gesamten Seite. Vielmehr geht es darum, Traffic (also Besucher oder Datenverkehr) umzuleiten, Daten von der Webseite oder dessen Nutzern zu stehlen (Datendiebstahl) oder über die Webseite Schadsoftware zu verteilen oder den vorhandenen Inhalt zu verändern. Die Wege dieser Personen werden dabei immer perfider und sind zumeist nicht auf den ersten Blick zu erkennen.

Leider – und mit steigender Anzahl – sind diese Versuche oft erfolgreich.

Was kann ich machen, damit meine Webseite nicht gehackt wird?

Glücklicherweise veröffentlichen die Hersteller und Entwickler der meisten CMS und den Erweiterungen regelmäßig Updates, um die Sicherheitslücken zu schließen, sobald diese erkannt werden. Die beste Verteidigung gegen diese Angriffe ist somit, die regelmäßige Aktualisierung des Systems. Abhängig von Deiner Webseite sind ggf. zusätzliche Sicherheitsmaßnahmen vom Hersteller empfohlen. Einer der wichtigsten Faktoren ist jedoch immer die regelmäßige Aktualisierung der Webseite!

Optimalerweise funktionieren die Updates des Systems vollautomatisch. Dies geht leider nicht bei den meisten CMS. Im Idealfall wird die Webseite geklont, das Update in der geklonten Umgebung durchgeführt. Darauf wird ein Test durchgeführt, der Änderungen optisch/inhaltlich erkennt. Wenn alles korrekt funktioniert, wird das Backup angefertigt und das Update im Live-System durchgeführt.

Aber wie erkennt man überhaupt, dass seine Webseite gehackt ist?

Im schlechtesten anzunehmenden Fall siehst Du oder gar einer Deiner Kunden in den Google Suchergebnissen den Hinweis „Diese Website wurde möglicherweise gehackt“ oder wenn Du darauf klickst siehst Du eine rote Bildschirm-Benachrichtigung „Diese Website kann Ihren Computer beschädigen“. Dann hat sogar schon Google mitbekommen, dass Deine Webseite offenbar ein Problem hat.

Nicht ganz so gravierend (aber immernoch peinlich genug): Du siehst auf einmal Inhalte auf der Seite, die nicht von Dir oder Deinem Team stammen. Hier können zwei Dinge passiert sein: 1. Deine Passwörter und Benutzerdaten sind irgendjemandem in die Hände gefallen oder 2. Das CMS Deiner Webseite hat eine Sicherheitslücke, die ausgenutzt wurde. Im besten Fall sind in beiden Fällen nur Inhalte ausgetauscht worden. Vielfach werden in einem solchen Fall aber auch noch eine oder gleich mehrere Hintertüren zu der Homepage geöffnet.

Diese Webkonsolen, Malware, Viren oder sonstige Schadsoftware bekommt man mit einem Viren-, Malwarescanner oder auch Diff-Tool (zeigt Unterschiede zu einem Backup oder dem originalen Code des CMS) zumeist identifiziert, sodass man sie entfernen kann. Das kann jedoch einige Zeit dauern, weshalb auch in einem solchen Fall meist ein aktuelles Backup einfacher erledigt wäre.

Was ist noch wichtig für die Sicherheit meiner Webseite?

Security Audits zum Beispiel. Hier werden Antworten auf die folgenden Fragen gegeben:

  • Ist eine Sicherheitslösung im CMS integriert?
  • Ist eine Web Application Firewall (kurz WAF) vor dem CMS? Diese filtert DDoS-Angriffe und ist in der Lage verdächtigen Datenverkehr zu filtern.
  • Von wann ist das letzte Backup?
  • Ist das Backup integer? Zur Erläuterung: Ein Backup ist erst dann ein Backup, wenn man getestet hat, dass sich daraus das System wiederherstellen lässt.
  • Sind das CMS und dessen Erweiterungen/Plugins aktuell?
  • Wie sieht die Serverumgebung (Webserver, Datenbank, …) aus?
  • Ist das System gehärtet? Unter Hardening versteht man in der Regel die Absicherung gegen Angriffe von außen. Ein Hack ist zumeist ein Umstand mehrerer unglücklicher Zufälle, daher sollte man sich nicht immer auf die erste Instanz verlassen, sondern im Vorfeld das System auch bestmöglich sichern, sodass ggf. auftretende Sicherheitslücken nicht ausgenutzt werden können.

Gibt es regelmäßige Status-Berichte und was kostet diese sinnvolle Ergänzung zur Webseite?

Am Ende des Tages oder besser am Monatsende will ich wissen, wie der Status meines Systems ist. Wir können über diesen – zu großen Teilen vollautomatisierten Prozess – einen Report erstellen, sodass man auch immer weiß, wann was passiert ist. Wir kümmern uns um etliche Websites. Sodass wir diese natürlich auch alle im Auge behalten wollen.

Erledigt man alles händisch (Backups, Updates) einmal je Woche, was durchaus möglich ist, so ist man – je nach Internetverbindung – einige Stunden zugange.

Wir bieten all das ab 35 Euro netto je Monat je Webseite an. Wir erledigen Backups, Updates und machen Deine Webseite sicherer und schneller. Für unsere Hostingkunden bieten wir sogar alles in einem nochmal attraktiverem Paket an.

Kontaktieren Sie uns gerne – kostenfrei und unkompliziert versteht sich!

WPML 3.9 ist erschienen und setzt der Duplikation ein Ende

Direkt nach Ende der Feiertage hat das Team rund um WPML einige neue Features und Verbesserungen veröffentlicht, die alle in dem Update 3.9 vereint werden.

WPML 3.9 bietet einige Neuheiten, neben den üblichen Verbesserung der Leistung und Stabilität. Unter anderem kann der Benutzer nun Inhalt in seiner Standardsprache anlegen, und solange keine Übersetzung für eine Sprache vorhanden ist, wird der Originaltext angezeigt. Dadurch entfällt das lästige kopiere in die anderen Sprachen, bis ein Übersetzer gefunden wurde.

Diese und weitere Informationen finden sich im offiziellen Ankündigungsbeitrag auf der offiziellen WPML Homepage.

WPML Contractors – Die neue Art der Hilfe

Brauchten Sie jemals Hilfe bei der Erstellung Ihrer Mehrsprachen Website? Oder sind Sie ein erfahrener Entwickler, der nach neuen Aufträgen sucht?

Das neue WPML Contractor System ist genau die Lösung und es ist nun gestartet. Das System erlaubt es Ihnen, erfahrene Entwickler zu finden, die Ihnen helfen können, Ihre Webprojekte zu realisieren.

Sofern Sie WPML für mehr als 6 Monate nutzen, werden Sie in Ihrem Benutzeraccount auf WPML.org eine Einladung finden, dem System beizutreten. Dort sehen Sie die weiteren Schritte, die benötigt werden, um dem System beizutreten als Entwickler. Eine der Vorraussetzungen besteht aus 3 Mehrsprachigen Websites, die Sie oder Ihr Team entwickelt haben müssen. Das WPML Team wird Ihre Bewerbung dann prüfen und, sollte sie angenommen werden, in der neuen Contractor Search veröffentlichen.

Für mehr Informationen, oder um Feedback zu geben, besuchen Sie bitte den offiziellen Veröffentlichungsbeitrag.

Erste Beta Version von WPML 3.9 erschienen

Für WPML 3.9 ist die erste Beta Version nun verfügbar. Neben zahlreichen kleinen Änderungen wurde auch eine große Änderung im Bereich der Inhaltsübersetzung angekündigt. So erlaubt ein neuer Modus, getauft „Translatable“, nicht übersetzte Einträge anzuzeigen in allen Sprachen anzuzeigen, ohne den Inhalt per Hand duplizieren zu müssen. Sobald eine Übersetzung für den Inhalt erstellt wurde, wird automatisch der Inhalt in der gewünschten Sprache angezeigt.

Wer die neue Version gerne ausprobieren möchten, kann in seinem WPML – Account unter Beta-Channel die benötigten Dateien herunterladen. Zur Sicherheit empfiehlt sich vorher ein Backup der WordPress-Datenbank zu erstellen.

Weitere Information zum neuen Update finden sich in der Ankündigung auf WPML.org.

WPML 3.8 endlich veröffentlicht!

Nach einer langen Entwicklungs- und Testphase wurde jetzt WPML 3.8 veröffentlicht.

Diese Version von WPML ist die bisher optimierteste und schnellste. Sie wurde einige Wochen lang auf der offiziellen Seite von WPML benutzt und es wurde eine starke Performance Steigerung in allen Bereichen festgestellt.

Neben der Performance wurde noch die Benutzbarkeit verbessert und einige neue Features hinzugefügt.

Eine genaue Auflistung aller Neuerungen und Änderungen findet sich in offiziellen Ankündigung (Englisch).

WPML Endbenutzer-Accounts für Ihre Kunden

Vor einiger Zeit wurde auf WPML.org von den Entwicklern bekannt gegeben, das sie beabsichtigen, Endbenutzer-Accounts für WPML anzubieten. Sie sind nun da und warten auf den Einsatz!

Endbenutzer Accounts helfen Ihnen, Zeit zu sparen und Ihren Kunden den besten Support für die WPML Übersetzungs Funktionen zu bieten.

Jeder hat Vorteile durch die neuen Endbenutzer-Accounts. Sie müssen weniger Support Anfragen beantworten, Ihre Kunden bekommen Experten-Hilfe vom Hersteller und der Hersteller hofft, das so mehr Leute mit ihrem Produkt effizient arbeiten können.

Mehr zum Thema Endbenutzer Accounts finden sie in dem offiziellen Veröffentlichungsbeitrag (Englisch).

PSR-2: Coding Style Guide

Die PSR-2 Spezifikation beinhaltet Vorgaben zur Formatierung einer PHP-Datei. Sich an diese Richtlinien zu halten, ist vor allem dann sinnvoll, wenn man mit anderen Leute zusammen an einem Projekt arbeitet. Halten sich alle an die gleichen Stilvorgaben, verschwendet niemand Zeit, sich erst in fremden Code einzulesen.

1. Allgemeines

Die erste Voraussetzung ist, dass sich der Code ebenfalls an die Vorgaben der PSR-1 Spezifikationen hält, welche sich mit dem allgemeinen Programmierstil befasst.

Weitere Vorgaben sind:

  • Alle PHP-Dateien müssen den UNIX LF als Zeilenumbruch benutzen
  • Die Datei muss mit einer Leerzeile abschließen
  • Bei einer reinen PHP-Datei entfällt das schließende ?> Tag
  • Einrückungen bestehen aus 4 Leerzeichen
  • Keywords wie true, false und null werden klein geschrieben
  • Nach der öffnenden Klammer und vor der schließenden keine Leerzeichen
  • Befinden sich eine schließende Klammer und eine geschweifte öffnende Klammer in einer Zeile, so werden sie durch ein Leerzeichen getrennt
  • Bei Aufzählungen kommt vor dem Komma kein Leerzeichen, danach schon

Zeilen

  • Zeilen sollten nicht länger als 80 Zeichen sein
  • Sie dürfen nicht länger als 120 Zeichen sein
  • Keine Leerzeichen am Ende einer Zeile
  • Nicht mehr als ein Statement pro Zeile
  • Leerzeilen dürfen zum Zwecke der Übersichtlichkeit hinzugefügt werden

Namespaces und use-Deklarationen

  • Nach namespace-Deklarationen muss eine Leerzeile folgen
  • Alle use-Deklarationen stehen unterhalb der namespace-Deklaration
  • Pro use-Deklaration muss ein use-Keyword benutzt werden
  • Nach dem use-Block muss eine Leerzeile folgen
<?php
namespace Bereich\Package;
use EinInterface;
use IrgendeineKlasse as EineKlasse;
use AndererBereich\ZweitesPackage\MeineKlasse;
...

2. Klassen, Methoden und Attribute

  • abstract und final-Deklarationen stehen der Sichtbarkeit-Deklaration voran
  • Die static-Deklaration kommt nach der Sichtbarkeit
  • Beim Aufruf einer Funktion kommt kein Leerzeichen zwischen den Methoden- oder Funktionsnamen und der öffnenden Klammer

Extends und implements

  • Die Schlüsselwörter extends und implements müssen in der gleichen Zeile deklariert werden wie Klassenname
  • Die öffnende geschweifte Klammer kommt in eine eigene Zeile
  • Die schließende geschweifte Klammer kommt in die Zeile nach dem body
  • Eine Liste von implements kann in mehrere Zeilen geschrieben werden, dabei muss jedes Element in eine eigene Zeile geschrieben werden

Attribute

  • Bei allen Attributen muss die Sichtbarkeit angegeben werden
  • Das var-Keyword darf nicht zum Deklarieren von Attributen benutzt werden
  • Pro Statement darf nur ein Attribut deklariert werden
  • Keine Präfixe benutzen, die die Sichtbarkeit eines Attributs wiedergeben

Methoden

  • Bei allen Methoden muss die Sichtbarkeit angegeben werden
  • Keine Präfixe verwenden, die die Sichtbarkeit einer Methode anzeigen sollen
  • Nach dem Methodennamen kommt kein Leerzeichen, sondern sofort die öffnende Klammer
  • Nach der öffnenden Klammer und vor der schließenden kommt kein Leerzeichen
  • Die öffnende geschweifte Klammer kommt in eine eigene Zeile nach dem Methodennamen
  • Die schließende geschweifte Klammer kommt in die Zeile nach dem Body der Methode
  • Default-Argumente kommen ans Ende der Liste der Argumente
  • Eine Liste von Argumenten kann wie bei implements über mehrere Zeilen geschrieben werden, dabei gilt: jedes Argument kommt in eine eigene Zeile
class NeueKlasse extends EineKlasse implements EinInterface
{
 public function beispielFunktion($a, $b, $c = 2)
 {
  if ($a == $c) { 
   diesunddas();
  } elseif ($b == $c) { 
   diesundjenes($b);
  } else { 
   MeineKlasse::tudas($a, $b);
  }
 }

  final public static function irgendwas()
 {
  machwas();
 }
}

3. Kontrollstrukturen

  • Nach dem Kontrollstruktur-Schlüsselwort kommt ein Leerzeichen
  • Kein Leerzeichen nach der öffnenden und vor der schließenden Klammer
  • Zwischen der schließenden Klammer und der öffnenden geschweiften Klammer muss ein Leerzeichen sein
  • Der Körper der Kontrollstruktur muss einmal eingerückt sein
  • Die schließende Klammer steht in der Zeile nach dem body

if-else

  • Das else und das elseif befinden sich in der gleichen Zeile wie die geschweifte schließende Klammer des if-Körpers
  • elseif sollte statt else if genutzt werden

switch-case

  • Das case-Statement muss einmal eingerückt werden
  • Der case-body wird noch einmal eingerückt, das break-keyword befindet sich auf der gleichen Ebene wie der body
  • Wenn das break in einem nicht-leeren case weggelassen wird, muss ein Kommentar wie //no break eingefügt werden

4. Closures

  • Closures müssen mit einem Leerzeichen nach dem function-keyword und einem vor und nach dem use-keyword deklariert werden
  • Die öffnende geschweifte Klammer kommt in die gleiche Zeile wie die Deklaration
  • Die schließende geschweifte Klammer kommt in die Zeile nach dem body
  • Kein Leerzeichen nach der öffnenden Klammer oder der schließenden Klammer der Argumenten- Liste




Weitere Informationen sind auf der Seite http://www.php-fig.org/psr/psr-2/ von der PHP Framework Interop Group zu finden.

Erstellen einer Accelerated Mobile Pages (AMP) HTML-Seite

1. Was ist AMP?

AMP steht für „Accelerated Mobile Pages“ und ist ein Open-Source-Projekt, das von einigen Unternehmen ins Leben gerufen wurde. Das Ziel ist, Web-Inhalte, vor allem im Hinblick auf die mobile Entwicklung, möglichst schnell zu laden. AMP ist eine Möglichkeit Webseiten schneller zu laden und für mobile Geräte weiter zu optimieren. Vor allem für Blogbeiträge, Newsartikel, die oft mobil abgerufen werden, bietet sich diese Technik an. AMP besteht aus drei wesentlichen Teilen:

  • AMP HTML
  • AMP JS
  • Google AMP Cache

AMP HTML ist größtenteils reguläres HTML, das um ein paar spezifische Ausdrücke erweitert wurde. AMP JS ist eine JavaScript-Bibliothek, über die alle Lösungen zum schnelleren Laden einer Webseite implementiert sind. Auf eine eigene JavaScript-Datei muss allerdings verzichtet werden. Google wiederum bietet einen Cache, der für alle zugänglich ist und in den alle AMPs geladen werden. Dadurch sind die Seiten für andere Nutzer schneller verfügbar. Ein weiterer Vorteil von AMP besteht darin, dass diese von Google in den SERPs (Search Engine Result Pages) weiter oben stehen, da es ein Rankingfaktor ist.

2. Vorbereitung

Um seine Seite mit Hilfe von AMP zu optimieren, müssen zunächst ein paar Änderungen im Head der Seite vorgenommen werden. Im Folgenden ist der Grundaufbau einer AMP-Datei zu sehen:

<html amp lang="de"> 
<head>
<meta charset="utf-8"> <title>Hello, AMPs</title> <link rel="canonical" href="http://example.ampproject.org/article-metadata.html" />
<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
<script type="application/ld+json"> { "@context": "http://schema.org", "@type": "NewsArticle", "headline": "Open-source framework for publishing content",
"datePublished": "2015-10-07T12:02:41Z", "image": [ "logo.jpg" ]    } </script>
<style amp-boilerplate> body { -webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both; -moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both; -ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both; animation:-amp-start 8s steps(1,end) 0s 1 normal both }
@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}} @-moz-keyframe -amp-start{from{visibility:hidden}to{visibility:visible}} @-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}} </style> <noscript> <style amp-boilerplate> body{ -webkit-animation:none; -moz-animation:none; -ms-animation:none;
animation:none } </style> </noscript>
<script async src="https://cdn.ampproject.org/v0.js"></script> </head>

<body> <h1>Dies ist bereits eine AMP Seite!</h1> </body>
</html>

Im Head-Bereich benötigte Angaben

  • Zunächst muss das Dokument mit der Doctype-Description beginnen: <!doctype html>
  • Das HTML-Tag muss wie folgt ergänzt werden: <html ⚡ > oder alternativ <html amp>, um dem Browser mitzuteilen, dass es sich hierbei um eine AMP-HTML Seite handelt.
  • Die <head> und <body> -Tags dürfen nicht weggelassen werden.
  • Im Head muss mit diesem Tag
    <link rel="canonical" href="$EINE_URL" />
    der Link zu der normalen HTML Version der Seite angegeben sein. Ist diese nicht vorhanden, so muss die HTML AMP Seite auf sich selbst verlinken.
  • Das erste Element des <head>-Tags muss die Zeichenkodierung enthalten:
    <meta charset="utf-8"><meta name="viewport" content="width=device-width,minimum-scale=1">
    muss vorhanden sein.
  • Für die AMP JS-Bibliothek muss das Tag
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    als letztes Element des <head>-Tags enthalten sein. Das „async“ sorgt dafür, dass es asynchron geladen werden darf und so das onload-Event nicht verzögert
  • Ebenfalls darf auf das <style amp-boilerplate> Tag, wie oben angegeben, nicht verzichtet werden.

Alle übrigen Angaben, wie zum Beispiel die Schema.org Definition, sind für eine AMP HTML Seite optional. Um in anderen Diensten (z.B. Googles News) angezeigt zu werden, können diese benötigt werden.

Verbotene/Ersetzte Tags

Aus Performancegründen wurden einige HTML-Tags bei AMP HTML ersetzt und einige werden nicht unterstützt.


Nicht unterstützte Tags:

  • base
  • frame
  • frameset
  • object
  • param
  • applet
  • embed
  • form (Zukünftiger Support wurde bereits angekündigt)
  • input Elemente, textarea, select, option etc. (Davon ausgenommen ist das <button>-Tag)


Eingeschränkte Tags:

  • script (Nur erlaubt, um AMP Komponenten zu laden oder bei type="application/ld+json")
  • style (Ein zusätzliches Style Tag mit dem Attribut amp-custom ist im Head erlaubt)
  • link (rel-Attribute, die auf microformats.org registriert sind, sind erlaubt. Außerdem gibt es Ausnahmen, um benutzerdefinierte Fonts einzuladen)
  • meta (http-equiv-Attribut ist verboten)
  • svg
  • a (Der Wert des href Attributs darf nicht mit javascript: beginnen)


Ersetzte Tags:

  • img ⇒ amp-img
  • video ⇒ amp-video
  • audio ⇒ amp-audio
  • iframe ⇒ amp-iframe

Des Weiteren dürfen das style-Attribut, xml-Attribute sowie Attribute, die mit on beginnen (onclick, onmouseover etc.) nicht benutzt werden. Davon ausgenommen ist das on Attribut ohne Suffix.

3. AMP Elemente

Auf so gut wie jeder Webseite gibt es Bilder. Somit dürfte das wahrscheinlich wichtigste, weil meistbenutzte, AMP Element das <amp-img> Element sein. Anstatt das HTML eigene <img>-Tag zu benutzen, muss stattdessen die AMP Version dieses Tags benutzt werden.
Will man also ein Bild in seine Webseite einbauen, sähe das mit AMP zum Beispiel wie folgt aus:

<amp-img 
    src="pfad_zum_bild.jpg" 
    width=300 
    height=150 
    layout="responsive" >
</amp-img>

Das Attribut layout wird unter dem Punkt „Responsives Design“ erläutert.

Diese häufig benutzten AMP Elemente sind von Haus aus in der Standard-AMP-Bibliothek eingebaut. Erweiterte Komponenten müssen im Head des Dokuments eingeladen werden. Dazu später mehr.

Häufig benutzte Attribute

Um seine Seite AMP konform zu gestalten, sollten einem die Attribute layout, width, height, media, placeholder und fallback geläufig sein. Diese sind wichtig, um das Layout eines Elements zu definieren und diesem seinen Platz zu reservieren bevor andere Ressourcen wie JavaScript geladen wurden. layout Dieses Attribut bestimmt, wie sich das Element im Layout des Dokuments verhält. Die verschiedenen Werte für das Attribut werden unter dem Punkt „Responsives Design“ näher erläutert. Welche Werte das Attribut bei einem Element annehmen darf, steht in der Dokumentation des jeweiligen Elements.
width und height Je nachdem welchen Wert das Attribut layout eines Elements hat, müssen diese Werte gesetzt sein. Die Attribute müssen einen Integer Pixel Wert haben.
media Der Wert dieses Attributs ist ein media query. Immer wenn sich die Fenstergröße des Browser ändert, werden die Queries neu evaluiert und dementsprechend das Element angezeigt oder nicht.
placeholder Dieses Attribut kann nicht nur AMP Elementen, sondern jedem HTML Element zugewiesen werden. Ein Element, das dieses Attribut enthält, ist als Platzhalter seines Elternelements markiert. Es wird angezeigt, so lange die Ressourcen des Elternelements noch nicht geladen oder initialisiert werden konnten.
fallback Wie das placeholder Attribut kann auch dieses Attribut jedem HTML Element zugewiesen werden. Es dient dazu, dem Benutzer der Webseite mitzuteilen, wenn ein bestimmtes Element nicht angezeigt wird, weil es nicht den seinen Browser unterstützt wird.

Weitere Informationen zu den Attributen und Layout sind unter der AMP HTML Layout System Dokumentation zu finden.

Erweiterte Elemente

Erweiterte Elemente sind nicht im Standardumfang der AMP Bibliothek enthalten und müssen extra im Head eingeladen werden. Dabei handelt es sich um Elemente, die nicht so häufig gebraucht werden, wie zum Beispiel Bilder. Sie werden innerhalb eines <script>-Tags geladen:

<script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script>

Wichtig ist, dass die async– und custom-element-Attribute nicht weggelassen werden dürfen.
Eine Liste aller momentan zur Verfügung stehenden erweiterten Elemente ist hier zu finden. Zu jedem dieser Elemente gibt es eine Seite, auf der diese ausführlich beschrieben werden. Zu Beginn der Seite findet man eine kleine Übersicht, in der man unter anderem den zum Einladen nötigen <script>-Tag und einen Link zu einem Beispiel findet.

Unter ampbyexample.com sind alle AMP Elemente mit Beispielen aufgelistet. Diese Seite eignet sich gut, um einen Überblick über die Elemente und ihre Implementierung im eigenen Code zu bekommen.

4. AMP und CSS

Bei der Benutzung von CSS gibt es ein paar Einschränkungen, über die man Bescheid wissen sollte. Zunächst muss auf externe Stylesheets verzichtet werden. Ebenso muss man auf Inline Style Attribute verzichten und einige Styles sind aus Performancegründen tabu.

Die Styleangaben müssen im Head des Dokuments angelegt werden. Dabei sollte man darauf achten, dass dieser Bereich nicht zu groß wird: maximal 50000 Bytes sind erlaubt, um AMP konform zu bleiben. Muss es doch etwas mehr sein, so kann allerdings auf CSS-Präprozessoren, wie zum Beispiel Sass oder Less, zurückgegriffen werden.

Verbotene Styles

Inline Style Attribute Alle Styles müssen im <head> der Seite innerhalb eines <style amp-custom> Tags stehen.
! important Da dieses Element durch das AMP CSS selbst benutzt wird und wichtig für die Größenänderungen der Elemente ist, darf es nicht verwendet werden.
<link rel=“stylesheet“> Diese Formulierung ist nur zum Einbinden von benutzerdefinierten Fonts zulässig. Externe Stylesheets sind nicht erlaubt.
* (universeller Selektor) Der universelle Selektor darf nicht benutzt werden, da sich das negativ auf die Performance der Seite auswirken kann. Außerdem könnten dadurch andere Restriktionen umgangen werden.
:not() Dieses Element könnte dazu benutzt werden, den universellen Selektor zu simulieren.
Pseudoselektoren, Pseudoklassen, Pseudoelemente Diese sind nur in Verbindung mit Selektoren, die Tag-Namen enthalten erlaubt. Davon ausgeschlossen sind Tag-Namen, die mit amp- beginnen. Beispiele: a:hover, div:last-of-type sind erlaubt, amp-img:hover ist nicht zulässig.
-amp- Klassen und i-amp Tag-Namen Benutzerdefinierte Klassennamen dürfen nicht mit -amp- beginnen, da diese der AMP-Runtime vorbehalten sind. Im Style Bereich sollte deswegen darauf verzichtet werden, mit Selektoren auf -amp- Klassen und i-amp Tags zuzugreifen.
behavior, -moz-binding Diese Eigenschaften sind aus Sicherheitsgründen nicht erlaubt.
filter Filter dürfen aus Performancegründen nicht verwendet werden.

Transitions und Animations

Transitionen und Animationen sind nicht grundsätzlich verboten. Solche, die bei den üblichen Browsern durch die GPU unterstütz werden, sind generell zulässig. Momentan sind opacity, transform samt -vendor-Prefixes erlaubt. Bei der overflow Eigenschaft muss darauf geachtet werden, dass diese nicht als „auto“ oder „scroll“ gestylt werden darf. Außerdem darf kein benutzerdefiniertes Element eine Scrollbar aufweisen.

Benutzerdefinierte Fonts

Es gibt zwei Möglichkeiten, bei AMP Seiten benutzerdefinierte Fonts einzubinden. Zum einen ist es möglich, in einem link-Tag auf einen von AMP „weißgelisteten“ Anbieter zu verlinken. Zu diesen Anbietern zählt momentan nur: https://fonts.google.com/.
Zum anderen können Fonts auch über @font-face eingebunden werden.

5. Responsives Design

Zur Unterstützung des responsiven Designs einer Seite gibt es bei AMP ein paar neue Attribute, die den AMP Elementen zugewiesen werden können. Das wichtigste unter ihnen ist das layout Attribut, das mit den Attributen width und height zusammenarbeitet.

Folgende Werte werden durch AMP für das Layout Attribut unterstützt:

nodisplay Keine Angabe zu Höhe/Breite nötig.
Dieses Layout kann jedem AMP Element zugewiesen werden. Es hat den selben Effekt wie display: none
fixed Angaben zur Höhe/Breite nötig.
Die Elemente haben eine festgesetzte Breite und Höhe und unterstützen kein responsives Design. Ausnahmen sind amp-pixel und amp-audio Elemente.
responsive Angaben zur Höhe/Breite nötig.
Das Element wird auf die Breite seines Containers vergrößert oder verkleinert und die Höhe entsprechend angeglichen. Mit Hilfe der max-width Eigenschaft kann die Größe des Elements angepasst werden. Dieses Layout funktioniert mit allen AMP Elementen.
fixed-height Angabe zur Höhe nötig.
Das Element nimmt den zur Verfügung stehenden Platz ein, ohne dabei seine Höhe zu verändern. Das width Attribut sollte nicht angegeben werden oder auf auto gesetzt sein.
fill Keine Angabe zu Höhe/Breite nötig.
Das Element übernimmt die Höhe und Breite des Eltern-Elements.
container Keine Angabe zu Höhe/Breite nötig.
Das Element übernimmt seine Größe von seinen Kind-Elementen, ähnlich einem div. Es verhält sich wie ein Container.

Wenn möglich, sollte das responsive Layout verwendet werden, da dieses der Idee des responsiven Designs entspricht.
Ist das Layout Attribut nicht vorhanden, so wird dem Element abhängig von den gesetzten Werten automatisch ein Layout zugewiesen.

Um seine Seite möglichst responsiv zu gestalten, ist es möglich, allen AMP Elementen das Attribut media zuzuweisen. Dieses funktioniert genau wie CSS Media Queries (die ebenfalls verwendet werden können).


<b><amp-img</b><br>
    media="(min-width: 650px)"<br>
    src="breit.jpg"<br>
    width=466<br>
    height=355<br>
    layout="responsive" <b>></b><br>
<b></amp-img></b>



Je nachdem wir breit der Bildschirm ist, wird eines der beiden Bilder ausgegeben.


<b><amp-img</b><br>
    media="(max-width: 649px)"<br>
    src="schmal.jpg"<br>
    width=527<br>
    height=193<br>
    layout="responsive" <b>></b><br>
<b></amp-img></b>

Des Weiteren werden durch AMP die Attribute srcset und sizes zur Verfügung gestellt. Ersteres wurde bereits bei regulären HTML Seiten benutzt und hat den gleichen Zweck wie das Attribut media. Es stellt dem Browser je nach Bildschirmgröße andere Bilder zur Verfügung.


<b><amp-img</b><br>
    src="breit.jpg"<br>
    srcset="breit.jpg" 640w,<br>
           "schmal.jpg" 320w<br>
    sizes="(min-width: 650px) 50vw, 100vw" <b>></b><br>
<b></amp-img></b>

Die Zahl vor dem w teilt dem Browser mit, wie breit das jeweilige Bild ist. Mit Hilfe des sizes Attributs kann festgelegt werden, in welcher Größe das Bild angezeigt werden soll. Im obigen Beispiel nähme das Bild bei einer Breite des Viewports von 650px und mehr, 50% der Breite des Viewports ein. Hätte der Viewport beispielsweise eine Breite von 600px, so würde die Breite des Bildes auf 300px gesetzt. Dementsprechend würde das 320px breite Bild geladen.

Weitere Informationen, wie man das responsive Design seiner Seite mit AMP verbessern kann, gibt es auf:
www.ampproject.org.

6. Validierung

Ob die nun erstellte Seite AMP-konform ist, lässt sich schnell feststellen. Zusammen mit der AMP JS-Bibliothek wird ein AMP Validator mitgeliefert.
Um diesen zu benutzen, muss #development=1 an die URL der Seite angehängt werden. Nach der Aktualisierung
der Seite werden in der Entwickler-Konsole mögliche Validierungsfehler angezeigt.

Alternativ kann das Web-Interface unter validator.ampproject.org benutzt werden. Dort kann man einfach die URL der Seite angeben und auf VALIDATE klicken. Der Code der Seite wird daraufhin in einem interaktiven Editor angezeigt. Falls Fehler vorhanden sind, werden sie darunter angezeigt und im Code markiert.

Als dritte Möglichkeit wird eine Browsererweiterung (bis jetzt nur für Chrome und Opera verfügbar) angeboten, die jede besuchte AMP Seite automatisch prüft und mit Hilfe eines Icons anzeigt, ob die Seite AMP-konform ist. Praktisch ist außerdem, dass es ein spezielles Icon gibt, um zu signalisieren, dass die besuchte Seite zwar keine AMP Seite ist, aber eine AMP Version dieser Seite vorhanden ist.

Damit die erstellte AMP in den Google Cache geladen wird, muss diese validiert werden. Zur Unterstützung bei der Fehlerbehebung haben die AMP Entwickler einen Guide zu den verschiedenen AMP Validierungsfehlern zur Verfügung gestellt. Dieser kann hier gefunden werden.

Nach der erfolgreichen Validierung des Codes steht der Veröffentlichung der Seite nun nichts mehr im Wege. Ist noch eine Version der Seite in regulärem HTML vorhanden, so muss im Head dieser Seite auf die AMP Version verlinkt werden und umgekehrt. Ist eine solche nicht vorhanden, so muss der Link im Head der AMP Seite auf diese selbst verweisen:

<!-- Reguläre Seite: --> <link rel="amphtml" href="https://www.beispiel.com/url/zu/amp/dokument.html"> 
<-- AMP Seite: --> <link rel="canonical" href="https://www.beispiel.com/url/zu/regulaerem/dokument.html">

Weiterführende Informationen

Unter folgenden Links sind weitere Informationen zu AMP zu finden:

Doppelt hält Besser (IPv4/IPv6): Dual Stack mit neuem Server

Seit nun fast 5 Jahren testen wir unsere Webseiten auch mit IPv6, heute ist es dann nun auch soweit, dass unsere Webseite https://www.coding-pioneers.com über IPv6 endlich verfügbar ist. Ebenso können alle unsere Hosting-Kunden ebenfalls ihre Webseite im Dual Stack-Betrieb mit IPv4 und IPv6 auf unseren Servern betreiben.

Doch der Reihe nach: Was ist eigentlich dieses IPv6 und was macht das im Web?

Mit der Protokollerneuerung von IPv6 ändern sich grundsätzliche Abläufe der Netzwerkkommunikation. Die Erweiterung des Adressraums von 32 auf 128 Bit wirkt dabei zum einen der Verknappung der IPv4-Adressen entgegen. Zum anderen ermöglicht der neue Standard, alle Endgeräte in einem Netzwerk eindeutig zu adressieren. Anders als IPv4 setzt die Version 6 des Internet-Protokolls den Grundgedanken des Ende-zu-Ende-Prinzips konsequent um.


IPv6, noch Fragen?

IPv6 steht für „Internet Protocol Version 6“ und ist ein Verfahren zur Übertragung von Datenpaketen in paketvermittelnden Rechnernetzen, insbesondere dem Internet. Zusammen mit vielen weiteren Netzwerkprotokollen bildet IPv6 die Grundlage für die Kommunikation im Internet der Zukunft. Zentrale Funktionen von IPv6 sind die Adressierung von Netzwerkelementen über die IPv6-Adressen sowie die Paketweiterleitung zwischen Teilnetzen (Routing). Dazu setzt IPv6 an der Vermittlungsschicht (dem Layer 3 des OSI-Schichtenmodells) an.

Die Vergabe von IP-Adressen erfolgt über sogenannte RIRs (Regional Internet Registries), die von der IANA (Internet Assigned Numbers Authority) jeweils eigene IP-Adressbereiche zugeteilt bekommen. Die zuständige RIR für Europa, den Nahen Osten und Zentralasien ist das RIPE NCC (Réseaux IP Européens Network Coordination Centre).

IPv6 vs. IPv4

Das neue Adressformat der 6. Protokoll-Version unterscheidet sich auf den ersten Blick deutlich von dem des Vorgängers IPv4.

  • IPv4-Adresse: 62.108.36.46
  • IPv6-Adresse: 2a00:0f70:abcd:0102:0000:0000:245:0002

Während bei IPv4 32 Bit-Adressen zum Einsatz kommen, setzt der Nachfolger IPv6 auf 128 Bit-Adressen, die aufgrund der besseren Lesbarkeit hexadezimal dargestellt werden.

So wird das zentrale Anliegen des neuen IP-Standards umgesetzt: Mit 128 Bit lassen sich deutlich mehr einzigartige IP-Adressen generieren als mit 32 Bit.

  • Adressbereich von IPv4: 32 Bit = 232 Adressen ≈ 4,3 Milliarden Adressen
  • Adressbereich von IPv6: 128 Bit = 2128 Adressen ≈ 340 Sextillionen Adressen

Wer sich nun darunter kaum etwas vorstellen kann: Der Adressbereich von IPv4 mit ca. 4,3 Milliarden IPs reicht nicht einmal, um jeden Menschen auf der Welt mit einer einzigartigen Adresse zu versorgen, während sich mit dem 128 Bit-System theoretisch jedem Sandkorn der Erde gleich mehrere IP-Adressen zuweisen lassen würden. Die Einführung von IPv6 ist somit als Investition in die Zukunft zu betrachten. Durch das Internet der Dinge (engl. „Internet of Things“, oder kurz: IoT) wird die Zahl der Geräte, die eindeutig identifizierbar mit dem Internet verbunden werden müssen, in den nächsten Jahren deutlich zunehmen.

Aufbau einer IPv6-Adresse

Die 128 Bit einer IPv6-Adresse sind in acht Blöcke à 16 Bit geteilt. Durch hexadezimale Schreibweise lässt sich ein 16-Bit-Block mit vier Ziffern (0-9) bzw. Buchstaben (A-F) notieren. Als Trennzeichen dient der Doppelpunkt:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002

Um eine IPv6-Adresse lesbarer zu gestalten, gibt es Verkürzungen: Führende Nullen innerhalb eines Hexadezimalblocks dürfen weggelassen werden (dezimal zu vergleichen mit 0100 ist 100). Besteht ein Block nur aus Nullen, muss die letzte Null erhalten bleiben:

  • 2a00:0f70:abcd:0102:0000:0000:245:0002
  • 2a00:f70:abcd:0102:0:0:245:0002

Einmal je IPv6-Adresse dürfen aufeinanderfolgende Null-Blöcke gestrichen werden:

  • 2a00:f70:abcd:0102:0:0:245:0002
  • 2a00:f70:abcd:0102::245:0002


Die aufeinanderfolgenden Doppelpunkte (im Beispiel oben nach dem 5. Block) zeigen diese Streichung an.

Praktisch stehen dem Internet weniger Adressen zur Verfügung, als das 128 Bit-Format vermuten lässt (ähnlich wie bei IPv4). Der Grund ist das Gestaltungsprinzip: Der neue Standard soll eine echte Ende-zu-Ende-Verbindung ermöglichen und die Übersetzung von privaten in öffentliche IP-Adressen auf Basis von NAT (Network Address Translation) überflüssig machen (wie es bei IPv4 noch der Fall ist). Grundsätzlich ließe sich auch mit IPv4 einen Ende-zu-Ende-Verbindung realisieren; da der IPv4-Adressraum jedoch zu klein ist, um jedes Gerät mit einer einzigartigen Adresse zu versorgen, wurde ein System mit getrennten Adressbereichen und der vermittelnden Komponente NAT entwickelt. Mit dem neuen Standard lässt sich jetzt jedes Endgerät, das an ein Netzwerk angeschlossen ist, über eine eigene IP logisch adressieren. IPv6-Adressen beinhalten daher zusätzlich zu dem Abschnitt zur Netzwerkadressierung (auch Netzadresse oder Routing-Präfix genannt) einen eindeutigen Interface-Identifier, der sich aus der MAC-Adresse der Netzwerkkarte des Endgeräts ergibt oder manuell erzeugt wird. Das Routing-Präfix als auch der Interface-Identifier umfassen dabei je 64 Bit einer IPv6-Adresse.

Aufbau: Routing-Präfix

Das Routing-Präfix einer IPv6-Adresse ist in der Regel in ein Netzwerkpräfix und ein Subnetzpräfix gegliedert. Dargestellt wird dies in der sogenannten CIDR-Notation (Classless Inter-Domain Routing). Dazu wird die Präfixlänge, sprich die Länge des Präfixes in Bits, mit einem Slash (/) an die Netzwerkadresse angehängt.

Die Notation 2a00:f70:abcd:0102::/64 beschreibt beispielsweise ein Subnetzwerk mit den Adressen 2a00:f70:abcd:0102:0000:0000:0000:0000:0000 bis 2a00:f70:abcd:0102:FFFF:FFFF:FFFF:FFFF:FFFF.

In der Regel bekommen Internetprovider (ISP) von der RIR /32er-Netze zugeteilt, die diese wiederum in Subnetze gliedern. An Endkunden werden entweder /48-Netze oder /56-Netze vergeben.

Das Paketformat von IPv6

Gegenüber IPv4 zeichnet sich IPv6 durch ein vereinfachtes Paketformat aus. Um die Verarbeitung der Pakete zu erleichtern, wurde für den Header eine Standardlänge von 40 Bytes (320 Bits) festgelegt. Optionale Informationen, die nur in Ausnahmefällen notwendig sind, werden in den Extension-Headers (EH) (dt.: Paketkopf-Erweiterungen) ausgelagert, die zwischen dem Header und der eigentlichen Nutzlast (Payload) eingebettet werden. So lassen sich Optionen einfügen, ohne dass der Header verändert werden muss.

Der IPv6-Paketkopf umfasst so nur noch acht Kopffelder, wohingehend bei IPv4 noch dreizehn Felder zum Einsatz kommen.

Jedes Feld im IPv6-Header enthält bestimmte Informationen, die für die Paketvermittlung über IP-Netze benötigt werden:

FeldErklärung
Version Beinhaltet die Version des IP-Protokolls, nach der das IP-Paket erstellt wurde (4 Bit)
Traffic Class Dient der Prioritätsvergabe (8 Bit)
Flow Label Pakete mit demselben Flow Label werden gleich behandelt (20 Bit)
Payload Length Gibt die Länge des Paketinhaltes (ohne Header) inklusive Erweiterung an (16 Bit)
Next Header Gibt das übergeordnete Transport-Layer-Protokoll an (8 Bit)
Hop Limit Gibt die maximale Anzahl an Zwischenschritten (Routern) an, die ein Paket passieren darf, bis es verfällt (8 Bit), und ersetzt damit das TTL aus IPv4
Source-IP-Address Beinhaltet die Absender-Adresse (128 Bit)
Destination-IP-Address Beinhaltet die Adresse des Empfängers (128 Bit)

Durch die Einführung der Extension-Header lassen sich optionale Informationen einfacher implementieren als bei IPv4. Auf dem Zustellungspfad eines Pakets mit IPv6-Extension-Header werden diese nicht vom Router geprüft noch verarbeitet, und so werden diese zumeist erst am Ziel ausgelesen. Somit ergibt sich eine deutliche Verbesserung der Routing-Performance von IPv6 zu IPv4, da diese optionalen Daten nicht mehr untersucht werden müssen.

Die Extension Header können unter anderem folgendes enthalten:

  • Knoten-zu-Knoten-Optionen
  • Zieloptionen
  • Routing-Optionen
  • Optionen zur Fragmentierung
  • Authentifikation und Verschlüsselung

Funktionalitäten von IPv6

Ein Großteil der Internetnutzer bringt IPv6 vor allem mit der Erweiterung des Adressraums in Verbindung. Der neue Standard bietet mehr: Weitere Funktionen, mit denen sich Einschränkungen von IPv4 überwinden lassen. Dazu gehört vor allem die konsequente Umsetzung des Ende-zu-Ende-Prinzips, die den Umweg über NAT überflüssig macht. Eine Implementierung von Sicherheitsprotokollen wie IPsec ist somit deutlich einfacher.

Darüber hinaus ermöglicht IPv6 die automatische Adresskonfiguration mit dem sog. Neighbor Discovery als auch die Vergabe mehrerer eindeutiger IPv6-Adressen pro Host mit unterschiedlichen Geltungsbereichen, um verschiedene Netzwerk-Topologien abzubilden. Neben der optimierten Adresszuordnung sorgen die Vereinfachung des Paketkopfes und die Auslagerung von optionalen Informationen für die Paketvermittlung in Extension-Headers für ein schnelleres Routing.

Mit QoS (Quality of Service) verfügt IPv6 über einen integrierten Mechanismus zur Sicherung der Dienstgüte, der für eine Priorisierung dringlicher Pakete sorgt und das Datenpaket-Handling effizienter gestaltet. Dazu wurden die Felder „Traffic Class“ und „Flow Label“ direkt auf die QoS-Methodik zugeschnitten.

Buzzwords des Online-Marketing für das Jahr 2016/2017

Wir waren auf der DMEXCO in Köln und haben uns Vorträge, Seminare und Diskussionsrunden für Euch angehört. Dabei sind uns folgende Buzzwords aufgefallen, die uns zweifelsfrei im nächsten Jahr begleiten werden: programmatic, mobil, performance-orientiert oder disrupted. Doch was steckt hinter den Wörtern?

Programmatic Advertising / performance-orientiert

Mittels Big-Data, der aktuellen Rechenpower und immer (künstlich-) intelligenteren Algorithmen lassen sich Vorhersagen treffen, was ein Nutzer wirklich sehen will. All diese Techniken stehen natürlich noch in den Anfängen, liefern aber auch dafür schon beeindruckend bessere Ergebnisse im bspw. Online-Advertising. Programmatic Advertising oder auch Programmatische Werbung ist im Online-Marketing ein Begriff, der das vollautomatische und individuelle Einkaufen/Schalten von Anzeigeflächen in Echtzeit Web bedeutet. Die ist über alle Plattformen (TV, Mobile-Devices, Wearables, Desktop) hinweg möglich. Ziel ist es, einem Nutzer die nur für ihn relevante Werbung anzuzeigen: One-to-One-Marketing. Dadurch gibt es im Marketing weniger Streuverluste und Werbung wird effizienter oder wie man häufig hören durfte: „performance-orientiert“ ausgeliefert. Im Optimalfall ist Marketing hiermit preiswerter, da die Conversion-Raten steigen und die Streuverluste geringer werden. Die Schattenseite der Technik: man braucht größere Datenmengen und ein wenig Intelligenz diese zu interpretieren.

Content-Marketing / Storytelling

Spätestens nach dem Google Such-Algorithmus-Update im Jahr 2015 gilt: „Content is king“! Notgedrungen haben viele Unternehmen Content regelrecht produziert. Dabei ist jedoch das Ziel aus dem Auge verloren worden: Der Besucher bzw. potentielle Kunde. Content-Marketing hat diesen Missstand aufgegriffen und entwickelt Content nicht für die Suchmaschine, sondern für den Nutzer. Ziel sind hier bestmögliche SEO-Ergebnisse aber der Kunde steht wieder im Mittelpunkt (was durch die Conversion-Rate gemessen wird).

Storytelling ist dabei im Content-Marketing ein essentieller Bestandteil der Kundenkommunkation. Storytelling lebt dabei von richtig guten Geschichten, um beim (potentiellen) Kunden auch eine entsprechende Emotion und Handlung hervorzurufen. Mit einer guten Geschichte kann auch die Marke oder das Produkt in den Hintergrund treten. Der Kunde bekommt weniger das Gefühl, dass ihm etwas verkauft wird, sondern dass er mit dem Produkt ein Problem lösen kann. Ein probates Mittel, mit dem Startups zur Zeit Millionenumsätze generieren.

Was für eine Rolle spielt dabei eigentlich VR/AR?

Die Technik hat sich seit dem Internet (zum Glück) entwickelt. Zunächst waren es einfache Textmeldungen, die zur Kommunikation genutzt wurden. Diese wurden durch eine Kommunikation mit Bildern abgelöst, aktuell sind Videos das probate Mittel der Wahl, um Geschichten zu erzählen. Mit den neuen Augmented Reality (AR) bzw. Virtual Reality (VR)-Möglichkeiten ist es möglich, eine noch tiefere Immersion zu erzielen. Der Nutzer betrachtet nicht nur die ihm präsentierte Geschichte, nein er kann Teil der Geschichte werden.

Mobile-first 2.0 – jetzt aber wirklich

In Deutschland entstehen über 50% des Web-Traffics über mobile Devices, auf Seiten wie Facebook sind es sogar 90% (20 von 22 Mio. Visits / Tag). Das Smarthphone ist dabei das Gerät, das wir kurz nach dem Aufwachen in der Hand haben und abends vor dem Schlafen zuletzt nutzen. Dabei werden Aufmerksamkeitsspannen kürzer und eigentlich hat keiner mehr Lust sich überflüssige Informationen anzusehen oder gar auf Webseiten zu warten, sich mit dem Navigationskonzept auf einer Seite zu beschäftigen oder Inhalte zu zoomen, um diese lesen zu können. Eine Seite muss nicht nur responsiv funktionieren, sondern sie muss auf die mobile Geräte möglichst zudesignt sein. Hier setzt Google mit seinem AMP an, Facebook empfiehlt doch gleich alles (oder zumindest vieles) über die Facebook-Page zu lösen und alle CMS-Hersteller versprechen, dass die von ihnen skizzierte Lösung das Mittel der Wahl ist. Kurzum: Der Dschungel wird größer und es wird essentiell hier einen Partner zur Seite zu haben, der diesen durchdringt, um hinterher im SEO-Ranking nicht komplett abzubauen und den Kunden inhaltlich dennoch zu erreichen.

Disrupted Business-Models

Alle, die nach den oben skizzierten Themen noch ruhig geblieben sind, denen sei nun gesagt: Your business model is (hyper) disruptive. Egal, ob die Hotelbranche durch Airbnb oder die Taxigesellschaft durch Uber kräftig aufgerüttelt wurde: So kann es – laut Ansicht einiger – in vielen Branchen weitergehen.

Aber mal ehrlich: Ein Jahrzehnte altes Geschäftsmodell, das darauf setzt, dass nicht jeder Endkunde CB-Funk zu Hause hat bzw. jeder Taxi-Fahrer ein Telefon mitführen kann, hat es kaum besser verdient. Wer seine Business-Strategie nicht regelmäßig auf Tauglichkeit prüft, muss früher oder später mit den Konsequenzen leben. Es gilt weiter dem Kunden einen USP durch die eigene Leistung zu geben. Für alle anderen gilt: