Wikis in Organisationen: Anforderungen

Bei der Auswahl einer Wikisoftware sind viele technische und funktionale Anforderungen zu beachten um die richtige Wahl zu treffen.

Je nach Anforderungsprofil des geplanten Wikis, aber auch der Nutzerschaft und deren Organisationsprofil ergeben sich unterschiedliche Schwerpunkte. Braucht ein großer traditioneller Betrieb vermutlich eher strikte Zugangsbeschränkungen und sehr einfache Bearbeitungsmöglichkeit, sucht ein junges Startup eher ein System mit hoher Bearbeitungsgeschwindigkeit, flexiblen Erweiterungen und einfachem mobilen Zugriff.

Leider ist die Entscheidung für die genutzte Software die unflexibelste bei der Einführung eines Wikis und sollte daher gut geplant sein. Denn eine Umstellung der Software ist technisch aufwändig und erfordert immer eine neue Eingewöhnung der Benutzer. Im Gegensatz zu Struktur- und Inhaltsänderungen, die jederzeit möglich sind und sogar das Grundprinzip und Arbeitsweise eines funktionierenden Wikis ausmachen.

Usability

Da ein Wiki von vielen Nutzer aktiv verwendet werden soll, ist die Usability die wichtigste Eigenschaft. Inhalte müssen einfach, logisch und über mehrerer Wege gefunden und erreicht werden können. Änderungen müssen einfach, schnell und ohne Hürden möglich sein.

Die Ladegeschwindigkeit der Seiten an sich und vor allem der Editierfunktion sollte schnell und zügig sein. Auch wenn es hier oft nur um Sekunden oder sogar Millisekunden geht. Ein Nutzer, unter Zeitdruck, der aber dennoch im Wiki etwas nachtragen will, kann von 2-3 Sekunden Ladezeit bereits so demotiviert sein, dass er sich doch wieder der eigentlichen Aufgabe widmet.

Zu viele funktionelle Buttons verwirren den User. Zwar ist eine Versionsgeschichte, eine Bookmarkfunktion oder die Seiten-Umbennenung wichtig, aber das sind Funktionen für erfahrene Nutzer. Der gewillte Wikibeginner muss erst mal nur den Edit-Button finden. Es genügt auch diesen prominent darzustellen.

Die größte Anforderung an die Usability ist die einfache Möglichkeit Inhalte beizutragen.

Beitragen

Ein Wiki ist nur so gut wie die Beiträge seiner Nutzer. Um die Nutzer zum aktuellen und ausführlichen Editieren zu motivieren muss dies einfach und schnell funktionieren.

Die Dokumentation sollte in einem Wiki immer zeitnah nach einer Veränderung oder gleich nach dem Erkenntnisgewinn sein; die guten Vorsätze: nach dem Projekt, nach dem Urlaub oder "wenn mal Zeit ist", bleiben meistens Vorsätze und werden viel zu selten erfüllt. Um aber im Tagesgeschäft noch nebenbei Wiki-Einträge zu erstellen muss dies so schnell und einfach gehen, wie eine Email schreiben.

Textverarbeitung

Die Erweiterung WikiEditor für Mediawiki hilft dem Nutzer die Syntax zu schreiben.

Ein Wiki ist hauptsächlich ein Textmedium. Die Wiki-integrierte Textverarbeitung soll Nutzern eine möglichst einfache Bearbeitung von bestehenden Texten ermöglichen und Änderungen nachvollziehbar darstellen.

Viele Wikis speichern ihre Inhalte in einer vereinfachten Auszeichnungssprache (auch Wiktext, Lightweight Markup Language oder Markup genannt). Dieses Wiki-Markup besteht aus Text und Steuerzeichen die Formatierung und Struktur abbilden.

Dieser sieht so oder ähnlich aus:

== Überschrift ==
Ein '''fettes'''oder ''kursives'' Wort und ein Link auf [https://de.wikipedia.org/wiki/Auszeichnungssprache Wikipedia]

* erster listenpunkt
* zweiter listenpunkt

Es gibt zwei wichtige Gründe warum Wikis Markup einsetzen:

• Änderungen sind exakt nachvollziehbar, da nicht nur Text verglichen werden kann, sondern auch Änderungen in der Struktur und am Format. Werden Struktur und Format versteckt gespeichert, ist es schwieriger dortige Änderungen darzustellen. Ändert beispielsweise ein Nutzer eine 2-rangige Überschrift zu einer 3-rangigen, müsste man diese sprachlich darstellen "Text" von Überschift 2 zu Überschift 3. Im Markup sieht man den Unterschied viel schneller (z.B. == Text == gegen === Text ===).
• dem Text kann eine semantische Struktur geben werden., die vor allem für kollaboratives Arbeiten notwendig ist.

Der Wechsel von der Leseansicht in den Editiermodus verwirrt viele Nutzer. Ist das Dokument lang oder komplex bekommt der Nutzer nach dem Klick auf den Edit-Button, im Gegensatz zu einem Office-Dokument oder Email, eine neue Ansicht in der er sich erst zurecht finden muss. Er verliert die gerade gelesene Textstelle und ist ganz oben auf der Seite und muss erst wieder an die gewünschte Stelle scrollen. Wikis lösen das unterschiedlich :

• Mit der Funktion edit section können einzelne Unterabschnitte einer Seite bearbeitet werden, ohne dass sich der User nach dem klick auf Edit erst im Syntax der ganzen Seite orientieren muss.
• Confluence merkt sich die Stelle an der der Nutzer war und scrollt im Bearbeitungsmodus an die gleiche Stelle.
• Am einfachsten wäre es den angezeigten Text direkt zu bearbeiten, ohne eine neue Ansicht zu laden. Mit HTML5 Content Editable ist dies auch möglich, tiki ist derzeit das einzige Wiki das diese Funktion zur Verfügung stellt. Leider gibt es derzeit keine Umsetzung um auch Formate (Überschiften, Links, Listen, etc) eingeben oder ändern zu können.

Eine weitere und häufig genannte Schwierigkeit ist, dass dieses reine Markup für sehr viele User verwirrend und demotivierend sein kann, da die unterschiedlich formatierten Elemente alle gleich aussehen. Eine Überschrift ist nicht fett und groß, wie in Word, sondern nur mit zwei Gleichheitszeichen (==) gekennzeichnet. So geht für den Nutzer die sichtbare Struktur verloren.

Markdown editor mit einer Toolbar für die wichtigsten Funktionen und gehighlighteten Tags, die bedeutungsgemäß formatiert sind.

Es gibt mehrere Ansätze um hilfebedürftige Nutzer nicht mit dem Syntax und einer großen Textbox ganz allein zu lassen. Hilfsmittel um die sichtbare Struktur wieder anzudeuten und das Bearbeiten zu vereinfachen können sein:

Toolbar

um Textstellen fett oder kursiv zu formatieren, Zeilen zu Überschriften deklarieren oder Links und Bilder mit einem Auswahldialog einzusetzen.

Code Highlighter

stellen weiterhin die ganze Semantik des Markups dar, dennoch sieht der User wie das formatierte Ergebnis aussehen wird.

Oder es wird ein WYSIWYG Editor eingesetzt.

WYSIWYG

Die Extension:FCKeditor für Mediawiki

Der WYSIWYG-Modus ist eine Textdarstellung vergleichbar mit Office Textverarbeitungsprogrammen oder einem E-Mailprogramm. Der Nutzer sieht wie das Dokument aussehen wird wenn es gespeichert ist, daher ist er eine häufige Anforderung seitens der Nutzer. So senken sich die Eingangshürden für Word- und Powerpoint-Nutzer. Tags, Anweisungen an die Software wie der Text aussehen soll, werden vor dem Nutzer versteckt, aber dennoch gespeichert. Die meisten Wikis können mit WYSIWYG-Editoren nachgerüstet werden, bringen diesen von Haus aus mit, wie BlueSpice, oder ermöglichen sogar nur das arbeiten mit WYSIWYG-Editor, wie Confluence.

Die für das Wiki wichtige Änderungsdarstellung ist so schwieriger, da Format- und Semantikänderungen nicht über Tags, sondern grafisch, dargestellt werden müssen. Außerdem verändern viele WYSIWYG-Editoren die Quelltexte weitaus mehr als notwendig oder verfälschen diesen sogar. Es werden teilweises falsche Formate eingesetzt (z.B. Fettschrift und Unterstreichung anstatt Überschrift), Verlinkungen entfernt oder format-entstellende Elemente hinzugefügt. Auch können weder Open-Source- noch kommerzielle WYSIWYG-Editoren die Erwartungshaltung an den Funktionsumfang, im Vergleich zu Office-Programmen, vollständig erfüllen. Um dennoch WYSIWYG-Editoren einsetzen zu können ist es wichtig, dass diese den Inhalt als Markup und nicht als HTML speichern. Nur so ist gewährleistet, dass komplexe Inhaltskonstrukte weiter in Markup verarbeitet werden können.

alternative Lightweight Markup Language

Viele Wikis verwenden eine eigene Syntax, die vor allem HTML vereinfachen wollen, aber nicht nur auf usability optimiert wurden. Es gibt alternative Lightweight Markup Languages, die vor allem unter dem Gesichtspunkt entwickelt wurden für Menschen einfach schreibbar, aber vor allem auch lesbarer zu sein. Beispielsweise muss man in Mediawiki Überschriften am Zeilenende schließen (== Überschrift ==), ein Relikt aus HTML; Markdown benötigt nur ein Zeichen am Zeilenanfang (## Überschrift). Auch wenn der Unterschied klein erscheinen mag, im Schreibfluss ist Markdown schneller und vor allem einfacher zu merken. Weitere empfehlenswerte Lightweight Markup Languages sind reStructuredText und Textile (wird in Redmine genutzt).

Dateien und Medien

Die meisten Wikisysteme können Dateien und Bilder verwalten. Aus Usability Sicht ist ein dialog-geführter Upload und ein durchsuchbares Medienarchiv wichtig. Manche Systeme können Bilder als Drag and Drop annehmen. Meist lässt sich einstellen welche Dateitypen erlaubt sind. Wenige Wikis haben einen Bulkupload, bei dem mehrere Dateien gleichzeitig oder ganze Ordner hoch geladen werden können.

Da Bilder und Videos schwierig sinnvoll kollobarativ verändert werden können, werden diese in einem Wiki nur eingebunden. Allerdings lassen sich diese dennoch versionieren. So können auch Änderungen der Nutzer an Bildern und Videos durch die Gesamtansicht von verschiedenen Versionen nachvollzogen werden.

Bilder sollten skalierbar und direkt in den Wikinhalt und als automatische Gallerie eingebunden werden können.

Tabellen und Charts

Zusätzlich zum Text können Tabellen und Charts die Inhaltsvermittlung erleichtern.

Kleine und auf Darstellung begrenzte Tabellen können mit den meisten Wikisytemen, per Wikitext oder WYSIWYG, erstellt werden. Aufwändige und berechnenden Tabellen, wie sie aus Office Tabellenkalkulationen bekannt sind, sind in Wikis nicht möglich.

Diagramme, mit der Einfachheit von Powerpoint, sind in Wikis ebenfalls nicht möglich. Lediglich Confluence bietet eine browserbasiertes Mockup-Tool. Mediawiki bietet eine Graphviz-Extension, durch die Graphviz-Auszeichnungssprache können Diagramme genauso wie Text gemeinsam erstellt und verändert werden. Allerdings ist die Graphviz-Auszeichnungssprache komplexer als Wikitext und Diagramme können nicht mit der Maus gezeichnet werden, sondern müssen beschrieben werden. Graphviz wird vermutlich nur von technisch affinen Nutzern verwendet werden können.

Ähnlich zu Bildern und Videos können Tabellen und Diagramme als Datei hochgeladen und eingebunden werden, eine gemeinsame Weiterverarbeitung und Änderungsdarstellung wie bei den Wikiinhalten ist nicht möglich. Ein einmal hochgeladenes Powerpointdiagramm kann nur erneut bearbeitet und wieder komplett hochgeladen werden. Externe Dienste können, je nach Datenschutzanforderung, diese Aufgabe auch übernehmen.

Seitenvorlagen

Auch wenn Wikis jedem neuen Artikel ein Anfang auf einem weissen Blatt ermöglichen, gerade bei Inhalten gleicher Art gibt es Strukturen die jede Seite braucht und die dem Nutzer mit einer Grundstruktur helfen alles Relevante beizutragen. Dem Nutzer aber auch ermöglichen aus dieser Struktur wieder auszuscheren. Es macht weniger Sinn existierende Artikel wieder und wieder zu kopieren, da sich so Fehler und Unvollständigkeiten fortsetzen. Vorlagen kann man für Vieles anbieten: Projekte, Besprechungsprotokolle, Blogposts.

Vorlagen können zahlreiche Elemente enthalten:

• die meist genutzten Überschriften (z.B. Verwendung, Zuständigkeit, Historie etc)
• Infoboxen für strukturierte Daten
• Inhaltsvorschläge die nach dem Ausschlussprinzip gelöscht werden und den gewünschten Inhalt hinschreiben (z.B. Projektleiter ist Maria Peter Johanna Hans)

Ordnung

Neben der Speicherung, Veränderung und Darstellung ordnet ein Wiki Informationen und Wissen in seinen jeweiligen Kontext ein. Große Mengen an Informationen und vor allem unterschiedliche Wissensgenres müssen aber in einem Ordnungssystem strukturiert sein. Wikis bieten unterschiedliche technische Ordnungsmöglichkeiten.

Seitentitel und Hyperlinks

Link-Autovervollständigung in einer Dialogbox

Verlinkungen sind ein zentrales Ordnungselement in semantischen Strukturen. Wikis müssen den Nutzer einladen leicht zu verlinken. Links sollten leicht im Textfluss geschrieben werden können. Interne Links werden in den meisten Wikis mit doppelten eckigen Klammern ([[Seitentitel]]) gekennzeichnet. Sinnvolle Hilfsfunktionen ist die Autovervollständigung für Linkziele, entweder als Inlinefunktion im Editor (dieser zeigt nach dem Tippen von [[ mögliche Titel an) oder in einer Dialogbox.

Nicht nur interne Hyperlinks sind wichtig, auch externe Links müssen einfach erzeugt werden können. Bei häufig gebrauchten Zielen, wie verknüpfter Software (CRM, ECM etc), lassen sich Links mit Interwiki links abkürzen. (z.B. [[adresse:Max Huber]] anstatt crm.intra/index.php?id=Max%20Huber)

Zusätzlich können über Backlinks, Links die auf eine Seite verweisen, semantische Informationen gewonnen werden. So kann man einfach sehen welche Projekte einen Prozess nutzen.

Weiterleitungen ermöglichen es Synonyme oder untergliederte Seitentitel auf andere Seiten verweisen zu lassen (z.B. Konferenzraum Main auf Büro Süd). Dies ist wichtig um unterschiedliche gesuchte Begriffe auf einen Inhalt zu verweisen und so Nutzern die mit anderen Begriffen suchen trotzdem den gesuchten Inhalt finden lassen.

Kategorisierung

Kategorien ordnen den Inhalt in logische Gruppen. Dabei gibt es streng hierarchische Kategorisierungen, bei der alle Kategorien immer einer Baumstruktur nach unten folgen müssen, oder matritzenförmige Kategorien, bei der auch Querkategorien angelegt werden können.

Wichtig ist hier 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 zahlreicher werden.

Namensräume oder Spaces

Ein Namensraum (englisch namespace) ist ein Ordnungsystem aus der Software Programmierung, bei dem alle Objekt eindeutig ein einer Verzeichnisstruktur als Baum angeordnet sind. In Wikis sind Namensräume, in Confluence auch Space genannt, Teil des Seitentitels, die jeden Artikel in genau eine hierarchische Unterkategorie einordnen.

Sie sind ähnlich wie Order in einem Dateisystem und erscheinen meist im Seitentitel und der URL (z.B. wiki.example.com/namensraum:seite). Der Namensraum kann je nach Software im Seitentitel und der URL durch ein allgemeines Trennzeichen (: oder /) abgetrennt werden. So ist bei Wikis in Organisationen: Ordnung und Wikis in Organisationen: Kultur der Bereich Wikis in Organisationen der Namensraum. Alle Artikel, die mit diesem beginnen, gehören zu einem Namensraum.

Namensräume können je nach Software unterschiedliche Funktionen ermöglichen:

• An den Namensraum gebundene Zugangsbeschränkungen ermöglichen.
• Links, in Syntax geschrieben ([[Zielseite]]), werden entweder absolut oder relativ zum Namensraum erzeugt. Relativ bedeutet dass der Link [[Zielseite]], innerhalb des Namensraum, auf die Seite Namensraum:Zielseite geht, bei absoluten links führt dieser ganz normal auf die Seite Zielseite.
• Die Kategorisierung mit Tags ist bei manchen Wikis nur innerhalb eines Namensraum möglich
• Namensräume könne auch unterschiedliche Layouts nutzen. Das können andere Seitenstrukturen (z.B. ein- oder zwei-spaltig) sein oder graphische Unterschiede (z.B. andere Hintergrundfarbe).
• Meist kann man die Suchfunktion auf Namensräume einschränken.

Namensräume sollten sparsam und richtig eingesetzt werden.

Transklusionen

B ist in Dokument A transkludiert worden.

Eine Transklusion ist die Funktion, Inhalte anderer Seiten oder einzelner Abschnitte daraus, in eine andere Seite einzubinden. So können Inhaltsbausteine an unterschiedlichen Stellen im Wiki mehrfach wiederverwendet werden. Wird der transkludierte Text aktualisiert, aktualisiert sich automatisch auch die Transklusion in allen Seiten in welchen diese eingebunden ist. Genutzt werden Transklusionen für:

Textbaustein

Textbausteine ermöglichen Kennzeichnungen oder Hinweise. In der Wikipedia z.B. werden so Warnhinweise zu Gesundheitsthemen eingefügt. In einem Organisationswiki können so die verantwortlichen Ansprechpartner einfach in Artikel eingeführt werden.

Infobox

Eine Infoboxen enthält standardisierte Metadaten zu den Artikelinhalten. Bekannt aus vielen Wikipediaartikeln zu Städten, Unternehmen oder Pflanzenarten . In einem Projektwiki kann man so Metadaten, wie Ansprechpartner, Kunde, Zeitraum eines Projekts speichern.

Unternavigation

Eine Unternavigation (wie am Endes dieses Artikels) ermöglicht es dem Leser bei einer zusammenhängenden Gruppe aus Artikeln schnell die Links zu relevanten Nachbarartikeln zu sehen. Infoboxen helfen auch als Einstieg zu einem Themenkreis. Die Anzahl der aufgeführten Artikel soll sich auf maximal 15 beschränken, mehr wird unübersichtlich.

Die so erfassten Inhalte können je nach Wikisoftware aggregiert und als strukturierte Daten dargestellt werden. Teilweise lassen sich Transklusion sogar logisch programmieren (Bedingte Anweisung und Verzweigung in Mediawiki).

Ganze Textabschnitte aus Fließtext sollten nicht in unterschiedlichen anderen Seiten transkludiert werden, da der Leser sonst Inhalte auf unterschiedlichen Seiten wiederfindet und eine eindeutige Zuordnung des Inhalts zu einer eindeutigen Fundstelle nicht möglich ist. Sind Inhalte an unterschiedlichen Stellen relevant, ist es besser diese als eigene Seite auszugliedern und dann auf diese zu verlinken.

strukturierte Daten

Wikis sind primär für semantischen Text gedacht. Dennoch ist es möglich auch strukturierte Daten zu verwalten. Tabellen zur einheitlich und wieder erkennbaren Darstellung strukturierter Daten sind in Wikiartikeln rudimentär möglich. Wenn auch die Funktionalitäten nicht so komplex sind wie in Tabellenkalkulationen (z.B. LibreOffice Calc, MS Excel). Dennoch hat eine Tabelle im Wiki den Vorteil gemeinsam mit mehreren Nutzern bearbeitbar zu sein.

Zusätzlich ermöglichen es Wikisysteme strukturierte Daten zu verknüpfen, zu aggregieren und anderweitig wiederzuverwenden. Es ist möglich Daten aus Artikeln zu sammeln, meist mit Transklusionen und an anderer Stelle konsolidiert einzubinden. Die Daten werden, genau wie Fließtext, innerhalb von Artikeln in einer strukturierten Form (z.B. Tabellen, Transklusionen, Überschriften, Listen) gespeichert. Dies erleichtert dem Nutzer die Eingabe strukturierter Datensätze, die einfach über, unter oder sogar mitten in die Prosainhalten geschrieben werden. Man benötigt kein zusätzliches Backend oder Eingabemaske. Außerdem ist man flexibler beim Hinzufügen von neuen Datenfeldern. Selbst wenn neue, zusätzliche Datenfelder nicht verarbeitet werden, sie können von jedem Nutzer eingepflegt werden, ohne die Software anpassen zu müssen. Die Wiki-Software, ähnlich einer dokumentenorientierte Datenbank, liest diese Daten ein und stellt sie strukturiert, an einer anderen Stelle, dar.

Beispielsweise kann ein Projektwiki eine Projektliste mit Status, Zuständigkeiten, Kontakten, Terminen generieren. Weiterhin hat man den Vorteil jedes Projekt individuell, als Wikiseite, zu beschreiben.

Nicht jede Software bietet die Möglichkeit strukturierte Daten zu verwalten. Die meisten im organisatorischen Umfeld gesetzten Wikis aber schon, wenn auch unterschiedlich ausführlich: Confluence kann Daten aus Tabellen mit einem Makro einbinden. In Mediawiki ist es möglich Daten aus einzelnen Abschnitten, gekennzeichneten Bereichen oder einzelne Werte aus Transklusionen in anderen Seiten wiederzuverwenden. Darüber hinaus gibt es mehrere Möglichkeiten, strukturierte Daten in MediaWiki zu verwalten. Dokuwiki kann Abschnitte anhand von Überschriften gesammelt in anderen Artikeln einbinden.

Darstellung

Die Inhalte eines Wikis werden, wie andere Webseiten, mit einem Browser dargestellt. Weitere mögliche Darstellungsarten sind:

Mobilgeräte

Nicht nur das mobile Internet, sondern auch das mobile Intranet wird immer wichtiger. Außendienstmitarbeiter oder Montagetrupps können wichtige, umfangreiche und aktuelle Information auch ohne Laptop abrufen. Dazu ist eine Darstellung durch Responsive Webdesign oder eine mobile Version möglich.

Drucken

Für normale Büroausdrucke gibt es in allen Wikisystemen eine Druckversion, wie bei Internetseiten auch üblich. Aufwendigere Druckverarbeitungen für Broschüren oder gebunde Bücher sind meist nicht eingebaut. Es gibt aber Möglichkeiten ein Wiki als Text- oder Mediadatenbank eines Desktop Publishing Systems einzubinden. Teilweise können mehrere Seiten in Buchform gebracht werden, um alle oder einzelne Artikel in ein klassisches Buch zu binden (für Handbücher etc.).

Präsentation

Die Inhalte eines können auch vor Gruppen präsentiert werden. Dabei muss man nicht unbedingt alle Inhalte statisch aus dem Wiki in eine Powerpointpräsentation kopieren. Man kann Inhalte direkt aus dem Wiki heraus auf einem Projektor oder einen Gruppenbildschirm vorführen. Teilweise wird S5, ein Präsentationssystem auf der Grundlage von XHTML zur Definition von Präsentation und den dazugehörigen Folien, unterstützt.

Suchen

Um Inhalte ohne genaue Kenntnis des Seitentitels oder der Kategorie zu finden bieten Suchmaschinen die Möglichkeit einer Schlagwortsuche über den gesamten Inhalt, und nicht nur in Seitennamen oder Kategorien. Die mit den Wikis gelieferten Suchmaschinen sind von unterschiedlicher Qualität. Einfache Wikis nutzen nur die einfache Datenbanksuchfunktion, die nur die eigentlichen Wikiinhalte, aber keine Kategorien oder Anhänge durchsucht. Auch beschränken sich diese auf die exakte Schreibweise und geben keine Ergebnisse zu Fehlschreibweisen (ähnlich dem meinten sie aus Google) an, oder ignorieren Wortstämme (Projektleiter oder Projektleiters). Leistungsfähigere Suchfunktionen (z.B. Lucene) finden auch unscharfe Suchanfragen und können den Suchbereich erweitern oder eingrenzen.

Manche Wikisuchmaschinen können zusätzlich auch Text-Medien wie PDF oder Office-Dokumente mit durchsuchen. Wikis können aber auch in externe Enterprise Search-Systeme (z.B. Google Search Appliance‎), sofern vorhanden, eingebunden werden.

Aber auch eine perfekte Suche muss vom Nutzer richtig bedient werden.

Änderungsmanagement

Eine Wiki lebt von seiner Veränderung, doch diese müssen gut überwachbar sein. Dazu ist es wichtig, dass die Software nicht nur mitteilt, dass etwas verändert wurde, sondern auch was. Wichtig bei der genutzten Versionsverwaltung ist es, dass Versionen einzeln miteinander verglichen werden können. Um Nutzer über Änderungen zu benachrichtigen sollte eine interne, persönliche Beobachtungsliste (auch Dashboard genannt) und eine Gesamtübersicht aller Änderungen möglich sein. Zusätzlich müssen Änderungsnachrichten auch per Email oder RSS versendert werden können.

Rollen- und Rechte-Management

Rollenkonzept

Es gibt unterschiedliche Organisationsstrukturen die sich auch im Rollenkonzept eines Wikis widerspiegeln können. Zwar sollte man immer versuchen möglichst einfach und freiheitlich mit den Hierarchien umzugehen, aber manche Organisationen wollen und brauchen speziellere Zugriffsregelungen, um ihre organisatorisches Sicherheitsanforderungen 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 häufigen Änderungen und deren Kontrolle verändert.

Zugriffsseinschränkungen sollten die Ausnahmen sein und es muss vermieden werden das Nutzer nur in wenigen streng zugeordneten Bereichen lesen und schreiben dürfen. Nur so kann man die Zusammenarbeit fördern und die Vorteile einer organisatorischen Transparenz nutzen.

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

Zugang

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

Seite werden einzeln gesperrt

Hier ist die Auswahl der verdeckten Inhalte selektiv. Mit einer einzelnen Sperrung lassen sich wenige, spezielle Seiten mit brisanten Inhalten sperren; eine größere Informationsmenge ist so schwerer zu schützen.

Es werden ganze Namensräume gesperrt

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

Es ist aber zu empfehlen Zugangsbeschränkungen immer auf ganze Namensräume zu legen und darauf zu achten das Sperrung im Namen oder im Layout erkenntlich sind. Bei einer Beschränkung von einzelnen Seiten geht leicht der Überblick verloren. Heißt ein Namensraum Geschäftsleitung ist klar wer darauf Zugriff hat, bei der einzelnen Seite Urlaubsregelung ist das nicht zu erkennen.

Gruppen

Die Nutzer eines Wikis 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 verloren und bremsen die Zusammenarbeit. Am Schluss hat jeder Nutzer seinen eigenen, ausschließlich persönlichen Bereich. Der Vorteil eines Wikis ist gerade, dass man Informationen der des ganzen Teams oder Organisation nutzen und aktiv mitgestalten kann.

Single Sign-on

Single Sign-on ermöglicht es das sich Nutzer an dritten Systemen anmelden und diese Anmeldung im Wiki genutzt wird. Diese Drittsysteme können Intranet-CMS, Active Directory oder LDAP-Anbindungen sein.

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 elementar. 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 Vorteil das Änderungen nah am Zeitgeschehen mit dokumentiert werden können und nicht im Entscheidungs-Rundlauf dahinsterben und sich selbst überholen. Wobei Änderungen im Nachlauf immer noch kontrolliert werden.

Technik

Mandantenfähigkeit

Auch wenn der Vorteil eines Wiki vor allem darin liegen Wissen über Gruppengrenzen hinwege zu erfassen, ist es manchmal manchmal nötig Wikis in Bereiche zu segmentieren. Eine grundsätzliche Segmentierung ist über Namensräume oder Spaces möglich, jedoch stoßen diese je nach Software an Grenzen.

Vor allem im Einsatz bei großen Unternehmen, mit konkurrierenden Profitcentern, werden mehrere getrennte Wikis gebraucht. Anstatt nun mehrere einzelne Instanzen einer Software zu betreiben, kann es sinnvoll sein ein mandantenfähige Wikis einzusetzen.

User können dann so konfiguriert werden nur in bestimmten Mandanten zu lesen, suchen, beobachten oder schreiben. So ist es möglich das je ein eigenes Wiki für viele Abteilungen, Projekte oder Gruppen angeboten wird.

Offline

Auch wenn der Trend zu ständiger Internetverfügbarkeit geht und ein Kollaborations-Tool vom einfachen Zugriff seiner Nutzer lebt, manchmal benötigt man die Inhalte Wiki eines offline. Entweder weil ein Firmenwiki nur im Intranet verfügbar ist und ein VPN-Zugang jedes mal zeitlichen Aufwand erfordert, um etwas nachzuschlagen, oder weil man unterwegs schlechten oder gar keinen Internetempfang hat. Förster, Tiefbauleiter oder Reisende im ICE sind eben nicht always-on.

Dabei stellt sich die Frage, ob es genügt, Inhalte nur nachschlagen zu können, oder ob man diese auch bearbeiten und bei Netzverbindung wieder zusammen fließen lassen will.

Die meisten Wikis ermöglichen es, einzelne Seiten, Teile oder den gesamten Inhalt als PDF- oder HTML-Snapshots zu exportieren. PDFs übernehmen keine Verlinkung, so dass der Offlinenutzer Kontext zu seiner Information selbst suchen muss. Allerdings fehlt bei PDF- oder HTML-Abzügen oft die Haptik und Funktion des Wikis. Ein lokaler Spiegelserver eines Wikis ermöglicht es den Nutzern in gewohnter Weise, sich durch das Wiki zu klicken, aber Änderungen lassen sich nicht in das Original zurück spielen.

Confluence bietet PDF- und HTML-Exporte und die etwas ältere Offline Extension Roadrunner. Mediawiki ermöglicht PDF-Bücher oder auch HTML-Exporte.

Experimentelle Wikis, die git-Repositories als Datenbasis nutzen, können alle Vorteile einer verteilten Versionsverwaltung, wie git, nutzen und können so Inhalte lesen, bearbeiten und haben zahlreiche Möglichkeiten, inhaltliche Konflikte bei der Zusammenführung zu lösen.

Add-on

Die Grundfunktionen genügen oft nicht allen Ansprüchen. Add-ons (auch Extensions) erlauben es Eingabe oder Darstellung zu verändern, zusätzliche Daten zu speichern oder fremde Inhalte einzubinden (z.B. Daten aus einem Personenverzeichnis, Wetter-Information). Es gilt zu beachten, ob es eine ausführlich Dokumentation, ausreichende Unterstützung der Community oder des Herstellers gibt und wie die Möglichkeiten zur Eigenentwicklung bestehen.

Schnittstelle

Über Programmierschnittstellen können Inhalte zur alternativen Nutzung abgefragt werden. Andere Content-Management-Systeme, Kiosklösungen oder Drucksysteme können Inhalte aus einem Wiki weiter nutzen. Auch automatische externe Tools zur automatischen Bearbeitung (z.B. Massenimporte, Umbenennungen, Kategorisierung, etc) werden über Schnittstellen integriert. Schnittstellen bieten Inhalte mindestens in unterschiedlich strukturierten Formaten (z.B. XML, JSON, rohes Markup) an.

Skalierung

Ein grundlegendes System wie ein Wiki muss die Größe und Struktur der Organisation auch abdecken können. Die meisten Technologien mit Datenbanken sind sicherlich standardmäßig für eine Mitgliederanzahl in in den Zehntausenden ausgelegt; aber auch größere Zugriffe sind durch technische Aufrüstung kein Problem. Auch eine örtliche Verteilung ist weltweit, durch das Internet, möglich.

Datenbank

Die meisten Wikisysteme setzen Datenbanken ein um 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.

Zusammenfassung

Aus diesen Einzelpunkten ergibt sich eine ganze Checkliste an Anforderungen. Diese müssen für jedes Organisationswiki, im Rahmen der Einführung, im Hinblick auf das Einsatzgebiet und die Zielgruppe verglichen werden.

Dabei sind die Schwerpunkte je nach Organisation unterschiedlich. Manche Firmen brauchen unbedingt einen leistungsfähigen WYSIWYG-Modus, wollen aber sogar auf eine Wiki eigene Dateiverwaltung verzichten, da keine Konkurrenz zu internen Netzlaufwerken entstehen soll. Manche Startups schreiben fließend Markdown, wollen aber auf jeden Fall eine umfangreiche Darstellung auf Mobilgeräten und Bearbeitungsmöglichkeit auch von Telefonen und Tablets. Ein Sportverein will vielleicht zahlreiche Untersektionen und die Möglichkeit das Wiki auch als öffentliche Webseite zu nutzen, braucht aber kein Single-Sign-On.

Bearbeitung

• Gibt es einen WYSIWYG, oder welcher Wikisyntax (Mediawiki, Markdown) soll genutzt werden.
• Einfache Benutzeroberfläche mit wenigen Buttons.
• Kann man Abschnitte einzeln bearbeiten (edit section).
• Ist der Upload, aber auch die einfache Verwaltung von Dateien möglich.
• Können Hyperlinks im Schreibfluss (link suggestion per Autovervollständigung) oder per Dialog eingefügt werden.
• Können beliebig viele Kategorien oder Tags eingesetzt werden.
• Sind Namensräume einfach anzulegen.
• Können Transklusionen einfach erzeugt und auch mit Variablen bestückt werden.
• Welche Arten an strukturierten Daten sollen verwaltet werden und können diese aggregeriert werden.
• Kann man Tabellen und Charts erzeugen.
• Sind Weiterleitungen von Begriffen auf andere Seiten möglich.
• Gibt es unterschiedliche Seitenvorlagen und wie werden diese aufgerufen.
• Sind Seitentitel eindeutig.

Darstellung

• Ist eine Darstellung auf mobilen Geräten möglich.
• Ist die Ladegeschwindigkeit ausreichend schnell.
• Gibt es eine unscharfe Suche und werden auch Dateien durchsucht.
• Werden Änderungen übersichtlich dargestellt (diff) und wie werden die Nutzer darüber informiert (Email, RSS, Beobachtungsliste, Gesamtliste der Änderungen).

Rollen- und Rechte-Management

• Reichen die Möglichkeiten des Rechte und Rollenkonzept aus.
• Ist ein Single Sign-on an bestehende Usersysteme sinnvoll.
• Wird ein Workflow zur Freigabe von Änderungen gebraucht.

Software

• Welche Add-on gibt es und kann man gegebenenfalls selbst welche entwickeln.
• Auf welche Schnittstelle kann man zugreifen.
• Wie skaliert das Wiki bei mehr Nutzern oder Inhalten.
• Welche Datenbank muss verwendet werden.

Weblinks

• Die Qual der Wiki-Wahl. Wikis für Wissensmanagement in Organisationen