Blick hinter die Kulissen – Content-Elemente: Reduce them to the Max
Update zu dieser Blogserie
Im ersten Teil haben wir in Aussicht gestellt, dass wir fortlaufend über den Projektfortschritt berichten wollen. Das mit dem „fortlaufend“ ist so eine Sache – Wunsch und Wirklichkeit sind bekanntlich zwei Dinge. So hat es etwas gedauert, bis wir uns hier zurückmelden ¯\_(ツ)_/¯.
Da wir das Projekt in der Zwischenzeit weit vorangetrieben haben, ergibt sich die Möglichkeit einer Neuausrichtung von einem chronologischen Logbuch hin zu einem themenzentrierten Logbuch.
Heute auf dem Programm: Content-Elemente.
Content-Elemente - Reduce them to the Max
Das Herz eines Content Management Systems sind die zur Verfügung stehenden Content-Elemente. Dabei spielen für jedes Projekt zwei Fragen die entscheidende Rolle:
- Welche Content-Elemente werden wirklich benötigt um den geplanten Inhalt der Website strukturiert abzubilden?
- Wie können diese Elemente im Backend so implementiert werden, dass sie von der Redaktion des Systems einfach und (nur) im vorgesehenen Sinne verwendet werden?
Bei der Beantwortung dieser Fragen ist unser Credo: „Weniger ist mehr“. Als Gegen- und Negativbeispiel seien hier Website-Baukästen wie Jimdo oder Wix, sowie „Allround “-Themes für z.B. WordPress genannt. Diese Systeme kommen mit einem bunten Blumenstrauß unzähliger Content-Elemente mit wiederum unzähligen Konfigurationsmöglichkeiten daher. Im ersten Moment klingt das vielversprechend, in der Praxis stellt dies jedoch unlösbare Anforderungen an die Redaktion und bringt somit – insbesondere bei langer Lebenszeit eines Systems – enorme Probleme mit sich.
Wenn die Option besteht, jede Einzelseite, jeden Newsartikel und jede Meldung komplett unterschiedlich zu „gestalten“, dann wird diese Option früher oder später genutzt werden. Dies mag dem individuellen gestalterischen Empfinden eines Redakteurs entsprechen, der Anforderung für die Zielgruppe, Informationen übersichtlich und strukturiert anzubieten, ist dies aber selten dienlich.
Wenig dienlich ist dies auch der Einhaltung von CI-Design-Vorgaben. Ein solches „Layout“ fliegt einem ratzfatz um die Ohren – spätestens für die Ansicht auf dem Smartphone.
Des Weiteren verkompliziert sich die redaktionelle Pflege durch die Überladung mit Optionen und wird so zu einem echten Zeitfresser und damit Kostenfaktor.
Ein weiterer Aspekt ist, dass man schnell die Optionen für die zukünftige Weiterentwicklung des Projekts verbaut; z.B. in Hinblick auf Ausspielung der Inhalte über andere Kanäle (API-Anbindungen, RSS) sowie in fernerer Zukunft in Hinblick auf einen Systemwechsel mit Content-Migration.
Gerade bei einem inhaltlich umfangreichen und inhaltsgetriebenen Projekt wie der ISB-Website sehen wir es deshalb als eine unserer zentralen Aufgaben, sicherzustellen, dass der Inhalt durch die Redaktion einfach und komfortabel gepflegt werden kann und dass dieser für den Website-User nachvollziehbar, schnell erfassbar und strukturiert dargestellt wird. Und vor allem, dass diese Qualität der Inhaltsdarstellung durch das System, das wir aufbauen, dauerhaft gestützt und gesichert wird.
Redaktionelle Inhaltselemente
Um diese Ziele zu erreichen, sind wir mit einem Minimal-Vorschlag an Content-Elementen im zweiten Sprint auf unsere Partner beim ISB zugekommen und haben die Anforderungen an die Content-Elemente fortlaufend in den weiteren Sprints aktualisiert. Inzwischen resultiert hieraus ein gewachsener, aber kompakter Satz von knapp zehn Content-Elementen zum inhaltlichen Aufbau von Einzelseiten:
- Section-Header
- Text
- Text mit Bild
- Infobox
- Bild / Bildkarussell
- Video und Audio
- Akkordeon
- Download (in zwei Layout-Optionen)
- Tabelle
Ein Teil dieser Content-Elemente hat keinen fest definierten Einsatzzweck und ist frei verwendbar (z.B. Text oder Bild-Element). Andere Elemente hingegen sind für einen klar definierten Zweck konzipiert und nur hierfür einzusetzen. So dient das Element „Section Header“ oberflächlich betrachtet dazu, eine Headline zu generieren. Im Detail betrachtet ist hiermit jedoch auch eine Funktion verbunden: Die jeweilige Seite wird mit diesem Element in mehrere, inhaltlich eigenständige Bereiche aufgeteilt. Für den regulären Website-User erzielen wir dies durch die dedizierte, optische Gestaltung der Headline. Für Suchmaschinen und im Sinne der Barrierefreiheit wird dies zusätzlich durch saubere semantische Auszeichnung des Quellcodes erreicht. Den korrekten Einsatz des Elements – und somit die Qualitätssicherung der Inhaltsstruktur – sichern wir durch klar definierte Regeln, die wir im CMS verankert haben. In diesem Fall ist das System so konfiguriert, dass der Section-Header nur an geeigneten Positionen eingesetzt werden kann. Dieser Headline-Typ lässt sich also nicht innerhalb von Fließtext oder gar innerhalb anderer Content-Elemente einsetzen.
An diesem Beispiel wird deutlich, wie entscheidend eine saubere Vorplanung und später der korrekte Einsatz von Content-Elementen ist und wie maßgeblich dies eine Auswirkung für den langfristigen Erfolg eines Projekts hat.
Spaltensatz - nope!
Grundsätzlich sind die o.g. Elemente beim Aufbau der Seiten beliebig kombinier- bzw. stapelbar. D.h. die Elemente sind übereinander und untereinander anlegbar – jedoch nicht nebeneinander in Spalten. Nach genauer Abstimmung mit dem ISB verzichten wir bewusst auf solche Spalten-Elemente (z.B. Extensions wie „Container“ oder „Grid-Elements“). Der Grund ist einfach: Durch die Einführung von frei belegbaren Spalten würden neue Freiheitsgrade und zusätzliche Komplexität entstehen. Redaktionell ist dies kaum beherrschbar und für den Enduser resultiert daraus keinerlei Mehrwert. Die Redaktion kann so zwar virtuose Layouts erstellen, dies jedoch zum Preis mangelnder Semantik, unklarer Bezüge in unterschiedlichen responsive-Viewports und zusätzlichem redaktionellen Aufwand.
Es ist wertvoll, sich immer wieder in Erinnerung zu rufen, dass wir von CMS sprechen: von Content-Management-Systemen. Nicht von Indesign, Quarkxpress oder gar Photoshop. Kurz: Ein CMS ist kein Layoutsystem! Dass dies nach weit über 10 Jahren responsiver Websites noch nicht in jeden Winkel vorgedrungen ist, erstaunt immer wieder.
Anstelle von redaktionellen (!) Spalten-Systemen setzen wir auf ein stringentes Konzept zur inhaltlichen Aufteilung der Seite in einen Inhaltsbereich und einen Sidebar-Bereich. Letzterer ist für bestimmte Funktionen reserviert und kann redaktionell nicht beliebig mit Inhaltsmodulen belegt werden. So wird sichergestellt, dass der User an den gleichen Positionen die erwarteten Inhaltstypen vorfindet.
Daneben haben wir ein einziges Element, das im Tablet- und Desktop-State in sich zweispaltig konzipiert ist: „Text mit Bild“. Dieses Element stellt ein Bild (links bzw. im Mobile-Viewport oben) mit optionalem Copyright und optionaler Bildunterschrift sowie einem zugehörigen, ggf. auch längeren Fließtext (rechts bzw. unten) dar. Es dient insbesondere der Darstellung von Publikationen und hochformatigen Bildern mit inhaltlichem Bezug. Durch die feste Struktur des Elements wird garantiert, dass der Bezug zwischen Bild und Text auf allen Geräten gegeben ist und Bilder nicht lediglich als dekoratives Schmuckwerk eingefügt werden.
Funktionale Inhaltselemente
Neben den o.g. redaktionellen Content-Elementen zum Seitenaufbau haben wir Module implementiert, die bestimmte Funktionen erfüllen und je nach redaktioneller Konfiguration z.B. die Inhalte für Listen oder Teaser automatisch generieren. Diese Elemente sind vor allem für den Aufbau von Index- und Übersichtsseiten interessant; mit ihnen reduziert sich redaktionelles Eingreifen für diese Seitentypen in der Zukunft auf ein Minimum, da redaktionelle Tätigkeiten automatisiert werden. Hier entfaltet sich das zu oft ungenutzte Potential strukturierter Daten und die Stärke eines gut konzipierten CMS. Auf die Konzepte und unsere Lösungen hierzu gehen wir in späteren Blog-Beiträgen ein.
Backend-Optimierungen
Wie in der Projektvorstellung bereits erwähnt: in diesem Projekt rechnen wir mit einer Fluktuation der Redakteure über die Zeit und möchten das Backend so selbsterklärend wie möglich gestalten. Neben den bereits aufgeführten Prinzipien zur Qualitätssicherung, die immanenter Bestandteil des Gesamtkonzepts sowie des Detailkonzepts einzelner Inhaltselemente sind, legen wir ein besonderes Augenmerk auf die Backendoptimierung. Für uns ist dies eigentlich selbstverständlich, nicht selten haben wir es aber anders gesehen. Konkret bedeutet dies, dass wir in den einzelnen Inhaltselementen keine ausufernden Freiheitsgrade bereitstellen, sondern nur die Optionen zur Verfügung stellen, die von den Redakteuren sinnvoll genutzt werden sollen und die tatsächlich eine Auswirkung haben. Darüber hinaus ergänzen wir Felder im Backend mit erklärenden Kurzbeschreibungen, die gerade für neue Redakteure eine große Hilfestellung sind. Insgesamt spart dies am Ende den Redakteuren viel Zeit und garantiert einen flüssigen Workflow im produktiven Einsatz.
Style-Guide und Dokumentation - Do's and Dont's
Zur Wahrheit gehört leider auch, dass sich nicht jede mögliche Fehlnutzung vermeiden lässt. Als Hilfestellung haben wir einen Style-Guide direkt im System aufgebaut, der erklärt, wofür welches Content-Element genutzt werden soll (und wofür nicht) und der die verschiedenen Ausprägungen des Elements zeigt.
Als angenehmen Nebeneffekt bekommen wir so Seiten, die vom TYPO3-System gerendert werden und die wir als Basis für unsere Visual-Regression-Tests nutzen können. Da diese Seiten auch später für die Redakteure zur Orientierung im System bleiben, können wir auf eine eigene Test-Datenbank verzichten.
TL;DR
- Anzahl der Inhaltselemente reduzieren
- Definition spezifischer Einsatzzwecke für Inhaltselemente
- Verzicht auf Spaltensatz und dadurch effektive Reduktion der Komplexität sowie Sicherstellung inhaltlicher Bezüge und Semantik
- Optimierung Backend-Optionen für die Redaktion
- Dokumentation für die Redaktion im System
Oder: Mache die Dinge so einfach wie möglich; aber nicht einfacher.