CMS hinter die Website klemmen, Nutzerzugänge verteilen, Knöpfchen drücken und los? So einfach ist es nicht. Auch dann nicht, wenn das ein oder andere CMS relativ nutzerfreundlich ist.
Yes, it is quite user-friendly, but apparently not enough for people who double-click on links when browsing or worst, enter their website’s url in Google to get there.8 ways to make WordPress easier to use for your clients
Das ist vielleicht etwas abfällig formuliert, aber es liegt auch was wahres darin. Gefordert sind auch wir Webdesigner bzw. Anbieter, die den Kunden/Anwender später auf das System loslassen. Man kann mehr tun, als die späteren Nutzer des Systems pro forma kurz zu schulen und dann zu hoffen, dass sie nichts kaputt machen.
Der oben genannte Artikel bezieht sich zwar speziell auf WordPress, kann aber in Teilen auch verallgemeinert werden. Es gibt Punkte, die man bereits bei der Konzeption der Website und dem dazugehörigen CMS oder Blogsystem berücksichtigen kann.
Welche speziellen Anforderungen bestehen, sollte bereits in den ersten Gesprächen erörtert werden. Je nachdem gibt es dann ein paar Aspekte, die zu berücksichtigen sind. Ich sehe da v.a. drei zentrale Ansatzpunkte, durch die die Usability im Backend des CMS beeinflusst wird.
- Der Editorbereich ist der wohl kritischte von allen. Er bildet den zentralen Dreh- und Angelpunkt für die Nutzer bzw. Redakteure im System. Also sollte er gut erreichbar, leicht verständlich und mit den wichtigsten Editorfunktionen versehen und eingerichtet sein.
- Seitenverwaltung. Die reine Auflistung der Seiten, wie z.B. bei WordPress, mit mehr oder weniger kryptischen Zusatzoptionen ist nicht intuitiv. Otto Normal kommt besser mit Seitenbäumen zurecht, die ähnlich funktionieren, wie ein gewohnter Dateiexplorer eines Betriebssystems. Auch die einfache Erweiterung und Anpassung der Seitennavigation. Es muss also möglich sein, neue Seiten ganz einfach hinzuzufügen oder verschieben zu können.
- Reduktion auf die wesentlichen Features. D.h. man nimmt den Nutzern das, was sie evtl. verwirren könnte. Ohne sie dabei aber in ihren Rechten all zu voreilig zu beschneiden bzw. zu bevormunden. Anforderungen an Rollen und Rechte sollten daher gemeinsam geklärt werden, um das System dann zielgerichtet entschlacken zu können.
Aber die Nutzer des CMS müssen trotzdem auch ein wenig Bereitschaft mitbringen, sich mit Technologie auseinander zu setzen. Ganz ohne geht es eben auch nicht. Ein CMS ist ein System, in dem viel Technologie steckt. Berührungspunkte mit dem Kern des Systems sind immer wieder gegeben. Es ist eben nicht ganz so trivial, wie das anlegen eines neuen Word-Dokuments.
Reynhard B. sagt:
„Reduktion auf die wesentlichen Features.“
Meiner Meinung nach ist das einer der wichtigsten Punkte in Bezug auf das CMS selbst. Viel zu viele Funktionen, welche man kaum braucht, verschleiern den Blick für das Wesentliche (z.B. Fettschrift, Headlines oder Listen).
Weniger ist mehr, und nach Absprache des Nutzers des CMS läßt es sich sogar auf das Minimum=Genutztes reduzieren.
15. Oktober 2009 — 18:06
Björn sagt:
@Reynhard B.: Das hat bei uns auch ganz gut funktioniert. Im Zweifel ergänzt man bei Bedarf später wieder etwas.
15. Oktober 2009 — 19:25
Stefan sagt:
Genau richtig. Reduktion ist das wichtigste. Ich teste seit Jahren die verschiedensten Systeme, und bin immer wieder schockiert, was ein Kunde mit einem angeblich „ach so nutzerfreundlichen“ System für Mist anstellen kann.
Ein Großteil der verfügbaren Systeme sind leider einfach ein Graus. Überladen, viel zu viele Funktionen. Von Technikern für Techniker.
Es gibt Systeme, wie auch WordPress, die schon recht vorbildlich sind, doch eigentlich immer noch zu komplex. Und als Blog-System nur bedingt für andere Seitenformen zu gebrauchen.
Ich beobachte seit ein paar Jahren die Entwicklung von Symphony CMS, aber auch ExpressionEngine hat viele sehr nützliche Ansätze.
Symphony kommt mit keinen Grundfunktionen außer Login/Logout, Usereinrichtung daher. Alles andere ist einzeln, je nach Bedarf auswählbar. Nur leider ist der Einstieg für Entwickler recht hoch, da auf XSLT als Template-Engine zurückgegriffen wird.
Meine Ansicht zu Bäumen ist sehr zwiespältig. Ich sehe immer wieder, wie man sich in der Komplexität größerer Seiten verliert. Ich denke ein Inhaltsbezogener Ansatz ist sinnvoller (also z. B. „Ich Pflege ein neues Angebot, einen neuen Kunden, eine Dienstleistung“). Die meisten Nutzer sind halt keine Informationsarchitekten, und wenn sie über ihr CMS die Inhalte da platzieren, wo sie es für gut halten, wird die Website fast immer lausig im Laufe der Zeit. Besser ist es eine logische Grundstruktur abzusprechen und auf Template-Ebene die Inhalte automatisch zu verteilen.
16. Oktober 2009 — 18:21
Björn sagt:
@Stefan: Danke für Deine ausführliche Meinung!
Die Seitebäume sind das, was die Nutzer schnell vermissen und dann auch fordern. Aber ich denke auch, dass der thematische Ansatz sehrt gut ist. Den könnte man verfolgen und ich denke die Nutzer auch davon überzeugen. Wobei bei kleineren Angeboten vielleicht doch der einfache Seitenbaum (sofern er ohne große Anpassungen lieferbar ist) der bessere Ansatz ist.
Aber am besten ist es eben, auch schon bei der Konzeption, die späteren Benutzer des Systems, nicht nur die Besucher der Website, mit einzubeziehen.
16. Oktober 2009 — 18:35
Harald sagt:
WordPress hat ein einigermaßen verständliches Admininterface, aber noch weit vom Optimum entfernt. Das finde ich vor allem dann, wenn die Eingabe von sichtbarem Content von der Eingabe von Metainformationen und Einstellungen getrennt wird, die Bearbeitung also in mehreren Schritten erfolgt.
Die Einrichtung der Seitennavigation sehe ich auch als Schwachstelle. Eine Visualisierung der Struktur muss nicht nur die Ebenen der Navigation wiedergeben, sie sollte auch deutlich zeigen, was für den Benutzer sichtbar ist. Dabei sollte auch die Implementierung berücksichtigt werden: wenn zum Beispiel ein Artikel auf der dritten Ebene abgelegt wird und diese auf der Website nicht verfügbar ist.
Seitenbäume finde ich jedoch relativ sinnfrei, wenn sie als schmale Spalte neben diversen anderen Editierfunktionen ihr Dasein fristen.
Optimal ist auch die Möglichkeit, Inhalte direkt im Seitenlayout anzulegen und zu bearbeiten (Inline Editing) oder zumindest ein abgestimmtes Stylesheet für den Visual-Modus bereit zu stellen. Nicht verfügbare CSS-Einstellungen und anderes Verhalten von Elementen im „Visual“-Modus (also „WYSIWYG“) irritieren häufig.
Inline-Editing und die Organisation von Menüs mit Drag&Drop werden die nächsten großen Aufgaben für CMS-Entwickler.
17. Oktober 2009 — 8:37