Fokus auf Content: Worum es bei der CMS-Auswahl wirklich geht
Zu Beginn der meisten Website-Projekte steht die Auswahl eines geeigneten CMS. In welchem Ausmaß diese Entscheidung den Projekt-Erfolg beeinflusst, wird häufig unterschätzt. Denn unabhängig von Kosten, IT-Anforderungen, Entwickler-Präferenz und Bekanntheitsgrad hat das CMS weitreichende Auswirkungen auf dessen wichtigstes Feature: die Content-Pflege.
Die Varianz bei den unterschiedlichen Content-Management-Systemen ist groß, und ein ungeeignetes CMS kann fatale Auswirkungen haben.
Zu häufig genannten Schmerzpunkten gehören zu straffe Strukturen, die aktuellen oder zukünftigen Anforderungen nicht gerecht werden, sowie mangelnde Benutzerfreundlichkeit, die die Redaktionsarbeit zu einer frustrierenden Erfahrung werden lassen. Einem Website-Projekt, das schon in den Startlöchern an diesen Problemen krankt, ist eine kurze Lebensdauer quasi garantiert.
Was ist die Aufgabe eines CMS?
Jedes moderne CMS muss eine Lösung anbieten, um jenseits von starren Datenmodellen dynamische Inhaltsdarstellungen und ansprechende Landing-Pages zu erstellen. Hier gibt es verschiedene Ansätze: Von den flexiblen, aber nicht immer benutzerfreundlichen Page-Builder-Tools bis hin zu klassischen, fixierten Datenmodellen.
Wir vergleichen im Folgenden die Ansätze, stellen mit dynamischen Inhaltsblöcken einen Mittelweg vor und verorten die von uns verwendeten CMS auf dem Spektrum.
Page Builder und WYSIWYG
Als Reaktion auf die hohen Ansprüche an Flexibilität und Design-Freiheit in der Inhaltsbearbeitung sind die sogenannten Page Builder entstanden – also Tools, über die ganze Websites ohne Coding-Kenntnisse erstellt und gestaltet werden können. Die Page Builder folgen dem WYSIWYG-Prinzip – What-you-see-is-what-you-get.
Page Builder können sich im Detail unterscheiden, in der Regel bieten sie aber die folgenden Funktionen:
- Inline-Bearbeitung: Statt über ein separates CMS-Interface findet die Inhaltsbearbeitung direkt auf der Seite statt.
- Block-basierte Layouts: Der Editor bietet ein vordefiniertes Repertoire an Inhaltselementen, die frei kombiniert und platziert werden können.
- Design-Optionen: Jeder Block bietet zahlreiche Optionen zur Gestaltung und Darstellung – zum Beispiel Hintergrundfarben, Schriftgrößen, Abstände, Bildgrößen, etc.
- Responsive Anordnung von Blöcken: Für große Bildschirme können Blöcke nebeneinander platziert werden, auf kleinen Mobil-Geräten untereinander. Manchmal gibt es auch Optionen, um Blöcke auf bestimmten Bildschirmgrößen zu verstecken.
Ein Vorteil von diesem Ansatz ist die große Gestaltungsfreiheit, die er mit sich bringt. Komplexe Layouts können schnell aufgebaut werden. Die Seitendarstellung und Inhaltsstruktur kann für jede Seite individuell angepasst werden. Und das alles ohne zusätzliche Entwicklungskosten.
Diese Freiheit hat aber auch ihre Kehrseiten. Die Vielzahl an Blöcken und Optionen resultieren in einem sehr komplexen Interface mit einer steilen Lernkurve. Abgesehen von technischen Schwierigkeiten werden auch mehr Anforderungen an den Benutzer gestellt. Traditionell werden über ein CMS Daten gepflegt, während die verwendeten Datenstrukturen und die Darstellung die Zuständigkeit der Webdesigner:innen und -Entwickler:innen ist. Ein Page Builder verlagert diese drei Aufgabenbereiche auf die Redakteur:innen – die damit nicht nur inhaltliche, sondern auch technische Kenntnisse und Design-Skills mitbringen müssen.
WordPress und Divi-Editor: hier erfolgt die Bearbeitung mit hohen Freiheitsgraden direkt auf der eigentlichen Webseite.
Ein einheitliches Design zu schaffen wird dadurch schwieriger, weil das System komplette Freiheit bietet, verschiedene Darstellungs-Stile zu vermischen. Auch ist es nicht mehr möglich, das Design zentral zu ändern, da die Design-Optionen für alle Blöcke und Seiten individuell eingestellt sind. Ein Datenexport für einen zukünftigen Relaunch ist ebenfalls nicht möglich, weil ein Page Builder keine strukturierten Daten erzeugt. Eine zukünftige “Zweitverwertung” der Inhalte z.B. innerhalb einer App oder einer weiteren Website/Landingpage ist dann nicht möglich.
Dazu kommt noch, dass Websites, die mit reinen Page Buildern gebaut werden, häufig deutlich schlechtere Ladezeiten aufweisen.
Strukturierte Daten
Das andere Ende des Spektrums sind klassische Datenstrukturen, die über ein CMS-Interface bearbeitet werden. Seiten bestehen hier aus einem festen Set an Feldern, die ein vordefiniertes Datenmodell abbilden. Dargestellt werden diese Seiten mit einem fest programmierten Template, das die Bandbreite möglicher Inhaltsvariationen darstellen kann und in dem jedes Feld und jede Information einen festen Platz hat. Formatierungsmöglichkeiten beschränken sich auf ein Minimum – zum Beispiel auf kursiven oder fetten Text und Links im Beschreibungstext.
Strukturierte Daten bieten genau die Vorteile, die ein Page Builder von Natur aus nicht erfüllen kann. Die Daten sind Schnittstellen-offen und portabel, dadurch wird die Zukunftssicherheit garantiert. Bei der Bearbeitung müssen Redakteur:innen sich nur auf die Inhalte konzentrieren – Darstellung und Technik sind über das Template abgedeckt. Auch ermöglichen strukturierte Daten weiterführende Anwendungen wie statistische Auswertungen, automatisch generierte Übersichtslisten und Filter-Funktionen.
Übersichtlich: Eingabemaske für strukturierte Daten z.B. beim CMS ProcessWire
Das feste Design kann aber auch zum Nachteil werden – eben dann, wenn es darum geht, abwechslungsreiche und ansprechende Seiten und Landing-Pages zu bauen. Hier kommt das statische Datenmodell schnell an seine Grenzen.
Sowohl Page Builder als auch strukturierte Datenmodelle haben also Ihre Schwächen. Gibt es einen besseren Ansatz?
Die goldene Mitte: Dynamische Inhaltsblöcke
Wie so häufig findet sich ein guter Kompromiss zwischen den beiden Extremen. Wir möchten hier einen Ansatz vorstellen, mit dem wir für diverse Projekte gute Erfahrungen gemacht haben – dynamische Inhaltsblöcke. Dieser kombiniert die besten Aspekte von Page Buildern und strukturierten Daten. Seiten werden dabei aus einer Reihe von Blöcken zusammengestellt, die beliebig kombinierbar sind.
Die einzelnen Blöcke sind diskrete Inhaltseinheiten – Text, Bilder, Zitate, Downloads, etc. Jeder Block hat eine feste Datenstruktur. Ein Text-Block besteht zum Beispiel einfach aus einem Text-Feld mit Basis-Formatierungsmöglichkeiten. Ein Zitat besteht aus dem Zitat selbst, dem Autor und einem optionalen Link (um zum Beispiel auf die Website des Autors zu verlinken). Ein Download-Block besteht aus einer Reihe von verlinkten Dateien.
Beim CMS Craft werden die strukturierten Eingaben direkt dargestellt.
Abgerundet werden die Blöcke durch sehr präzise und reduzierte Design-Optionen – wie zum Beispiel die Darstellungsgröße eines Bildes oder eine Auswahl aus mehreren vordefinierten Hintergrundfarben. Die Blöcke können beliebig kombiniert und angeordnet werden, dadurch können komplexe und abwechslungsreiche Seiten aufgebaut werden. Gleichzeitig stellen die Blöcke eine strukturierte Datenbasis dar. So ist es kein Problem, die Darstellung und das Design zentral anzupassen, ohne alle bestehenden Blöcke überarbeiten zu müssen.
Wie erfolgt nun die eigentliche CMS-Auswahl?
Im Falle eines Website-Relaunchs oder einer Website-Neuerstellung ist es ratsam, die Anforderungen an ein CMS im Vorfeld genau zu definieren. Dazu macht es Sinn, sich folgende Fragen zu stellen:
- Wer arbeitet mit dem CMS? Redakteur:innen, Designer:innen oder IT-Mitarbeiter:innen?
- Welche Strukturen und Muster bestehen bei den zu verwaltenden Inhalten?
- Wie hoch ist die Varianz der zu verwaltenden Inhalte?
- Wie sehen die Designanforderungen an die Inhaltsdarstellung aus?
- Müssen bestehende Inhalte oder Datenbanken automatisiert übernommen werden?
- Für welche Anwendungen werden die Inhalte aktuell und zukünftig eingesetzt?
- Wie sehen die redaktionellen Workflows aus?
Aus den Antworten auf diese Fragen ergibt sich eine Verortung auf dem Spektrum zwischen fixierten Datenmodellen und Page Buildern – und damit ein Anforderungsprofil für ein geeignetes CMS. Bei der konkreten Auswahl kann es auch sinnvoll sein, die Arbeit mit dem CMS anhand von geeigneten Demo-Installationen zu testen und zu evaluieren.
Page-Builder-Ansätze in CMS
Zum Überblick möchten wir hier noch kurz darauf eingehen, wo die von uns eingesetzten CMS auf dem Spektrum zu verorten sind:
- WordPress setzt auf den Page Builder Ansatz – seit Version 5 ist mit dem Gutenberg Editor sogar ein Page Builder in das CMS integriert. Aber auch viele der meist genutzten Themes und Plugins stellen einen eigenen Page Builder zur Verfügung. Strukturierte Daten können in WordPress nur mit zusätzlichen Plugins eingepflegt werden.
- Drupal 9 hat einen starken Fokus auf strukturierte Daten und das Interface ist auch dafür ausgelegt. Page Builder oder dynamische Inhaltsblöcke sind nur über Umwege möglich, und die Inhaltsbearbeitung ist dabei deutlich umständlicher.
- ProcessWire ist auf strukturierte Daten ausgelegt, dynamische Inhaltsblöcke sind über das sogenannte Repeater-Matrix-Feld ebenfalls möglich. Einen Page Builder mit Inline-Bearbeitung oder Live-Vorschau gibt es aber nicht.
- Craft unterstützt strukturierte Daten und dynamische Inhaltsblöcke über das sog. Matrix-Feld. Die Inhaltsbearbeitung ist hier dank der eingebauten Live-Vorschau sehr komfortabel. Mit dieser kann man bei jeder Änderung direkt sehen, wie die dynamischen Blöcke am Ende aussehen werden. Das ermöglicht schnelleres Experimentieren mit Inhaltsstrukturen und Darstellungsmöglichkeiten.
Fazit
In jedem Fall spart eine rechtzeitige, geordnete CMS-Auswahl Zeit und Kosten bei allen Beteiligten. Denn nichts ist schlimmer als ein erzwungener Relaunch nach kurzer Zeit, weil die Redaktion mit dem CMS nicht klarkommt, minimal geänderte Anforderungen nicht umgesetzt werden können oder “Zweitverwertungen” der mühsam eingepflegten Daten nicht möglich sind.
