The way to headless without losing your head

No. 1 – First things first: Change your mindset!

Headless Content Management Frameworks gewinnen immer mehr die Herzen unserer Kunden und der Entwickler. Doch sobald das erste Projekt mit diesem Ansatz startet, wird schnell klar, dass man eine andere Denkweise etablieren muss. Ist man nicht in der Lage, seinen Content in einer bestimmten Hierarchie oder in Datentypen zu sehen, wird das Projekt zum Scheitern verurteilt sein.

In den letzten acht Jahren war ich sehr aktiv in der Landschaft der CMS-Systeme (TYPO3, WordPress, Drupal, Kentico, Adobe Experience Manager…) unterwegs. Aus dieser Erfahrung heraus kann ich sagen, dass der Ansatz der Headless-Systeme wirklich eine Revolution darstellt. Die Vorgehensweise, Content und Präsentation zu trennen, bringt uns zurück zu den Wurzeln des Content Management. Doch dieser Wechsel geht natürlich nicht ohne Verwirrung und mit einer gewissen Ungewissheit einher. In diversen Meetups zu diesem Thema konnte ich mich mit vielen Entwicklern aus dem klassischen CMS-Umfeld austauschen. Einige der spannendsten Fragen waren:

• „Wie kann man gewährleisten, dass der Anwender selbst Seiten erstellen kann?“
• „Wie kann man die Navigation verwalten?“
• „Welches sind meine favorisierten Plugins?“

Einer der wichtigsten Punkte ist, das Konzept hinter Headless-Systemen zu verstehen. Sonst läuft man schnell in die Falle, das neue System in Richtung der bekannten CMS umzubiegen. Als Resultat landet man dann bei einer schlechten Implementierung des Ansatzes, ohne überhaupt einen der Vorzüge eines Headless-Systems zu haben.

No. 1.1 – Content first – then make it bling

In der Vergangenheit habe ich oft erlebt, dass Projekte von Anfang an zum Scheitern verurteilt waren, da mit einer kontraproduktiven Grundeinstellung gestartet wurde: „Wir müssen unsere Webseite/App neu gestalten!“. Also wird damit losgelegt, die wichtigsten Seiten zu designen und dann mit Content zu befüllen. Doch was ist falsch an diesem Ansatz? “Wir haben das doch schon immer so gemacht.” – Ganz genau hier liegt auch der größte Fehler. Wir fangen an Zeit zu verschwenden, indem wir Inhalte erstellen, die zu unserem Layout passen. Als weiteren Leitfaden möchte ich hier auch noch einmal auf den Artikel „Schema First Design – Produktentwicklung mit GraphQL “ verweisen.

Schauen wir einmal weiter auf den Lebenszyklus einer Webseite und der Entwicklung eines Unternehmens, können neue Anforderungen in Form von Apps oder Chatbots entstehen. Und schon beginnt der Prozess von vorn. Um die Verschwendung von Ressourcen zu vermeiden, sollte man einen Schritt zurückgehen und mit einer klaren Content-Strategie beginnen:

• Wer ist meine Zielgruppe?
• Wie sieht die Customer Journey aus, und welche Inhalte muss ich dem Anwender für die einzelnen Schritte innerhalb meiner Applikation bereitstellen?
• Welche Kommunikationskanäle möchte ich bedienen (Omni-Channel Marketing)?
• Wie kann man den Inhalt strukturieren, damit ich diesen wiederverwendbar nutzen kann?

Wenn die Content-Strategie einmal steht, kann man damit beginnen auf die Präsentations- und Interaktionsebene zu wechseln. Bitte führt euch stets vor Augen, dass Headless-Systeme darauf ausgelegt sind, mit Content First zu starten und herauszukristallisieren, was man überhaupt kommunizieren möchte, anstatt es nur schick aussehen zu lassen.

No. 2 – Reusable Content – Beyond the web

Bevor man aber beginnt Inhalt in Schriftform zu verfassen, benötigt man ein Content-Modell. Dieses Modell kann man analog zu einer Datenbankstruktur betrachten. Es beschreibt, welche Inhalte man erstellen will (Content-Types), wie diese strukturiert sind (Attributes), wie diese beschrieben werden (Metadata), wie die Inhalte kategorisiert sind (Taxonomies) und natürlich wie diese Inhaltstypen in Relation zueinander stehen (Relations).

Worin besteht also nun der Unterschied bei der Inhaltsmodellierung mit einem Headless-System? – Der Schlüssel ist die Organisation und Strukturierung der Inhalte, sodass sie eine hohe Wiederverwendbarkeit garantieren. Betrachtet man aktuelle Systeme, als Beispiel einmal WordPress, besteht der Inhalt meistens aus einer Titelzeile und einem Textfeld mit WYSIWYG-Editor.

Unstrukturierter Inhalt, der nicht wiederverwendbar ist

Diesen Ansatz kann man natürlich auch mit einem Headless-System fahren, jedoch verliert man dadurch einen riesengroßen Vorteil des Headless-Konzeptes: die Möglichkeit, Inhalte zu erstellen, die auf mehrere Kommunikationskanälen ausgespielt werden sollen. Der Inhalt sollte idealerweise unabhängig von der Darstellung sein. Dies bedeutet im Kontext eine klare Struktur, kategorisiert und mit Metadaten angereichert.

Strukturierter Inhalt, der über mehrere Kanäle genutzt wird

Einmal erstellt, ist man jetzt in der Lage, den Inhalt über verschiedene Webseiten, eine App, E-Mail Newsletter, Chatbots, digitale Assistenten, interaktive Schaufenster, AR/VR Apps, oder was zukünftig noch erscheinen wird, zu nutzen. Mit der steigenden Anzahl von Kommunikationskanälen und Endgeräten ist es umso wichtiger, Inhalte für eine einfache Wiederverwendbarkeit zu strukturieren. Ein gut durchdachtes Content Model bedeutet einen höheren Return on Investment der Inhalte, da der Inhalt über mehrere Kanäle und Anwendungen genutzt werden kann und der Lebenszyklus über mehrere Designanpassungen verlängert wird.

No. 3 – Breaking bad behaviors und WYSIWYG-Ansatz vermeiden

Die größte Herausforderung findet jedoch nicht auf der technischen Seite statt, sondern beim Endanwender. Über Jahre hinweg hat sich der Workflow etabliert, Inhalte im Kontext zum Design und mit Previews zu bearbeiten. Diese Denkweise ist auch keineswegs ein Vorwurf, da der WYSIWYG-Editor bei vielen Content-Management-Systemen als ausschlaggebendes Feature angepriesen wurde. Das Problem dabei ist jedoch, dass Inhalte nur für einen bestimmten Kanal oder ein vordefiniertes Design erstellt und bearbeitet werden. Doch als Redakteur sollte der Fokus darauf liegen, was ich mitteilen möchte und nicht mich damit rumzuschlagen, wie es am Ende aussieht. Denn Designs und die Kanäle, über die wir kommunizieren, können sich ändern und weiterentwickeln. Wir sollten also als einen wichtigen Grundsatz etablieren, dass Editoren sich nicht über die Präsentation sorgen müssen – das übernehmen die Frontend-Entwickler (SPA, Apps, PWA) – sondern ihren Fokus auf die Vermittlung von Informationen legen sollten.

No. 4 – Stakeholder überzeugen

Eine der prägnantesten Erscheinungen in den letzten Jahren waren die Drag-and-Drop Pagebuilder. Es herrscht auch heute noch ein Kampf zwischen den CMS-Anbietern, wer den komfortabelsten und umfangreichsten Pagebuilder hat, mit dem Ziel, dem Endanwender die Erstellung von einfachen Landingpages oder Salespages zu ermöglichen, und das alles ohne einen Entwickler. Viele Benutzer kamen auch mit dieser Frage zu mir: „Wie kann ich so etwas mit einem Headless-System realisieren?“

Meine Antwort auf diese Frage ist es, Seiten in sogenannte Schlüsselelemente wie: Bühnenbild (Hero-Image), Artikelübersicht oder aktuelle Karrierebeiträge zu gliedern. Somit versetzten wir den Anwender in die Lage, wiederverwendbare Content-Bausteine zu nutzen. Hierfür habe ich ein Beispiel visualisiert:

Redakteure mit modularen Inhaltsbausteinen versorgen

Natürlich sieht diese Art der Visualisierung nicht so attraktiv aus wie ein visueller Pagebuilder, jedoch erlaubt sie uns, Inhalte in einem strukturierten, wiederverwendbaren Format zu speichern. Der erste kurzweilige Eindruck für Redakteure ist, dass sie Komfort beim Erstellen der Inhalte verlieren, doch auf lange Sicht versetzen wir sie in die Lage, Inhalte über mehrere Designs zu erhalten und damit wiederverwendbaren Content zu erzeugen.

No. 5 – Neue Denkweise bei Menüstrukturen

Bei traditionellen Content-Management-Systemen werden Seiten in Baumstrukturen organisiert und geben somit meistens die Menüstruktur vor.

Klassische Navigation innerhalb eines CMS

Diese Herangehensweise ist für Redakteure sehr intuitiv, wird aber nicht über andere Kommunikationskanäle funktionieren. Denn eine App oder ein Chatbot nutzen andere Wege den Anwender zu navigieren, und dies ist auch einer der ausschlaggebenden Gründe, warum Headless-Systeme hier eine andere Denkweise erfordern. An dieser Stelle sei gesagt, dass wir natürlich eine sortierbare Struktur benötigen, wenn wir zum Beispiel an eine klassische Webseitennavigation denken.

Was passiert, wenn sich das Unternehmen entscheidet, einen weiteren Service zum Menü hinzuzufügen? Muss jetzt der Entwickler gefragt werden, einen neuen Menüpunkt einzufügen? Die Antwort ist nein, denn die Lösung ist auf unsere neue Denkweise zurückzuführen, und wir betrachten das Menü nun als separaten Content-Type. Wir erstellen einen neuen Typen, der einen Menüpunkt darstellt mit Attributen wie zum Beispiel: Name, Ziel-URL, Icon und so weiter. Okay, das sieht schon ganz gut aus, oder? Aber wie definieren wir jetzt ein Untermenü?

Beziehungen sind wie im echten Leben manchmal sehr hilfreich, so auch in diesem Fall. Wir definieren ein Subset innerhalb des eigentlichen Content-Type und nennen diesen Submenu „Items“, diese werden dann über Relationen einfach mit einer Linkauswahl hinzugefügt.

Content-Typ eines Menüs innerhalb eines Headless-CMS

Auf diese Art und Weise können wir jede Art von Navigation erzeugen – für Webseiten, Apps, Chatbots oder anderen Anwendungsszenarien. Es ist zwar nicht so intuitiv wie der klassische Ansatz, erlaubt jedoch mehr Flexibilität und Wiederverwendbarkeit.

No. 6 – APIs benutzen und Plugins vermeiden

Headless-Systeme gehen auch hier einen anderen Weg. Bei den traditionellen CMS installieren wir unsere Core-Applikation und fügen dann durch Plugins von Drittanbietern oder bereits integrierten Modulen Funktionalitäten hinzu. Benötigt man einen passwortgeschützten Bereich oder einen einfachen Warenkorb? – Da gibt es doch ein Plugin!

Das Problem, das ich hier sehe, ist der klassische Vendor Lockin in ein System und dessen Ökosystem. Sollte man sich etwa entscheiden auf ein anderes System zu wechseln, bedeutet dies meist eine komplette Neuentwicklung. Kosten, die man sich mit dem Headless-Ansatz sparen kann, denn diese Systeme sind darauf optimiert, Inhalte zu strukturieren, zu verwalten und diese über ein API auszuliefern.

Jetzt kommt wahrscheinlich die Frage auf, was mit den Plugins passiert. Muss ich diese alle neu entwickeln? Die Lösung dieses Problems können wir mit Software as a Service (SaaS) beantworten: Hier gibt es seit geraumer Zeit etablierte Lösungen für die verschiedensten Anwendungsfälle. Benutzer- und Rollenverwaltung können bequem mit Auth0 oder Okta gelöst werden. E-Commerce ist auch kein Problem, denn dank Stripe oder Snipcart sind diese Funktionen im Handumdrehen per Service angestöpselt. Kommentare und Formulare könnt ihr mit Diensten wie Google Forms, Netlify Forms und Disqus, Livefyre oder ähnlichen bereitstellen.

In der Welt der Headless-Architektur ist das CMS nicht mehr eure Development-Plattform. Stattdessen baut ihr eure Anwendungen mit verschiedenen Frameworks (React, Vue, Angular) und greift auf Services zurück, die euch weitere Funktionalitäten anbieten. Am Anfang habt ihr damit natürlich mehr Arbeit, aber perspektivisch könnt ihr somit einen Vendor Lockin vermeiden und habt eine saubere Trennung der Architektur.

Nochmal mit Nachdruck – Rethink!< – Startet klein, und vermeidet eine schmerzhafte Bruchlandung.

Wie ihr vielleicht an den Beispielen erkennt, ist Headless CMS nicht einfach ein neues Content-Management-System. Es ist eine komplett andere Vorgehensweise, um eure Applikationen zu entwickeln und erfordert ein Umdenken auf Entwickler- und Kundenseite. Um die Risiken zu minimieren, gerade in größeren Unternehmen, solltet ihr nach dem LEAN-Ansatz vorgehen. Startet mit einem kleinen Pilotprojekt, lernt damit laufen, lasst Fehlerkultur zu und lernt aus diesen Fehlern. So könnt ihr euch ständig weiterentwickeln und einen idealen Weg für euer Team und eure Kunden finden.

Wenn euch der Artikel gefallen hat, teilt ihn gerne mit anderen und lasst einfach einen Kommentar da. Danke fürs Lesen und bis bald.