Stellen Sie sich folgende Frage: Was geschieht, wenn sich die Zahl der Inhaltselemente, die von Ihrem CMS verwaltet werden, verzehnfacht? Oder verhundertfacht? Die wenigsten Käufer eines CMS stellen sich diese Frage. Die meisten Systeme produzieren wunderbare Ergebnisse, wenn die Zahl der Elemente überschaubar bleibt, aber sie gehen in die Knie, wenn die Zahl eine gewisse Grenze überschreitet. Dieses Problem ist besonders für Content-Management-Systeme virulent, da die Systeme in den meisten Fällen Browser-basiert arbeiten. Ein gewaltiger Vorteil, da die Installation einer zusätzlichen Software entfällt. Ein gewaltiger Nachteil, da wir uns nun mit den Problemen einer Netzumgebung zu beschäftigen haben. Browser verfügen nicht über ausgefeilte UI-Elemente und müssen dennoch - unter Berücksichtigung der Bandbreite - akzeptable Interaktionsmöglichkeiten bieten. Die größte Herausforderung für die Hersteller wird künftig darin liegen, klar strukturierte und intuitive Interfaces zu realisieren, die selbst große Datenmengen navigierbar halten. Diese Aussage steht in einem gewissen Widerspruch zum Postulat, das sich moderne Content-Management-Systeme in die unternehmensweite IT-Landschaft einfügen müssen, aber vergessen Sie nicht: Was nicht benutzbar ist, wird nicht benutzt!
My Interface sucks
Probleme mit der Benutzeroberfläche sind oft schwer dingfest zu machen und entstehen nicht selten über einen längeren Zeitraum. Die Symptome solcher Schwierigkeiten sind subtiler als jene, die sich zeigen, wenn die IT-Infrastruktur der Website zu klein dimensioniert ist. Nichtsdestotrotz können sie genauso schwerwiegend sein. Die Probleme mit solchen Interface-Flaschenhälsen führen zu Verzögerungen im editorischen Prozess. Vielleicht ist es zu schwer, an bestimmte Inhaltselemente zu gelangen, weil es - hervorragende Antwortzeiten des Redaktionsservers vorausgesetzt - einfach zu langwierig ist, sich durch die Inhalte zu schaufeln. Vielleicht gibt es bestimmte Funktionen, die Sie gerne gebündelt abarbeiten möchten, doch leider zwingt Sie das System dazu, jedes Objekt einzeln zu bearbeiten. Oder vielleicht zeigt das Content-Management-System nicht, welcher Redakteur gerade mit welchem Arbeitsschritt beschäftigt ist - was zu unnötigen Verzögerungen führt. Was zahlreiche Nachfragen über das interne Messaging-System zur Folge hat und damit zu einem Kommunikationsüberhang führt, zu dessen Abschaffung das System eigentlich in erster Linie gekauft wurde. Die Probleme mit der Interface-Skalierbarkeit lassen sich in vier Bereiche einteilen:
1. Ich muss es wieder und wieder und wieder tun ...
Mangelnde Unterstützung für Batch-Funktionen (wie das Löschen oder Verschieben von Inhaltselementen) ist eines der größten Gefahren, wenn es um Interface-Skalierbarkeit geht. Die Beschränktheit von Browser in Bezug auf grafische Bedienelemente und die der klassischen Client-Server-Architektur innewohnende Zeitverzögerung sind massive Probleme, mit denen Hersteller von Content-Management-Systemen zu kämpfen haben. Die Limitiertheit bei der Programmierung Browser-basierter Interfaces führt häufig dazu, dass Batch-Operationen überhaupt nicht implementiert werden oder ihre Nutzung so schwierig ist, dass sie dem Paradigma der intuitiven Benutzbarkeit widersprechen. Eine einfache Funktion als Beispiel: der Import eines Bildes. Die Vorgehensweise ist bei den meisten Systemen gradlinig und bedarf keiner näheren Erklärung. Wie jedoch steht es um die Möglichkeiten des Imports zahlreicher Bilder. Ein möglicher Workaround besteht darin, unter Umgehung der CMS-Benutzeroberfläche die Bilder per FTP auf den Server zu laden. Damit wird jedoch der Nutzer gezwungen, das System zu umgehen und sich auf andere (systemfremde) Technologien zu verlassen. Batch-Operationen sind die klassischen Beispiele bei der Betrachtung von Aspekten der Interface-Skalierbarkeit. Aspekte, die erst zu Tage treten, wenn es darum geht, größere Datenmengen in das Content-Management-System zu importieren.
2. Zeig' mir nur meine Sachen!
Dieses Konzept zeigt sich an zwei Stellen: Zunächst bei den Inhaltselementen, die ein Nutzer bearbeiten soll, dann bei den Inhaltselementen, die ein Nutzer bearbeiten darf. Alle ernst zu nehmenden Systeme am Markt verfügen über Workflows und Rechteverwaltung. Damit einher geht stets ein Interface, das Objekte und Funktionen, die nicht im Rechtebereich des Nutzers liegen, verbirgt. Das "Zeig' mir nur meine Sachen"-Konzept ist eine gängige Konvention des Content Management - mit großen Auswirkungen.
Zunächst zu den Dingen, die ein Nutzer bearbeiten soll. Ein mächtiger Workflow-Mechanimus ist eine unbedingte Notwendigkeit für ein Content-Management-System. Workflows helfen, Arbeitsabläufe sinnvoll zu strukturieren. Wenn also ein Mitarbeiter auf seiner Todo-Liste die Bearbeitung von zehn Artikeln stehen hat, ist es nur sinnvoll, wenn das CMS diese Artikel an prominenter Stelle zur Bearbeitung anbietet, egal welchen Themengebieten oder Site-Bereichen sie entstammen. Schließlich warten im Workflow nachgeordnete Mitarbeiter auf diese Inhalte. Wenn der Hersteller bei der Implementierung selbst einfachster Workflow-Features schludert, leidet die Effizienz.
Dann zu den Dingen, die ein Nutzer bearbeiten darf. Rechtesysteme sorgen dafür, dass ein Nutzer nur jene Objekte und Funktionen sieht, mit denen er arbeiten darf. Das bedeutet - so trivial es klingen mag - auch, dass ein Nutzer nicht sieht, was er nicht bearbeiten darf. Unnötige Bedienelemente überfrachten nicht nur eine Benutzeroberfläche, sie verwirren auch den Nutzer und machen ihn ineffizient. Moderne Content-Management-Systeme erledigen die Aufgaben Inhalts- und Funktionsfilterung meist sehr gut. Rechtesystem helfen dabei, dem Nutzer nur jene Inhaltsobjekte und Funktionen zu zeigen, mit denen er arbeiten darf. Und dennoch ist die Anzahl der Objekte oft noch unüberschaubar groß, selbst mit Rechte-basierter Filterung. Einige Hersteller sind dazu übergegangen, zusätzlich verhaltensorientierte Filterung in ihren Systemen zu implementieren, z.B. "recently opened"- oder "most accessed"-Listen.
Bitte beachten Sie unsere Informationen zum Datenschutz.
blog comments powered by Disqus© 2012 FEiG & PARTNER