Content-Editing mit Struktur

Es geht heute nicht mehr darum, mit einem CMS eine banale Web-Visitenkarte aufzublasen, es geht um Kommunikationsprozesse.

Wir werden uns in diesem Artikel damit beschäftigen, wie Redakteure Contents (Inhalte) bearbeiten, und in welcher Form diese Contents gespeichert werden, um sie später auf verschiedensten Plattformen und Geräten zu publizieren. Um die Dimensionen und die erweiterten Anforderungen an Content-Management besser einordnen zu können und zu entscheiden, wie in einem Unternehmen zukünftig Content strukturiert und verarbeitet werden soll, stellen wir im Folgenden zunächst verschiedene Editing-Konzepte vor und vergleichen sie anhand von drei konkreten CM-Systemen miteinander.

Konzepte im Vergleich

In der ersten Vorstellungsrunde werfen wir einen Blick auf Wordpress 5.0 mit seinem integrierten Gutenberg-Plugin, sowie das CMS Umbraco mit seinem Grid-Editor. Diese Art des Editings ist sozusagen ein Mittelweg zwischen BackEnd- und Inline-Editing. Als weiteren Typ  von Web-Editoren werden Sie das Inline Editing von NEOS kennenlernen, das CMS, das eigentlich Typo3 ablösen sollte, aber nun parallel zu Typo3 weiterentwickelt wird.

Warum wurden die oben genannten Systeme ausgewählt? Es gibt nur wenige gemeinsame Zielgruppen. Wordpress bedient Blogger und kleine Unternehmer und Selbstständige, NEOS versteht sich als Enterprise-CMS der nächsten Generation und Umbraco ist .NET-basiert und ist durch seine ASP.NET MVC System-Architektur prädestiniert, den Enterprise-Markt zu bedienen.

Wordpress ist weltweit am meisten genutzt, NEOS ist als Mitglied der Typo3-Familie in Deutschland gut bekannt und Umbraco wird außerhalb Deutschlands in Nordeuropa und den angelsächsischen Ländern häufig eingesetzt.

Alle drei Systeme bringen auf unterschiedliche Weise die grundlegenden Editing-Möglichkeiten eines CMS mit, die in diesem Artikel betrachtet werden sollen. Gemeinsam ist allen CMS, dass sie Open-Source-Systeme sind. Hinweis: FORMFAKTEN setzt Umbraco ein, weil es sich als CMS-Framework als äußerst flexibel erwiesen hat und sich Content-Strategien daher sehr gut mit Umbraco umsetzen lassen.

Vorstellungsrunde

1. BackEnd Editing mit Blocks

Wordpress hat Ende 2018 mit seiner runderneuerten Version 5 einen neuen Editor an den Start gebracht. In Anlehnung an den guten alten Buchdruck nennt sich diese Erweiterung »Gutenberg«. Zentrale Funktion dieses Editors ist die Devise »Building blocks«. Wenn man eine neue Seite oder einen neuen Post in Wordpress anlegt, kann mit einem Klick einen neuen Block anlegen und auswählen, welchen Inhalt dieser Block enthalten soll.

Wählt man als Inhaltstyp »Paragraph«, wird ein Block mit einem WYSIWYG-Editor erzeugt. Wählt man Bild, wird ein Block mit einem Editor für das Einfügen von Bildern erzeugt. So kann man beliebige Content-Blöcke untereinander stapeln. Auch mehrspaltige Blöcke lassen sich anlegen. Jede Spalte kann dann einen eigenen Editor enthalten. Nach wie vor ist es möglich, mit dem WYSIWYG-Editor Bilder und Medien einzusetzen.

Out-of-the-box steht eine stattliche Auswahl an Block-Typen zur Verfügung. Man kann darüber hinaus eigene Blöcke programmieren und somit das System erweitern. Man kann einzelne Blocktypen nicht auf bestimmte Post-Types (Seiten, Posts oder Custom Post Types) beschränken, es sei denn, ... ja richtig, man verwendet ein Plugin.

2. Umbraco Grid

Umbraco stellt Dokumenttypen bereit, die man als Sammlung von Properties verstehen kann. Ein Property ist jeweils einem Datentyp zugeordnet. Diesen Datentypen wiederum liegen Property-Editoren zugrunde. Die Editoren enthalten das eigentliche User Interface, mit dem Daten erfasst werden.

Der Web-Entwickler definiert für einen Dokumenttyp eine Sammlung an Properties, weist ihnen die passenden Property-Editoren zu und ermöglicht es damit, dass strukturiert Inhalte eingegeben werden können. Property-Editoren können UI-Komponenten für die Eingabe von Texten sein, das können Komponenten zum Einfügen von Bildern sein, von Datumsfeldern, Checkboxen und vieles mehr.

Man kann auch eigene Property-Editoren entwickeln, und mit Hilfe eines einfachen Plugin-Systems in das Gesamtsystem integrieren. Die Möglichkeiten sind dadurch unbegrenzt. Man kann in einem Dokumenttyp einfach nur einen WYSIWYG-Editor einfügen, oder komplexe Formulare für komplexere Datenstrukturen anlegen. Man kann die Property-Editoren auch in verschiedenen Reitern (Tabs) organisieren, zum Beispiel den Content in einem Tab, die Metadaten in einem anderen Tab. (In Umbraco V8 wird es keine Tabs mehr geben, aber einen adäquaten Ersatz in Form von Abschnitten.)

Jedem Dokumenttyp können ein oder mehrere Templates zugewiesen werden. Ein Template ist, wie der Name schon andeutet, ein Muster für den Output, den ein Dokument beim Rendern erzeugen soll. Jeder Wert eines Properties kann an beliebiger Stelle des jeweiligen Templates gerendert werden. Der Redakteur oder Content-Manager kann nun in der Content-Sektion seine strukturierten Daten eingeben, die dann mithilfe eines Templates gerendert werden. Welches Template verwendet wird, kann entweder fest vorab oder dynamisch zur Laufzeit bestimmt werden.

Umbraco hat in der Version 7 bereits seit 2014 einen Property-Editor im Einsatz, der sich Grid nennt. Ein Dokumenttyp kann also ein Grid als Property enthalten. Das Grid kann man sich als einen Container vorstellen, der wiederum Properties enthalten kann. Als Editoren für diese Properties können die im System vorhandenen  Property-Editoren wiederverwendet werden.

Die wichtigsten Funktionen sind out-of-the-box als Grid-Editoren verfügbar, wie zum Beispiel den HTML-Editor oder einen Medien-Editor. Mit Hilfe der vorhandenen Property-Editoren kann der Web-Entwickler sehr leicht neue Grid-Editoren definieren. Damit lassen sich komplexere Grid-Editoren wie Galerien, Akkordeons etc. mit ein paar Mausklicks zusammenstellen.

Hat der Entwickler das System soweit konfiguriert, kann der Redakteur mit der Arbeit beginnen. Der Redakteur hat die Möglichkeit, ein Raster zu definieren und in dessen Zellen (Areas) verschiedene Grid-Editoren einzusetzen. Zunächst wählt er sein Zeilenformat, wobei vom Einspalter bis zu mehrspaltigen Aufteilungen mit verschiedenen Breitenangaben alles möglich ist. Anschließend fügt er mit dem Auswahldialog den entsprechenden Grid-Editor ein. Die Festlegungen, welche Zeilenlayouts zur Verfügung stehen, trifft wiederum der Web-Entwickler. 

Für jedes Zeilenformat kann bestimmt werden, welche Grid-Editoren sichtbar sind. Man kann für jedes Grid im System auch die Optionen des RTE bestimmen. Zum Beispiel wird häufig die Möglichkeit zum Einfügen von Bildern deaktiviert, da in Umbraco ein eigener Grid-Editor für Medien zur Verfügung steht. So schafft man strukturierten Inhalt.

3. Inline Editing mit Neos

Eine Editing-Art wird immer wieder von neuem zum Leben erweckt, nachdem sie bereits mehrmals verworfen worden war: das Inline-Editing.

Es scheint nahe zu liegen, nicht nach Front-End und Back-End zu unterscheiden. Der Redakteur sieht die komplette Webseite samt Navigation, Farben, Hintergründen, Footer und Sidebar im fertigen Layout. Er sieht als eingeloggter Benutzer mit entsprechenden Redakteurs-Rechten lediglich Rahmen an den Stellen, an denen er Text bearbeiten kann, und kann innerhalb der bearbeitbaren Zonen weitere Content-Elemente hinzufügen.

Die Bearbeitung funktioniert auch responsive, d.h. wenn man mit dem Browser eine bestimmte Auflösung eines Gerätes, beispielsweise eines Smartphones, einstellt, verhält sich die Seite so, dass sich einzelne Spalten und Content-Elemente an die entsprechende Stellung im Layout-Grid, also im Web-Raster anordnen. Die Bearbeitung funktioniert also auch für alle möglichen Bildschirmauflösungen, die User Experience scheint für Redakteure hervorragend zu sein. »True WYSIWYG« ist das Schlagwort, mit dem man diese Art des Editing umschreiben kann.

4. Weitere Editing-Tools

Es gibt noch andere, einfachere Bearbeitungs-Tools, wie »MarkDown«- Editoren, die eine einfache Sprache zur Auszeichnung von Inhalten bereitstellen. Die so markierten Inhalte werden dann beim Rendern der Web-»Seite« automatisch als HTML ausgegeben. Oder ganz einfache Textareas, in denen man lediglich Text einfügen kann, ohne Auszeichnung oder Formatierung. Diese Möglichkeiten sollen hier gerne kurz erwähnt werden, aber ansonsten in der weiteren Betrachtung unberücksichtigt bleiben.

Sie haben bis hierher einige Konzepte des Content-Editing kennen gelernt. Welche dieser Möglichkeiten kann man nun für welche Anwendungsfälle verwenden? Welche Anforderungen gibt es denn im Zeitalter von semantischem Web, strukturiertem oder adaptivem Content? Und welche Art und Weise wird welchen Anforderungen gerecht?

Anforderungen

Als Content-Editor oder Redakteur muss man heutzutage bei der Bereitstellung von Inhalten verschiedenste Formate für alle möglichen Devices und Touchpoints berücksichtigen. Zudem muss man bei personalisierten Web-»Seiten« möglicherweise unterschiedliche Content-Blöcke bereitstellen, die zum Beispiel je nach Interesse des Nutzers oder seines Standortes trotz einer identischen URL unterschiedlich angezeigt werden. Das ist die Anforderung, dass Content »adaptiv« sein soll.

Adaptiver Content beschreibt die Fähigkeit eines webbasierten Systems, für verschiedenste Geräte nicht nur das Design, sondern die Inhalte an die Bedürfnisse des Nutzers anzupassen. Nicht jeder Nutzer einer Site hat die gleichen Erwartungen an ein Web-Angebot. Spielt man Inhalte an große interaktive Displays mit Touch-Fähigkeit aus, wie man sie beispielsweise auf Flughäfen oder am POS großer Möbelhäuser sieht, möchte man zwar auf die Daten eines zentralen CMS zurückgreifen, aber die Bedienung und der Umfang der Inhalte unterscheidet sich stark von den Inhalten anderer Touch-Devices wie Smartphones oder Tablets.

Willkommen im Multichannel-Universum

Geräte ändern sich, die Features der Geräte ändern sich kontinuierlich, dadurch ist ein in Blöcken strukturierter Inhalt für zukünftige Plattformen leichter auf neue Plattformen portierbar. Auch Sprachversionen ein und derselben Web-»Seite« gehören zu den Anforderungen der Personalisierung.

Jede einzelne »Seite« wird damit mehrdimensional, es gibt nicht mehr die eine Darstellung. Willkommen im Multichannel-Universum. Kann Inline-Editing bei Anforderungen wie adaptivem Content oder Multichannel-Marketing funktionieren?

Strukturierter Content

Zunächst wollen wir noch den Begriff Web-»Seite« betrachten. Wenn wir seine Wortbedeutung genauer untersuchen, stellen wir fest, dieser Begriff wurde dem Print-Bereich entlehnt. Die Metapher »Seite« für die Einheit, die Contents enthält, beschreibt ein digitales Dokument als etwas Statisches. Auch die Bearbeitung von Content wird hinlänglich mit Methoden aus dem Print bedient. »Moderne« WYSIWYG-Editoren, wie wir sie eingangs beschrieben haben, kommen aus der Print-Welt. Office-Programme oder Layout-Programme arbeiten genau mit diesem User Interface. In ihrem Artikel WYSIWTF beschreibt Karen McGrain genau diesen Widerspruch aus analogen Vorstellungen und modernen Anforderungen an digitale Prozesse. Und das bereits im Jahr 2013. Provozierend läutete sie das Ende von Desktop-Publishing und WYSIWYG ein. Ihre Forderung, Content nicht als Blobs, sondern als Chunks innerhalb einer Content-Entität zu strukturieren, überzeugte seinerzeit und so mancher CMS-Hersteller suchte Wege, diese Idee in seinem System abzubilden. »Binary Large Objects«, Blob ist ein Begriff aus der Datenbankwelt, der beschreibt, dass mehr oder weniger unstrukturierte Daten in einem einzigen Datenbankfeld abgespeichert werden. Mit Chunk meint Karen McGrain hingegen voneinander abgegrenzte Content-Blöcke. Und diese Blöcke, eben Chunks, lassen sich gut mit Metadaten anreichern. Derart strukturierte Contents enthalten möglichst keine Auszeichnungen, in welchem Layout die Daten vorliegen, es findet auch keine Festlegung statt, in welcher Reihenfolge oder in welcher Spaltenanordnung Blöcke angeordnet sind, Chunks oder Blöcke werden also präsentationsunabhängig abgespeichert. Es findet in einem CMS nicht nur eine klare Trennung von Struktur und Inhalt statt (Navigation und Content), sondern auch eine klare Trennung von Chunks und Struktur innerhalb einer »Seite« (man kann an dieser Stelle über einen anderen Begriff wie Content-Entity oder Content-Container nachdenken, um das Wort »Seite« zu vermeiden, Umbraco verwendet hier den Begriff Dokument).

Welcher Editor für welchen Zweck

Vergleichen wir nun die Anforderungen an strukturierten Content mit den eingangs vorgestellten Editor-Typen. Lassen Sie uns mit NEOS beginnen. NEOS wirbt damit, dass man mit ihrem CMS Content strukturiert organisieren kann, es stellt sich aber die Frage, wozu benötige ich dann das designabhängige Inline-Editing, wenn das Rendern der Contents für beliebige Output-Channels sowieso unterschiedliche Layouts erzeugt? Das Inline-Editing fokussiert sich jeweils auf eine Output-Plattform, möglichweise die Unternehmens-Website, aber andere Views können beim Editing nicht gleichzeitig dargestellt werden. Wozu brauche ich dann das Inline-Editing? Ähnliches gilt für Wordpress. Es gibt zwar die Auffassung, dass man mit Gutenberg die Contents strukturiert ablegen kann, aber die einzelnen Blöcke werden nicht als einzelne Entities oder als Objekte, sondern zusammen in einem einzigen Blob abgespeichert.

Für rein webbasiertes Publishing eignen sich beide Editing-Möglichkeiten sehr gut, wenn man allerdings moderne Anforderungen an Enterprise-Kommunikation stellt, wird man mit Inline-Editing wie auch mit Gutenberg an die Grenzen des Machbaren stoßen.

Wenden wir uns nun nochmals Umbraco zu. Sie haben weiter oben gesehen, dass man mit Umbraco Contents im Grid bearbeiten kann. Die Daten der einzelnen Blöcke samt Zeilen- und Spaltenzuordnung werden auch hier alle in einem einzigen Datenbankfeld abgespeichert. Das scheint auf den ersten Blick auch recht blobby und wenig chunky zu sein. Es gibt aber an dieser Stelle aber einen entscheidenden Unterschied. Die Contents werden innerhalb des Datenbankfeldes in einer JSON-Struktur abgelegt, also als Javascript-Objekte.

Der Programmierer erhält diese JSON-Struktur jedoch nicht als JSON-Text, sondern sie wird im System transparent in ein C#-Objektsystem übersetzt. Einzelne Blöcke, die mit Grid-Editoren erfasst wurden, werden als einzelne Objekte gespeichert und stehen als solche in der Bearbeitung, zum Beispiel beim Rendern, zur Verfügung. Die Objekte lassen sich als strukturierte Chunks verwenden, und nach Belieben ein- und ausblenden, umstrukturieren, manipulieren. Um dieses Konzept ein wenig zu beleuchten, werden Sie im Folgenden ein Proof of Concept kennenlernen, wie sich die im Umbraco-Grid gespeicherten Daten verwenden lassen, um alle Anforderungen an strukturierten Content erfüllen zu können.

Proof of Concept

Der Sinn und Zweck ist es, Content unabhängig von seiner Struktur innerhalb eines Content-Containers abzulegen. Die Idee, die wir hier entwickeln, beruht auf einem zweistufigen Einsatz des Umbraco-Grids. Im ersten Schritt wird ein Grid angelegt und nur ein einziges Zeilenformat mit einem einspaltigen Layout konfiguriert. Nennen wir es das Grid für Content-Blöcke. In ihm werden die einzelnen Chunks gespeichert. Man kann beliebige Grid-Editoren einsetzen, Texte, Bilder, Galerien etc. Die so gespeicherten Contents enthalten keinerlei Information über Layout, Farben o.ä.

Als nächstes wird ein Umbraco-Grid für verschiedenste Channels definiert: Beispielsweise ein Grid für die Web-Ansicht, eine Ansicht für Newsletter, ein Grid für ein Produkt-Informations-System (PIM). Das sind unsere Content-Compositions. Mit diesen Grids lassen sich die im ersten Schritt erfassten Contents in eine bestimmte Struktur einbinden.

Das ist das View Model, also das sind die Daten, die gerendert werden. Konkreter: Aus den Parametern eines solchen Grids (welches Zeilenformat wird gerade verwendet, welches Spaltenformat hat eine bestimmte Spalte (Area) usw.) werden Layout-Anweisungen. Wenn Sie Twitter Bootstrap FrontEnd-seitig für das Rendern der Contents verwenden, wären das CSS-Anweisungen wie col-md-6, col-lg-4 usw.

Lassen Sie uns die einzelnen Schritte noch einmal wiederholen:

• Es wird pro Dokument eine Sammlung an Content-Blöcken geben. Das ist das Grid mit nur einem Zeilenformat mit nur einer Spalte (Area) und verschiedenen Grid-Editoren, die unsere Content-Typen repräsentieren. Indem Grideditoren in das Grid eingefügt werden, entstehen konkrete Content-Typen.
• Anschließend wird ein Grid-Editor benötigt, das einen Selektor für Content-Typen darstellt. Mit ihm kann man aus den vorhandenen Contents aus der Block-Sammlung auswählen.
• Jetzt werden ein oder mehrere Grids definiert (je nach Anzahl der Channels). In jedem dieser Grids (Content-Compositions) sind verschiedene Zeilenformate zugelassen. In den Spalten (Areas) dieser Grids kann man nur den einen Grid-Editor benutzen, der die Auswahl der Contents erlaubt.
• Jedes dieser Grids hat jetzt seinen eigenen Grid-Renderer und kann die Contents entsprechend ausliefern. Beachten Sie, dass der Renderer nicht notgedrungen Html ausliefern muss, es kann ein JSON-Format oder XML sein, hier bleiben keine Wünsche offen.

Fazit

Strukturierter Content ist die Methode, um komplexe Content-Prozesse zu verwalten. Einfaches Web-Publishing wird in Zukunft  nicht mehr für digitale Marketing-Strategien hinreichen. Dennoch müssen Redakteure eine einfache und übersichtliche Benutzer-Oberfläche zur Verfügung haben, die möglichst nicht an ein bestimmtes Layout gebunden ist. Konzepte wie WYSIWYG oder Inline-Editing sind oft nur hinderlich und vermischen Content und Struktur. Das Layout und die Formatierung muss das System im Hintergrund übernehmen. Dazu muss Content zunächst von einer konkreten Struktur und von einem konkreten Layout getrennt abgespeichert werden. Erst dann kann Content für verschiedenste Zwecke wiederverwendet werden. Und hier spielt Umbraco seine Stärken aus. Durch seine flexible Software-Architektur können komplexe digitale Prozesse hervorragend abgebildet werden. Die Entwicklung geht eindeutig weg von blobby Contents, also weg von unstrukturierten Contents. Willkommen in Chunkytown.