Wikis in Organisationen: Anforderungen an das Wiki

Aus Wikibooks

Zur Einführung eines Wikis sind eine Vielzahl von Anforderungen zu betrachten. Die Auswahl der Software ist einer unflexibelsten Entscheidungen bei einem Wiki, da eine Änderung der Software nur schwer möglich ist.

Jede Wikisoftware bringt eine gewisse Grundphilosophie mit. Das sind unterschiedliche Konzentrationspunkte wie Benutzerfreundlichkeit, Zugriffsregelung, Strukturierung etc

Usability ist wahrscheinlich die wichtigste Eigenschaft für den Erfolg jedes Kommunikationssystems.

Inhaltsverzeichnis 1 Markup 2 Änderungsmanagement 3 Rollenkonzept 3.1 Inhalte 3.2 Gruppen 4 Darstellung 5 Ordnung 5.1 Kategorisierung 5.2 Namensraum 6 Dateien 7 Programmierung 8 variable Textbausteine 9 Workflow 10 Skalierung 11 Datenbank 12 Add-on 13 Quellen

[Bearbeiten] Markup

Oft stößt man bei den ersten aktiven Wikiberührungen auf missfallen beim Markup. Es sieht, wie alles Neue, ungewohnt und damit schwierig aus. Allerdings verdienen die meisten Wiki-Syntaxen den Namen Markup nicht, da sie sehr leicht zu lernen sind und die Regeln auf einer Postkarte Platz haben.

Die optimierte und standardisierte Wikitext-Sprache Creole ist ein Weg in die richtige Richtung.

WYSIWYG ist zwar eine oft geforderte Anforderung, wird aber erfahrungsgemäß im laufenden Betrieb nicht benötigt, da die Vorteile von Markup überwiegen. Allerdings ist das "verwirrende" Markup ein gewaltiger psychologischer Hemmschuh gegen ein Wiki: „In einer unternehmens-internen Umfrage unter Verantwortlichen äußerten 75% der Befragten, dass sie selbst und die Mitarbeiter ihres Bereiches ein Wiki ohne integrierten Rich-Text Editor kaum verwenden würden. der Praxis konnte dies zwar teilweise wiederlegt werden“ (^[1])

[Bearbeiten] Änderungsmanagement

Eine Wiki von seiner Veränderung, doch diese müssen gut überwachbar sein. Dazu ist es wichtig das die Software nicht nur mitteilt das etwas verändert wurde, sondern auch was. Die sogenannte Diff-Darstellung beschreibt genau welche Textphrasen verändert wurden. Hilfsmittel zur Benachrichtigung sind Beobachtungslisten und letzte Änderungen, aber auch externe wie Email oder RSS.

[Bearbeiten] Rollenkonzept

Es gibt unterschiedliche Organisationsstrukturen, zwar sollte man immer versuchen möglichst einfach und freiheitlich mit den Hierarchien umgehen. Aber manche Organisationen wollen und brauchen speziellere Zugriffsregelungen, um ihr organisatorisches Sicherheitsbedürfnis zu decken. Auch in der Einführungsphase ist es wichtig, das bestehende Rollenkonzepte abgebildet werden können, auch wenn diese mit der Zeit einfacher werden und mehr in das Wechselspiel zwischen schneller Änderung und deren Überwachung verändert.

Prinzipiell müssen mindestens die Grundseiten immer für alle Teilnehmer einsehbar und veränderbar sein. Können "normale" Mitglieder nur in ihren Bereichen (Namensräumen) editieren ist das Wikiprinzip gebrochen und die Nutzer sind nur schwer zur Mitarbeit zu bewegen.

Weiter gilt in einem Wiki mit einem definierten Mitgliederstamm im Gegensatz zu einem freien Wiki im Internet: Jeder der lesen darf, darf auch schreiben^[2]. Viele Berater empfehlen auch: Keine Zugriffs- oder Editierbeschränkungen! (alle User dürfen alles)^[3]. Die Gefahr, dass Seiten mutwillig zerstört werden besteht aufgrund der namentlichen Verfolgbarkeit nicht.

[Bearbeiten] Inhalte

Gesperrte Inhalte, die nur einer exklusiven Gruppe (z.B. Geschäftsleitung, Entwicklung) vorbehalten sind, müssen sicher und einfach verwaltbar sein; dazu gibt es 2 Methoden:

Seite werden einzeln gesperrt (Seitenselektiv)

Hier ist die Auswahl der verdeckten Inhalte selektiv. Mit einer einzelnen Sperrung lassen sich wenige, spezielle Seiten die brisante Inhalte beinhalten sperren; eine größere oder definierte Informationsmenge ist so schwer zu schützen.

Es werden ganze Namensräume oder Kategorien gesperrt (Raumselektiv)

Alle Inhalte, die in einem sinnvollen Namensraum (z.B. Entwicklung) stehen, sind für Nichtmitglieder weder einsehbar noch editierbar. So werden sehr viele Inhalte grundsätzlich dem Zugriff "Gruppenfremder" entzogen.

Eine Kombination aus beiden ist natürlich ideal.

[Bearbeiten] Gruppen

Die Mitglieder und Teilnehmer an einem Wiki kann man in unterschiedliche Gruppenformen einteilen:

• Liegt eine hierarchische Ordnung vor, darf die oberste Gruppe (z.B. Geschäftsführung, Admins) alles einsehen und ändern, die Gruppen darunter dürfen dann immer weniger.
• bei einer matrizenförmigen Ordnung dürfen bestimmte Gruppen sich nicht gegenseitig in die Inhalte schauen. So darf die Entwicklung nicht die Preisstruktur des Marketings sehen, im Gegenzug die Marketingabteilung nicht die Neuentwicklungen.

Auch hier gilt weniger ist mehr. Umso feiner eine Gruppenstruktur gezimmert wird umso mehr gehen die Wikieigenschaften flöten und am Schluss hat jeder seinen eigenen, ausschließlich persönlichen Bereich. Der Vorteil eines Wikis, das man Informationen der des ganzen Teams oder Organisation nutzen und aktiv mitgestalten kann, ist weg.

[Bearbeiten] Darstellung

Wikiinhalte werden hauptsächlich mit einem Browser auf einem normalen PC dargestellt. Allerdings sind weitere Darstellungsarten möglich und nützlich:

Drucken

Für normale Büroausdrucke gibt es fast allen Wikisystemen eine spezielle Druckseite oder ein print-css wie bei klassischen Internetseiten auch üblich. Aufwendigere Druckverarbeitungen für Broschüren oder gebunden Bücher sind wie bei anderen Inhaltsverwertungssystemen nicht standardmäßig eingebaut. Es gibt aber sicher Möglichkeiten ein Wiki als Text- oder Mediadatenbank eines Desktop Publishing Systems einzubinden. Teilweise gibt es weiter noch die Möglichkeit mehrere Seiten in Buchform zu bringen, um alle oder bestimmt Artikel in eine klassisches Buch zu fassen (für Handbücher etc.).

Präsentation

Inhalte müssen oft vorgestellt werden. Dabei muss man nicht unbedingt alle Inhalte statisch aus dem Wiki in eine Powerpointpräsentation kopiert werden. Auch hier kann man direkt aus dem Wiki präsentieren, muss die Inhalte aber für einen Vortrag den die Projektion umgestalten. Hier gibt es wieder die Möglichkeit mit einem projection css, welches aber nur vom Browser Opera nativ unterstütz wird und sonst mit einem styleswitch eingeschaltet werden muss. Angenehem ist S5, ein Präsentationssystem auf der Grundlage von XHTML zur Definition von Präsentation und den dazugehörigen Folien.

Mobil

Nicht nur das mobile Internet sondern auch das mobile Intranet wird immer wichtiger und hilfreicher. Außendienstler oder Montagetrupps können wichtige, umfangreiche und aktuelle Information auch ohne Laptop abrufen. Dazu ist eine Darstellung auf mobilen Geräten nötig, die aber wiederum per css oder Sonderansicht möglich ist und als gängige Webtechnologie bei vielen engines dabei ist.

[Bearbeiten] Ordnung

Zwar ordnet sich ein Wiki primär semantisch matritzenförmig durch unterschiedliche Seiten die jeweils ein abgegrenztes Thema beschreiben. Doch kann man in einem Wiki gleichzeitig mehrere Ordnungssysteme verwenden.

[Bearbeiten] Kategorisierung

Die wichtigste 2. Ordnung in jedem Wiki sind Kategorien. Zwar könnte man Kategorien manuell als eigene Seiten führen, jedoch benötigt man so für jede Kategorisierung 2 Edits. Was erfahrungsgemäß irgendwann nicht mehr gemacht wird.

Es gibt streng hierarchische Kategorisierungen, bei der alle Kategorien immer einer Baumstruktur nach unten folgen, und matritzenförmige, bei der auch Querkategorien angelegt werden können.

Wichtig ist hier auch die Skalierbarkeit. Muss man Kategorien z.B. aus einem DropDown-Menue auswählen (Tikiwiki), fällt die Übersichtlichkeit schnell weg, da alle Kategorien angezeigt werden müssen. Andere Kategorisierungssysteme binden sich als spezieller Syntax (Mediawiki) auf der Seite ein, und können so wesentlich mehr werden.

[Bearbeiten] Namensraum

Namensräume können eine nützliches Instrument zur Strukturierung sein und sollten in den meisten engines vorhanden sein.

[Bearbeiten] Dateien

Die meisten Wikisysteme können Dateien verwalten. Meist lässt sich einstellen welche Dateitypen erlaubt sind. Wenige wikis haben einen Bulkupload, bei dem mehrere Dateien gleichzeitig oder ganze Ordner hochgeladen werden können.

[Bearbeiten] Programmierung

Computerprogramme bestehen auch nur aus Text, dem Quelltext. Sicherlich ist ein Wiki der falsche Ort um komplexe Softwareanwendungen zu verwalten. Aber es gibt weniger komplexe dafür mehr integrierte Software die man in einem Wiki verwalten kann:

• Datenbankabfragen die mehr als einmal gebraucht werden, für die sich aber keine eigene Applikation lohnt, können erst einmal als Text im Wiki gespeichert werden um sie dann mit einem anderen Programm auszuführen. Allerdings ist das Wiki selbst schon eine Datenbankumgebung, das ein Wiki dann über eine Scriptsprache (z.B. PHP) die Abfrageergebnisse selbst darstellt ist ein weiterer Zwischenschritt.
• Makros

[Bearbeiten] variable Textbausteine

Variable Textbausteine sind Seiten die als vorgefertigten Text der in einen anderen Text eingefügt wird. Dabei aktualisiert sich der Text automatisch in allen Seiten in die dieser eingebunden ist. Es gibt aber auch statische Vorlagen.

In diesen Textbausteinen kann man je nach Wikiengine alle Funktionalitäten (Markup, Kategorisierung, html, Sperren, etc) verwenden. Im Wikipedia- und Mediawikiumfeld werden diese Vorlagen genannt. Es handelt sich dabei um nicht ausführbare PHP Includes.

Diese Bausteine sind hilfreich um Artikel zu Kennzeichnen, Unternavigation oder Infoboxen sehr benutzerfreundlich aber flexibel und umfassend zu gestalten.

Teilweise lassen sich diese auch programmieren (Mediawiki).

[Bearbeiten] Workflow

Die Wikiphilosophie dreht den klassischen Workflow um. Normalerweise wird eine Änderung "beantragt" und dann vom Verantwortlichen freigegeben, was mitunter dauern kann. In der Umgebung eines Wikis ist Vertrauen aber elementar (Natürlich würde keine Firma verlautbaren kein Vertrauen in seine Mitarbeiter zu haben). In diesem Vertrauensumfeld geht man davon aus das Neuerungen oder Änderungen nach besten Gewissen gemacht werden, auch bei kritischen Informationen wie Geschäftsprozessen. Das hat den immensen Vorteil das Änderungen nah am Zeitgeschehen mit dokumentiert werden können und nicht im Rund lauf dahinsterben und sich selbst überholen. Wobei Änderungen im Nachlauf immer noch kontrolliert werden.

Wir doch ein redaktioneller Wikiworkflow gewünscht so kann diesen derzeit nur Confluence und Twiki anbieten.

[Bearbeiten] Skalierung

Ein dann grundlegendes System wie eine Wiki muss die Größe und Struktur der Organisation auch bedienen können. Die meisten Technologien sind sicherlich standardmäßig für eine Mitgliederanzahl in der Größe einer Kleinstadt ausgelegt; aber auch größerer Zugriffe sind durch technisch Aufrüstung kein Problem. Auch eine hohe örtliche Verzweigung ist weltweit, durch Internet,möglich. Die verhältnismäßig geringen Datenmengen die übermittelt werden sind schnell verteilt.

[Bearbeiten] Datenbank

Oft werden Datenbanken eingesetzt um die Inhalte zu speichern, hier kommen mySQL oder auch PostgreSQL zu Einsatz. Viele Wikis können Ihre Daten aber auch in Textdateien (Dokuwiki, TWiki) speichern. Das hat den Vorteil das keine Datenbankumgebung, mit Sicherheitsrisiken und Administrationsaufwand, benötigt wird und die Dateien im Notfall auch mit einem einfachen Editor gelesen werden können.

Den Performance-Vorteil von Datenbanken kommt in einem abgesteckten Wiki mit Zugriffszahlen von unter 10 Zugriffen pro Sekunde nicht zum tragen.

[Bearbeiten] Add-on

Diese Grundfunktionen genügen aber oft nie allen Ansprüchen dazu ermöglicht es die meiste Software mit Add-on (auch Extensions) eine Erweiterung und Anpassung. Dabei ist darauf zu achten das Add-ons ob und wie Add-ons zukünftige Pläne abdecken, ob es eine ausreichende Unterstützung der Community oder des Herstellers gibt und wie die Möglichkeiten zur Eigenentwicklung bestehen. Vor allem bei Add-ons ist eine reichhaltige Dokumentation sehr wichtig für die Anpassung.

[Bearbeiten] Quellen

1. ↑ http://zungu.net/blog/77/is-what-you-see-what-you-wiki/
2. ↑ kornegger.com - Wiki-Fachvortrag online
3. ↑ Vertrauensbasierte Zusammenarbeit in Enterprise Wikis