Topics und Assemblies

„Ich glaube wirklich, dass wir uns in einem Krieg zwischen Blobs und Chunks befinden. Wir befinden uns in einem Konflikt zwischen riesigen, unstrukturierten Blobs von Content und sauberen, gut strukturierten Feldern von Content, an die Metadaten angehängt sind. Wir befinden uns in einem Krieg zwischen Blobs und Chunks. Sie alle sind im Team Chunk. Wir können die Blobs nicht gewinnen lassen.“ – Karen McGrane

Alle Content-Manager*innen saßen schockiert da. Ein Krieg? Im Content Management? Gab es Kriege nicht nur zwischen Unix-Texteditor*innen? Warum sollte jemand in der Welt der Content Management Systeme (CMS) Krieg führen? Schließlich waren Content-Manager*innen durch die Tatsache vereint, dass alle CMS-Plattformen schlecht waren. Das hatte bislang den Frieden gewahrt, auch wenn es ein unbehaglicher Frieden war.

Warum also rief Karen McGrane sie in den Krieg? Traditionelle CMS sind Nachkommen von „Desktop Publishing-Systemen“, in denen Editor*innen Seiten, in der Regel für den Druck, mit WYSIWYG-Funktionen (What You See Is What You Get) entwarfen.

Für die Druckveröffentlichung wurde das Ausgabeformat festgelegt. Vor der digitalen Ära war die Wiederverwendbarkeit keine Priorität. Die Wiederveröffentlichung desselben Contents bedeutete in der Regel auch eine Neugestaltung.

Dies ist ein Problem für digitale Plattformen. Content-Manager*innen haben das schon immer gewusst. Sie haben einfach akzeptiert, dass es ihr grausames Schicksal ist, jede einzelne Seite im Internet neu zu entwerfen.

Als jedoch neue Geräte in vielen Formen, Größen und Formfaktoren auf den Markt kamen, vervielfachte sich die Anzahl der Schriftarten, Auflösungen, Pixeltiefen und Gerätefunktionen. Es wurde schmerzlich offensichtlich, dass digitale Plattformen Content nicht auf die gleiche Weise und mit den gleichen Workflows bereitstellen konnten, die für die Druckveröffentlichung erstellt worden waren.

Als sich die Plattformen ausbreiteten, wurde WYSIWYG schnell zu WYSIWTF.

Karen McGrane fährt fort:

„Die Ära des „Desktop-Publishing“ ist vorbei. Das gleiche gilt für die Ära, in der wir die Desktop-Weboberfläche über alle anderen stellten. Die Tools, die wir zur Verwaltung unseres Content erstellen, sind Überbleibsel der Desktop-Publishing-Revolution, bei der wir versucht haben, so viel direkte Manipulation von Content wie möglich zu ermöglichen. In einer Welt, in der wir unendlich viele Möglichkeiten haben, unseren Content zu veröffentlichen, ist es an der Zeit, über Tools hinauszugehen, die auf visuellem Styling basieren, um semantische Bedeutung zu vermitteln. Wenn wir eine echte Trennung von Content und Form wollen, muss dies im CMS beginnen.“

Wir brauchen eine echte Trennung von Content und dem Kontext, in dem er erscheint. Und wir brauchen diese Trennung im CMS.

Was genau ist ein Blob? Laut Karen:

„Wir haben CMS, die es den Leuten ermöglichen, zu sagen: ‚Ich möchte, dass es genau wie Microsoft Word funktioniert.‘ Ich möchte Tabellen, Schriftarten und Bilder einbetten können, und ich möchte meinen Content so gestalten können, dass er perfekt aussieht und funktioniert, wie ich es mir vorstelle. Ich möchte ein Tool haben, das genau wie Microsoft Word funktioniert, damit ich mir vorstellen kann, wie mein Content in dem einen und einzigen Kontext, den ich im Kopf habe, aussehen und funktionieren wird, und das ist die Desktop-Website. Es gibt also Leute, die die Fähigkeit haben, diese riesigen unstrukturierten Blobs von Content mit Formatierung und Bildern, und was auch sonst noch eingebettet wird, zu erstellen.“

Ein Blob ist eine Sammlung von Daten, die von WYSIWYG-Editoren erstellt werden und es Editor*innen ermöglicht, Schriftarten, Tabellen, Bilder und alles andere dazwischen in ihren Content einzubetten.

Das Problem ist, dass dies nicht die ideale Arbeitsweise ist, aber praktisch alle bestehenden CMS-Plattformen funktionieren auf diese Weise.

Andrew, ein Nutzer von StackOverflow, versuchte, ein CMS zu finden, das adaptiven Content unterstützt, und beschreibt den Content-Workflow bei der Verwendung eines Blob-basierten CMS so:

„Mit einem traditionellen Web-Publishing-Tool würde ich wahrscheinlich eine neue Seite unter Nachrichten erstellen und dann den Nachrichtenartikel in einem leeren WYSIWYG-Texteditor eingeben und formatieren – es geht also um Seiten mit Content.“

Die Content-Plattform, von der er träumte, würde hingegen anders funktionieren:

„Ich würde dem CMS die Art des Contents mitteilen, den ich erstelle, und aufgefordert werden, ein Formular mit einzelnen Feldern auszufüllen, die auf Nachrichtenartikel zugeschnitten sind (z. B. Überschrift, Untertitel, Volltext, kurzer Ausschnitt und Bilder) – es geht um Teile des Contents.“

Der Krieg zwischen Chunks und Blobs wurde im StackOverflow-Thread sofort beendet, und zwar unter dem Vorwand, dass die Frage „nicht konstruktiv“ sei.

Contentful ist eine Content-Infrastruktur, die Anforderungen wie die von Andrew an eine Content-Plattform und mehr erfüllt. Sie ermöglicht es Ihnen, Ihren Content als einzelne Teile zu definieren, indem Sie Contenttypen verwenden, die aus Feldern und Referenzen bestehen, und diesen Content dann über eine API bereitstellen. So kann er in jedem Kontext, auf jeder Plattform und mit jedem Technologie-Stack präsentiert werden.

Es ist wichtig zu beachten, dass die API hier eine wichtige Rolle spielt, insbesondere ihre Funktionsweise. Viele CMS-Plattformen im Desktop-Publishing-Stil verfügen ebenfalls über eine API. Diese sind jedoch blobbasiert und stellen Content bereit, der über „Blobs as a Service“ bereitgestellt wird, anstatt Content direkt über die API bereitzustellen.

Wir brauchen keine APIs, die Blobs liefern. Wir brauchen APIs, die Chunks liefern.

Karen McGrane ist unser Sensei. Sie erläutert uns, warum traditionelle CMS, die aus dem Desktop-Publishing stammen und in Bezug auf Seiten funktionieren, die falsche Lösung für die digitale Bereitstellung von Content sind.

Eine Seite ist kein Content, junger Grashüpfer, eine Seite ist ein Kontext, in dem Content erscheint.

Bruce Lee hilft uns, dies auf einer tieferen Ebene zu verstehen:

„Leere deinen Geist, sei formlos, gestaltlos – wie Wasser. Wenn du Wasser in eine Tasse gießt, passt es sich an die Tasse an, wenn du Wasser in eine Flasche gießt, wird es Teil der Flasche, wenn du es in eine Teekanne gießt, wird es die Form der Teekanne annehmen. Wasser kann fließen oder es kann zerstören. Sei Wasser, mein Freund.“

Content ist wie Wasser – und die große Vielfalt an digitalen Plattformen erfordert, dass der eigentliche Content mit Blick auf Validierung und Wiederverwendbarkeit definiert und von Kontext und Struktur getrennt wird.

Dies erfordert einen Topic-zentrierten Ansatz und keinen Seiten-orientierten Ansatz.

Ann Rockley, eine führende Expertin für die Organisation und Präsentation von Informationen im Internet und Veteranin des Krieges gegen Blobs, arbeitet seit langem an ihrem Konzept des „intelligenten Contents“. Sie sagt:

„Intelligenter Content ist Content, der strukturell reich und semantisch kategorisiert ist und daher automatisch auffindbar, wiederverwendbar, rekonfigurierbar und anpassungsfähig ist.“

Ann Rockley hat einen großen Einfluss auf die Darwin Information Typing Architecture (DITA) ausgeübt, ein XML-Datenmodell für die Erstellung und Veröffentlichung von Content. XML ist ein Datenformat, das sowohl für Menschen als auch für Maschinen lesbar ist. Es funktioniert weder hier noch dort gut, und neigt wie Mückenstiche dazu, bei Entwickler*innen eine allergische Reaktion auszulösen.

Mückenstiche an sich jucken nicht, es ist die allergische Reaktion, die den Juckreiz verursacht; es scheint jedoch, dass fast jeder diese Allergie hat. Eine Theorie besagt, dass Menschen, die allergisch auf Mückenstiche reagierten und von den übertragbaren Krankheiten wussten, dazu neigten, Gebiete mit vielen Mücken zu verlassen und Maßnahmen zu ergreifen, um neue Stiche und die damit verbundenen Krankheiten zu vermeiden.

Der Grund, warum fast jeder heute diese Allergie hat, ist, dass unsere Vorfahren genau das getan haben. Jene, die nicht allergisch waren, liessen sich von den Stichen nicht so sehr stören und verließen die Gebiete nicht oder ergriffen keine Maßnahmen, um die Stiche zu vermeiden. Sie überlebten also nicht. Es muss einmal Entwickler*innen gegeben haben, die nicht allergisch gegen XML waren. Wir wissen nicht, was aus ihnen geworden ist.

DITA gibt uns jedoch eine Schlüsselwaffe in unserem Krieg gegen Blobs, das „Topic“.

Ihr Content-Modell sollte klar definierte Topics enthalten. Topics sind das, worum es in Ihrer App oder Website geht. Vielleicht haben Sie einen Bildschirm, der bevorstehende Events auflistet. Die Events wären die Topics. Vielleicht hat Ihre App eine Karussell-Komponente mit verwandten Produkten. Die Produkte wären die Topics. Vielleicht haben Sie eine Webseite, die Artikel präsentiert. Die Artikel wären die Topics.

Ihr Content-Modell sollte Contenttypen enthalten, die Ihre Topics bilden. Events, Artikel, Produkte und alles andere, was Sie haben, sollten als Contenttypen definiert, in die erforderlichen Felder unterteilt werden und Validierungen enthalten, um sicherzugehen, dass sie korrekt eingegeben werden.

Topics sollten:

• Einzeln erstellbar sein. Jedes Topic sollte zu einem Bereich gehören und eigenständig erstellt werden können.

• Immer wiederverwendbar sein. Ein einzelnes Topic sollte an mehreren Stellen und über verschiedene Kanäle hinweg angezeigt werden können. Es sollte daher nicht an bestimmten Content oder Layouts gebunden sein und überall verwendbar sein.

• Unabhängig verständlich sein. Jedes Topic sollte ausreichend vollständig sein, damit es eigenständig präsentiert werden kann.

Ein Event ist zum Beispiel die Art von Content, die Sie auf einer Webseite und auf einem Bildschirm anzeigen möchten, ganz unabhängig vom gegebenen Kontext.

Das ist das Konzept: Editor*innen sollten ihre Bemühungen nicht durch die Duplizierung von Topics vervielfachen müssen. Das von NPR geprägte Sprichwort „Einmal erstellen, überall veröffentlichen“ beschreibt diese Idee.

Anstatt eine erste Version des Events für das Web und eine kopierte Version für einen Bildschirm zu haben, sollten Editor*innen in der Lage sein, dasselbe Event überall wiederzuverwenden.

Beim Erstellen Ihrer Topics ist es wichtig, dass jedes Topic unterschiedliche und separate Contenttypen hat. Selbst wenn Topics dieselben Felder wie andere Contenttypen verwenden, haben sie oft unterschiedliche Governance-Modelle. Dies erfordert unterschiedliche Berechtigungen, Strategien für verschiedene Sprachen, funktionale Anforderungen an das Frontend und Organisationsanforderungen. Rachel Lovinger gibt das folgende Beispiel:

„Eine Pressemitteilung kann einer allgemeinen Content-Seite sehr ähnlich sein, aber nur die Pressemitteilung wird in einem automatisch aggregierten Newsroom erscheinen. Es ist einfacher, diese herauszufiltern, wenn es sich um eine einzigartige Art von Content handelt.“

Um Topics über mehrere Kanäle hinweg bereitzustellen, sollten sie frei von vordefinierten Layouts und Kontexten sein und aus Content in Form von Feldern und Referenzen bestehen.

Sie können sich Ihre Sammlung von Topics als das Domainmodell für Ihren Content vorstellen. Sobald Sie Ihre Topics haben, können Ihre Autor*innen Content erstellen.

In den meisten Fällen benötigen Editor*innen immer noch eine Möglichkeit, die Kontexte zu verwalten, in denen diese Topics erscheinen. Rachel Lovinger nennt dies das Assembly-Modell, das sie als „die Art und Weise, wie Content-Ersteller*innen einzelne Content-Elemente zu Webseiten, Kampagnen, Dokumenten oder anderen Content-Produkten zusammenstellen“ beschreibt.

Um Ihr Assembly-Modell zu erstellen, erstellen Sie zusätzlich zu Ihren Topics sogenannte Assemblies. Assemblies sind auch Contenttypen, aber im Allgemeinen mit weniger unterschiedlichen Feldern, da sie nicht beschreiben, worum es auf Ihrer Website geht, sondern wie sie zusammengesetzt ist.

• Assemblies haben Felder für Layout- und Seitennavigationsdaten, manchmal auch zusätzliche Metadaten für SEO oder Analysen, aber sie enthalten keinen Content. Assemblies verwenden Referenzfelder, um auf Topics zu verweisen.

• Assemblies können in anderen Assemblies verschachtelt sein, sodass sie auch Referenzfelder haben können, die auf andere Assemblies verweisen.

• Assemblies strukturieren Ihren Content für die Präsentation an Endnutzer*innen.

Beispiele für Assemblies sind ein Karussell, eine Reihe von vorgestellten Events, ein modulares Seitenlayout, eine einfache Seite usw.

Sie können mit der Planung Ihres Assembly-Modells beginnen, indem Sie das Design oder den Wireframe für Ihre App oder Website aufschlüsseln. Jeder Bereich der Seite und die Seite selbst ist ein Eintrag eines Assembly-Contenttyps.

Ein Seiten-Assembly kann beispielsweise einen URL-Slug, einen Google-Analytics-Code und eine Reihe von Referenzen enthalten, die es Editor*innen ermöglichen, Seitenmodule auszuwählen, einschließlich der Komponenten im Wireframe (d. h. ein Banner, ein Produktkarussell, ein vorgestelltes Video und ein vorgestellter Artikel).

Assemblies sind nicht einzeln erstellbar, aber einzeln verwaltbar. Im Gegensatz zu Topics können Assemblies nicht einzeln erstellt werden, da sie sich auf Topics und andere Assemblies beziehen. Um ein Topic zu erstellen, müssen Sie lediglich einige Felder ausfüllen. Bei Assemblies müssen Sie jedoch alle Topics erstellen, aus denen sie bestehen, und diese zu einem Assembly zusammenfassen. Das Hinzufügen neuer Topics kann gleichzeitig mit dem Hinzufügen des Assembly erfolgen. Beim Wiederverwenden von Topics wird das Assembly verwendet, um auf vorhandene Topic-Einträge zu verweisen.

Unabhängig davon, ob einzelne Content-Ersteller*innen alle Topics erstellen, die ein vollständiges Assembly bilden, sollte es für alle Content-Ersteller*innen möglich sein, alle Teile eines Assembly zu pflegen. Individuell wartbar bedeutet, dass eine einzelne Person in der Lage ist, alle Komponenten eines Assembly zu verwalten.

Assemblies sind manchmal wiederverwendbar. Während Topics immer wiederverwendbar sind (z. B. kann ein Event in vielen verschiedenen Kontexten auftreten), ist dies bei Assemblies nicht immer der Fall. Assemblies strukturieren, wie Topics präsentiert werden, und sie verbinden Topics mit den Kontexten, in denen diese Topics erscheinen. Einige Assemblies können an den Kontext gebunden sein und sind dementsprechend nicht wiederverwendbar.

Ein Ereigniskarussell ist beispielsweise tatsächlich wiederverwendbar: Vielleicht ist es eine gute Idee, dass dasselbe Karussell sowohl auf einer App als auch auf einer Webseite angezeigt wird. Andererseits kann ein modulares Seitenlayout für Webseiten nützlich sein, aber nicht für einen Bildschirm. Vielleicht werden die gleichen Topics unterschiedlich präsentiert, wenn sie separat auf einem Bildschirm anstatt zusammen auf einer Webseite angezeigt werden. Ein modulares Seitenlayout würde dann für letztere großartig funktionieren, aber nicht für die erste Option.

Während Topics unabhängig voneinander verständlich sind, sodass es ausreicht, sich ein Topic selbst anzusehen, um zu wissen, um was es geht, sind Assemblies unabhängig voneinander unverständlich. Das bedeutet, dass ein Assembly ohne die Topics, auf die es sich bezieht, bedeutungslos ist, da es ein Mittel zum Zusammenstellen von Topics für die Anzeige ist.

Mit Assemblies können Sie Validierungen erstellen, die sicherstellen, dass gültiger und vollständiger Content zusammengestellt und den Nutzer*innen präsentiert wird.

In einem strengen Assembly sind beispielsweise alle Felder für einen einzelnen Wert oder eine einzelne Referenz zulässig (d. h. wenn Sie ein Seiten-Assembly mit drei Blöcken haben). Der Assembly-Contenttyp könnte drei Felder haben: „Hero-Banner“, „Produktkarussell“ und „Sonderangebote“. Jedes dieser Felder würde validiert, um nur den entsprechenden Contenttyp zuzulassen, sodass Editor*innen die Seitenmodule auswählen können, die in die Seite aufgenommen werden sollen, sie aber nicht positionieren können.

Die Änderung der Position dieser Module ist weniger einfach. Um beispielsweise das Produktkarussell nach unten und die Sonderangebote in die Mitte zu verschieben, wäre eine Codeänderung und eine erneute Bereitstellung der Software erforderlich.

Eine Alternative ist die Verwendung eines flexiblen Assembly, bei der anstelle von einzelnen Referenzfeldern, die nur für einen bestimmten Contenttyp validiert sind, ein Mehrfachreferenzfeld verwendet wird, das für alle drei Contenttypen validiert ist.

Mit flexiblen Assemblies können Editor*innen alle gültigen Contenttypen auswählen und sortieren. So können sie Content ohne Eingreifen von Entwickler*innen selbst organisieren und vermarkten.

Fixe Assemblies sind ideal für entwicklerorientierte Teams, die das Layout ausschließlich im Code steuern möchten und es stark redaktionell ausgerichteten Teams ermöglichen, ihren Editor*innen Flexibilität zu geben.

Sie können sich Ihre Sammlung von Assemblies als Brücke zwischen Ihrem Domainmodell, wie es in Ihren Topics zum Ausdruck kommt, und Ihrem Anzeigemodell vorstellen, das letztendlich von Ihren Front-End-Vorlagen und -Komponenten gerendert wird.

Die Eigenschaften Ihrer Komponenten und die Platzhalter in Ihren Vorlagen stimmen mit den Feldern Ihrer Contenttypen überein.

Topics und Assemblies sind Ihre Waffen im Krieg der Chunks gegen Blobs. Indem wir die Dinge, um die es auf Ihrer Website oder in Ihrer App geht, in klare, wiederverwendbare, validierbare Topics unterteilen und verschachtelte Assemblies verwenden, um Topics für die Anzeige über verschiedene Kanäle hinweg zu erstellen, können wir diesen Krieg für das Team Chunk gewinnen. Contentful ist auf Ihrer Seite und wir sind hier, um Ihnen zu helfen.

Von Dmytri Kleiner und Stephen Pastan