Aspekte bei Wahl und Einrichtung von Content-Management-Systemen
5. Dezember 2013
Ein sperriger Titel, ein Dauerbrenner-Thema: Seit etwa zehn Jahren laufen beinahe alle Websites, die von Webdesign-Profis und Amateuren erstellt werden, auf Basis eines webbasierten Content-Management-Systems (CMS). Ich mag heute nicht zwingend bestimmte Systeme anpreisen oder verurteilen. Das habe ich vor einigen Jahren schon einmal getan, und werde es sicher in naher Zukunft wieder tun. Heute geht es mir um die Praxiserfahrungen und die Lehren, die ich aus acht Jahren aktiver CMS-Betreuung mit unterschiedlichsten Kunden sowie unterschiedlichsten CMSen gesammelt habe. Genauer gesagt eine Reihe unsortierter Aspekte, die ich hervorheben möchte. Und los:
Der Mythos vom eifrigen Kunden
Dass alle Kunden alle ihre Inhalte selber pflegen wollen, bedarf keiner Frage. Bis auf wenige Ausnahmen ist es das erklärte Ziel in allen Briefing-Gesprächen, die Dinge selber in die Hand nehmen zu wollen. Unsere Aufgabe als Webdesigner ist es, diese Absichten richtig einzuordnen. 80 bis 90 Prozent der Projekte, die ich in den letzten Jahren begleitet habe, werden de facto sehr wenig bis überhaupt nicht gepflegt, und das völlig unabhängig davon, wie aufwändig wir das Backend für den Kunden individualisiert und hübsch hergerichtet haben.
Die wenigen tatsächlich eifrigen Kunden melden sich zuverlässig und freundlich, wenn etwas nicht so klappt, wie sie es wollen. Und es herscht auch erstaunlich wenig Groll, wenn man dann erklärt, dass das eben nicht so geht. Die wenigsten Kunden haben die technischen Möglichkeiten und Paradigmen von einem halben Dutzend unterschiedlichen CMSen im Kopf und können sich fundiert beschweren, dass die artikelbasiert verknüpfbare, aber grundsätzlich globale Bildverwaltung von WordPress aber flexibler sei als die rein artikelbasierte Bildverwaltung von ProcessWire.
Was CMS-Schulungen angeht, so haben wir uns seit kurzem auf Anregung von Nils vorgenommen, nach Möglichkeit keine telefonischen oder vor-Ort-Schulungen mehr durchzuführen. Hier sind es nämlich gefühlte 93 Prozent der Teilnehmer, die sich das System nach der Schulung mindestens ein Vierteljahr nicht mehr angucken, und dann selbstredend alles wieder vergessen haben. Statt dessen: kleine Schulungsvideos per Screencast aufnehmen und per privatem YouTube-Link an den Kunden schicken. Dauert nur unwesentlich länger als die direkte Live-Schulung und kann jederzeit wieder angeguckt und nachvollzogen werden. Wir testen das in den nächsten Monaten und werden berichten, wie es damit läuft.
Anwender- oder entwicklerfreundlich?
Kann man beides haben? Es hängt davon ab. Manche Systeme sind von Haus aus ziemlich benutzerfreundlich, wenn es um Standardsituationen geht, kränkeln aber sehr schnell, sobald Spezialfälle auftreten. Andere Systeme müssen erst sehr mühsam benutzerfreundlich gemacht werden, können dafür aber extrem flexibel sein. Systeme mit schneller Entwicklungsgeschwindigkeit und flexiblen Möglichkeiten sind bisweilen Gift für nicht-technische Anwender. Und so weiter und so weiter.
Es gilt, mit ganz viel Menschenkenntnis herauszufinden, ob der Kunde tatsächlich zu den erlauchten 10 Prozent gehört, die tatsächlich mit ihrer Website arbeiten, und zwar mehrmals monatlich, ggf. sogar wöchtentlich oder gar – man mag es nicht zu hoffen wagen – täglich! Falls ja, kann man getrost ein größeres Budget einplanen und eventuell die CMS-Wahl noch einmal überdenken, denn nun müssen die ganzen fancy Speziallayoutmodule auch noch pflegbar gemacht werden!
Wer als Webdesigner gerne sein Ding macht und genug Selbstbewusstsein besitzt, kann aber auch immer das entwicklerfreundliche CMS nehmen, mit dem er selber am besten zurechtkommt, pfeilschnell und flexibel Seiten bauen kann. Das führt zu günstigen Preisen. Wenn der Kunde dann wider Erwarten doch dieses und jenes zweimal im Jahr geändert haben möchte, ist es eine Überlegung wert, ihm das als Service innerhalb einer kleinen Rahmenvereinbarung anzubieten. Oder die Pflegbarkeit on demand nachzurüsten. Tipp: Die zweite Lösung ist meist teurer und weniger zufriedenstellend.
Machen wir uns nichts vor: bestimmte Layout-Konstrukte sind einfach nicht dafür gemacht, vom Kunden gepflegt zu werden. Und entgegen der Beteuerungen wird das auch selten nötig sein. Mein Appell: mehr Mut zu »Geht erstmal nicht. Rufen Sie an, wenn Sie es tatsächlich ändern wollen!« Der Anruf wird vorerst nicht kommen. Und wenn doch, fällt einem sicher eine gemeinsame Lösung ein.
WYSIWYG wird besser
Manche mögen es nicht glauben, aber inzwischen ist es denkbar, den Kunden ihren geliebten TinyMCE zu geben. Schmeißt alles raus, begrenzt die erlaubten Elemente und Klassen, stutzt das Ding bis zur Unkenntlichkeit, aber sorgt in Gottes Namen für ein eigenes Stylesheet, dass dem CSS des Frontends einigermaßen entspricht. Eigene Klassen sind möglich, auch div-Bereiche lassen sich realisieren und beschriften. Gute CMSe kapern auch die Bildfunktion und integrieren die eigenen serverseite Bilderskalierung. Da geht einiges. Vor allem für kleinere Webprojekte.
Markdown und Shortcodes können auch rocken
Vor allem wenn man selber (oder der fleißige Praktikant) größere Mengen an Inhalten umpflegen muss, ist trotz aller WYSIWYG-Euphorie so eine schöne Plaintext-Welt die robustere und schnellere. Und bei tatsächlich großen Webprojekten, die von mehreren Redakteuren über Jahre hinweg kontinuierlich und einheitlich gepflegt werden, würde ich stets versuchen, die Professionalität, Verlässlichkeit und Unbestechlichkeit von Markdown in Kombination mit diversen eigenen Shortcode-Erweiterungen einzubringen. Natürlich muss man anfangs etwas Überredungskunst anwenden, da immerhin eine neue Syntax gelernt werden muss mit individuellen Spezialbefehlen. Aber bei Projekten wie Renovabis und Catan hat sich das (im Rahmen von Drupal) durchaus bewährt.
Rockstar oder Underdog?
Ganz klar: Mit bekannten Namen hat man es immer leichter. Fast jeder Kunde hat irgendwann einmal etwas von WordPress, Typo3 oder Joomla gehört. Völlig klar, dass dann eine Webdesignerin erst einmal in einer Defensivsituation ist, wenn sie ihr (für den vorliegenden Fall) klar überlegenes ProcessWire oder ExpressionEngine verargumentieren muss. Oftmals ist man ja auch dankbar, wenn der Kunde bereits einen CMS-Wunsch äußert, selbt wenn er nicht fundiert ist. Dann hat man später wenigstens nicht den Schwarzen Peter in der Hand, wenn es nur so mittelrund läuft mit dem Projekt.
Dennoch sollten wir hartnäckig bleiben. Falls wir der Meinung sind, dass für den gegebenen Fall die Vorteile eines »alternativen« CMS eindeutig erkennbar sind, sollten wir versuchen, es durchzudrücken! Und ganz ehrlich: So obskur kann ein CMS nicht sein, dass sich nicht mindestens ein halbes Dutzend fähiger Webdesigner in Deutschland finden lassen, die im Notfall das Projekt übernehmen könnten.
Vom agentureigenen CMS im Rahmen einer proprietäre Gesamtdienstleistung inklusive Hosting und monatlicher Strafmiete halte ich übrigens nicht viel. Ein Unternehmen sollte stets die Hoheit über seine eigene Website haben.
Der Mythos der schnellen, billigen Theme-Anpassung
Auch ich bin der Versuchung mehrfach erlegen, für ein kleines Budget einem sympatischen Kunden ein vorhandenes WordPress-Theme anzupassen und somit massig Zeit zu sparen. Es ist dann immer anders gekommen als geplant. Entweder der Quellcode des Themes ist einfach nur Schrott oder entspricht so gar nicht dem eigenen Stil. Das ist nicht gut für den Blutdruck. Oder der Kunde installiert sich eigenmächtig Plugins und wundert sich, dass die nicht automatisch zum Stil der Seite aussehen – immerhin ist es doch ein fertiges Theme! Oder geringfügige Anpassungen am Theme lassen die responsiven Layoutkonstrukte komplett durcheinanderpurzeln, weil man diese zunächst nicht bedacht hatte.
Am Ende wäre es fast immer genauso viel oder sogar weniger Arbeit gewesen, selber ein individuelles Theme aufsetzen, maximal mit einem neutralen Sandbox- oder Starter-Theme als Hilfestellung. Weil einfach jeder Extrawunsch sehr viel länger dauert als im eigenen Theme. Und Extrawünsche kommen garantiert – wenn nicht vom Kunden, dann von euch selber! Ein bisschen Stolz steckt nämlich in jedem von uns. Wer kennt das nicht? »Uh, so kann man das nicht lassen! Nur noch schnell diesen Abstand, dann hier noch das Fett rausnehmen, und hier … Moment, wie hat der denn die Navigation gelöst? Pfui Spinne! Das muss ich noch schnell ordentlich machen…« Und schon sind drei Stunden rum, bei responsiven Layouts auch gerne ein ganzer Tag!
Und sonst so?
Es gibt noch viele weitere Aspekte bei der praxisnahen CMS-Zähmung. Das soll jedoch erstmal genügen. Über eure Erfahrungen in den Kommentaren freue ich mich natürlich!