praegnanz.de büro für intervernetzte medien

Gerrit, 05.12.2013

Aspekte bei Wahl und Einrichtung von Content-Management-Systemen

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!

11 Kommentare

  1. Gerrit am 5. Dezember 2013 #

    Bitte in diesem Kommentarthread keine CMS-Empfehlungen á la »Hast du dir mal $supersystem angeguckt? Damit kannst du $tolleDinge machen, während du $andereDinge machst.

  2. Susanna Künzl am 6. Dezember 2013 #

    Super Artikel, der meine Erfahrungen voll und ganz widerspiegelt! Auch wir haben schon bittere Erfahrungen mit dem eben mal schnell individualisierten Fertig-Template gemacht.
    Der Prozess der Auswahl des geeigneten CMS baut mE auf zwei Entscheidungen auf: Welches CMS hat möglichst viele Features, die mein Kunde jetzt (und möglichst auch in Schritt 2) braucht, schon an Bord? Das hält die Zahl der zusätzlichen Module/Extensions/Plugins gering und die Wartbarkeit hoch. Für TYPO3 gilt: Lieber ein paar Zeilen Typoscript schreiben, als eine Extension einbauen.
    Die andere Seite der Medaille sind die Erwartungen des Kunden an die Arbeit mit dem Backend. Wobei ich auch schon Kunden erlebt habe, die sich ein CMS explizit gewünscht haben, weil sie schon mal damit gearbeitet hatten, aber dann ihre Erfahrungen überschätzt haben. Wahrscheinlich, weil sie doch nicht einmal die Woche etwas an ihrer alten Website getan hatten.
    Ich denke mal, dass genaues Zuhören und eine umfassende Beratung die unverzichtbare Voraussetzung für das Gelingen eines CMS-Projektes sind.

  3. Peter am 6. Dezember 2013 #

    Schöner Artikel, der eigener Erfahrung entspricht.

    Für kleine Projekte:
    In Sachen nachhaltiger Qualitätssicherung hat es sich bei mir bewährt, dem Kunden nur einen Teil des Projektes in eigene Hände zu geben. Inhalte, die nur über einen sehr langen Zeitraum mal angepasst werden müssen, behalte ich in meiner Hand und ändere meist gleich online auf dem Server.

    Der Kunde bekommt zudem auch nur die Möglichkeit, Inhalte einzupflegen, aber nicht am Layout/Design oder an der Navigation herumzufummeln.

    Neben markdown kann auch der HTML Purifier gute Dienste leisten. Dazu ein paar projektbezogene Anpassungen. So bleibt ein Projekt standardkonform.

    Ich denke, dort wo es sich anbietet, muss es nicht immer das große ausgewachsene CMS sein. Was beim Einsatz eines CMS herauskommt, welches weder Dienstleister noch Kunde beherrschen, sehe ich aktuell am Relaunch der Gemeindeseiten. Grauenhaft …

  4. Matthias Grimm am 6. Dezember 2013 #

    Hallo Gerrit,

    ich kann Dir in allen Punkten nur zustimmen und die Idee mit den Screencasts ist super, aber ich kann meine eigene Stimme nicht ertragen, wenn ich sie aufgenommen höre ;-)

    Viele Grüße
    Matthias

  5. Christoph am 13. Dezember 2013 #

    Mit Screencasts habe ich auch gute Erfahrungen gemacht. Ich stelle diese auf einer eigenen Google Site für den Kunden bereit, das macht nochmal Eindruck.

  6. Nils Pooker am 13. Dezember 2013 #

    Ein sehr guter, fundierter und grandios aufrichtiger Artikel, Gerrit. Die Ernüchterung bezüglich der Diskrepanz zwischen dem Kundenwunsch, unabhängig zu sein und der Realität, dann doch alles den Webdesigner machen zu lassen, kann ich vollumfänglich bestätigen.

    Es ist andererseits auch in Ordnung, wenn Kunden zumindest theoretisch die Unabhängigkeit vom Webdesigner erhalten und für uns Dienstleister ist es das ebenso: auf ein »Ich habe Sie nicht für eine wichtige Meldung erreicht« kann man guten Gewissens entgegen: »Warum haben Sie es dann nicht selbst versucht?«

    Danke für den Hinweis auf meine Wenigkeit. Es waren neben der Entfernung zu vielen Kunden genau die von dir beschriebenen Probleme der Aufnahmefähigkeit in Verbindung mit den Tücken des Kurzzeitgedächtnisses und ständigen Störungen durch Tagesgeschäft und Telefonate, die mich in die Screencasts getrieben haben…

    Der eigene Youtube-Kanal ist natürlich eine grandiose Idee, danke für den Tipp!

    Nils

  7. Chio am 3. Januar 2014 #

    Ja, genauso ist es! Speziell: »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.«

    Alle 5 Monate möchte Kunde W ein neues PDF auf die Seite stellen. Natürlich mit Vorschaubildchen.
    Wäre natürlich kein Problem… aber: Ich brauch 3 Minuten, um das Ding einzustellen und 20 Minuten, um ihm das zu erklären, wie das geht. Also mach ich, und wenn mal wieder mehr zu tun ist, verrechne ich eine gefühlte halbe Stunde mehr.

  8. Anatol Broder am 9. Januar 2014 #

    Wie Gerrit bemerkt hat, pflegt der gemeine Kunde seine Webseite nie. Deshalb würde ich immer das System wählen, womit ich als Entwickler am besten zurechtkomme.

  9. Robert Daschke am 10. Januar 2014 #

    Hallo,

    Ich selber benutze screencasts und die Yourube Idee ist gar nicht mal so schlecht. Auch wenn ich manchmal meine stimme nicht hören mag finde ich, dass es einen unglaublichen Eindruck hinterlässt. Wer also auf Professionalität achtet, sollte auf dieses nicht verzichten.

    Grüße

  10. jan am 13. Februar 2014 #

    ein sehr schöner artikel, den ich nach den letzten jahren und erfahrungen nur unterstreichen kann. für dieses jahr habe ich mir vorgenommen, nerven und kundenbeziehungen nicht mehr mit cms-projekten (und den daran hängenden updates und wartungsaufgaben) unnötig zu strapazieren.

  11. Patek Philippe am 7. Juni 2014 #

    Your article shows you have a lot of background in this topic. Can you direct me to other articles about this? I will recommend this article to my friends as well. Thanks

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.