Das Wiregate und die Dokumentation - Confluence Server BEREIT

[StefanW]

Kurzer Zwischenstand: Ich habe mich derweilen ein wenig in Bluespice eingelesen, das ist eine Entwicklung einer Regensburger Firma zur Erweiterung des Mediawiki. Einige der Module sind kostenfrei, andere kostenpflichtig. Was mir gefällt ist, dass evt. Ausgaben an eine deutsche Firma und deutsche Arbeitsplätze gehen. Soweit für mich als völlig wiki-unerfahren überhaupt beurteilbar, läßt sich damit auch alles machen und es wird bei uns gehostet und die DB liegt komplett offen.

Mit dem Lesen bin ich auf weitere Gedanken gekommen, wie ich damit auch innerbetriebliche Doku, Ablaufbeschreibungen, Herstellungsanweisungen, Testprozeduren kollaborativ erstellen und speichern kann. Insofern würde sich auch von unserer Seite die Einarbeitung lohnen, so dass wir dann auch nicht nur bei der offiziellen Doku, sondern auch administrativ bei der Community-Doku unterstützen könnten.

Soll aber keine Vorab-Entscheidung für Bluespice sein, ich muss mir noch Confluence näher ansehen. Vielleicht habe ich ja ein AHA Erlebnis, dass mir über die bisher bekannten Einschränkungen hilft.

Freut mich sehr, dass wir das Thema nun in Fahrt bekommen.

Lg

Stefan

[wuestenfuchs]

Schön, freut mich auch! Danke, dass du uns da auch an deinen Überlegungen teilhaben lässt!

[Hannatz]

Das Wiregate und die Dokumentation

Hey, schön das dieses Thema doch noch Fahrt aufnimmt!!
In Sachen Confluence (und Jira) bin ich mittlerweile ganz fit, betreibe den ganzen Kram bei uns mit jeweils 500 Usern. Gerne kann ich den administrativen Kram übernehmen sowie "User-Support" (wie mache ich dieses oder wie funktioniert jene Funktion) anbieten. Soweit ich das beurteilen kann ist Confluence das aktuell leistungsfähige Wiki, durch die hohe Verbreitung gibt es auch ne Menge (teilweise kostenloser) Plugins. So hat die Integration von Diagram.ly bspw. die Qualität der Dokumentation bei uns erheblich verbessert.

@Stefan: Falls Ihr sowas noch sucht, neben dem sehr guten Wiki an sich (schau Dir mal das Helpdesk-Plugin an) ist die Integration zu Jira (Ticketsystem) einfach super. Haben innerhalb von 6 Monaten quasi die komplette Software-Entwicklung darauf umgestellt, und dass weil die Kollegen das selber wollten (sind sonst IBM oder Oracle-geschädigt...)

Bzgl. der Useraccounts sind licensed User nur für die Schreiberlinge notwendig, lesen und/oder kommentieren kann man auch anonym.

So Sachen wie Inhaltsverzeichnisse etc. bauen sich selber, einfach Content erstellen und den Rest schubse ich dann schon zurecht. Am wichtigsten ist aber die Frage: lokal installiert oder gehosted? Wenn lokal, was sind die Specs?

Gruss Hannatz


Gesendet von meinem iPad mit Tapatalk

[swiss]

Die Frage ist, wozu braucht man ein endloses Inhaltsverzeichniss als Navigation? Ich denke über 90% der Leute die das Handbuch zu rate ziehen interessieren sich nur für dass Problem oder die Frage die sie aktuell gerade beschäftigt. Kaum einer wird sich das Handbuch durchlesen. Wenn jemand ein Problem mit Plugins hat schlägt er gleich das Kapiter Plugins oder im Mediawiki die Portalseite Plugins auf. Weil ihn die Themen VPN, Sensoren und weitere im Moment nicht interessieren.

Also sehe ich momentan keinen wirklichen Vorteil den Confluence gegenüber dem Mediawiki mit bluespice haben soll. Aber vieleicht habe ich die wahren "Super Argumente" für confluence einfach noch nicht gefunden.

Kann mich da jemand aufklären? Scheinbar gibt es hier ja sehr viele Wissende

[Hannatz]

Das Wiregate und die Dokumentation

Bluespice kenne ich nicht, sorry.
Aber die guten Wikis haben heutzutage eigentlich alle die gleichen Grundfunktionalitäten (Volltext-indiziert, guter Editor, Versionierung, pluginfähig usw.), falls nicht vorhanden gleich vergessen! ;-)
Aus meiner Erfahrung sind die verfügbaren/bezahlbaren Plugins sowie die Usability entscheidend, wenn du deine User nicht zufriedenstellen kannst (warum oder was auch immer) dann leidet die Akzeptanz. Im Vergleich zu den alten Sachen bei uns Inder Firma waren die sehr gute Suche (wie Google, schnell und sucht bspw auch in Kommentaren oder Anhängen) sowie direkt im Browser malen (XML, BPMN, Netzwerkdiagramme) die "Killerargumente"

Also, bei Confluence kann ich administrativ unterstützen, bei Bluespice wäre ich halt Autor.


Gesendet von meinem iPad mit Tapatalk

[bluegaspode]

Die Frage ist, wozu braucht man ein endloses Inhaltsverzeichniss als Navigation?

Wie findet ein Benutzer, der sich nicht mit dem Wiregate auskennt den ihn interessierenden Content?

Der BlueSpice-Artikel behauptet, Benutzer verwenden die Suchfunktion - das mag bei 'ner WikiPedia vielleicht sogar stimmen. In einem Benutzerhandbuch passt das aber nicht - denn man weiß ja nicht, welcher Suchbegriff einen überhaupt zum Erfolg bringt.

=> Suche ist nicht zum Einstieg in die Thematik und nur bedingt zum Auffinden der Artikel geeignet.

Wie dann Artikel finden?
Na klar kannst du ein paar Hauptartikel auch im MediaWiki links platzieren. Doch was passiert dann? Alle 'tieferen' Artikel sind nun nur noch über aktive (meist gut im Text versteckte) Links zu erreichen.
Um jetzt Content zu finden/die Seiten zu entdecken, müsste man die Hauptartikel sehr genau lesen - und manche Seiten findet man nur über zwei/drei Linkverkettungen. Dann hast du aber auf einmal den Überblick verloren, wo man sich eigentlich befindet und wie man zurück kommt (Browser-Back-Button?).

=> ein "Netz" von Webseiten, die untereinander verlinkt sind (+Einstiegsseiten) passt nicht zum Konzept Benutzerhandbuch, bzw. lässt viel zu viel Content unentdeckt (weil man die Links beim Überfliegen gar nicht mehr verfolgt).

Bestes Beispiel für diese Problem ist für mich das CometVisu-Wiki. Bestimmte (richtig gute Seiten, die mich interessiert haben) fand ich nur über die "All Pages" Ansicht. Ich weiß bis heute nicht, wie ich sie auf "normalen" Navigationspfaden gefunden hätte.
Und das obwohl du ja sehr engagiert den Content erzeugt hast. Was soll erst passieren, wenn es mehr Leute gibt, die aber nur halb so engagiert sind?

Lösbar sind diese Probleme für mich nur mit einem ordentlichen Inhaltsverzeichnis. Und zwar eines, was ständig sichtbar ist, mir zeigt wo ich mich befinde (für die Übersichtlichkeit)- und was mich HighLevel zum stöbern durch die Überschriften anregt.

Ein Inhaltsverzeichnis zwingt darüber hinaus die Autoren einen roten Faden aufzubauen! Ein wesentliches Konzept (und Qualitätsmerkmal) für übersichtliche und verständliche Dokumentation, was bei freier Verlinkung nicht einmal ansatzweise passiert.

Wenn BlueSpice das bieten kann (vielleicht mit diesem kostenpflichtigen Plugin? bookmaker: BlueSpice - The free MediaWiki Enterprise Distribution), dann gerne.
Ohne Inhaltsverzeichnis -> glaube ich nicht an Übersichtlichkeit und den roten Faden.

Ich denke über 90% der Leute die das Handbuch zu rate ziehen interessieren sich nur für dass Problem oder die Frage die sie aktuell gerade beschäftigt.

Dafür wäre eine Suchfunktion ausreichend. Es wäre aber schade, wenn das der alleinige Fokus der Dokumentation sein sollte.
Als Neuling der die Grundinstallation hinbekommen hat, habe ich die Frage "mit welchen spannenden Sachen kann ich nun weitermachen".
Diese Frage ist nur explorativ zu lösen - und der einfachste Weg ohne 'ne Menge Text zu lesen ist ein Inhaltsverzeichnis zu scannen und aktiv bei bestimmten Themen abzutauchen.

Also sehe ich momentan keinen wirklichen Vorteil den Confluence gegenüber dem Mediawiki mit bluespice haben soll

Ich glaube der Grund warum Confluence so viele Fans hat, sind die vielen Kleinigkeiten, die ein stimmiges Gesamtkonzept ergeben. Und die einen motivieren, weiteren ordentlichen Content zu erzeugen.
Natürlich funktioniert ein Wiki auch ohne die ganzen vielen Kleinigkeiten, die nicht kriegsentscheidend sind. Aber eben nicht so gut.

Um noch ein paar Beispiele zu nennen, die ich so selten woanders gesehen habe, bei denen ich aber glaube, dass sie neben dem Inhaltsverzeichnis guten Content forcieren.

• das hätte dir bei der CometVisu-Doku viel geholfen: in Confluence kannst du Screenshots per Copy/Paste einfügen. Kein Abspeichern auf der Festplatte und Suchen im Fileexplorer + Upload nötig.
  Gibt es bei BlueSpice übrigens auch (für Geld): (paste image: BlueSpice - The free MediaWiki Enterprise Distribution)
  
• Confluence kommt auch mit Social Features daher. So hast du z.B. Like-Buttons an jedem Artikel. Wie stark das motiviert regelmäßig Content zu erzeugen, zeigen die sozialen Netzwerke. Gamification ist einfach nötigt, wenn es um freiwillige Arbeiten geht. Man kann auch mit @Name gezielt andere Autoren ansprechen (in Artikeln oder Kommentaren), diese bekommen dann Notifications und werden zurück zu den Artikeln gezogen.
  
• Confluence hat Kommentare: auch hier weiß ich aus der Praxis, wie dass die Qualität von Artikeln fördert. Auf einmal beteiligen sich Leute, die sich aus Respekt nie an den Hauptartikel getraut hätten, weil die Einstiegshürde deutlich niedriger ist.
  Kann ich dir im MediaWiki/BlueSpice unkompliziert Feedback geben, wenn ich in einem Artikel etwas nicht verstehe oder einen hilfreichen Hinweis habe? Wenn das gewährleistet super - wenn nicht - hätte ich Bauchschmerzen beim hoffen auf langfristigen Erfolg.
  
• Wysiwyg Editor (der funktioniert): Confluence hat vor zwei Jahren mit einem sehr radikalen Schritt die Wiki-Markup abgeschafft und alles auf einen funktionierenden Wysiwyg Editor gesetzt mit dem man normale Texte schreiben kann aber auch fortgeschrittene Sachen einfach hinbekommt (Layouting, Makros, Panels für Code z.B., Emoticons etc.). Das hat vor zwei Jahren sehr geschmerzt, weil es an vielen Stellen hakte. Inzwischen (gezwungen durch alle ihre Kunden) ist das Ding sehr sehr gut und ich glaube kaum, dass irgendein OpenSource Wysiwyg Editor mithalten kann.
  Reines Bauchgefühl - aber für mich sind die Zeiten wo ich Lust habe mich mit Wiki-Markup rumzuschlagen vorbei.

Auf all das kann man bestimmt irgendwie verzichten (oder sich mit viel Mühe durch die verfügbaren Plugins des MediaWiki durchwühlen). Confluence ist halt was seine Features betrifft in seiner Grundinstallation super ausbalanciert.

So - genug Fanboy Gesülze. Ich warte jetzt mal einfach ab, was passiert

[swiss]

Interessant... Nun habe ich mal etwas fleisch um die feinen Details mal genauer zu betrachten und mit dem Mediawiki zu vergleichen. In einigen der aufgeführten Punkten gebe ich dir recht. Klar ist z.B. das CometVisu Handbuch zusammengefrickelt. Dort war auch das Ziel dass gewisse Inhalte nicht direkt im Handbuch erscheinen weil das den Supportaufwand explodieren lassen könnte. Es gibt einige Dinge die zwar Dokumentiert sind aber der Ottonormalnutzer nicht unbedingt versuchen sollte weil es einiges an Grundwissen voraussetzt. Das Problem sehe ich beim Wiregate wehniger. Man teile einfach den gesammten Inhalt in "Standardfunktion" und "Expertenfunktion unsupportet". Auch braucht das Wiregatehandbuch nicht in mehreren Versionen gepflegt werden.

Aber wie gesagt eine Hauptseite mit den Haupttemen und darunter gut aufgreäumte Portalseiten können mindestens genau so leicht verständlich sein. Wer will schon ein stieres 500 Seiten starkes Handbuch lesen. Mich stört da schon das durchlesen von 5 Seiten Inhaltsverzeichniss um eine bestimmte Frage zu beantworten. Da sind klar strukturierte Abkürzungen in meinen Augen wesentlich Dankbarer (würde warscheinlich auch mit confluence gehen).

Also lieber:

Hauptseite -> Fernzugriff -> Ersteschritte

Als:

Hauptseite
-ersteschritte
--Einrichten von Sensoren
---Arten und einstellungen von Sensoren
---RRD Tool
--Konfiguration KNX
---Mögliche Schnittstellen und Parameter
--Socket einrichen
---Mögliche Soketparameter
--IP Konfiguration
--Updates
---Update durchführen
---Verfügbare Zusatzpakete
--VPN
---Serverkonfiguration
---Einrichte eines neuen Client
--Plugins
---Erste schritte
----Liste Fertiger Plugins und kurze Beschreibung
-----Plugin1 Beschreibung, installation konfiguration
-----Plugin2 Beschreibung, installation konfiguration
-----Plugin3 Beschreibung, installation konfiguration
----Plugins Selber Schreiben
-----HowToStart
usw...

Zumal es noch problematisch ist weil z.B. VPN sowohl in "erste schritte" wie auch zu "Expertenfunktion für Fortgeschrittene" gehöhren kann. Und da eine übersichtliche Baumstruktur zu erstellen ist auch mit confluence warscheinlich nicht einfach.

Wobei eine Kombination aus Portal und Seitenindex wohl eine gute Zwischenlösung sein könnte.

Aber lassen wir uns überaschen. Am Ende wird sich Stefan entscheiden und wir folgen

[StefanW]

Wow, das sind ja wirklich wunderbare Diskussionen auf sehr hohem Niveau, mit viel Kenntnissen und ein wenig Herzblut. So wie es sein soll! Wirklich wunderbar. So macht Community wirklich Spaß.

Ich denke alle Beteiligten lernen gerade sehr viel zum Thema Wiki und welche Feinheiten beachtenswert sind in der Realität.

Am Ende geht es aber nicht darum was mir gefällt, sondern was Euch gefällt (natürlich muss es bezahlbar sein). Akzeptanz und Motivation ist durch nichts zu ersetzen.

Aus Sicht desjenigen, der ab und an Texte für den Shop oder in Artikelform hier schreibt, kann ich sehr gut nachvollziehen, wie wichtig ein guter Editor ist. Gerade wenn es um Tabellen, Bilder usw. geht, kann man sich ohne guten Editor stundenlang abquälen. Ein Bild per Copy & Paste einzufügen (das dabei auch noch passend komprimiert wird) wäre der absolute Traum.

Nach meiner Erfahrung sind bebilderte Anleitungen nicht zu schlagen - aber eben auch das aufwändigste, Wenn das einfach geht, das wäre schon richtungsentscheidend.

So, muss mir nun dochmal Confluence näher ansehen, bin ich heute noch nicht dazu gekommen (bin auch im Urlaub).

Lg

Stefan

[Hannatz]

Und da eine übersichtliche Baumstruktur zu erstellen ist auch mit confluence warscheinlich nicht einfach.

Doch, wird anhand der Seiten und deren Position im Baum generiert. Einmal nen Macro eingefügt und fertig...

Aber mal sehen was Stefan sagt, letztendlich sollte der Hersteller hier aktiv mitarbeiten. Und wenn der mit der Plattform nicht glücklich ist...

Gruß Hannatz

[Robert_Mini]

Hab bisher in keinem Wiki bearbeitet.

Confluence ist absolut intuitiv, Layout etc. ähnlich. Word & Co.
Ich finde das sehr motivierend mitzuwirken. Einarbeitungszeit als Schreiber=0.

Zum Thema Verzeichnis:
Ich finde ein Inhaltsverzeichnis ideal, da man darin auch schmökern kann!
Und durch das Einklappen von Ebenen bleibt es jederzeit übersichtlich. Das sieht man bereits in der Demo, wo ich ein wenig gespielt habe.

Just my 5ct
Robert

[wuestenfuchs]

Beim Thema Inhaltsverzeichnis bin ich absolut bei euch. Halte ich auch für unverzichtbar. Argumente wurden ja schon genug genannt.

Was Confluence anbetrifft: So sehr ich das System durch das, was ich bisher gesehen habe, auch schätze, das größte Problem ist und bleibt die fehlende Skalierbarkeit. Gerade im OSS-Community-Bereich skalieren die Autor-Zahlen nun mal über die Zeit nach oben. Benutzerabhängige (im Sinne von Benutzer = Autor) Lizenzen skalieren da einfach nicht mit.

[swiss]

Ja dass mit den Lizenzen darf auch nicht ausser Aucht gelassen werden. Gerade wenn man möchte, dass z.B. Entwikler von Plugins ihr Werk selber dokumentieren hat man das Problem, dass man viele Accounts benötigt, mit denen vieleicht nur 1-2 Steiten gepflegt werden. Das spielt bei einer freien Lösung keine Rolle aber bei Lösungen bei denen man quasi pro Account bezahlt ist das keine befriedigende Lösung.

Die andere Frage ist noch wegen dem VendorLockin... Wie sieht es da aus? Wenn das Projekt aus irgendwelchen Gründen nicht läuft und sich Elabnet wegen den abnehmenden Autoren irgend wann entschliessen würde das Abonement zu kündigen oder diePlatform zu wechseln... Bekäme dann mit der Auflösung des Vertrages ElabNet die Daten in einem verwertbaren Format ausgehändigt? Denn (das wäre noch genau zu klären!) Die Inhalte unterligen ja dem Urheberrecht des Autoren oder ElabNet. Und Confluence hat im gegensatz zu ElabNet keinen Anspruch auf die Daten... Ausser dies wäre irgend wo in den Lizenzbedingungen so geregelt, dass der gesammte Inhalt der produziert wird in das Eigentum von Confluence übergehen würde <- Würde ich NIE akzeptieren und wäre ein Todesargument für das System.

[Hannatz]

Du hast jederzeit Vollzugriff auf die Daten, Export bspw. als XML/Doc/PDF. Wenn lokal gehosted dann kannst Du die DB aussuchen, wird einfach per JDBC eingebunden. OOTB wird ne MySQL mitgeliefert, sollte also ausreichen.
Lizenzen ist ein Thema, soweit korrekt. Man kann ohne Login Artikel schreiben, soweit kein Problem. Schöner ist sicherlich nen NamedAccount, aber ein anderer meinte ja das OpenSource kostenfreie Lizenzen ermöglicht? Sollte man sicher noch mal nachschauen...

[wuestenfuchs]

Die andere Frage ist noch wegen dem VendorLockin... Wie sieht es da aus? Wenn das Projekt aus irgendwelchen Gründen nicht läuft und sich Elabnet wegen den abnehmenden Autoren irgend wann entschliessen würde das Abonement zu kündigen oder diePlatform zu wechseln... Bekäme dann mit der Auflösung des Vertrages ElabNet die Daten in einem verwertbaren Format ausgehändigt? Denn (das wäre noch genau zu klären!) Die Inhalte unterligen ja dem Urheberrecht des Autoren oder ElabNet. Und Confluence hat im gegensatz zu ElabNet keinen Anspruch auf die Daten... Ausser dies wäre irgend wo in den Lizenzbedingungen so geregelt, dass der gesammte Inhalt der produziert wird in das Eigentum von Confluence übergehen würde <- Würde ich NIE akzeptieren und wäre ein Todesargument für das System.

Confluence kannst du in zwei Varianten bekommen: Entweder als gehostete Version auf deren Server oder als lokale Installation auf deinen eigenen Servern. Soweit ich Stefan richtig verstanden habe, möchte er die Dienste (verständlicherweise) selbst hosten.

Die Daten landen alle in einer Datenbank, d.h. die liegen dir lokal vor. Das ist auch nicht das Problem. Die Schwierigkeit besteht - wie bei allen Datenbanken - wie einfach du die Daten aus der Datenbank wieder strukturiert rauskriegst und in ein z.B. anderes System importieren kannst. Und das ist auch der Knackpunkt: Hersteller können die Daten wunderbar in eine z.B. MySQL oder PostgreSQL-Datenbank ablegen, du hast ja Zugriff drauf und kannst dir die Daten da rausholen. ABER: Der Hersteller kann es einem auch ziemlich schwierig machen, die Daten sinnvoll aus der Datenbank zu extrahieren - z.B. indem die Daten breit verteilt sind (Stichwort 'Normalform') oder vieles unnötigerweise in Binary Blobs gespeichert wird. Eine Frage ist z.B. wie und wo die Bilder, die per Copy&Paste in den Editor eingefügt werden können, abgelegt werden.

In einem Artikel habe ich davon gelesen, dass die Datenbankstruktur von Confluence nicht dokumentiert ist. Da wäre ein Export halt schwieriger, weil du dir die erforderlichen Zusammenhänge erst selbst erarbeiten musst - und das kann schon ziemlich komplex werden, so dass eine Herstellerabhängigkeit entstehen kann - selbst, wenn auf eine 'offene' Datenbank gesetzt wird.

[Hannatz]

Das DB-Schema liegt offen im Netz, haben da schon einige custom queries gebaut...
Aber, wer will denn im Migrationspfad direkt den DB-Content exportieren? Als XML raus und so wieder in eine neue Plattform rein.

Ok, ich glaub man merkt das ich von dem Atlassian-Kram überzeugt bin, aber wer vorher mit Sharepoint oder Lotus Connections gefoltert worden ist kann das vielleicht nachvollziehen...

Warten wir mal was Stefan sagt!