MS Word, oder wie aus einem abgehalfterten Gaul ein Rennpferd wird

Word für die Technische Dokumentation? Man könnte ja meinen, im Zuge der Einführung von XML-basierten Redaktionssystemen (und weil auf Konferenzen wie der tekom-Tagung fast nur darüber geredet wird) stirbt die massenhafte Nutzung von Word in der Technischen Dokumentation aus.

Aufhorchen ließ mich die Adobe-Umfrage 2020, die nach Adobe-eigener Darstellung die weltweit größte Umfrage zur Technischen Dokumentation ist. (Hier gehts zum ausführlichen Blog-Artikel zur Umfrage).

Demnach erzeugen ca. 90 % der Anwender Dokumente mit klassischen DTP-Werkzeugen, darunter 37 % mit HTML-Editoren.

Noch deutlicher war das Ergebnis bei einer weiteren Umfrage (General Tech Comm Industry Survey 2018):

Ist man hier in Deutschland etwa schon viel „weiter“, viel „strukturierter“, viel XML-affiner? In der Tat kann man das bei größeren Firmen (mehr als 1000 Mitarbeiter) durchaus vermuten, befassen sich doch die meisten inzwischen mit XML-Redaktionssystemen für die Nutzerinformationen oder wandern in Richtung HTML-Systeme (z. B. MadCap Flare, Confluence) ab. Bei anderen mit starkem Einfluss der Marketingabteilung taucht immer öfter InDesign als Redaktionswerkzeug auf – leider in den meisten Fällen, besonders im Vergleich zu Word, eine Fehlentscheidung. Doch wenn man einen Blick „hinter die Kulissen“ wirft und auch die interne Dokumentation betrachtet, etwa Lasten- und Pflichtenhefte und Projektdokumentationen, aber durchaus auch Benutzerinformationen, dann wird deutlich, dass „gegen Word kein Kraut gewachsen“ ist.

Warum auch: Word ist, nach wie vor, das am meisten eingesetzte Software-Werkzeug überhaupt, aber leider auch das am meisten missverstandene. Und oft wird leider vergessen: Word ist der komplexeste Editor (quasi ein eigenes Redaktionssystem) am Markt und viele gutgemeinte Tipps behindern leider gerade den effizienten Word-Einsatz.

Woher das kommt: Microsoft hat Word zu dem gemacht, was es ist, weil Millionen Anwender entsprechende Wünsche geäußert haben. Aber nicht als Gesamtsystem, denn jede einzelne Funktion hat zig User-Geschichten als Grund für die Implementierung. Microsoft hat gerade das beherzigt, was man dem Begründer des industriell gefertigten Autos, Henry Ford, als Ablehnung in den Mund gelegt hat: »Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: ›schnellere Pferde‹.«

Word ist inzwischen zum „Universalpferd“ für nahezu jede denkbare Dokumentenerstellung geworden, seien es Marketingdokumente, lange strukturierte Dokumente oder Einwegbriefe oder, als besonderer Schwerpunkt, Einladungskarten zu irgendwelchen Feiern. Leider glauben viele in den Unternehmen, dass Word ja jeder beherrschen würde (behauptet nahezu jeder Lebenslauf) und man daher keine aufwändigen Prozessimplementierungen, passende Dokumentvorlagen und, das ist leider total unterschätzt, keine Benutzeroberflächenanpassung benötigen würde.

Diese Fehleinschätzung wird von vielen Informationsexperten indirekt bestätigt: Word ist demnach jenseits vom Briefeschreiben untauglich und man bräuchte halt ein „vernünftiges“ XML-Redaktionssystem, das eine unstrukturierte kreativ-chaotische Dokumentenerstellung einfach verhindert. Doch diese Aussage ist so platt formuliert schlicht falsch. Man gebe den Word-Implementierern nur einen vergleichsweise geringen Bruchteil der Redaktionssystems-Budgets und mit entsprechendem Know-how wird aus dem vermeintlich abgehalfterten Gaul ein Rennpferd für die Technische Dokumentation.

Word hat aber leider auch gravierende implementierte Denkfehler bei der Umsetzung bestimmter Use Cases (etwa die Pseudo-Buchfunktion, Zentral-Filial-Dokument) und auch Bugs, aber vergleichbare Denkfehler und Bugs kenne ich auch nahezu bei jedem Redaktionssystem: Diese Denkfehler und Bugs müssen dann die Systemimplementierer für viel Geld umschiffen. Während aber bei Word eine Prozess- und Template-Implementierung für, sagen wir, 10.000 EUR eher als „Frechheit“ verunglimpft wird, sind solche Projektbudgets für Redaktionssysteme eher „Peanuts“. Dabei bedeutet die Umsetzung von bestimmten Prozessen in einem System, ob Word oder Redaktionssystem, durchaus einen vergleichbaren Aufwand, oder besser: bei Word sind Anpassungen natürlich viel einfacher und flexibler umsetzbar.

Damit wir uns nicht missverstehen: Redaktionssysteme von docuglobe (Word-basiert) bis Schema oder Smart Media Creator (XML-basiert) bieten weit mehr Möglichkeiten als Word allein. Und in Teams von mehr als zwei Personen mit mehr als zwei Sprachen und der Anforderung, neben PDF auch HTML5 ausgeben zu können, ist auch unsere Empfehlung meistens, lieber ein Reaktionssystem zu verwenden. Aber die Behauptung, Word sei prinzipiell ungeeignet für die Technische Dokumentation, ist falsch! Und in unserem Word-Workshop weisen wir auch auf mögliche sinnvolle Fertiglösungen rund um Word hin, wie z. B. texManager, DocuPro, Microsoft Forms oder docuglobe.

itl bietet seinen Kunden mehrere Möglichkeiten, um den gravierenden Missverständnissen und Fehlanwendungen von Word zu begegnen: zum einen mit dem itl Word-Workshop (Online oder bei der itl AG oder als firmeninterner Workshop) oder den Online-Seminaren der itl GmbH (Österreich) und zum anderen mit dem itl DocuGuide-Template.

Der genannte Word-Workshop setzt gute Grundkenntnisse in Word voraus und beseitigt alle Missverständnisse und Fehlanwendungen für die Technische Dokumentation. Sie werden erstaunt sein, welche Tipps und Tricks Sie noch nicht kannten, um ein gestriegeltes Word-Rennpferd zu erhalten.

Die Themen:

  • Word-Versionen und Word-Formate: Fallstricke und wie man sie verhindert
  • Grundeinstellungsoptionen: Wenn Microsoft „Auto…“ sagt, sollten Sie die Option fast immer deaktivieren
  • Formatvorlagen (Zeichen, Absätze, Listen, Tabellen) und warum die Verwendung der Formatvorlage „Standard“ verboten ist
  • Bilder, Grafiken und Grafikintegration: Welche Verankerung stabil ist, was der Zeichenbereich ist und warum PowerPoint der beste Editor am Markt für Schemagrafiken ist
  • Tabellen, Tabellenformatvorlagen, Tabellenfunktionen: tolle Funktionen im (zu) komplexen Gewand und was dennoch fehlt
  • Seitenlayout: das Geheimnis der Abschnittsumbrüche, warum Sie immer bis 3 zählen und rückwärts denken müssen
  • Verzeichnisse, das Geheimnis des TOC-Feldes und warum das Content-Control eher stört
  • Modularisierung: von manuellen Lösungen basierend auf Variablen, Hyperlinks und Querverweisen über Autotexte, {textInclude}- und {RD}- Feldern hin zu professionellen Fertiglösungen
  • Word out of the box: optimiert für Grußkarten-Design. Word für die Technische Dokumentation: ohne Anpassung der Benutzeroberfläche ineffizient. Wie einfach Sie eine Anpassung ohne Programmierung erreichen
  • Makros für Nicht-Programmierer: die besten Fundstellen für Anwender und einfache Verwendung des Makrorekorders

Die DOTM-Dokumentvorlage itl DocuGuide für Word ist ein Beispiel dafür, welche Word-Dokumentvorlagen wir für unsere Kunden entwickeln. itl DocuGuide versteht sich als weitgehend fertige out of the box-nutzbare Dokumentvorlage. Das integrierte Menüband des itl DocuGuides bietet den Zugriff auf alle benötigten Funktionen.

 

Hier geht es zu weiteren Blogartikeln von Dieter Gust

Noch Fragen? Kontaktieren Sie Andrea Wagner

Abteilungsleitung Technische Dokumentation  

Kommentar schreiben

Kommentar schreiben

* Diese Felder sind erforderlich

Kommentare

Kommentare

Hallo Mark: Viele FrameMaker-Profis, die FrameMaker gut kennen, sehen Word ähnlich wie Sie.
Ursache ist, mit Blick auf Word, die falsche Vorstellung, wie die Word-Funktionen technisch aufgebaut sind: Viele Word-Funktionen sind anders gestaltet als die vergleichbaren FrameMaker-Funktionen.

Leider ist Ihr Urteil über Word so emotional zwar nachvollziehbar aber faktisch einfach falsch: Word verhält sich wie FrameMaker vorhersehbar und kontrollierbar, wenn Sie die Word-Funktionen genau kennen würden.
Was aber stimmt, ist, dass Microsoft durch eine zum Teil falsch gedachte Usability-Funktionalität, das Nachvollziehen der Word-Funktionalität unnötigerweise erschwert.

Beispiel: Listen sind in Word eigenständige Objekte, die von Absatzformatvorlagen zunächst völlig unabhängig sind. Listen enthalten aber auch Absatzeigenschaften wie Einzüge. Die Word-Benutzeroberfläche verleitet ohne Kenntnis der Hintergründe zur falschen Anwendung von Listen.

FrameMaker-Anwender können die Listenlogik von Word zunächst gar nicht verstehen und müssen ihr mentales Modell, wie Listen funktionieren, ändern. Die konkrete Zuordnung zwischen Listen und Absätzen ist ein komplexer Sachverhalt, der mit Listenformatvorlagen klar kontrollierbar wird. Wenn das mentale Modell einer Listenfunktion im Kopf einmal auf Word hin angepasst ist, wird Word so einfach bedienbar wie FrameMaker.

Vielen Dank für ihre Sichtweise. Ich stimme ihnen zu, wenn sie sagen, dass Würg sehr viel komplexer ist, als es manche Anwender vermuten und dass ein (technischer) Redakteur einen tiefen Einblick in die Funktionsweise von Würg benötigt. Es gibt aber noch die andere Seite - und für die ist Würg selbst verantwortlich.

Sie mögen sich vielleicht wundern, weshalb ich oben beständig Würg statt Word schreibe - es bezeichnet einfach den physiologischen Reflex, der sich bei meiner täglichen Arbeit mit diesem dauerpubertären MS-Maschwerk einstellt. Dauerpubertär deshalb, weil es sich wie ein Mensch in diesem Entwicklungsstadium verhält. Ich gebe eine Anweisung und Würg macht einfach etwas anderes. Das geht nicht nur mir so. Ein spezieller Fall sind beispielsweise die Formatvorlagen, für TRs ein wesentliches Kriterium bei der Gestaltung von Dokumenten. Trotz aller Format-Basiseinstellungen für das Kopieren von Text zwischen Dokumenten (weil hier eben noch Altlasten zu beheben sind), ist die korrekte Anwendung der Fomateeinstellungen auf den jeweiligen Text Würg vollkommen egal. Es macht einfach, was ihm selbst gerade einfällt, manchmal richtig, oft aber falsch. Beim Kopieren mehrerer Absätze in einem Rutsch werden dann die einen Textpassagen richtig formatiert, die anderen nicht und ich ich muss alles manuell noch einmal kontrollieren, weil ich mich nicht darauf verlassen kann, dass Würg die Anweisung vollständig korrekt ausführt. Und das ist nur ein Beispiel von vielen, die mir in meiner täglichen Arbeit begegnen.

Dieses Verhalten ist nicht nur pubertär oder ADS-geprägt, sondern zeigt schon starke psychopathologische Züge.

Ich habe früher mit FrameMaker gearbeitet, der hatte auch seine Macken, aber im Vergleich zu Würg nahezu harmlos!

Wie war Witz mit der Fehleruhr, deren Sekundenzeiger sich bei jedem Fehler eines Microsoft-Produkts weiterbewegt? Die hängt in der Hölle und wird dort als Ventilator zur Kühlung verwendet! Wie wahr!

Aus diesem Grund ist Würg kein Tool für eine sinnvolle, reibungslose und vor allen produktive (was MS beständig für seine Produkte proklamiert) Dokumentationsarbeit! Nicht zu gebrauchen