Content Management für Eilige

Aus der Geschichte des WWW: Nach in mühevoller Handarbeit mit vi oder Notepad erstellten Homepages kamen datenbankgestützte dynamische Inhalte. Heute stellen Content-Management-Systeme sicher, dass die Bearbeiter sich auf die Inhalte konzentrieren können und nicht auf das Verfassen korrekten HTML-Codes. Communities wie Slashdot kanalisieren die verstreuten Informationen der Leser in konsumierbare und kommentierbare Formen. Foren bedienen die eher dialogorientierten Bedürfnisse des Netzvolks, während Weblogs dem Nobody seine ganz persönliche Bühne zur Inszenierung unbefriedigter Mitteilungsbedürfnisse bieten.

Allen diesen Ansätzen ist zweierlei gemein: Mit der Mühe nehmen sie dem gemeinen Benutzer meist ebenfalls die Freiheit, seine Inhalte weiterhin beliebig zu bearbeiten, wenn der `Senden'-Knopf einmal gedrückt ist. Und Zusammenarbeit mit anderen ist oft bestenfalls über hinzugefügte Kommentare, im ungünstigsten Fall nur über Feedback via E-Mail möglich. Allzu häufig haben Webautoren sich schon geärgert, dass es eben nicht machbar ist, einen offenkundigen Fehler auf einer Webseite stillschweigend korrigieren zu können, zu knappe Informationen einfach zu ergänzen oder kurzerhand mit einem Link auf andere Seiten mit mehr Details zu versehen. Ganz schnell und unkompliziert, ohne durch HTML-Tags waten oder zusätzliche Software installieren zu müssen, ohne umständliche Download-Bearbeiten-Upload-Zyklen; ohne Registrierung und ohne Passwörter.

Kartenstapel als Basis fürs Web

Ein kleiner Schritt zurück in das Jahr 1995: Ausgehend von einem Hypercard-Stack für den Macintosh schrieb Ward Cunningham ein CGI-Script in Perl, das es ermöglichte, in einzelnen Dateien gespeicherte Textinhalte mit HTML-Formularen direkt im Browser zu bearbeiten und zu verknüpfen. Ziel war eine schnelle und einfache Möglichkeit, Texte online zu verfassen, sie im WWW zu veröffentlichen und Dritten das einfache Kommentieren, Ändern und Ergänzen dieser Texte zu erlauben. Als Namen für seine Software wählte er `wiki wiki', den hawaiianischen Begriff für `schnell'. So einfach diese Software war, sie hatte ein bestechendes Konzept, das sich beim Einsatz dieses ersten Wiki-Wiki-Webs beim Portland Pattern Repository (ein Online-Journal zu den Themen Pattern Languages und Extreme Programming) in den folgenden Jahren bewährte. Einem Ansatz des Extreme Programming (XP) folgend (`Do the simplest thing that can possibly work') versucht ein Wiki, die Grenzen zwischen passiver Nutzung und aktivem Erstellen von Inhalten aufzuheben.

Klickt man in einem Wiki auf einer beliebigen Seite auf den `Bearbeiten'-Link, erhält man ein Formular, das wenig mehr enthält als ein Textfeld mit den Inhalten und einem Knopf zum Speichern der Seite. Im Textfeld findet man die zu bearbeitenden Inhalte der Seite nicht etwa in HTML, sondern in einem extrem einfachen, für die manuelle Eingabe optimierten Format: Absätze werden durch eine Leerzeile erzeugt, Textauszeichnungen wie Zwischenüberschriften, Betonungen oder Trennlinien durch Umschließen des jeweiligen Textteils mit Hochkommata, Unterstrichen und anderen ähnlich leicht erreichbaren Zeichen markiert. Nebenstehender Screenshot des Dse-Wiki - der deutschsprachigen Softwareentwickler - lässt die Struktur gut erkennen.

Einfache Struktur: links die eigentliche Webseite, rechts das Formular zum Ändern derselben.

Nach dem Speichern der Seite werden diese Auszeichnungen für den Browser in HTML umgesetzt, die Titel anderer Seiten dabei automatisch auf diese verlinkt. Die Software erkennt solche Titel anhand eines einfachen Schemas sogenannter `WikiWörter': jedes zusammengezogene Wort mit großen Anfangsbuchstaben stellt einen solchen Seitentitel dar, der sogar dann verlinkt wird, wenn die betreffende Seite noch gar nicht existiert. Folgt man einer solchen URL auf eine nicht existierende Seite, liefert der Server keine Fehlermeldung, sondern einfach ein leeres Formular, mit dem sich die neue Seite umstandslos mit Inhalten versehen lässt.

Ähnlich direkt wie das Bearbeiten ist die Navigation im Wiki. Sie erfolgt hauptsächlich über im Inhalt zu findende URLs auf weitere Seiten. Wenn man sich zu verirren droht, hilft eine schnelle Volltextsuche weiter, ein Klick auf den Titel der aktuellen Seite listet alle anderen Seiten auf, die im Text auf diese verlinkt sind. Spätestens wenn man beginnt, angelernte Reflexe wie die Suche nach einem inhaltlichen Navigationsmenü zu unterdrücken und stattdessen häufiger den Back-Button des Browsers zu benutzen, fällt einem die durch weitgehenden Verzicht auf grafische Elemente und komplexe Layoutstrukturen gewonnene Geschwindigkeit des Seitenaufbaus auf. Bei häufigerem oder gar täglichem Besuch eines Wikis dürften Webbenutzer die automatisch erzeugte Liste zuletzt geänderter oder neu erzeugter Seiten zu schätzen lernen und anderswo bald schmerzlich vermissen.

Wenn Anwender einfach editieren

So originell all das klingen mag - es stellt sich die Frage, ob derlei zu etwas zu gebrauchen ist. Bei der Erkenntnis, dass hier jeder dahergelaufene Surfer die Seiten beliebig ändern oder gleich ganz löschen kann, steht dem gestandenen Webmaster das blanke Entsetzen ins Gesicht geschrieben. Mit etwas interessierter Nachdenklichkeit gemischt ist dieser Ausdruck bestenfalls bei Betreuern interner Informationssysteme: Wie wäre es, wenn die Benutzer sich auf diese Weise zumindest teilweise selbst um ihre Inhalte kümmern könnten, anstatt für jede Kleinigkeit dem Betreuer die Zeit zu stehlen?

In der Tat ist ein Wiki für solche Zwecke prädestiniert. Motorola verwendet mittlerweile mindestens fünf Installationen von TWiki (siehe Kasten `Auswahl von Wiki-Engines') für interne Zwecke, mit Zugriffszahlen von rund 16 000 Hits pro Tag (Juli 2002). Ein Wiki stellt einen im Volltext durchsuchbaren, verteilt zugänglichen strukturierten elektronischen Zettelstapel dar, der wenig Ressourcen beansprucht, schnell installiert ist und ansonsten wenig Arbeit verursacht. In vielen Fällen führt gerade die flexible Struktur, die sich erst mit den von den Benutzern angelegten Seiten entwickelt und die durch simpelste Bedienung niedrig bleibende Benutzungsschwelle zu einem schnell wachsenden Knowledge-Pool leicht zugänglicher und auffindbarer Informationen.

Für öffentlich zugängliche Wikis scheint paradoxerweise zu gelten, dass sie um so besser funktionieren, je spezieller ihr Thema ist. Obwohl sich ein Wiki geradezu anbietet, um Informationen zu allgemein interessierenden Themen zu sammeln, funktionieren offenbar die Wikis besser, die einen großen Anteil aktiver statt nur passiver Besucher haben. Eine Ausnahme können einfache private oder nichtkommerzielle Homepages sein, bei denen ein Wiki als einfaches Content-Management-System für textzentrierte Inhalte dienen kann, notfalls mit abgeschalteten oder zugriffsgeschützten Editierfunktionen.

Obwohl die Wiki-Grundideen nichts von ihrer Faszination verloren haben, haben sich seit 1995 nicht nur die Wahrnehmungsgewohnheiten der Webbenutzer geändert. Und die Entwickler haben ebenfalls nicht geschlafen. So beherrscht die Auszeichungssprache vieler Wikis heute Tabellen, Fußnoten und eingebundene Grafiken. Seitentitel lassen sich nicht mehr nur mit hässlichen `WikiWörtern', sondern ohne viel Tippaufwand erheblich gefälliger formulieren. HTML-Templates für die Anpassung der Darstellung an die Vorlieben des jeweiligen Publikums sind schon fast selbstverständlich, ebenso wie eine zumindest rudimentäre Rechteverwaltung, mit der sich einzelne Seiten gegen Veränderungen sperren lassen.

Revisionskontrollsysteme nehmen unerwünschten Löschungen oder Änderungen von Inhalten den Schrecken, Datenbankanbindungen samt Plug-in-Systemen wie bei phpwiki lassen ein Wiki als Framework für speziellere Anwendungen geeignet erscheinen. Da zudem die meisten Wiki-Engines als Open Source daherkommen und wohl jeder eine in seiner Lieblingssprache programmierte Engine finden dürfte, sind individuelle Anpassungen meist mit handhabbarem Aufwand zu schaffen. Verglichen mit vielen anderen Webapplikationen sind Wikis oft verblüffend wenig komplex - ab 170 Zeilen (AwkiAwki) ist man dabei.

Fazit

Betrachtet man die aktuelle Entwicklung bei Wiki-Engines, beginnt teilweise technisch gesehen die Grenze zu ausgewachsenen CMS zu verschwimmen. Der Unterschied ist trotzdem leicht auszumachen: Ein Wiki legt den Schwerpunkt auf Einfachheit, Offenheit und Geschwindigkeit, während ein CMS primär auf Verwaltung der Inhalte abzielt, die Erstellung auch komplex gestalteter Seiten ermöglicht, mit fein granulierter Rechtevergabe die Möglichkeiten der Benutzer kontrolliert und die dafür notwendige Einarbeitung aufgrund hoher Komplexität in Kauf nimmt. Ob ein Wiki für einen gegebenen Einsatzzweck das Richtige ist, sollte sich auf dieser Achse einfach bestimmen lassen. Für die Auswahl einer Wiki-Engine anhand ihrer Features hilft vielleicht ein weiterer Grundsatz des Extreme Programming weiter: `You aren't going to need it'.

JOCHEM HUHMANN

ist freiberuflicher Autor.

Literatur

[1] Bo Leuf, Ward Cunningham; The Wiki Way: Collaboration and Sharing on the Internet; Reading, MA (Addison-Wesley) 2001

[2] Richard Cyganiak; Wiki und WCMS: Ein Vergleich; Hausarbeit vom 19. Mai 2002 - [PDF]