Eine Wiki-ähnliche Website als Werkzeug für Wissenssammlungen

Was Sie hier sehen ist nicht etwa die Wikipedia oder ein Wiki, das mit MediaWiki, der ziemlich leistungsfähigen Software, die hinter der Wikipedia steht, erstellt wurde, sondern es ist mein persönliches Wiki. Und es besteht aus statischen Seiten, geschrieben in Markdown und herausgeschrieben mit RubyFrontier.

Warum ein persönliches Wiki?

Im Laufe der Zeit sammeln sich bei jedem von uns, also sicher auch bei Ihnen, Informationen an, die man aufheben und vielleicht später einmal verwenden möchte. Klassischer Aufbewahrungsort für solche Wissensschnipsel war früher der Zettelkasten, in dem man auf Karteikarten seine Notizen festhielt und hoffte, sie durch mehr oder weniger vernünftige Schlagworte und Einsortierungen später auch wiederzufinden. Mit dem Aufkommen der Computer wollte man diese Aufgabe natürlich diesem übergeben und hoffte, daß dieser das Wieder- und Auffinden der Informationen einfacher machte. Dabei war die Karteikarten- und Karteikasten-Metapher eine unheimlich starke Metapher, die das Design einiger früher Anwendungen deutlich beeinflußte. HyperCard zum Beispiel, eine frühe, sehr einflußreiche Hypertext/Hypermedia-Software, war direkt von der Metapher des Kartenstapels beeinflußt, nur, daß die Karten untereinander verlinkt werden konnten. Und auch frühe Windows 3.1-Nutzer werden sich sicher noch an das mitgelieferte Progrämmchen erinnern, das direkt einen Karteikasten simulierte.

Ich selber habe diese beiden Programme viel genutzt, um Informationen zu sammeln. Und habe viele gesammelte Informationen verloren, weil es beide Programme so nicht mehr gibt.

Ähnlich verhält es sich mit dem MediaWiki und anderen Wiki-Engines, mit denen Sie sicher eine Wissenssammlung anlegen können. Nur gibt es dabei folgendes zu bedenken:

1. Das MediaWiki speichert seine Daten in einer Datenbank. Dort sind sie erst einmal versenkt und nur das MediaWiki kann sie auch wieder herauslesen. Es ist ein Menge Arbeit erforderlich, wenn Sie dieses in der Datenbank versenkte Wissen in einem anderen Zusammenhang mit einer anderen Software nutzen wollen.
2. Der Aufwand für die Installation und die Betreuung für so ein serverbasiertes Wiki ist beachtlich. Sicherheitsupdates müssen eingespielt werden und die Anforderungen an den Server selber sind auch nicht ohne.

Auf der anderen Seite: Ist solch ein Wiki erst einmal installiert, ist es sehr einfach, dort Dinge hereinzuschreiben und Informationen abzulegen. Daher soll ja auch der Name stammen, WikiWiki ist angeblich hawaiianisch und bedeutet schnell schnell.

Auch ich habe mein Wiki lange Jahre als dynamisches Wiki betrieben. Die dahinter arbeitende Software war ein DokuWiki, eine Wiki-Engine, die ohne Datenbank auskam und alle Informationen in reine Textdateien abspeicherte. Damit war dem Versenken in einer Datenbank schon einmal ein Riegel vorgeschoben. Aber was blieb, war die Abhängigkeit von einem Server.

Und so habe ich mich vor einigen Jahren, nachdem der Server meines Providers mal wieder Ausfallerscheinungen zeigte, entschlossen, mich von dieser Abhängigkeit zu befreien. Ein statisches Wiki ist nicht unbedingt ein Wiki im klassischen Sinne mehr, also eine Anwendung, in der jeder hineinschreiben kann, sondern eben mehr ein persönlicher Zettelkasten. Aber das war ja genau das, was ich mir wünschte.

RubyFrontier trennt scharf zwischen Content, also den Inhalt der Wikiseiten und der Präsentation, also dem ganzen anderen Drumherum, dem Layout und die Navigation, das in das Template gehört. Und so besteht im Endeffekt das gesamte, gesammelte Wissen, das mein Wiki ausmacht, aus einem Bündel reiner Markdown-Dateien, die untereinander allerdings dank des Autoglossary’s von RubyFrontier heftig verlinkt sind.

Aber es sind alles Textdateien, die auf meinem Rechner leben, die ich auch offline schreiben kann und — Markdown ist ja, wie ich schon mehrfach erwähnte, eine Auszeichnungssprache, die auch von anderen Programmen gelesen werden kann — mit denen ich einige anderen Dinge anstellen kann, z.B. ausgewählte Texte nach LaTeX konvertieren oder sie für ein Ebook aufbereiten.

Auf der anderen Seite ist das herausgeschriebe HTML etwas, das ich auf jeden Server meiner Wahl hochladen kann, solange dieser Server in der Lage ist, statisches HTML auszuliefern. Und das ist eigentlich das Mindeste, was ein Webserver können sollte, denn sonst wäre er ziemlich nutzlos.

Desktop-Wiki

Ein weiterer Vorteil eines solchen mit RubyFrontier realisierten Zettelkastens: Niemand zwingt Sie, ihn ins Netz zustellen. Wenn Sie damit zum Beispiel Informationen sammeln, von denen etliche noch dem Urheberrecht unterliegen, dann schreiben Sie Ihr Wiki doch nur auf Ihrem Rechner heraus. Und wenn Sie an mehreren Rechnern arbeiten, nutzen Sie die Dropbox zur Synchronisation. Sie können ja auch die fertigen HTML-Seiten dort ablegen und haben so auf jedem ihrer Rechner Zugriff auf Ihr gesammeltes Wissen.

Laß das mal den Google machen …

Aber natürlich ist ein Wiki ohne Suchfunktion ziemlich nutzlos. Und so dachte ich mir: Wer kann eigentlich am Besten suchen? Die Antwort ist natürlich klar und so habe ich in mein Testwiki eine Google-Suche eingebaut. Das ist ziemlich einfach und kann beispielsweise so aussehen:

<form method="get" action="http://www.google.com/search">
  <input type="hidden" name="as_sitesearch"
  value="cognitiones.kantel-chaos-team.de" />
  (Google-) Suche:<br />
  <input type="text" name="q" size="16" maxlength="255"
  value="" /><br />
 <input type="submit" name="sa" value="Start" />
</form>

Die Idee ist, die Google-Suche auf die Wiki-Domain einzuschränken, eine ähnliche Suche hatte ich auch schon in der statischen Version des Schockwellenreiters implementiert.

Natürlich nützt das nichts, wenn die Seiten nicht auf Googles Index landen. Daher habe ich das mal getestet: Diese Seite zur GLS Bank hatte ich gestern abend geschrieben und hochgeladen und heute früh wird sie schon von Google gefunden. Das sollte für alle praktischen Belange ausreichen.