Schnell, schnell

Tim Berners-Lees Traum Anfang der 90er Jahre war nicht der Webbrowser, wie ihn ein jeder kennt, sondern eine Mischung aus Viewer und Editor. In einem im Wesentlichen nichtkommerziellen Bereich hat sich eine solche Technik durchgesetzt: bei den Wiki-Engines.

28

12.09.2002, 02:00 Uhr

Lesezeit: 8 Min.

iX Magazin

Von

Jochem Huhmann

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.

Auswahl von Wiki-Engines

Eine vollständigere Liste von gut 70 Wiki-Engines findet sich unter c2.com/cgi/wiki?WikiEngines .

Kehei Wiki (Perl) ist eine erweiterbare Wiki-Software mit HTML-Templates, öffentlichen und privaten Bereichen, C/C++-Quelltextbrowser und optionalem kommerziellem Support (kehei.com/).

JSPWiki (Java Server Pages) unterstützt UTF-8, hat ein Plug-in-Interface, lässt sich über XML-RPC fernsteuern und exportiert einen RSS-Feed (Rich Site Summary) für Content Syndication (www.ecyrd.com/JSPWiki/Wiki.jsp).

AwkiAwki (awi) hat nur eine minimale Menge an Eigenschaften, ist aber klein und schnell (awkiawki.bogosoft.com).

TWiki (Perl) verfügt über Zugriffskontrollen auf Benutzer- und Gruppenebene samt Benutzerregistrierung, Revisionskontrolle, Plug-ins, Templates, Dateianhänge, E-Mail-Benachrichtung bei Än-derungen und viele andere Features (twiki.org/).

PHPWiki (PHP) unterstützt Datei- und mehrere Datenbank-Backends, allgemeine und seitenspezifische Templates, RSS, Plug-ins, benutzerspezifische Einstellungen, XHTML-Export (phpwiki.sourceforge.net).

MoinMoin (Python) verfügt neben den üblichen Features über spezielle Wiki-Farm-Unterstützung und grundlegenden XML-Support (moin.sourceforge.net/).

OpenWiki (ASP/VB) läuft auf Microsofts IIS, kontrolliert die Benutzerschnittstelle über XML-Stylesheets und verfügt über extensive RSS/RDF-Unterstützung (openwiki.com/).

Wikit (Tcl) arbeitet mit nur einer Datei für Code und Daten, lässt sich durch einfaches Kopieren dieser Dateien komplett transferieren und bietet für lokale Benutzung ein GUI-Frontend (mini.net/tcl/).

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]

iX-TRACT

Wikis sind einfach einsetzbare Werkzeuge zur gemeinschaftlichen Erstellung und Pflege von Hypertext-Inhalten, öffentlich oder in geschlossenen Gruppen.
Im Gegensatz zu Content-Management-Systemen setzen Wikis auf die direkte Mitarbeit der Nutzer durch Minimierung von zentralisierter Kontrolle und Anwendungskomplexität.
Die bewußte Einschränkung auf minimales Mark-Up begrenzt das Einsatzgebiet von Wikis weitgehend auf Freiform-Inhalte, die ohne wesentliche multimediale Anteile auskommen.

Wiki-Tipps

Wikis stellen durch ihre offene und dynamische Struktur besondere Anforderungen an Benutzer und Administratoren. Deshalb hier einige Tipps.

Viele Wiki-Engines kommen mit einem Grundbestand von Seiten, die das Prinzip Wiki erklären, die Editiermöglichkeiten erläutern und oft etliche Worte über Geschichte und Grundlagen dieser Idee verlieren. Werden diese Default-Seiten einzeln direkt von der Startseite verlinkt, finden neue Besucher vor lauter Wiki kaum zu den Inhalten. Besser ist es, notwendige Erläuterungen über einen einzelnen Link (`Benutzungshinweise') auf einen eigenen Bereich auszulagern.

Die Startseite sollte einer Handvoll Links auf Unterseiten vorbehalten sein. Die teilt man besser erst dann weiter auf, wenn sie beginnen, unhandlich groß zu werden. So ergibt sich die notwendige Struktur fast von allein. Eine komplexe Struktur von leeren oder fast leeren Seiten schreckt Benutzer eher ab, während Ergänzungen und Korrekturen zu bestehenden Inhalten oft leichter fallen. Sowohl für öffentliche als auch für interne Wikis gilt meist, dass Benutzer entweder beim ersten Besuch dableiben und mitmachen oder aber so bald nicht wiederkommen. Besser als breitgestreute Ankündigungen ist es daher, gezielt einzelne Personen per E-Mail einzuladen, von denen man weiß, dass sie am betreffenden Thema interessiert sind. Auch wenige oder gar ein einzelner Mitarbeiter können ein Wiki sinnvoll nutzen.

Wenn ein Wiki zu wachsen beginnt, sammeln sich zusammengehörige Informationen oft verstreut auf verschiedenen Seiten. Hier sollte man sich nicht scheuen, diese Teile frühzeitig zusammenzufassen und redundante Teile zu löschen. Je konsistenter die Seiten sind, desto leichter finden Benutzer einen passenden Ort für ihre Beiträge.

Suchmaschinen wie Google indizieren Links auf dynamische Inhalte, begrenzen aber die Anzahl solcher Links, die pro Seite verfolgt werden, um sich nicht in Datenbanken (etwa Online-Shops) festzubeißen. Wer Wert auf Indizierung des Wiki durch solche Suchmaschinen legt, sollte Seiten spätestens dann aufteilen, wenn sie viele Links auf andere Wiki-Seiten enthalten. Alternativ können manche Wikis zusammen mit Rewrite-Rules des Webservers URLs als statische Verzeichnis- und Dateinamen darstellen.

Last not least: Selbst in einem gut gepflegten Wiki werden Benutzer signifikant häufiger Links zu anderen Seiten folgen oder den Back-Button betätigen als auf einer regulären Website. Schnelligkeit beim Seitenaufbau ist daher nicht nur Bonus, sondern pure Notwendigkeit. Erforderliche Begrenzungen der Textbreite mittels CSS-Stylesheets sind daher Seitenlayouts mit Tabellen vorzuziehen - und grafische Elemente sollte man sparsam verwenden.