CMS vergleichen – oder welcher Wagen darf es sein?

In meinem Kopf: «Wir benötigen eine Übersicht – einen Vergleich – eine Bewertung.» Zu einem Thema, bei dem sogar Leute, die schon Erfahrung gesammelt haben, lieber weghören. Content Management Systeme (CMS) gilt es aber zu kennen und wir wollten unser Wissen teilen. Unerwartet, während wir eine FEINTalk-Präsentation vorbereiten wollten, tauchten spannende Fragen auf: Wie überhaupt Dinge unterscheiden? Wie kategorisieren? Und: Welche Analogie nutzen wir? Hier das Making-of unseres CMS-Vergleichs.

Im Sitzungszimmer: Für den FEINTalk vom 23. April hatten wir zuerst das Thema Content Management Systeme (CMS) ausgewählt. Um die Inhalte verständlich rüberzubringen, einigten wir uns darauf, die CMS-Landschaft zu beschreiben. Schliesslich ging es darum, dass mittels ausschlaggebender Kriterien eine Übersicht über verschiedene CMS-Kategorien geliefert wird. Eine passende Analogie würde dann das i-Tüpfchen für die Präsentation abgeben.

Für mich als beruflicher und privater Nutzer von unterschiedlichen CMS, aber Nicht-Programmierer, war klar, dass die Kosten das wichtigste Kriterium bei der Kategorisierung von verschiedenen Typen und folglich für den Vergleich sein sollten.

1 – Kriterien zum Unterscheiden

Doch das war eine eingeschränkte Sicht auf die Endnutzer. Gegenübersitzend wiesen die beiden Entwickler darauf hin, dass der Rahmen breiter gesteckt werden müsste. Grundsätzlich gehe es darum, die technischen Möglichkeiten und Einschränkungen bei der Implementation zu betrachten, nicht bei der Nutzung.

Es gebe Baukästen, sogenannte Content Management Frameworks (CMF), bei denen seien alle Funktionen denkbar, man müsse sich vorher nur entscheiden, was und wie man es genau will.

Hier kam eine weitere Unterscheidung aus Entwicklersicht ins Spiel: Wie gross ist der Anfangsaufwand, bis das CMS mit seinen Funktionen schliesslich auf der Website einsetzbar ist? Hier gibt’s einen klaren Zusammenhang: Je passgenauer Applikationen sein sollen und je häufiger man solche einsetzt, also wie stark man auf Frameworks angewiesen ist, desto höher sind die Initialaufwände.

Schliesslich das dritte Kriterium: die Möglichkeit, dass die abgelegten Website-Inhalte Bezüge zueinander haben können. Ändert man eine Information an einem Ort, werden auch verknüpfte Einheiten aktualisiert. Was mir einleuchtete: Durch diese ‹strukturierten Daten› war man schneller in der Inhaltsverwaltung und die Fehlerquote sank. Aus der Sicht der Organisation: ein Effizienzgewinn.

2 - Von Kriterien zu CMS-Kategorien

Für die Präsentation am FEINTalk schien mir das als Hintergrundwissen wichtig, aber zum Verstehen zu kompliziert. Wir brauchten Kategorien, statt nur Kriterien. Und abschliessend eine Analogie, die jede und jeder versteht.

Unsere Kriterien nochmals:

• Sollen mittels eines Baukastensystems jede Funktionalität ermöglicht werden (hohe Passgenauigkeit auf Anforderungen)? Ja oder Nein?
• Wie hoch ist der Initialaufwand bei der CMS-Installation? Tief, mittel oder hoch?
• Sind Daten-Standorte miteinander verknüpft, also umfasst die Informationsarchitektur strukturierte Daten? Ja oder Nein?

Bei der Grobaufteilung in drei Kategorien orientierten wir uns wieder an den Kosten:

Die tiefste, einfachste Kategorie (Typ A) kannte ich aus eigener Erfahrung bereits gut: Als Endnutzer klickt man sich bei einer Software, die übers Netz angeboten wird, die eigene Website im Nu zusammen. Wordpress.com oder Squarespace als bekannte Vertreter.

Am anderen Ende des Spektrums (Typ C) liegen die bauteiligen Content Management Frameworks (CMF), welche absolute Passgenauigkeit für Anforderungen und höchste Potentiale für organisatorische Effizienz bieten, aber einen hohen Initialaufwand mit sich bringen. Alles ist möglich bei Django oder Ruby on Rails.

In der Mitte (Typ B) schliesslich befinden sich die CMF-Abkömmlinge: aus den Bausätzen wurden für die gebräuchlichsten Szenarien einzelne CMS entwickelt. Diese bieten dadurch fertige Module an und können dank strukturierten Daten repetitive Inhaltsbearbeitungen erleichtern. Joomla, Drupal, Typo3 oder auch unser FeinCMS fallen unter diese Kategorie.

3 - Die Analogie

Gut, wie übersetzt man dieses Trio nun in ein verständliches Bild? Nichts grässlicher in Präsentationen, als wenn Kategorien unklar oder für den Redefluss einfach zu lang sind. MTV-Moderatoren, die früher ‹The Artist Formerly Known as Prince› ansagen mussten oder Diplomaten, die von Beziehungen mit der ‹Former Yugoslavian Republic of Macedonia› sprechen, taten mir immer leid. (Und vergessen Sie’s: TAFKAP und FYROM sind auch keine geeigneten Eigennamen).

Die Vorbereitungsrunde im Sitzungszimmer war mittlerweile schon richtig warm gelaufen. Bald kam ein Projektleiter mit der Idee: «Eigentlich ist es wie beim Autokauf. Man hat gewisse Ansprüche, was das Fahrzeug erfüllen muss. Und damit es nicht zu teuer wird, muss man Abwägungsentscheide treffen.» Der Runde gefiel die Idee.

Squarespace und Wordpress.com (Typ A) wären also Kleinwagen, Drupal und Typo3 (Typ B) Mittelklassewagen und Django (Typ C) eine Limousine. «Halt», ruft der eine Entwickler in den Raum, «Das Ding mit Django oder Ruby on Rails ist ja nicht einfach, dass sie super gemütlich sind, jeden Schnickschnack bieten und lautlos fahren. Das Beste an diesen CMF ist doch, dass man alles Mögliche daraus basteln kann.» Und schwupps, als Beweis zeigte er einen Clip, in dem ein Armeejeep in seine Einzelteile auseinandergenommen und grad wieder zusammengesetzt wird (siehe ganz unten).

So kamen wir schliesslich zum Trio Kleinwagen – Mittelklasse – Limousine / Armeejeep, um unterschiedliche CMS-Typen dem Publikum zu erklären. Dass diese Einordnung zukünftig auch in Informatik-Lehrbüchern verwendet werden wird, darauf wollte komischerweise niemand wetten.

Weiterführendes
- FEINTalk: Planung einer Webseite vom 23.4.2015 (Folien, Videoclip und Fotos)

So flexibel wie ein Content Management Framework: Ein Armeejeep