Über Erfolg oder Mißerfolg eines CMS-Projektes entscheidet mittelfristig auch die Frage, wie intensiv das CMS benutzt wird. Die Idee von Content Management ist letzlich, die Pflege von Inhalten nicht nur wenigen sondern vielen Mitarbeiter in einem Unternehmen zu ermöglichen. Dabei stammen die zu veröffentlichen Inhalte aus den Köpfen der unterschiedlichen Fachabteilungen.

Bei einem Webauftritt oder Intranet ohne CMS muß dabei der Inhalt von den Fachabteilungen zu einem IT-Fachman transportiert werden, der über das technische Know-How verfügt, aus dem Inhalt ein HTML-Dokument zu erstellen und dieses in den bestehenden Auftritt zu integrieren. Content management Systeme sollen die Fachabteilung selbst in die Lage versetzen, Inhalte zu pflegen und damit einerseits wesentlich schneller mit dem Inhalt online zu gehen, andererseits aber auch die IT-Abteilungen von derartigen Routineaufgaben entlasten.

Dieses Konzept geht aber nur dann auf, wenn das CMS durch Fachabteilungen auch bedienbar ist, und zwar auch dann, wenn ein Mitarbeiter nur gelegentlich mit dem CMS arbeitet. Leider sind aber die Benutzeroberflächen von CM-Systemen häufig so komplex, daß eine dauerhafte intensive Auseinandersetzung damit Voraussetzung für die Verwendung ist. Erfaßt ein Autor nur einmal pro Monat ein Dokument, so findet dabei jedesmal eine ?Wiedereinarbeitung? statt und das führt schnell zu Fustrationen und  Ängsten und letztlich zur Ablehnung des Systems.
Entscheidend für den dauerhaften Erfolg des CMS-Projektes ist deswegen die ?Usability? der Autorenoberfläche:

• wie leicht erlernbar ist das System?
• Wie leicht ist das System wieder erlernbar?
• Wie werden Poweruser unterstützt?
• Wie Effizient ist die Benutzung:
• wieviele Klicks sind notwendig um das Zieldokument auszuwählen, zu bearbeiten, freizugeben?
• Stimmt die Performance - insbesondere bei großen Datenbeständen?
• Wie reagiert das System auf Fehleingaben?
• Hat der Autor Erfolgserlebnisse?

Der Browser als CMS-Benutzeroberfläche

Fast alle CM-Systeme besitzen eine browserbasierte Benutzeroberfläche. Die Gründe liegen auf der Hand: Der Browser ist überall verfügbar, eine Clientinstallation ist nicht notwendig. Updates sind zentral administrierbar. Wenn ein Ziel des CMS-Projektes ist, möglichst viele Mitarbeiter die Möglichkeit der Inhalspflege zu geben, dann ist die Bedienung über den Browser daher in der Regel die erste Wahl. Übersehen wird dabei schnell, daß der Browser für die Erstellung ergonomischer Benutzeroberflächen denkbar ungeeignet ist. Nicht nur, daß gewohnte Bedienelemente wie Treeviews, Menüs, modale Dialoge und Drag&Drop-Funktionen fehlen, eine Bedienung über die Tastatur ist kaum möglich und bei jedem Klick muß die Seite auf dem Server neu berechnet und im Browser komplet neu aufgebaut werden. Technologisch befindet man sich dabei letzlich zurück im Terminalzeitalter. Das heißt nicht, daß eine ergonomische Benutzeroberfläche im Browser unmöglich ist. Sie ist nur sehr viel aufwendiger zu entwickeln und diese Entwicklungskosten werden so von vielen Herstellern eingespart. Was eine moderne Browseroberfläche bieten sollte, ist folgendes:

• allem voran: Inline-Editing statt Formulareingabe. Damit ist die Möglichkeit gemeint, Daten ähnlich wie in einer Textverarbeitung direkt im Browser eingeben zu können. Der Autor hat ein direktes visuelles Feedback, er weiß, was er tut, fühlt sich sicher und hat ein Erfolgserlebnis.
• Darstellung der Sitestruktur in einer Baumansicht ähnlich dem Windows Dateiexplorer. Zu beachten ist dabei, daß Teilbäume von Server nachgeladen werden, da sonst ein Performantes Arbeiten bei meheren Tausend Dokumenten nicht möglich ist (Tipp: lassen sie sich das Produkt nicht mit hundert sondern mit tausend Dokumenten vorführen)
• Kontextabhängige Aktionsbuttons: CM-Systeme müssen eine Vielzahl von Funktionen bereitstellen, die insbesondere Gelegenheitsautoren schnell überfordern. Das CMS sollte daher abhängig vom aktuellen Bearbeitungsschritt die zwei bis drei häufigsten Funktionen deutlich sichtbar anbieten.
• Trennung von Autoren-, Designer- und Administrationsoberfläche

Alternativen zur browserbasierten Benutzeroberfläche

Auch wenn im Browser ergonomische Benutzeroberflächen möglich sind, werden sie niemals so mächtig und gleichzeitig intuitiv sein können, wie Clientanwendungen, die direkt auf dem PC des Autors ablaufen und die typischen Windows-Bedienelemente zur Verfügung stellen. Derartige Clientanwendungen sind aber bei der IT-Abteilung unbeliebt, weil sie auf jedem Autoren-PC installiert und gewartet werden müssen. Aber es gibt Alternativen, die versuchen, beide Konzepte miteiander zu verbinden: serverseitige "intelligenz" und clientseitige "präsentation" ohne dabei von der Clientinstallation "abhängig" zu sein. Eine solche Plattform ist zum Beispiel das frei erhältliche Eclipse, auf z. B. das auch der Notesnachfolger IBM Lotus Workplace aufsetzt.

Eclipse selbst ist zwar ein eigenständiges Programm - daß auch auf dem Client installiert werden muß - besitzt aber keine eigene "Anwendung". Ähnlich wie ein Browser als "generisches Programm" davon lebt, HTML-Anwendungen zu präsentieren und zu steuern, lebt Eclipse davon, "Eclipse-Anwendungen" zu präsentieren. Eine Eclipseanwendung ist ein "Plug-in", daß nicht nur automatisch von einem Server installiert, sondern daß auch zeit- oder eventgesteuert oder automatisch upgedated werden kann. Insofern kann der Eclipseclient als "Browser für Anwendungen" verstanden werden und genau wie ein Webbrowser standardmäßig auf jedem Unternehmens-PC installiert sein.



Der Eclipseclient als CMS Autorenoberfläche
Die Abbildung zeigt den Prototyp des neuen Eclipseclient für das CMS WebGate Anywhere. Mit diesem Client sind CMS Autoren in der Lage, kompfortabel und mit gewohnten Bedienelementen Inhalte zu erstellen und zu verwalten. Der Datenaustausch zwischen Client und Server geschieht dabei über Webservices, so daß mit einem Client auf beliebige WebGate Anywhere Sites zugegriffen werden kann. Der Siteexplorer wird dabei dynamisch nachgeladen, so daß auch mit großen Dokumentenmengen gearbeitet werden kann. Eine Browserview zeigt das zu bearbeitende Dokument an und per "Inline-Editing" kann direkt im Dokument geschrieben werden. Sämtliche Dialoge dagegen sind "echte Dialoge" im gewohnten Loog&Feel des Betriebssystems - egal ob Windows, Mac OS oder Linux. Neue Versionen des WebGate Anywhere-Client-Plugins können beim Start von Eclipse automatisch aktualisiert werden, so daß auch IT-Abteilungen "sorgenfrei" bleiben.

Fazit:

Gute Useability im Browser ist möglich aber eher selten. Wenn vorhanden kann sie jedoch niemals so gut sein, wie in einem Eclipseclient. Unternehmen sollten daher Ihren CMS-Hersteller nach ergonomischeren Richclients fragen, da dies die Akzeptanz des CMS im Unternehmen deutlich verbessern kann.