Die Wikipedia bekommt einen WYSIWYG-Editor

Prototyp des Visual Editors für MediaWiki

Eine der grössten Hürden für neue bzw. weniger routinierte Wikipedia-Autoren ist der archaisch anmutende Editor: Wer einen Artikel anlegen oder überarbeiten will, kommt kaum darum herum, sich in Wikitext (wie die spezielle Auszeichnungssprache der MediaWiki-Software heisst) einzuarbeiten. Im Zeitalter von WYSIWYG-Editoren ist das gewöhnungsbedürftig, auch wenn es gute Gründe dafür gibt. Wikitext ist über die Jahre zu einer ziemlich mächtigen Sprache herangewachsen, und entsprechend ist es nicht trivial, dafür einen benutzerfreundlichen und zuverlässigen Editor zu entwickeln. Wer mit WYSIWYG-HTML-Editoren arbeitet, kann dies gut nachvollziehen – auch diese produzieren nicht immer effizienten und fehlerfreien Code und sind zudem nicht immer so bequem in der Anwendung, wie man auf den ersten Blick glauben würde.

Trotzdem hat sich die Wikimedia Foundation an die Entwicklung eines visuellen Editors gewagt, denn die stagnierenden Benutzerzahlen der Wikipedia sind nicht zuletzt auf die zu komplexe Benutzeroberfläche zurückzuführen. Inzwischen ist ein erster Prototyp des Visual Editors verfügbar, der allerdings erst sehr grundlegende Funktionen bereitstellt (und damit noch weniger weit geht als der heutige Wikipedia-Editor):

Toolbar des Visual Editors

In der Visual Editor Sandbox kann man diesen Prototypen gefahrlos testen und Feedback an die Entwickler geben. Bis dieser Editor in der Wikipedia ausgerollt wird, dürfte es allerdings noch mindestens ein halbes Jahr dauern, wie man im Blog der Wikimedia Foundation nachlesen kann. Denn:

“It’s the biggest and most important change to our user experience we’ve ever undertaken.”

ScrewTurn Wiki: Wiki mit WYSIWYG-Editor auf .NET-Basis

Screenshot: Screwturn Wiki mit WYSIWYG Editor

Von den meisten anderen Wikis unterscheidet sich ScrewTurn Wiki zunächst dadurch, dass es auf dem .NET-Framework basiert. Gerade wenn ein Wiki im Unternehmensumfeld eingesetzt werden soll, wo häufig Windows-Server laufen, kann dies ein entscheidendes Kriterium sein. ScrewTurn Wiki benötigt keine Datenbank, sondern legt die Inhalte in Files ab; für Anwendungen mit sehr vielen Zugriffen kann die Speicherung aber auch in einem SQL Server erfolgen. Zudem gibt es eine Desktop Edition, mit der sich ScrewTurn Wiki als persönliches Wiki auf jedem Windows-PC oder –Notebook nutzen lässt (wobei die Desktop Edition leider nicht auf dem neusten Entwicklungsstand ist).

Ein entscheidender Pluspunkt von ScrewTurn Wiki ist der WYSIWYG-Editor: Während man in vielen Wikis eine spezielle Markup-Syntax verwenden muss, die für Wiki-Neulinge und Nicht-Techniker wenig einladend wirkt, bietet ScrewTurn Wiki alternativ auch einen Rich-Text-Editor, wie man ihn von vielen CMS oder Blogs her kennt. Auch der Bildzuschnitt direkt im Web-Interface, die Kommentarfunktion oder der elegante Umgang mit Dateianhängen gehört nicht zum Standard bei Wiki-Software. Wiederum für den Unternehmenseinsatz interessant ist die Möglichkeit, ein Active Directory anzubinden und somit existierende User Accounts zu nutzen. Andere Dinge wie Namespaces, Themes, Versionierung mit Vergleichsdarstellung, Benachrichtigung über E-Mails und eine Plugin-Architektur sind dagegen zwar wichtig, aber wenig überraschend.

ScrewTurn ist unter der GPLv2-Lizenz frei verfügbar. Daneben gibt es auch kommerzielle Lizenzen mit Support durch das italienische Startup Threeplicate, welches ScrewTurn entwickelt.

Issue Tracker in MediaWiki integrieren

Screenshot: IssueTracker Extension für MediaWiki

Wikis und Issue Trackers sind zwei unverzichtbare Werkzeuge, wenn man in einer Gruppe an einer Website oder an einer Software arbeitet. Wer MediaWiki nutzt und keinen Issue Tracker mit allen Schikanen braucht, sollte sich die Extension IssueTracker anschauen: Ist sie einmal installiert, so kann man durch blosses Hinzufügen des Tags <issues /> auf jeder beliebigen Wiki-Seite einen Issue Tracker einfügen.

Pro Issue kann man dann einen Titel, einen Text, einen Typ (konfigurierbar), einen Status (konfigurierbar) sowie den verantwortlichen MediaWiki Users erfassen. Das ist nicht eben viel, reicht aber in der Praxis oft aus. Die Liste der Issues kann nach allen Spalten sortiert, gefiltert und durchsucht werden. Ein bestehender Issue kann editiert oder archiviert werden.

Die Installation der Extension erfordert – wie so oft bei MediaWiki-Extensions – etwas Handarbeit: Die Source Files müssen einzeln heruntergeladen werden, und die erforderliche Datenbanktabelle wird per SQL-Skript angelegt. Sodann sind noch einige Known Bugs zu beheben, die kleine Änderungen an den Source Files erfordern. All dies ist aber gut dokumentiert, und es ist die Mühe wert: Schon oft hätte ich mir eine solche Lösung gewünscht, statt von Hand im Wiki To-do-Listen zu pflegen.

siwiki: Wie man ein Wiki in eine TYPO3-Website integriert

image

Es gibt Situationen, wo man sich nicht zwischen einem Content Management System und einem Wiki entscheiden möchte, sondern beide Funktionalitäten braucht. Statt nun zwei separate Software-Pakete mehr schlecht als recht zu kombinieren kann man auch auf die Extension siwiki zurückgreifen, welche ein einfaches Wiki direkt in eine TYPO3-Website integriert.

Das Interface von siwiki wirkt modern, was es der Yahoo! User Interface Library (YUI) verdankt. Vor allem aber fällt auf, dass der Benutzer keine Wiki-Syntax schreiben muss, sondern einen Rich Text Editor benutzt. Damit ist eine wesentliche Hürde aus dem Weg geräumt, an der viele Wikis scheitern. Andererseits muss man sich natürlich fragen, ob man nicht gleich auf die CMS-Funktionalität zurückgreifen und ganz auf ein Wiki verzichten könnte, zumal TYPO3 ja über einen Frontend Editing Mode verfügt.

image

Ein Wiki lässt typischerweise das Editieren ohne Anmeldung zu und speichert dafür jeden Bearbeitungsschritt, so dass Änderungen nachvollziehbar bleiben. Diesem Konzept ist auch siwiki verpflichtet, und damit ist auch bereits der wesentlichen Unterschied zum traditionellen CMS-Betrieb genannt. Hinzu kommt die einfache Verlinkung (auch auf noch nicht existierende Seiten) sowie die Benachrichtigungsfunktion bei Änderungen an einer Seite. Es gibt also durchaus Gründe, siwiki einzusetzen.

Man darf diese Extension sicher nicht an MediaWiki oder DokuWiki messen. Andererseits erlaubt sie es, innert kurzer Zeit ein benutzerfreundliches Wiki in eine existierende TYPO3-Website zu integrieren. Die Entwickler Stefan Isak und Andreas Lappe haben zudem konkrete Pläne für den weiteren Ausbau – man darf also gespannt sein, was aus diesem Projekt noch wird.

Discussion: Kommentar-Plugin für DokuWiki

 image

Erstmals aufgefallen ist mir das Konzept vor Jahren in der offiziellen PHP-Dokumentation: Unten an der Seite können alle Besucher Anmerkungen anfügen, auch wenn sie für den normalen Seiteninhalt keine Schreibberechtigung haben. Oft findet man dort wertvolle Ergänzungen und Beispiele, an welche die Autoren der Dokumentation nicht gedacht haben.

Discussion ist ein Plug-in für DokuWiki, welches eine vergleichbare Kommentarfunktion bereitstellt. Nun könnte man zwar argumentieren, dass dies in einem Wiki – wo jeder Besucher den normalen Seiteninhalt umschreiben kann – nicht wirklich sinnvoll ist. Drei Gründe sprechen trotzdem für dieses Konzept:

  1. Es gibt Wikis, in denen nur ein beschränkter Kreis von registrierten Benutzern schreiben soll. In diesem Fall kann man die Inputs von Autoren und Besuchern sauber trennen.
  2. Es gibt Besucher, die zwar gerne einen kurzen Kommentar hinterlassen, die sich aber niemals die Mühe machen würden, den Seiteninhalt umzuschreiben (zumal dies Kenntnisse in der Wiki-Syntax verlangt). Das Kommentarformular ist dann eine niederschwellige Möglichkeit, um das Wissen solcher Besucher nutzbar zu machen.
  3. Das MediaWiki (das man von der Wikipedia her kennt) bietet zu jeder Seite eine Diskussionsseite, so dass der eigentliche Inhalt und die Diskussion darüber sauber getrennt sind. DokuWiki bietet keine solchen Diskussionsseiten, aber das Discussion-Plug-in leistet letztlich dasselbe.

Discussion ist eines der populärsten Plug-ins für DokuWiki – zu recht, kann ich da nur sagen.

Nachtrag zum Spam-Schutz (11. Juli 2009)

Kommentarformulare sind ein beliebtes Ziel von Spammern. Damit Ihr Wiki nicht verslumt, sollten Sie entweder Kommentare moderieren (das Plug-in bietet hierzu ein übersichtliches Backend sowie E-Mail-Benachrichtigung) und/oder das CAPTCHA-Plug-in installieren.

Inhalte aus einem MediaWiki als PDF exportieren mit der Collection Extension

image

Schon seit längerem beschäftigt mich die Frage, wie man den Inhalt eines Wikis mit vernünftigem Aufwand und in guter Qualität ausdrucken kann (vgl. Wie druckt man ein MediaWiki aus?). Inzwischen habe ich eine Lösung gefunden, die zumindest in meinem eigenen Setup sehr gut funktioniert.

Der Schlüssel zur Lösung ist die Extension Collection, welche von PediaPress entwickelt wird. Wie bei den meisten MediaWiki-Extensions ist zwar etwas Handarbeit erforderlich, im Prinzip ist die Installation aber nicht schwierig. Die Skripts der Extension kann man als Snapshot herunterladen (richtige MediaWiki-Version auswählen!), anschliessend sind noch einige Einträge in den LocalSettings.php sowie im Skin-File erforderlich. Wenn man das README.txt beachtet, kann eigentlich nichts schiefgehen.

Der Clou an der Sache ist, dass man die Phython-Libraries mwlib und mwlib.rl, welche für das Parsen der Wiki-Seiten und die Konvertierung in ein PDF zuständig sind, nicht unbedingt auf dem eigenen Server installieren muss, sondern dass man den Server von PediaPress benutzen kann. Für Wikis mit beschränktem Traffic reicht dies vollkommen aus.

image In der Anwendung ist Collection sehr elegant: In der Navigation erscheint ein neuer Befehl, mit dem man beliebige Seiten in eine Kollektion aufnehmen kann. Lässt man sich später die Kollektion anzeigen (vgl. obigen Screenshot), so kann man noch die Reihenfolge der Seiten anpassen und Kapitel einfügen. Anschliessend lässt sich aus der gesamten Kollektion ein einziges PDF generieren. Alternativ kann man auch ein Textdokument im OpenOffice.org-Format erzeugen, das man dann nicht nur drucken, sondern ggf. auch noch editieren kann.

Wie druckt man ein MediaWiki aus?

image

MediaWiki eignet sich hervorragend, um im Team-Work Informationen zusammenzutragen, zu strukturieren und zu überarbeiten. Aber was, wenn man das Resultat in Form eines PDFs exportieren oder ausdrucken möchte? Die Frage beschäftigt mich schon länger, und die perfekte Lösung habe ich noch nicht gefunden. Im Moment zeichnen sich zwei Favoriten ab:

  • PDF Book: Diese Extension erlaubt es, alle Seiten einer bestimmten Kategorie in einem einzigen Arbeitsgang als PDF zu exportieren. Dabei wird automatisch ein Inhaltsverzeichnis erstellt, pro Wiki-Seite wird ein Kapitel angelegt. Diese Lösung setzt allerdings voraus, dass HTMLDOC auf dem Server installiert ist.
  • Collection: Bei dieser Extension wird das PDF aus einer sogenannten Collection erstellt. Eine Collection ist vergleichbar mit einer persönlichen Bookmark-Sammlung, die direkt im Wiki abgelegt ist. Auf der Website WikiEducator kann man das in einem öffentlichen Beta-Test selbst ausprobieren. Und wie einer Medienmitteilung der Wikimedia-Foundation vom letzten Dezember zu entnehmen ist, handelt es sich bei dieser Extension um eine Entwicklung, welche strategische Bedeutung für MediaWiki hat und im Verlaufe des Jahres 2008 auch auf Wikipedia eingebaut werden soll. Vielversprechend ist auch die Ankündigung, dass bis Mitte 2008 zusätzlich ein Export im OpenDocument-Format möglich werden soll. Was mich dagegen irritiert ist die Tatsache, dass die Collection-Extension zwei Python-Libraries voraussetzt, während MediaWiki ja in PHP geschrieben ist. Ob diese Lösung auch für einfache Shared-Hosting-Accounts mit LAMP-Umgebung funktioniert?

Neben den beiden erwähnten Extensions gibt es noch eine ganze Reihe anderer Ansätze (vgl. die Liste der alternativen Parser sowie die Data Extracation Extensions), die mir allerdings – aus verschiedensten Gründen – weniger überzeugend scheinen. Gibt es tatsächlich keine Extension, die allein mit den Mitteln von PHP den Export einer ganzen Kategorie im PDF-, OpenDocument- oder RTF-Format erlaubt?

TikiWiki: Definitiv mehr als „nur“ ein Wiki

image

TikiWiki gehört zu den häufig genannten Wiki-Produkten im Open-Source-Umfeld. Es lässt sich auf einem klassischen LAMP-Hosting-Account problemlos installieren, läuft aber auch in einer Microsoft-Umgebung mit IIS und SQL-Server, solange PHP verfügbar ist.

Bereits die Grösse des Downloads (entpackt rund 35 MByte) lässt erahnen, dass TikiWiki ein mächtiges System ist, und der Eindruck bestätigt sich, sobald man sich in den Admin-Bereich einloggt: Die Fülle an Features und ihre Konfigurationsmöglichkeiten ist – je nach dem, was man sucht – beeindruckend bis erschlagend. TikiWiki ist deshalb nur dem Namen nach ein Wiki:

„TikiWiki CMS/Groupware is one of the most feature-rich CMS software packages in the World. Unlike other open source projects that ship only a small set of features and encourage 3rd party Add-ons, the Tiki community has chosen to include a very large number of features in the main code base, which helps to ensures that – unlike other projects – when you upgrade, your features will not get broken. It also permits tight integration of the various features and makes it easier for content re-use.“

Betrachtet man TikiWiki unter dem Aspekt einer Groupware, so ist es sicher gut geeignet, um ein Portal, Intranet oder Extranet für ein Unternehmen, eine Organisation, ein Projekt-Team oder eine Community aufzubauen. Wiki, Blog, Forum, Bugtracker, Bildergalerie, FAQ, Chat, Newsletter, Polls, Web-Mail, Kalender, Aufgabenliste – es gibt kaum eine Funktionalität, die TikiWiki nicht abdecken könnte, und dank einer ausgefeilten Rechtesteuerung kann man den Zugriff auf die einzelnen Bereiche und Funktionen gut regulieren.

Allerdings wirkt die Benutzeroberfläche trotz vieler attraktiver Themes (realisiert über austauschbare CSS Style Sheets und die Smarty Template Engine) ziemlich traditionell und technisch. Wer also eine einfache Lösung sucht, die sich den Benutzern (und den Administratoren) ohne lange Einarbeitung erschliesst, sollte eher nicht zu TikiWiki greifen, das bezüglich Komplexität in der Liga von Drupal, TYPO3 oder eGroupware spielt. Wer den Aufwand nicht scheut erhält mit TikiWiki hingegen ein leistungsfähiges, flexibles und performantes System, hinter dem eine aktive Community steht.

EasyTimeline: Timelines in MediaWiki

image

Für die Visualisierung von zeitgebundenen Fakten bieten sich Zeitleisten (Timelines) an. Von Haus aus hat MediaWiki hier keine Unterstützung zu bieten, aber mit der Extension EasyTimeline kann man Grafiken wie die oben gezeigte per Wiki-Text erstellen und editieren. Diese Methode ist natürlich – wie bei Wikis üblich – relativ technisch und setzt voraus, dass man sich in die Syntax der Extension einarbeitet. Der Aufwand lohnt sich aber, wenn man beispielsweise ein Wiki mit historischen Themen betreibt, einen Projektplan direkt im Wiki pflegen möchte oder (wie oben gezeigt) die Geschichte alle Apple-Macintosh-Computer nachzeichnen will.

Pawfaliki: Das Single Page Wiki

image

Ähnlich wie Onecore, das ein CMS in einem einzigen PHP-File realisiert, ist Pawfaliki ein Wiki in Form eines einzigen PHP-Skripts. Lediglich die Formatierung ist in eine CSS-Datei ausgelagert, die Konfigurationseinstellungen können als separates File gespeichert werden, und die Inhalte werden in einem Verzeichnis abgelegt. Diese Details sind im Hinblick auf Updates und Migrationen eine kluge Entscheidung und tun der Einfachheit des Gesamtkonzepts keinen Abbruch.

Was man mit Pawfaliki bekommt ist an sich ein richtiges Wiki, allerdings mit einer sehr reduzierten Funktionalität. Eine Änderungs-History sowie eine Rollback-Funktion gibt es nur in Ansätzen, eine Volltextsuche ist überhaupt nicht vorhanden, und der Upload von Bildern ist ebenfalls nicht vorgesehen. Auf der anderen Seite sind immerhin Funktionen wie RSS-Feed, E-Mail-Benachrichtigung bei Änderungen, Passwortschutz und IP-Filter vorhanden.

Wenn es darum geht, möglichst schnell eine online editierbare Website ohne grafische Ansprüche aufzusetzen, gibt es fast nichts Einfacheres als Pawfaliki. Man benötigt nicht mehr als ein Hosting-Account mit PHP (eine Datenbank ist nicht erforderlich), einen FTP-Client und 5 Minuten Zeit, um ein Wiki aufzusetzen. Pawfaliki unter liegt der GPL und gibt sich mit PHP 4.3.10 oder neuer zufrieden.

css.php