Edge Delivery Services
Wie funktioniert das "document based editing"
Edge Delivery Services
Endlich ist es so weit – die Konzeption und die Planung der eiligen Werbekampagne ist fertig.
Die Entwürfe, die in Microsoft Word und Excel erstellt wurden, sind intern abgenommen. Die Web-Kampagne soll jetzt blitzschnell ausgespielt werden.
Die Dokumente werden an AEM-Content-Autoren übergeben, Diagramme aus Excel exportiert und dann von AEM Asset-Autoren ins DAM eingespielt, Template-Autoren werden gebraucht, der Workflow wird gestartet… und nach etlichen Arbeitsschritten ist die Kampagne im Web veröffentlicht.
Manchmal wäre ein dokumentenbasiertes Erstellen von Websites wünschenswert, um Inhalte schnell publizieren zu können.
Das hat auch Adobe erkannt und Edge Delivery Services (EDS) in der AEM as a Cloud Service Infrastruktur auf den Markt gebracht. Bei Edge Delivery Service (EDS), auch bekannt als AEM Franklin oder Project Helix, handelt es sich um ein neues Modell, um schnell vollumfängliche Websites mit Hilfe von Google Docs oder Microsoft Docs (Word und Excel) erstellen zu können.
Als integrierter Bestandteil von Adobe Experience Managers können EDS und AEM-Sites in derselben Domäne koexistieren. EDS lässt sich ebenso mit Adobe Target, Analytics und Launch verwenden. Bild 1 zeigt den Unterschied zwischen der herkömmlichen Infrastruktur, bestehend aus AEM Autor und Publisher, und Edge Delivery Service.
Bild 1: Gegenüberstellung der AEM Sites & EDS Infrastruktur
Das bedeutet, Autoren können aus deren gewohnten Textverarbeitungsprogramm Websites erstellen. Das Dokument muss lediglich einer bestimmten Struktur entsprechen, die im Folgenden beschrieben wird.
Document Based Authoring
Jedes beliebige Dokument (Microsoft Word/Excel oder Google Drive Doc) lässt sich mit Hilfe von Edge Delivery Services in eine HTML-Seite umwandeln und in die Website einbinden.
Um eine übersichtliche Webpage erstellen zu können, wird das Dokument in gleiche Themenbereiche (sogenannte Sections) gruppiert und strukturiert.
Ein Dokument kann beliebig viele Sections haben. Diese lassen sich einfach im Dokument mit drei Punkten (…) oder einer horizontalen Linie unterteilen.
Bild 2: Aufbau eines Dokuments für das Ausspielen zu Edge Delivery Services
Bild 2 zeigt, dass Sections zwei verschiedene Inhalte beinhalten können: Standard-Inhalte und Blöcke.
- Standard-Inhalt: Dies stellt herkömmliche HTML-Elemente dar, wie Überschriften (h1-h6), Paragrafen (p), Listen (ol, ul), Bilder (picture) und so weiter. Fügen Autoren also bspw. Eine Heading-2 Überschrift im Dokument ein, wird diese automatisch in eine h2-headline im HTML für die Website umgewandelt.
- Block: Block-Inhalte sind etwas komplexer und sind mit AEM-Komponenten, wie bspw. einem Karussell, vergleichbar: Es handelt sich also um Content mit Funktionalität bzw. einem spezifischen Aussehen.
Blöcke werden mit Hilfe einer herkömmlichen Tabelle erstellt, die verschieden viele Spalten und Zeilen haben kann.
In Bild 3 wird die Einfachheit der Nutzung der Blöcke verdeutlicht, indem die direkte Beziehung zwischen dem Tabellennamen und der Art des zu generierenden Blocks hervorgehoben wird.
Ist der Tabellenname z.B. „cards“ (out of the box im Standard-Projekt vorhanden) werden übersichtliche Web-Cards für die Website erstellt.
Die Blöcke, deren Namen und deren Funktionen sind im Projekt hinterlegt, und Autoren können diese beliebig einsetzen.
Bild 3: Blöcke werden mit herkömmlichen Tabellen im Dokument erstellt
Zusammengefasst mag es unglaublich erscheinen, aber es ist wahr:
Content-Autoren benötigen lediglich Kenntnisse darüber, wie die Website in Bereiche gegliedert (--- mit Hilfe horizontaler Linien) bzw. wie Blöcke erstellt werden (mit Hilfe einer Tabelle und deren Tabellennamen, die den Block bestimmt). Abgesehen davon ist das Website-Erstellen für Autoren der gewohnte Prozess einer Dokumentenerstellung.
Jedem Dokument wird bei der Website-Generierung automatisch ein Header und ein Footer hinzugefügt, die in einem entsprechenden Dokument editiert werden können.
Außerdem lassen sich ebenso Dokumente in Dokumente inkludieren, verlinken, mit SEO-Daten hinterlegen und vieles mehr.
Der Name des Dokuments spiegelt sich in der URL wider, wobei „index“ jeweils die Startseite des übergeordneten Ordners ist.
Vorschau und Veröffentlichung der Seiten
Um eine Web-Seite aus dem Textdokument zu generieren und sie für EDS bereitzustellen, müssen die Seiten erst veröffentlicht (gepublished) werden, analog dem Publishing-Prozess, der bereits aus AEM Sites bekannt ist.
Die Möglichkeit von Vorschau und Veröffentlichung bietet den Vorteil, Änderungen vorab zu überprüfen. So kann man sicherstellen, dass die Website den gewünschten Inhalt korrekt darstellt, bevor sie öffentlich zugänglich gemacht wird. Dies ermöglicht eine sorgfältige Kontrolle und eine reibungslose Präsentation der Inhalte für die Benutzer.
Mit Hilfe der Chrome-Erweiterung „Sidekick“ (diese Erweiterung funktioniert ebenso mit anderen Browsern) lässt sich dies einfach verwirklichen.
Bild 4: Sidekick Webbrowser Erweiterung
Nachdem die Erweiterung in den Webbrowser installiert wurde (Bild 4), ist sie für den Browser verfügbar. Folgende Funktionen sind für EDS verfügbar:
- Vorschau & Massen-Vorschau der Website
- Veröffentlichen & Massenveröffentlichung (3)
- Dokument Bearbeiten (öffnet das Dokument) (1)
- Neu laden, um Änderungen zu sehen (2)
- URLs kopieren
- Aufheben der Veröffentlichung (Unpublish)
- Löschen der Vorschau
Bild 5: Vorschau einer Website mit dem aktivierten Sitekick von Adobe
Die Browser-Erweiterung Sidekick bietet viele weitere Funktionen.
Schnelle technische Einrichtung
Die Einrichtung der EDS Infrastruktur gestaltet sich äußerst unkompliziert und ist schnell einzurichten.
Folgendes wird benötigt:
- GitHub account
- Google account
- Google Drive / Sharepoint
- Ggf. node / npm für einen lokalen Server und eine lokale Entwicklungsumgebung
Zunächst wird ein neues Repository erstellt.
Hierzu bietet Adobe ein voll funktionsfähiges Repository (aem-boilerplate) [https://github.com/adobe/aem-boilerplate], das als Template genutzt werden kann.
Bild 6: Template für das eigene Repository nutzen
Der Name des Repositorys widerspiegelt den Namen der Website wider.
Vorsicht: Die Kombination aus Branch, Repository-Name und Git-Username darf nicht mehr als 60 Zeichen haben.
Ebenso muss ein Programm installiert werden, um den Code vom Repository zu EDS synchronisieren zu können. Mit der aem-code-sync [https://github.com/apps/aem-code-sync] Funktion lässt sich das Repository verknüpfen.
Die Website ist nun bereits erreichbar und setzt sich aus dem Branch-Namen, dem Repository-Namen und dem Git-Nutzernamen zusammen.
{branchname (1) }—{Git-Repository Name(2) }—{Git Nutzername (3)}.hlx.page
Im Beispiel aus Bild 7:
- https://main--eggsEDS-eggspert.hlx.page für die Vorschau
- https://main--eggsEDS-eggspert.hlx.live für die veröffentlichte Seite
Bild 7: Zusammensetzung der URL an einem Beispiel
Aus dem Standard wird ein default Content ausgespielt, der in Adobes Google Drive [https://drive.google.com/drive/folders/1MGzOt7ubUh3gu7zhZIPb7R7dyRzG371j] zu finden ist.
Der darin existierende Content (footer, index und nav für den Header) kann kopiert und in einen eigenen Ordner in Google Drive oder Sharepoint eingefügt werden.
Dieser Ordner ist nun für helix.com freizugegeben, um die Dokumente ausspielen zu können, siehe Bild 8.
Bild 8: Freigeben des Sharepoint Ordners an helix@adobe.com
Abschließend muss noch im Git Repository eine Konfiguration bearbeitet werden:
Auf der ersten Ebene befindet sich die Datei fstab.yaml, hier ist der mountpoint des gerade erstellten Google Drive Ordners anzugeben.
Bsp:
mountpoints:
/: https://drive.google.com/drive/u/0/folders/folderUID
Die Änderung muss in das Repository gepushed werden, nun werden die eigenen Google Drive Dokumente als Content für die Website ausgespielt.
In nur wenigen Minuten ist das „document based authoring“ aufgesetzt und der Content in Google Drive stellt den „Authoring Layer“ dar.
Entwicklung & Entwicklungsumgebung
Alle benötigten Informationen für die Website (Schriften, Icons, Styles usw.) findet man im Git-Repository und lassen sich beliebig ändern und erweitern.
Im Root-Ordner findet man ebenso den Ordner „blocks“. Hier sind die Blöcke mit deren Funktionalitäten und Styles aufgelistet.
Wird ein neuer Block benötigt (bsp. ein Karusell), kann dieser mit den entsprechenden CSS- & JS-Dateien erstellt werden. Um das Karussell für das Authoring nutzen zu können, muss lediglich der Name des Ordners in den Blocks, dem Namen der Tabelle im Dokument entsprechen.
Globale Stylings sind unter styles/styles.css und globale Skripte unter scripts/scripts.js zu finden.
Um Änderungen während der Entwicklung nicht immer direkt ins Repository pushen zu müssen, kann eine lokale Entwicklungsumgebung genutzt werden. Mit einem aem-cli Command Line Interface ist diese unkompliziert einzurichten.
Hierbei ist folgender node-Befehl auszuführen:
npm install -g @adobe/aem-cli
Sobald die CLI installiert ist, kann ein Node Server mit nur einem Command aufgesetzt werden:
aem up
Nun ist die Web-Seite auf einem Node-Server unter localhost:3000 mit einem integrierten Watcher erreichbar.
Fazit
Für diese neue Art der Content-Erstellung sind bestimmte Verhaltensweisen zu verlernen und neue anzunehmen.
Mit der allgemeinen Verfügbarkeit von Edge-Diensten bietet AEM jetzt einen großen Mehrwert, da jeder Office-Anwender ohne Einarbeitung als Autor fungieren und Inhalte in Sekundenschnelle erstellen könnte.
Und es ist vielversprechend:
Die Website, die mit EDS erstellt werden, haben eine Lighthouse Bewertung (Score) von nahe oder genau 100, was die hervorragende Leistung, Performance und Qualität der Web-Seiten verdeutlicht.
Haben Sie weitere Fragen? Oder sind Sie an einer Schulung interessiert Zögern Sie nicht uns zu kontaktieren!
Autor
Kontaktiere uns
Kontakt
Martin Brösamle
Leiter Vertrieb und Marketing
Balanstr. 73, Haus 19 81541 München
E-Mail: info@eggs.de Headquarter: +49 (89) 743456-0