Die richtige Wahl des Content-Management-Systems (CMS) hat zwar immer noch weitreichende Folgen für das Gelingen von Webprojekten, sie hat aber nicht mehr das Maß an Einfluss auf die Umsetzung. Statt sämtliche technischen Grenzen und Richtlinien zu definieren, ist der Fokus auf den Umgang mit den redaktionellen Tools des CMS gewechselt, denn die meisten Dienste und Funktionen werden heute auf verschiedene Systeme verteilt. Auf diese Weise werden monolithische Konstruktionen vermieden und das Updaten oder Austauschen von Teilsystemen ermöglicht.

CMS im Kontext

Content-Management-Systeme stehen heute kaum mehr allein, sondern werden je nach System-Komplexität durch eine Vielzahl von Subsystemen ergänzt. So ergänzt ein externe Suchmaschine den internen Index für eine Onsite-Suche, ein Media Management System ersetzt die interne Bilddatenbank, Video oder Podcast-Hoster streamen Medieninhalte und eine Shopsoftware auf SaaS-Basis bringt Produkte ins Netz. Das CMS kümmert sich »nur noch« um die Aufarbeitung und Bereitstellung von Content.

Selbst das Frontend einer Webseite kann komplett losgelöst vom CMS entwickelt und erhalten werden, sodass entweder das eine oder das andere ausgetauscht werden kann, ohne die ganze Webseite relaunchen zu müssen (Headless Ansatz). Dieser Ansatz erlaubt es auch bspw. freien Entwicklern, das Frontend zu bearbeiten und weiter zu entwickeln, ohne das CMS kennen zu müssen.

Die Fragmentierung der Dienste erlaubt außerdem nicht nur einen leichten Austausch, sondern gibt den System in sich Luft, neue Komplexität aufzubauen. Im Falle eines Shops kann ein proprietäres System mit sehr viel mehr Tiefe aufwarten, wenn es bspw. um Bezahlmöglichkeiten, Nutzerverwaltung und Sicherheit geht, als es ein CMS tun könnte  - und dann auch nur mit erheblichem Mehraufwand.

Auswahl

Für die meisten Webprojekte können eine Vielzahl von CMS benutzt werden, die jeweils bestimmte Vor- und Nachteile aufweisen. Über die richtige Wahl entscheiden oft Details, die sich erst im Projektverlauf herausstellen. Die Wahl des CMS sollte daher nicht zu zeitig getroffen werden um zu vermeiden, dass eine der Entscheidungen nachträglich nur mit erhöhtem Aufwand rückgängig gemacht werden kann. 

Drupal

Drupal ist ein weit verbreitetes Open Source CMS mit einer breiten Entwickler:innen Community. Es ist geeignet für mittlere bis große Webprojekte und besticht durch seine komplett freie Konfigurierbarkeit, welche allerdings auch einen großen Anspruch an die Entwicklung stellt.

Eine Nutzung von Drupal zeichnet sich durch folgende Vorteile aus: 

• vollständige REST API zur Integration von Fremddiensten
• Umfassende Entwickler:innen Community und zahlreiche PlugIns verfügbar
• Mehrsprachigkeit ist Teil des Cores
• kostenloses Lizenzmodell
• externes Frontend Setup möglich
• Anbindung von MAM möglich

Potentielle Nachteile dieses CMS sind hingegen folgende: 

• als Open Source CMS sind Exploits sehr wahrscheinlich und verlangen regelmäßige Updates
• die Notwendigkeit von Konfigurationen kann die Kosten beeinträchtigen
• die Umsetzung von Custom-Code Lösungen durch PlugIns und Individualprogrammierung erhöhen die Wartungskosten
  

Magnolia

Magnolia ist ein Enterprise CMS aus der Schweiz, das international viel Beachtung gefunden hat. Unter anderem haben sie Klient:innen wie die New York Times oder BMW auf ihrer Kundenliste. Das CMS setzt auf einen hybriden Ansatz aus festem kostenpflichtigen Kern CMS, einer sehr reduzierten kostenfreien Variante, sowie einem breiten Partnerprogramm bestehend aus Entwicklungs- und Integrationspartner:innen.

Das System zeichnet sich durch folgende Eigenschaften aus: 

• sehr gutes Multi Site und Multi Language Setup
• WYSIWYG-Editor
• schlankes, aufgeräumtes Backend
• vollständige API 
• abgekapseltes Autoren-System (Probleme auf dem einen System beeinträchtigen nicht das andere = mehr Stabilität für das Live-System)
• nicht öffentlich zugänglicher Source-Code, daher weniger Exploits
• internationaler Support 
• Update-Garantie und Langlebigkeit durch robustes Unternehmen
• zahlreiche PlugIns und Erweiterungen verfügbar
• sehr gutes Preis-Leistungsverhältnis

Potentielle Nachteile dieses CMS sind hingegen folgende: 

• Es fallen jedes Jahr feste Lizenzgebühren an
• kleinere Entwickler:innen-Community
  

Kostenpflichtiges vs. kostenfreies CMS

Der Gedanke ein kostenfreies, dem kostenpflichtigem CMS vorzuziehen, ist oft naheliegend, er blendet aber die Folgeaufwände aus. Die Open Source CMS sind zunächst kostenfrei, müssen aber in viel kürzeren Abständen gewartet und geupdatet werden, auch um Sicherheitslücken zu vermeiden. Außerdem werden Erweiterungen aus der Community oft ohne Garantie der Langlebigkeit erstellt. (Nur weil Programmierer:innen heute noch ein tolles Modul haben, heißt es nicht, dass sie es morgen noch pflegen.) All das treibt die Folgekosten in die Höhe. Kostenpflichtige Systeme sind hier wartungsstabiler, weniger updatebedürftig, sicherer und der Ausfall von Kompetenzen ist weniger wahrscheinlich.

Erscheinungsbild und Qualitätssicherung 

Ein bekanntes Problem ist der Verlust von Qualität im Frontend durch eine nicht dem Konzept entsprechende Benutzung. Eine Maßnahme, diesem Verlust entgegenzuwirken, sind gut geschulte Mitarbeiter:innen und eine trennscharfe Dokumentation. Wenn jede:r Redakteur:in immer weiß, wie eine Seite befüllt werden muss, bleibt Qualität erhalten. 

Eine andere Maßnahme ist es, die entsprechenden Optionen im Backend einzuschränken, sodass Seiten nur auf eine bestimmte Art befüllt werden dürfen. Diese Regeln können dann nicht missachtet werden. 

Beide Maßnahmen haben Vor- und Nachteile:

• Sehr einschränkende Templates sichern garantiert ein einheitliches Layout, kosten Redakteur:innen aber viel Flexibilität, wenn es darum geht, neue Inhalte in ein Template zu setzen, das diese nicht kennt. Selbst kleine Anpassungen müssen dann von der Agentur gemacht werden, oder resultieren in einem sehr unübersichtlichen Template Katalog.
• Eine gute Dokumentation ist sinnvoll und kann freie Templates erlauben, ist allerdings nicht an feste Regeln gebunden. Um dennoch eine gleichbleibende Qualität zu ermöglichen, braucht es eine Schlussredaktion, die die Konsistenz der Webseite sicherstellt. 
  

Wir haben die besten Erfahrungen mit einer Mischform gemacht. Templates sollten so viel einschränken wie nötig und so viel erlauben wie möglich. Der Rest muss über eine geschulte Redaktion, ein gut kommentiertes Backend, und eine umfassende Dokumentation erreicht werden. Das genau Verhältnis muss im Projekt bestimmt werden. 

Dokumentation und Knowledge Transfer

Webseiten sind schon lange keine Projekt mehr, sondern Prozesse, die über Jahre laufen können.

In dieser Zeit kann sowohl auf Seiten der Kund:innen als auch auf Seiten des Dienstleisters viel passieren. Besonders die Abwanderung von Wissen durch den Verlust von Mitarbeiter:innen oder durch mangelnde Praxis und Erfahrung im Projekt stellt einer immerwährende Gefahr da. 

Beiden Punkten kann mit einer guten und vor allem laufenden Dokumentation für Technik als auch Redaktion begegnet werden. 

Die technische Dokumentation ist ein Teil unseres Qualitätsmanagements und stellt einerseits sicher, dass wir unseren eigenen Systeme morgen noch verstehen und andererseits, dass wir Projekte im Falle des Endes einer Zusammenarbeit auch an andere Dienstleister übergeben können. Diese Dokumentation erfolgt parallel zum Entwicklungsprozess in Form von Tickets, die sowohl die konzeptuelle Überlegung, das Design und die technische Umsetzung dokumentieren und die entsprechenden Verweise auf das Repositiory geben. 

Die redaktionelle Dokumentation ist eine separate Dienstleistung und kann von einer Schulung, über ein Handout bis hin zu einer eigenen Webseite viele Formen annehmen. 

Wir haben mit einer Kombination aus Schulungen und kleinen Tutorial-Webseiten die besten Erfahrungen gemacht. Die direkte Q&A Situation ermöglicht den tiefsten Transfer zu einem bestimmten Thema. Diese Schulungen können online stattfinden und auch nach dem Launch wiederholt werden. Eine Online-Dokumentation ergänzt die Schulungen und gibt Anleitungen zu den wichtigsten Produktionsabläufen und sichert zusätzlich das Erscheinungsbild einer Webseite. Wir entscheiden uns hierbei bewusst gegen PDFs oder Videos, da beide Formate zu hermetisch sind, um nachträglich angepasst werden zu können. Wenn sich etwas an der Webseite ändert, muss aufwändig eine neue Datei erstellt werden, was zu hohen Folgekosten und Versionskonflikten führen kann.