TikiWiki in der Praxis: Intranet für die Firma Ibau GmbH

Bild des Benutzers Regina Oswald
Für die Firma Ibau führen wir seit einiger Zeit den Support für die Webseiten unter TYPO3 durch.

Nun stand die Aktualisierung des bereits vorhandenen TikiWikis in neuer Version an, die mit zahlreichen Änderungs- und Erweiterungswünschen verbunden war.
Alternativ wurde diskutiert, Joomla oder Drupal einzusetzen.

 

Folgende Wünsche wurden angefragt:

  • Blogs

  • Foren

  • Dokumenten-, Dateien- und Bildverzeichnis Projekt-/Abteilungs-/Themenbezogen

  • wiki (link oder integriert)

  • Leicht zu wartender Gruppen-/Projekte-Terminkalender Projekt-/Abteilungs-/Themenbezogen

  • Wissensmanagement-Funktionen (z.B. webbasiertes Lernen) Projekt-/Abteilungs-/Themenbezogen

  • Integration von Videokonferenzen

  • Benutzerfreundlichkeit durch:
    - intuitiv bedienbare Oberfläche
    - selbsterklärende Oberfläche

  • Volltext-Suche über alle Bereiche des Intranets

  • individuelle Submenüs für Abteilungen

  • leicht zu bedienendes Berechtigungskonzept einschl. abgestufter admin-Rechte
    - z.B. Bearbeiten eines wiki durch alle Nutzer
    - z.B. Dokumente hochladen nur durch Moderatoren

  • Übernahme der Daten aus dem „alten“ Intranet (wenn es ersetzt werden soll)

  • leicht zu erstellendes Link-Verzeichnis

  • Pro Abteilung ein Verantwortlicher zur Pflege

  • Datenaustausch (wechselnde Infos, z.B. TOP-Listen): Pflege und Wartung sicherstellen

  • Anmeldung der User über LDAP

  • „Schwarzes Brett“

  • Marktplatz

Nicht alle geforderten Features hatten hohe Prio, einige kamen dann auch nicht zur Umsetzung.

 

Vergleich Joomla-TikiWiki-Drupal

Da es in der Firma einige Mitarbeiter gibt, die Joomla-KnowHow besitzen, wurde ich gebeten, als erstes eine Abschätzung zu geben, welches der beiden Systeme ich empfehlen würde.

Bzw. wir haben dann auch noch Drupal vorgeschlagen.

Im Folgenden ein Ausschnitt aus dem Vergleich der Systeme, den ich gemacht habe mit entsprechendem Fazit.

Vorteile von TikiWiki

  • Besonders geeignet für Wissens- und Dokumenten-Management

  • Besonders geeignet für Intranets

  • Viele angefragte Funktionen liegen bereits in der Core-Version vor, bzw. Plugins können per einfachem Knopfdruck aktiviert werden

  • Schneller Versionen-Wechsel mit immer neuen Funktionalitäten und Verbesserungen

  • Benutzerfreundlich

  • Daten-Migration bei Update von Version 5 auf aktuelle Version ist einfacher als von Tiki auf Joomla oder andere Systeme

  • Gute Funktionen für Webbasierte Zusammenarbeit.

  • Gut skalierbares Rechte- und Gruppen-System

  • Linksverzeichnisse, Dateiverzeichnisse, Wikiseiten, Foren, Kalender ect. können sehr gut auf Abteilungen zugeschnitten werden, ebenso wie Submenüs

  • LDAP-Anbindung gut unterstützt.

  • KnowHow in der Firma liegt vor

Nachteile von TikiWiki

  • Auch in der aktuellen Version 8.3. ist die Implementierung des Wysiwyg-Editors in Foren und Blogs nicht vollständig gegeben. Artikel sowie Wiki-Seiten unterstützen den Wysiwyg-Editor jedoch vollständig

  • TikiWiki ist vor allem auf schnelle unkomplizierte Implementierung ausgerichtet.
    Wenn es darum geht, bestimmte Funktionen (wie z.B. Webbasiertes Lernen, Umfragen ect.) individuell zu erweitern, dann gibt es sicher leistungsfähigere Systeme s.u.

  • Die Community ist zwar groß, aber nicht so groß, wie bei Joomla und Drupal.
    D.h. Neuprogrammierungen, Hilfe in den Benutzer-Foren ect. ist nicht ganz so umfangreich.

Vergleich mit Intranet-Funktionen von Drupal und Joomla

  • Drupal- Wiki ist auch bei Vergleichen von Wiki- und Intranet-Software mit TikiWiki gemeinsam aufgeführt, wogegen Joomla, bei solchen Vergleichen nie auftaucht.
    Das liegt daran, dass Joomla seine Stärken eher im Web-Publishing hat, als bei Wiki-Funktionen, Webbasierter Zusammenarbeit oder Communities.
    Viele sinnvolle Module von Joomla stehen bislang nur für Version 1.5 bzw. 1.7 zur Verfügung.
    Andere Features sind aber erst ab aktueller Version vorhanden.

  • TikiWiki hat mehr Funktionen Out-Of-The-Box als die beiden Vergleichs-CMS
    Bei Joomla und Drupal kann man die Module wie gewünscht und benötigt hinzufügen.
    Folglich ist TikiWiki schneller bei der Implementierung und hat bessere Updatefähigkeit, weil nicht auf Kompatibilität der Module geachtet werden muss.

  • Bei Drupal und Joomla gibt es zu jedem Modul (was sich bei TikiWiki Plugin nennt) mehrere Varianten zur Auswahl je nach Anforderung. Bei TikiWiki gibt es in der Regel nur ein Plugin pro Feature (Blog, Forum). Individuelle Änderungen sind in TikiWiki weniger leicht umzusetzen.
    Ist man allerdings mit den Standard-Features zufrieden, so sind diese relativ schnell zu implementieren.

  • Synchronisation des Kalenders mit Outlook ist bei Drupal und Joomla gut integriert via Zusatz-Module, bei TikiWiki ist die Funktion noch in Planung

  • Echte Massen-Uploadfunktionalität bieten Drupal und Joomla.
    Bei TikiWiki können gezippte Dateien hochgeladen werden, die dann auf dem Server entzippt werden.

  • Bei allen drei Systemen gibt es Module zur LDAP-Anbindung

Empfehlung:

Wenn die angefragten MUSS- und SOLL-Positionen mit den Standard-Features von TikiWiki ausreichend abgedeckt sind, dann empfehlen wir ein Update auf die Version 9.
Die Feature-Liste von TikiWiki entspricht in sehr hohem Maße den angefragten Anforderungen.
Zwar kann das Update nicht auf die bestehende Version installiert werden, aber der Export auf der bestehenden Version und nachfolgender Import auf dem neuen System sind mit wesentlich geringerem Aufwand zeitnah zu bewerkstelligen.

Dafür spricht auch, dass es bereits eine funktionierende LDAP-Schnittstelle gibt.
Und natürlich, dass KnowHow bereits vorliegt.

Falls für die Themen Wissensmanagement und wissensbasiertes Lernen / Video-Konferenz / Produkt Management / Projektmanagement eine hohe individuelle Anpassungs-Möglichkeit erwartet wird, dann empfehlen wir Drupal mit einer Reihe von Wiki- und Community-Modulen.
In dem Fall wäre die Anpassungsfähigkeit unbegrenzt.
Allerdings wäre auch der Aufwand bei der Implementation etwas höher.

Joomla kann -in der uns bekannten Version 1.5.x – nicht empfohlen werden, da es nach unseren Erfahrungen weniger benutzerfreundlich, flexibel und pflegeleicht ist (s.o.).
Das ist eine subjektive Einschätzung und das Programm ist sicher in der aktuellen Version 2.5. wesentlich verbessert worden.
Allerdings ist diese Version gerade erst veröffentlicht worden und es liegen einige notwendige Module noch nicht vor.

 

Praktische Umsetzung

Hier sollen nur Beispielhaft einige Punkte aufgeführt werden, deren Umsetzung besonders interessant waren:

LDAP-Anbindung:
In der Firma werden die Anmeldungen zentral in einem Active Directory verwaltet.
Deshalb war es wünschenswert, dass die gleichen Gruppen und Benutzer auch in TikiWiki integriert werden und die Benutzer sich mit üblichem Passwort anmelden können.

Konfiguration der Anmeldung via LDAP

Konfiguration der Anmeldung via LDAP

Konfiguration der Anmeldung via LDAP

Dedizierte Rechte vergeben auf Ebene der Firmen-Abteilungen
Jede Abteilung soll einen oder mehrere Moderatoren (-Rollen) haben mit weitgehenden Lese / und Schreibrechten.
Je nach Plugin gibt es dann Rollen, die für dieses Plugin (Foren, Artikel) nur eingeschränkte Schreib- und Leserechte haben.

Welche Rechte auf welches Objekt eines Plugins greifen, kann der Ersteller über Kategorien bestimmen.
Es wurde also für jede Abteilung eine Kategorie angelegt.

Kategorienverwaltung in TikiWiki

In der sehr detaillierten Benutzerverwaltung können für jedes Plugin globale Rechte vergeben werden.

Diese Globalen Rechte werden dann durch Rechte überschrieben, die für die einzelnen Kategorien (Abteilungen) gelten.

Dieses Kategorien-System zieht sich durch fast alle Verwaltungs-Ebenen durch.

Es regelt auch, dass ein angemeldeter User nur die Menüpunkte sieht, die für ihn interessant sind.

Da vom Active Directory alle Gruppen (=Rollen) übernommen werden, also auch solche, die in TikiWiki keine Verwendung finden, kann die Rechteverwaltung schnell unübersichtlich werden.

Allerdings bietet TikiWiki die sehr angenehme Möglichkeit, dass jeder User sich seine eigene Gruppenansicht zusammenstellen kann.

Schwarzes Brett / Marktplatz
Diese beiden Punkte wurden angefragt. Es hat sich aber rausgestellt, dass damit im Prinzip das Gleiche gemeint ist.
Die gewünschte Funktion läßt sich mit Aktivierung des vorinstallierten Moduls „shoutbox“ sehr einfach umsetzen

Foren und Blogs
Beides wurde angefragt, es hat sich aber schnell heraus gestellt, dass die gewünschten Zwecke mit dem Foren - Modul umzusetzen sind und kein zusätzliches Blog-Modul nötig ist.

Volltextsuche unter Windwos
Besonders wichtig war dem Kunden die Suche in PDF und außerdem wünschenswerte eine Suche in Word und Exvel.

Da das Projekt auf einem Windows-Server läuft, war die Umsetzung nicht ganz einfach. Auch weil sich die verfügbaren Dokus im Web fast ausschließlich auf Linux beziehen.

Im Backend vin TikiWiki läßt sich einstellen, daß die Suche mit MySQL Fulltextindex funktionieren soll:

Suche: Einstellungen im Backend von TikiWiki

Auf dem Server müssen die Programme für die Suche in Dateien unabhängig von TikiWiki installiert sein.
Für Suche in PDF steht für Windows Xpdf zur Verfügung und konnte auch problemlos eingerichtet werden.
Für Excel und Word steht unter Linux Catdoc zur Verfügung.
Es gab vor Jahren ein Projekt, um Catdoc auch für Windows zur Verfügung zu stellen.
Dieses Programm wird aber offensichtlich nicht weiter verfolgt und die Version, die im Netz verfügbar ist, funktioniert nicht auf Windows 7-Servern.

Deshalb konnte eine Suche in Word und Excel auf dem Windows-Server nicht umgesetzt werden.

Damit das Programm für die Indizierung der PDF's aufgerufen wird, muss im Modul FileGallery der Pfad zu diesem Programm hinterlegt werden.
Das Helperprogramm pdftotext benötigt einen Parameter, damit Umlaute mit utf8 indiziert werden:

"C:\Pfad-zum-xpdf-Programm\pdftotext.exe" -enc UTF-8 %1 -

Ein Wunsch des Kunden war, dass auch Worte mit weniger als drei Buchstaben in den Index aufgenommen werden, da in den Artikeln häufig firmeninterne Abkürzungen verwendet werden.
Da im TikiWiki eingestellt ist, dass die MySQL-Volltextsuche verwendet werden soll, muss eine Konfiguration in der my.ini vorgenommen werden:

ft_min_word_len=3

Anpassung des Templates
TikiWiki liefert eine Template Engine, die Individual-Anpassungen einfach vornehmen läßt.

Dazu wird einfach eines der mitgelieferten Standard-Themes in den individuellen Theme-Ordner kopiert und gibt im Backend den Namen des neuen Themes an.
Dies passiert im Plugin Look & Feel.

Plugin Look&Feel für die Verwaltung des Templates von TikiWiki

In diesem eigenen Template kann nun das CSS angepasst werden oder es werden Template-Dateien der Plugins hierher kopiert und verändert.
Für Logische Abfragen (z.B. auf bestimmte Gruppen-Zugehörigkeiten) steht Smarty zur Verfügung.

Bei diesem Projekt wurde vor allem die Startseite mit der Anmeldung verändert und die Suche-Templates.

 

Fazit

Die vorab geschätzten Punkte haben sich auch in der Praxis bewahrheitet.

Tikiwiki kann viele Funktionen für ein Intranet Out-Of-The-Box.
Auch spezielle Kundenwünsche können umgesetzt werden, ohne Programmieraufwand.
Allerdings ist dazu schon recht viel Kreativität gefragt.

In der Praxis hat sich das Kategorien-System sehr bewährt, um unterschiedlichen Abteilungen der Firma eine ganz andere Oberfläche zu bieten.

Wenn TikiWiki nicht bereits im Einsatz gewesen wäre, dann wäre dennoch Drupal unsere Empfehlung gewesen, welches auch alle Ansprüche abgedeckt hätte und in den individuellen Anpassungen noch einfacher und flexibeler wäre.

Die Template Engine mit Smarty ist - für meinen Geschmack - deutlich weniger smart, als die für Drupal.
Die Textverwaltung in Drupal ist Out-of-the-Box wesentlich komfortabler.
Bei TikiWiki muss man einige Anpassungen vornehmen, damit der Wysiwyg-Editor reines HTML statt der Wiki-Syntax verwendet.

Die diversen Probleme bei der Suche lassen sich auf die Verwendung des Windows-Servers zurück führen und sind folglich nicht CMS-typisch.