Atlassian Confluence, von Atlassian seit jeher als „Enterprise Wiki“ bezeichnet, wird nun wirklich immer mehr „Enterprise-ready“. Ich beziehe die „Enterprise“-Anforderung dabei eher auf die Bedürfnisse des typischen Enterprise Users (aka Business User oder Information Worker), also der mit MS Word, Excel und Powerpoint arbeitende dokumentenbasierte Usertyp. Aus technischer Sicht ist Confluence schon lange für Unternehmen einsetzbar (Java, Clusterfähig, Oracle support, LDAP Integration, etc)
Aus meinen Erfahrungen bei PXP im Einsatz von Confluence war mir klar, dass Atlassian irgendwann die pure Wiki-Metapher etwas erweitern muss, um in einem Unternehmen nicht nur die Techies zu erreichen. Verwaltung und Anzeige von Dokumenten, ein bulletproof Richtexteditor, strukturierte Datenverwaltung über Formulare, Templates für die Anzeige von Informationen – all das ist nun grundsätzlich vorhanden. Zusätzlich stellt Confluence nun immer mehr die Benutzer und ihre Aktionen in den Vordergrund und platziert diese rund um den Content.
In der Theorie war das schon seit ca Version 2.7 so, in der Realität allerdings waren ein paar kleinere Bugs und fehlende Features dafür verantwortlich, dass ich immer mit etwas Erklärungsnotstand vor den Business Usern saß.
Was ist also neu und erwähnenswert in Atlassian Confluence 2.10:
- (Verbesserter) Office Connector für MS Office und Open Office, bundled im Produkt: Wikiinhalte können in Word editiert werden, Worddokumente direkt in Wikiinhalte umgewandelt werden
- Automatische inline view Funktionen von MS Office und Open Office Dokumente: die Anzeige von Office Dokumenten direkt im Wiki über die manuelle Platzierung des ViewFile Macros war schon länger möglich, nun ist die Funktion automatisiert integriert. Man benötigt kein MS Office oder Open Office, sondern kann Word, Excel oder PowerPoint Dokumentedirekt im Browser betrachten
- Default Homepage für Spaces, d.h. einfache Space-Templates. Die Grundfunktion gabs schon lange, allerdings erst mit 2.10 den Bugfix für Default Space Content does not support macro, der die Funktion unbrauchbar machte. Nun kann die Startseite von zb Projektspaces einheitliche Funktionen und Aussehen bereitstellen. Komplexe Templates für Spaceinhalte müssen aber weiterhin über Plugins selbst entwickelt werden.
- Widget Connector: Konsolidierung vieler Einzelmacros (flickr macros etc), simples einbinden von Google Gadgets, Videos, Twitter und Friend Feed, Slidehare, Sliderocket, Scribd etc.
- Verbesserte JIRA Macros zur Anbindung von Atlassian JIRA Issue Management
- Nett: Admin interface für CSS Stylesheet Änderungen
- Verbesserte Plugin Architektur
Seit langem ist mir unverständlich, warum Confluence in einem für mich wesentlichen Punkt zb Jives Clearspace und Mindtouch’s Deki absolut hinterherhinkt: Die Benutzbarkeit von Macros ohne Eingabe von Code – d.h. die Benutzbarkeit von 90% der Funktionalität für 90% der Anwender über ein User Interface zur Konfiguration der Macros. Nun endlich die Ankündigung für die Version 3.0: der Confluence Macro Browser soll diese Lücke schliessen. Hiermit kann endlich die volle Funktionsvielfalt der Zusatzmakros über ein Userinterface für alle Benutzer erschlossen werden. Ich hoffe Confluence 3.0 wird bald veröffentlicht, in der Zwischenzeit (und nicht nur da) lohnt sich auch ein Blick auf Mindtouch’s Deki – mit seinem dual licencing scheme sowohl im Enterprise als auch im Privatumfeld interessant. Die Diskussion zum Vergleich Confluence vs Deki im Deki Forum ist für Interessierte sehr zu empfehlen.
Um den Hintergrund darzustellen: Ich halte Atlassian Confluence für eines der besten Stück Software, die im Umfeld Web Content Management je geschrieben wurden – für Intra- und Extranetprojekte sowieso, für Internetprojekte in zunehmenden Maße. Viele Web CMS Systeme und Frameworks sind für mich Ungetüme aus der Urzeit des Internets, wo ein Projekt immer endete, wenn es eigentlich erst beginnen sollte: Zum Zeitpunkt des Launches. Schon lange vor dem Launch ist es mit der Flexibilität zur Anpassung an geänderte Rahmenbedingungen vorbei. Es wird in hundertseitigen Dokumenten die Funktionsweise eines Systems in jedem Detail beschrieben, Frameworks gekauft, die die Komplexität (und den Preis) einer Marsmission haben, 5 stufige Workflows mit 3 stelligen Versionsziffern spezifiziert und Content Master zu Sklaven ihres Systems degradiert. Es mag große und komplexe Projekte geben wo dies der einzig mögliche Weg ist, oftmals ist es aber Overkill und erfolgsverhindernd.
Ein Projekt mit Atlassian Confluence kann anders aussehen. Die Wiki-Metapher determiniert die Art der Nutzung nicht schon vor Beginn des Livegangs, vieles kann on-the-fly (durch Macros, Seitenstrukturen, ad-hoc Prozesse, etc) erweitert werden, grössere Änderungen durch die Entwicklung von Plugin Extensions trotzdem realisiert werden. Für den trotzdem häufig benötigten strukturierten und „starren“ Teil des Intra- oder Extranets kann man entweder mit Confluence pragmatische Lösungen finden oder Microsoft Sharepoint anbinden. Zu Sharepoint kann man stehen wie man will, im Enterprise Umfeld kommt man schwer dran vorbei. Atlassian ist ein offizieller Microsoft Partner und hat den Confluence Sharepoint Connector entwickelt (wurde übrigens scheinbar nun verbilligt!). Damit können Confluence und Sharepoint bidirektional verbunden werden. Eine tiefgreifende technische Erklärung findet sich im MOSS Team Blog unter SharePoint Connector for Confluence – How We Did It.
Dieser Artikel hat als Grundlage den von mir im PXP Blog verfassten Artikel Confluence Wiki und die Bedürfnisse des Enterprise Users. Fragen und Anregungen gerne in den Kommentaren beider Artikel.
Neueste Kommentare