Das Problem damit, Kunden ein vollständiges CMS zu geben: Sie machen Dinge kaputt

Das Problem des unbeabsichtigten Redesigns

Ein Kunde öffnet sein WordPress-Dashboard, um eine Seite zu aktualisieren. Er möchte einen Absatz ändern. Dabei entdeckt er einen Button zur Änderung der Schriftgröße. Er macht sie größer. Dann entdeckt er einen Farbwähler. Die Überschrift ist jetzt türkis. Er fügt einen neuen Abschnitt mit einem Page-Builder-Block ein, den er noch nie verwendet hat. Ein Bild wird vom Handy hochgeladen - es ist 6.000 Pixel breit und 8 MB groß. Das Layout funktioniert auf Mobilgeräten nicht mehr. Nichts davon war beabsichtigt.

Das ist kein Hypothetisches. Varianten davon passieren auf fast jeder WordPress-Website mit mehr als einem Redakteur. Die Design-Philosophie der Plattform ist, dass mehr Flexibilität besser ist. Die Annahme ist, dass Kunden sowohl die Fähigkeit als auch die Zurückhaltung haben, diese Flexibilität innerhalb der Grenzen des ursprünglichen Designs zu nutzen. Diese Annahme ist meistens falsch - nicht weil Kunden unvorsichtig sind, sondern weil die Oberfläche jede Option als gleich gültig darstellt.

Wenn ein Schriftgrößen-Selektor Optionen von 10px bis 100px zeigt, signalisiert nichts in der Oberfläche, welche Werte für das Design angemessen sind. Wenn ein Farbwähler das gesamte Spektrum zeigt, gibt es keine Möglichkeit zu wissen, welche Werte zur Markenpalette gehören. Das CMS unterscheidet nicht zwischen "Design-Entscheidungen, die von der Person getroffen wurden, die diese Website gebaut hat" und "Einstellungen, die du wahrscheinlich in Ruhe lassen solltest."

Wie Page-Builder es schlimmer machen

WordPress Page-Builder - Elementor, Divi, WPBakery und ihre Konkurrenten - verstärken das Problem erheblich. Sie geben Redakteuren die Möglichkeit, Seitenabschnitte hinzuzufügen, zu entfernen und neu zu ordnen, Spalten-Layouts zu ändern und die visuelle Struktur einzelner Komponenten zu modifizieren.

Das Ergebnis ist, dass das Design einer Seite aufhört, eine feste Sache zu sein, und zu einer Variable wird. Jedes Mal, wenn ein Redakteur eine Seite öffnet, steht das Layout zur Modifikation bereit. Mit der Zeit driften Seiten vom ursprünglichen Design ab. Verschiedene Seiten verwenden unterschiedliche Abstände, unterschiedliche Schriftgrößen, unterschiedliche Farbkombinationen. Die Website beginnt so auszusehen, als wäre sie von mehreren verschiedenen Personen mit inkompatiblen ästhetischen Vorstellungen erstellt worden - weil sie es in gewisser Weise auch wurde.

Page-Builder erzeugen auch instabiles HTML. Der Code-Output von Elementor oder Divi ist stark verschachtelt, JavaScript-abhängig und ändert sich oft zwischen Plugin-Versionen. Eine Website, die nach dem letzten Update einwandfrei aussah, kann nach dem nächsten Layout-Probleme haben, ohne vorhersehbaren Auslöser.

Die Teillösung des Headless CMS

Plattformen wie Contentful, Sanity und Storyblok reagieren auf diese Probleme, indem sie Inhalt von der Präsentation trennen. Das CMS speichert rohen Inhalt - Text, Bilder, Beziehungen zwischen Inhaltstypen - und eine separate Frontend-Schicht entscheidet, wie er angezeigt wird.

Das ist eine erhebliche architektonische Verbesserung. Redakteure können das Layout nicht mehr direkt modifizieren, weil das Layout im Code lebt, nicht im CMS. Das Design ist unabhängig davon, was der Redakteur tut, stabil.

Die Einschränkung ist, dass die meisten Headless-Plattformen immer noch Rich-Text-Felder mit Formatierungsoptionen zulassen, und diese Formatierungsoptionen werden häufig missbraucht. Ein Langtext-Feld mit Fett, Kursiv, Überschriftenebenen und Link-Einfügung gibt einem Redakteur viele Möglichkeiten, eine Ausgabe zu erzeugen, die auf dem Frontend falsch aussieht. Eingefügter Inhalt aus Word bringt seine eigene Formatierung mit. Inline-Stile, die in einem Kontext funktionieren, brechen in einem anderen.

Das andere Problem ist die Komplexität. Headless-CMS-Plattformen sind primär für Entwickler konzipiert. Die redaktionelle Oberfläche für nicht-technische Nutzer variiert erheblich in der Qualität, und die Einrichtung einer Headless-Plattform auf eine Weise, die für ein nicht-technisches Team wirklich nutzbar ist, erfordert erheblichen Konfigurations- und Schulungsaufwand, den die meisten Projekte nicht einplanen.

Was strukturierte Felder tatsächlich lösen

Die Alternative ist ein CMS, das Redakteuren von vornherein keine Layout-Kontrolle gibt - nicht weil es gesperrt wurde, sondern weil die Felder, die es zeigt, keinen Layout-Eigenschaften entsprechen. Strukturierter Inhalt bedeutet, dass das CMS weiß, was jedes Inhaltsstück ist, nicht nur, wo es auf der Seite erscheinen soll.

Anstatt eines Textbereichs, in dem ein Redakteur den Hero-Abschnitt eintippt, gibt es separate Felder: ein Überschriftenfeld, ein Unterüberschriftenfeld, ein Fließtextfeld und ein CTA-Button-Feld. Jedes hat spezifische Einschränkungen. Die Überschrift hat ein Zeichenlimit. Das CTA-Feld hat ein Link-Ziel und ein Button-Label, aber keinen Farbwähler. Der Redakteur kann den Hero-Abschnitt nicht versehentlich anders aussehen lassen, weil die Design-Entscheidungen in der Feldstruktur eingebettet sind, nicht über die Oberfläche zugänglich.

Ein Bild-Upload-Feld kann Dimensionen, Dateigrößenlimits und Seitenverhältnis-Anforderungen durchsetzen. Ein Team-Mitglieder-Feld kann einen Namen, eine Rolle und ein Foto haben - aber keine Biografie, die als dreispaltiges Layout mit einem Pull-Quote formatiert ist. Der Inhaltstyp definiert die Struktur; der Redakteur füllt die Werte aus.

So funktioniert Kernset. Jeder Inhaltstyp ist als eine Reihe von typisierten Feldern mit expliziten Einschränkungen definiert. Redakteure sehen eine klare, einfache Oberfläche für die Inhalte, für die sie verantwortlich sind. Das Design bleibt über jedes Update hinweg konsistent, weil es durch Code kontrolliert wird, nicht durch die CMS-Oberfläche. Upload- und Textfelder können sinnvolle Grenzen durchsetzen, bevor Inhalte die Live-Website erreichen.

Das praktische Argument für strukturierte Inhalte

Das Geschäftsargument für strukturierte Inhalte hängt nicht von einem philosophischen Bekenntnis zur Trennung von Zuständigkeiten ab. Es geht schlichtweg um Support-Kosten und Design-Stabilität.

Wenn ein CMS Redakteuren vollständige Layout-Kontrolle gibt, sind die laufenden Kosten für die Aufrechterhaltung von Design-Konsistenz hoch. Jemand muss Inhalts-Updates auf Layout-Probleme prüfen. Jemand muss Seiten neu aufbauen, die Redakteure auf eine Weise verändert haben, die das Design zerschossen hat. Jemand muss auf "die Website sieht kaputt aus"-Nachrichten reagieren, die sich als Ergebnis eines gut gemeinten, aber schlecht ausgeführten Inhalts-Updates herausstellen.

Strukturierte Inhalte eliminieren die meisten dieser Kosten. Nicht weil Redakteure daran gehindert werden, irgendetwas zu tun, sondern weil das CMS selbst die Einschränkungen durchsetzt, die sonst manuelle Überprüfung erfordern würden. Redakteure haben echte Freiheit innerhalb der Grenzen dessen, was sie tatsächlich kontrollieren sollten. Entwickler verbringen Zeit damit, Features zu bauen, nicht unbeabsichtigte Redesigns zu reparieren.

Das Ergebnis ist eine Website, die in Jahr drei genauso aussieht wie in Jahr eins - nicht weil niemand sie angefasst hat, sondern weil jedes Update durch ein System erfolgte, das die Struktur aufrechterhalten hat, von der das Design abhängt.