Wahl der Waffen, Teil III: Wiki oder Onlinehilfe? 15.08.201503.11.2018 (Bildquelle siehe unten) Alle wollen weg vom Papier. Auch in der Technischen Dokumentation stehen Dokumentationsverantwortliche und Redakteure oft vor der Entscheidung: soll ich einer vermeintlichen Gesetzeslage folgen und für den Anwalt dokumentieren oder für den Benutzer und das Produkt?1 Nun ist es natürlich so, dass der Hersteller und Inverkehrbringer dafür zuständig ist, dass der Benutzer das Prodiukt auch sicher und zuverlässig benutzen kann. Die Benutzung muss also dokumentiert werden. Aber wie? No print, please! Papier ist geduldig und Papier ist teuer, langsam und schlecht zu durchsuchen. Kurz: Papier widerspricht allen ergonomischen Anforderungen an eine Technische Dokumentation. Papier ist eine Krücke, ein kleinster gemeinsamer Nenner aus einer Zeit, als die Industrialisierung noch Werktätige bevorzugte, die “ihre” Maschine noch selbst reparieren konnten. Papier ist Industrie 2.0. Seit einigen Jahren aber bewegen wir uns mit hoher Geschwindigkeit auf Industrie 4.0 zu: alle Geräte sollen miteinander kommunizieren können. Auch wenn es dem einen oder anderen Technikskeptiker kalte Schauer über den Rücken jagt: wenn das nicht ginge, könnte er nicht mal telefonieren. Getrieben von der rasanten Entwicklung der Telekommunikationsmöglichkeiten und der Verbreitung digitaler Lesegeräte und mobiler Computer (vor allem Smartphones) steht nun auch die Technische Dokumentation vor einer großen Herausforderung: Weg von Gutenberg. Nicht mehr nur die Lettern sind beweglich, die Information ist es auch. Angesichts der Tatsache, dass weltweit über 1500 Millionen Smartphones im Umlauf sind2, kann man eigentlich von einer echten Wahl nicht mehr sprechen: Technische Dokumentation muss online. Punkt.3 Wie kommt man aus der Nummer raus? Gar nicht. Sofern der Inhalt topic-orientiert geschrieben ist4, kommt in der Redaktion ein Thema auf, über dass sich die Beteiligten die Köpfe heiß reden können: Nehmen wir eine Onlinehilfe oder nehmen wir ein Wiki? Beides ergibt Sinn, wenn klar ist, wie sich die Anwendung- und Erstellungsprozess unterscheiden. Denn eigentlich unterscheiden sich die Inhalte ja nicht. Statt einer Plus-Minus-Liste stelle ich nun ein paar Überlegungen gegenüber, die eine Entscheidung erleichtern können. Wiki „Onlinehilfe“ Erfordert Server oder Online-Zugang Kann offline verwendet werden als verlinkte Dokumentensammlung Browserunabhängig Benötigt ggf. Plug-ins Durchsuchbar Durchsuchbar Nutzt Hyperlinks Nutzt Hyperlinks HTML/CSS HTML/CSS/JavaScript (HTML-Version einstellbar) Jederzeit direkt aktualisierbar, kann von allen berechtigten Benutzern geändert werden Muss nach der Aktualisierung neu ausgegeben (kompiliert) werden, benötigt daher einen definierten Redaktionsprozess Übersetzbar Übersetzbar Browser für Ein- und Ausgabe Editor für die Eingabe, Browser für die Ausgabe Inhaltsverzeichnis nur für eine Seite Inhaltsverzeichnis über alle Seiten Festgelegte Benutzeroberfläche Konfigurierbare Benutzeroberfläche (im Editor) Review nach der Publikation (Änderung) Review vor der Publikation Inhalte von allen Berechtigten betreut Inhalte von Redakteuren betreut Es ist also nicht ganz trivial und hängt davon ab, wozu man diese Dokumentation einsetzen möchte. Für ein internes Dokumentationssystem ist ein Wiki sicher die bessere Wahl, da die Aktualisierung nicht von einzelnen Mitarbeitern abhängt. Allerdings erfordert dies auch eine gewisse Schulung der Berechtigten, denn das Wiki verkommt schnell zu einem losen „Papierstapel“, in dem niemand etwas wiederfindet, wenn er nicht den richtigen Suchbegriff kennt. Andererseits hat eine Onlinehilfe (auch wenn sie offline verwendet werden kann) in der Benutzerdokumentation gerade dort ihre Stärke, dass sie eben in einen Informationsprozess eingebunden ist und beispielsweise nur aktualisiert wird, wenn es Produktänderungen gibt. Auch ist der Dokumentation- und Inhaltsverantwortliche (Redaktion und Freigabe) damit besser greifbar. Die Onlinehilfe benötigt dazu jedoch einen gut organisierten Redaktionsprozess. Letzteres ist für ein internes Dokumentationssystem meist zuviel des Guten. Optimal allerdings ist es, wenn bei der Konzeption beides gleich mitgedacht wird, so dass sich die Publikationstypen ergänzen: Produktneuheiten kommen ins Wiki, Kundensupport in die Onlinehilfe. Das geht zwar auch, führt aber an dieser Stelle zu weit. Bildquelle: „Die Waffen der Wartburg 319 Tafel 55“ von Alfons Diener-Schönberg *19.08.1879 +16.11.1936. (pnd130137626) – Alfons Diener-Schönberg: Die Waffen der Wartburg (1912) Tafel 55. Lizenziert unter Gemeinfrei über Wikimedia Commons) Es ist eine weit verbreitete Missinterpretation, dass laut Maschinenrichtlinie Papier immer gefordert ist. Das steht da nicht. Der Absatz 1.7.4 in der MRL bezieht sich zwar auf alle möglichen Aspekte wie Sicherheitshinweise und Herstellerangaben – von Papier ist da aber keine Rede. Nirgends. ↩laut Statista ↩Auch wenn sich viele Anbieter und Hersteller noch immer auf den zugegebenermaßen einfachen Prozess zurückziehen, aus einer papier- und druckorientierten Ausgabe eine PDF zu machen, ist PDF kein wirklicher Fortschritt. Wer schon mal versucht hat, die Ergüsse der Marketingabteilungen als PDF auf seinem Smartphone zu lesen, der weiß, dass das schlicht unmöglich ist. Von technischen Daten ganz zu schweigen. ↩Wie man das macht, steht an anderer Stelle in diesem Blog: Topics: Informationshäppchen hirngerecht servieren ↩Gefällt mir:Gefällt mir Wird geladen … dokumentation online publishing redaktion technische dokumentation InformationszeitalterInternetTechnische Kommunikation
dokumentation Gehirngekrakel: von der Idee zur Zeichnung 25.11.201703.11.2018 Kreativität sei 10% Inspiration und 90% Transpiration, hat mal Thomas Edison behauptet – stimmt auch… Teilen mit:MastodonWhatsAppE‑MailBlueskyMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More
dokumentation Usability: Listen und Handlungen lesegerecht gestalten 05.05.2007 Eine der schlimmsten Vorstellungen des Technischen Redakteurs ist die „Brainstorming“-artige Informationsvermittlung des Programmierers oder Konstrukteurs.… Teilen mit:MastodonWhatsAppE‑MailBlueskyMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More
appseits Smarter mailen mit Spark 09.10.201708.01.2022 Wer ein neueres Gerät mit iOS und macOS besitzt und sich vor allem bei iOS… Teilen mit:MastodonWhatsAppE‑MailBlueskyMehrDruckenLinkedInTelegramPinterestGefällt mir:Gefällt mir Wird geladen … Read More