Strukturierte CMS-Textproduktion – eine Typologie

Nicht jeder hat die Zeit, einen meiner 90-Minuten-Vorträge in Gänze anzusehen. Zum Thema CMS gab es diesen Sommer wieder einen entsprechenden Mitschnitt. Umso besser, wenn ich dann mal die Zeit finde, die Essenz meiner mündlichen Ergüsse schriftlich herauszuarbeiten!

Wenn es darum geht, strukturierte Texte zu verfassen und im Rahmen eines CMS fürs Web aufzubereiten, haben wir Webdesigner bisweilen eine harte Nuss zu knacken: Wie bringen wir die technischen und gestalterischen Fähigkeiten (oder Nicht-Fähigkeiten) der Redakteure in Einklang mit dem Wunsch, abwechslungsreiche und spannungsvolle Layouts für die Leser zu erzeugen? Und das Ganze auch noch in responsiver Form?

In den vergangenen knapp 20 Jahren Web-CMS haben sich eine Reihe von Paradigmen entwickelt, wie dies zu handhaben sein könnte. Doch zunächst möchte ich zwischen den zwei extremen Anwendungsfällen unterscheiden, nämlich der Bleiwüste und dem Datenblatt.

Die Bleiwüste

Ein sehr einfach strukturierter Text, der im Grunde nur aus Absätzen, Überschriften, Hyperlinks und vielleicht einer kleinen Bullet-Liste besteht. Keine Bilder, keine Spalten, keine sonstigen Spielereien.

Diese Textart findet sich nur noch recht selten und stellt das geringste Problem dar. Die Redakteure lernen ein paar Brocken Markdown oder bekommen einen sehr stark abgespeckten WYSIWYG-Editor à la CKEditor vorgesetzt und können hier kaum etwas kaputt machen. Die Möglichkeiten zur individuellen Textaufwertung durch interessante Zusatzelemente ist allerdings nicht gebeben.

Als Beispiel mag ein typischer Blogbeitrag dienen, wie er auf Daring Fireball erscheint:

Das Datenblatt

Wenn es nicht um längere Freitexte geht, sondern um eine gewisse Anzahl von immer gleich strukturierten Daten und Metadaten (wie beispielsweise bei einem Shop oder Online-Katalog), so sieht die Eingabemaske im CMS entsprechend kleinteilig aus, wird einmalig vom Webdesigner in der sinnvollsten Form festgelegt und führt zu sehr einheitlich aussehenden Einzelseiten, die sich prima nach den Metadaten filtern und sortieren lassen.

Auf der kürzlich relaunchten Website der Fahrradmanufaktur Velotraum sind solche stark strukturierten Datenblätter zu begutachten:

Umgesetzt wird das alles im Handumdrehen mit individuell zusammengestellten und im Backend arrangierten Feldern in ProcessWire:


Alles dazwischen: Text mit Extras

Alle Inhaltsstrukturen, die zwischen diesen beiden Extremen liegen, bezeichne ich als frei strukturierbaren, reichhaltigen Inhalt. Oder kurz: Text mit Extras.

Und hier wird es erstmals richtig knifflig, denn die Ansichten darüber, wie dieser mittels CMS am besten umzusetzen sei, könnten unterschiedlicher nicht sein.

Über die Jahre habe ich fünf prototypische Ansätze gefunden, die jeweils verschiedene Ansprüche an das Zeitbudget des Webdesigners, die technischen Fähigkeiten des Redakteurs oder die Modernität des CMS stellen:

  1. What You See Is What You Get
  2. Shortcodes
  3. Matrix aus Widgets
  4. Stapel aus Komponenten
  5. Frontend-Editing

Und jetzt gleich nochmal im Detail – legen wir los!

1. What You See Is What You Get

Natürlich sind die WYSIWYG-Editoren im Laufe der Jahre besser geworden, doch ihr Ruf als HTML-Integritätskiller und Designverbrechen-Möglichmacher basiert schon irgendwie auf Fakten. MsoNormal, anyone?

Die ersten paar Jahre mit TinyMCE waren hart, doch ehrlicherweise muss man sagen, dass die Idee genial war, eine für Büromenschen vertraute Word95-Umgebung in das Backend eines CMS zu verpflanzen, um Webinhalte auf die gleiche Weise zu pflegen wie Printdokumente. Die anfänglichen Schwierigkeiten mit kaputtem HTML lassen sich inzwischen über Filter und sinnvolle Konfiguration in den Griff bekommen.

Konzeptionell gibt es jedoch immer noch zwei Herausforderungen. Zum einen das responsive Webdesign; hier trügt nämlich das WYSIWYG-Versprechen: Was man während der Inhaltserstellung sieht, ist nur in ganz bestimmten Sonderfällen das, was man bekommt.

Zum anderen gibt es oft ein gewisses Kompetenzgerangel zwischen Editor und CMS: Wer ist für die Extras zuständig, die den einfachen HTML-Text anreichern sollen: Bilder, Bildergalerien, Querverweise, Infoboxen usw.? Wird dies vom Editor übernommen, so muss dieser extrem individuell für das jeweilige CMS angepasst werden. Im Falle von WordPress geschieht das tatsächlich; den dort verwendeten TinyMCE erkennt man fast nicht wieder.

Kümmert sich hingegen das CMS um solche Extras, so sieht man im Editor meist nur einen Platzhalter, der über andere CMS-Felder mit Inhalt befüllt wird, nicht innerhalb des Editors.

Die meisten CMSe können und wollen sich den Einsatz eines hoch individualisieren WYSIWYG-Editors nicht leisten (insbesondere im Hinblick auf Third-Party-Plugins). Standard-Editoren können aber nur Standard-Aufgaben erledigen, keine fancy Spezialmodule sinnvoll integrieren. Es bleibt meist eine klapprige Lösung!

2. Shortcodes

Wer den Mut zur Abstraktion hat, vor allem aber den Mut, seinen Kunden eine gewisse Fähigkeit zur Abstraktion zuzubilligen, sollte sich überlegen, auf Shortcodes zu setzen. Das sind kryptische Platzhalter innerhalb von (meist mit Markdown) strukturiertem Text, die für die Platzierung der Extras, manchmal auch für kleinere Layout-Fragmente wie Spalten zuständig sind. Eine klassische Bildergalerie könnte dann so eingebunden werden:

## Unser Sommerausflug

Das war eine *ganz* besondere Sache. Aber seht selbst:

[[gallery name="sommerausflug" style="slider"]]

Das Konzept ist aus WordPress bekannt und stellt eine der präzisesten und auch zukunftssichersten Lösungen dar. Präzise deswegen, weil es quasi kaum möglich ist, aus Versehen falschen oder überflüssigen HTML-Code zu erzeugen. Man kann Shortcodes als eine Wortschatz-Erweiterung von Markdown verstehen – es gibt hier keine falschen Verschachtelungen oder leere p-Elemente.

Die Zukuftssicherheit des Codes liegt darin, dass das konkrete HTML, welches beispielsweise die Bildergalerie beschreibt, nicht im Editor lebt und ausgegeben wird, sondern vom Galerie-Plugin erzeugt wird. Wenn sich irgendwann Änderungen ergeben sollten, weil man Bildergalerien im Jahr 2017 anders codet als im Jahr 2025, kann man das global in einem Template ändern und alle Shortcodes sind trotzdem weiterhin gültig. Für den Redakteur ändert sich nichts!

Idealerweise überstehen hinreichend abstrakte Shortcodes sogar Relaunches mit komplett neuem HTML-Frontend, und im extremen Falle wäre sogar ein CMS-Wechsel denkbar. Ein Plugin, um WordPress-kompatible Shortcodes zu parsen und auszuwerten, existiert in jedem vernünftigen CMS.

3. Matrix aus Widgets

Die Lösungsansätze 1 und 2 fokussieren sich auf eine linearisierte Inhaltsbearbeitung, beschreiben also einen im Wesentlichen einspaltig gedachten Textfluss mit gelegentlichen Extras hier und da. Ganz anders die Matrix! Hier steht ein zweidimensionales Layout-Raster im Vordergrund, welches auf einzelnen Zeilen basiert, die wiederum in mehrere nebeneinander stehende Zellen geteilt sein können.

Es gibt eine ganze Reihe von CMS-Plugins, die ein solch freies Layout für Redakteure möglich machen: SiteOrigin Page Builder, WPBakery Page Builder, Grid. Der clevere Deal: Die Matrix kümmert sich nur um das Basis-Layout des Rasters, liefert hierfür ein hoffentlich stabiles und responsive HTML/CSS-Gerüst, für den Inhalt der einzelnen Zellen ist hingeben jeweils ein Text- oder WYSIWYG-Editor zuständig, oder eben ein sogenanntes Widget, wie es insbesondere aus WordPress oder Drupal bekannt ist.

Ein cleveres System, denn man verheiratet hier zwei bewährte Konzepte aus vielen CMSen: Einfache Textverarbeitung (siehe Bleiwüste) und systemweit wiederverwendbare Widgets.

Der Nachteil liegt allerdings auch auf der Hand: Eine frei gestaltbare Matrix verlangt nach einem Gestalter-Auge, wenn es gut aussehen soll. Unbedarfte Redakteure sind mit den Layout-Möglichkeiten leicht überfordert oder setzen die Matrix als Waffe gegen den guten Geschmack ein. Enttäuschungen in Sachen Linearisierung für Mobile sind außerdem vorprogrammiert. Für ansprechende Ergebnisse braucht es Einschränkungen und Leitfäden, die vom erfahrenen Webdesigner vorgegeben werden müssen.

4. Stapel aus Komponenten

Das in den letzten Jahren als sehr innovativ bejubelte Konzept ist eigentlich steinalt; bereits die allerersten Versionen von TYPO3 benutzten nämlich untereinander angeordnete Seitenabschnitte, die der Redakteur aus einer fixen Auswahl von Layout-Minivorlagen zusammenstellen konnte, ganz nach dem Motto „Text mit Bild links“, „Reiner Text“, „Slider-Galerie“ usw.

Die Benutzung in TYPO3 und TypoLight war damals etwas umständlich, insbesondere im Vergleich zu den simplen, universellen Textboxen, welche man von WordPress und anderen Blog-CMSen der Nuller Jahre kannte.

Doch eine regelrechte Renaissance hebt seit Mitte der Zehnerjahre das Stapelkonzept in das Bewusstsein vieler Webdesigner: bei craftCMS als Matrix bekannt, bei Kirby als Kirby Page Builder, bei ProcessWire als RepeaterMatrix und demnächst möglicherweise im WordPress-Core als Gutenberg.

Wieviel Freiheit der Redakteur bei diesem Spiel erhält bzw. wie groß die Auswahl an verfügbaren Komponenten-Typen ist, bestimmen Seitenbetreiber, Webdesigner und das Budget ;-) Klar ist: bei einem individuell erstellten responsiven Webdesign bedeutet jeder Komponententyp einen gewissen Aufwand für die Aufbereitung im Backend und Frontend. Zum Glück skaliert das Konzept sehr gut: Wir gehen oft mit einem begrenzten Set an Möglichkeiten an den Start und ergänzen nach und nach je nach Bedarf weitere Komponenten bzw. schaffen Variationsmöglichkeiten.

Volle Code-Kontrolle für den Webdesigner, visuell miteinander harmonisierende Komponenten, und eine kuratierte Freiheit für den Redakteur – das Stapelkonzept gehört klar zu den Stars im modernen CMS-Workflow!

5. Frontend-Editing

Einen vermeintlichen Blick in die Zukunft gewährt uns schon seit einigen Jahren das Bearbeiten von Seiteninhalten direkt im Frontend. Oft behauptet, selten tatsächlich in der Praxis eingelöst, aber nichtsdestotrotz hochinteressant.

Bildrechte: 20th Century Fox / DreamWorks Pictures

Konzeptionell sehen wir hier meist eine weitergedachte Version der Konzepte 3 und 4, wobei die angezeigten Preview-Inhalte bereits zu 100 % dem Endergebnis entsprechen und die ganzen Bedienelemente meist als schwebende Menüs über dem Inhalt platziert werden, dynamisch an den Stellen, wo sie gerade gebraucht werden.

Da die Trennung zwischen Front- und Backend aufgehoben ist, lassen sich individuell entwickelte Websites nur schwer entsprechend nachrüsten. Falls jemand Frameworks kennt, mit denen sich das machen lässt: Ab in die Kommentare! Die mir bekannten Frontend-Editing-Lösungen sind alle Teil eines größeren Theme-Pakets (siehe Divi) oder einer gehosteten Komplettlösung (wie bei Squarespace).

Sollte man einem Redakteur ein Tool wie Divi an die Hand geben? Eher nicht! Zu vielfältig sind die Möglichkeiten, Dinge visuell zu zerstören. Ich sehe Frontend-Editing eher als die moderne Version von Dreamweaver: ein Tool für Designer ohne Code-Ambitionen, die individuelle Einzelseiten für eine eher kleinere Kundenwebsite zusammenstellen. Solchermaßen eingesetzt bin ich von den grundsätzlichen Möglichkeiten durchaus beeindruckt. Aber ohne Reinfuchsen klappt das freilich auch hier nicht!

tl;dr

Es gibt verschiedene Möglichkeiten, wie CMS-Redakteure strukturierte Texte mit Extras erstellen können – alle mit unterschiedlichen Vor- und Nachteilen für Redakteur, Webdesigner und Budget. Welches die beste Methode ist, lässt sich nicht pauschal beantworten, aber der Stapel aus Komponenten ist ganz schön gut.

6 Kommentare

Dominik Dröscher

Ich finde es sehr elegant wie ProcessWire 3 Frontend Editing als Konzept mit anbietet: https://processwire.com/blog/posts/front-end-editing-now-in-processwire-3.0-alpha-4/

Habe das für eine relativ statische Kundenseite implementiert und viel Spaß damit gehabt: http://dl.blue.de/2RcCXW — natürlich eine sehr einfache Variante. Wie immer kann man beliebig in Tiefe und Breite erweitern (ProcessWire halt), aber in diesem Fall hat das sehr gut gepasst.

Es ist schön zu sehen, dass hier immer noch Platz für Innovationen und Experimente ist. Die RepeaterMatrix kommt inzwischen aber bei den meisten meiner CMS-Projekten zum Einsatz.

Matthias Lange

Sehr schöner Beitrag. Vielen Dank dafür. Bitte werft noch mal einen Blick auf das redaxo 5 das eine wie ich finde optimale »Stapel-Verarbeitung« bietet. Sehr schön auch die Lösung für Kirby (Kirby Page Builder), die ich so noch nicht kannte. Danke dafür.

Wir verbauen überwiegend redaxo, kirby und processwire. Dabei ist es oft nicht so sinnvoll jede Seite für den Kunden anpassbar zu machen. Wir haben bei Kundenprojekte festgestellt das bestimmte Einzelseiten und Module vom Kunden nie geändert wurden. Heute gehen wir dazu über eher zu fragen was der Kunde wirklich braucht. Das spart viel Geld (Frontend/Backend) und er bekommt am Ende ein Set von Optionen die er immer erweitern kann (so wie oben beschrieben).

amus

Shortcodes sind in meinen Augen bestenfalls eine Notlösung. Ich kann als Admin nicht verhindern, dass Shortcodes unbefugt verändert oder gelöscht werden.

Das sind Ansätze, die für Profis sicherlich ok sind. Redakteure, die ohnehin oft Angst haben, etwas kaputt zu machen, können hier bei einer normalen Textkorrektur einfach den Slider killen. Vernünftiges Content Management sieht sicherlich anders aus.

Gerrit

@amus: Das hängt wirklich vom Kunden ab. Ich habe jahrelang Seiten betreut, bei denen Shortcodes heftig benutzt wurden, die sehr stabil und ohne Probleme gelaufen sind. Ich versuche es inzwischen zu vermeiden, aber wenn das Budget klein, die Ansprüche groß und das technische Know-How ausreichend ist, kann es gut passen!

amus

@Gerrit: Na klar, kann so etwas funktionieren. Das Versprechen am Anfang eines Projektes ist aber häufig “so easy wie Word” und dann sieht sich der Redakteur mit Shortcodes konfrontiert.

Problematisch aber auch: Der Begriff Content-Management-System wird sehr großzügig ausgelegt. Im Grunde hat man ein Webseitenerstellungs-Tool. Medienneutral spielt gar keine Rolle.

Gutenberg in WordPress macht das Dilema deutlich: Der Redakteur kann sich eine Website “zusammenschieben”. Die ganze Konstruktion wird inkl. Shortcodes einfach in ein Datenbankfeld abgelegt. Diese Inhalte dann ganz oder teilweise noch mal in einem anderen Kontext zu nutzen (z.B. Newsletter, App, Print etc.), funktioniert bestenfalls mit Filtern, die den Code wieder aufräumen.

Dennis

Schöner und sehr treffender Artikel, Gerrit.

Vor allem den Absatz mit “Unbedarfte Redakteure sind mit den Layout-Möglichkeiten leicht überfordert oder setzen die Matrix als Waffe gegen den guten Geschmack ein.” ist genau das, was wir regelmäßig in der Praxis feststellen. Der Kunde wünscht eine multifunktionale Lösung, kann Sie aber nicht bedienen bzw. kommt mit der Vielfalt nicht zurecht, weil u.a. die gestalterische Kompetenz/Vorstellungskraft fehlt.

Kommentar verfassen