DD #006 Die digitale Anleitung – Publizieren in HTML
![DD #006 Die Digitale Anleitung – Publizieren In HTML](https://gft-akademie.de/wp-content/uploads/2022/05/Die-digitale-Anleitung-Publizieren-in-HTML.jpg)
In meiner letzten Folge DD#005 habe ich einige Betrachtungen zu der Frage angestellt, ob ein Informationsprodukt als PDF oder E-Book publiziert werden sollte. Die heutige Ausgabe erweitert diese Betrachtungen um das HTML-Format.
Haben Betriebsanleitungen & Co. in Form eines PDF-Dokumentes mittlerweile eine breite Akzeptanz bei Produktherstellern und technischen Redakteuren gefunden, scheint dies bei Webdokumenten noch nicht der Fall zu sein.
Das ist in gewisser Weise sogar nachvollziehbar, denn die Erstellung von HTML-Dokumenten erfordert mitunter doch eine etwas andere Herangehensweise als man es von Printdokumenten her kennt. Dennoch ist eine generelle Angst vor diesem Thema unnötig, wie ich im Laufe des Podcast verdeutlichen werde.
Zuerst noch ein kleiner Terminologiehinweis: In diesem Podcast verwende ich das Kürzel HTML als Überbegriff für alle webbasierten Dokumente. HTML steht im Englischen für Hypertext Markup Langage. Hierbei haben wir es also mit einer textbasierten Auszeichnungssprache zu tun, welche zur Strukturierung elektronischer Dokumente verwendet wird. Auch wenn viele Menschen sie nicht in ihrer Ursprungsform wahrnehmen, begegnet sie ihnen ständig – überwiegend in Form von Webseiten, die im Internetbrowser des PCs oder Smartphones dargestellt werden.
Welche Kenntnisse braucht der technische Redakteur?
Die erste Frage, die sich nun möglicherweise stellt, lautet: Welche zusätzlichen Kenntnisse müssen technische Redakteure haben, um ein Informationsprodukt in HTML erstellen zu können?
Nun, obwohl mit einem gut konfigurierten Component Content Management System – kurz CCMS – wie Bloxedia sauber strukturierte Dokumente generiert werden können, sollten zumindest Grundkenntnisse in HTML und CSS vorhanden sein. Wer hingegen WebApps schreiben möchte, kommt um Javascript nicht herum, darüber hinaus sind PHP sowie SQL-Kenntnisse durchaus von Nutzen.
Und damit sind wir auch schon bei dem Hauptargument, was gerne gegen ein HTML-basierte Lösung ins Feld geführt wird: Wir brauchen einen Spezialisten, einen Web-Designer und Programmierer! Und der kostet viel Geld!
Das kann man durchaus so oder so betrachten. Entscheidend ist schlussendlich, wie soll das fertige Produkt aussehen, was soll es leisten und wem soll es wie nutzen?
Fallbeispiele
Betrachten wir hierzu einige Punkte:
Beim Webauftritt eines Shops, eines Dienstleisters oder eines Vereins, kommt es neben der inhaltlichen informativen Qualität u. a. auch auf die Form der Darstellung an und es wird versucht, die Besucher der Website zu informieren, zu unterhalten, zu animieren – kurz: auf der Website zu halten und ein echtes Nutzererlebnis zu bieten.
Zwar möchten wir in der technischen Dokumentation ebenfalls erreichen, dass die Konsumenten unsere Informationsprodukte gerne lesen und anschauen – aber zwei der Prinzipien zur Erfüllung der Norm 82079-1 lauten: Minimalismus und Prägnanz. Auf weitschweifende Erklärungen und Füllwörter im Text ist damit somit ebenso zu verzichten wie auf unnötige Einzelheiten in Grafiken und Videos.
Somit entfällt hier weitestgehend ein künstlerischer Aspekt, denn unsere Betriebs- oder Serviceanleitung soll den Nutzern ausschließlich ein Maximum an korrekter und umfassender Information zum sicheren Gebrauch seines Produktes liefern. Und Abbildungen, Prozessanimationen, Video- und Tondokumente erstellen wir bei Bedarf ja auch für PDF-Dokumente auf anderen Wegen – also völlig unabhängig von HTML.
Etwas technischer ausgedrückt: Mit HTML legen wir nur die Struktur unseres Informationsproduktes fest. Im besten Fall erfolgt dieses bereits mit dem Export aus einem Redaktionssystem heraus. Die eigentliche Auszeichnung, die Gestaltung von Überschriften, Absätzen, Farben, etc. realisieren wir mit CSS – den Cascading Stylesheets. Auch dies wird – die entsprechende Leistungsfähigkeit und Konfiguration des Redaktionssystems vorausgesetzt – im optimalen Fall bereits automatisiert erfolgen. Hier werden technische Redakteure also nur sehr wenig oder möglicherweise überhaupt nicht mit HTML in Kontakt kommen.
Wo auf ein solch potentes CCMS nicht zurückgegriffen werden kann, ist jedoch Handarbeit angesagt. Hier sind wir in der Tat gefordert, uns mindestens mit HTML und CSS auseinanderzusetzen.
Aber das klingt zunächst schlimmer, als es ist. Mit ein wenig Ein- und Vorarbeit, lassen sich beispielsweise wiederverwendbare Komponenten erstellen. So habe ich mir für Warnhinweise eigene CSS-Klassen zur Formatierung von HTML-Tabellen geschrieben, die mir quasi auf Knopfdruck einen korrekt nach SAFE strukturierten und ausgezeichneten Warnhinweis erzeugen.
Worin liegt der Nutzen von HTML?
Welchen Nutzen hat ein HTML-Dokument nun im Vergleich zu einem PDF-Dokument? Aus meiner Sicht sind die wesentlichen Punkte die zentrale Aktualisierbarkeit und Verteilbarkeit sowie die Flexibilität.
Betrachten wir das an kleinen Beispielen:
Ein Unternehmen produziert eine Maschine für den Weltmarkt. Ihre Wartung und Reparatur erfordert speziell ausgebildetes Personal, das der Hersteller selbst zur Verfügung stellt. Wir haben also Servicetechniker im weltweiten Einsatz. Diese benötigen Zugriff auf die entsprechenden technischen Unterlagen, die selbstredend immer auf dem aktuellsten Stand sein müssen.
Oder: Ein Unternehmen hat sich auf den deutschlandweiten Service für Großkopierer und Drucksysteme spezialisiert. Hierbei bedient es die umfangreichen Produktreihen verschiedener Hersteller. Der räumlich breit gestreute Kundenkreis des Unternehmens erfordert es, dass die Servicetechniker ganz- oder mitunter sogar mehrtägig unterwegs sind, um ihre Kunden nacheinander aufzusuchen – ohne Zwischenstopp im Unternehmen selbst.
Wie gestaltet sich nun die Ausstattung der Servicetechniker mit technischen Dokumenten?
Die Aktualisierbarkeit und Verteilbarkeit
Üblicherweise wird man heute die Tablet-PCs oder Notebooks der Techniker mit einer umfangreichen Bibliothek von Dokumenten in PDF-Form ausstatten. Der Kofferraum voller gedruckter Handbücher gehört damit der Vergangenheit an. Allerdings stellt dieses Verfahren jedoch auch Anforderungen an die Logistik: So ist sicherzustellen, dass alle Mitarbeiter stets auf die aktuellsten Dokumente zugreifen können. Zudem müssen die eingesetzten Endgeräte die gleiche Reader-Software besitzen. Bei einem großen Mitarbeiterstamm kann dies schon eine echte Herausforderung für den IT-Verantwortlichen des Unternehmens darstellen.
Gerne tritt auch ab und zu der Fall ein, dass der Techniker auf seiner Tour unvorhergesehen zu einem Neukunden gerufen wird, der umgehende Hilfe benötigt.
Murphys Law folgend, sind die erforderlichen Unterlagen für das zu reparierende Gerät selbstverständlich nicht auf dem Tablett-PC oder Notebook gespeichert.
Hier hilft eine zentrale Verteilung ausgehend vom Webserver des Unternehmens, diese Klippen zu umschiffen. Rund um die Uhr und von jedem Ort aus können die benötigten Informationen abgerufen werden. Soweit die Betrachtungen zur Verteilbarkeit.
Nun, das alleine ist vermutlich noch nicht das schlagende Argument für HTML, denn auch PDF-Dokumente können ja bei Bedarf im Download bezogen werden.
Schauen wir uns daher noch kurz das Argument der Aktualisierbarkeit an: Informationsprodukte sind nicht zwingend statisch. Gründe für eine mögliche Änderung können vielfältig sein und reichen von der Korrektur unwesentlicher grammatikalischer Fehler bis hin zu schwerwiegenden Instruktionsfehlern oder weiteren sicherheitsrelevanten Punkten.
Diese Korrekturen sind zwar möglicherweise schnell eingepflegt, aber wie erreichen die aktualisierten Dokumente die Techniker? Der bereits erwähnte Download des korrigierten PDFs ist eine Option. Allerdings müssten im Vorfeld erst einmal alle Techniker von der Änderung in Kenntnis gesetzt werden.
Ein aktualisiertes HTML-Dokument steht nach dem Upload auf den Server sofort allen Mitarbeitern zur Verfügung. Fehler beim Dateiaustausch können nicht vorkommen.
Schauen wir nun auf die Flexibilität:
Die Flexibilität
Ein Servicetechniker wird zu einem Gerät gerufen, das in unterschiedlichen Variationen hinsichtlich des Leistungsumfanges und der Technik produziert wird. Nun kann der Hersteller für jede Variante eine eigene komplette Serviceanleitung erstellen. Da diverse Komponenten aber in allen Gerätevarianten gleich sind, müsste auch auf diese in jeder einzelnen Anleitung detailliert eingegangen werden und in einer PDF-Ausgabe enthalten sein.
Die flexible Lösung bietet HTML: Jedes Gerät bekommt einen seiner Variante entsprechenden QR-Code als Aufkleber. Einmal mit dem Tablet abgefragt, wird eine Datenanforderung an den Unternehmensserver geschickt, der datenbankgestützt ein ausschließlich auf diese Gerätevariante angepasstes Informationsprodukt zur Verfügung stellt – quasi Online-Single-Source-Publishing in Echtzeit.
Während der Reparatur stellt unser Techniker nun fest, dass einige Komponenten defekt sind und ausgetauscht werden müssen. Für einen solchen Fall enthält sein virtuelles HTML-Servicehandbuch eine Teileliste, in der er die entsprechenden Positionen markiert und diese online direkt zurück an sein Unternehmen sendet. Idealerweise sieht er bereits hierbei, ob die benötigten Teile am Lager sind oder erst beschafft werden müssen. Und wenn es ganz besonders gut läuft, ist nur kurze Zeit später ein Kurier mit den angeforderten Komponenten auf dem Weg zu ihm.
Aber auch der GAU für jeden Techniker – der Verlust oder Defekt seines Endgerätes – verliert seinen Schrecken. Mit seinem Benutzerkonto kann er im Notfall auch vom PC des Kunden auf alle benötigten Informationen zugreifen, ein Download von PDF-Dokumenten und damit die Gefahr eines möglicherweise unbeabsichtigten Verbleibs unternehmensinterner Daten auf dem Kunden-PC entfällt.
Zukunftsmusik? Keineswegs! In vielen Branchen kann eine Stunde Stillstandzeit einer Maschine, oder eines Servers eine erhebliche Summe Geld kosten – schnelle und effiziente Lösungen sind daher sehr willkommen. Es darf allerdings nicht unerwähnt bleiben, dass derartig spezifische Konzepte alleine mit HTML- und CSS-Kenntnissen nicht zu realisieren sind. Hier ist zusätzlich mindestens fundiertes Wissen in Javascript, PHP und SQL erforderlich.
Klassische Website oder doch eine Webapp?
An dieser Stelle vorab einige weitere Terminogie-Hinweise: Als Website bezeichnet man den gesamten Webauftritt – also die Sammlung aller unter einer Domain wie beispielsweise www.gft-Akademie.de abrufbarer Informationen. Die Webseite stellt dabei eine einzelne Seite innerhalb dieses Webauftrittes dar – beispielsweise das Impressum. Die Homepage schließlich, ist das erste Dokument der Website – also die Startseite.
Wir haben uns nun entschieden, Informationsprodukte webbasiert zu publizieren. Welche Form eignet sich dazu?
Da wäre zunächst die klassische – und am einfachsten zu realisierende Lösung – die Website. Unser Informationsprodukt liegt hierbei beispielsweise in Form einer Anzahl einzelner HTML-Dokumente vor. Diese sind praktischerweise der Makrostruktur des Informationsproduktes folgend angelegt. Also eine Datei Sicherheitskapitel, eine Datei Wartungskapitel, und so fort. Miteinander verknüpft werden diese einzelnen Komponenten durch ein entsprechend gestaltetes Navigationssystem.
Haben wir ein sogenanntes responsives Layout bei der Gestaltung gewählt, wird unser Informationsprodukt sich optimal jedem Endgerät anpassen und, egal ob auf dem PC oder dem Smartphone, stets leserlich und lesbar sein.
Für diese Ausführung reichen bereits Kenntnisse in HTML- und CSS.
Mehr Potenzial können wir mit einer sogenannten WebApp erreichen: Diese ist unter der Haube prinzipiell zwar noch immer eine Website, das Look and Feel ähnelt jedoch einem Programm bzw. einer echten (nativen) App. Anders ausgedrückt: Wir haben es nach wie vor mit einer klassischen Website zu tun, die sich mittels entsprechender Gestaltung der Bedienelemente wie Buttons oder Dialogfelder optisch und bedientechnisch jedoch wie eine Software darstellt.
Das alleine ist nun noch kein echter Mehrwert. Wesentliches Merkmal für Webapps ist die Möglichkeit, auf bestimmte Hardwarefunktionen des Endgerätes zugreifen zu können – beispielsweise auf die Kamera des Smartphones oder Tablets. Diese Funktion wäre die Basis, um den vorhin erwähnten QR-Code an einem Gerät oder einer Maschine auslesen zu können.
Ein weiterer Vorteil der Webapp liegt darin, dass sie nicht auf dem Endgerät installiert werden muss – sie ist also eine plattformunabhängige Lösung mit breitem Leistungspotenzial. Jedoch hat die Sache einen Haken: Zu ihrer Erstellung sind mindestens fundierte Kenntnisse in Javascript und JavaScript-Bibliotheken wie jQuery zwingende Voraussetzung.
Und wie überall macht die Entwicklung auch in diesem Segment nicht halt. So finden seit geraumer Zeit die sogenannten progressiven WebApps zunehmende Einsatzgebiete. Ihre Stärken liegen u. a. in der Offline-Verfügbarkeit von Inhalten. Hier können einmal abgerufene Inhalte künftig auch ohne Internetverbindung angezeigt werden. Ein Plus, dass eine klassische Webapp nicht bietet.
Schlussendlich gibt es noch die echte App (auch native App) – also eine plattformabhängige Anwendung. Da sie jedoch einer Bindung an ein Betriebssystem oder eine Hardware unterliegt und auf dem Endgerät installiert werden muss wird sie wohl nur in ganz speziellen Fällen für ein Informationsprodukt von Bedeutung sein. Ein Beispiel hierzu wäre eine in das Produkt vom Benutzer selbst vollständig integrierbare Benutzeranleitung.
Nutzen im B2C-Markt?
Waren meine Beispiele bisher vorwiegend auf den B2B-Bereich bezogen, möchte ich noch einige Worte zum B2C-Segment verlieren:
Kann auch ein Endanwender, ein Verbraucher von den genannten Lösungen und ihren Vorteilen profitieren? Ich bin der Meinung – grundsätzlich ja. Allerdings sollte hier immer die Art des Informationsproduktes betrachtet werden. Ist es wirklich sinnvoll, eine HTML-Version der Bedienungsanleitung einer Stereoanlage zu generieren? Anders sieht es bei dem Handbuch zu einem PKW aus: Hier lassen sich Funktionen mit einem echten Mehrwert für den Fahrzeugbesitzer integrieren. Beispielsweise können die bereits erwähnten QR-Codes im Falle eines Defektes hilfreiche Informationen liefern, oder es lässt sich mit einer entsprechenden Schnittstelle das Diagnosesystem des Fahrzeugs auslesen und die Daten vorab an die heimische Vertragswerkstatt übertragen.
Fazit
Halten wir also fest: Bereits nur mit HTML und CSS ist es möglich, ausgezeichnete Informationsprodukte erstellen. Das gilt sowohl für die interne wie die externe Dokumentation, denn auch der unternehmenseigene Redaktionsleitfaden oder die Werksnorm lassen sich so sehr einfach im Unternehmen verteilen. Schließlich gelten hier ebenfalls die schon genannten Vorzüge Aktualisierbarkeit und Verteilbarkeit sowie Flexibilität.
Wird mehr Leistungsfähigkeit des Informationsproduktes gefordert, sind jedoch Fachleute zu seiner Erstellung Voraussetzung. Und multimediale Inhalte wie Animationen, Video- oder Tondokumente lassen sich heute einfacher denn je in HTML-Dokumente integrieren.