Adobe Edge Delivery Services

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 Manager 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.

Das bedeutet, Autoren können mit Hilfe ihres gewohnten Textverarbeitungsprogramm Websites erstellen. Das Dokument muss lediglich einer bestimmten Struktur entsprechen, die im Folgenden beschrieben wird.

Adobe Document Based Authoring - Ein Überblick

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 definieren.

Bild 2 zeigt anhand eines einfachen Beispiels, wie die Struktur eines Dokuments für Document Based Authoring aussehen kann. Sections können dabei zwei verschiedene Arten von Inhalten beinhalten: Standard-Inhalte und Blöcke.

• Standard-Inhalt: Hierzu gehören herkömmliche HTML-Elemente, wie Überschriften (h1-h6), Paragraphen (p), Listen (ol, ul), Bilder (picture) und so weiter. Fügen Autoren also beispielsweise eine Heading-2 Überschrift in ein Dokument ein, wird diese automatisch in eine HTML h2-headline für die Website umgewandelt.

• Block: Block-Inhalte sind etwas komplexer und sind mit AEM-Komponenten, wie beispielsweise 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 dieser Blöcke verdeutlicht: Die direkte Beziehung zwischen dem Tabellennamen und der Art des zu generierenden Blocks wird hier ersichtlich.

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, einschließlich ihrer Namen und Funktionen, sind im Projekt hinterlegt und können von den Autoren flexibel verwendet werden

Zusammengefasst mag es unglaublich erscheinen, aber es ist wahr:

Content-Autoren benötigen lediglich Kenntnisse darüber, wie die Website in Bereiche (Sections) gegliedert, und wie Blöcke erstellt werden. Abgesehen davon folgt die Erstellung einer Website für Autoren dem gewohnten Prozess der Dokumentenerstellung.

Jedem Dokument wird bei der Website-Generierung automatisch ein Header und ein Footer hinzugefügt, die ebenfalls in den entsprechenden Dokumenten editiert werden können.

Darüber hinaus können Dokumente miteinander verlinkt, inkludiert, mit SEO-Daten versehen werden und vieles mehr.

Der Name des Dokuments spiegelt sich in der URL wider, wobei „index“ die Startseite des übergeordneten Ordners darstellt.

Vorschau und Veröffentlichung der Seiten mit Adobe Sidekick

Um eine Webseite aus dem Textdokument zu generieren und sie für Edge Delivery Services (EDS) bereitzustellen, müssen die Seiten erst veröffentlicht (gepublished) werden, was dem bekannten Publishing-Prozess aus AEM Sites entspricht.

Die Möglichkeit zur Vorschau und Veröffentlichung bietet den Vorteil, Änderungen vorab zu überprüfen. So kann sichergestellt werden, 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 umsetzen.

Nachdem Adobe Sidekick im Webbrowser installiert wurde, sind folgende Funktionen für EDS verfügbar:

• Dokument bearbeiten (öffnet das Dokument) (1)
• Neu laden, um Änderungen zu sehen (2)
• Veröffentlichen & Massenveröffentlichung (3)
• Vorschau & Massen-Vorschau der Website
• URLs kopieren
• Aufheben der Veröffentlichung (Unpublish)
• Löschen der Vorschau

Adobe Sidekick bietet viele weitere Funktionen um das Arbeiten mit EDS zu vereinfachen. Mehr dazu in der Dokumentation von Adobe.

Die technische Einrichtung der EDS Infrastruktur

Die Einrichtung der EDS Infrastruktur gestaltet sich äußerst unkompliziert und schnell. 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 auf GitHub ein voll funktionsfähiges Repository (aem-boilerplate), das als Template genutzt werden kann.

Der Name des Repositorys entspricht dem Namen der Website. Wichtig: Die Kombination aus Branch, Repository-Name und Git-Username darf nicht mehr als 60 Zeichen umfassen.

Ebenso muss ein Programm installiert werden, um den Code vom Repository zu EDS synchronisieren zu können. Mit der 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. Dies ergibt folgendes Schema:

{branchname (1) }—{Git-Repository Name(2)}—{Git Nutzername (3)}.hlx.page

Im Beispiel aus Bild 7 würden sich somit folgende URL ergeben:

• Vorschau: https://main--eggsEDS-eggspert.hlx.page
• Veröffentlichte Seite: https://main--eggsEDS-eggspert.hlx.live

Aus dem Standard wird ein Default-Content ausgegeben, der in Adobes Google Drive zu finden ist.

Der darin enthaltene Content (wie Footer, Index und Navigation für den Header) kann kopiert und in einen eigenen Ordner in Google Drive oder Sharepoint eingefügt werden.

Dieser Ordner muss nun für helix.com freigegeben werden, um die Dokumente ausspielen zu können. Siehe Bild 8.

Abschließend muss im Git Repository eine Konfiguration bearbeitet werden: Auf der ersten Ebene befindet sich die Datei fstab.yaml, in der der Mountpoint des gerade erstellten Google Drive Ordners angegeben werden muss. Bsp:

mountpoints:
    /: https://drive.google.com/drive/u/0/folders/folderUID

Die Änderung muss dann in das Repository gepushed werden. Danach werden die eigenen Google Drive Dokumente als Content für die Website bereitgestellt. In nur wenigen Minuten ist das Document Based Authoring eingerichtet und der Content in Google Drive dient als Authoring Layer.

Entwicklung & Entwicklungsumgebung

Alle benötigten Informationen für die Website (Schriften, Icons, Styles usw.) finden sich im Git Repository und können beliebig angepasst und erweitert werden. 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 (z. B. 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 Ordnername des 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.

Folgender Node-Befehl muss ausgeführt werden:

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 Webseite auf einem Node-Server unter localhost:3000 mit einem integrierten Watcher erreichbar.

Herausforderungen und Vorteile von Adobe EDS und Document Based Authoring

Die Einführung von Adobe Edge Delivery Services (EDS) verändert die Art und Weise, wie Content erstellt und bereitgestellt wird. Für diese neue Form der Content-Erstellung müssen bestimmte Arbeitsweisen verlernt und neue Ansätze adaptiert werden.

Mit der allgemeinen Verfügbarkeit von Edge-Diensten bietet AEM einen erheblichen Mehrwert, da jeder Office-Anwender ohne zusätzliche technische Einarbeitung als Autor fungieren und Inhalte in Sekundenschnelle erstellen kann. Die Content-Erstellung wird effizienter und einfacher.

Und es wird noch vielversprechender: Webseiten, die mit EDS erstellt werden, haben einen Lighthouse Score von nahe oder genau 100, was die hervorragende Performance, Qualität und Ladegeschwindigkeit dieser Webseiten bestätigt. Dies führt nicht nur zu einer besseren User Experience (UX), sondern steigert gleichzeitig SEO-Rankings.

Möchten Sie mehr über die Vorteile von Adobe EDS und Document Based Authoring erfahren? Oder interessieren Sie sich für eine Schulung? Zögern Sie nicht, uns zu kontaktieren!