Foliensatz zu Martin Häberle's Präsentation "Mythos und Wahrheit: Wikis für die Technische Dokumentation" bei der tekom Regionalgruppe Stuttgart am 30. April 2014 Slidedeck of Martin Häberle's presentation about Wikis for Technical Documentation at the tekom Regionalgruppentreffen Stuttgart, April 30th 2014 See http://www.tekom.de/ueber-uns/regionalgruppen/termine.html?tx_tekomwebforum_webforumtermin[uid]=8225&tx_tekomwebforum_webforumtermin[action]=show&tx_tekomwebforum_webforumtermin[controller]=WebforumTermin&cHash=506c752271f2ece081efa125e626ed9b for further details about the event (German).

2. Martin Häberle
Diplom-Technikredakteur (FH)
Consultant, K15t Software
@Lesegefahr
Wer bin ich??

3. Mythos und Wahrheit:
Wikis für die Technische Dokumentation
Vortrag bei der tekom-Regionalgruppe Stuttgart
30. April 2014
!
Martin Häberle, K15t Software GmbH

4. Heute wird aufgeräumt:
10 Wiki-Mythen unter der Lupe

5. We believe that wiki-based technologies will
be the future for technical documentation.
“
”

6. Wiki, or what?
?

7. • 30 Millionen Artikel in über 280 Sprachen
• 1,7 Millionen Benutzer (und unzählige Anonyme)
• Deutsche Wikipedia: über 6.100 aktive Autoren
!
• Regionales Wiki mit rund 24.000 Artikeln und
29.000 Bildern
• 105 aktive Nutzer (6.000 Anmeldungen)
Erfolgreiche Wikis „da draußen“?

8. bieten typische Funktionen, die für
Unternehmensanwendungen notwendig sind:
• Strukturierung
• Schnittstellen
• Versionierung
• Benutzerzugriffskontrolle
Enterprise-Wikis?

9. Arbeiten im Wiki
1

10. In Wikis zu arbeiten ist doch
immer ein einziger K(r)ampf
mit dieser Wiki-Syntax
1
”
Aussage:
“

11. In vielen Fällen: wahr! Leider!
'''Wikipedia'''
[{{IPA|ˌvɪkiˈpeːdia}}]
ist
ein
am
[[15.
Januar|15. Januar]]
[[2001]]
gegründetes
Projekt
zur
Erstellung
eines
[[Freie
Inhalte|freien]]
[[Onlinelexikon]]s
in
zahlreichen
Sprachen.
1

12. Es gibt aber auch Ausnahmen1

13. • Grafischer Editor – „WYSIWYG“
• Drag and Drop
• Tastenkürzel für Überschriftenformate etc.
Editieren wie es sein sollte1

14. Besser:
“
”
Mit klassischen Wikis zu arbeiten
ist ein einziger K(r)ampf mit der
Wiki-Syntax“
1

15. 2
Word vs. Wiki

16. Mit Word und im Dateisystem
arbeiten wir doch viel effizienter
2 Aussage:
“
”

17. • … nur eine Person Inhalte erstellt/bearbeitet;
• … diese Person exzellent MS Word beherrscht;
• … Inhalte nur an einer Stelle veröffentlicht werden;
• … die Infos nur in diesem Dokument benötigt werden.
Stimmt! Allerdings bloß wenn …2

18. z.B. thematisch, nach Datum, nach Version
Ablage im Dateisystem2

19. • Nutzer arbeiten komfortabel im Browser
• Alle Inhalte werden zentral im Wiki gepflegt
• Inhalte/Seiten werden „getaggt“ + zusammengestellt
• Versionierte Dateianhänge für Seiten
• Änderungshistorie; ggf. explizite Versionierung
• Für alle transparent, was sich ändert
In Enterprise Wikis2

20. Word ist so social wie ein Pfund Zwiebelmett.
Kurz:2

21. 3
Struktur

22. Wikis haben keine Struktur
und man findet nichts darin
3 Aussage:
“
”

23. • Historisch bedingtes Vorurteil (Technologie)
• Pauschal nicht gültig; Enterprise Wikis beheben
genau diese Mängel.
• Fehlende Einführungsstrategie (von Einzelpersonen
bzw. Einzelprojekten getrieben)
Wikis als „chaotische Info-Sammlung“3

24. • Bereiche (thematisch, nach Zugriff, je Handbuch …)
• Hierarchische Strukturen (beliebig tiefe Unterseiten)
• Finden statt suchen (Volltext-Indizierung)
• Labels zum Gruppieren von Seiten
• Links zwischen Seiten, Bereichen
• Vorlagen für einheitliche Seitenstrukturen
Beispiel3

25. 4
Wiederverwendung

26. Wiki-Inhalte lassen sich nicht
modular wieder verwenden
4 Aussage:
“
”

27. Seitenstruktur mit Homepage
Wiederverwendung-Bibliothek
• Nur für Autoren sichtbar
• Beliebig inkludierbar
• Seitentitel: _Modulname
• auf Wunsch versioniert
Wiederverwendung mit Confluence4

28. 5
Versionierung / Varianten

29. Kein Wiki geht vernünftig mit
Versionen und Varianten um
5 Aussage:
“
”

30. Ein (Enterprise) Wiki ist kein klassisches CMS, sondern
eine Plattform für Kollaboration und Wissensmanagement.
Gute Nachrichten: Wikis wie Confluence sind
erweiterbar und es gibt zahlreiche Add-ons
für verschiedene Anwendungsfälle.
Ertappt!5

31. Versionierung
Varianten-Management
Mehrsprachigkeit
Übersetzungs-
Import/Export
Mehrfache Seitentitel,
SEO
5 Content Management Add-ons

32. 6
Schnittstellen

33. Aber für unsere Sprach-Tools
gibt’s keine Schnittstellen, oder?
6 Aussage:
“
”

34. • TMS-Export/Import via XML-Schnittstelle
• Beliebig viele Sprachen
• Delta vs. Komplettübersetzung
Übersetzungs-Management6

35. via Acrolinx
• Terminologie-Check
• Stilregeln
• Grammatik und Rechtschreibung
Sprachprüfung6

36. Sprachprüfung6

37. 7
Qualität

38. Wenn jeder alles bearbeiten darf,
geht die Qualität den Bach runter
7 Aussage:
“
”

39. Keiner hat ein Interesse daran, fehlerhafte
Inhalte beizusteuern.
!
Ausnahme: Vandalismus (gibt es in
Enterprise Wikis nicht)
Fehlerhafte Inhalte7

40. Sind auch im Wiki möglich.
Nutzer werden aber zumeist
ohne Not eingeengt.
Beschränkungen und Freigabe-Workflows7

41. Motivierte Wiki-Autoren verbessern sich gegenseitig!
Ex-post-Qualitätssicherung7

42. Statt Restriktionen lieber einfache Bearbeitung durch
möglichst viele Benutzer.
Eine Folge ist die Auflösung der Grenze zwischen
Inhalts-Produzenten und -Konsumenten.
The Wiki way7

43. Nur weil viele Technische Redaktionen ein
spezielles CMS mit Workflows etc. einsetzen, ist die
Informationsqualität nicht automatisch höher.
„Garbage in – garbage out“7

44. Redaktionssysteme werden oft nicht optimal genutzt
(siehe Kennzahlen zur Wiederverwendung)
CMS-Studie der tekom:7

45. • sind komplex, auch in der Bedienung;
• können nur von einem extrem begrenztem
Anwenderkreis genutzt werden.
• „Informations-Silos“
Redaktionssysteme …7

46. 8
Single-Source Publishing

47. Single-Source Publishing und
Druckausgabe für Wikis ist reines
Wunschdenken
8 Aussage:
“
”

48. Ausgabe in PDF, HTML, Word (einzelne Seiten)
ist eine Standardfunktion von Confluence
Erweiterte Ausgabe über Add-ons
Exportformate8

49. 9
Nutzung

50. Niemand liest das Wiki, oder
trägt freiwillig Inhalte bei
9 Aussage:
“
”

51. 9 Alles ein Frage der Unternehmens-Kultur

52. • alle Mitarbeiter nutzen Confluence (+ JIRA)
• Intranet (Organisation, Prozesse, Ablage,
Besprechungsprotokolle)
• Software-Spezifikationen und Projektinfos
• Dokumentation für alle Scroll-Produkte
• Website und Blog auf Confluence
9 „Drink your own Champagne“

53. Ordnet und
reduziert Chaos
Motiviert und hilft
Schafft
Strukturen
Baut einen
Grundstock
Repariert
„Broken Windows“
Ist die „1“ in der
90-9-1-Regel
Unverzichtbar: Wiki-Gärtner9

54. 10
Für Kunden

55. Ein Wiki mag intern etwas taugen,
aber doch nicht für Kunden
10 Aussage:
“
”

56. … denn Dokumentation endet nicht bei deren
Veröffentlichung.
Jetzt geht’s erst richtig los!10

57. Wiki
Technische Redakteure
Produktmanager
Entwickler
/Ingenieure
Fachexperten
Übersetzer
Qualitätssicherung
Marketing
Dienstleister
Partner
Kunden
Lieferanten
Händler
InteressentenFeedback
!
(Kommentare)
!
Fragen
Doku
!
Produkt-
infos
!
Fachwissen

58. • Produktdokumentation
• Öffentlicher Wiki-Zugang
• alle dürfen kommentieren
• Anregungen, Fragen und
Antworten
• Bereich für Austausch mit
Kunden/Partnern
https://confluence.atlassian.com/display/DOC/Cheese+Macro
Beispiel Atlassian10

59. Wiki-basierte Dokumentation ist nicht bloß möglich,
sondern wird x-fach erfolgreich praktiziert.
Fazit

60. Ein Wiki ist für viele Anwendungsfälle nicht nur
gleichwertig, sondern sogar haushoch überlegen.
Fazit

61. Die allermeisten Wiki-Mythen sind zu pauschal, um
wahr zu sein. Das heißt sie sind falsch.
Fazit

62. Fragen & Antworten
?

63. info@k15t.com
@k15tsoftware
www.k15t.com
Heute: Tobias, Nils, Martin
In Kontakt bleiben@
Einladung: Webinar am Mittwoch, 7. Mai
„Content Management mit Confluence“