Vom Austria-Forum zum Wiki-Konzept Masterarbeit

Transcription

Vom Austria-Forum zum Wiki-Konzept
Masterarbeit
an der
Technischen Universität Graz
vorgelegt von
Christoph Trattner
Institut für Informationssysteme und Computer Medien IICM
Technische Universität Graz
A-8010 Graz
Österreich
Jänner 2009
 Copyright 2009, Christoph Trattner
Betreuer:
Dipl.-Ing. Dr.techn. Univ.-Doz. Denis Helic
Kurzfassung
2
Kurzfassung
Auch wenn das Austria-Forum - eine zitierfähige Community-geprägte OnlineEnzyklopädie mit vorwiegend österreichischen Inhalten - ein großartiges Konzept darstellt, um User- und Expertengemeinde hinsichtlich der Erstellung von qualitativ hochwertigen und zitierfähigen Beiträgen in ein und demselben System zu vereinen, so war
dieses auf Grund technischer Probleme nicht so erfolgreich wie erhofft. Die hier vorgestellte Arbeit befasst sich deshalb näher mit der Analyse des zu Grunde liegenden Systems, wobei einige interessante technische Probleme aufgezeigt und diskutiert werden.
Zudem findet eine Reihe von Systemanalysen statt, mit dem Ziel, geeignete Softwarelösungen zu finden, um das Konzept Austria-Forum in technischer Hinsicht besser zu
realisieren. Schlussendlich wird eine Lösung auf Basis eines Wiki-Systems vorgestellt,
mit der es möglich ist, das Konzept Austria-Forum optimal umzusetzen.
Schlagwörter: Austria-Forum, Wiki, JSPWiki, Online-Enzyklopädie
Abstract
Although the Austria-Forum - a citable community-coined online encyclopaedia with
mainly Austrian contents - offers an excellent concept to unite user- and expertcommunities in a common effort to produce high-quality citable contributions in one and
the same system, unfortunately, because of technical limitations, to date, this effort has
not been as successful as it had been expected. This thesis presents first a detailed
analysis of the present system and points out several interesting technical problems,
which are then discussed in greater detail. Furthermore, a number of system analyses
are carried out, in order to find a suitable software solution which would enable a technically better realization of the Austria-Forum concept. Finally, a solution based on a
Wiki system is presented which makes an optimal implementation of the Austria-Forum
concept possible.
Keywords: Austria-Forum, Wiki, JSPWiki, Online encyclopaedia
Inhaltsverzeichnis
3
Inhaltsverzeichnis
Kurzfassung ................................................................................................................2
Abstract .......................................................................................................................2
Inhaltsverzeichnis .......................................................................................................3
Abbildungsverzeichnis ...............................................................................................6
Tabellenverzeichnis ....................................................................................................7
Listingverzeichnis .......................................................................................................7
Danksagung.................................................................................................................9
1
Motivation .......................................................................................................10
2
Ziele.................................................................................................................12
3
Das Austria-Forum .........................................................................................13
3.1
Entstehung .......................................................................................................14
3.2
Klassifizierung ..................................................................................................15
3.3
Technik ............................................................................................................16
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
Funktionsüberblick ...........................................................................................18
Navigation ........................................................................................................18
Browsing und Searching...................................................................................19
Editieren und Erstellen von Beiträgen...............................................................21
Kommunikation.................................................................................................22
Authentifizierung...............................................................................................24
Sonstige Funktionen.........................................................................................24
3.5
Zusammenfassung...........................................................................................25
4
Kritik und Umsetzbarkeitsanalyse ................................................................26
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.1.7
Kritik .................................................................................................................26
Navigation und Browsing..................................................................................26
Suche...............................................................................................................27
Editieren und Erstellen von Beiträgen...............................................................27
Speichern und drucken von Beiträgen..............................................................27
Sicherheit .........................................................................................................28
Community .......................................................................................................28
Popularität ........................................................................................................29
4.2
Weiterentwicklung sinnvoll?..............................................................................30
4.3
Problem- und Umsetzbarkeitsanalyse ..............................................................31
Inhaltsverzeichnis
4
4.3.1
4.3.2
4.3.3
4.3.4
Usability............................................................................................................31
Sicherheit .........................................................................................................35
Community .......................................................................................................36
Popularität ........................................................................................................36
4.4
Fazit .................................................................................................................36
5
Auf der Suche nach einer geeigneten System-Basis...................................37
5.1
Allgemeine Anforderungen ...............................................................................37
5.2
Technische Anforderungen an das neue System .............................................37
5.3
Die Qual der Wahl - Oder vielleicht doch nicht?................................................38
5.4
Wikis ................................................................................................................40
5.4.1 Was ist ein Wiki? ..............................................................................................40
5.4.2 Entstehung und geschichtlicher Hintergrund ....................................................40
5.4.3 WikiWikiWeb - Das erste Wiki und die Popalisierung........................................41
5.4.4 Wiki-Systeme ...................................................................................................44
5.4.5 Typische Wiki-Merkmale ..................................................................................45
5.4.6 Wiki-Technik.....................................................................................................46
5.4.7 Charakteristische Wiki-Funktionen ...................................................................46
5.4.8 Wieso das Wiki-Konzept überhaupt funktioniert................................................51
5.4.9 Wieso Wikis kein HTML verstehen sollten ........................................................53
5.4.10 Typen von Wiki-Systemen und Anwendungsgebiete ........................................54
5.4.11 Vorteile.............................................................................................................56
5.4.12 Nachteile ..........................................................................................................58
5.5
Wikis als Basis für das Austria-Forum einsetzbar? ...........................................61
5.6
Fazit .................................................................................................................63
6
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
Wiki-Systeme im Vergleich ............................................................................64
MediaWiki.........................................................................................................65
FlexWiki............................................................................................................67
JSPWiki............................................................................................................69
TWiki ................................................................................................................71
DokuWiki ..........................................................................................................73
6.2
Anforderungsanalyse........................................................................................75
6.3
Fazit .................................................................................................................79
7
Implementierung ............................................................................................80
7.1
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
7.1.6
JSPWiki Erweiterungsmöglichkeiten.................................................................80
Plugins .............................................................................................................80
Filter .................................................................................................................81
Variablen ..........................................................................................................82
Forms...............................................................................................................83
Editor Modul .....................................................................................................84
Templates und Styles .......................................................................................86
Inhaltsverzeichnis
5
7.1.7 Datastorage......................................................................................................87
7.1.8 Security Modul..................................................................................................90
7.2
Anpassungen und Featureset...........................................................................93
7.2.1 Strukturierung von Daten..................................................................................93
7.2.2 Navigation und Browsing..................................................................................95
7.2.3 Searching .......................................................................................................100
7.2.4 Editieren und Erstellen von Beiträgen.............................................................102
7.2.5 Upload von Dateien........................................................................................103
7.2.6 Das „Info“ Tab ................................................................................................103
7.2.7 Kommunikation...............................................................................................104
7.2.8 Zugriffsrechte .................................................................................................104
7.2.9 Authentifizierung und Profilverwaltung............................................................105
7.2.10 PDF-Export und Drucken von Beiträgen.........................................................106
7.2.11 Sperren/Verbergen von Beiträgen und das Qualitätsgütesiegel......................107
7.2.12 Daten Import ..................................................................................................108
7.2.13 RSS-Feeds.....................................................................................................108
8
Konklusion....................................................................................................109
9
Ausblick ........................................................................................................110
Literatur ...................................................................................................................111
Anhang.....................................................................................................................123
Erklärung .................................................................................................................134
Abbildungsverzeichnis
6
Abbildungsverzeichnis
Abbildung 1: Die Einstiegsseite des Austria-Forums ...................................................14
Abbildung 2: Ajax Modell einer Web-Anwendung, entnommen aus [Garrett 2005] ......16
Abbildung 3: Vergleich zwischen klassischen und Ajax-Modell einer WebAnwendung, entnommen aus [Garrett 2005]....................................................18
Abbildung 4: Suche und Metadatensuche im Austria-Forum .......................................20
Abbildung 5: Das Editor-Modul des Austria-Forums ....................................................23
Abbildung 6: Chatfunktion (Fenster im Vordergrund), Online-Status (Fenster oben)
und integrierte Emailfunktion (Fenster unten)...................................................23
Abbildung 7: Alexa Daily Pageviews für die Domain austria-forum.org, entnommen
aus [Alexa 2009] ..............................................................................................30
Abbildung 8: Links das Kommunikationsschema „One-to-May“ wie es das
Weblogkonzept vorsieht, rechts das Konzept „Many-to-May“, entnommen
aus [Pfister 2006] .............................................................................................40
Abbildung 9: WikiWikiWeb Zugriffsstatistik, entnommen aus [C2 2008b].....................43
Abbildung 10: Aktuelle Besucherstatistiken von wikipedia.org, entnommen aus
[Wikimedia 2008] .............................................................................................44
Abbildung 11: Darstellung einer, Wiki-Seite auf wikipedia.org .....................................48
Abbildung 12: Editorenansicht der in Abbildung 11 dargestellten Seite .......................48
Abbildung 13: Die „Diff“ Funktion des Wikis wikipedia .................................................50
Abbildung 14: Wikipedia Global Traffic Ranking, entnommen aus [Alexa 2009] ..........58
Abbildung 15: Das MediaWiki......................................................................................66
Abbildung 16: Das FlexWiki.........................................................................................68
Abbildung 17: Das JSPWiki.........................................................................................70
Abbildung 18: Das Twiki..............................................................................................73
Abbildung 19: Das DokuWiki .......................................................................................75
Abbildung 20: Der Standardeditor PlainEditor .............................................................85
Abbildung 21: Der WYSIWYG Editor TinyMCE ...........................................................85
Abbildung 22: JSPWiki im WikiMedia Style von Martin Unger, entnommen aus
[JSPWiki 2008] ................................................................................................87
Abbildung 23: Versionsverwaltung des BasicAttachmentProviders auf FilesystemEbene ..............................................................................................................90
Abbildung 24: Ausgabe des List Plugins......................................................................97
Abbildung 25: Ausgabe des GlossaryPlugins ..............................................................98
Abbildung 26: Ausgabe des TabbedGlossaryPlugins ..................................................99
Abbildung 27: Die Ajax basierte Schnellsuche...........................................................101
Abbildung 28: Die Search-Page ................................................................................101
Abbildung 29: Das Tab „Anhänge“ ............................................................................103
Abbildung 30: Das Tab „Info“.....................................................................................104
Abbildung 31: Das Anmeldeformular .........................................................................105
Abbildung 32: Die Profilansicht..................................................................................105
Abbildung 33: Die Druckansicht.................................................................................107
Tabellenverzeichnis
7
Tabellenverzeichnis
Tabelle 1: Prozent der globalen Internet User für die Domain austria-forum.org,
entnommen aus [Alexa 2009]...........................................................................29
Tabelle 2: Alexa Traffic Rank, basierend auf einer kombinierten Berechnung aus
Traffic Rank und Page Views, entnommen aus [Alexa 2009] ...........................29
Tabelle 3: Anzahl der Unique Pages Viewed pro Tag, entnommen aus [Alexa
2009]................................................................................................................29
Tabelle 4: Ergebnisse der Suchmaschinen Google, MSN und Yahoo (Stand
2.1.2009) .........................................................................................................30
Tabelle 5: Seitenanzahlen des WikiWikiWeb in den Jahren 1994 bis 2000,
entnommen aus [C2 2008b].............................................................................42
Tabelle 6: HTML vs. Wiki-Syntax der Wiki-Systeme DokuWiki, JSPWiki und
MediaWiki ........................................................................................................47
Tabelle 7: Vergleich der 5 Wikis MediaWiki, FlexWiki, JSPWiki, TWiki und
DokuWiki .........................................................................................................79
Tabelle 8: JSPWiki CorePages, entnommen aus [JSPWiki 2008] ...............................86
Tabelle 9: Standard Security Policy Einstellungen von JSPWiki, entnommen aus
[JSPWiki 2008] ................................................................................................92
Tabelle 10: JSPWiki-Syntax, entnommen aus [JSPWiki 2008] ..................................102
Listingverzeichnis
Listing 1: Beispielhafter HTML Code für das Erstellen eine und der Selben
Überschrift mit verschiedenen Tag Variationen................................................54
Listing 2: JSPWiki Plugin.............................................................................................81
Listing 3: Das JSPWiki Plugin Interface.......................................................................81
Listing 4: Das PageFilter Interface...............................................................................82
Listing 5: Syntax für JSPWiki Variablen.......................................................................83
Listing 6: Das FormOpen Element...............................................................................83
Listing 7: Das FormClose Element ..............................................................................83
Listing 8: Das FormSet Element ..................................................................................84
Listing 9: Das FormOutpunt Element...........................................................................84
Listing 10: Die Elemente FormSelect, FormTextarea und FormInput ..........................84
Listing 11: Das Interface WikiPageProvider.................................................................87
Listing 12: ACL Syntax ................................................................................................91
Listing 13: ACL Beispiel ..............................................................................................91
Listing 14: URL Codierung ..........................................................................................93
Listing 15: Die angepasste Verzeichnisstruktur des JSPWikis.....................................93
Listing 16: Die Konstanten LEGACY_CHARS_ALLOWED und
PUNCTUATION_CHARS_ALLOWD................................................................94
Listing 17: Die Methoden findPages, getPageCount und getAllPages.........................94
Listing 18: Die Methoden getAllCategoryPages und getTotalPageCount ....................94
Listingverzeichnis
8
Listing 19: Das List Plugin ...........................................................................................95
Listing 20: Das ImageList Plugin .................................................................................95
Listing 21: Ergänzungen für die Methode ListFilter in der Datei filter.xml.....................96
Listing 22: Das Sequenz Plugin...................................................................................96
Listing 23: Das CategoryIndexPlugin...........................................................................97
Listing 24: Das GlossaryPlugin....................................................................................98
Listing 25: Das TabbedGlossaryPlugin........................................................................98
Listing 26: Ergänzungen für das Tag CategoryPath ....................................................99
Listing 27: Das CategoryPath Tag.............................................................................100
Listing 28: Ergänzungen in der Datei web.xml für das Einbinden des Plugins
PDFPlugin......................................................................................................106
Listing 29: Ergänzungen in der Datei ViewTemplate.jsp............................................106
Listing 30: Das AProoved Plugin ...............................................................................107
Danksagung
9
Danksagung
Die hier vorgestellte Diplomarbeit ist am Institut für Informationsverarbeitung und Computer gestützte Neue Medien (IICM) der Technischen Universität Graz im Rahmen einer achtmonatigen Projektmitarbeit - am Austria-Forum - entstanden.
Ich möchte mich an dieser Stelle vor allem bei Herrn O.Univ.-Prof. Dr.Dr.h.c.mult.
Hermann Maurer bedanken, der mir die Möglichkeit geboten hat, mich als Diplomand
in das Projekt einzubringen.
Des Weiteren bedanke ich mich recht herzlich bei meinem Betreuer Dipl.-Ing. Dr.techn.
Univ.-Doz. Denis Helic für die hilfreiche Unterstützung und die zahlreichen Anregungen
während der gesamten Diplomarbeitenzeit.
Frau Ingeborg Schinnerl für das aufopfernde Korrekturlesen dieser Arbeit und vor allem
für die immer wieder aufmunternden Worte. Vielen herzlichen Dank!
Dem Team - Austria-Forum - Christina Fressel, Mag. Dana Kaiser und Katharina Ziegel: Herzlichen Dank!
Meinen besonderen Dank schenke ich meinen Eltern Christine und Leonhard Trattner,
die mir dieses Studium ermöglicht haben. Danke für eure Geduld und dass ihr immer
an mich geglaubt habt.
Darüber hinaus bedanke ich mich bei meinen lieben Geschwistern Alexandra und Stephan.
Zu guter Letzt, ein besondere Dank noch an meine liebe Freundin Uta: Ohne deine
Geduld, deine aufmunternden Worte und vor allem durch deine Liebe, wäre diese Arbeit wohl nicht so schnell entstanden.
1 Motivation
1
10
Motivation
War das Publizieren zu den Anfängen des World Wide Web noch staatlichen Regierungsbehörden, Unterrichtsorganisationen oder Online-Redaktionen vorbehalten, so ist
dies heute anders.
Heutzutage begnügt sich der Internetnutzer nicht mehr mit dem schlichten Browsen
des Internets, sondern sieht sich immer mehr selbst dazu berufen, zum Akteur zu werden. In der Form von Blogs, Wikis oder ähnlichen Web 2.0 Anwendungen werden tagtäglich tausende neue „Publikationen“ von Usern selbst geschaffen. Ein Beispiel hierfür
ist die Online-Enzyklopädie Wikipedia1, mit über 10 Millionen von Usern verfassten
Beiträgen. Doch so brillant das Konzept im ersten Moment möglicherweise erscheinen
mag, so komplex sind auch die Probleme, welche damit einhergehen.
Vor allem hinsichtlich der Qualität der von den Usern verfassten Beiträge können immer wieder gravierende Unterschiede festgestellt werden [Rosenzweig 2006]. Aber
auch Plagiarismus, das „Copy&Paste Syndrom“ oder Copyright-Verletzungen zählen
zu einen der vielen Probleme [vgl. Helic et al. 2008]. Auch hinsichtlich der OnlineRecherche muss gesagt werden, dass der Web 2.0 Hype eher ein Fluch als ein Segen
ist, denn haben solche Websites (siehe Wikipedia) die Eigenschaft besonders hoch im
Ranking der Suchmaschinenbetreiber (siehe Google2) zu stehen [Maurer et al. 2007].
Das Problem dabei: In den meisten Fällen wird davon ausgegangen, dass die Relevanz der gefundenen Beiträge mit der tatsächlichen Qualität des Artikels einhergeht
[Johnson 2005; Haber 2005]. Aber wie schon zuvor beschrieben, trifft diese Vermutung
nicht immer zu.
Doch wie soll diesem Teufelskreis entgegengewirkt werden? Eine mögliche Lösung
wäre, das gesamte Web 2.0 unter redaktionelle Aufsicht zu stellen. Dass dieser Gedanke natürlich nicht in die Tat umgesetzt werden kann, ist klar, denn welche Institution
hätte schon die Mittel, Millionen von Beiträgen Tag für Tag wissenschaftlich zu prüfen,
abgesehen von der Tatsache, dass eine nachträglich eingeführte aufgezwungene Kontrollbehörde in einem sozialen Umfeld, wie dem World Wide Web nicht akzeptiert werden würde.
Was aber durchaus Sinn macht, ist eine Symbiose aus wissenschaftlicher Gemeinde
und Community, in der Beiträge, wenn gewünscht, redaktionell geprüft werden oder
aber als kollaboratives Werk als solches stehen bleiben können, wie es das AustriaForum - eine zitierfähige Online-Enzyklopädie - beweisen soll [vgl. Helic et al. 2008].
1
2
http://www.wikipedia.org
http://www.google.com
1 Motivation
11
Doch so überzeugend dieses Konzept auf den ersten Blick auch erscheinen mag, so
konnte das zu Grunde liegende System wegen technischer Mängel in den letzten zwei
Jahren leider nicht überzeugen.
2 Ziele
2
12
Ziele
Was waren also die Ziele beziehungsweise was sollte im Rahmen dieser Arbeit alles
umgesetzt werden?
Im Rahmen dieser Arbeit solle(n),
•
das Konzept Austria-Forum näher untersucht und verstanden werden.
•
häufige Kritikpunkte im Bezug auf das System schriftlich niedergelegt und diskutiert
werden, ob es sich lohnen würde, das alte System weiter zu entwickeln.
•
darüber nachgedacht werden, welches Konzept sich am Besten dazu eignen würde
eine zitierfähige Online-Enzyklopädie zu erstellen.
•
geeignete Systeme miteinander verglichen werden, um daraus einen „optimalen
Kandidaten“ für weitere Entwicklungen zu finden.
•
das ausgewählte System an die Bedürfnisse des Austria-Forums angepasst werden.
Im Großen und Ganzen formulieren die oben genannten Punkte die fünf großen Ziele
dieser Arbeit.
3 Das Austria-Forum
3
13
Das Austria-Forum
[AF 2008]
Würde man das Austria-Forum3 mit einem Satz beschreiben wollen, so wäre man
höchstwahrscheinlich dazu geneigt den Begriff „Digitale Datenbank mit vorwiegend
österreichischen Inhalten“ zur Beschreibung heranziehen.
Doch wäre diese Bezeichnung wohl etwas unglücklich formuliert, denn hat das Konzept bei Weitem mehr zu bieten, als nur einfache Datensätze zu speichern oder nach
diesen zu suchen.
So wäre die Bezeichnung „Digitale Online-Enzyklopädie“ schon eher passend, denn
bietet das Austria-Forum nicht nur Daten aus einem bestimmten Interessengebiet an,
sondern vereint eine Fülle an Informationen aus bekannten österreichischen Lexika,
Büchern, Bildbänden, Videoarchiven und noch vieles mehr, in einem einzigen System.
Auch wenn nun vielleicht der Vergleich nahe steht, das Konzept mit einem „Brockhaus
Digital“ oder einer „Microsoft Encarta“ in einer Onlineversion vergleichen zu wollen, so
trifft dies, vielleicht in qualitativer Hinsicht und in der Strukturierung der Beiträge zu,
aber mit Sicherheit nicht mit dem Grad der Interaktion zwischen User und System.
So hat jeder User im Austria-Forum die Möglichkeit sich zu registrieren, um Beiträge zu
verfassen beziehungsweise zu kommentieren und über Funktionen wie Forum oder
integriertem Emailsystem mit den Autoren in Kontakt zu treten. Des Weiteren können
Beiträge nicht nur von einzelnen Personen erstellt werden, sondern auch im kollaborativen Miteinander. Auch wenn jetzt vielleicht der Gedanke aufkommen sollte, das System mit dem von Wikipedia vergleichen zu wollen, gibt es doch einige wesentliche Unterschiede.
Kommt bei Wikipedia ein Artikel grundsätzlich nie zur Ruhe oder ist dessen Verfasser
meist unbekannt, so ist dies beim Austria-Forum nicht der Fall.
So können beispielsweise Beiträge von Autoren gesperrt werden, um ein nachhaltiges
Editieren zu verhindern. Des Weiteren ist es möglich, Beiträge von anerkannten österreichischen Interessenvertretern redaktionell prüfen zu lassen. Entsprechen diese den
Kriterien einer wissenschaftlichen Arbeit, so können diese Beiträge - wenn gewünscht in einen geschlossenen Publikationsbereich des Systems übernommen werden. Man
erhält also im Sinne der Wissenschaften zitierfähige Beiträge. [AF 2008]
Das Austria-Forum eine - zitierfähige Community-geprägte Online-Enzyklopädie mit
vorwiegend österreichischen Inhalten - würde das Konzept in einem Satz wohl am Besten beschreiben.
3 Das Austria-Forum
14
Abbildung 1: Die Einstiegsseite des Austria-Forums
3.1
Entstehung
Auch wenn die Implementierung des Systems schon vor gut zwei Jahren stattgefunden
hat, so ist das Konzept Austria-Forum viel älter als man vielleicht annehmen würde.
So wurde schon im Jahr 1996 am Institut für Informationsverarbeitung und Computer
gestützte Neue Medien (IICM) der Technischen Universität Graz ein ähnliches System
entwickelt, das bekannte Kulturinformationssystem AEIOU4.
Wer das System kennt, weiß, dass es sich hierbei um eine Online-Enzyklopädie der
besonderen Art handelt. So wird beispielsweise ein eigenes Videoarchiv der österreichischen Film Geschichte angeboten, in dem einige der ersten Fernsehaufnahmen des
Österreichischen Rundfunks (ORF) in digitaler Form (aufbereitet) zu sehen sind. Aber
auch ein eigenes Musikalbum mit Musikstücken von Beethoven, Mozart, Schubert und
weitere wichtige Vertreter der österreichischen Musikgeschichte, stehen zum Beispiel
in den Formaten MP3 oder WAV zum Download bereit, ganz abgesehen davon, dass
das komplette zweibändige Österreich-Lexikon der Verlagsgemeinschaft ÖsterreichLexikon digitalisiert wurde und im System integriert ist. Alles in allem stehen dem Benutzer zehn Gigabyte an Daten zur Verfügung [AEIOU 2008].
3
4
http://www.austria-forum.org
http://www.aeiou.at
3 Das Austria-Forum
15
Eine Weiterentwicklung des Kulturinformationssystems AEIOU stellte das im Jahr 2006
entwickelte Informationssystem Alexander da. Es wurde von Christian Safran unter der
Leitung von Prof. Hermann Maurer konzipiert und umgesetzt. Anders als bei AEIOU
war es das Ziel, nicht nur hochwertige Datenbestände und Nachschlagewerke
anzubieten, sondern auch zusätzlich noch dem User die Möglichkeit zu geben,
Beiträge zu kommentieren beziehungsweise diese selbständig zu verfassen oder aber
auch Fragen zu stellen, die von Teilnehmern oder Experten beantwortet werden
konnten. [Alexander 2008]
Doch leider musste das Projekt kurz vor dem offiziellen Start ad acta gelegt werden,
obwohl sich die Kombination „aktuelle Informationen“ und „Enzyklopädie - Community“
bewährt hatte. Grund hierfür war, dass ein wichtiger/tragender Partner, der Meyer Verlag, in finanzieller Hinsicht absprang.
Dieser Rückschlag hatte zur Folge, dass eine Neuausrichtung nötig war, welche
schlussendlich Prof. Hermann Maurer zum Gedanken führte, das Austria-Forum in
seiner jetzigen Form entstehen zu lassen.
3.2
Klassifizierung
Auch wenn der Begriff „zitierfähige Community-geprägte Online-Enzyklopädie“ dem
Anwender als Systembeschreibung zur Genüge reichen mag, so ist es auf Entwicklerseite üblich, ein System möglichst genau zu klassifizieren.
Wie schon im Einleitungskapitel beschrieben, handelt es sich beim Austria-Forum um
eine zitierfähige Online-Enzyklopädie mit vorwiegend österreichischen Inhalten.
Ziemlich vereinfacht ausgedrückt könnte auch gesagt werden: Beim Austria-Forum
handelt es sich um ein Internet basiertes (= Web) Informationssystem (= System) mit
vorwiegend österreichischen Inhalten (= Content) [AF 2008].
Fasst man die in der Klammerung definierten Begrifflichkeiten zusammen, so könnte
das System in erster Instanz also auch als Web-Content-System (WCS) klassifiziert
werden.
Da aber der Begriff Web-Content System so dehnbar ist, dass im Grunde jedes System, welches Content im Web anbietet (vgl. Newsgroups, Foren, Webseits, Weblogs,
und so weiter), als solches bezeichnet werden kann, ist es sinnvoll (wenn möglich)
weitere Kriterien zu finden, die eine genauere Klassifizierung zulassen.
Wie schon in der Einleitung zu diesem Kapitel erwähnt, hat jeder User die Möglichkeit
sich am System zu registrieren, um Beiträge zu verfassen beziehungsweise diese zu
bearbeiten (=Erstellung/Bearbeitung), wobei diese von den Autoren gesperrt werden
können, um ein nachhaltiges Editieren zu verhindern. Darüber hinaus ist es möglich,
selbst verfasste Beiträge redaktionell prüfen zu lassen. Entsprechen diese den Kriterien einer wissenschaftlichen Arbeit, so können diese Beiträge, wenn gewünscht, in
3 Das Austria-Forum
einen geschlossenen Publikationsbereich
(=Publikation/Archivierung).
16
des
Systems
übernommen
werden
Laut [Zschau et. al 2001] können die Begrifflichkeiten „Erstellung und Bearbeitung“ von
Beiträgen, „Publikation“ und „Archivierung“ in Summe auch unter dem Begriff Management zusammengefasst werden, was schlussendlich dazu führt, dass das System im
Allgemeinen als Web-Content-Management-System (WCMS) klassifiziert werden kann.
3.3
Technik
Vom technischen Standpunkt aus betrachtet, ist das Austria-Forum ein typischer Vertreter dessen, was man als eine Ajax (asynchronous JavaScript and XML) Webanwendung bezeichnen würde.
Abbildung 2: Ajax Modell einer Web-Anwendung, entnommen aus [Garrett 2005]
Der Unterschied zu herkömmlichen Webanwendungen, wie man sie heute kennt, ist
jener, dass die eigentliche Applikation nicht am Server läuft, sondern zum größten Teil
auf den Client ausgelagert wird. Der Datenaustausch zwischen Client und Server
erfolgt asynchron im Hintergrund über die so genannte XMLHttpRequest API (siehe
Abbildung 2). Der Vorteil hierbei ist, dass nicht wie bei herkömmlichen
Webanwendungen (im klassischen Sinne) eine Seite komplett vom Browser geladen
werden muss, sondern die Kommunikation zwischen Client und Server auf ein
3 Das Austria-Forum
17
Minimum reduziert werden kann, da Datensätze „on-demand“ geladen werden (siehe
Abbildung 3).
Für die Implementierung der Benutzeroberfläche wird die Technologie DHTML, dynamisches HTML oder auch DOM Scripting genannt, zum Einsatz gebracht, um Daten,
welche vom Server geladen werden, zu manipulieren und zu visualisieren.
Serverseitig kommt die Technologie Java Server Pages (JSP) zum Tragen, um
„schwere“ Funktionen wie Suche oder Authentifizierung zu implementieren. Als WebServer wird ein Apache Tomcat5 Server zum Einsatz gebracht.
Die eigentlichen Inhalte der einzelnen Webpages, die so genannten HTML Files, werden am Server zusammen mit den Strukturfiles (.txn Files), welche die Zusammenhänge der einzelnen HTML Seiten widerspiegeln, im herkömmlichen Filesystem abgelegt.
Auch externe Ressourcen wie Bilder, Video- oder Audiodaten werden so gespeichert.
Funktional betrachtet ergibt sich somit folgender Ablauf, um Inhalte vom Server zu laden und am Client zu visualisieren:
•
Zuerst wird die Clientseitige Applikation des Austria-Forums vom Server geladen
und initialisiert.
•
Fordert der User nun eine Seite vom Server an, so wird ein XMLHttpRequest abgesetzt, welcher den Inhalt eines .txn Files anfordert.
•
Das .txn File wird vom Client geparst, die Seitenstruktur wird via DOM erstellt beziehungsweise angepasst, und die HTML Files werden vom Server via
XMLHttpRequest geladen.
•
Die vom Server zur Verfügung gestellten HTML Files werden vom Client via DOM
in die aktuelle Seitenstruktur eingebunden und schlussendlich zur Anzeige gebracht.
5
http://tomcat.apache.org
3 Das Austria-Forum
18
Abbildung 3: Vergleich zwischen klassischen und Ajax-Modell einer Web-Anwendung,
entnommen aus [Garrett 2005]
3.4
Funktionsüberblick
Wie schon in der Einleitung beschrieben, bietet das Austria-Forum eine Reihe von Features an. Um welche speziellen Funktionen es sich hierbei im Konkreten handelt und
welche Möglichkeiten das System dem User im Allgemeinen bietet, soll in weiterer Folge näher erörtert werden.
3.4.1 Navigation
Wie heutzutage üblich, wurde auch beim Austria-Forum daran gedacht, einen zentralen Anlaufpunkt für alle wichtigen Systemfunktionen zu integrieren, die so genannte
„Menu-Bar“ oder auch „Menü-Leiste“. Hier findet der Anwender alle wichtigen Funktionen, wie Hilfestellungen zum System, eine Suchfunktion, eine Druckansicht, einen
3 Das Austria-Forum
19
zentralen Kommunikationsknopf, einen Editierbutton und noch vieles mehr. Die wichtigsten Schaltelemente stellen hierbei die fünf Navigationsknöpfe da, mit deren Hilfe
durch das System „gelenkt“ werden kann, wobei folgende Optionen zur Verfügung stehen:
•
Mit dem nach Rechts ausgelegten Pfeilknöpfen kann der User ebenenweise wie bei einer Slideshow - einzelne Kategorien nach vorne durchlaufen. Der einfach ausgeführte Pfeil-Button ermöglicht dabei das schrittweise Durchwandern,
wohingegen der mit einem senkrechten Strich ausgeführte an das Ende einer
Kategorie springen lässt.
•
Die nach links ausgelegten Pfeilknöpfe bieten im Grunde die gleichen Funktionalitäten an, nur mit dem Unterschied, dass diese ein Zurücklaufen einer Artikel-Serie ermöglichen.
•
Das fünfte und letzte Navigationselement, der „Zurück“-Button, musste auf
Grund technischer Gegebenheiten eingefügt werden, da, wie aus AjaxSystemen bekannt, ein herkömmliches Zurücknavigieren über die BrowserHistory nicht möglich ist [vgl. Amikelive 2008]. Der „Zurück“-Knopf implementiert
im Wesentlichen, wie schon angedeutet, die Funktionalität des Browser-Buttons
„Back“.
3.4.2 Browsing und Searching
Um Informationen im System zu finden stehen dem User zwei wesentliche Möglichkeiten offen und zwar die des Browsings und die des Searchings, wobei die Begrifflichkeiten wie folgt definiert werden [Guetl 2008]:
•
Unter Searching versteht man ein explizites Informationsbedürfnis, welches durch
die Formulierungen einer Suchanfrage (Query) zu einer Ergebnisliste oder auch
Suchliste führt.
•
Unter Browsing versteht man das Stöbern oder Durchsuchen von Dokumenten. Die
Ergebnisliste entsteht hierbei nicht durch ein explizites Informationsbedürfnis oder
eine konkrete Suchanfrage, wie dies beim Searching der Fall ist.
Entscheidet man sich für die Methodik des Stöberns und Durchsuchens, so bietet das
Austria-Forum vier wesentliche Konzepte an [vgl. Guetl 2008]:
•
Die des Flat-Browsings, um Folgen von Beiträgen nacheinander in einer bestimmten Reihenfolge zu durchsuchen.
•
Das Konzept des Structure-Guided-Browsings, welches über die Möglichkeit der
Darstellung von Dokumenten und Kategorien in einer hierarchischen Baumstruktur
realisiert wurde und dem User zur Verfügung steht.
•
Die des Hypertext-Browsings, welches durch die Möglichkeit der Verlinkung von
einzelnen Beiträgen bewerkstelligt wurde.
3 Das Austria-Forum
•
20
Die des Tabbed-Browsings, wobei diese Funktion mit der unter dem Begriff bekannten Technik nicht viel gemeinsam hat, denn unterscheiden sich diese deutlich:
So wird im Austria-Forum diese Funktion dazu verwendet, um Unterverzeichnisse
in Registerkarten darzustellen und nicht, wie bei der herkömmlichen Methode üblich, einzelne Browser-Fenster.
Abbildung 4: Suche und Metadatensuche im Austria-Forum
Des Weiteren steht dem User, wie schon zuvor angedeutet, die Möglichkeit offen auch
dezidiert nach Informationen zu suchen. Insgesamt kommen sieben Suchparadigmen
zum Einsatz, welche wie folgt lauten:
•
Die klassische Volltextsuche, bei der der User einen Suchquery definiert, um Dokumenteninhalte auf das Vorkommen dieses Querys hin zu untersuchen (matchen),
und sich diese entsprechend der Ähnlichkeit zum definierten Query ausgeben lässt.
Zudem kann vom User definiert werden, ob diese auf den ganzen Datenbestand
des Austria-Forums anzuwenden ist, oder strukturiert, auf einen eingeschränkten
Datenbestand.
•
Eine weitere Option, welche im Austria-Forum implementiert wurde, sind die Methodiken der so genannten Titel-, Themen und Keyword-Suche wo versucht wird
,den vom User definierten Query auf diese Bereiche der Dokumente zu beschränken.
•
Des Weiteren findet man auch die Möglichkeit der so genannten Ähnlichkeitssuche
vor, bei der ein gerade betrachtetes Dokument über dessen Titel mit anderen Do-
3 Das Austria-Forum
21
kumenten auch über dessen Titel und Schlüsselwörter verglichen werden kann um
zu einem Suchergebnis zu führen.
•
Eine andere Methodik, welche vielleicht noch nicht so bekannt ist, stellen die so
genannten Such-Links dar. So ist es beispielsweise möglich, einzelne Wörter als
herkömmlichen Links auszuweisen, um auf der Grundlage derer, eine Schlüsselwortbasierte Suche durchzuführen.
•
Darüber hinaus wurde auch das Prinzip des Ajaxbasierten Suchfilterkonzeptes umgesetzt. So können beispielsweise Themen lokal oder auch global mit einem vom
User verfassten Query an Hand des Titels gefiltert werden. Aber auch in einigen
Alben wird dieses Prinzip angewandt, um die Fülle an Informationen besser visualisieren zu können.
•
Eine interessante Option hinsichtlich der Suche ist die im System integrierte Funktion „Geo-Search“. Beiträge, welche hinsichtlich einer geographischen Positionsangabe „getaggt“ wurden, können im System über eine geographische Suche gefunden werden. Die Resultatsanzeige erfolgt hierbei direkt in einer von Microsoft Virtual World erzeugten Map.
•
Die letzte Methodik, welche an dieser Stelle noch genannt werden soll, ist die MetaDaten Suche. Ähnlich der Keyword-Suche wird der vom User verfasste Query hier
mit dem Meta-Daten-Schema einzelner Beiträge oder Kategorien gematched. Da
sich die Meta-Daten von Kategorie zu Kategorie unterscheiden können, wird auch
zusätzlich noch das Paradigma des Meta-Daten getriebenen Ajax basierten Suchfilterkonzeptes angeboten, um durch die Formulierung eines Query in den MetaDaten Feldern an Informationen zu gelangen.
3.4.3 Editieren und Erstellen von Beiträgen
Wie schon in der Einleitung zu diesem Kapitel beschrieben, beschränkt sich das System nicht nur auf das schlichte Anbieten von Informationen, sondern ermöglicht es,
selbst zum Akteur zu werden. Für diesen Zweck steht dem User ein multifunktionales
Editiermodul zur Verfügung, welches in der Menu-Bar als eigenes Schaltelement mit
der Aufschrift „Bearbeiten“ zur Verfügung gestellt wird. Multifunktional deshalb, weil
damit nicht nur Beiträge erstellt oder bearbeitet werden können, sondern auch Beiträge
verschoben, Hyperlinks erstellt oder Bilddaten auf den Server geladen werden.
Um nun einen Artikel erstellen zu können beziehungsweise diesen zu editieren, steht
dem User ein Editoren-Modul zur Verfügung, welches folgende Komponenten in sich
vereint:
•
Ein „Titel“-Feld, um einem Dokument einen entsprechenden Namen geben zu können
3 Das Austria-Forum
22
•
Ein „Schlüsselwort“-Feld, um den Inhalt eines Dokumentes mit einer Folge von
Wörtern näher zu beschreiben
•
Eine „Textarea“, um Seiteninhalte mit Hilfe der Textaufzeichnungssprache HTML
zu definieren, wobei auch Scriptsprachen wie JavaScript oder Cascading Style
Sheets (CCS) zulässig sind
•
Ein „Drag&Drop“ Feld, mit dessen Hilfe eine Folge von Daten auf den Server geladen werden kann
•
Vier „Checkboxen“, um Beiträge hinsichtlich der Themenliste, Reihenfolge, Nachfolgebeiträgen oder Verlängerung zu sperren
•
Ein „Drop-Down“ Menü mit der Möglichkeit, enthaltene Themen in einer Seite zu
editieren
•
Zwei Eingabefelder mit der Option „lat“ und „lng“ um einen Beitrag mit geographische Längen- und Breitenangaben zu „taggen“
•
Und natürlich die zwei Funktionsknöpfe, um einen Beitrag via „OK“ zu speichern
oder mittels „Abbrechen“ das Erstellen oder Bearbeiten dessen zu verwerfen
3.4.4 Kommunikation
Wie schon in der Einleitung erwähnt, stehen dem User eine Reihe von Kommunikationskanälen zur Verfügung, welche wie folgt lauten:
•
Im System wurde ein Instant-Messenger integriert, welcher es erlaubt, sich über
das System mittels Kurznachrichten zu unterhalten.
•
Des Weiteren zu finden ist eine Chat-Funktion, um mit mehreren Usern gleichzeitig
zu kommunizieren.
•
Darüber hinaus bietet das System ein integriertes Emailsystem an. Die Kommunikation erfolgt hierbei über den Benutzernamen, was den Vorteil hat, dass Nachrichten ohne Preisgabe der Identität und Emailadresse verschickt werden können.
•
Eine für die Qualitätssteigerung der Beiträge wichtige Funktion ist die Möglichkeit,
Artikel kommentieren zu können, weshalb auch diese Option dem User im AustriaForum zur Verfügung steht. Die Kommentare werden hierbei dem Beitrag angehängt und können somit zusammen mit dem Artikel auf einer Seite zusammengefasst angezeigt werden.
•
Das letzte Werkzeug, welches in die Rubrik der Kommunikationstools fällt, ist ein
integrierter Blog Server, auf dem User eigene Blogs anlegen können um Beiträge
den Interessengebieten entsprechend zu verfassen und der Community zugänglich
zu machen.
3 Das Austria-Forum
23
Abbildung 5: Das Editor-Modul des Austria-Forums
Abbildung 6: Chatfunktion (Fenster im Vordergrund), Online-Status (Fenster oben) und
integrierte Emailfunktion (Fenster unten)
3 Das Austria-Forum
24
3.4.5 Authentifizierung
Da es sich beim Austria-Forum um ein geschlossenes System handelt, in dem nur registrierte Benutzer Beiträge verfassen und kommentieren oder miteinander kommunizieren können, werden folgende Konzepte zum Einsatz gebracht, um den Anforderungen gerecht zu werden:
•
So findet prinzipiell jeder User einen „Registrierungs“-Button vor, um sich via Benutzername und Emailadresse am System zu registrieren. Das Passwort wird hierbei per Email verschickt.
•
Die Authentifizierung erfolgt über den Funktionsknopf „Anmelden“.
•
Des Weiteren bietet das Austria-Forum dem Benutzer die Möglichkeit an ein Profil
mit zusätzlichen persönlichen Daten wie Vor- und Zuname, Homepage-Adresse,
Organisation, Persönliche Beschreibung, Bild und so weiter zu definieren.
•
Darüber hinaus können User eigene Benutzergruppen definieren und andere dazu
einladen, diesen beizutreten, was den Vorteil mit sich bringt, sich von anderen Mitglieder abzugrenzen um beispielsweise via Chatfunktion miteinander zu kommunizieren oder auch Kategorien unabhängig von anderen Usern gemeinsam zu nutzen.
3.4.6 Sonstige Funktionen
Abgesehen von den schon zuvor erwähnten Funktionen, implementiert das AustriaForum eine Reihe von zusätzlichen Features, welche an dieser Stelle kurz vorgestellt
werden sollen:
•
Neues: Über den Menüpunkt „Neues“ stehen dem User eine Reihe von Übersichtsseiten zur Verfügung um beispielsweise über aktuelle Änderungen im System informiert zu werden.
•
Druck: Über den Menüpunkt Druck ist es möglich eine Druckansicht vom gewünschten Artikel unabhängig vom Seiten-Template zu erzeugen.
•
Lesezeichen: Des Weiteren wird ein eigener Lesenzeichenmanager angeboten, mit
dem systeminterne Seiten unabhängig vom Browser gespeichert werden können.
•
RSS-Feeds: Einzelne Themen oder auch das ganze System können als RSS-Feed
(Version 2.0) abonnieren werden.
•
Bewertung: Die letzte hier zu nennende Funktion ist die Möglichkeit, Beiträge bewerten zu können. Diese Funktion steht, wie das Kommentieren von Beiträgen,
dem User auf jeder Seite im System zur Verfügung.
3 Das Austria-Forum
3.5
25
Zusammenfassung
Beim Austria-Forum handelt es sich um eine zitierfähige Community-geprägte OnlineEnzyklopädie mit vielen Erweiterungen wie sie heute nicht in jedem herkömmlichen
Web-Content-Management-Systemen zu finden sind. So stechen neben hochwertigen,
mit Meta-Daten versehenen, kategorisierten Artikeln vor allem auch Module wie ein
integriertes Emailsystem, Blog- und Chatfunktion, sowie ein integrierter Lesezeichenmanager oder ein RSS-Dienst unter Anderem hervor. Ein interessantes Konzept, wenn
es darum geht, Community und Online-Enzyklopädie miteinander zu vereinen.
4 Kritik und Umsetzbarkeitsanalyse
4
26
Kritik und Umsetzbarkeitsanalyse
Auch wenn das Konzept Austria-Forum durchwegs positives Feedback erntet, so konnten in den zwei Jahren, in denen das System nun im Betrieb ist, auch einige kritische
Punkte evaluiert werden. In dem hier folgenden Kapitel sollen diese näher beschrieben
und diskutiert werden.
4.1
Kritik
Wie schon zuvor angedeutet, wurde das System in einigen speziellen Punkten des
Öfteren kritisiert. Im Rahmen dieser Diplomarbeit wurde das System deshalb einigen
Analysen unterzogen. Unter Anderem wurde das Editoren-Team des Austria-Forums
gebeten, Probleme im Umgang mit dem System in Rahmen der wöchentlich stattfindenden Besprechung bekannt zu geben. Die folgenden Kapitel fassen die vom Editoren-Team und vom Autor dieser Arbeit am meisten kritisierten Punkte zusammen.
4.1.1 Navigation und Browsing
Bezug nehmend auf die Navigation wurden folgende Punkte des Öfteren von den Editoren kritisiert:
•
(P1.1) Menüleiste: Wie schon in Kapitel 3.3.2 erwähnt, ist für das Navigieren durch
die einzelnen Artikel und Kategorien eine eigene Navigationsleiste implementiert.
Betrachtet man die funktionale Zuordnung der Knöpfe mit deren Symbolen näher,
so muss gesagt werden, dass diese auf den Benutzer verwirrend wirken. Vor allem
wurde der einfach ausgeführte Pfeil-Zurück-Knopf des Öfteren mit dem Browserbutton „Back“ verwechselt.
•
(P1.2) Back/Forward-Button-Problem: Ein weiterer kritischer Punkt, welcher angemerkt wurde, ist die Tatsache, dass ein Browser initiiertes Zurück- oder Vorwärtslaufen nicht möglich ist.
•
(P1.3) Links: Darüber hinaus wurde auch mehrmals angemerkt, dass Hyperlinks
nicht als solche im System ersichtlich sind. Vor allem das Nichtunterstreichen und
das Verwenden der sonst untypischen Farbe Rot wurden hierbei als Grunde genannt.
•
(P1.4) Zu tiefe Hierarchien: Einige User beschwerten sich, dass Informationen zu
tief im System versteckt sind.
27
4.1.2 Suche
Hinsichtlich der Suche konnten folgende Dinge festgestellt werden:
•
(P2.1) Heterogenität: Wie aus Kapitel 3.3.3 ersichtlich, integriert das System eine
Reihe von unterschiedlichen Such-Paradigmen. Vor allem die große Anzahl an verschiedenen Möglichkeiten der Suche irritierte einige User.
•
(P2.2) Globale-Suche: Des Weiteren kam es bei der globalen Suche des Öfteren
zu Ärgernissen, da standardmäßig keine Volltext- sondern eine Keyword- und Titelbasierte Suche vom System durchgeführt wird.
•
(P2.3) Volltextsuche: Die Suchanwendung stürzte ab, wenn Stoppwörter wie „der,
die, das“ verwendet wurden.
Bezüglich des Editierens von Beiträgen wurden folgende Punkte von den Editoren kritisiert:
•
(P3.1) Fenstergröße: Insbesondere wurde die Fenstergröße des Editors als zu
klein angesehen. Vor allem die nicht vorhandene Möglichkeit, dieses zu vergrößern, war ein häufiger Kritikpunkt bei der Beitragserstellung.
•
(P3.2) HTML-Syntax: Einige Editoren beklagten den mühevollen Umgang mit
HTML als Textaufzeichnungssprache. Vor allem wurde die syntaktische Handhabe
teilweise nicht richtig verstanden, weshalb das Erlernen der Syntax von der tatsächlichen Arbeit abhielt.
•
(P3.3) Verschieben von Beiträgen: Zudem wurde die nicht vorhandene Option zum
globalen Verschieben von Beiträgen als Kritikpunkt genannt. Es musste für diese
Tätigkeit immer ein Systemadministrator herangezogen werden, was das flüssige
Arbeiten mit dem System beeinträchtigte.
•
(P3.4) Verbergen von Beiträgen: Als sehr unangenehm wurde die nicht vorhandene
Möglichkeit zum Verbergen von Beiträgen angesehen. So gab es vor allem das
Problem, dass nicht fertig gestellte Beiträge von der Community kritisiert wurden,
diese aber nicht verborgen werden konnten.
•
(P3.5) Upload von Bildern: Es wurde darüber geklagt, dass die Drag&Drop Funktion zum Upload von Bildern nicht immer funktioniert, da eine JAVA Laufzeitumgebung nicht installiert war.
4.1.4 Speichern und drucken von Beiträgen
Zuzüglich zu den bereits erwähnten Mängeln wurden auch noch folgende Punkte kritisiert:
28
•
(P5.1) Speichern von Seiten: Einige User beschwerten sich, dass über die Browser-Funktion „Datei/Speichern Unter“ ein Abspeichern einzelner Artikel nicht möglich ist.
•
(P5.3) Druck: Zu guter Letzt wurde noch darauf hingewiesen, dass ein Drucken
über den Menüpunkt „Druckansicht“ nicht möglich ist.
4.1.5 Sicherheit
Hinsichtlich der Systemsicherheit mussten folgende Punkte festgestellt werden:
•
(P4.1) Überschreiben von Beiträgen: Im System existiert kein LockingMechanismus um Beiträge davor zu schützen gleichzeitig von mehreren Benutzen
bearbeitet zu werden.
•
(P4.2) Überschreiben von Bildern: Des Weiteren können auch Bilder über die Funktion Drag&Drop von anderen Benutzern überschrieben werden.
•
(P4.3) Keine Verschlüsselung von Userdaten: Userdaten wie Passwörter, EmailAdresse und so weiter werden im System in Plain-Text abgelegt. Obwohl sich der
Betreiber des Austria-Forums dazu verpflichtet hat diese zu schützen so können
diese Daten von jeder Server-berechtigten Person eingesehen oder sogar verändern werden.
•
(P4.4) Keine Skriptfilterung im HTML-Editor: Über den HTML-Editor ist es möglich
auch JavaScripte mit auf den Server zu speichern. Es ist einem Angreifer also beispielsweise möglich ein Script auf den Server zu laden, um gegebenenfalls sensible Daten unter dem Deckmantel des Austria-Forums vom Benutzer zu erbitten.
4.1.6 Community
Zuzüglich zur Usability wurde die Community-Ausprägung des Systems untersucht.
Wichtige Kriterien hierfür waren:
•
Die Anzahl der erstellten Accounts
•
Die Anzahl der von der Community erstellten Beiträge
•
Das Nutzen der Community-spezifischen Funktionen wie Chat, Blogging und
Kommentare
Folgende Punkte konnten dabei festgestellt werden (Stand: 20.12.2008):
•
Insgesamt wurden seit dem Bestehen des Systems 292 Accounts angelegt
•
95% aller Beiträge wurden von bezahlten Editoren verfasst
•
Vier Prozent aller Beiträge wurden von externen Editoren verfasst
•
Ein Prozent der Beiträge wurden von der Community verfasst
29
•
Die Chat Funktion wurde nie genutzt
•
Das Blog System wurde von insgesamt drei Usern genutzt
4.1.7 Popularität
Zusätzlich wurde das System hinsichtlich seiner Popularität untersucht. Als AnalyseTools kamen hierbei der Webinformationsdienst Alexa6 und die drei Suchmaschinen
Google, MSN7 und Yahoo8 zum Einsatz.
Der Webinformationsdienst Alexa lieferte für die Domain austria-forum.org folgende
Ergebnisse (Stand: 2.1.2009):
Tabelle 1: Prozent der globalen Internet User für die Domain austria-forum.org, entnommen aus [Alexa 2009]
Yesterday
1 wk. Avg.
3 mos. Avg.
3 mos. Change
n/a
--
0.000024%
↓ 4%
Tabelle 2: Alexa Traffic Rank, basierend auf einer kombinierten Berechnung aus Traffic
Rank und Page Views, entnommen aus [Alexa 2009]
Yesterday
1 wk. Avg.
3 mos. Avg.
3 mos. Change
n/a
--
2,562,866
150,882
Tabelle 3: Anzahl der Unique Pages Viewed pro Tag, entnommen aus [Alexa 2009]
Yesterday
1 wk. Avg.
3 mos. Avg.
3 mos. Change
n/a
--
1,6
↓ 10%
Des Weiteren bietet Alexa die Möglichkeit an, eine Domain hinsichtlich eingehender
Hyperlinks zu untersuchen. Für die Domain austria-forum.org konnten laut [Alexa 2009]
sieben Websites gefunden werden, deren Hyperlinkstrukturen Verweise auf das Austria-Forum enthielten.
6
http://www.alexa.com
http://www.msn.com
8
http://www.yahoo.com
7
30
Abbildung 7: Alexa Daily Pageviews für die Domain austria-forum.org, entnommen aus
[Alexa 2009]
Tabelle 4: Ergebnisse der Suchmaschinen Google, MSN und Yahoo (Stand 2.1.2009)
Suchmaschine
Anzahl an unterschiedlichen Websites in
denen der Suchbegriff „austria-forum.org“
auftaucht.
Indizierte Seiten der Domain
„austria-forum.org“
Google
40
150
MSN
33
n/a
Yahoo
43
n/a
4.2
Weiterentwicklung sinnvoll?
Auch wenn das Konzept Austria-Forum überzeugen mag, so muss hinsichtlich der
technischen Realisierung des Systems doch einiges an Kritik ausgesprochen werden.
Vor allem hinsichtlich der Usability, eines der wohl mit Abstand wichtigsten Kriterien,
wenn es darum geht ein erfolgreiches System zu schaffen [Andrews 2008; Nielson et
al. 2001; Zerfaß und Zimmermann 2004], muss gesagt werden, dass das System nicht
gerade ein Vorzeigeobjekt ist.
So wird beispielsweise ein eigenes Navigationsmenü implementiert, um „besseres“
Browsen durch die einzelnen Beitragshierarchien zu gewährleisten. Doch wie in Kapitel
4.1 gezeigt, kommt es vor allem hinsichtlich der funktionalen Zuordnung der einzelnen
Navigationsknöpfe zu Problemen beim User.
31
Aber auch hinsichtlich der Suche ist anzumerken, dass das System nicht überzeugen
kann. Vor allem der exzessive Einsatz unterschiedlicher Suchparadigmen verwirrte
mehr, als dadurch etwas leichter gefunden werden konnte.
Ein weiterer kritischer Punkt sind die vielen technischen Mängel des Systems. So werden Beiträge nicht gesperrt, wenn diese von mehreren Usern gleichzeitig bearbeitet
werden. Auch das Anbieten einer nicht funktionierten Druckfunktion, die Unmöglichkeit,
Artikel speichern zu können oder die nicht vorhandene Option Beiträge zu verschieben
beweisen, dass das System leider nicht sehr praktikabel ist, wie die allgemein schwache Community-Ausprägung beweist.
Die Frage, welche sich nun aufdrängt ist, in wie weit es Sinn macht, das bestehende
System weiter zu entwickeln.
4.3
Problem- und Umsetzbarkeitsanalyse
Um die in Kapitel 4.2 aufgeworfene Frage „in wie weit es Sinn macht, das bestehende
System weiter zu entwickeln“ zu beantworten, ist es zweckdienlich, das System hinsichtlich der in Kapitel 4.1 geäußerten Kritikpunkte näher zu analysieren, Lösungsvorschläge zu machen und darüber zu diskutieren, in wie weit diese umgesetzt werden
können.
In den hier folgenden Kapiteln sollen nun eine Analyse hinsichtlich der von den Usern
geäußerten und allgemein kritisierten Punkte vorgenommen werden.
4.3.1 Usability
Menüleiste und Back/Forward-Button-Problem
Problem:
P2.1 + P2.2
Lösungsvorschlag:
Das Vor- und Rückwärtsnavigieren sollte über die jeweiligen
Browser-Buttons möglich gemacht werden [Dué et al. 2008]
Die Navigationspfeile sollten deshalb aus dem System entfernt werden. Für das Navigieren durch eine Sequenz wäre
es sinnvoll ein gutes Pagination-Konzept zu implementieren
(siehe beispielsweise smashingmagazin.com9)
Umsetzbarkeit:
Schwer/Unmöglich
Diskussion:
Zwar ist das Ajax Back-Button Problem vom technischen
Standpunkt aus schon seit geraumer Zeit gelöst [vgl. Stenhouse 2005; Neuberg 2005], doch wird dieser Hotfix leider
nicht von jedem Browser unterstützt, weshalb gesagt wer-
9
http://www.smashingmagazine.com/2007/11/16/pagination-gallery-examples-and-goodpractices/
32
den muss, dass dieses Problem nur schwer oder gar nicht
gelöst werden kann
Links
Problem:
P3.3
Lösungsvorschlag:
Links sollten dahingehend angepasst werden, dass diese
als solche ersichtlich sind. Klassischerweise unterstrichen
und in der Farbe blau gehalten, wäre eine gute Lösung für
dieses Problem [Nielsen 2004]
Umsetzbarkeit:
Leicht
Diskussion:
Die Umsetzung dieses Vorschlages kann als relativ „leicht“
umsetzbar eingestuft werden, da das Einführen eines globalen Styles für das Anker-Tag dieses Problem lösen würde
(siehe beispielsweise w3c.org10)
Tiefe Hierarchien
Problem:
P1.4
Lösungsvorschlag:
Ein „Ausflachen“ und Zusammenfassen von Hierarchien
wäre ein möglicher Lösungsvorschlag für dieses Problem
Umsetzbarkeit:
Schwierig
Diskussion:
Auf Grund der in Kapitel 4.1 geäußerten Probleme hinsichtlich des Verschiebens von Beiträgen könnte sich dieses
Unterfangen als eher schwierig erweisen. Was die interne
und externe Link-Konsistenz anbelangt, so muss gesagt
werden, dass die Problemlösung auch eher schwer umzusetzen ist, da auf Grund der Hypertexttechnologie keine
100% Möglichkeit besteht, herauszufinden welche externen
Verweise auf einzelne Artikel bestehen
Heterogenität und Globale Suche
Problem:
P2.1+P2.2
Lösungsvorschlag:
Es sollte versucht werden die verschiedenen Such Paradigmen auf ein Minimum zu reduzieren. Ein guter Lösungsvorschlag wäre ein einheitliches Suchfeld im Menübereich.
[Nielsen 1997] Darüber hinaus sollte standardmäßig die
Volltextsuche aktiv sein
10
http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes
Umsetzbarkeit:
Leicht
Diskussion:
Siehe beispielsweise w3c.org11
33
Volltextsuche
Problem:
P2.3
Lösung:
Implementierung eines Stoppwortfilters
Umsetzbarkeit:
Mittel
Diskussion:
Beispiele hierfür sind auf onjava.com12 oder apache.org13 zu
finden
Fenstergröße und Fenster allgemein
Problem:
P3.1 + P5.2
Lösung:
Den DHTML Fensterkomponenten sollten Funktionen wie
„Drag&Drop“ oder „Resize“ hinzugefügt werden oder aber
auf Window-Komponenten verzichtet und eine neue Seite
mit dessen Inhalt zur Anzeige gebracht werden
Umsetzbarkeit:
Mittel
Diskussion:
Ein möglicher Lösungsvorschlag für dieses Problem kann
auf dynamicdrive.com14 gefunden werden
HTML Syntax
Problem:
P3.2
Lösungsvorschlag:
Einführen einer simplen Syntax
Eingabe-Templates
X2HTML Konverter
Umsetzbarkeit:
Mittel
Diskussion:
Das Einführen einer simplen Syntax, Eingabe-Templates
oder Konvertierroutinen würde dieses Problem mit Sicherheit minimieren. Da dazu einige Lösungsvorschläge auf
google.com existieren, siehe Internetforen- oder Wikisyntax
oder Word2HTML Konverter, ist das eigentliche Problem
nur mehr in der Implementierung zu sehen
11
http://www.w3.org/TR/html401/interact/forms.html
http://www.onjava.com/pub/a/onjava/2003/01/15/lucene.html?page=2
13
http://hudson.zones.apache.org/hudson/job/Lucenetrunk/javadoc/org/apache/lucene/analysis/StopFilter.html
14
http://www.dynamicdrive.com/dynamicindex8/dhtmlwindow/
12
34
Verschieben von Beiträgen
Problem:
P3.3
Lösungsvorschlag:
Das zur Verfügung stellen eines globalen DHTML-Baumes
mit der Möglichkeit, Artikel via Drag&Drop zu verschieben,
wäre ein Lösungsansatz für dieses Problem
Umsetzbarkeit:
Mittel
Diskussion:
Auf dhtmlx.com15 findet man beispielsweise eine Ajax basierte Lösung, welche diese Idee umsetzt
Verstecken von Beiträgen
Problem:
P3.4
Lösungsvorschlag:
Die Implementierung eines Hide/Show Buttons würde dieses Problem beheben
Umsetzbarkeit:
Mittel
Diskussion:
Im Grunde dürfte diese Funktion mit mittlerem Aufwand zu
realisieren sein
Speichern von Seiten
Problem:
P5.1
Lösungsvorschlag:
Verzicht auf Frames und Einschränkung hinsichtlich des
exzessiven Einsatzes von DHTML [Nielsen 1996]
Umsetzbarkeit:
Unmöglich
Diskussion:
Um diesen Lösungsvorschlag umzusetzen, müsste das
System vom technischen Standpunkt aus betrachtet komplett überarbeitet werden. Der hier beschriebene Kritikpunkt
zählt zu einem der Hauptprobleme bei der Umsetzung von
AJAX Anwendungen
Druck
Problem:
P5.3
Lösungsvorschlag:
Es wäre sinnvoll den Print-View nicht über das Document
Object Model anzubieten, da diese Funktion von einigen
Browsern (beispielsweise Mozilla Firefox) nicht unterstützt
wird. Stattdessen wäre ein nativer Print-View denkbar
Umsetzbarkeit:
15
Leicht
http://www.dhtmlx.com/docs/products/dhtmlxTree/index.shtml
Diskussion:
35
Da der Seitencode nativ in .htm Dateien vorliegt (siehe Kapitel 3.3) würde eine Referenz auf diese genügen um das
Problem zu beheben
4.3.2 Sicherheit
Upload und Überschreiben von Bildern
Problem:
P3.5+P4.2
Lösungsvorschlag:
Ein Verzicht dieser Funktion wäre sinnvoll
Umsetzbarkeit:
Leicht
Diskussion:
-
Überschreiben von Beiträgen
Problem:
P4.1
Lösungsvorschlag:
Implementierung eines Locking-Mechanismus
Umsetzbarkeit:
Mittel
Diskussion:
Auf sun.com16 ist beispielsweise eine Lösung für dieses
Problem zu finden
Keine Verschlüsselung von Userdaten
Problem:
P4.3
Lösungsvorschlag:
Implementierung einer Verschlüsselungsfunktion
Umsetzbarkeit:
Mittel
Diskussion:
Siehe beispielsweise jasypt.org17
Keine Skript Filterung im HTML-Editor
Problem:
P4.4
Lösungsvorschlag:
Es wäre besser, die Eingabe von HTML ganz zu unterbinden oder einen geeigneten HTML und Javascriptfilter zu
implementieren
Umsetzbarkeit:
Mittel
Diskussion:
Siehe beispielsweise java2s.com18
16
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileLock.html
http://www.jasypt.org/howtoencryptuserpasswords.html
18
http://www.java2s.com/Code/Java/Servlets/HTMLfilterutilit y.htm
17
36
4.3.3 Community
Problem:
P6
Lösungsvorschlag:
Die Community sollte integraler Bestandteil des Systems
werden:
Behebung der technischen Mängel sowie Steigerung der
Usability
Community Bereich auf das ganze System ausweiten
Es sollten bessere Möglichkeiten des kollaborativen Arbeitens angeboten werden
Umsetzbarkeit:
Schwierig
Diskussion:
Um dieses Konzept umzusetzen, wären Funktionen wie
Revisionskontrolle, Diff-Funktion, Access Control Listen und
so weiter nötig
4.3.4 Popularität
Problem:
P7
Lösungsvorschlag:
Verzicht auf Frames und DHTML
Umsetzbarkeit:
Unmöglich
Diskussion:
Um diesen Lösungsvorschlag umzusetzen, müsste das
System vom technischen Standpunkt aus betrachtet komplett überarbeitet werden.
4.4
Fazit
Auch wenn drei der in Kapitel 4.1 vorgestellten Probleme „leicht“ behoben werden
könnten, so konnten dennoch neun „mittelmäßig schwer“ zu lösende, drei „schwer“ zu
lösende und drei „unlösbare“ Probleme festgestellt werden.
Vor allem in architektonischer Hinsicht kann keine befriedigende Lösung gefunden
werden, um beispielsweise die Usability bezüglich der Navigation über alle Browserversionen hinweg zu steigern oder das Problem „Abspeichern von Seiten“ zu lösen.
Aber auch der Kritikpunkt Popularität kann auf Grund der zuvor geschilderten Gegebenheiten nicht gelöst werden, da es durch den exzessiven Einsatz von Frames und
DHTML den jeweiligen Suchmaschinen verwehrt bleibt Seiteninhalte zu indizieren.
Da das System hinsichtlich dieser Kritikpunkte nicht überarbeitet werden kann, es zuzüglich eine Reihe von nur schwer und mittelmäßig schwer zu lösenden Problemen
gibt, muss daher vorgeschlagen werden, das System von Grund auf zu überarbeiten.
5 Auf der Suche nach einer geeigneten System-Basis
5
37
Auf der Suche nach einer geeigneten System-Basis
Wie schon in Kapitel 4 beschrieben, wurde das System hinsichtlich einer Reihe von
Problemen kritisiert. Vor allem bezüglich des Kriteriums Usability konnten einige
schwerwiegende Mängel festgestellt werden. Aber auch hinsichtlich der Punkte Sicherheit, Community und Popularität erwies sich das System als nicht hinreichend erfolgreich, weshalb auch festgestellt wurde, dieses von Grund auf zu überarbeiten.
Dieses Kapitel befasst sich deshalb neben dem Definieren der neuen Systemanforderungen vor allem mit der Frage, welches Konzept sich am Besten eignen würde, das
Austria-Forum in technischer Hinsicht zu realisieren.
5.1
Allgemeine Anforderungen
In Anbetracht der in Kapitel 4 geäußerten Probleme können die allgemeinen Anforderungen an die neue Software-Lösung wie folgt definiert werden:
Das System sollte,
•
frei verfügbar sein (OpenSource)
•
benutzerfreundlich sein
•
die Community als integralen Bestandteil ansehen
•
Suchmethoden Volltext- oder Keywordsuche unterstützen
•
einfache Methodiken zur Content Erstellung anbieten (z.B.: WYSIWYG Editor,
simple Syntax, Eingabe-Templates und so weiter)
•
kollaboratives Arbeiten ermöglichen und damit einhergehende wichtige Methodiken
unterstützen (Revisionskontrolle, Diff-Funktion)
•
ein User Management- und Control-Modul zur Verfügung stellen
•
eine flexible Art der Kategorisierung anbieten
•
Drucken und Speichern von Beiträgen ermöglichen
5.2
Technische Anforderungen an das neue System
Die technischen Anforderungen können wie folgt definiert werden:
•
OpenSource: Das System sollte auf eine Open Source Software Lösung aufgebaut
werden.
38
•
Authentifizierung/Userverwaltung: Das System sollte ein Authentifizierungs- und
Userwaltungsmechanismus bereitstellen.
•
Zugriffskontrolle: Das System sollte dezidierte Zugriffskontrollmechanismen anbieten.
•
Strukturierung von Beiträgen: Beiträge sollen vom System in strukturierter Form
dem User angeboten werden können. Ein Kategorisierungssystem wäre wünschenswert.
•
Suche: Das System sollte dem User die Möglichkeit offerieren, einfache und komplexe Suchanfragen zu generieren.
•
Kommentare und Foren: Das System sollte eine Foren- und Kommentarfunktion
beinhalten.
•
XHTML/CSS/PDF Ouput und RSS-Feeds: Das System sollte Standardausgabeformate wie XHTML 1.0/CSS und PDF beherrschen. Des Weiteren sollte einen
RSS-Dienst inkludieren.
•
Mediasupport: Das System sollte einen ausgeprägten Mediensupport (Video/Audio)
anbieten.
•
Conflict Handling: Das System sollte einen Conflict Handling Mechanismus beinhalten.
•
Revison Control: Das System sollte einen Revision Control Mechanismus beinhalten.
•
Einfache Syntax: Das System sollte eine einfache Eingabesyntax beziehungsweise
Methodiken welche diesem Konzept nahe kommen zur Verfügung stellen.
5.3
Die Qual der Wahl - Oder vielleicht doch nicht?
Begibt man sich auf die Suche nach einem geeigneten System, um das Konzept Austria-Forum in technischer Hinsicht zu realisieren, so stellt man fest, dass es im Grunde
keine „eins zu eins“ Lösung gibt. Was es aber gibt, ist eine schier unüberschaubare
Fülle an Softwarelösungen im Bereich der Web-Content-Management-Systeme
(WCMS).
So können beispielsweise auf der bekannten CMS Website CMSMatrix19 über 1020
WCM Systeme gefunden werden. Aber auch populäre Directory-Dienste wie das
Google-Verzeichnis20 mit über 460 Einträgen oder DMOZ21 mit fast 440 Einträgen bieten nicht gerade weniger Auswahl an.
19
20
http://www.cmsmatrix.org
http://directory.google.com
39
Laut Bob Doyle [Doyle 2008] werden mittlerweile annähernd über 1700 Web-ContentManagement-Systeme auf dem Softwaremarkt [Doyle 2005] angeboten.
Somit ist es also ratsam, Einschränkungen zu treffen, um die Auswahlmenge weiter zu
minimieren.
Wie schon in Kapitel 5.1 beschrieben, soll das neue System vor allem auch den Aspekt
der Community mit abdecken. Die Softwarelösung kann also auch als Community-Web
Content-Management-System klassifiziert werden.
Hinsichtlich dieses Kriteriums gestaltet sich die Suche schon ein wenig einfacher, denn
fallen insgesamt nur mehr drei Systeme in diesen speziellen Klassifikationsbereich
[Baumgartner 2005]:
•
Weblog-Systeme
•
Community-Content-Collaboration-Management-Systeme (C3MS)
•
Wiki-Systeme
Doch welches der drei Systeme eignet sich am Besten für die Umsetzung des neuen
Systems? Um die Antwort vorweg zu nehmen, Weblog-Systeme und CommunityContent-Collaboration-Management-Systeme eignen sich nicht dafür und zwar aus
folgenden Gründen:
Anders als beim Austria-Forum, wo die Content-Erstellung auf einer gemeinschaftlichen Ebene stattfindet (kollaborativ), fördern Weblogs die individuelle ContentErstellung. Weblogs arbeiten also nach dem Kommunikationsschema „One-to-Many“
wohingegen das Austria-Forum vorsieht, das Konzept „Many-to-Many“ zu unterstützen.
Genau aus diesem Grund muss aber gesagt werden, dass der Weblog leider als geeignetes Konzept für die technische Realisierung des neuen Austria-Forums auszuschließen ist. [vgl. Aigner et al. 2007]
Bei den Community-Content-Collaboration-Management-Systemen würde man annehmen, dass die Entscheidungsfindung abgeschlossen sein müsste, denn erfüllen
diese Systeme im Grunde alle gewünschten Anforderungen [vgl. Baumgartner 2005].
Doch musste festgestellt werden, dass es entweder nur teure, nicht frei verfügbare
Lösungen in diesem Bereich gibt (siehe beispielsweise reddiXL22) oder unausgereifte
Portalsoftwarelösungen (siehe beispielsweise PHP-Nuke23 oder PostNuke24) welche in
technischer und sicherheitsrelevanter Hinsicht den Anforderungen nicht gerecht werden können [vgl. Valeur et al. 2005; Ferner 2004].
21
http://www.dmoz.org
http://reddi.digi-info.de/reddiXL/downloads_reddi/reddi_kurz.pdf
23
http://phpnuke.org
24
http://support.pn-cms.de
22
40
Somit bleibt also die Frage offen, inwieweit Wiki-Systeme den Anforderungen gerecht
werden können.
Abbildung 8: Links das Kommunikationsschema „One-to-May“ wie es das Weblogkonzept vorsieht, rechts das Konzept „Many-to-May“, entnommen aus [Pfister 2006]
5.4
Wikis
Wie sich in Kapitel 5.3 herausgestellt hat, eignen sich Weblog-Systeme und Community-Content-Collaboration-Management-Systeme nicht für die technische Umsetzung
des Konzeptes Austria-Forum, weshalb zu untersuchen ist, inwieweit sich das WikiKonzept als Basis für die technische Realisierung des Systems eignet.
5.4.1 Was ist ein Wiki?
wi·ki / wikē/ • n. a Web site that allows collaborative editing of its content and structure
by its users. [OPDCE 2008]
„A wiki is a freely extandable collection of interlinked Web pages, a hypertext system
for storing and modifying information - a database, where each page is easily editable
by any user with a forms-capable Web browser client.“ [Leuf und Cunningham 2001]
„A wiki is a collaborative Webspace where anyone can add content and anyone can
edit content that has already been published.” [Richardson 2008]
5.4.2 Entstehung und geschichtlicher Hintergrund
Streng geschichtlich betrachtet könnte man sagen, dass die ersten Ideen zum heutigen
Wiki-Konzept, schon lange vor dem eigentlichen Aufkommen des Wiki-Phänomens im
Jahr 1985 entstanden sind. So wurde in den Jahren 1972-1985 an der Carnergie Mellon Universität ein Konzept entwickelt, welches in gewisser Weise einem Wiki sehr
ähnlich war. Das Konzept, bekannt unter den Namen ZOG, war die erste Datenbank
die für mehrere Benutzer ausgelegt war und die Möglichkeit bot, über ein Interface bestehend aus einem Text-Frame (Wiki-Pages) (in dem Titel, Beschreibung und eine
41
Kommandozeile angezeigt wurde) andere Text Frames miteinander zu verlinken. [C2
2008a]
In den Jahren darauf wurde das ZOG Datenbanksystem von den beiden Programmierern Robert Akscyn und Donald McCracker erweitert. Das System - bekannt unter den
Namen Knowledge Management System (KMS) - war das erste kollaborative System,
welches auf direkte Änderungen der Benutzer reagierte, zusätzlich noch Grafiken und
Bilder in einem Frame anzeigte und für das Verfolgen von Links einen Browser implementierte. [Akscyn et al. 1987]
Im Jahr 1985 entwickelte Janet H. Walker, basierend auf den vorangegangenen Arbeiten am ZOG Projekt, den so genannten „Document Examiner“, welcher dazu verwendet wurde um Computeranleitungen darzustellen [Walker 1987].
Im Jahr 1987 übernahm die Firma Xerox diese Idee und entwickelte daraus das so
genannte Note Cards System, um Informationen kombiniert mit einem eigenen Browser und einem Navigationsfenster in scrollbaren Bildschirmfenstern darzustellen. Inspiriert von Xerox’ Idee übernahm dann kurz darauf auch die Firma Apple dieses Konzept
und entwickelte ihrerseits wiederum daraus das so genannte HyperCard System, welches laut Cunningham ihm als Grundlage für die Entwicklung des ersten Wiki-Systems
diente. [Leuf und Cunningham 2001; C2 2008a]
5.4.3 WikiWikiWeb - Das erste Wiki und die Popalisierung
Das erste Wiki-System wurde im Jahr 1994 von Ward Cunningham entwickelt und
diente in seinen Anfängen als Plattform zum schnellen Austausch von Informationen im
Bereich des Softwaredesigns. Genannt wurde das System WikiWikiWeb, was sich aus
dem Hawaianischen ableiten lässt und so viel heißt wie „Sehr schnelles Web“, in Anlehnung daran, dass Cunningham ein „schnelles“ System zum gegenseitigen Austausch von Informationen haben wollte. Der Einfachheit halber nannte Cunningham
sein System dann schlichtweg „Wiki“, da ihm WikiWikiWeb zu umständlich erschien
[Ebersbach et al. 2007].
Da sich um die Begriffsbildung beziehungsweise dessen Herkunft ein regelrechter Kult
entwickelt hat und es noch immer viele Fehlinterpretationen zu geben scheint, sei an
dieser Stelle ein Ausschnitt aus einem Briefverkehr zwischen Cunningham und Patrick
Taylor, Mitarbeiter der Firma Dictionary Department Trade & Reference Division, dargeboten, wo erklärt wird, wie es zur Namensgebung gekommen war.
„[...] Wiki wiki is the first Hawai’ian term I learned on my first visit to the islands. The
airport counter agent directed me to take the wiki wiki bus between terminals. I said
what? He explained that wiki wiki meant quick. I was to find the quick bus. I did pick up
a book about the language before my return home. I learned many things from this but
wiki wiki is the word that sticks the most. [...] I thought „wiki wiki web“ was more fun to
say than „quick web“, no mater what pronunciation is used. The name „quick web“
42
would have been appropriate for a system that makes web pages quickly. Microsoft’s
„quick basic“ was a precedent for such a name. I chose to call the technology WikiWikiWeb. I used exactly this spacing and capitalization because the technology would
then recognize the term as a hyperlink. I consider WikiWikiWeb to be the proper name
of the concept, of which Wiki or wiki is an abbreviation.” [Cunningham 2003]
Am 16. März 1995 war es dann fast so weit. Cunningham sandte eine Email an einen
Freund mit Namen Steve mit folgendem Inhalt:
„Steve - ich habe eine neue Datenbank auf meinem Web-Server installiert und bitte
Dich, mal einen Blick darauf zu werfen. Es ist ein Web von Menschen, Projekten und
Mustern, auf das man über ein cgi-bin-Skript zugreifen kann. Es bietet die Möglichkeit,
ohne HTML-Kenntnisse mit Formularen Text zu editieren. Es wäre schön, wenn Du
mitmachen oder wenigstens Deinen Namen in der Liste der RecentVisitors eintragen
könntest. Die URL ist http://c2.com/cgi-bin/wiki - danke schön und beste Grüße.“
[Moeller 2003a]
Am 1. Mai 1995 sandte Cunningham eine Reihe von weiteren Emails an Freunde und
Bekannte aus der ihm so geliebten Programm Pattern Szene um diese von seinem
Projekt zu begeistern [Moeller 2003a]. Und in der Tat, das Projekt war erfolgreich und
zwar so erfolgreich, dass das WikiWikiWeb zur begehrtesten Adresse im Internet
wurde, wenn es um das Thema Programm Patterns ging (siehe Tabelle 5 und
Abbildung 9).
Tabelle 5: Seitenanzahlen des WikiWikiWeb in den Jahren 1994 bis 2000, entnommen
aus [C2 2008b]
Datum
Seitenanzahl
Web
Nov 29 1994
-
Dec 15 1995
2426
Dec 1 1996
5134
Dec 31 1997
10600
Mar 25 1998
14554
Dec 2 2000
62919
WikiWiki-
So richtig populär wurde das Konzept WikiWikiWeb aber erst einige Jahre danach
durch einen glücklichen Zufall. Das Unternehmen US-amerikanische Unternehmen
Bomis hatte in den Jahren 1999 und 2000 die Idee, eine Enzyklopädie auf der Basis
des World Wide Web zu entwickelt. Das Projekt, welches unter den Namen Nupidia
bekannt wurde, war in seinen Anfängen aber nur mäßig erfolgreich, denn es wurde ein
umständliches Experten Review System eingesetzt, was zur Folge hatte, dass trotz
43
begeisterten Lektorengemeinschaft in den drei Jahren seiner Existenz gerade einmal
30 Artikel produziert wurden. [Moeller 2003a]
Abbildung 9: WikiWikiWeb Zugriffsstatistik, entnommen aus [C2 2008b]
Erst als das System von Jimmy Wales und Larry Sanger Ende des Jahres 2000 auf der
Basis eines Wikis umgestellt wurde, war dem Erfolg des Systems kein Einhalt mehr
geboten. Am 15. Jänner 2001 ging dieses schließlich unter dem Namen wikipedia.com
online. Eigentlich als Experiment gedacht um sich der umständlichen Art und Weise
des Reviews zu entledigen, war das Konzept ein voller Erfolg. [Moeller 2003a]
Im Jahr 2005 überschritt Wikipedia dann erstmalig die Grenze von einer Million Seiten
und wurde zu einer der meist Besuchtesten Websites überhaupt im Internet. Laut Jimmy Wales, war Wikipedia zum damaligen Zeitpunkt mit insgesamt 400 Millionen Aufrufen pro Monat beliebter als bekannte Seiten wie IBM, Paypal, Excite oder Geocities
(siehe Abbildung 10) [Wales 2005].
Heutzutage gilt Wikipedia als größte Enzyklopädie und als das Vorzeigeobjekt, wenn
es darum geht das Konzept Wiki zu unterstreichen.
44
Abbildung 10: Aktuelle Besucherstatistiken von wikipedia.org, entnommen aus
[Wikimedia 2008]
5.4.4 Wiki-Systeme
Wie schon zuvor erwähnt, fand das von Cunningahm entwickelte System regen Anklang bei der Community, weshalb auch bald darauf die ersten Wiki Klone entstanden.
So kam es dazu, dass Peter Merel den ersten bedeutsamen Wiki Clone im Jahr 1987
entwickelte, welcher unter dem Namen CvWiki bekannt wurde. Im Jahr 1998 wurde
das heute noch beliebte TWiki von Peter Tony entworfen. Im Unterschied zum von
Peter Merel entwickelten CvWiki, welches zum Ablegen von Dokumenten ein CVS
System implementierte, war das Twiki das erste Wiki-System, welches Texte über das
herkömmliche Filesystem sicherte und versionisierte. Im Jahr darauf entstanden das
UseModWiki und das erste, nicht in der Programmiersprache PERL kodierte Wiki, das
so genannte PHPWiki. [C2 2008]
Heutzutage existieren mehr als 300 Wiki Klone [C2 2008e; Wikimatrix 2008]. Sie unterscheiden sich auf technischer Ebene zumeist in der zu Grunde liegenden Programmiersprache und dem verwendeten Backend für das Ablegen von Daten. Aber auch
auf Anwenderebene sind nicht alle Wikis gleich, denn werden zumeist die unterschiedlichsten Zusatzfeatures mit implementiert (oder auch nicht).
45
Um einen guten Vergleich zwischen den einzelnen Wikis anstellen zu können, empfiehlt es sich, einschlägige Websites wie beispielsweise die bekannte Adresse wikimatrix.org25 aufzusuchen.
5.4.5 Typische Wiki-Merkmale
Als „typische“ Wiki-Merkmale bezeichnet man den kleinsten gemeinsamen Nenner
aller Eigenschaften, Funktionen und Besonderheiten unterschiedlicher Wiki-Systeme.
Laut [Leuf und Cunningham 2001] können die „typischen“ Merkmale eines Wikis - auch
gerne als „Essenz eines Wikis“ bezeichnet - in folgenden Punkten zusammen werden:
•
Wikis laden dazu ein von jedem User benutzt zu werden, sprich jeder hat die Möglichkeit Seiten frei zu erstellen und diese zu bearbeiten. Des Weiteren sollte das Editieren mit einem Standard Webbrowser möglich sein, ohne zusätzliche Software
installieren zu müssen.
•
Wikis fördern eine aussagekräftige thematische Zuordnung zwischen verschiedenen Seiten durch die einfach und intuitive Art und Weise der Verlinkung.
•
Wikis sind keine sorgfältig zusammen gestellten Websites. Stattdessen zielen Wikis
darauf ab, den Benutzer in einen stetigen Prozess der Seitenerstellung und Kollaboration zu involvieren, um das Aussehen und dessen Inhalte ständig zu verändern.
Eine etwas andere, aber ähnliche Zusammenfassung dessen, was die „typischen“
Merkmale eines Wikis seien, wird im Buch „Wiki - Kooperation im Web“ von Anja
Ebersbach, Markus Glaser, Richard Heigl und Alexander Warta, näher erläutert. Die
Autoren beschreiben die Essenz eines Wikis hierbei zusammengefasst wie folgt
[Ebersbach et al. 2007]:
•
Nichtlineare Hypertextstruktur: Wikis ermöglichen die Entstehung assoziativer Hypertexte mit nicht-linearen Navigationsstrukturen.
•
Einfacher und weitgehender Zugriff: Wiki-Systeme reduzieren das technische Vorwissen im Bezug auf deren Benutzung auf ein Minimum.
•
Keine Client-Software: Wiki-Systeme erlauben das Lesen, Schreiben, Navigieren
und das Editieren einer Seite ohne Installation zusätzlicher Client-Software.
•
Soziale Prozesse im Vordergrund: In Wiki-Systemen steht das Diskutieren und Philosophieren über Beiträge mehr im Vordergrund als die Erstellung derer.
25
http://www.wikimatrix.org
46
5.4.6 Wiki-Technik
Auch wenn sich die einzelnen Wiki-Klone funktional teilweise beträchtlich voneinander
unterscheiden, so unterliegen diese vom technischen Standpunkt aus betrachtet immer
demselben Prinzip.
Wikis sind im Grunde nichts anderes als herkömmliche Client-Server Anwendungen,
welche auf der Basis des World Wide Web agieren [Leuf und Cunningham 2001]. So
beruht jegliche Kommunikation zwischen Benutzer und System auf dem HTTPProtokoll mit den dazugehörigen Request Methoden GET und POST, wobei die Methode GET dafür verwendet wird, um Daten vom Server zu laden und die Methode
POST, um Daten zum Server zu schicken.
Möchte man nun als herkömmlicher Benutzer einen Eintrag auf einem Wiki-System
lesen, werden im Hintergrund folgende Operationen durchgeführt:
•
Im ersten Schritt wird über die Methode GET ein Request an den Server abgesetzt,
welcher über die URL erkennt, um welche Seite der Benutzer gebeten hat.
•
Im zweiten Schritt auch Verarbeitungsschritt genannt, generiert das Wiki-System
(jetzt serverseitig) aus dem so genannten Wiki-Text HTML Code.
•
Im dritten Schritt, wird der zuvor erzeugte HTML Code in eine vom Wiki-System zur
Verfügung gestellten Vorlage, auch Template genannt, eingebettet um schlussendlich die eigentlich Wiki-Seite zu generieren.
•
Im vierten und letzten Schritt wird der zuvor produzierte Code zurück an den Client
gesendet, welcher dort vom Browser interpretiert und schließlich angezeigt wird.
5.4.7 Charakteristische Wiki-Funktionen
Wie die typischen Wiki-Merkmale unabhängig von der Implementierung sind, so verhält
sich dies auch mit den so genannten charakteristischen Wiki-Funktionen. Beispiele
hierfür der so genannte Wiki-Text, eine einfache Textaufzeichnungssprache um WikiBeiträge zu erstellen, die enthaltene „Edit“ Funktion, mit der Beiträge erstellt und bearbeitet werden können, die Überblicksseiten „History“ und „Recent Changes“ sowie die
Suchfunktion oder die so genannte „Sandbox“, um nur einige zu nennen. [Ebersbach et
al. 2007]
In den hierauf folgenden Kapiteln werden die zuvor kurz dargestellten typischen Vertreter für die wohl rudimentärsten Wiki-Funktionen näher erläutert.
5.4.7.1 Wiki-Syntax
„There is no single correct or necessarily even best way to define a markup syntax for
text. While Wiki tries to give a small and logically consistent set of markup options,
given the nature of the current Web clients, there is no way it can even come close to
functioning as a full-featured HTML editing tool. Instead, the intent is to give the user
47
something that is useful, reasonably intuitive (or at least easy to learn), and easy to
use.” [Leuf und Cunningham 2001]
Wie schon in Kapitel 5.4.5 beschrieben, sollte die Methodik des Beitragerstellens so
einfach wie möglich sein. Wiki-Systeme implementieren deshalb häufig eine einfach zu
lernende Sprache, gerne auch als „Wiki-Text“ bezeichnet [Krötzsch et al. 2007], welche
rudimentäre Elemente moderner Textaufzeichnungssprachen in ihrer einfachsten Form
unterstützt.
Wiki-Text lehnt sich dabei sehr stark an die Möglichkeiten, die HTML bietet, an. Das
hat den einfachen Grund, dass Wiki-Sprach-Elemente, die so genannten Wiki-Tags,
vom Wiki-System, vor der Ausgabe auf das Browserfenster in HTML konvertiert werden. Das wiederum bringt natürlich den Vorteil mit sich, dass keine zusätzliche Software installiert werden muss um einen Wiki-Beitrag zu erstellen.
Die Gesamtheit aller Wiki-Tags und die für die Verwendung dieser zu Grunde liegenden Regeln wird als Wiki-Syntax bezeichnet [Fiebig 2005], wobei dazu gesagt werden
muss, dass sich diese von Wiki-System zu Wiki-System unterscheiden kann [Augar et
al. 2004]. Zumeist aber bieten die verschiedenen Wiki-Derivate sehr ähnliche Tags für
dasselbe Übersetzungsschema in HTML an, wobei die Sprache als solche sehr einfach
zu lernen ist. [Schaffert et al. 2006; Wiebrands 2006]
Tabelle 6: HTML vs. Wiki-Syntax der Wiki-Systeme DokuWiki, JSPWiki und MediaWiki
HTML
DokuWiki
JSPWiki
MediaWiki
<a href=”link”>
[[a Link]]
[link]
[[a link]]
<h1>Level1</h1>
====== Level 1 ======
! Level 1
==Section==
<b>bold</b>
**bold**
__bold__
‘‘‘bold’’’
<i><italics/i>
//italics//
‘‘italics’’
‘‘italic’’
<img
src=„image.png“>
{{image.png}}
[image.png]
[Image:image.png]
5.4.7.2 Editieren von Beiträgen
Die wohl mit Abstand wichtigste Funktion eines Wiki-Systems ist die so genannte Editierfunktion, mit der es möglich ist, Beiträge zu erstellen und zu editieren, zumeist als
Tab oder eigener Funktionsknopf im System mit der Aufschrift „Edit“ oder ähnlich ausgewiesen.
Die Editierfunktion, auch als „Editpage“ bekannt, beinhaltet eine Reihe von Elementen
mit denen es möglich ist eine Seite einfach zu bearbeiten oder zu erstellen. So finden
sich auf dieser Seite zumeist ein Eingabefeld und eine Menüleiste mit deren Funktionsknöpfen es möglich ist, Wiki-Code auch ohne syntaktisches Vorwissen zu erzeugen. Aber auch eine „Preview-Funktion“ ist zumeist vorhanden sowie ein „Save“-Button
um Beiträge abzuspeichern.
Abbildung 11: Darstellung einer, Wiki-Seite auf wikipedia.org
Abbildung 12: Editorenansicht der in Abbildung 11 dargestellten Seite
48
49
5.4.7.3 Suchfunktion
Ein wichtiges Feature, das in jedem Datenbanksystem zu finden ist, ist die SuchFunktionen. So ist diese wichtige Zugangsmethodik auch integraler Bestandteil eines
jeden Wiki-Systems.
Die meisten Wiki-Systeme bieten zusätzlich zu herkömmlichen Methodiken, wie Volltext- und Schlüsselwortsuche noch die Möglichkeit an, direkt zu einem Beitrag zu
„springen“, ähnlich einem Karteikartensystem.
5.4.7.4 Verlinkung
Neben der Möglichkeit Beiträge frei erstellen zu können und diese zu editieren ist wohl
die Option Beiträge miteinander zu verlinken, eine der wichtigsten Funktionen, die ein
Wiki zu bieten hat.
So kann in einem Wiki-System jeder Beitrag auf einen anderen verweisen und eine
neue Hyperlinkstruktur bilden. Die Verlinkung eines Artikels erfolgt hierbei zumeist über
dessen Namen und verlangt keine Referenzierung über dessen URL. Zudem unterstützen die meisten Wikis das Generieren von so genannten WikiWords, oder auch
CamelCases genannt. Hierbei werden Phrasen, welche im eigentlichen Sprachgebrauch auseinander geschrieben werden, zu einem Wort zusammengefasst. Die
Phrase „DasIstEinWikiBeitrag“ wäre hierfür ein gutes Beispiel, um zu veranschaulichen
was konkret damit gemeint ist. [Ebersbach et al. 2007]
Darüber hinaus bieten die meisten Wikis so genannte Übersichtsfelder an, die es ermöglichen festzustellen, welche Links auf eine soeben betrachtete Seite verweisen
beziehungsweise davon weg zeigen.
Hyperlinks, welche nicht existieren, werden zudem als solche erkennbar gemacht. Zumeist rot unterlegt, offerieren diese dem Benutzer die Möglichkeit, einen Beitrag zu
diesem Link/Thema zu erstellen.
5.4.7.5 Recent Changes
Eine wichtige und beliebe Anlaufstelle für den Wiki Benutzer ist die Seite „Recent
Changes“, auf der, wie der Name schon sagt, der Benutzer eine Liste der letzten Änderungen im Wiki-System vorfindet. Hierbei ist zu beachten, dass diese Liste sich nicht
nur Änderungen einer Seite bezieht wie die Funktion „History“, sondern alle in einem
Wiki verfügbaren Seiten. Da diese Liste unüberschaubare Ausmaße annehmen würde,
wäre sie nicht beschränkt, wird zumeist ein definierter Zeitraum herangezogen, um
eine obere Schranke einzuführen und diese übersichtlicher zu gestalten. Neben „normalen“ Wiki-Benutzern, welche diese Überblicksseite zumeist dafür verwenden um
über die neuesten Geschehnisse informiert zu werden, ist diese außerdem ein unabdingbares Administratorenwerkzeug, wenn es darum geht Vandalismus entgegen zu
wirken (siehe Kapitel 5.4.12). [Osman 2006]
50
5.4.7.6 History und Revision
Die wohl mit Abstand wichtigste Wiki-Funktion, wenn es darum geht Änderungen an
einer Wiki-Seite zuerkennen, ist die so genannte „History“-Seite. Auf ihr werden, ähnlich der „Recent Changes“-Seite, Änderungen, chronologisch sortiert, dem Benutzer
dargeboten. Zudem stehen dem User zwei wichtige Funktionen zur Verfügung: Die
Revisions- und die Diff-Funktion (dazu mehr in Kapitel 5.4.7.7).
So ist es also dem Benutzer möglich, nicht nur Änderungen festzustellen, sondern diese wenn gewünscht, auch rückgängig zu machen, wobei die Versionisierung der Beiträge zumeist bis zu deren Erstellungsdatum zurückreicht.
Eine kleiner Zusatz sei an dieser Stelle noch erlaubt: Das ursprünglich entwickelte Wiki-System Cunninghams das WikiWikiWeb, hatte diese Funktion zwar auch implementiert, doch reichte die Historie einer Seite immer nur auf den letzten Beitrag zurück. Das
hatte natürlich zur Folge, dass Wiki-Seiten von Vandalen zur Gänze zerstört werden
konnten. Cunningham entdeckte diese Schwachstelle schnell und behob diese in der
zuvor beschriebenen Form.
5.4.7.7 Die „Diff“-Funktion
Um einen Vergleich zwischen zwei Wiki-Seiten anzustellen, steht dem Benutzer ausgehend von der „History“-Seite, die so genannte „Diff“-Funktion zur Verfügung. Eine
sehr praktikable und vor allem übersichtliche Funktion, wenn es darum geht, Unterschiede zwischen zwei Versionen einer Seite zu erkennen. Zumeist wird dem Benutzer
eine Ansicht dargeboten, in der Unterschiede zwischen der aktuellen Version und der
zur vergleichenden nebeneinander dargestellt und unterschiedliche Text Passagen
mittels Syntax-Highlighting erkennbar gemacht werden (siehe Abbildung 13).
Abbildung 13: Die „Diff“ Funktion des Wikis wikipedia
51
5.4.7.8 Sandbox
Eine wichtige Wiki-Seite, welche man vor dem Erstellen eines Wiki-Beitrages besuchen
sollte, ist die so genannte Sandbox. Da die meisten Wiki-Systeme die Philosophie vertreten offen zu sein, jeder User also eine Seite verändern kann, wäre es natürlich fatal
ungeschulte „Editierkünste“ auf bereits aufwendig gestaltete Beiträge los zulassen,
zumal solch ein „vandaler“ Akt zumeist dazu führt, gebannt zu werden. Es wäre also
ratsam sich zuerst in der Sandbox auszutoben, welche speziell dafür gedacht ist um
Editierfunktionen auszutesten.
5.4.7.9 Upload
Als eine weitere Standardfunktion kann die so genannte „Upload“-Funktion genannt
werden, welche es ermöglicht, externe Ressourcen in ein Wiki einzubinden. Typischerweise bieten Wiki-Systeme im Editormodus eine eigenen Schaltfläche an, um
diese spezielle Funktion zur Verfügung zu stellen, aber auch eigene Uploadseiten oder
Archivseiten, welche konkret für den Upload externer Ressourcen eingerichtet wurden,
können diese Funktion implementieren.
Dass diese Funktion eher dazu gedacht ist, Beiträge mit zusätzlichen Inhalten wie Bilder, Videos oder Musik zu ergänzen, beschränken die meisten Wiki-Systeme ihre Uploadfunktion auf wenige ausgewählte Formate.
5.4.7.10 Diskussionsforen
Da es sich bei der Entstehung eines Wiki-Beitrages um einen kollaborativen Prozess
handelt und jeder User die Möglichkeit hat einen Beitrag zu überarbeiten, entstehen
natürlich auch im Idealfall Diskussionen darüber. Um die Inhalte einer Seite nicht mit
Diskussionen darüber voll zu pflastern wieso, etwas verändert wurde, wieso Inhalte
falsch dargestellt wurden oder unzulänglich recherchiert wurden, etc. bieten die meisten Wiki-Systeme die Funktion eines Diskussionsforums an. In diesem, von der eigentlichen Wiki-Seite abgeschnittenen Bereich, werden zumeist rege Unterhaltungen darüber geführt, welche das Ziel haben, einen gemeinsamen Konsens zu bilden um den
zu Grunde liegenden Artikel zu verbessern. [Osman 2006]
5.4.8 Wieso das Wiki-Konzept überhaupt funktioniert
„Das also ist das WikiWeb: ein schlecht abgesichertes System, Benutzer-feindlich, voll
von schwierigen Personen.“ [Wikiservice 2008]
Es ist natürlich immer wieder erstaunlich, wieso das Wiki-Konzept überhaupt funktionieren kann. Trotz der Möglichkeit Beiträge anderer zu editieren, zu löschen, zu kommentieren, zu verlinken, also quasi das Schlimmste was einem als Webseitenbetreiber
passieren kann, die Kontrolle über den Inhalt und dessen Struktur nicht selbst im Griff
zu haben, funktioniert das Konzept - siehe Wikipedia - als wohl bekanntestes Beispiel
hierfür.
52
Auf „Gründer Wiki“ einem populären deutschsprachigen Wiki, wenn es darum geht
Antworten rund um das Thema „Wiki“ zu finden, werden beispielsweise drei wesentliche Punkte genannt, wieso das Wiki-Konzept funktioniert [Gründerwiki 2008]:
Wiki funktioniert,
•
weil einfach mehrere Menschen gemeinsam ein Thema bearbeiten, diskutieren,
sich gegenseitig kritisieren, sich gegenseitig neue Wege zeigen um zu einem Konsens zu kommen.
•
weil jeder Benutzer Informationen ändern, kommentieren und löschen kann. Überflüsse Kommentare, Flames oder Spams werden einfach gelöscht. Übrig bleiben
richtige Inhalte, welche aus einem kreativen Prozess heraus entstanden sind.
•
weil jeder experimentieren darf. Auch wenn Inhalte zerstört werden, gibt es immer
noch die „history“ Funktion, mit der es möglich ist, Beiträge wieder herzustellen.
Die Community leitete diesen Beitrag im Übrigen ursprünglich von Cunningham’s WikiSystem WikiWikiWeb ab. Interessanterweise entwickelte sich der Beitrag dort etwas
anders weiter. So wurden aus den ehemals drei Punkten, neun wesentliche Antworten
darauf, wieso das Wiki-Konzept funktioniert, wobei an dieser Stelle die zusätzlichen
sechs genannt werden [C2 2008c]:
Wiki funktioniert,
•
weil die Community sich verpflichtet fühlt ein Wiki sauber zu halten.
•
weil es kein real-time System ist. Das heißt, Wiki Autoren haben die Möglichkeit
sich über einen Artikel, Gedanken zu machen, bevor dieser nieder geschrieben
wird.
•
weil es kein WYSIWYG ist. Das Editieren einer Seite wirkt wie ein kleiner Intelligenztest. Menschen, welche sich von dem nicht angezogen fühlen, nehmen auch
nicht am Wiki-Konzept teil. Was bleibt sind die Freuden rationaler Diskurse und reger Diskussionen mit den Beteiligten.
•
weil dessen User oft von pedantischer, störrischer und unvernünftiger Natur sind,
woraus sich ein gewisses gemeinschaftliches Gefühl entwickelt.
•
weil es von Natur aus unstrukturiert ist. Die Möglichkeit, Seiten selbst zu erstellen
und zu verlinken fasziniert einfach. Es gibt keine Diktatur, stattdessen formt sich die
Gemeinschaft selbst etwas.
•
weil man sich sicher sein kann auf spielerisch denkende User zu treffen. Das
erstellen einer Wiki-Seite ist wie fast so spannend wie die Beobachtung dessen,
was passiert wenn man ein Garnknäuel einer Meute Katzen zum Spielen gibt.
Zum Abschluss noch ein Zitat von Ward Cunningham, weshalb dieser daran glaubt,
warum das Wiki-Konzept so erfolgreich wurde:
53
„A wiki is a body of writing that a community is willing to know and maintain. That
community has every right to be cautiously selective in what it will groom. This particular wiki has been blessed with thoughtful, diligent, diverse and open-minded volunteers,
who have invested years learning what works here and what doesn’t. When volunteers
tire and depart, others take their place. I remain amazed that this works without mechanically enforced authority. Possibly it works because there is no mechanically enforced authority. In any event, I remain grateful to all volunteers, past, present and future.” [Cunningham 2008]
5.4.9 Wieso Wikis kein HTML verstehen sollten
Wie schon in Kapitel 5.4.7.1 beschrieben, implementieren Wiki-Systeme eine eigene
Markupsprache, um es dem User zu ermöglichen auf simpelste Art und Weise Textinhalte zu erstellen. Doch vor allem technisch versierte Benutzer kritisieren gerne diese
Methodik, denn zumeist fehlen wichtige Elemente (Tags) um eine Seite bis in das
kleinste Detail zu designen. So wird öfters gefordert, doch HTML als Markupsprache
als zusätzliche Option zur Verfügung zu stellen.
Doch es gibt auch einige Gründe, weshalb diese Möglichkeit in den meisten WikiSystemen unterbunden wird [vgl. C2 2008d]:
•
Wikis legen mehr Wert auf den Inhalt einer Seite als auf deren Präsentation. Vergleicht man das Erstellen von Wiki-Seiten mit dem Erstellen einer Seite mittels
HTML, so fällt einem beim näheren Betrachten von aufwendig gestalteten HTML
Seiten auf, dass kaum eine Trennung von Inhalt und Code durchgeführt wird. In
Wiki-Systemen hingegen legen die Menschen mehr Wert auf den Ausdruck ihrer
Ideen als das Verschönern ihrer Inhalte.
•
Die Wiki Textformatierungsregeln wurden dahingehend geschaffen, das einfachste
Mögliche zu implementieren, was funktionieren könnte.
•
Das Schreiben eines Textes in HTML führt oft dazu, dass der Gedankenfluss unterbrochen wird, speziell dann, wenn schwierige Textformatierungen mittels Tabellen oder Ähnlichem durchgeführt werden.
•
Teil der Wiki Natur ist es, dass Inhalte trotz der Verwendung von Code-Fragmenten
lesbar bleiben sollen. Das oft dargestellte Problem von HTML in diesem Zusammenhang ist jenes, dass der Codeanteil den wirklichen inhaltlichen Anteil überwiegt
und deshalb nur schwer bis teilweise gar nicht lesbar ist.
•
Das Zulassen von HTML innerhalb von Wiki-Seiten hat auch oft zur Folge, dass
durch die Fülle an Designmöglichkeiten ein buntes Durcheinander von Seiten entsteht, also keine einheitliche Struktur und Formatierung (als Ganzes betrachtet)
gewährleistet werden kann.
•
54
Die Möglichkeit, HTML in Wiki-Seiten einzubinden, bringt auch ein gewisses Sicherheitsrisiko mit sich. So sind zum Beispiel ausgeklügelte JavaScripts, welche in
HTML Code integriert werden können, in der Lage, Passwörter von Benutzern auszulesen. Darüber hinaus, kann durch das nicht sachgemäße Einhalten der HTML
Syntax eine Seite bis zur Unkenntlichkeit entstellt werden.
Zwei weitere wichtige Punkte welche an dieser Stelle noch hinzugefügt werden sollten,
sind einerseits der Aspekt der Portierbarkeit und andererseits der Aspekt, dass nicht
jeder Mensch HTML kennt und den Umgang damit beherrscht.
•
So ist es beispielsweise in HTML möglich einen Code zu erzeugen, der ein und
dasselbe Ergebnis am Browser liefert (siehe Listing 1).
Vor allem hinsichtlich der Portierfähigkeit sind in HTML abgelegte Textinhalte problematisch. Denn woher sollte eine Exportroutine wissen, ob nicht vielleicht ein anderer Benutzer dieses Systems die Syntax <p style=“font-size:19px”><b>
dazu verwendet hat, wichtige Textpassagen hervorzuheben, wohingegen Überschriften in dessen Texten in der Form <font size=“+2”> ausgewiesen wurden.
•
Ein weiterer wichtiger Punkt wie schon zuvor angedeutet, der gerne unterschätzt
wird, ist die Tatsache, dass nicht jeder Internet User HTML kennt und kann. Wäre
es also in einem System zulässig, beispielsweise Dokumente gleichzeitig in HTML
oder Wiki-Syntax zu erstellen, um auch versierten Internet Benutzern die Möglichkeit zu geben, über das normale Maß hinaus Seiten zu gestalten, so wäre dies für
eine Vielzahl an Benutzern, welche nicht mit HTML vertraut sind, eine herbe Einschränkung.
Es steht zwar außer Frage, dass Wiki-Syntax teilweise zu wenig Möglichkeiten bietet,
um Beiträge bis in das kleinste Detail zu gestalten, doch muss gesagt werden, dass die
zuvor gemachten Aussagen als gute Gründe herangezogen werden können, um HTML
als Markupsprache in Wiki-Systemen zu unterbinden.
Listing 1: Beispielhafter HTML Code für das Erstellen eine und der Selben Überschrift
mit verschiedenen Tag Variationen
<h3>Das ist eine Überschrift</h3>
<p style=“font-size:19px”><b>Das ist eine Überschrift</b></p>
<div style=“font-size:19px;font-weight: bold”>Das ist eine Überschrift</div>
5.4.10 Typen von Wiki-Systemen und Anwendungsgebiete
War Cunningham’s Wiki-System WikiWikiWeb darauf ausgelegt, Design Patterns im
Bereich der Softwareentwicklung zu entwerfen beziehungsweise darüber zu diskutieren, so gibt es heute eine Vielzahl an Anwendungsbereichen, in denen das Wiki-
55
Konzept zum Tragen kommt. Prinzipiell existieren heutzutage zwei wesentliche Typen
von Wiki-Systemen:
•
offene Wiki-Systeme
•
geschlossene Wiki-Systeme
In offenen Systemen können prinzipiell „alle“ Benutzer, egal ob registriert oder nicht,
Beiträge erstellen, editieren oder löschen. In geschlossenen Wikis muss sich der User
mit dem System identifizieren, um Beiträge zu editieren, zu erstellen oder zu löschen,
wobei zumeist dezidierte Zugriffsrechte auf Rollen- oder Benutzerebene existieren.
In weiterer Folge nun einige Beispiele für den Einsatz von Wiki-Systemen:
•
Wikis als Kommunikationshilfe
Wikis erfreuen sich zunehmender Beliebtheit als Zusatztool in geschlossenen Projekten. Hierbei werden Wikis oft dazu eingesetzt, um zu den bekannten Werkzeugen, wie Mailinglisten und Groupeware Lösungen, als ergänzendes Kommunikationstool zu dienen [Cyganiak 2002]. Des Weiteren kommen Wiki-Systeme immer öfter an Schulen im Bereich des E-Learing zum Tragen. Große Firmen wie SAP, Motorola oder British Telecommunications benutzen Wikis als dezentrales Intranet, um
die Kommunikation zwischen den Mitarbeitern zu erhöhen [Ebersbach et al. 2007].
•
Wikis als Organisationshilfe
Neben der Steigerung von Kommunikationsprozessen werden Wiki-Systeme auch
häufig dazu verwendet, um Organisationsprozesse zu optimieren. So verwendet
beispielsweise das Austria Social Forum oder der Chaos Computer Club Wikis als
Organisationshilfe in ihren Unternehmen [Ebersbach et al. 2007], aber auch Firmen
wie Amazon, BBC, IBM etc. setzen Wiki-Systeme erfolgreich ein [Tscholotfeldt
2008].
•
Wikis als E-Learning Tool
Immer mehr Schulen und Universitäten installieren Wiki-Systeme als kollaborative
Wissensplattforum. Beispiele hierfür wären der Fachschaftsrat Informations- und
Medientechnik (IMT) and der Technischen Universität (TU) Cottbus26 oder die Chinese Students and Scholar Association an der Florida State University27.
•
Wikis als PIM oder Desktop-Wiki
Wikis werden des Weiteren auch immer öfter dafür verwendet um als Personal Information Manager (PIM) zu dienen. Der Vorteil dabei ist das strukturierte Ablegen
von Daten. Beispiele hierfür wären das so genannte AcroWiki für Palm OS, Wikipad
für Windows oder Zim Wiki für Linux, um nur einige zu nennen. [Wikipedia 2008]
26
27
http://www.tu-cottbus.de/imt
http://www.fsucssa.com/wiki/doku.php
•
56
Wikis als Online-Enzyklopädien
Vor allem als Basis für Enzyklopädiesysteme werden Wikis gerne eingesetzt.
Gründe hierfür sind zumeist die einfache Art und Weise der Contenterstellung und
die des kollaborativen Arbeitens sowie die Möglichkeit, Beiträge auf simplem Wege
miteinander verknüpfen zu können. Bekanntestes Beispiel hierfür ist die OnlineEnzyklopädie Wikipedia.
•
Wikis als Diskussionsplattformen
Viele Wiki-Systeme werden auch oft dahingehend eingerichtet und angepasst, um
als einfache Diskussionsplattform zu dienen. Der Vorteil dabei ist, Beiträge bleiben
auch nach einigen Monaten oder Jahren erhalten, wohingegen bei herkömmlichen
Forumslösungen Beiträge nach einiger Zeit gelöscht werden oder unauffindbar im
Forumsdschungel verschwinden. [Cyganiak 2002].
•
Wikis als WCMS
Solche Systeme stellen einen typischen Vertreter eines geschlossenen Systems
dar, denn werden einige Einschränkungen getroffen. So gestatten es solche WikiSysteme beispielsweise nicht, jedes Dokument zu bearbeiten, zu erstellen oder zu
löschen. Des Weiteren sind Inhalte zumeist vor strukturiert und obliegen redaktioneller Aufsicht. Nach außen hin sind WCMS-Wikis aber nicht von „normalen“ WikiSystemen zu unterscheiden, was auch Sinn und Zweck der Sache ist, denn so machen sich solche Systeme vor allem die Benutzerfreundlichkeit herkömmlicher Systems zum Nutzen [Cyganiak 2002]. Immer mehr Wikis bieten WCMSFunktionalitäten an, weshalb Unterscheidungen zwischen klassischen WCMSSystemen und Wikis immer schwieriger zu treffen sind.
Natürlich gibt es noch eine Vielzahl von weiteren Anwendungsgebieten in denen heute
Wiki-Systeme zum Einsatz gebracht werden. Die oben dargestellte Liste sollte nur einen groben Überblick darüber geben, was möglich ist und vielleicht in Zukunft noch
kommen wird.
5.4.11 Vorteile
Wie schon zuvor erwähnt, bieten Wiki-Systeme eine Reihe von Vorteilen. In weiterer
Folge sollen diese zusammengefasst werden:
•
Wikis sind benutzerfreundlich
Wie schon zuvor beschrieben, reduzieren Wiki-Systeme das technische Vorwissen
im Bezug auf deren Benutzung auf ein Minimum [Ebersbach et al. 2007]. So muss
weder zusätzliche Software installiert werden, um ein Wiki-System zu benutzen,
noch muss für die Erstellung von Texten eine komplizierte Markup-Sprache gelernt
werden. Auch die breiten Einsatzgebiete, vor allem im Bereich des E-Learnings
zeigen, dass es sich um ein benutzerfreundliches System handelt muss, wie auch
57
eine Studie des National Research Council Canada aus dem Jahr 2005 beweist.
Trotz einiger Mängel kann als Konklusion Folgendes festgehalten werden:
„Overall our study indicates that wiki (or at least our Lizzy implementation) is indeed
usable by non-technical users. The fact that a class of 15 Grade 4 children can use
it to collaboratively create complex web-based stories with only two 15 minute training sessions attests to that. Though the instructor was present to answer the children’s, Désilets has administered wiki sites for which there was no live help present
but were nonetheless used successfully by non-technical adult users. This is consistent with the success and size of the WikiPedia on-line encyclopoedia.” [Désiltes
et al. 2005]
•
Wikis sind billig
Wiki-Systeme unterliegen in der Regel Lizenzen wie der GNU General Public Lizenz (GPL), Common Public Lizenz oder der General Lesser Public Lizenz (GLPL),
das heißt sie sind im allgemeinen frei verfügbar, zum größten Teil gratis oder ziemlich billig und der Code kann zumeist ohne Einschränkungen erweitert/modifiziert
und weitergegeben werden. [vgl. GNU 2008]
•
Wikis sind populär
Egal ob in Schulen als E-Learning Tool genutzt, in Firmen als Organisationshilfe
oder Diskussionsplattform, auf Universitäten als Knowledgebase, Wikis sind ein
populäres Konzept, wenn es darum geht Content zu erstellen und diesen zu verwalten.
•
Wikis sind flexibel
Vor allem die Möglichkeit, Quelltext an eigene Bedürfnisse anzupassen und die hohe Vielfalt an Anwendungsgebieten beweisen, dass Wikis flexible Softwarelösungen sind.
•
Wikis sind ortunabhängig
Ob im Internetcafe, zu Hause vor dem Rechner oder via Handy, Wiki-Systeme sind
überall dort einsetzbar wo das Medium World Wide Web zur Verfügung steht. Das
heißt sie sind nicht an einen fixen Ort gebunden.
•
Wikis ranken gut
Vor allem durch die einfache Möglichkeit Seiten zu erstellen, steigt der Content in
einem Wiki-System zumeist schnell. Zudem sind Wiki-Seiten oft stark verlinkt, bieten hohen textuellen Informationsgehalt an und verzichten auf Scriptsprachen. All
das sind Gründe dafür, warum Wikis gerne von Suchmaschinen indiziert werden
(siehe beispielsweise Abbildung 14).
•
58
Wikis sind interaktiv
Wikis bieten die Möglichkeit, über Funktionen wie Foren oder Kommentarfunktion
mit der Community in Kontakt zu treten. Auch wenn das Konzept nicht sonderlich
neu ist, gibt es doch einen wesentlichen Unterschied. Ist für das Kommentieren oder das Diskutieren normalerweise eine Anmeldung notwendig, so verzichten die
meisten Wiki-Systeme darauf. Die Hemmschwelle ist also relativ gering wodurch
eine Konsensbildung meist schneller stattfindet als in herkömmlichen kollaborativen
Umgebungen.
•
Wikis sind schnell
Vor allem durch die Möglichkeit selbst Beiträge zu verfassen können Informationen
schneller verbreitet werden. Ein Umweg über den Webseitenbetreiber entfällt also.
Abbildung 14: Wikipedia Global Traffic Ranking, entnommen aus [Alexa 2009]
5.4.12 Nachteile
Trotz der vielen Vorteile gibt es auch einige Nachteile mit denen sich Wikis konfrontiert
sehen. Vor allem in offenen Wiki-Systemen (ohne Zugriffskontrolle) treten folgende
Probleme des Öfteren auf:
•
Wikis fördern den Vandalismus
Vandalismus meint weniger die User, welche Inhalte unabsichtlich verfälschen,
sondern jene, die Beiträge absichtlich und mutwillig verändern oder gar zerstören.
So geschah es beispielsweise im Jahr 2006, dass der Komiker Stephan Colbert vor
laufender TV-Kamera den Wikipedia Beitrag zu George Washington mutwillig verfälschte. Des Weiteren rief der Comedy Star dazu auf, über Wikipedia die Information zu verbreiten, dass sich die Elefantenpopulation in Afrika im letzten halben
59
Jahr um das Dreifache gesteigert hätte, worauf Wikipedia 20 Artikel über Elefanten
sperren musste. [Goeßmann 2006]
Dieser eher belustigende Form des Vandalismus folgt aber auch eine Reihe von
nicht so rühmlichen Ausführungen. So geschah es beispielsweise, dass der USPharmakonzern AstraZeneca, einen Mitarbeiter dazu ermutigte den Wikipedia Beitrag zum Medikament Seroquel zu manipulieren. Hieß der originale Eintrag noch,
das Medikament habe die Nebenwirkung labile Teenager auf Selbstmordgedanken
zu bringen, so wurde dieser wichtige Zusatz schlicht und ergreifend gelöscht.
[Frank 2007]
Das Medikament rief im Übrigen wirklich schon einige Todesfälle hervor, wie die
Packungsbeilage28 des Medikamentes beweist.
Natürlich bieten Wikis die Möglichkeit einer Revisionskontrolle an, doch wie Beispiele aus der Vergangenheit zeigen, helfen die besten Autorenwerkzeuge und das
Auge der Community nicht immer, um solche Falschdarstellungen sofort zu erkennen.
So geschah es beispielsweise im Sommer 2005, dass ein Wikipedia Eintrag über
den US-Journalisten John Seigenthaler fälschlicherweise mit der Ermordung J. F.
Kennedys in Verbindung gebracht wurde. Es dauerte aber nicht weniger als 132
Tage bis der Fehler erkannt und behoben wurde. Ein beträchtlicher Zeitraum, wenn
man daran denkt, dass im Schnitt 400 Millionen User Wikipedia monatlich aufsuchen, um „Wissen“ zu recherchieren. [Bichlmeier 2006]
•
Wikis fördern die Selbstdarstellung
Ein weiteres großes Problem mit dem Wiki-Systeme zu kämpfen haben, sind Beiträge aus der Community, die nicht unter dem Aspekt eines neutralen Standpunktes entstanden sind. Auch wenn beispielsweise Wikipedia den Grundsatz „neutraler
Standpunkt“ als eine von vier Grundregeln niedergeschrieben hat, so kommt es
immer wieder zu Verfälschungen von Tatsachen.
Ein gutes Beispiel hierfür ist der Fall Klaus Kleinfeld, seines Zeichens ehemaliges
Vorstandsmitglied der Siemens AG. So geschah es, dass im Frühling 2006 dessen
Wikipedia Eintrag von Siemens Mitarbeitern verändert wurde, um diesen in der Öffentlichkeit in ein besseres Licht zu rücken. Ein anderes Beispiel, welches für Furore sorgte, war ein vom US-Amerikanischen Geheimdienst CIA verfasster Kommentar zum Beitrag vom iranischen Präsidenten Mahmoud Ahmadinejad. So wurde der
Wortlaut „Wahhhhhh!“ neben dessen Bild hinein editiert. Der Vorfall flog im Übrigen
nur deshalb auf, weil Virgil Griffith, ein 24-Jähriger Student vom California Institute
of Technology sich die Mühe gemacht hatte sämtliche von Wikipedia gespeicherten
anonymen IP Adressen zu verfolgen. [Frank 2007]
28
http://www.pharmazie.com/graphic/A/60/1-23460.pdf
•
60
Wikis sind von minderer Qualität
Ein weiterer großer Vorwurf, welcher Wiki-Systeme betrifft ist jener, dass deren Beiträge zumeist von minderer Qualität seien. Vor allem durch den zuvor dargestellten
Vandalismus und das Einnehmen eines nicht neutralen Standpunktes, haben zum
Beispiel Wikipedia Beiträge oft damit zu kämpfen, als tatsächliches „Wissen“ anerkannt zu werden.
Ein wichtiger Punkt, der in diesem Zusammenhang noch des Öfteren erwähnt wird,
ist jener, dass Wikipedia trotz der Fülle an Benutzern nur einen geringen tatsächlichen Autorenstamm hat, der qualitativ hochwertige Beiträge schreibt. Demzufolge
wurde im Jahr 2005 eine interessante Studie von Jakob Voß durchgeführt, um herauszufinden, welche beziehungsweise wie viele User tatsächlich sich an der Erstellen eines Wikipedia Beitrages beteiligen und ob signifikante Unterschiede in qualitativer Hinsicht zu erkennen sind. Voß kam am Ende seiner Studien zu folgenden
Ergebnissen: Etwa 50% der Artikel wurden von weniger als fünf angemeldeten Autoren bearbeitet, 25% gar nur von einer einzelnen Person, entsprechend unterschiedlich war die Qualität der einzelnen Artikel. [Bichlmeier 2006]
•
Wikis verletzten das Copyright
Ein weiterer wesentlicher Punkt, mit dem sich Wiki-Systeme des Öfteren konfrontiert sehen, sind die die so genannten Copyrightverletzungen. Wiki-Systeme sind im
herkömmlichen Sinn frei verfügbare OpenSource Projekte, welche das Ziel haben
offene Inhalte anzubieten. Zumeist werden deshalb Lizenzsysteme verwendet, welche diese Art der Publikation unterstützen. So bietet beispielsweise Wikipedia das
so genannte GNU Free Documentation License Model an, unter dem es jeden Autor erlaubt ist, Beiträge zu verfassen. Die Problematik, mit der sich Wikipedia deshalb des Öfteren konfrontiert sieht, sind Beiträge in denen geschützte Inhalte unbedachterweise verwendet werden, denn die GNU FDLM erlaubt nicht nur das Kopieren sondern auch das uneingeschränkte Verbreiten von Beiträgen. [Ebersbach et
al. 2007]
•
Wikis produzieren nicht zitierfähige Beiträge
Als Beispiel hierfür sei abermals die Online-Enzyklopädie Wikipedia herangezogen.
So kam es im Jahr 2006 dazu, dass Erfinder Jimmy Wales selber davon abriet, Wikipedia als Nachschlagewerk für wissenschaftliche Arbeiten heranzuziehen. Wales
erhielt in den Monaten vor dieser Meldung anscheinend circa zehn Emails pro Woche, in denen sich Studenten darüber beschwert hatten, dass ihre Arbeiten nicht
von ihren Dozenten anerkannt wurden, weil diese Wikipedia Zitate enthielten.
[Lombardi 2006]
Die Gründe für dieses Verhalten der Dozenten sind schnell erklärt: Wikipedia ist ein
offenes Wiki-System, wodurch es prinzipiell jedem möglich ist, Beiträge zu verändern oder zu verfassen und das sogar anonym, das heißt ein wirkliche namentliche
61
Zuordnung ist nicht möglich. Zudem kommen Wiki Artikel nicht wirklich zur Ruhe,
das heißt ein wirkliches Veröffentlichungsdatum kann nicht angegeben werden.
Dazu kommen noch Gründe wie Vandalismus und nicht vorhandene redaktionelle
Prüfung, weshalb Wikipedia Beiträge teilweise als Quellen zurückgewiesen werden.
5.5
Wikis als Basis für das Austria-Forum einsetzbar?
Im Folgenden abschließenden Kapitel soll darüber diskutiert werden, ob beziehungsweise wie weit sich Wikis dazu eignen das Konzept Austria-Forum in technischer Hinsicht zu realisieren.
Für dieses Unterfangen ist es zweckdienlich, die gewünschten allgemeinen Systemeigenschaften mit denen der Wikis zu vergleichen und zu diskutieren:
•
Das System sollte frei verfügbar sein (OpenSource)
Wie schon in Kapitel 5.4.11 beschrieben, sind die meisten heutigen Wiki-Systeme
frei verfügbar und unterstützen Lizenzmodelle wie GNU General Public Lizenz
(GPL), Common Public Lizenz oder General Lesser Public Lizenz (GLPL), weshalb
das Kriterium „freie Verfügbarkeit“ als Bedingung erfüllt ist.
•
Das System sollte benutzerfreundlich sein
Wie schon in Kapitel 5.4.11 beschrieben sind Wikis vor allem eines, nämlich „benutzerfreundlich“. Es werden keine zusätzlichen Softwaretools benötigt, um ein Wiki zu benutzen, noch muss der User sich damit herumschlagen, eine komplizierte
Markupsprache zu lernen um Inhalte zu gestalten. Auch das breite Anwendungsgebiet vor allem im Bereich des E-Learnings beweist, dass Wikis benutzerfreundliche Systeme sind. Die Bedingung „Das System sollte benutzerfreundlich sein“ ist
somit erfüllt.
•
Das System sollte die Community als integralen Bestandteil ansehen
Auch diese Bedingung ist vom Wiki-Konzept erfüllt. Vor allem durch Eigenschaften
wie Offenheit, die des kollaborativen Arbeitens oder des Diskutierens und Philosophierens in gesonderten Bereichen sowie die Einfachheit und die Benutzerfreundlichkeit des Konzeptes an sich, machen Wikis zu „den“ Community Systemen
schlechthin, wie auch die lange Liste der unterschiedlichsten (Community behafteten) Anwendungsgebiete beweist.
•
einfache Suchmethoden unterstützen (Volltext, Keyword)
Bezüglich dieses Kriteriums muss gesagt werden, dass auch hier alle Bedingungen
erfüllt sind. Egal ob Volltext- oder Keywordsuche, beide Methodiken werden von
den meisten Wiki-Systemen unterstützt. Zudem gibt es immer mehr Wiki-Systeme
auf dem Markt, welche Features wie semantische Annotation und Suche von Bei-
62
trägen (siehe beispielsweise IkeWiki29oder Semantic MediaWiki30) ermöglichen, ein
Kritikpunkt der „herkömmlichen“ Wikis des öfteren zuteil wird.
•
einfache Methodiken zur Content Erstellung anbieten (z.B.: WYSIWYG Editor,
simple Syntax, Eingabe-Templates, und so weiter)
Wie schon in Kapitel 5.4 beschrieben, bietet das Wiki-Konzept besonders einfache
und leicht zu lernende Möglichkeiten an, um Content zu erstellen. So kann jeder
Beitrag über die Funktion „Edit“ bearbeitet werden beziehungsweise über einen
noch nicht vorhandenen Titel (Link) können Beiträge erzeugt werden. Die für die
Erstellung der Beiträge zu Grunde liegende Syntax ist dazu besonders einfach
gehalten. Somit kann gesagt werden, dass auch dieser Punkt vom Wiki-Konzept erfüllt ist.
•
ein User Management und Control Modul anbieten
Auch wenn „User Management und Control“ nicht explizit als charakteristische Wiki-Funktionen angeführt wurden, so bieten die meisten Wiki-Systeme dieses Konzept an. Vor allem aus Gründen des Vandalismus, aber auch um Copyrightverletzungen vorzubeugen und die Qualität der Beiträge zu steigern, wird dieser Mechanismus von immer mehr Systemen angeboten (siehe beispielsweise JSPWiki31,
TWiki32 oder MediaWiki33). Somit ist auch diese Bedingung mehr oder weniger vollständig erfüllt.
•
eine flexible Art der Kategorisierung anbieten
Auch wenn es mittlerweile vereinzelt Wiki Klone mit nativem Support hinsichtlich
der Strukturierung von Beiträgen via Sub-Pages gibt, so muss gesagt werden, dass
diese Feature alles andere als typisch ist. Was aber fast von allen Wiki-Systemen
zumeist unterstützt wird, sind spezielle Tags mit deren Hilfe es möglich ist, Unterteilungen einfach und flexibel nach der Beitragserstellung durchzuführen. So kann
gesagt werden, dass auch diese Bedingung mehr oder weniger erfüllt ist.
•
Drucken und Speichern von Beiträgen ermöglichen
Wie schon in Kapitel 5.4.6 beschrieben, sind Wikis vom technischen Standpunkt
aus betrachtet recht einfach gehaltene Client-Server Anwendungen. Aber nicht nur
das System an sich ist einfach gehalten, sondern auch das Ausgabeformat. So erzeugen Wikis, wie schon des Öfteren erwähnt, zumeist reinen HTML Code und
verzichten auf Technologien wie DHTML oder Ajax. Auch wenn moderne Systeme
wie beispielsweise JSPWiki oder TWiki solche Konzepte zum Einsatz bringen, wird
29
http://ikewiki.salzburgresearch.at
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
31
http://www.jspwiki.org
32
http://www.twiki.org
33
http://www.mediawiki.org/wiki/MediaWiki
30
63
trotzdem darauf geachtet, dass Beiträge gedruckt oder abgespeichert werden können, sei es durch einen eigens implementierten Print-View oder mittels StyleSheets. Somit kann festgestellt werden, dass auch diese Bedingung erfüllt ist.
5.6
Fazit
Auch wenn in diesem Kapitel keine dezidierte Softwarelösung als Basis für das AustriaForum gefunden wurde (dazu in Kapitel 6 mehr), konnte zumindest festgestellt werden,
dass sich Wikis im Grunde dazu eignen würden, das Konzept Austria-Forum in technischer Hinsicht zu realisieren.
Vor allem bezüglich der Kriterien Usability, Community, Printability und ContentErstellung ist das Konzept dem Austria-Forum in seiner jetzigen Form überlegen. Wo
es aber Einschränkungen zu geben scheint, sind Funktionen wie Zugriffskontrolle und
Kategorisierung, denn unterstützen nicht alle Wiki-Systeme diese beiden genannten
Features.
Zudem wurde noch festgestellt, dass Weblogs auf Grund der eingeschränkten Kommunikationsmöglichkeiten
und
Community-Content-Collaboration-ManagementSysteme wie beispielsweise PHPNuke und PostNuke auf Grund technischer und sicherheitsrelevanten Probleme keine Alternative für das Austria-Forum darstellen.
6 Wiki-Systeme im Vergleich
6
64
Wiki-Systeme im Vergleich
Im folgenden Kapitel werden fünf der wohl derzeit bekanntesten Wiki-Systeme miteinander verglichen. Das Ziel hierbei: Das Ausfindigmachen eines geeigneten Systems
mit dem das Konzept Austria-Forum in technischer Hinsicht umgesetzt werden kann.
Die Vorauswahl der Systeme erfolgte hierbei bezüglich der Kriterien OpenSource, Popularität [Wikimatrix 2008a; Smith und Sauer 2006], Programmiersprache (wobei PHP,
Java, .NET und PERL relevant waren) sowie hinsichtlich der Funktionen Zugriffskontrolle und Kategorisierung, wobei als Vergleichssoftware das auf der Website wikimatrix.org zur Verfügung gestellte Komparationstool zum Einsatz gekommen ist.
Die abgewandelten „neuen“ technischen Anforderungen an das System können dabei
wie folgt definiert werden, da einige Kriterien wie beispielsweise die Revisionskontrolle
oder OpenSource-Projekt wegfallen:
•
Security: Das System sollte einen Authentifizierungsmechanismus bereitstellen.
Zudem sollte es dezidierte Zugriffskontrollmechanismen anbieten.
•
Userverwaltung: Das System sollte einen Userwaltungsmechanismus bereitstellen.
•
Strukturierung von Beiträgen: Beiträge sollen vom System in strukturierter Form
dem User angeboten werden können. Ein Kategorisierungssystem wäre wünschenswert.
•
Suche: Das System sollte dem User die Möglichkeit offerieren einfache und komplexe Suchanfragen zu generieren.
•
Kommentare und Foren: Das System sollte eine Foren- und Kommentarfunktion
beinhalten.
•
XHTML/CSS/PDF Ouput und RSS-Feeds: Das System sollte Standardausgabeformate wie XHTML 1.0/CSS und PDF beherrschen. Des Weiteren sollte es einen
RSS-Dienst inkludieren.
•
Mediensupport: Das System sollte einen ausgeprägten Mediensupport (Video/Audio) anbieten.
•
Conflict Management: Das System sollte einen gutes Conflict-Managment-System
beinhalten.
•
Herstellersupport: Das System sollte einen guten Herstellersupport anbieten.
•
Datastorage: Das System sollte ein leicht anzupassendes Datastorage-Modul anbieten.
•
Erweiterbarkeit: Das System sollte prinzipiell leicht erweiterbar sein.
65
•
Print-Friendly: Das System sollte einen nativen Print-Support anbieten.
•
Code und Programmiersprache: Das System sollte eine gute Codebase anbieten
und eine professionelle Programmiersprache zum Einsatz bringen.
•
Syntax: Das System sollte eine leicht zu lernende Wiki-Syntax anbieten.
Auch wenn Wikis prinzipiell sehr benutzerfreundlich sind, so unterscheiden sich diese
doch in mancherlei Hinsicht, weshalb auch dieser Punkt als Zusatz anführt werden soll:
•
Usability: Das System sollte möglichst benutzerfreundlich sein.
6.1.1 MediaWiki
Das wohl mit Abstand bekannteste Wiki-System [Smith und Sauer 2006], ist das so
genannte MediaWiki. Entwickelt wurde die Software vom deutschen Biologen Magnus
Maske für die Online-Enzyklopädie Wikipedia. Ursprünglich bildete dessen Basis das
so genannte UseMod Wiki. Es musste aber auf Grund des großen Erfolges von Wikipedia und der damit einhergehenden schlechten Skalierbarkeit ausgetauscht werden.
Am 25. Jänner 2002 wurde die erste Version von MediaWiki, damals noch unter dem
Namen Phase II bekannt, erstmalig zum Einsatz gebracht. Im Juni desselben Jahres
noch wurde das System durch eine komplette Code-Überarbeitung durch Lee Daniel
Crocker in seine heutige Form gebracht. [Moeller 2003a]
Zurzeit (Stand: 17.12.2008) befindet sich das System in der Version 1.13.0 und hat als
Systemvoraussetzungen PHP in der Version 5 sowie MySQL4 oder Postgres 8.0. Die
Installation erfolgt wie auch bei den meisten anderen Wiki-Systemen über ein Installationskript. Wurde die Installation erfolgreich durchgeführt, so erzeugt das Wiki eine
Datei mit dem Namen LocalSettings.php, welche in das Hauptverzeichnis des Wikis
verschoben werden muss. Diese Datei ist wichtig, denn werden mit ihr alle relevanten
Konfigurationen wie zu verwendende Sprache, Zugriffsrechte und noch vieles mehr,
vorgenommen. [Pelka et al. 2007]
Bezüglich Rechteverwaltung stehen globale Einstellungen über Gruppen zur Verfügung. Action Control Listen (ACLs) werden nicht unterstützt. Beim Editieren von Seiten
wird auf Conflict-Resolution gesetzt. Das Editieren ein und derselben Seite von gleichzeitig mehreren Autoren ist also möglich. [MediaWiki 2008]
Was die Robustheit des Codes anbelangt, so wurde daran gedacht einen objektorientierten Ansatz zu verfolgen. Die Dokumentation ist zwar groß und übersichtlich gehalten, kann aber mit einer JAVADoc nicht zur Gänze mithalten.
Hinsichtlich der Erweiterungsmöglichkeiten ist das MediaWiki recht umfangreich, denn
existieren knapp an die tausend Plugins, mit denen das System in funktionaler Hinsicht
ergänzt werden kann. Vor allem auf das Einbinden anderer Module wie beispielsweise
des Amazon-Bookstores, Google-Maps oder Youtube-Videos wurde Wert gelegt. Aber
auch zahlreiche Exportformate, unter Anderem in PDF, stehen zur Verfügung. Auch
66
können Formeln direkt in Latex geschrieben, in Wiki-Seiten eingebunden und zur Anzeige gebracht werden. Des Weiteren ist das MediaWiki mit seinen 140 Sprachen, das
wohl best übersetzte Wiki unter den fünf hier vorgestellten Systemen. [MediaWiki 2008]
Abbildung 15: Das MediaWiki
Was zusätzliche Add-Ons wie Foren oder Blogs anbelangt, so werden diese nicht dezidiert unterstützt. Ein Forum Plugin oder eine ImageGallery ist vorhanden, auf Blogs
wird aber weitgehend verzichtet. Die (Volltext)-Suche im System ist hervorragend wie
ein Testbericht aus der Computerfachzeitschrift C’T zeigt. So wurden in einem Test
über 10.000 Dokumente (ca. 80MB an Daten) in fast weniger als einer Sekunde Response-Zeit durchsucht. [Moeller 2003b]
Was die Syntax anbelangt, so wird neben herkömmlicher Wiki-Syntax auch inlineHTML unterstützt, wobei diese im Vergleich zu anderen Systemen etwas gewöhnungsbedürftig erscheint. Des Weiteren stehen dem User die bekannten Funktionen
wie Diff, Edit, RecentChanges, History und so weiter zur Verfügung.
67
6.1.2 FlexWiki
Das FlexWiki ist wohl das schlankste von den hier vorgestellten Systemen. So ist die
neueste Version 2.1.0.274 (Stand: 18.12.2008), welche auf sourceforge.net34 zum
Download bereit steht gerade einmal 900KB groß. Der wesentliche Unterschied zu den
hier vorgestellten Systemen ist, dass für die Implementierung des Systems ausschließlich das von Microsoft bekannte .NET-Framework mit den Programmiersprachen C#
und ASP zum Einsatz gekommen ist. Entwickelt wurde das System ursprünglich von
David Ornstein, seines Zeichen Lead-Program-Manager von Microsoft Windows.
FlexWiki war im Übrigen auch eines der ersten Programme, welches von Microsoft zu
einem Open-Source-Projekt gemacht wurde. Der erste Release Kandidat kam im Jahr
2004 unter der Common Public License heraus [Cal et al. 2008].
Was die Systemvoraussetzungen anbelangt, so werden laut Herstellerseite das Betriebsystem Windows XP Professional oder Windows Server 2003 empfohlen. Als
Webserver reicht ein Microsoft Internet Information Server der Version 5 oder höher.
Die Installation ist recht simpel gehalten, denn muss das Zip-Archiv lediglich in den
Ordner Inetpub\wwwroot kopiert und Leserechte für das Verzeichnis fwfolder beziehungsweise Schreibrechte für das Verzeichnis fwfolder\WikiBases erteilt werden.
Was den allgemeinen Funktionsumfang anbelangt, ist das vorgestellte FlexWiki - laut
[Wikimatrix 2008b] - jenes mit dem kleinsten Feature-Set. So wurde das Wiki beispielsweise bis heute noch in keine weitere Sprache übersetzt. Auch fehlen Features
wie Kommentarfunktion, PDF-Export, Change Summery, und so weiter [Wikimatrix
2008b]. Das hat vor allem den Grund, dass hinter dem Projekt zurzeit eine kleine
Community steht, welche sich um die Pflege des Projektes kümmert. Nichtsdestotrotz
läuft das Projekt verhältnismäßig gut, wie die fast monatlichen Releases beweisen.
Für das Ablegen von Wiki-Pages stehen dem User die Möglichkeiten eines FileSystem- oder eines Datenbankbasierten Backends offen. In der StandardKonfiguration wird ersteres verwendet. Zum Editieren von Beiträgen wird ein eher ungewöhnliches Feature angeboten, denn können Beiträge direkt durch einen Doppelklick auf den gewünschten Artikel editiert werden. Ein WYSIWYG wird nicht angeboten,
dafür aber die Option Keywords zu definieren, um das Suchen nach Inhalten zu vereinfachen. Die zu verwendende Wiki-Syntax ist dabei recht einfach gehalten, wobei aber
auch einfache und komplexe Tabellen unterstützt werden. Features wie „Page-Histroy“,
„Recent-Changes“, „Lost and Found“ und „Rename“ sind ebenfalls vorhanden. Die
Seitenausgabe am Browser erfolgt in HTML, wobei ein dezidierter Standard nicht eingehalten wird. [Wikimatrix 2008b]
34
http://www.sourceforge.net
68
Abbildung 16: Das FlexWiki
Die große Stärke von FlexWiki ist eine Smalltalk basierte Programmiersprache namens
„Wiktalk“, mit der sich dynamische Seiteninhalte erstellen lässt. Aber auch ein PluginModul wird angeboten um das Wiki in funktionaler Hinsicht zu expandieren. Was die
Zugriffsrechte auf das Wiki anbelangt, so können diese über eine Konfigurationsdatei
flex.wiki.config eingerichtet werden. Auch ACLs stehen zur Verfügung. Für die
Authentifizierung kommt das Windowseigene Backend zum Tragen. Aber auch ein
eigenes Anmeldeformular mit ASP .NET Membership Provider wird angeboten [Cal et
al. 2008]. Was die Medienintegration anbelangt, werden Flash und Videosupport angeboten. Add-Ons wie Foren, Blogs existieren nicht.
Zum Abschluss sei noch etwas über Strukturierung von Beiträgen und der Suche gesagt. So können in FlexWiki zwar Beiträge in Namespaces zusammengeführt werden.
Sub-Pages werden aber nicht unterstützt. Was die Suche anbelangt, steht eine Volltextsuche zur Verfügung, mit der auch das Suchen mit Hilfe von regulären Ausdrücken
möglich ist.
69
6.1.3 JSPWiki
[JSPWiki 2008; JSPWikiDoc 2008]
Wie der Name schon vermuten lässt, wird das JSPWiki mit Hilfe von Java Server Pages (JSP) implementiert und liegt zurzeit in der Version 2.8.1 (Stand: 16. Dezember
2008) vor. Neben fast täglichen Builds und einer breiten Community zeichnet sich das
Projekt vor allem hinsichtlich seines qualitativ hochwertigen Quellcodes aus. Durch die
klare Trennung zwischen Code und Präsentation ist der Code sehr homogen, was sogar dazu geführt hat, dass die Apache Software Foundation das Projekt (Seit Version
2.8) adaptiert hat.
Bezüglich der Installation ist das System recht einfach zu handhaben. So wird auf der
Herstellerseite eine .WAR Datei, welche auf einfachem Wege mit einen Apache Tomcat Server deployed werden kann, angeboten. Ein simples Installationsscript, mit dem
Arbeitsverzeichnis und ein Admin-Passwort definiert werden können, erledigt den Rest
um das Wiki zum Laufen zu bringen.
Hinsichtlich Dokumentation ist das Wiki auch vorbildlich, so findet sich auf der Dokumentationshomepage eine ausgedehnte FAQ-Seite mit sämtlichen nur erdenklichen
Fragen und Antworten.
Bezüglich der Erweiterungsmöglichkeiten ist das System allen anderen hier vorgestellten Systemen überlegen.
So wird beispielsweise ein File-Provider-Modul implementiert, auf dessen Basis sämtliche Speicherkonzepte abgebildet werden können. In der Standardinstallation ist zum
Beispiel ein CVS-, ein herkömmlicher File-System- oder ein Buffer-File-System- Provider enthalten. Aber auch Datenbanken wie MySQL oderPostgreSQL oder Eigenentwicklungen werden unterstützt.
Ein weiterer Erweiterungsmechanismus ist die so genannte Plugin-Architektur, um das
System vor allem in funktionaler Hinsicht leicht zu erweitern. Aber auch das Feature
der so genannten Wiki- „Variablen“ und „Forms“ wird angeboten.
Um das System hinsichtlich seines Aussehens zu verändern, steht dem User ein
durchdachtes Template-Konzept zur Verfügung. Auf der Herstellerseite finden sich
eine Reihe von Vorlagen um beispielsweise das JSPWiki in einer Art Windows-Vista
Style erscheinen zu lassen. Die Ausgabe auf den Browser erfolgt im Übrigen via
XHTML 1.0 Strict. Als Exportmöglichkeiten einzelner Seiten stehen Print-CSS oder
PDF zur Verfügung.
Hinsichtlich Zugriffsrechte und Userverwaltung bietet das JSPWiki ein recht umfangreiches Featurset an. So kann die Userverwaltung global über JAAS-Files geregelt werden oder aber auf Page Ebene via ACLs. Darüber hinaus werden Konflikte bei der Seitenbearbeitung erkannt und gegebenenfalls dem Benutzer angezeigt.
70
Die Seitenerstellung erfolgt wie sonst üblich auch über das Broken-Link Konzept, wobei für das Editieren ein WYSIWYG Editor oder eine recht simple Wiki-Syntax zum
Einsatz gebracht werden können.
Abbildung 17: Das JSPWiki
Zu guter Letzt noch etwas zum Thema Community, Suche und Mediensupport.
Neben den herkömmlichen Wiki Möglichkeiten, Beiträge kollaborativ zu erstellen und
diese zu bearbeiten, werden auch zusätzliche Elemente wie Kommentarfunktion, Foren
und Blogs als Add-Ons angeboten. Um auf dem neuesten Stand der Dinge zu bleiben,
werden auch RSS-Feeds unterstützt sowie die sonst üblichen Übersichtsseiten „Recent-Changes“ oder „History“.
Die Suche im JSPWiki erfolgt mit Hilfe der bekannten OpenSource Suchmaschine Apache Lucene35. Es wird sowohl eine Bereichssuche angeboten, aber auch eine Volltextsuche. Zudem wird ein Ajax basiertes Suchkonzept angeboten.
Was den Mediensupport anbelangt, so können neben Bildern auch Videos oder Flashanimationen direkt in den Seiten angezeigt werden. Der Upload erfolgt dabei direkt als
Attachment, was den Vorteil mit sich bringt, dass alle Dateien übersichtlich zu der gehörigen Seite im System auffindbar sind.
35
http://lucene.apache.org
71
6.1.4 TWiki
Beim so genannten TWiki handelt es sich um ein cgi-bin Skript, welches in der Programmiersprache PERL implementiert wurde. Entstanden ist das System ursprünglich
aus dem Projekt JOSWiki an dem auch der Autor Peter Thoeny beteiligt war. Die erste
Version von TWiki wurde am 23. Juli 1998 veröffentlicht, wobei das System in seinen
Anfängen als Intranet-Tool zum Bereitstellen einer Knowledgebase eingesetzt wurde.
[Raygan und Green 2002]
Das TWiki in seiner heutigen Form empfiehlt sich laut TWiki Homepage vor allem für
Klein- bis Mittelbetriebe. Entwickelt wird das System hauptsächlich von einer breiten
Community und Peter Thoeny. Aber auch Firmen wie Yahoo und Motorola beteiligen
sich an der Implementierung und setzten es wie viele andere im Unternehmensumfeld
ein. [Seibert 2008]
Was die Installation des Systems anbelangt, so ist das TWiki wohl mit Abstand das am
schwersten zu integrierende (von den hier vorgestellten Systemen). Trotz umfangreicher Installationsanweisung hat das Programm einige Makel. So benötigt man für die
zurzeit aktuelle Version 4.2.4 (Stand 18. Dezember 2008) eine Reihe von zusätzlichen
PERL-Modulen und UNIX-Funktionen wie beispielsweise [TWiki 2008]:
•
RCS (Revision Control System) 5.7 oder höher
•
GNU diff 2.7 oder höher
•
GNU patch
•
fgrep, egrep
•
UNIX cron, und so weiter
Kein Wunder, dass es mittlerweile eine Reihe von Installationsanleitungen in elektronischer oder gedruckter Form gibt, um diese Hürde leichter zu überwinden [Mahrbach
2008; Pro 2008; Weber 2007] .
Bezüglich des Funktionsumfangs hat das Wiki ähnlich den hier vor gestellten Systemen Einiges zu bieten. So werden Daten gleich wie beim JSPWiki oder dem PHPWiki
in Plain-Text abgelegt, auf ein zusätzliches Datenbank-System wird also verzichtet.
Der Vorteil bei dieser Art der Datenverwaltung ist jener, dass Daten leichter strukturiert,
kopiert oder verschoben werden können [Moeller 2003b]. Auf der Wiki-eigenen Homepage wirbt Thoeny auch gerne mit dem Schlagworten „Structured Wiki“.
Auf User Ebene werden die Daten in Webs, Topics und Attachments eingeteilt, wobei
ein Web als Themengruppe (Kategorie) angesehen wird. Topics sind, wie der Name
schon vermuten lässt, einzelne Dokumente in einem Web-Archiv, wobei diese hierarchisch geordnet werden können. Ein Topic selbst enthält neben dem eigentlichen Textinhalt einer Seite auch Daten wie Autor, Zeitpunkt der Erstellung, Revisionsdatum, Meta-Daten und so weiter An ein Topic angehängt werden die Attachments, welche bis zu
10 MB groß sein dürfen. [Seibert 2008]
72
Als Aufzeichnungssprache (Wiki-Syntax) wird TML verwendet, wobei die Ausgabe am
Browser in CCS und XHTML 1.0 Transitional erfolgt. Für das Arbeiten an einem Dokument von gleichzeitig mehreren Editoren unterstützt das System das Konzept der
Conflict Resolution. [Wikimatrix 2008b]
Für Erweiterungsmöglichkeiten stehen dem User eine Reihe von Plugins zur Verfügung (insgesamt über 300) wobei auch eine API mitgeliefert wird, um eigene Module
zu implementieren. So steht zum Beispiel für den Medienexport ein PDF-Plugin bereit,
um ein Dokument direkt als PDF-Datei für den Download verfügbar zu machen. Darüber hinaus steht auch ein Template-Modul bereit, um den Standard-Style des Systems auf seine individuellen Bedürfnisse anzupassen. [TWiki 2008]
Bezüglich der Zugriffskontrolle bietet das TWiki ähnlich dem JSPWiki auch feine Abstimmungsmöglichkeiten an, so werden zum Beispiel Features wie ACLs auf PageEbene unterstützt. Aber auch eine Zugriffskontrolle über eine Gruppenverwaltung wird
unterstützt. Als Authentifizierungsbackend können Apache Webserver Features wie
LDAP, NIS, AD oder Kerberos verwendet werden. [Wikimatrix 2008b]
Zu guter Letzt noch ein paar Worte zum Thema Community-Support und Suche.
Um mit anderen Usern in Kontakt zu treten, unterstützt das TWiki Features wie Blogs,
Foren- und Kommentarfunktion. Aber auch ein integriertes Email-Notifikation-System
ist vorhanden.
Was die Suche anbelangt, so wird eine globale Schnellsuche angeboten, aber auch
eine erweiterte Volltextsuche. Als Searchengine kommt das UNIX Tool „find“ und
„grep“ zum Einsatz, was bei größeren Dokumentensammlungen dazu führen kann,
dass diese leider versagt [Moeller 2003b].
73
Abbildung 18: Das Twiki
6.1.5 DokuWiki
Gleich wie das MediaWiki ist das in weiterer Folge vorgestellte DokuWiki ein in PHP
implementiertes Wiki-System. Im Unterschied zu seinem „großen“ Bruder benötigt die
Software aber keine zusätzliche Datenbank, um Daten ablegen zu können. Beiträge
werden als Plain-Text im Filesystem abgelegt. Dies hat den großen Vorteil, dass das
Wiki recht simpel zu installieren ist, da lediglich ein Webserver mit PHP Interpreter benötigt wird.
Entwickelt wurde das System von einem Deutschen namens Andreas Gohr. Der erste
Release Kandidat wurde im Jahr 2004 veröffentlicht, wobei das Wiki ein Jahr später
noch einmal komplett überarbeitet wurde. Heute ist das Dokuwiki laut WikiMatrix.org
„das“ Wiki, für welches sich die meisten Benutzer interessieren [Moeller 2003b]. Die
zurzeit aktuellste Version ist vom 5.5.2008 (Stand 17.12.2008). Für die Installation
empfiehlt DokuWiki das PHP Package in der Version 4.3.10. Aber auch bis zur Version
4.3.3 ist das Wiki-Funktionsfähig, wobei aus Sicherheitsgründen davon abzuraten ist.
Natürlich wird darüber hinaus PHP in der Version 5.x unterstützt. [DokuWiki 2008]
Hinsichtlich der Codebase ist zu sagen, dass diese recht überschaubare Maße hat, in
der man sich schnell zu Recht findet. Nachteil hierbei ist, dass das Wiki nach dem
74
Funktionalen Programmiermodell entwickelt wurde, was auf den zweiten Blick doch
einige Redundanzen im Code erkennen lässt.
Bezüglich Erweiterbarkeit implementiert das DokuWiki ein Plugin-System, deren
Sammlung mittlerweile recht ansehnlich ist. So stehen dem User fast über 300 Plugins
zur Verfügung. [DokuWiki 2008]
Was die Seiten-Zugriffskontrolle anbelangt, so werden hierfür ACLs verwendet. Aber
auch eine dezidierte Kontrolle über den Mime-Typ beim Upload von Daten stehen zur
Verfügung. Die Konfiguration erfolgt hierfür (ein wenig umständlich) über eines der
insgesamt sechs Konfigurationsdateien. [Dokuwiki 2008]
Um eine Seite zu erstellen, stehen dem User neben einer homogenen Wiki-Syntax
auch Möglichkeiten, wie „Diff“- und „History“-Funktion zur Verfügung. Ältere Versionen
werden dabei in gezippten Dateien abgelegt. Darüber hinaus besteht die Option, Artikel
gleichzeitig mit mehreren Usern zu bearbeiten. [Fuecks 2004]
Um mit Usern in Kontakt zu treten, werden Features wie Kommentare und Blogging
unterstützt. Eine Forenfunktion wird nicht dezidiert angeboten. [Wikimatrix 2008b]
Was die Strukturierung von Wiki-Seiten anbelangt, so stehen dem User Namespaces
zur Verfügung, um Beiträge thematisch zusammen zu fassen. Aber auch eine übersichtliche Index-Page erleichtert die Navigation durch das Wiki. Des Weiteren werden
Statistikseiten wie „Recent-Changes“ und „Wanted-Pages“ unterstützt, aber auch ein
Analyse-Tool steht bereit. [Dokuwiki 2008]
Bezüglich der Ausgabe werden folgende Features angeboten [Wikimatrix 2008b]:
•
XHTML 1.0 Transitional + CSS
•
Print CSS
•
PDF
•
RSS
Zu guter Letzt sei noch die Suche erwähnt. Auch hier unterstützt das System eine einfache Keywordbasierte Suche über das globale Suchfeld. Aber auch eine eigens entwickelte Volltextsuche wird implementiert. Die Indizierung der einzelnen Wiki-Seiten
erfolgt hierbei über (die aus der Webstatistik bekannten Technik) Webbugs. Kleine 1x1
Pixel große „unsichtbare“ Bilder, welche der Suchmaschine Aufschluss darüber geben,
ob eine Seite indiziert werden muss oder nicht. [Dokuwiki 2008]
75
Abbildung 19: Das DokuWiki
6.2
Anforderungsanalyse
In diesem Kapitel werden die bereits vorgestellten Wiki-Systeme an Hand der zu Beginn des Kapitels 6 dar gebrachten Kriterien näher diskutiert. Ziel dabei ist, eine geeignete Softwarelösung zu finden, mit der das Konzept Austria-Forum in technischer Hinsicht am „Besten“ umgesetzt werden kann.
Vergleicht man die fünf Systeme hinsichtlich der zuvor erwähnten Kriterien, so ergibt
sich die in Tabelle 7 dargestellte Auswertung. Vor allem die drei Systeme MediaWiki,
JSPWiki und DokuWiki stechen dabei ins Auge, da diese am Besten in diesem Vergleich abschneiden. Warum sich das FlexWiki für das weitere Vorhaben nicht eignet,
ist schnell erklärt.
So fehlen beispielsweise rudimentäre Features wie guter Hersteller-Support (eine ausgedehnte Dokumentation des Systems ist leider nicht vorhanden), Printability (zwar
gibt es einen Print-View, aber ein PDF-Export existiert nicht) oder auch die Usability
des Systems, in dem man sich leider nur schwer zurechtfinden kann.
76
Das Twiki, obwohl es sich vor allem als Softwarelösung für kleine und mittlere Unternehmen anbietet und sogar als Enterpriselösung in bekannten Firmen eingesetzt wird,
scheidet aus folgenden drei Gründen aus:
•
Zwar ist die Volltextsuche gut für einen kleinen Dokumentenbestand, doch sind die
UNIX-Tools „find“ und „grep“ für ein größeres Volumen zu langsam, wie ein Test
der Computerfachzeitschrift C’T zeigt.
•
Des Weiteren ist das System in seiner Gesamtheit für versiertere User ausgelegt,
weshalb die Usability für den herkömmlichen Internetbenutzer zu umständlich erscheint.
•
Darüber hinaus ist nicht sicher, inwieweit sich das Projekt weiterentwickeln wird,
denn gab es erst im Oktober diesen Jahres einen heftigen Streit zwischen Gründer
Peter Thoeny und der Entwickler-Community, welcher zur Folge hatte, dass sich
die beiden Parteien getrennt haben. Die Community entwickelt seitdem ein eigenes
Projekt mit dem Namen NextWiki36. Thoeny versucht stattdessen sein Werk am Leben zu erhalten. [Heise 2008]
Die Frage, welche sich hiermit stellt ist, in wie Weit sich MediaWiki, JSPWiki und das
DokuWiki für das weitere Vorhaben eignen.
•
Userverwaltung und Security
Betrachtet man beispielsweise das Kriterium „Userverwaltung und Security“, so
schneiden alle drei Systeme fast gleich gut ab, wobei das MediaWiki keine ACLs
unterstützt und das Authentifizierungsbackend auch nicht so ausgereift scheint wie
beispielsweise beim JSPWiki, wo als Backend das Java interne Security Policy
Modul via JAAS-Files zum Einsatz kommt.
•
Strukturierung von Beiträgen
Was die „Strukturierung von Beiträgen“ anbelangt, das letzte Kriterium welches an
dieser Stelle behandelt werden soll, so muss gesagt werden, dass das JSPWiki
hinsichtlich dieses Features die schlechtere Wahl ist. Auch wenn Kategorien standardmäßig unterstützt werden, so fehlt die Option Dokumente in Namespaces miteinander zu vereinen.
•
Suche
Bezüglich der „Suche“ beziehungsweise der Volltextsuche bieten MediaWiki und
JSPWiki die beiden besten und schnellsten Konzepte an. MediaWiki ist auf Grund
des Datenbank-Backends natürlich besonders effizient, wenn es darum geht ein
großes Datenvolumen zu durchsuchen. Das JSPWiki mit der Suchmaschine Apache Lucene und einem gecachten Index ist aber nicht bedeutsam langsamer. Das
36
http://www.nextwiki.org
77
DokuWiki verfolgt zwar auch einen gecachten Ansatz, doch ist die proprietäre
Suchmaschine nicht so leistungsfähig wie die der beiden Kontrahenten.
•
Kommentare, Foren und Blogs
Hinsichtlich der Features Kommentar-, Forum- oder Blog-Funktion bietet auch hier
das JSPWiki die größere Auswahl an. Vor allem fehlt beim MediaWiki ein Blog Modul. Beim DokuWiki ist diese Option zwar vorhanden, doch fehlt dort die Forumsfunktion komplett.
•
XHTML,CSS, RSS und PDF Ausgabe
Bezug nehmend auf die „Ausgabe“ muss gesagt werden, dass hier das JSPWiki als
knapper Gewinner hervorgeht. Auch wenn alle drei Systeme RSS, CSS und
XHTML als Ausgabeformate angeben, so überzeugt das JSPWiki durch die Verwendung des Standards XHTML 1.0 Strict, wohingegen sich MediaWiki und DokuWiki mit dem Standard XHTML 1.0 Transitional begnügen.
•
Mediensupport
Was den Mediensupport anbelangt, gewinnt hier das MediaWiki. Auch wenn das
JSPWiki diesbezüglich fast die gleichen Features anbietet, steht dem User nur eine
einfache Mediensuche über den Dateinamen zur Verfügung, wohingegen beim
MediaWiki eine Keywordsuche möglich ist. Beim DokuWiki wird diese Option leider
nicht geboten. Auch fehlt die Funktion einer Medienrevision.
•
Conflict Management
Vergleicht man die Systeme hinsichtlich des Kriteriums „Conflict Management“, so
muss gesagt werden, dass das MediaWiki das beste Konzept anbietet. Zwar
kommt es in allen drei Systemen zu keinen „Dirty-Writes“, doch können beim
JSPWiki und beim DokuWiki zwei oder mehrere User keinen Beitrag gleichzeitig
bearbeiten, auch wenn es dabei zu keinem Konflikt kommen würde. JSPWiki und
DokuWiki sperren den gesamten Artikel für die Bearbeitung anderer Benutzer, wohingegen beim MediaWiki der Ansatz Konflikt-Resolution verfolgt wird.
•
Herstellersupport
Ein weiteres wichtiges Kriterium für die Auswahl ist der „Herstellersupport“, denn
soll das System erweitert werden und hierfür ist eine gute Dokumentation anbieten.
Auch hier schneiden JSPWiki und DokuWiki am Besten ab, denn bieten diese beiden Systeme den meisten Support in diese Richtung an. Was beim MediaWiki
missfällt ist die schlechte Code Dokumentation.
•
Datastorage
Hinsichtlich des Kriteriums „Datastorage“ schneidet das JSPWiki mit Abstand am
Besten ab, denn bietet es auf Grund seiner Architektur die günstigsten Voraussetzungen dafür um proprietäre Konzepte umzusetzen.
•
78
Erweiterbarkeit
Hinsichtlich „Erweiterbarkeit“ geht auch hier das JSPWiki als klarer Sieger hervor,
denn werden eine Unmenge an Modulen geboten, um das System in allen Belangen zu expandieren. Neben Plugins, Templates, werden auch noch Wiki Variablen
oder das Filter-, Edit- oder Formmodul angeboten, ganz abgesehen vom abstrakten
Programmier-Model, das leichte und saubere Erweiterungen auf Codeebene zulässt. Das MediaWiki und das DokuWiki bieten zwar auch ein Plugin und Template
Konzept an, doch sind Erweiterungen auf Codeebene bei Weitem schwerer zu vollziehen, da die Programmstrukturen weniger gut voneinander getrennt sind. Zwar
verfolgt das MediaWiki einen Objektorientierten Ansatz, doch ist die Abstraktionsebene viel zu niedrig angesetzt.
•
Code und Programmiersprache
Was das Kriterium „Code und Programmiersprache“ anbelangt, so muss gesagt
werden, dass hier eindeutig das JSPWiki als Sieger hervorgeht, da es in der Programmiersprache Java implementiert ist. Eine saubere Trennung zwischen Code
und Präsentation, Robustheit, Stabilität, eine Vielzahl an Tools und eine breite
Community zeichnen dieses also besonders aus. Das MediaWiki und das Dokuwiki
können in dieser Hinsicht nicht mithalten, denn sind beide in der Programmiersprache PHP implementiert. Der einzige Vorteil, der hierbei gesehen werden kann ist,
dass für die Exekution des Codes, da es sich um eine interpretierte Programmiersprache handelt, kein Restart des Servlet-Containers von Nöten ist. Trotz dessen
fehlen aber Programmiertools, Typensicherheit oder ein ausgewachsenes Exceptionhandling.
•
Print-Friendly
Vergleicht man die drei Wikis hinsichtlich des Kriteriums Printability, so muss gesagt werden, dass sowohl das MediaWiki als auch das JSPWiki und das DokuWiki
gleichen Support bieten.
Zum Schluss seien die drei Systeme noch hinsichtlich der Kriterien „Wiki-Syntax“ und
„Usability“ miteinander verglichen:
•
Wiki-Syntax
Bezüglich „Wiki-Syntax“ muss gesagt werden, dass alle drei Systeme gleich gut
bewertet werden müssen. Auch wenn das JSPWiki vom Funktionsumfang vielleicht
den geringeren Support anbietet, so besticht es durch seine einfache Syntax. Vor
allem wird auf die Verwendung von HTML-Tags verzichtet, was den Wiki-Code an
sich homogener erscheinen lässt als den der beiden Kontrahenten.
•
Usability
Was die „Usability“ anbelangt, muss hier dem MediaWiki der Vortritt gewährt werden. Die klare Anordnung der Schaltelemente und die intuitive Handhabe derer,
79
macht das Wiki in dieser Hinsicht knapp aber doch zum Gewinner in dieser Kategorie.
Tabelle 7: Vergleich der 5 Wikis MediaWiki, FlexWiki, JSPWiki, TWiki und DokuWiki
Media
Wiki
Flex
JSP
Wiki
Wiki
Security Features
o
++
+
++
+
Userverwaltung
+
++
++
+
++
Strukturierung
++
o
+
++
++
Suche
++
+
++
--
+
Kommentare, Forumen, Blogs
o
--
+
+
o
XHTML,CSS, RSS, PDF
+
-
++
+
+
Media (Video, Audio, Flash)
++
--
++
++
o
Conflict Management
++
o
o
++
o
Hersteller Support
o
--
++
o
++
Datastorage
o
+
++
o
o
Erweiterbarkeit
o
++
++
+
o
Code&Programmiersprache
+
+
++
o
o
Printer Friendly
++
-
++
+
++
Syntax
+
-
+
+
+
Usability
++
--
+
-
+
Kriterien
TWiki
Doku
Wiki
++ Sehr Gut, + Gut, o Befriedigend, - Genügend, -- Nicht Genügend
6.3
Fazit
Insgesamt betrachtet muss gesagt werden, dass das JSPWiki das wohl bessere System ist, wenn es darum geht, das Konzept Austria-Forum hinsichtlich der geforderten
Kriterien umzusetzen. Vor allem besticht das System sowohl durch sein flexibel einsetzbares und leicht erweiterbares Datastorage-Modul als auch durch die gute Userverwaltung.
Auch das Kriterium Suche wird in jeglicher Hinsicht gut realisiert. Die Ausgabe in
XHTML 1.0 Strict überzeugt und das Kriterium Printability ist auch erfüllt. Darüber hinaus entspricht das Wiki bezüglich der Usability fast alle gewünschten Anforderungen.
Durch die ausgezeichnete Codebase, die vielen Möglichkeiten der Erweiterungen und
den glänzenden Support sollte es aber kein Problem darstellen, das System auf die
noch gewünschten Features zu erweitern.
7 Implementierung
7
80
Implementierung
In diesem abschließenden Kapitel dieser Arbeit sollen folgende Dinge behandelt werden: Im ersten Teil dieses Kapitels werden die „Erweiterungsmöglichkeiten“ des
JSPWikis näher erörtert, vor allem um klar zu machen, wie flexibel und anpassungsfähig das System ist. Im zweiten Teil dieses Kapitels wird darüber berichtet, was tatsächlich implementiert wurde um das Konzept einer - zitierfähigen Online-Enzyklopädie mit
vorwiegend österreichischen Inhalten - zu realisieren.
7.1
JSPWiki Erweiterungsmöglichkeiten
Wie schon in Kapitel 6 dieser Arbeit erwähnt, bietet das JSPWiki eine Reihe von
Erweiterungsmöglichkeiten an, die hier näher erörtert werden sollen. Als diesem
Kapitel zu Grunde liegende Quellen, können die beiden Ressourcen [JSPWiki 2008]
und [JSPWikiDoc 2008] genannt werden.
7.1.1 Plugins
Zum wohl wichtigsten und rudimentärsten Erweiterungsfeature des JSPWikis können
mit Sicherheit die so genannten JSPWiki-Plugins gezählt werden. Vor allem um das
System in funktionaler Hinsicht zu erweitern, müssen dieses als „unabdingbares Feature“ bezeichnet werden.
Laut Herstellerseite stehen dem Anwender fünfundzwanzig so genannte Core-Plugins
zur Verfügung. Darunter zum Beispiel ein IndexPlugin, mit dem es möglich ist, alle im
System vorhandenen Wiki-Seiten namentlich in alphabetischer Reihenfolge sortiert
auszugeben, ein InsertPagePlugin, um bereits vorhandene Wiki-Pages zu inkludieren
oder ein SearchPlugin, mit dem es möglich ist, auf die Suchmaschinenroutinen des
Systems zuzugreifen und noch vieles mehr.
Zuzüglich existiert eine lange Liste von Contributed-Plugins. Darunter zum Beispiel ein
DrawingPlugin, mit dem es möglich ist, Grafiken direkt in einer Wiki-Seite zu erstellen,
ein GoogleMapsPlugin, um geografische Daten direkt via Google Maps anzeigen zu
lassen oder ein MathPlugin, um mathematische Formeln, in Latex verfasst, direkt aus
einer Wiki-Seite heraus anzeigen zu lassen.
Das Einbinden eines Plugins erfolgt ähnlich dem Einbinden eines Hyperlinks oder eines Bildes via Wiki-Syntax, wobei folgende syntaktische Regeln gelten:
7 Implementierung
81
Listing 2: JSPWiki Plugin
[{INSERT <plugin class> WHERE
<param1=value1>,<param2=value2>,...}]
Die Parameter Liste und das Tag WHERE sind hierbei optional zu sehen. Seit Version
1.6.3 kann eine Schreibweise auch ohne dem einleitenden Tag INSERT erfolgen.
Um Plugins selbst zu implementieren, steht auf Codeebene ein recht simples Interface
mit dem treffenden Namen WikiPlugin zur Verfügung. Aufgerufen wird vom System die
Funktion execute, wobei die beiden Parameter vom Typ WikiContext und Map mit übergeben werden. Die Ausgabe erfolgt über den Typen String, womit in der Regel
HTML-Codes gemeint sind.
Listing 3: Das JSPWiki Plugin Interface
public interface WikiPlugin {
public String execute( WikiContext context, Map params )
throws PluginException;
}
7.1.2 Filter
Das Filter-Modul zählt zu einer der neuesten Erweiterungsmöglichkeiten. Es wurde in
der Version 2.2 erstmalig eingeführt und dient, wie der Name schon ahnen lässt, dazu
den Ein- und Ausgabeprozess zu manipulieren.
Insgesamt werden vier Einstiegsstellen angeboten:
•
Vor dem ersten Konvertierungsschritt, bevor aus Wiki-Syntax HTML Code generiert
wird
•
Nach dem ersten Konvertierungsschritt, nach der Konvertierung aber vor dem httpRequest SEND
•
Vor dem Ablegen einer Wiki-Seite mittels Datastorage-Modul
•
Nach dem Ablegen einer Wiki-Seite mittels Datastorage-Modul
Wie auch das Plugin Modul eine Reihe von Kern-Funktionen zur Verfügung stellt, so
stehen auch hier drei Grundfilter zur Verfügung:
•
der PingWeblogsCom-Filter
•
der Profanity -Filter
•
der Spam-Filter
7 Implementierung
82
Mit Hilfe des PingWeblogsCom-Filter ist es möglich, den Weblog-Bereich einer JSPWiki-Seite zu filtern. Der Profanity-Filter stellt die gleiche Funktionalität wie der PingWeblogsCom-Filter zur Verfügung, nur mit dem Unterschied, dass die Filteroperationen
auf eine ganze Seite angewendet werden können. Der Spam-Filter ist der umfangreichste aller drei hier vorgestellten und implementiert eine Reihe von Möglichkeiten,
um das JSPWiki Spam frei zu halten.
Um einen Filter selbst auf Codeebene zu definieren, steht das Interface PageFilter zur
Verfügung. Wie schon zu vor erwähnt, steht es dabei frei, wo die Filterung stattfinden
soll. Die Funktion initialize wird, wie der Name schon sagt, beim Initialisieren eines Filters aufgerufen, wohingegen mit der Funktion destroy abschließende Operationen
durchgeführt werden.
Listing 4: Das PageFilter Interface
public interface PageFilter {
public void initialize( WikiEngine engine,
Properties properties ) throws FilterException;
public String preTranslate( WikiContext wikiContext, String
content ) throws FilterException;
public String postTranslate( WikiContext wikiContext,
String htmlContent ) throws FilterException;
public String preSave( WikiContext wikiContext, String content )
throws FilterException;
public void postSave( WikiContext wikiContext, String content )
throws FilterException;
public void destroy( WikiEngine engine );
}
7.1.3 Variablen
Zuzüglich zu den bereits vorgestellten Modulen bietet das JSPWiki ein integriertes Wiki-Variablen-Modul an. Folgende Typen werden unterstützt:
•
Konstante Variablen oder auch System Variablen sind vom JSPWiki Kern vordefiniert und stehen dem User quasi global auf jeder Seite zur Verfügung. Das JSPWiki
in der Version 2.8 unterstützt insgesamt fünfzehn dieser globalen Variablen.
7 Implementierung
83
•
Kontext Variablen stehen, wie der Name schon andeutet, mit einer anderen Anwendung, zum Beispiel einem Plugin, in Verbindung. Diese können beispielsweise
dazu verwendet werden, um Anwendungen zu konfigurieren oder aber auch, um
Werte auszulesen.
•
Property Variablen sind eine sehr angenehme und vor allem simple Lösung, wenn
es darum geht, Werte aus dem jspwiki.properties File auszulesen.
•
Page Variablen dienen dem Benutzer dazu selbst Variablen in einer Wiki-Seite zu
definieren.
Um eine Variable zu definieren ist folgende Sytax zu verwenden:
Listing 5: Syntax für JSPWiki Variablen
[{SET <name>=‘<value>’}]
Mit Hilfe der Syntax [{<name>}] können JSPWiki Variablen in einer Wiki Page aufgerufen werden.
7.1.4 Forms
Die JSPWiki-Forms stellen ein weiteres leicht zu handhabendes Feature dar, wenn es
darum geht, das Wiki hinsichtlich (HTML) Formular-Funktionen zu erweitern, wobei
folgende Elemente angeboten werden:
•
Das FormOpen Elements wird, wie der Name schon vermuten lässt, dazu verwendet, um ein Formular einzuleiten. Des Weiteren stehen Parameter wie form, submit,
method oder hide zur Verfügung. Die Wertezuteilung der einzelnen Parameter erfolgt hierbei einem an HTML angelehnten Schema.
Listing 6: Das FormOpen Element
[{FormOpen form=‘meinFormName’ submit=‘/servlets/halloWelt’
method=‘post’ hide=‘onsuccess’]
•
Das CloseForum Element dient dazu, um Formulare zu schließen. Eine Parametrisierung ist hierfür nicht nötig.
Listing 7: Das FormClose Element
[{FormClose}]
7 Implementierung
•
84
Das FormSet Element wird dazu verwendet um (wie in HTML auch üblich) Parameter und Wertezuweisungen verborgen (hidden) zu übermitteln.
Listing 8: Das FormSet Element
[{FormSet form=‘meinFormName’ msg=‘hallo’}]
•
Mit Hilfe des FormOutput Elements ist es möglich, einen eigenen FormHandler zu
definieren.
Listing 9: Das FormOutpunt Element
[{FormOutput handler=‘meinPlugin’ form=‘meinFormName’}]
[{FormOpen form=‘meinFormName’}]
...
[{FormClose}]
•
Natürlich stehen dem Benutzer auch die gewohnten (HTML) Steuerelemente FormInput, FormSelect und FormTextarea zur Verfügung. Die Parametrisierung der Elemente FormInput und FormTextarea ist hierbei zu den beiden HTML Pendants
identisch, nur die Parametrisierung des Elementes FormSelect erfolgt auf eine etwas ungewohnte Art und Weise. So kann beispielsweise ein eigener Parameter
seperator definiert werden, um FormSelcet Values zu splitten. Des Weiteren wird
über einen eigens ausgeführten Parameter selector definiert, welcher Wert zur Anzeige gebracht werden soll.
Listing 10: Die Elemente FormSelect, FormTextarea und FormInput
[{FormSelect name=‘feld1’ separator=‘,’ selector=‘!’
value=‘eins,zwei,!drei’}]
[{FormTextarea name=‘feld2’ value=‘Hallo’ rows=5 cols=10}]
[{FormInput type=‘submit’ value=‘Send!’ name=‘feld3’}]
7.1.5 Editor Modul
Zuzüglich zu den bereits erwähnten Erweiterungsmöglichkeiten bietet das JSPWiki die
Option an, über ein eigens ausgeführtes Modul Editoren auszutauschen oder hinzuzufügen.
Standardmäßig enthalten ist ein Modul mit dem treffenden Namen „PlainEditor“, um
Beiträge via Wiki-Syntax zu erzeugen (siehe Abbildung 20).
7 Implementierung
85
Abbildung 20: Der Standardeditor PlainEditor
Aber auch eine Reihe von Contributed-Editoren stehen zur Verfügung. Darunter zum
Beispiel bekannte WYSIWYG Editoren wie TinyMCE37 oder FCKeditor38.
Abbildung 21: Der WYSIWYG Editor TinyMCE
37
38
http://tinymce.moxiecode.com
http://www.fckeditor.net
7 Implementierung
86
7.1.6 Templates und Styles
Um den View (Ansicht) beziehungsweise das Aussehen anzupassen, stehen zwei wesentliche Konzepte zur Verfügung: Die der Templates und die des Page-Stylings via
CSS-Stylesheets.
Mit der Hilfe eines Templates kann die Seitenstruktur angepasst werden. Um die Strukturen im Aussehen zu definieren werden Styles herangezogen, wobei JSPWiki zwischen dynamischen, dem User zur Verfügung gestellten, und dem Site-Admin vorbehaltenen Styles unterscheidet. Bei den in zweiter Folge genannten handelt es sich um
herkömmliche CSS-Sheets, um Templates auf das gewünschte Äußere anzupassen.
Beim den dynamischen hingegen handelt es sich um aufwendig in JavaScript codierte
und dem User in Wiki-Syntax zur Verfügung gestellte Styles. Auch wenn der Programmieraufwand ungleich höher ist, um dynamische Styles zu implementieren, lohnt es
sich, denn können so zum Beispiel dynamisch kollabierende Tabellen oder Tab-Listen
angeboten werden welche zudem sogar druckbar sind.
Um das allgemeine Aussehen anzupassen, steht, wie schon zuvor erwähnt, ein Template-System zur Verfügung, wobei standardmäßig eine Reihe von Vorlagen im Installationspackage enthalten sind. Um selbst ein Seiten-Template zu erstellen, ist es notwendig, einige Anpassungen vorzunehmen. So muss beispielsweise im jspwiki.proterties File der Parameter jspwiki.templateDir=<Templateordner> ge-
setzt werden. Des Weiteren müssen die (insgesamt zehn) JSPWiki CorePages in den
zuvor definierten Ordner kopiert und angepasst werden. Natürlich steht es auch frei,
selbst Funktionen zu definieren, doch ist es ratsam sich zuerst mit den in den JSPWiki
CorePages vorhandenen Funktionen vertraut zu machen.
Tabelle 8: JSPWiki CorePages, entnommen aus [JSPWiki 2008]
CorePages
JSP File
view
PageContent.jsp
diff
DiffContent.jsp
info
InfoContent.jsp
preview
PreviewContent.jsp
conflict
ConflictContent.jsp
find
FindContent.jsp
prefs
PreferencesContent.jsp
error
DisplayMessage.jsp
edit
EditContent.jsp
comment
CommentContent.jsp
7 Implementierung
87
Abbildung 22: JSPWiki im WikiMedia Style von Martin Unger, entnommen aus
[JSPWiki 2008]
7.1.7 Datastorage
Wie schon in Kapitel 6 beschrieben, stellt das JSPWiki ein besonders leicht anzupassendes Datastorage-Modul zur Verfügung. So existiert auf Codeebene ein Interface mit
dem treffenden Namen WikiPageProvider, von dem ausgehend sämtliche DatastorageKonzepte umgesetzt werden können.
Listing 11: Das Interface WikiPageProvider
public interface WikiPageProvider
extends WikiProvider
{
public void putPageText( WikiPage page, String text )
throws ProviderException;
public boolean pageExists( String page );
public Collection findPages( QueryItem[] query );
public WikiPage getPageInfo( String page, int version )
7 Implementierung
88
public Collection getAllPages()
public Collection getAllChangedSince( Date date );
public int getPageCount()
public List getVersionHistory( String page )
public String getPageText( String page, int version )
public void deleteVersion( String pageName, int version )
public void deletePage( String pageName )
public void movePage(String from, String to)
}
Prinzipiell wird zwischen zwei Typen von PageProvidern unterschieden. So gibt es auf
der einen Seite die Klasse der FileProvider und auf der anderen Seite die der WikiAttachmentProvider. Diese Unterscheidung wird aus folgendem Grund getroffen: Anders
als bei den Wiki-Systemen MediaWiki oder PHPWiki werden externe Ressourcen wie
Bilddaten, Videoarchive, etc. nicht global gespeichert und als solche behandelt, sondern als ein lokales, einer Wikipage zugehöriges Objekt betrachtet.
Um nicht selbst Hand anlegen zu müssen, sind im Standardinstallationspaket drei unterschiedliche FileProvider und ein WikiAttachmentProvider enthalten:
•
der FileSystemProvider
•
der VersioningFileProvider
•
der RCSFileProvider
•
der BasicAttachmentProvider
7 Implementierung
7.1.7.1
89
Der FileSystemProvider
Die Klasse FileSystemProvider setzt das einfachste hier vorgestellte Konzept des Datastorages um. So werden Wiki-Pages in herkömmliche Textdateien konvertiert und im
Filesystem abgelegt. Zudem existiert keine Strukturierung, denn werden alle Dateien in
einen speziellen Ordner „flach“ abgelegt. Des Weiteren wird keine Versionsverwaltung
implementiert, das heißt, ältere Dateien werden einfach überschrieben. Die Interfacemethode getVersionHistory retourniert in diesem Fall also immer eine Liste der Länge
eins. Dass Methoden wie Revisionskontrolle und Differenzbildung nicht möglich sind ist
klar, weshalb auch explizit davon abzuraten ist, diese Klasse zum Einsatz zu bringen.
7.1.7.2
Der VersioningFileProvider
Die Klasse VersionFileProvider implementiert, wie der Name schon ahnen lässt, die
Funktion eines Versionskontrollmechanismus, wobei Wiki-Pages wiederum im Filesystem als Textdateien abgelegt werden. Anders als beim FileSystemProvider wird
zusätzlich ein spezieller Systemordner (OLD) angelegt, in dem alle vorherigen Versionen wiederum als Ordner abgelegt zu finden sind. Die Versionsverwaltung erfolgt im
Grunde durch einfaches numerisches Hochzählen. Zuzüglich werden noch spezielle
properties Dateien erzeugt, um Meta-Daten wie Erstellungsdatum, Autor, etc. nicht zu
verlieren.
7.1.7.3
Der RCSFileProvider
Mit Hilfe der Klasse RCSFileProvider ist es möglich, Wiki-Pages über ein so genanntes
Revision-Control-System (RCS) zu versionisieren. Auch wenn diese Klasse eine gute
Alternative zum VersioningFileProvider darstellt, so musste leider festgestellt werden,
dass es kein funktionierendes Revision-Control-System für das Betriebssystem Microsoft Windows (in allen Versionen) gibt. Zudem ist auf der Herstellerseite zu lesen, dass
die UNIX Variante vor allem mit einem großen Datenvolumen Performanceprobleme
hat, weshalb davon abzuraten ist, diesen Provider zum Einsatz zu bringen. Für nähere
Details zum Thema RCS sei an dieser Stelle auf [Tichy 1985] verwiesen.
7.1.7.4
Der BasicAttachmentProvider
Die Klasse BasicAttachmentProvider implementiert ein einfaches Datastorage-Konzept
hinsichtlich der Verwaltung externer Ressourcen. Ähnlich der Klasse VersioningFileProvider implementiert diese eine Versionskontrolle über das herkömmliche Filesystem.
Wird beispielsweise auf Anwendungsebene eine WikiPage mit dem Namen Main erstellt, so erzeugt der BasicAttachmentProvider auf Systemebene in einem definierten
Attachment-Verzeichnis den Ordner Main-att. Wird auf Anwendungsebene nun der
WikiPage zum Beispiel eine Datei test.png angehängt, so wird auf Systemebene im
Verzeichnis Main-att ein Ordner test.png-dir erzeugt, wobei die Datei unter dem Namen
7 Implementierung
90
1.png abgespeichert wird. Zudem wird wiederum ein properties File erzeugt, in dem
Meta-Daten abgelegt werden.
Abbildung 23: Versionsverwaltung des BasicAttachmentProviders auf FilesystemEbene
7.1.8 Security Modul
Wie schon in Kapitel 6 erwähnt, bietet das JSPWiki ein flexibles und leicht anzupassendes Security Modul an. In weiterer Folge soll dieses kurz vorgestellt werden.
7.1.8.1
Authentifizierung
Prinzipiell stehen dem Benutzer eines JSPWikis folgende Authentifizierungsmöglichkeiten offen:
•
anonym
•
asserted
•
authentifiziert
•
admin
Anonym ist ein Benutzer dann, wenn dieser vom JSPWiki eindeutig identifiziert werden
kann, was bedeutet, dass keine Anmeldung stattgefunden hat und kein Cookie am
Rechner des Users gespeichert werden konnte.
Wird ein Benutzer als asserted betrachtet, so ist zwar keine dezidierte Anmeldung geschehen, doch konnte der User über ein Cookie identifiziert werden.
Authentifiziert ist ein User dann, wenn eine Anmeldung mittels Benutzername und
Kennwort erfolgt ist. Des Weiteren wird ein Benutzer als Admin gewertet, wenn eine
Authentifizierung via Admin-Name und Passwort erfolgt ist.
7 Implementierung
7.1.8.2
91
Zugriffskontrolle
Um den Zugriff auf das JSPWiki zu steuern, stehen insgesamt zwei wichtige Kontrollmechanismen zur Verfügung: Controll Listen (ACLs) auf Page-Ebene und die JAVA2
Security Policy mit den JAAS Konfigurationsdateien für eine allgemeine Zugriffskontrolle, wobei folgende drei Ebenen kontrolliert werden können:
•
die Benutzerebene (einzelne Personen)
•
die Gruppenebene (Benutzer können in Gruppen zusammengefasst werden)
•
die Rollenebene (Benutzer können speziellen Rollen zugeordnet werden)
Wie schon zuvor erwähnt, erfolgt die Zugriffskontrolle auf Page-Ebene über ACLs. Insgesamt können fünf Zugriffsprivilegien definiert werden, welche wie folgt lauten:
•
view
•
edit
•
comment
•
rename
•
delete
Da die einzelnen Zugriffsregeln selbst erklärend sein sollten, wird an dieser Stelle auf
eine detaillierte Beschreibung verzichtet.
Um nun die gewünschten Zugriffsrechte auf Page-Ebene zu setzten, ist es notwendig,
ein Plugin mit folgender Syntax einer JSPWiki-Seite hinzuzufügen:
Listing 12: ACL Syntax
[{ALLOW <BenutzerPrivilegien> <Benutzer>}]
Konkrete Beispiele hierfür wären:
Listing 13: ACL Beispiel
[{ALLOW view Christoph,Anonym}]
[{ALLOW edit Denis, Christoph, Hermann}]
[{ALLOW delete Hermann,Admin}]
Da eine Zugriffskontrolle auf Page-Ebene zu umständlich wäre um eine Vielzahl von
Seiten zu administrieren, wird ein globales Security-Policy-Modul basierend auf der
JAVA 2 Security Policy und den JAAS Konfigurationsdateien angeboten.
Wichtig hierbei: Zugriffsregeln, welche mittels JAAS Konfigurationsdateien erstellt werden, wirken stärker als jene der ACLs. Es ist also zum Beispiel nicht möglich, mittels
ACL einem anonymen Benutzer zu erlauben eine Seite zu editieren, wenn dies zuvor
7 Implementierung
92
in der JAAS Konfigurationsdatei unterbunden wurde. Der JAAS Konfigurationsfile ist im
Übrigen im Ordner WEB-INF unter dem Namen jspwiki.policy zu finden und kann
selbstverständlich auf die eigenen Bedürfnisse angepasst werden. In Tabelle 9 sind die
Grundeinstellungen des jspwiki.policy Files in komprimierter Form zusammengefasst dargestellt.
Tabelle 9: Standard Security Policy Einstellungen von JSPWiki, entnommen aus
[JSPWiki 2008]
Zugriffsrechte
Anonym
Asserted
Authentifiziert
Admin
Alle Seiten betrachten
x
x
x
x
Alle Seiten Editieren
x
x
x
x
Upload von
Attachments
x
x
Alle Seiten modifizieren
x
x
Kommentare
schreiben
x
x
x
x
Neue Seiten erstellen
x
x
x
x
x
x
Seiten umbenennen
Seiten
löschen
x
Alle Gruppen
betrachten
x
x
x
Alle Gruppen
editieren
x
x
Alle Gruppen
umbenennen
x
x
Alle Gruppen
löschen
x
Neue Gruppen
erstellen
x
x
x
x
Editieren der
User Präferenzen
x
x
Editieren des
User Profils
x
x
Neues profil erstellen
x
x
7 Implementierung
7.2
93
Anpassungen und Featureset
Wie schon in Kapitel 6 dieser Arbeit beschrieben, konnte festgestellt werden, dass sich
das JSPWiki am Besten dazu eignet, das Konzept Austria-Forum in technischer Hinsicht zu realisieren, denn sind bereits (fast) alle gewünschten Funktionen vorhanden
um darauf aufbauen zu können.
Aus diesem Grund wurde das JSPWiki auch weitestgehend in seiner Standardkonfiguration übernommen. In den hier folgenden Kapiteln nun eine Zusammenfassung dessen, was bis dato (Stand: 14 Jänner 2009) implementiert wurde und was das System
zu leisten vermag.
7.2.1 Strukturierung von Daten
Um Beitragsstrukturierungen vorzunehmen, bietet das JSPWiki standardmäßig die
Möglichkeit an, Kategorien über ein (Category) Plugin zu definieren. Doch musste festgestellt werden, dass diese Option nicht dafür eignet ist, um auch auf FilesystemEbene Strukturierungen vorzunehmen. Da das System eine Kategorisierung sowohl
auf Anwenderebene als auch auf Systemebene möglich machen soll, mussten deshalb
eine Reihe von Anpassungen vorgenommen werden.
Die gewünschte URL Notation wurde wie folgt definiert:
Listing 14: URL Codierung
http://www.austria-forum.org/<CategoryName>
http://www.austria-forum.org/<CategoryName>/<CategoryName>/...
Die Abbildung auf Filesystem-Ebene wurde ähnlich definiert, denn wird für jeden CategoryName ein gleichnamiges Verzeichnis erstellt. Des Weiteren wurde definiert, dass
Inhalte einer Wiki-Page als Textdateien auf gleicher Ebene wie das CategoryNameVerzeichnis abgelegt werden sollen.
Listing 15: Die angepasste Verzeichnisstruktur des JSPWikis
<WebRootDir>/<CategoryName>
<WebRootDir>/<CategoryName>.txt
Um diese Form der Datenspeicherung und Verwaltung zu unterstützen, mussten an
zwei wesentlichen Stellen im Code Änderungen vorgenommen werden.
Die erste Änderung erfolgte in der Klasse MarkupParser. Um auch eine Slashdot Notation für die URL Eingabe zu ermöglichen, mussten die beiden Konstanten LEGA-
7 Implementierung
94
CY_CHARS_ALLOWED und PUNCTUATION_CHARS_ALLOWED um dieses Element
erweitert werden.
Listing 16: Die Konstanten LEGACY_CHARS_ALLOWED und PUNCTUATION_CHARS_ALLOWD
protected static final String LEGACY_CHARS_ALLOWED = “._/”;
public static final String PUNCTUATION_CHARS_ALLOWED = “ ()&+,-=._$/”;
Die größten Anpassungen mussten aber an der Klasse AbstractFileProvider vorgenommen werden. So wurden beispielsweise die Methoden findPages, getPageCount
und getAllPages abgeändert, um das gewünschte Konzept zu unterstützen.
Listing 17: Die Methoden findPages, getPageCount und getAllPages
public Collection findPages(QueryItem[] query);
public int getPageCount();
public Collection getAllPages() throws ProviderException;
Des Weiteren wurden die zwei Methoden getAllCategoryPages und getTotalCategoryPageCount hinzugefügt, um einerseits die Möglichkeit zu schaffen alle Sub-Kategorien
als Collection auslesen und andererseits, um zu erfahren wie viele Sub-Kategorien
existieren.
Listing 18: Die Methoden getAllCategoryPages und getTotalPageCount
public Collection getAllCategoryPages(String category)
public int getTotalCategoryPageCount (String category)
Um diese Methoden global zugänglich zu machen, wurde die Interface-Klasse WikiPageProvider und PageManager dementsprechend erweitert.
Auf Grund dieser Anpassungen ist es nun möglich, einerseits dem User strukturierte
und vor allem leicht zu lesende URLs zur Verfügung zu stellen und andererseits Daten
in einer übersichtlichen Form auf Filesystem-Ebene abzulegen, welche zudem leicht
exportiert und verschoben werden können.
7 Implementierung
95
7.2.2 Navigation und Browsing
Anders als beim alten System wurde besonderen Wert darauf gelegt, dass das neue
System hinsichtlich Navigation und Browsing leicht zu bedienen ist. So kann auf Grund
der architektonischen Gegebenheiten des JSPWikis ein herkömmliches Navigieren
über die Browser-Buttons Back und Forward vollzogen werden. Auch wenn noch kein
eigenes Menüfeld existiert (dieses ist bereits in Bearbeitung), stehen zurzeit eine Reihe
von Browsing Konzepten zur Verfügung:
Das Konzept des
•
FlatBrowsings (siehe Sequenz, ImageList und List Plugin)
•
Structure-Guided-Browsings (siehe CategoryIndexPlugin und GlossaryPlugin)
•
Hypertext-Browsings (wird standardmäßig vom JSPWiki unterstützt)
•
Tabbed-Browsings (siehe TabbedGlossaryPlugin)
Des Weiteren wurde eine „Bread-Crumbs“-Funktion (siehe CategoryPathTag) implementiert, um ein leichteres Navigieren und Orientieren im System zu ermöglichen.
7.2.2.1
Das Sequenz, ImageList und List Plugin
Um dem User die Möglichkeit zu geben, auch ebenenweise durch das System zu
browsen, wurden drei wesentliche Plugins implementiert.
Das erste und vielleicht wichtigste trägt den Namen List und ermöglicht es, aus einer
Kategorie eine Listendarstellung zu generieren, wobei die Option besteht selbst eine
Sequenz zu definieren.
Für das Einbinden dieses Plugins ist folgende Syntax zulässig:
Listing 19: Das List Plugin
[{list category=‘<CategoryName>’}]
[{list category=‘<CategoryName>’
sequenz=‘<Wikipage1>,<Wikipage2>,...’}]
Für das sequenzielle Durchlaufen an eine Wiki-Seite angehängter Bilddaten steht das
Plugin ImageList zur Verfügung. Es ist recht einfach gehalten, denn werden für die
Konfiguration keine zusätzlichen Parameter benötigt:
Listing 20: Das ImageList Plugin
[{ImageList}]
7 Implementierung
96
Das letzte Plugin aus der Serie der Sequenz-Plugins trägt den passenden Namen Sequenz und ist dafür zuständig, aus einer Linkliste eine Sequenzansicht zu generieren.
Da es leider nicht möglich ist, über ein Plugin den kompletten Pageview zu manipulieren, musste zusätzlich ein Filter ListFilter implementiert werden, dessen Aufgabe es ist,
Wikilinks zu eliminieren.
Um den Filter nicht an eine bestimmte Klasse zu binden, wurde die Datei filter.xml mit
dem unten dargestellten Zusatz ergänzt, um das Aufrufen dieser Methode dem FilterManager zu überlassen.
Listing 21: Ergänzungen für die Methode ListFilter in der Datei filter.xml
<pagefilters>
<filter>
<class>com.ecyrd.jspwiki.ListFilter</class>
</filter>
</pagefilters>
Um nun eine Sequenz aus mehreren Links zu erzeugen, muss das Plugin Sequenz als
erstes Element in eine Seite eingebunden werden. Mehr ist hierfür nicht notwendig,
denn das Plugin sucht selbst nach enthaltenen Linkstrukturen und stellt diese als Sequenz dar.
Listing 22: Das Sequenz Plugin
[{Sequenz}]
[WikiLink]
[WikiLink]
…
7 Implementierung
97
Abbildung 24: Ausgabe des List Plugins
Die Vorteile dieser Methode liegen auf der Hand, denn kann aus jeder beliebigen Linkliste eine Sequenz durch das einfache Hinzufügen des Plugins Sequenz erzeugt werden. Des Weiteren muss keine eigene Routine entwickelt werden, um Beiträge aus
einer Sequenz zu löschen oder zu verschieben, denn genügt hierfür ein schlichtes Löschen eines Links oder das Einfügen an der gewünschte Position.
7.2.2.2
Das CategoryIndexPlugin und GlossaryPlugin
Um ein strukturiertes Browsen im System zu ermöglichen, wurden im Wesentlichen
zwei Plugins implementiert, das CategoryIndexPlugin und das GlossaryPlugin.
Beim CategoryIndexPlugin handelt es sich um eine Möglichkeit, eine Indexansicht einer Kategorie zu erzeugen. Es ist recht simpel gehalten und kann es mit folgendem
Befehl in einer Seite eingebunden werden:
Listing 23: Das CategoryIndexPlugin
[{CategoryIndexPlugin category=‘<CategoryName>’}]
Das GlossaryPlugin stellt eine Möglichkeit zur Verfügung, um eine Glossaransicht aus
einer bestimmten Kategorie zu erzeugen. Syntaktisch dem CategoryIndexPlugin sehr
7 Implementierung
98
ähnlich, steht ein zusätzlicher Parameter col zur Verfügung um die Spaltenanzahl für
die Ausgabe selbst zu definieren. Es wird folgendermaßen zum Einsatz gebracht:
Listing 24: Das GlossaryPlugin
[{GlossaryPlugin category=‘<CategoryName>’ col=‘<SpaltenAnzahl>’}]
7.2.2.3
Das TabbedGlossaryPlugin
Eine etwas abgewandelte Form des herkömmlichen GlossaryPlugins stellt das so genannte TabbedGlossaryPlugin da. Es bietet die Möglichkeit an, aus einer Kategorie
eine Glossaransicht zu erstellen, welche einzelne Beitragsgruppen über Tabs zusammenfasst. Vor allem um große Datenbestände zu visualisieren, eignet sich dieses Plugin besonders gut.
Die zu Grunde liegenden syntaktischen Regeln für die Verwendung diese Plugins lauten wie folgt:
Listing 25: Das TabbedGlossaryPlugin
[{TabbedGlossaryPlugin category=‘<CategoryName>’}]
Abbildung 25: Ausgabe des GlossaryPlugins
7 Implementierung
99
Abbildung 26: Ausgabe des TabbedGlossaryPlugins
7.2.2.4
Das CategoryPathTag
Wie schon zuvor erwähnt, wurde auch die Möglichkeit geschaffen über eine „BreadCrumbs“-Funktion im System zu navigieren (siehe Abbildung 27 (links oben)).
Für diesen Zweck wurde eine eigene Klasse mit dem Namen CategoryPathTag abgeleitet von der Klasse WikiTag implementiert. Um diese Funktion global zur Verfügung
zu stellen, war es notwendig, die Library-Datei jspwiki.tld mit dem in weiterer Folge
dargestellten Eintrag zu ergänzen.
Listing 26: Ergänzungen für das Tag CategoryPath
<tag>
<name>CategoryPath</name>
<tagclass>com.ecyrd.jspwiki.tags.CategoryPathTag</tagclass>
<bodycontent>empty</bodycontent>
<attribute>
<name>seperator</name>
<required>false</required>
</attribute>
</tag>
7 Implementierung
100
Eingebunden wird das CategoryPathTag über das WikiTag:
Listing 27: Das CategoryPath Tag
<wiki:CategoryPath>
7.2.3 Searching
Bezüglich der Suche wurde jegliche Funktionalität des JSPWikis übernommen. Anders
als im ursprünglichen System steht dem User also nur mehr ein wesentliches SuchKonzept zur Verfügung und zwar das der „dynamischen Ajax basierten Suche“.
Auch wenn dem User ein globales Schnellsuchefeld zur Verfügung steht und zudem
eine eigene Search-Page existiert, so ist das Grundprinzip immer das Gleiche:
Wird ein Tastenanschlag im Suchfeld erkannt, so wird im Hintergrund über die Methode XMLHttpRequest eine Suchanfrage an den Server gesendet und vom JSPWiki verarbeitet. Sobald Ergebnisse vorliegen, werden diese zusammen mit den Rankingergebnissen zurück zum User geschickt und zur Anzeige gebracht. Auch wenn es sich
hierbei um eine herkömmliche Server/Client-Kommunikation handelt und die Methodik
der Suche an sich identisch zur klassischen Suchanfrage ist, so unterscheidet sie sich
dadurch, dass der Informationsaustausch im Hintergrund stattfindet, mit der Eingabe
eines neuen Zeichens passiert und kein neues Laden einer Seite von Nöten ist.
Was den Suchbereich anbelangt, so stehen insgesamt fünf Optionen zur Verfügung.
Es kann entweder gezielt nach Autoren, Beitragsnamen und Anhangsnamen gesucht
werden oder aber auch nach Seiteninhalten und in allen vier Feldern zugleich. Standardmäßig wird die letzte Variante angeboten.
7 Implementierung
101
Abbildung 27: Die Ajax basierte Schnellsuche
Abbildung 28: Die Search-Page
7 Implementierung
102
Auch die vier Methoden Editieren, Erstellen, Wiederherstellen und Vergleichen von
Beiträgen wurden zur Gänze vom JSPWiki übernommen, da alle gewünschten Features schon standardmäßig unterstützt werden. Für das dezidierte Erzeugen eines
neuen Beitrages muss zurzeit noch ein Broken-Link eingefügt werden, um zur Ansicht
„Neue Seite erstellen?“ zu gelangen. Dieses Feature soll aber in Zukunft über ein eigenes Schaltelement dem User zugänglich gemacht werden, denn so ist diese Art der
Seitenerstellung nicht allzu intuitiv.
Für das Editieren von Beiträgen stehen dem User der Standardeditor Plaineditor und
der WYSIWYG Editor FCKeditor zur Verfügung. Die für die Erstellung von Beiträgen
wichtige Wiki-Syntax wurde weitgehend übernommen. Lediglich ein Style-Element um
Tabellen leichter zu erstellen, wurde hinzugefügt.
Tabelle 10: JSPWiki-Syntax, entnommen aus [JSPWiki 2008]
Tag
Beschreibung
----
make a horizontal ruler. Extra ‘-’ is ignored.
\\
force a line break
[link]
create a hyperlink to an internal WikiPage called ‘Link’.
[this is also a
link]
create a hyperlink to an internal WikiPage called ‘ThisIsAlsoALink’ but show the link as typed with spaces.
[a sample|link]
create a hyperlink to an internal WikiPage called ‘Link’, but
display the text ‘a sample’ to the user instead of ‘Link’
~NoLink
disable link creation for the word in CamelCase.
[1]
make a reference to a footnote numbered 1.
[#1]
the footnote number 1.
[link]
create text ‘[link]’.
!heading
small heading with text ‘heading’
!!heading
medium heading with text ‘heading’
!!!heading
large heading with text ‘heading’
‘‘text’’
print ‘text’ in italic.
__text__
print ‘text’ in bold.
{{text}}
print ‘text’ in monospaced font.
[text|]
print ‘text’ underscored (dummy hyperlink)
* text
make a bulleted list item with ‘text’
# text
make a numbered list item with ‘text’
;term:ex
make a definition for ‘term’ with the explanation ‘ex’
7 Implementierung
103
7.2.5 Upload von Dateien
Um externe Dateien einzubinden beziehungsweise zu sichern, steht dem User eine
Upload-Funktion zur Verfügung. Auch dieses Modul wurde aus der Standardkonfiguration übernommen und ist über den Reiter „Anhänge“ zugänglich. Um beim Upload von
größeren Datensätzen oder langsamen Internetverbindungen nicht in Versuchung zu
kommen den Datentransfer vorzeitig abzubrechen, wird ein Progress-Balken zur Anzeige gebracht. Ebenfalls auf dieser Seite zu finden ist eine Liste aller Anhänge sowie
eine Reihe von Zusatzinformationen wie Autoren, Versionen und so weiter.
Abbildung 29: Das Tab „Anhänge“
7.2.6 Das „Info“ Tab
Um Beiträge wieder herzustellen oder miteinander zu vergleichen sowie allgemeine
Beitragsinformationen zu erhalten, steht ein eigens ausgeführtes Tab mit der Aufschrift
„Info“ zur Verfügung. Dort ist eine Diff-Funktion, um Beiträge mit einander zu vergleichen, und eine Revisions-Funktion, um Artikel wieder herzustellen, zu finden. Aber
auch eine dezidierte Liste aller ein- und ausgehender Links, Seitenversionen und Zusatzinformationen wie Beitragserzeuger, Datum, Größe, Kommentar ist vorhanden.
7 Implementierung
104
Abbildung 30: Das Tab „Info“
7.2.7 Kommunikation
Bezüglich der Kommunikation steht dem User zurzeit nur ein Mittel zur Verfügung. Über den Reiter „Weitere…“ gelangt dieser zur Kommentarfunktion. Ein Beitrag wird mit
dem Standardeditor erstellt und dem Artikel angehängt. Es wurde bewusst darauf verzichtet, eine Chatfunktion zu implementieren, denn wurde diese Funktion im alten System ein einziges Mal (vom Autor dieser Arbeit) genutzt. Was in Zukunft noch implementiert werden wird, sind Möglichkeiten der Diskussion über ein eigens dem Beitrag
angehängtes Forum sowie die Option einen Weblog zu erstellen.
7.2.8 Zugriffsrechte
Hinsichtlich der Zugriffsrechte wurden weitgehend alle Standardkonfigurationen des
JSPWikis übernommen, somit können auch nicht registrierte Benutzer Beiträge
verfassen und kommentieren. Was aber zusätzlich noch eingeführt wurde, ist eine
eigene Gruppe „Editoren“, welcher dieselben Rechte zugeteilt wurde wie der Gruppe
„Admin“. Des Weiteren wurden auf Kategorieebene ACLs mit der Konfiguration
[{ALLOW edit=‘Editoren’}] eingeführt, um zu verhindern, dass herkömmliche User
an der Strukturierung Änderungen vornehmen können. Das Gleiche geschah auch mit
den vom alten System übernommenen Beiträgen.
7 Implementierung
105
7.2.9 Authentifizierung und Profilverwaltung
Hinsichtlich des Authentifizierungsmechanismus und der Profilverwaltungen konnten
auch diese beiden Komponenten aus der Standardkonfiguration übernommen werden.
Abbildung 31: Das Anmeldeformular
Abbildung 32: Die Profilansicht
7 Implementierung
106
Um sich also mit dem System zu identifizieren, steht ein eigens ausgeführtes Schaltelement („Anmelden“) zur Verfügung. Über den Reiter „Neuen Benutzer registrieren“
kann ein neuer Account angelegt werden, wobei Benutzername, Passwort und Name
verpflichtend sind. Die Möglichkeit der Eingabe einer Emailadresse ist vorhanden und
wird dahingehend genutzt, um vergessene oder verloren gegangene Passwörter den
Usern automatisiert zukommen zu lassen (siehe Reiter „Neues Passwort anfordern).
Über den Button „Meine Einstellungen“ steht dem User eine Profilansicht zur Verfügung. Neben herkömmlichen Einstellungsmöglichkeiten wie Zeitzone, Zeitformat und
unzähligen weiteren Features, können auch Einstellungen hinsichtlich des gewünschten Seiten-Templates oder Editors getroffen werden.
7.2.10 PDF-Export und Drucken von Beiträgen
Um Beiträge in das Format PDF zu konvertieren, wurde im Menüpunkt „Weitere…“ ein
Punkt „Seite als PDF anzeigen“ definiert. Diese Feature ist standardmäßig nicht im
JSPWiki enthalten, konnte aber leicht durch das auf der JSPWiki Homepage zur Verfügung stehende PDFPlugin implementiert werden.
Ergänzungen mussten lediglich in den Dateien web.xml und ViewTemplate.jsp vorgenommen werden.
Listing 28: Ergänzungen in der Datei web.xml für das Einbinden des Plugins PDFPlugin
<servlet>
<servlet-name>Wiki2PDFServlet</servlet-name>
<servlet-class>
com.palbrattberg.jspwiki.Wiki2PDFServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Wiki2PDFServlet</servlet-name>
<url-pattern>/wiki.pdf</url-pattern>
</servlet-mapping>
Listing 29: Ergänzungen in der Datei ViewTemplate.jsp
<a href=“wiki.pdf?page=<wiki:Variable var=“pagename”/>&ext=.pdf”>
Seite als PDF anzeigen</a>
7 Implementierung
107
Bezug nehmend auf das Drucken von Beiträgen mussten keine Anpassungen vorgenommen werden, denn wird standardmäßig ein durchdachtes CSS-Print Konzept unterstützt.
Abbildung 33: Die Druckansicht
7.2.11 Sperren/Verbergen von Beiträgen und das Qualitätsgütesiegel
Um Beiträge zu sperren oder zu verbergen wurde das eingebaute Konzept der Access
Control Listen übernommen. Es steht also jedem User frei, wie Beiträge behandelt
werden sollen.
Zuzüglich wurde noch ein Plugin mit dem Namen AProoved eingeführt, um gesperrte
Beiträge mit einem Qualitätsgütesiegel zu versehen und um diese einzufrieren, das
heißt, ein nachträgliches Ändern ist nur noch auf Systemebene möglich. Für das Einfügen dieses Plugins ist folgende Syntax zulässig:
Listing 30: Das AProoved Plugin
[{AProoved name=‘<LoginName>’}]
7 Implementierung
108
Dieses Plugin kann zurzeit noch von jedem User verwendet werden. Ein entsprechender Filter ist aber bereits in Entwicklung.
7.2.12 Daten Import
Auch wenn das Datenimport-Modul kein explizites Feature des Austria-Forums-Neu
darstellt, so sollte diese Funktion trotz dessen an dieser Stelle genannt werden. Um
sämtliche Datensätze des alten Systems dem neuen zugänglich zu machen, wurde,
wie schon angedeutet, ein eigenes Datenimport-Modul implementiert. Hierfür wurden
eine Reihe von Konvertierungsroutinen entwickelt, vor allem um alte Beiträge hinsichtlich ihrer Strukturierung und dem zu Grunde liegenden Format anzupassen.
Für die Konvertierung von HTML in JSPWiki-Syntax wurde das OpenSource Projekt
Bliki39 zum Einsatz gebracht. Auch wenn es sich hierbei um eine JAVA API handelt,
welche speziell dafür entwickelt wurde, um Mediawiki Dokumente offline zu editieren,
werden mittlerweile eine Reihe von Wiki-Syntaxen unterstützt. Darunter auch ein
HTML2JSPWiki Konverter, welcher erweitert wurde und sich im Daten-Import-Modul
wieder findet lässt.
7.2.13 RSS-Feeds
Zu guter Letzt wurde ein RSS-Feed Dienst eingerichtet. Da diese Funktion standardmäßig im JSPWiki inkludiert, aber nicht aktiviert ist, musste hierfür im jspwiki.properties File der Parameter jspwiki.rss.generate=true gesetzt werde.
Die restlichen Einstellungen wurden übernommen, womit also alle 3600 Sekunden eine
Aktualisierung des RSS-Files stattfindet und unter der Adresse <WebRootDir>/rss.rdf zur Verfügung steht.
39
http://matheclipse.org/en/Java_Wikipedia_API
8 Konklusion
8
109
Konklusion
Auch wenn zu Beginn dieser Arbeit klar war, dass das alte System in seiner jetzigen
Form so nicht weiter existieren kann, war es doch erstaunlich festzustellen, dass das
Konzept „Austria-Forum - eine zitierfähige Community geprägte Online-Enzyklopädie“
mit einem Wiki-System umgesetzt werden kann. Vor allem wenn man bedenkt, welche
Kritikpunkte Wikis des Öfteren zu Teil werden: „Wikis produzieren nicht zitierfähige
Beiträge“, „Wikis verletzten das Copyright“ oder „Wikis sind von minderer Qualität“ sind
Beispiele dafür, wie sie des Öfteren zu hören sind. Doch wie schon in dieser Arbeit
beschrieben, sollten diese Kritikpunkte nicht pauschalisiert werden, denn ist zu unterscheiden, ob es sich um ein offenes oder ein geschlossenes System handelt.
Das Wiki-System JSPWiki ist ein gutes Beispiel hierfür, dass auch das Gegenteil funktioniert. Vor allem ein ausgeklügeltes Security Modul erlaubt es, dass Community- und
Expertengemeinden nebeneinander existieren und agieren können.
Zudem bietet das System alles an, was im alten nicht zur Verfügung stand beziehungsweise kritisiert wurde. So werden dezidierte Kontrollmechanismen auf User-Ebene unterstützt, um beispielsweise Beiträge zu verbergen oder selbst zu sperren. Ebenso wird
das Navigieren über die Browserbuttons „Back“ und „Forward“ sowie ein einfach zu
verwendendes Such-Paradigma angeboten. Des Weiteren können Beiträge gedruckt
oder im Format PDF exportiert werden.
Aber auch was die Erweiterungsmöglichkeiten anbelangt, ist das JSPWiki (und die
meisten heute bekannten Wiki-Systeme) vorbildlich. So existiert die Möglichkeit, über
ein ausgeklügeltes Plugin-Konzept das System in funktionaler Hinsicht fast an jegliche
Bedürfnisse anzupassen. Und auch wenn es einmal nicht möglich sein sollte, eine
Funktion „schnell“ über ein Plugin zu implementieren, so hilft die vorbildliche Codebase
und eine ausführliche Dokumentation weiter, um das Problem auf schnellstem Weg zu
lösen.
Wenn auch noch kein dezidiertes Userfeedback vorliegt, muss aus technischer Sicht
gesagt werden, dass das System in jeglicher Hinsicht dem alten überlegen ist, weshalb
auch in dem Zeitraum, in dem diese Diplomarbeit entstanden ist, die Entscheidung
getroffen wurde, das hier vorgestellte Konzept zu übernehmen.
9 Ausblick
9
110
Ausblick
Wie sich das System und das Konzept Austria-Forum in Hinblick auf die immer größer
werdende Konkurrenz (vgl. Google Knol40) am Marktplatz Internet etablieren wird,
bleibt natürlich offen. Aus technischer Sicht sollte aber einem Erfolg nichts im Wege
stehen, denn das System vereint die Vorzüge eines Wikis wie beispielsweise Benutzerfreundlichkeit, gutes Suchmaschinenranking, Community, etc. mit den Vorzügen einer
Enzyklopädie im klassischen Sinn.
Auch wenn bereits alle Funktionen vorhanden sind, um das System als eine „zitierfähige Community-geprägte Online-Enzyklopädie mit vorwiegend österreichischen Inhalten“ bezeichnen zu können, bleibt auch in Zukunft Einiges zu tun.
So wird beispielsweise die Möglichkeit geschaffen werden, Beiträge mit Meta-Daten zu
versehen, um Suchergebnisse noch besser präzisieren zu können.
Des Weiteren wird ein Tagging-System implementiert werden, mit dem es möglich sein
wird, Beiträge zusätzlich zur dezidierten Meta-Dateneingabe semantisch anzureichern.
Darüber hinaus soll eine „Wikifizierung“ des Systems stattfinden, um ein schnelleres
Navigieren durch das Wiki zu ermöglichen, und eine Implementierung einer Reihe von
weiteren Features, um das System auch in Zukunft am Marktplatz Internet zu etablieren.
40
http://knol.google.com
Literatur
111
Literatur
[Akscyn et al. 1987]
Akscyn R., McCracken D., Yoder E., KMS: a distributed hypermedia system for
managing knowledge in organizations, Proceeding of the ACM conference on
Hypertext, p. 1-20, Chapel Hill, North Carolina, United States, November 1987
[AEIOU 2008]
Annotierbares Elektronisches Interaktives Oesterreichisches UniversalInformationssystem (Aeiou), www.aeiou.at (Datum des letzten Zugriffs: 12. Jänner
2009)
[AF 2008]
Austria-Forum, http://www.austria-forum.org (Datum des letzten Zugriffs: 12. Jänner
2009)
[Aigner et al. 2007]
Aigner W., Hinum K., Miksch S., InfoVis:Wiki - Eine Informations- und
Diskussionsplattform für die InfoVis-Community, 2007, http://www.donauuni.ac.at/imperia/md/content/department/ike/ike_publications/2007/contributionsinbook
s/aigner_2007_infovis-wiki.pdf
[Alexa 2009]
Alexa the Web Information Company, http://www.alexa.com (Datum des letzten
Zugriffs: 12. Jänner 2009)
[Alexander 2008]
Alexander, Die Wissensgemeinde, http://www.iicm.tugraz.at/ask-lex (Datum des letzten
Literatur
112
[Amikelive 2008]
Amikelive.com, Whitepaper, Some Issues on Ajax Invocation, 2008,
http://tech.amikelive.com/whitepapers/Some_Issues_on_Ajax_Invocationwhitepaper.pdf (Datum des letzten Zugriffs: 12. Jänner 2009)
[Andrews 2008]
Andrews K., Human-Computer Interaction, Vorlesung, Technische Universität Graz,
2008, http://courses.iicm.tugraz.at/hci/hci.pdf
[Augar et al. 2004]
Augar N., Raitman R., Zhou W., Teaching and learning online with wikis, School of
Information Technology Deakin University, 2004
[Baumgartner 2005]
Baumgartner P., Wie man das richtige Content Management Tool für ein bestimmtes
Lernmodell auswählt, Fernuniversitaet in Hagen, Institute for Educational Science and
Media Research (IfBM), Mai 2005, http://www.irrintzi.net/doks/lernparadigCMS.pdf
(Datum des letzten Zugriffs: 12. Jänner 2009)
[Bichlmeier 2006]
Bichlmeier Ch., „Wer sucht, der findet - oder auch nicht.“ Hilfsmittel, Methoden und
Probleme bei der Online-Recherche im Fach Geschichte, Diplomarbeit, Universität
Passau, 2006
[CMSReview 2009]
CMS-Review, Content Management Systems, http://www.cmsreview.com (Datum des
letzten Zugriffs: 12. Jänner 2009)
[Cal et al. 2008]
Cal D., Eidenberger H., Ludewig M., Mintert S., Schulz C., Spanneberg B., Völkl G.,
v.d. Heyden R., Sechs exemplarische Wiki-Engines, Mit heißer Feder, IX, Magazin für
professionelle Informationstechnik, Heft 12, Dezember 2008
Literatur
113
[Cyganiak 2002]
Cyganiak R., Wiki und WCMS: Ein Vergleich. Hausarbeit im Rahmen des Seminars
„Content Management - Einführung in Theorie und Praxis“ von Tobias MüllerProthmann, Freie Universität Berlin, Institut für Publizistik- und
Kommunikationswissenschaft, Mai 2002,
http://richard.cyganiak.de/cm/wiki_und_wcms.pdf (Datum des letzten Zugriffs: 12.
Jänner 2009)
[C2 2008a]
C2.com, Wiki Wiki Origin, http://c2.com/cgi/wiki?WikiWikiOrigin (Datum des letzten
Zugriffs: 20. Dezember 2008)
[C2 2008b]
C2.com, Wiki History, http://c2.com/cgi/wiki?WikiHistory (Datum des letzten Zugriffs:
20. Dezember 2008)
[C2 2008c]
C2.com, Why Wiki Works, http://c2.com/cgi/wiki?WhyWikiWorks (Datum des letzten
Zugriffs: 20. Dezember 2008)
[C2 2008d]
C2.com, Why Doesnt Wiki Do Html, http://c2.com/cgi/wiki?WhyDoesntWikiDoHtml
(Datum des letzten Zugriffs: 20. Dezember 2008)
[C2 2008e]
C2.com, Wiki Engines, http://c2.com/cgi/wiki?WikiEngines (Datum des letzten Zugriffs:
20. Dezember 2008)
[Cunningham 2003]
Cunningham W., Correspondence on the Etymology of Wiki, November 2003,
http://c2.com/doc/etymology.html (Datum des letzten Zugriffs: 12. Jänner 2009)
Literatur
114
[Cunningham 2008]
Cunningham W., Why Wiki Works, C2.com http://c2.com/cgi/wiki?WhyWikiWorks
[Désiltes et al. 2005]
Désilets A., Paquet S., Vinson N.G., Are wikis usable?, Proceedings of the 2005
international symposium on Wikis, p. 3-15, October 16-18, San Diego, California, 2005
[DMOZ 2009]
DMOZ, Open Directory - Computers: Software: Internet: Site Management: Content
Management,
http://www.dmoz.org/Computers/Software/Internet/Site_Management/Content_Manage
ment/ (Datum des letzten Zugriffs: 12. Jänner 2009)
[Dokuwiki 2008]
Dokuwiki, http://www.dokuwiki.org/dokuwiki (Datum des letzten Zugriffs: 12. Jänner
2009)
[Doyle 2008]
Doyle B., Weblog, http://www.bobdoyleblog.com/ (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Doyle 2005]
Doyle B., How many CMS are there?: msg#00035, osdir.com,
http://osdir.com/ml/cms.cms-forum.general/2005-08/msg00035.html (Datum des letzten
[Dué et al. 2008]
Dué R., Tidwell J., Vollmann D., Pattern 35: Back button, AKA: Go back one step
(Tidwell), 2008, http://www.trireme.com/WU/wup35.htm (Datum des letzten Zugriffs:
12. Jänner 2009)
Literatur
115
[Ebersbach et al. 2007]
Ebersbach A., Glaser M., Heigl R., Warta A.,Wiki - Kooperation im Web, Springer,
Auflage: 2. Auflage, Berlin, Oktober 2007
[Ferner 2004]
Ferner J., PHP-Nuke - Eine Empfehlenswerte Enterprise-Lösung?, Gegenüberstellung
der Vor- und Nachteile im Vergleich zu kommerziellen Lösungen, Netskill AG,
www.competence-site.de, Juni 2004
[Fiebig 2005]
Fiebig H., Wikipedia, Das Buch Aus der freien Enzyklopädie Wikipedia, WikiPress 1,
Originalausgabe, p. 20, November 2005
[Frank 2007]
Frank H., Manipulationen an der Online-Enzyklopädie, Die CIA und der WikipediaVandalismus, RP Online, WASHINGTON, August 2007
[Fuecks 2004]
Fuecks H., Pick of the Wikis: Dokuwiki, sitepoint.com, Oktober 2004,
http://www.sitepoint.com/blogs/2004/10/11/pick-of-the-wikis-dokuwiki/ (Datum des
[Garrett 2005]
Garrett J. J., Ajax: A New Approach to Web Applications, Februar 2005,
http://www.adaptivepath.com/ideas/essays/archives/000385.php (Datum des letzten
[GNU 2008]
GNU, Licenses - GNU GPL, GNU LGPL, GNU FDL, General Public License, Lesser
General Public License, Free Documentation License, List of Free Software Licenses,
http://www.gnu.org/licenses/ (Datum des letzten Zugriffs: 12. Jänner 2009)
Literatur
116
[Gründerwiki 2008]
Gründerwiki, Warum Wiki-Funktioniert,
http://www.wikiservice.at/gruender/wiki.cgi?WarumWikiFunktioniert (Datum des letzten
[Goeßmann 2006]
Goeßmann D., WIKIMANIA-TAGUNG 2006, Elefanten überrennen Lexikon,
Cambridge, http://www.spiegel.de/netzwelt/web/0,1518,430440,00.html (Datum des
[Guetl 2008]
Guetl C., Information Search and Retrieval, Vorlesung, Block 01: Basics in IR,
Technische Universität Graz, 2008,
http://www.iicm.tugraz.at/cguetl/courses/isr/vo/folien/block01_v1_3.pdf
[Haber 2005]
Haber P., „‘Google-Syndrom’. Phantasmagorien des historischen Allwissens im World
Wide Web“, Geschichte und Informatik/Histoire et Informatique. Vom Nutzen und
Nachteil des Internet für die historische Erkenntnis, vol. 15, pp. 73-89, 2005
[Helic et al. 2008]
Helic D., Maurer H., White B., AUSTRIA-FORUM: A CITABLE WEB ENCYCLOPEDIA,
IADIS International Conference WWW/Internet, 2008
[Heise 2008]
Heise Online, Twiki.net vs. NextWiki: Freie Entwickler gehen eigene Wege, Oktober
2008, http://www.heise.de/newsticker/Twiki-net-vs-NextWiki-Freie-Entwickler-geheneigene-Wege--/meldung/118143 (Datum des letzten Zugriffs: 12. Jänner 2009)
[JSPWiki 2008]
JSPWiki, http://www.jspwiki.org (Datum des letzten Zugriffs: 12. Jänner 2009)
Literatur
117
[JSPWikiDoc 2008]
JSPWiki Dokumentation, http://doc.jspwiki.org/2.4/ (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Johnson 2005]
Johnson S., Everything Bad is Good for You: How Popular Culture is Making Us
Smarter, London: Allen Lane, 2005
[Krötzsch et al. 2007]
Krötzsch M., Vrandecic´ D., Völkel M., Haller H., Studer R., SemanticWikipedia, Web
Semantics: Science, Services and Agents on the World Wide Web (2007),
doi:10.1016/j.websem.2007.09.001,
http://www.websemanticsjournal.org/papers/20071025/SemanticWikiKrotzschV5I4.pdf
[Leuf und Cunningham 2001]
Leuf B., Cunningham W., The Wiki Way, Quick Collaboration on the Web, AddisonWesley, New York, 2001
[Lombardi 2006]
Lombardi C., Wikipedia: Stop citing our site, CNET News Blog, Juni 2006,
http://news.cnet.com/8301-10784_3-6084715-7.html?tag=txt (Datum des letzten
[Mahrbach 2008]
Marbach W., TWiki: Installieren * Konfigurieren * Administrieren, C & l Computer- U.
Literaturverlag, November 2008
[Maurer et al. 2007]
Maurer H., Balke T., Kappe F., Kulathuramaiyer N., Weber S., Zaka B., Report on
dangers and opportunities posed by large search engines, particularly Google , Report,
September 2007
Literatur
118
[Mediawiki 2008]
MediaWiki, http://www.mediawiki.org/wiki/MediaWiki (Datum des letzten Zugriffs: 12.
Dezember 2008)
[Moeller 2003]
Möller E., Das Wiki-Prinzip, Tanz der Gehirne Teil 1, Heise Zeitschriften Verlag, Mai
2003, http://www.heise.de/tp/r4/artikel/14/14736/1.html (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Moeller 2003b]
Möller E., Schreibwerkstätten, Fünf Wiki-Engines im Vergleich, C’T, Heft 25, 2003
[Neuberg 2005]
Neuberg B., AJAX: How to Handle Bookmarks and Back Buttons, O’Reilly onjava.com,
Oktober 2005, http://www.onjava.com/pub/a/onjava/2005/10/26/ajax-handlingbookmarks-and-back-button.html (Datum des letzten Zugriffs: 12. Jänner 2009)
[Nielsen 1996]
Nielsen J., Why Frames Suck (Most of the Time), Jakob Nielsen’s Alertbox, useit.com,
Dezember 1996, http://www.useit.com/alertbox/9612.html (Datum des letzten Zugriffs:
12. Jänner 2009)
[Nielsen 1997]
Nielsen J., Search and You May Find, Jakob Nielsen’s Alertbox, useit.com, Juli 1997,
http://www.useit.com/alertbox/9707b.html (Datum des letzten Zugriffs: 12. Jänner
2009)
[Nielsen et al. 2001]
Nielsen J., Kara Pernice Coyne and Marie Tahir, Make it Usable, pcmag.org,
http://www.pcmag.com/article2/0,1759,33821,00.asp (Datum des letzten Zugriffs: 12.
Jänner 2009)
Literatur
119
[Nielsen 2004]
Nielsen J., Guidelines for Visualizing Links, Jakob Nielsen’s Alertbox, useit.com, Mai
2004, http://www.useit.com/alertbox/20040510.html (Datum des letzten Zugriffs: 12.
Jänner 2009)
[OPDCE 2008]
The Oxford Pocket Dictionary of Current English, „wiki“, 2008, Encyclopedia.com,
http://www.encyclopedia.com
[Osman 2006]
Osman-El Sayed R.,“Wiki-Systeme im eLearning“, Diplomarbeit, Goethe Universität
Frankfurt am Main, 2006
[Pelka et al. 2007]
Pelka B., Grote M., Kretzmann J., Röber H., Schmidt M., Vanzella K., Weißenborn M.,
Ein Mediawiki-Handbuch von Einsteigern für Einsteiger, Institut für Journalistik und
Kommunikationsforschung (IJK) der Hochschule für Musik und Theater Hannover,
2007, http://www.ijk.hmt-hannover.de/fileadmin/www.ijk/pdf/aktuelles/wikihandbuch_080204.pdf
[Pfister 2006]
Pfister M., Swisscom, SchoolNetGuide, Jeder Leser auch ein Autor: Blogs und Wikis,
SchoolNetGuide Nr. 9, Sommer 2006
[Pro 2008]
Program-Transformation.Org, TWiki Installation Guide, http://www.programtransformation.org/TWiki/TWikiInstallationGuide (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Raygan und Green 2002]
Raygan R. E., Green D. G., Internet Collaboration: Twiki, IEEE SoutheastCon, April
2002
Literatur
120
[Richardson 2008]
Richardson W., Blogs, Wikis, Podcasts, and Other Powerful Web Tools for Classrooms
(Taschenbuch) Corwin Press; Auflage: 0002, September 2008
[Rosenzweig 2006]
Rosenzweig R., Can History Be Open Source?, Wikipedia and the Future of the Past,
The Journal of American History, Juni 2006
[Schaffert et al. 2006]
Schaffert S., Gruber A., Westenthaler R., „A SEMANTIC WIKI FOR COLLABORATIVE
KNOWLEDGE FORMATION”, Knowledge-based Information Systems Group, Salzburg
Research, Austria, 2006
[Seibert 2008]
Seibert M., Wikis im Intranet Teil 1: MediaWiki und TWiki - sehr ausgereifte Systeme
für sehr unterschiedliche Anforderungen, Perl Magazin, Mai 2008
[Smith und Sauer 2006]
Smith Ch., Sauer Ch., Open Source Wiki Engine Popularity, Hochschule Heilbronn,
August 2006, http://www.i3g.hsheilbronn.de/attach/WikiMarkupStandard/WikiPopOS.pdf
[Stenhouse 2005]
Stenhouse M., Fixing the Back Button and Enabling Bookmarking for AJAX Apps,
contentwithstyle , June 2005, http://www.contentwithstyle.co.uk/content/fixing-the-backbutton-and-enabling-bookmarking-for-ajax-apps (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Twiki 2008]
Twiki, http://www.twiki.org (Datum des letzten Zugriffs: 12. Jänner 2009)
Literatur
121
[Tscholotfeldt 2008]
Tschlotfeldt, E-Learning-Wiki: Wikis in Unternehmen,
http://www.tschlotfeldt.de/elearning-wiki/Wikis_in_Unternehmen (Datum des letzten
[Valeur et al. 2005]
Valeur F., Mutz D., Vigna G., A Learning-Based Approach to the Detection of SQL
Attacks, University of California, Santa Barbara, Springer Link, Juni 2005
[Wales 2005]
Wales J., Lecture at Stanford University on 2 9 2005, Stanford, Transcribed by Harold
Rheingold, answers.com, http://www.answers.com/topic/jimmy-wales-lecture-atstanford-university-on-2-9-2005 (Datum des letzten Zugriffs: 12. Jänner 2009)
[Walker 1987]
Walker J. H., Document Examiner: delivery interface for hypertext documents,
Proceeding of the ACM conference on Hypertext, p. 307-323, Chapel Hill, North
Carolina, United States, November 1987
[Weber 2007]
Weber C., TWiki 4.1 Installationsanleitung, zungu.net, Februar 2007,
http://zungu.net/blog/19/twiki-41-installationsanleitung/ (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Wiebrands 2006]
Wiebrands C., Collaboration and communication via wiki : The experience of Curtin
University Library and Information Service., 2006. In Australian Library and Information
Association 2006 Biennial Conference, Perth (Australia), p. 19 – 22, September 2006
[Wikimatrix 2008a]
WikiMatrix, Most Comparisons, http://www.wikimatrix.org/statistic/Most+Comparisons
Literatur
122
[Wikimatrix 2008b]
WikiMatrix, http://www.wikimatrix.org (Datum des letzten Zugriffs: 12. Jänner 2009)
[Wikimedia 2008]
Wikimedia, Wikipedia-Statistik - Besucher pro Tag, http://stats.wikimedia.org (Datum
des letzten Zugriffs: 12. Jänner 2009)
[Wikiservice 2008]
Wikiservice, Warum Wiki-Funktioniert,
http://www.wikiservice.at/dse/wiki.cgi?WarumWikiFunktioniert (Datum des letzten
[Wikipedia 2008]
Wikpiedia - Wiki, http://de.wikipedia.org/wiki/Wiki (Datum des letzten Zugriffs: 12.
Jänner 2009)
[Zerfaß und Zimmermann 2004]
Zerfaß A., Zimmermann H.J. (Hrsg.), Usability von Internet-Angeboten, Grundlagen
und Fallstudien, Stuttgarter Beiträge zur Medienwirtschaft Nr. 10, pp. 69, Januar 2004
[Zschau et. al 2001]
Zschau O., Traub D., Zahradka R., Web Content Management - Websites professionell
planen und betreiben, Galileo Business, 2001
Anhang
Vergleich der fünf Wiki-Systeme DokuWIki, FlexWiki, JSPWiki, MediaWiki und TWiki. Die folgenden Tabellen wurden mit dem auf wikimatrix.org verfügbaren Komparationstool erstellt.
General Features
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Version
05.05.2008
2.0.0.199
02.08.2001
1.13.2
TWiki 4.2.4
Last Release Date
05.05.2008
14.02.2008
24.11.2008
02.10.2008
06.12.2008
Author
Andreas Gohr
Microsoft
Apache Software
Foundation
Magnus Manske, Brion
Vibber, Lee Daniel Crocker, Tim Starling, Erik
Möller, and others.
Peter Thoeny,
TWiki community
URL
www.dokuwiki.org
www.flexwiki.com
www.jspwiki.org
www.mediawiki.org
twiki.org and
www.twiki.net
Free and Open
Source
Yes
Yes
Yes
Yes
Yes
License
GPL 2
Common Public License Apache License
(CPL)
GPL
GPL
Programming Language
PHP
C#
Java
PHP
Perl
Data Storage
Files
Files, DB
Files, DB, RCS
Database
Files, RCS
Anhang
License Cost/ Fee
124
0
Development status Mature
Intended Audience
Free
0
0
$0, and subscriptions for support
Mature
Mature
Mature
Mature
all
End Users/Desktop, Education
Large enterprise;
small to medium
businesses
private, small to medium n/a
companies
System Requirements
DokuWiki
FlexWiki
JSPWiki
Operating System
UNIX, Windows,
MacOS X, probably
others
Windows XP, Vista,
Server 2003 or
2008, LINUX
any platform suppor- *nix, Windows, Mac
ting JDK 1.5+
OS X
Linux, Windows, OS-X and other
Root Access
No
Yes
No
No
No
Webserver
Apache, IIS, Lighttp, IIS (ASP.NET),
anything with PHP
APACHE (MONO)
support
any servlet 2.4+
compliant web
server, e.g. Tomcat
5+, Jetty, Glassfish,
Websphere
Any with PHP support
Almost any webserver, typically
Apache 1.3/2.0
optional JavaMail
none
RCS (optional), cron/scheduler,
fgrep, egrep; Plugins may have
additional dependencies
Other Requirements
None
MediaWiki
TWiki
Anhang
125
Datastorage
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
MySQL
No
No
Plugin
Yes
No
PostgreSQL
No
No
Plugin
Yes
No
Oracle
No
No
Plugin
SQLite
No
No
Plugin
Yes
No
BerkeleyDB
No
No
Plugin
No
No
RCS
No
No
Plugin
No
Yes
Other
None
SQL Server 2000,
2005 or Express
page provider archi- No
tecture -> several
implementations
RcsLite Perl library for version
control without external RCS;
backend API for other storage
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Patch
Yes
No
No
Special Features
Right-to-Left Support
Yes
Interface Languages
44 languages
Not localized
8 languages
140 languages
16 languages
Email notification
Optional
Yes
Plugin
Optional
Yes
Comments
Plugin
No
Flat
Discussion Pages
Threaded
Categories
Plugin
Yes
Yes
Yes
Yes
Anhang
126
Namespaces
Yes
Yes
No
Yes
Yes
Conflict Handling
Page Locking
Conflict Detection
Page Locking
Conflict Resolution
Conflict Resolution
Search
Full Text
Full Text
Full Text
Full Text
Full Text
Structured Data
Plugin
n/a
Yes
Plugin
Yes
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Page Permissions
Yes
Yes
Yes
Yes
Yes
ACL
Yes
Yes
Yes
No
Yes
Authentication Backends
Textfile, LDAP,
MySQL,
PostgreSQL
Windows, Forms
JAAS
(ASPNET Providers)
Yes
Internal authentication; anything
Apache supports such as LDAP,
NIS, AD, Kerberos
Host Blocking
Plugin
Yes
Optional
Yes
Plugin
Mail Encryption
Optional
No
Plugin
Plugin
Yes
nofollow
Optional
Yes
Optional
Optional
Plugin
Blacklist
Optional
Yes
Yes
Yes
Plugin
CAPTCHA
Plugin
Yes
Yes
Plugin
Plugin
Security/Anti-Spam
Anhang
127
Development/Support
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Commercial Support
Yes, 16 listed
No
Yes, 1 listed
Yes, 32 listed
Yes, 27 listed
Preconfigured
Hosting
Yes
No
No
Yes
Yes
Code Repository
dev.splitbrain.org
flexwiki.svn.sourceforge.net
svn.apache.org
svn.wikimedia.org
twiki.org
Issue Tracker
bugs.splitbrain.org
sourceforge.net
issues.apache.org
bugzilla.wikimedia.org twiki.org
Mailing List
www.freelists.org
lists.sourceforge.net
www.jspwiki.org
lists.wikimedia.org
twiki.org
Support Forum
forum.dokuwiki.org
n/a
please use mailing
lists or issue
tracker
mwusers.com
twiki.org
IRC Channel
www.dokuwiki.org
n/a
Freenode: #jspwiki
www.mediawiki.org
twiki.org
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Preview
Yes
Yes
Yes
Yes
Yes
Minor Changes
Yes
No
No
Yes
Yes
Change Summary
Yes
No
Yes
Yes
Yes
Page History
Yes
Yes
Yes
Yes
Yes
Common Features
Anhang
128
Page Revisions
Unlimited
Unlimited
Unlimited
Unlimited
Unlimited
Revision Diffs
Between all
Between all
Between all
Between all
Between all
Page Index
Yes
Yes
Yes
Yes
Yes
Plugin System
Yes
Yes
Yes
Yes
Yes
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
HTML Tags
Optional
Plugin
Optional
Some
All
Math formulas
Plugin
No
Plugin
Yes
Plugin
Tables
simple
simple + complex
simple + complex
simple + complex
simple + complex
CREOLE support
Plugin
No
Yes
No
No
Markdown Support
Plugin
No
No
No
No
Textile Support
Plugin
Yes
No
No
Plugin
BBCode Support
Plugin
No
No
No
No
Emoticon Images
Yes
Yes
Plugin
Optional
Plugin
Syntax Highlighting Yes
No
Plugin
Plugin
Plugin
Footnotes
Yes
Yes
Yes
Yes
Plugin
Quoting
Yes
Yes
No
No
Yes
Internal Comments
Plugin
Yes
Plugin
Yes
Yes
Custom styles
No
Yes
Yes
Yes
Yes
Syntax Features
Anhang
129
Scripting
Optional, PHP
yes; WikiTallk
plugins for
Optional
JavaScript, TCL and
Groovy
JavaScript; TWiki variables; powerful API
Content Includes
Plugin
Yes
Yes
Yes
Yes
Feed Aggregation
Yes
Yes
Plugin
Plugin
Plugin
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Section Editing
Yes
No
Yes
Yes
Plugin
Page Templates
n/A
n/A
Yes
Yes
Yes
Double-Click Edit
No
Yes
No
Optional
Plugin
Toolbar
Yes
No
Yes
Yes
Yes
WYSIWYG Editing
Plugin
No
Plugin
Plugin
Yes
Access Keys
Yes
No
Yes
Yes
Yes
Auto Signature
Yes
No
Plugin
Yes
Yes
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Recent Changes
Yes
Yes
Yes
Yes
Yes
Wanted Pages
Plugin
No
Yes
Yes
No
Usability
Statistics
Anhang
Orphaned Pages
130
Plugin
Yes
Yes
Yes
Plugin
Most/Least Popular No
No
No
Yes
Yes
Recent Visitors
No
No
No
Plugin
No
Analysis
Plugin
No
No
Optional
Yes
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Output
HTML
XHTML 1.0 Transiti- HTML 4
onal
XHTML 1.0 Strict
XHTML 1.0 Transiti- XHTML 1.0 Transitional
onal
CSS Stylesheets
Yes
Yes
Yes
Yes
Yes
Printer Friendly
Print CSS
Print View
Print CSS
Print CSS
Print View
Mobile Friendly
No
n/a
No
No
Plugin
Themes & Skins
Yes
Yes
Yes
Yes
Yes
RSS Feeds
Yes
Yes
Yes
Yes
Yes
ATOM Feeds
Yes
No
Yes
Yes
Yes
Auto-TOC
Yes
Yes
Plugin
Yes
Yes
Raw Export
Yes
Yes
Yes
Yes
Yes
HTML Export
Yes
Yes
Optional
Yes
Yes
XML Export
No
No
No
Yes
Plugin
PDF Export
Plugin
No
Plugin
Plugin
Plugin
Anhang
131
Media and Files
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
File Attachments
Yes
Optional
Yes
Yes
Yes
Media Revisions
No
No
Yes
Yes
Yes
Embedded Flash
Yes
Plugin
Plugin
Plugin
Plugin
Embedded Video
Plugin
Yes
Plugin
Plugin
Plugin
Media Search
No
No
Filenames only
Keywords
Contents
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
Image Galleries
Plugin
n/a
Plugin
Yes
Plugin
Forums
No
n/a
Yes
Plugin
Plugin
Blogs
Plugin
n/a
Yes
No
Yes
Extras
Syntax Examples
Internal Link
DokuWiki
FlexWiki
JSPWiki
MediaWiki
TWiki
[[a Link]]
[[namespace:link]]
[[link|With a Title]]
HomePage
[link]
[text|link]
[text|wiki:link]
[[a link]]
[[a link|with title]]
WikiWord autolink
Otherweb.WikiWord
[[Spaced text]]
[[WikiWord][label]]
Anhang
External Link
Headlines
Bold Format
Italics Format
Underline Format
Monospace
Format
Strikethrough
Format
Superscript
Format
Subscript Format
Images
132
[[http://example.com]]
„WikiMa[[http://example.com|Wit trix“:http:://w
h a Title]]
ww.wikimatri
x.org
====== Level 1 ====== !Heading 1
===== Level 2 =====
==== Level 3 ====
=== Level 4 ===
== Level 5 ==
**bold**
//italics//
[http://www.example.com/]
[example|http://www.example.co
m/]
[text|wiki:link]
! Level 1
!! Level 2
!!! Level 3
*bold* or
__bold__
‘‘italics here’’ ‘‘italics’’
[http://example.org The
title]
http://twiki.org/ autolink
[[http://twiki.org/][label]]
---+ Level 1
==Sectin==
---++ Level 2
===Subsection===
====Sub-subsection==== ---+++ Level 3
---++++ Level 4
---+++++ Level 5
---++++++ Level 6
*bold*
‘‘italic’’
_italic_
__underlined__
+underline
text+
%%(text-decoration: under- <u>underlined</u>
line) text %%
<u>underline</u>
‘‘monospace’’
This is monospace
{{monospace}}
=monospaced text= and
<verbatim>
multi line text
</verbatim>
<strike>strikethrough</strike>
<tt>monospace</tt>
<del>strikethrough
</del>
%%(text-decoration: line<s>strikethrough</s>
strikethrough through) deleted text %%
text<sup>superscript</sup> ^super^
%%(vertical-align: sup) text <sup>superscript</sup>
%%
<sub>subscript</sub>
~sub~
%%(vertical-align: sub) text <sub>subscript</sub>
%%
{{local.jpg}}
http://whatev [local.jpg]
{{http://foo.bar/baz.jpg}} er/path/file.jp [{Image src=‘local.jpg’}]
g
[{Image
src=‘http://foo.bar/foo.jpg’}]
[[Image:wiki.png]]
<sup>superscript</sup>
<sub>subscript</sub>
%ATTACHURL%/image.png
http://any.domain/image.png
Anhang
Aligning Text
Text Indentation
133
n/a
n/a
* item 1
* item 1.1
* item 2
- item 1
Numbered Lists
- item 1.1
- item 2
Bulleted Lists
Definition Lists
Horizontal Rule
Use a span
or div with a
class and
custom css
Use a span
or div witha
class and
custom css
* Point
* Block
Plugin
1. List item
one
1. List item
two
1. List item
three
n/a
----
----
%%(text-align: right) text
%%
<center>Centered
</center>
| left | center | right |
or HTML
or CSS
%%(text-indent: 20px) 20
pixels %%
%%(text-indent: 30%) 30
percent %%
* Item 1
** Item 1.1
* Item 2
# Item 1
## Item 1.1
# Item 2
: indented line
<blockquote>
multi line text
</blockquote>
* Item 1
** Item 1.2
* Item 2
# Item 1
## Item 1.2
# Item 2
* Item 1
* Item 1.1
* Item 2
1. Item 1
a. Item 1.a
1. Item 2
;term:definition
; term : definition
$ Term: Definition
----
----
---
Erklärung
Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig angefertigt habe.
Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel benutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches
kenntlich gemacht.
Ort, Datum
Unterschrift

Vom Austria-Forum zum Wiki-Konzept Masterarbeit

Transcription

Similar documents

handout alltag krieg - herr

yES NO yES NO

Elektronen in Metallen

KAWAI Products Catalogue 2009 (English / Deutsch)

Content-Management-Systeme CMS

Hestasport Riding Tours 2016

bws Prospekt - bauwandsystem

MAVI 2.0 – Konzept und Möglichkeiten

GESIS-Technical Report

Kapitel 04.18: Ãkosystem Meer, Tiefsee & Korallenriffe

Nutzung von Social-Media-Diensten in den Zielgruppen