Wiki bedeutet: Schnelligkeit. Wiki bedeutet: writable web. Wiki bedeutet: jeder kann ein Autor sein.
Unglücklicherweise ist aber nicht jeder Wiki-User ein Wiki-Autor: Nur ein kleiner Prozentsatz der User erstellen und ändern Inhalte selber.
Für große Communities wie Wikipedia ist dies kein Problem; in kleinen Wikis schon. Insbesondere in Enterprise Wikis - beim Einsatz eines Wikis in einem Unternehmen also - wird nach den Ursachen hierfür gefragt.
Eine häufig gegebene Antwort ist, dass die Wiki Bedienung zu kompliziert sei. Die Wikisyntax schrecke viele potentielle Autoren ab: Besser wäre es, die Bedienung sei einfach wie Word.
Word als Wiki-Editor - das ist verlockend; erst Recht in Unternehmen, die den Wiki-Rollout wegen der zu erwartenden Widerstände des Personals scheuen („Wie? schon wieder ein neues System?!“). Gewünscht ist hier vor allem das Wysiwyg-Formatieren von Textabschnitten. Was ist so schlecht daran, das in einem Wiki so anzubieten?
Die Antwort ist: nicht alles, was in Word augenscheinlich einfach ist, ist es auch in Wirklichkeit. Und das, was in Word möglich ist, macht nicht zwangsläufig in einem Wiki Sinn.
Wikis sind unter anderem deswegen so erfolgreich, weil sie ein sehr simplen Vorrat an Strukturierungsmöglichgkeiten bieten: Im wesentlichen
Die Beschränkung auf wenige Strukturwerkzeuge zwingen die Wiki-Autoren, sich Gedanken über den Aufbau des Dokumentes zu machen. Da diese Strukturen automatisch hinterlegte typografische Visualisierungen (Style-Sheets) haben, werden keinerlei manuelle Eingriffe zur Gestaltung dieser benötigt - im Gegenteil: die konsequent einheitliche Formatierung erleichtert es den Lesern, eben jene Strukturen besser zu verstehen.
Das, was an Word augenscheinlich so einfach ist - das Färben, Fett- und Kursivstellen und die Kombination verschiedener Fonts - ist auch maßgeblich dafür verantwortlich, dass viele Texte ein fragwürdiges Erscheinungsbild bekommen, denn leider sind nur wenige mit den Grundsätzen der Typografie vertraut: Nicht jeder Autor ist ein guter Setzer.
Die oben genannten zeichenorientierten Formatierungen wie kursiv, Font-Farbe etc sind genau genommen die einzigen wirklich einfach in Word zu handhabenden Werkzeuge 2). Die Verwendung von Gliederungen dagegen ist in Textverarbeitungsprogrammen kompliziert; dies ist natürlich auch dem Umstand geschuldet, dass hier auch sehr umfangreiche Texte oder sogar Bücher erstellt und strukturiert werden müssen. In Wikis ist dies nicht nötig - komplexe Themen werden in mehrere untereinander verlinkte Dokumente aufgeteilt.
Wirklich leistungsfähig wird Word erst, wenn konsequent mit Formatvorlagen gearbeitet wird. Dieses entspricht dann im Grunde der Arbeit im Wiki: Inhalte strukturieren und gemäß der Semantik auszeichnen. Die Schönheit kommt dann ganz von allein. 3)
Wikis unterliegen als Webanwendungen grundsätzlich den Anforderungen an den Schriftsatz in digitalen Dokumenten, haben aber ein paar Besonderheiten:
Es gibt kein festes Spaltenmaß und in der Regel auch keine Mehrspaltigkeit: die Spaltenbreite richtet sich nach der Breite des Browserfensters. Verändert der Nutzer die Größe des Browsers, so ändern sich auch die Zeilenumbrüche. Im Webdesign manifestiert sich seit längerem der Trend für ein festes Spalten-Layout; in Wikis hat sich dies (noch) nicht durchgesetzt. Kritikpunkt des liquid Layout ist vor allem die mangelnde Lesbarkeit allzu langer Zeilen: der wichtigste typografische Wirkfaktor ist die Zeilenbreite, als optimal werden 40-50 Anschläge pro Zeile angesehen 4).
Fürsprecher des liquid design dagegen mahnen an, dass es auf Grund der unterschiedlichen Bildschirmgrößen und -Auflösungen ohnehin verschiedene Ergebnisse zu erwarten sind. Nicht zu letzt durch das barrrierefreie Design können Benutzer ihre Schriftgröße selbst einstellen - wodurch sich ebenfalls die Anzahl der Anschläge pro Zeile verändert.
Absätze werden simpel mit doppelten Leerzeilen eingerichtet. Das in der Print-Typografie verbreitete Mittel des Einzugs wird in der Praxis nicht verwendet. (Das Prinzip des Einzugs der ersten Zeile wirkt typografisch harmonischer und spart Papier. Im Web mit anderen Lesegewohnheiten und ohne Platzprobleme gilt das so nicht).
Die den Wikiartikeln innewohnende, durch Überschriften bzw. Gliederungspunkte vorgegebene Struktur wird in einem Inhaltsverzeichnis (TOC - Table of Contents) mitgeführt. Dies entspricht einer seiteneigenen Subnavigation. Problematisch ist die Platzierung des Inhaltsverzeichnisses: es macht vor allem Sinn im oberen Bereich der Seite, nimmt dort aber den ersten Sätzen den Platz weg. Da das Inhaltsverzeichnis automatisch aus Überschriften generiert wird, benötigt es (in Breite und Länge) flexibel Platz.
In der Typografie sind Fettstellungen und Unterstreichungen verpönt; Fettstellungen stören den Grauwert und damit den Lesefluss; Unterstreichungen (für Typografen eh ein Graus) werden für Hyperlinks verwendet. Es bleiben somit nur Kursivstellungen, die aus typografischer Sicht unproblematisch sind: sie stören nicht den Grauwert, und werden erst beim Lesen wahrgenommen.
Ein wenig offensichtlicher, aber dennoch wichtiger Faktor für den Erfolg von Wikipedia besteht in der Einheitlichkeit der Präsentation. Würde dort jeder Redakteur sich als Schriftsetzer betätigen, so wäre bedingt durch die unterschiedlichen ästhetischen Empfindungen und das gestaltersiche Können ein uneinheitliches Erscheinungsbild die Folge, welcher der Akzeptanz für freies Wissen nicht gerade förderlich wäre.
Dieses Ziel wird beileibe nicht automatisch erreicht, sondern ist in verbindlichen Regeln festgelegt: Die Kriterien für gute Artikel geben eine Übersicht zum Aufbau „guter“ Artikel. Lesenswert in diesem Zusammenhang ist der Wikipedia Guide to Layout, der eine Empfehlungsliste zur Gliederung der Texte und der Verwendung von Strukturbausteinen gibt. Ein solches Regelwerk ist gerade für eine themenübergreifende Informationssammlung enorm hilfreich, da hierdurch Gemeinsamkeiten geschaffen werden, die dem Leser zu Gute kommen. Zudem sind Artikel bezüglich dieses Regelwerkes überprüfbar und können (von Koautoren) angepasst werden.
Das sehr umfangreiche Dokument Manual of Style befasst sich dagegen mit den typografischen Festlegungen. Schwerpunkt hier sind Festlegungen zur Schreibweise und zur Verwendung der Punktuation.
Und wo bleibt dabei die Formatierung?
Formatting issues such as font size, blank space and color are issues for the Wikipedia site-wide style sheet and should not be specified in articles except in special cases. 5)
Dennoch bleibt man aber irritiert zurück: Heisst „Wiki“ nicht „schnell“? Was wird gewonnen, wenn zwar die (rein technische) Eingabe der Inhalte sehr einfach ist 6), die Anforderungen an die Struktur dagegen hoch sind: Genau hierfür ist ja eine Systemunterstützung wünschenswert!
Mit einer einfachen Integration einer Toolbar, über die Fonts, Farben und Schnitte gewählt werden können, werden die Probleme also nicht gelöst. Statt dessen muss de Benutzer bei der Pflege von Strukturen unterstützt werden.
Im ICKE Projekt befassen wir uns unter anderem mit eben diesem Thema und werden die Arbeit mit DokuWiki verbessern. Fokus liegt hierbei also nicht auf der vollständigen Implementation eines Wysiwyg-Editors, sondern in der Optimierung bei der Bearbeitung der Wiki-Syntax.
Bereits umgesetzt und in die DokuWiki-Code-Base eingecheckt sind folgende Verbesserungen:
Listen: Hier ist ein automatisches Einfügen von Folgepunkten sowie ein Wechsel der Ebenen gewünscht
Überschriften: Unterstützung, um nachfolgende Überschriften der gleichen Ebene einfach erzeugen zu können
Linkeditor: Unterstützung bei der Suche nach Dokumenten
Auf der weiteren Todoliste stehen:
Neben diesen Aspekten der Systembedienung werden Hilfestellungen für die Strukturpflege entwickelt. Gerade in Unternehmenswikis werden die Dokumente häufig bestimmten Inhaltsmustern zuzuodnen sein (Mitarbeiterseiten, Projektseiten etc). Zur Erstellung solcher Dokumente wird eine Wizard-Technologie entwickelt werden, mit welcher (kundenspzifisch anpassbar) in wenigen Schritten das Rohgerüst für Dokumente erstellbar ist. Getreu dem Motto etwas Bestehendes zu verändern ist einfacher als etwas neues Schaffen können diese dann mit dem Syntaxeditor weiterbearbeitet werden.
Auch wenn das Wikiprinzip an sich einfach ist, so ist der Aufbau einer vielseitig genutzten Wissensplattform aufwändig; ein Wysiwygeditor schafft hierbei an sich keine Abhilfe, sondern verlagert lediglich das Problemfeld.
Durch Optimierungen der Usability aber lassen sich viele Hemmnisse von Wikineulingen abbauen; Für den Erfolg eines Wikis aber bleibt eine intensive Beschäftigung mit den Inhaltsstrukturen unerlässlich.
