Grundlagen der technischen Dokumentation

Grundlagen der technischen Dokumentation

Motivationen, Methoden und Zusammenhänge

von Marcel Saft, Dipl.-Technikredakteur (FH)

www.technische-dokumentation.org 2

Autor Marcel Saft

freiberuflicher Dipl.-Technikredakteur (FH) 99089 Erfurt

www.technische-dokumentation.org [email protected]

Version Version 01 (April 2020)

Dieses E-Book wird in unregelmäßigen Abständen ergänzt und aktualisiert. Auf der Website www.technische-dokumentation.org ist stets die aktuelle Version dieses

E-Books verfügbar. Weitere Informationen siehe Versionshistorie, Seite 125.

Verwendung Dieses E-Book ist kostenfrei erhältlich unter www.technische-dokumentation.org. Es darf zu nicht-kommerziellen Zwecken frei verwendet und verbreitet werden. Bei Interesse an einer

kommerziellen Verwendung kontaktieren Sie bitte den Autor.

Gastbeiträge In dieses E-Book können Gastbeiträge aufgenommen werden, selbstverständlich unter

Ihrem Namen. Kontaktieren Sie bei Interesse bitte den Autor.

Anzeigen Unternehmen können ihre doku-relevanten Dienstleistungen und Produkte in diesem E-Book

vorstellen. Nähere Informationen siehe Seite 126.

http://www.technische-dokumentation.org/


Inhaltsverzeichnis


Inhaltsverzeichnis 1 Einleitung 7

2 Einführung in die technische Dokumentation 8

2.1 Was ist technische Dokumentation? 8

2.2 Technische Dokumentation im Produktlebenszyklus 9

2.3 Wozu professionelle technische Dokumentation? 10

2.4 Gesetzliche Grundlagen der technischen Dokumentation 12

2.4.1 Produktsicherheitsgesetz 12

2.4.2 Produkthaftungsgesetz 14

2.4.3 Bürgerliches Gesetzbuch 15

2.4.4 Fallbeispiel „Milupa“ 15

2.5 Für wen technische Dokumentation? 16

2.5.1 Zielgruppenanalyse 16

2.5.2 Was-macht-wer-Matrix 18

2.5.3 Persona-Methode 19

2.6 Allgemeine Anforderungen an technische Dokumentation aus Sicht der Nutzer 20

2.6.1 Leicht verständlich 20

2.6.2 Gut leserlich 25

2.6.3 Reibungsloser Zugang möglich 26

2.6.4 Zielgruppengerechter Inhalt und Umfang 27

2.6.5 Korrekter Inhalt 27

2.6.6 Sichere Anleitungen 28

2.7 Allgemeine Anforderungen an technische Dokumentation aus Sicht der Hersteller 28

2.8 Vorgehensmodelle und Projektplan 28

2.8.1 Vorgehensmodell ALASKA 29

2.8.2 Vorgehensmodell nach DIN EN 82079-1 30

2.9 Inhalt von technischer Dokumentation 30

2.9.1 Allgemeine Vorgaben durch Normen und Gesetze 30

2.9.2 Fallbeispiel Kreissäge 32

2.9.3 Konstruktion vor Instruktion 36

2.10 Lernkontrolle 36

3 Wozu standardisieren? 37

3.1 Das „Schema F“ 37

3.2 Standardisieren dem Leser zuliebe 37

Inhaltsverzeichnis


3.3 Standardisieren der Effizienz zuliebe 38

3.3.1 Die Bedeutung von Software-Algorithmen 38

3.3.2 Das Funktionsprinzip eines TMS 39

3.3.3 Rechenbeispiel für die Einsparung durch ein TMS 42


4 Methoden und Hilfsmittel zum Standardisieren von technischer Dokumentation 44

4.1 Standardisieren der Inhaltsstruktur 44

4.1.1 XML-basierte Inhaltsstrukturen 44

4.1.2 Standardisierungsmethoden 46

4.1.3 Normen und Richtlinien 46

4.1.4 Strukturebenen 47

4.2 Standardisieren der Sprache 48

4.2.1 Terminologiemanagement 48

4.2.2 Kontrollierte Sprache 49

4.2.3 Sprachkontrollsystem 53

4.3 Standardisieren der Gestaltung 54

4.3.1 Trennung von Inhalt und Layout 54

4.3.2 Formatvorlagen in MS Word, FrameMaker & Co. 55

4.3.3 Stylesheets 57

4.3.4 Cross-Media-Publishing 59

4.3.5 Normen 59

4.4 Standardisieren von Abbildungen 59

4.4.1 Technische Eigenschaften von Abbildungen 59

4.4.2 Positionsnummern und Positionslinien 60

4.5 Standardisieren der Prozesse 63

4.5.1 Vorgehensmodelle 63

4.5.2 Redaktionssysteme 63

4.5.3 Makros für Bildbearbeitung 65

4.5.4 Profile für PDF-Erzeugung 65

4.5.5 Dokumentvorlagen 66

4.5.6 Formulare 66

4.6 Redaktionsleitfaden 67

4.6.1 Definition und Nutzen eines Redaktionsleitfadens 67

4.6.2 Inhalt eines Redaktionsleitfadens 68

4.6.3 Anwendung eines Redaktionsleitfadens 69

Inhaltsverzeichnis



5 Strukturierungsprinzipien 71

5.1 Strukturierung nach Handlungszielen 71

5.2 Strukturierung nach Produktbestandteilen 71

5.3 Strukturierung nach Zielgruppen 73

5.4 Strukturierung nach Nutzungssituation 73

5.5 Card-Sorting als Hilfsmittel zur Strukturierung 74


6 Standardisierungsmethode Funktionsdesign 76

6.1 Was ist Funktionsdesign? 76

6.1.1 Definition 76

6.1.2 Die vier Prinzipien 76

6.2 Wie wird ein Funktionsdesign aufgebaut? 80

6.2.1 Die vier Ebenen des Funktionsdesigns 80

6.2.2 Ablauf einer Funktionsdesign-Planung 86

6.3 Technische Umsetzung von Funktionsdesign 88

6.3.1 Formatvorlagen oder XML? 88

6.3.2 Formatvorlagen und die Trennung von Inhalt und Layout 89

6.3.3 Die Funktionsdesign-Ebenen in MS Word umsetzen 91

6.4 Allgemeine Tipps 96


6.6 Funktionsdesign-Muster 98

6.6.1 Musteranleitung nach Funktionsdesign® erstellen 98

6.6.2 Funktionale Planung 104

6.6.3 Sequenzmuster 105

7 Weitere Standardisierungsmethoden und Informationsmodelle 107

7.1 Standardisierungsmethoden 107

7.1.1 Klassenkonzept-Technik® 107

7.1.2 Information Mapping® 108

7.1.3 Zielprogrammierung 109

7.2 Informationsmodelle 110

7.2.1 DITA 110

7.2.2 PI-Mod 112


8 Single-Source-Publishing 114

8.1 Was sind Single-Source-Publishing und Modularisierung? 114

Inhaltsverzeichnis


8.2 Vorteile von Modularisierung 115


9 Verzeichnisse und Sonstiges 117

9.1 Abbildungsverzeichnis 117

9.2 Tabellenverzeichnis 119

9.3 Quellenverzeichnis 119

9.4 Stichwortverzeichnis 123

9.5 Über den Autor 124

9.6 Über dieses E-Book 125

9.7 Danksagungen 125

9.8 Versionshistorie 125

10 Dienstleistungen und Produkte 126

11 Musterlösungen der Lernkontrollen 127

11.1 Kapitel 2.10 127

11.2 Kapitel 3.4 128

11.3 Kapitel 4.7 128

11.4 Kapitel 5.6 129

11.5 Kapitel 6.5 129

11.6 Kapitel 7.3 130

11.7 Kapitel 8.3 131

Einleitung


1 Einleitung Sie erhalten in diesem Buch einen kompakten, leicht nachvollziehbaren Einstieg in das Fachgebiet der technischen Dokumentation.

In den Kapiteln 2 bis 5 werden die allgemeinen Grundlagen der technischen Dokumentation beleuchtet:

• Weshalb ist technische Dokumentation wichtig?

• Welche Anforderungen sollten Gebrauchsanleitungen und ähnliche Dokumente erfüllen?

• Welche Rolle spielt Standardisierung?

Antworten auf diese und ähnliche Fragen kennen Sie nach der Lektüre dieser Kapitel. Dabei gehen diese Kapitel jedoch nicht in die Tiefe. Der Zweck dieser Einführungskapitel ist vielmehr, Ihnen einen Gesamtüberblick zu geben, damit Sie alle folgenden Inhalte besser in ein großes Ganzes einordnen können.

In Kapitel 6 lernen Sie die Standardisierungsmethode Funktionsdesign® kennen – und wie man sie praktisch umsetzen kann.

Einige alternative Standardisierungsmethoden sowie Informationsmodelle werden in Kapitel 7 vorgestellt. Kapitel 8 schließlich führt Sie in das Single-Source-Publishing ein, in die Welt der Module und der Wiederverwendung.

Am Ende jedes Hauptkapitels stehen einige Fragen. Sie können die Fragen schriftlich für sich selbst beantworten und damit überprüfen, ob Sie das jeweilige Thema verstanden haben. Alle Antworten lassen sich aus dem entsprechenden Hauptkapitel ableiten. Musterantworten finden Sie in Kapitel 11.

Eine Bitte habe ich an Sie, liebe Leserin oder lieber Leser: Wenn an irgendeiner Stelle dieses Buches Fragen für Sie offen bleiben oder wenn Sie Anregungen haben … ich freue mich über Ihre E-Mail! Schreiben Sie an: [email protected].

mailto:[email protected]

Einführung in die technische Dokumentation


2 Einführung in die technische Dokumentation

In diesem Kapitel lernen Sie die Grundlagen der technischen Dokumentation kennen. Was ist technische Dokumentation eigentlich? Was macht gute technische Dokumentation aus? Wie erstellt man technische Dokumentation? Diese und weitere Fragen werden nachfolgend beantwortet.

2.1 Was ist technische Dokumentation? Es gibt Berufe, die relativ unbekannt sind und unter deren Berufsbezeichnung sich Außenstehende nicht sehr viel vorstellen können. Zu diesen Berufen gehört bisher auch der des Technische Redakteurs. Entsprechend bekommt man als Technischer Redakteur gelegentlich die Frage gestellt, was man in diesem Beruf eigentlich tut. Zeitschriftenartikel über technische Sachverhalte schreiben? Kann passieren, das Berufsfeld ist groß. Viele Technische Redakteure kürzen das Raten ab und bringen schnell „den Klassiker“ ins Spiel: Gebrauchsanleitungen. Nicht nur, aber vor allem Gebrauchsanleitungen und ähnliche Informationsprodukte schreibt man als Technischer Redakteur.

Etwas weiter gefasst erstellen Technische Redakteure technische Dokumentation. Aber was ist darunter zu verstehen? Die Norm VDI 4500 Blatt 1 bietet eine Orientierung:

„Technische Dokumentation beinhaltet alle Informationen, die von einem Hersteller/Vertreiber parallel zum Entstehen und zum Lebensweg eines Produktes (Produktlebenszyklus) erstellt werden.“

(VDI 4500 2006, 4)

Diese Definition bringt auf den Punkt, dass technische Dokumentation quasi alle Dokumente umfasst, die im Laufe eines Produktlebens beim Hersteller des Produkts entstehen: von den ersten Entwicklungsplänen, über interne Protokolle und Anweisungen, über die Gebrauchsanleitung bis zur Außerbetriebnahme- und Entsorgungsanleitung.

Die technische Dokumentation ist damit zwar sehr weit gefasst. Welche Informationsprodukte aber tatsächlich erstellt werden müssen

Definition nach VDI 4500

technische Dokumentation im Produktlebenszyklus



und ob der Technische Redakteur damit betraut ist, ist natürlich je nach Unternehmen sehr unterschiedlich.

Um etwas übersichtlicher darzustellen, was typischerweise unter technischer Dokumentation verstanden wird, bietet sich die Unterscheidung zwischen interner und externer technischer Dokumentation an: Interne technische Dokumentation „beinhaltet alle technischen Informationen über ein Produkt, die im Unternehmen verbleiben“ (VDI 4500 2006, 4). Risikobeurteilungen, Prüfprotokolle und dergleichen gehören also zur internen technischen Dokumentation. Externe technische Dokumentation „beinhaltet alle technischen Informationen über Produkte, die […] für […] Anwender und Verbraucher bestimmt sind“ (VDI 4500 2006, 6). Unter anderem die Gebrauchsanleitung ist somit Gegenstand der externen technischen Dokumentation.

Im weiteren Verlauf dieses E-Books ist mit „technische Dokumentation“ stets „externe technische Dokumentation“ gemeint, wie zum Beispiel Gebrauchsanleitungen.

2.2 Technische Dokumentation im Produktlebenszyklus

Abbildung 1 zeigt einen typischen Produktlebenszyklus nach ISO 9004:

Abbildung 1: Produktlebenszyklus nach ISO 9004 (ISO 9004-1 1994, zitiert nach tekom 2015a)

interne und externe technische Dokumentation



Während der einzelnen Phasen bzw. für die einzelnen Phasen des Produktlebenszyklus können zum Beispiel folgende Informationsprodukte entstehen: Phasenbezeichnung Informationsprodukte Produktbeobachtung Service-Bulletin (Dokumentation

einzelner Supportfälle) Produktspezifikation Informationskonzept Produktentwicklung Entwicklungsdokumentation,

Schaltpläne, Hydraulikpläne Verifizierung Freigabedokumente Verpackung und Lagerung Lagerungshinweise Verkauf Produktkataloge und -webseiten Verteilung Transportanleitung Montage Montageanleitung Inbetriebnahme Inbetriebnahmeanleitung Betrieb Gebrauchsanleitungen,

Betriebsanleitungen, Softwarehilfen, Support-Webseiten

Technische Unterstützung Ersatzteilkataloge Wartung Wartungsplan, Hilfsstofflisten Beseitigung (oder Wiederverwendung)

Deinstallationsanleitung

Marketing Vertriebsunterlage Tabelle 1: Informationsprodukte im Produktlebenszyklus (tekom 2015a)

2.3 Wozu professionelle technische Dokumentation? Kaum ein Unternehmen verkauft mehr Produkte, weil die zugehörige technische Dokumentation gut ist. Weshalb also sollten Unternehmen in professionelle technische Dokumentation investieren? Es gibt einige Argumente für Unternehmen, sich ernsthaft um ihre technische Dokumentation zu kümmern:

Für die meisten Unternehmen ist das wichtigste Argument eine möglichst weitgehende Absicherung vor Schadenersatzansprüchen. Die Voraussetzung dafür ist, dass die Nutzer in die Lage versetzt werden, ein Produkt gefahrlos zu verwenden. Sollte dennoch einmal ein Nutzer einen Unfall mit einem Produkt erleiden, dann kann der Produkthersteller im Idealfall auf seine technische Dokumentation

das Unternehmen rechtlich absichern



verweisen und darauf, dass der Unfall bei Befolgen der Informationen vermeidbar gewesen wäre.

Einen Überblick über die gesetzlichen Grundlagen der technischen Dokumentation erhalten Sie in Kapitel 2.4 „Gesetzliche Grundlagen der technischen Dokumentation“ ab Seite 12.

Ein ebenfalls wichtiges Argument ist die Verringerung der Anzahl von Supportanfragen, Reklamationen und Garantiefällen. Solche Vorfälle verursachen oft hohe Kosten und verärgern die Kunden. Durch professionell erstellte technische Dokumentation können viele Fehlbedienungen oder ähnliche Probleme von vornherein vermieden werden: Die Anwender erhalten alle nötigen Informationen an der richtigen Stelle und in leicht nachvollziehbarer Weise. Sollten doch einmal Schwierigkeiten auftreten, finden die Anwender zum Beispiel in der Gebrauchsanleitung schnell Hilfe. Die Support-Experten haben somit mehr Zeit für wirklich wichtige Kundenprobleme.

Mit dem technischen Fortschritt werden viele Produkte immer komplexer und damit erklärungsbedürftiger. Ohne die entsprechenden Erklärungen können Anwender nur einen Teil der Funktionen nutzen, die eigentlich verfügbar sind. Das kann dazu führen, dass Anwender insgesamt mit dem Produkt unzufrieden sind, auch wenn keine Fehlbedienungen vorliegen. Viele Funktionen erschließen sich schlichtweg nicht allen Anwendern von selbst. Ist es nicht schade, wenn dadurch Funktionen ungenutzt bleiben, die sogar ein Alleinstellungsmerkmal eines Herstellers sind? Ein Beispiel hierfür sind viele moderne Smartphones: Mitgeliefert wird oft nur noch eine Schnellstartanleitung für die nötigsten Funktionen, zum Beispiel um das Gerät ein- oder auszuschalten oder die SIM-Karte einzulegen. Die Entdeckung aller weiteren Funktionen obliegt dem Spieltrieb des Anwenders.

Einige Unternehmen haben erkannt, dass technische Dokumentation auch Teil einer Markenstrategie sein kann. Kunden, die sich auch nach dem Kauf optimal mit Informationen versorgt fühlen, erleben die Marke positiver. Die Wahrscheinlichkeit steigt, dass Kunden wiederholt ein Produkt dieser Marke kaufen.

Die zielgruppengerecht aufbereiteten Informationen der Technischen Redakteure sind oft für weitere Abteilungen in einem Unternehmen sehr nützlich, zum Beispiel für Schulungen oder für den Vertrieb.

Bei der Erstellung der technischen Dokumentation können natürlich auch Kosten eingespart werden, wenn professionell vorgegangen

die Benutzer befähigen, das Produkt fehlerfrei zu verwenden

die Benutzer befähigen, den Funktionsumfang des Produkts auszunutzen

technische Dokumentation als Marketinginstrument

Schulung und Vertrieb unterstützen

Kosten einsparen



wird. Zentrale Schlagworte sind hier „Wiederverwendung“ und „Automatisierung“.

Mit Hilfe von …

• Modularisierung,

• Trennung von Inhalt und Layout,

• konsistentem und zielgruppengerechtem Inhalt und

• konsistenten Inhaltsstrukturen

… können Inhalte mit relativ geringem Aufwand mehrfach verwendet werden. Das ist beispielsweise dann sinnvoll, wenn ein Produkt in unterschiedlichen Varianten angeboten wird. Es können dann teils dramatische Einsparungen bei der Erstellung der technischen Dokumentation in der Ausgangssprache und beim Übersetzen erzielt werden.

Kosten können zusätzlich eingespart werden durch eine insgesamt bessere Unternehmenskommunikation.

2.4 Gesetzliche Grundlagen der technischen Dokumentation

Die Notwendigkeit von technischer Dokumentation ist gesetzlich verankert. Mehrere Gesetze verlangen mehr oder weniger konkret, dass Hersteller zu ihren Produkten Informationen beilegen, die die Nutzer dazu befähigen, ein Produkt gefahrlos zu verwenden:

• das Produktsicherheitsgesetz (ProdSG)

• das Produkthaftungsgesetz (ProdHaftG)

• das Bürgerliche Gesetzbuch (BGB)

2.4.1 Produktsicherheitsgesetz

Das Produktsicherheitsgesetz (ProdSG) enthält mehrere konkrete Forderungen nach technischer Dokumentation:

§ 3 Absatz 2 ProdSG

„Ein Produkt darf […] nur auf dem Markt bereitgestellt werden, wenn es bei bestimmungsgemäßer oder vorhersehbarer Verwendung die Sicherheit und Gesundheit von Personen nicht gefährdet. Bei der Beurteilung […] sind insbesondere zu berücksichtigen:



• die Eigenschaften des Produkts einschließlich […] Anleitungen für seinen Zusammenbau, die Installation, die Wartung und die Gebrauchsdauer, […]

• die Aufmachung des Produkts, […] die Warnhinweise, die Gebrauchs- und Bedienungsanleitung, die Angaben zu seiner Beseitigung sowie alle sonstigen produktbezogenen Angaben oder Informationen […]“ (Gesetze-im-Internet.de 2015a; eigene Hervorhebungen)

§ 6 Absatz 1 ProdSG

„Der Hersteller [hat] bei der Bereitstellung eines Verbraucherprodukts auf dem Markt

• sicherzustellen, dass der Verwender die Informationen erhält, die er benötigt, um die Risiken, die mit dem Verbraucherprodukt während der […] Gebrauchsdauer verbunden sind und die ohne entsprechende Hinweise nicht unmittelbar erkennbar sind, beurteilen und sich gegen sie schützen zu können […]“ (Gesetze-im-Internet.de 2015b; eigene Hervorhebungen)

§ 3 Absatz 2 aus 9. Verordnung zum Produktsicherheitsgesetz

Das Produktsicherheitsgesetz wird durch einige Verordnungen erweitert. Mittels einer solchen Verordnung wurde unter anderem die EG-Maschinenrichtlinie in deutsches Recht umgesetzt: Die 9. Verordnung zum Produktsicherheitsgesetz – kurz „9. ProdSV“ – entspricht nahezu wörtlich der EG-Maschinenrichtlinie 2006/42/EG. Auch dort findet sich die Forderung nach technischer Dokumentation:

„Der Hersteller […] muss vor dem Inverkehrbringen […] einer Maschine […]

• insbesondere die erforderlichen Informationen, wie die Betriebsanleitung, zur Verfügung stellen […]“

(Gesetze-im-Internet.de 2015c; eigene Hervorhebungen)

§ 3 Absatz 1 aus 9. Verordnung zum Produktsicherheitsgesetz

Die 9. ProdSV enthält eine weitere, indirekte Forderung nach technischer Dokumentation:



„Der Hersteller […] darf Maschinen nur in den Verkehr bringen […], wenn sie bei ordnungsgemäßer Installation und Wartung und bei bestimmungsgemäßer Verwendung oder vorhersehbarer Fehlanwendung die Sicherheit und die Gesundheit von Personen […] nicht gefährden.“ (Gesetze-im-Internet.de 2015c)

Wie eine Maschine ordnungsgemäß installiert und gewartet wird und wie sie verwendet werden soll, sind wichtige Inhalte der technischen Dokumentation für Maschinen.

2.4.2 Produkthaftungsgesetz

Das Produkthaftungsgesetz (ProdHaftG) regelt unter anderem die verschuldensunabhängige Haftung. Außerdem findet sich in diesem Gesetz indirekt die Festlegung, dass die technische Dokumentation Teil des Produktes ist:

§ 1 Absatz 1 ProdHaftG

„Wird durch den Fehler eines Produkts jemand getötet, sein Körper oder seine Gesundheit verletzt oder eine Sache beschädigt, so ist der Hersteller des Produkts verpflichtet, dem Geschädigten den daraus entstehenden Schaden zu ersetzen.“ (Gesetze-im-Internet.de 2015d; eigene Hervorhebungen)

Nach diesem Paragrafen sind Vorsatz und Fahrlässigkeit keine Voraussetzungen dafür, als Hersteller mit Haftungsansprüchen konfrontiert zu werden, falls durch ein Produkt jemand verletzt wird. Es handelt sich um eine verschuldensunabhängige Haftung. Schließlich muss auch bei einem unabsichtlichen Produktfehler der Geschädigte Anspruch auf eine Entschädigung haben. Doch wann hat ein Produkt einen Fehler? Und welche Rolle spielt hierbei die technische Dokumentation? Dazu Paragraf 3 dieses Gesetzes:

§ 3 Absatz 1 ProdHaftG

„Ein Produkt hat einen Fehler, wenn es nicht die Sicherheit bietet, die unter Berücksichtigung aller Umstände, insbesondere

• seiner Darbietung,

• des Gebrauchs, mit dem billigerweise gerechnet werden kann,

• des Zeitpunkts, in dem es in den Verkehr gebracht wurde,



berechtigterweise erwartet werden kann.“ (Gesetze-im-Internet.de 2015e)

Die technische Dokumentation ist genau dazu da, alle sicherheits- und zielgruppenrelevanten Informationen bereitzustellen. Wofür ein Produkt gebraucht werden darf und wofür nicht, sind wichtige Inhalte jeder Gebrauchsanleitung. Die technische Dokumentation gehört außerdem zur „Darbietung“ des Produktes. Also: Ist die technische Dokumentation fehlerhaft, gilt das ganze Produkt als fehlerhaft.

2.4.3 Bürgerliches Gesetzbuch

Im Bürgerlichen Gesetzbuch (BGB) § 823 Absatz 1 ist die verschuldensabhängige Haftung geregelt:

„Wer vorsätzlich oder fahrlässig das Leben, den Körper, die Gesundheit, die Freiheit, das Eigentum oder ein sonstiges Recht eines anderen widerrechtlich verletzt, ist dem anderen zum Ersatz des daraus entstehenden Schadens verpflichtet.“ (Gesetze-im-Internet.de 2015f)

Dieser Paragraph enthält zwar keine konkrete Forderung nach technischer Dokumentation. Doch die technische Dokumentation ist per Gesetz ein Teil des zugehörigen Produktes, siehe Kapitel 2.4.2 „Produkthaftungsgesetz“, Seite 14. Sie soll die Nutzer dazu befähigen, das Produkt gefahrlos zu verwenden. Ein Hersteller, der seinen Kunden oder Nutzern keine oder nur eine mangelhafte technische Dokumentation bereitstellt, handelt somit vorsätzlich oder fahrlässig. Im Schadensfall muss er haften.

2.4.4 Fallbeispiel „Milupa“

Abschließend ein Fallbeispiel, das zeigt, dass die Verurteilung eines Unternehmens – in diesem Fall wegen mangelhafter Warnhinweise – nicht nur eine theoretische Gefahr ist:

„Die Firma Milupa hatte Anfang der 1980er Jahre ein zuckerhaltiges [Getränk] für Kleinkinder sowie Babyflaschen vertrieben. […] 1981 beschrieb [ein Professor], dass dauerndes Nuckeln […] zum Nursing-Bottle-Syndrom, einer Form der Karies an den Milchzähnen, führen kann. Daraufhin fügte die Firma entsprechende Warnhinweise bei, die sich bis Ende 1982 ohne besondere Hervorhebung in der Zubereitungsanleitung befanden. […] Das Nursing-Bottle-Syndrom war bereits 1971 in ausländischen Publikationen beschrieben worden.

Beispiel Milupa-Fall



[Dem] 1979 geborenen Kläger [wurden] bis 1983 täglich […] die Flaschen […] zum Einschlafen gegeben […], sodass er langandauernd unbeaufsichtigt genuckelt hatte. 1985 wurde bei ihm Milchzahnkaries festgestellt und mehrere Schneidezähne mussten gezogen werden. Er verlangte vom Hersteller Schadenersatz.

Der Bundesgerichtshof […] sprach dem Kläger Schadenersatz gemäß § 823 […] BGB zu, da der Hersteller seiner Instruktionspflicht nicht ausreichend nachgekommen sei.

Das Gericht vertrat die Auffassung, dass der Hersteller bereits 1979 die Gefahr von Milchzahnkaries hätte kennen müssen. Zudem seien die angebrachten Warnhinweise nicht ausreichend gewesen. Selbst nach 1982, als die Hinweise hervorgehoben wurden, sei nicht davon auszugehen gewesen, dass Kunden […] diese Hinweise lesen würden, da die Warnung nicht deutlich genug sei. Diese Verletzung der Instruktionspflicht sei schuldhaft gewesen […]. Die Richter merkten in der Urteilsbegründung auch an, dass es zwar kein bestimmungsgemäßer Gebrauch sei, das Kind dauernd unbeaufsichtigt nuckeln zu lassen, jedoch ein naheliegender Fehlgebrauch […].“

(Wikipedia 2013)

2.5 Für wen technische Dokumentation? Bei der Erstellung von technischer Dokumentation spielen Zielgruppen eine zentrale Rolle. Von der Zielgruppe eines Informationsproduktes hängen unter anderem der Inhalt, die fachliche Tiefe und die Terminologie ab. Doch wie können Sie als Technischer Redakteur herausfinden, wer Ihre Zielgruppe ist und welche Vorkenntnisse und Informationsbedürfnisse diese Zielgruppe hat?

2.5.1 Zielgruppenanalyse

Hier geht es darum, sich Informationen über eine Zielgruppe zu verschaffen, indem Sie mit Angehörigen der Zielgruppe sprechen oder indem Sie Dritte befragen, die eine Zielgruppe kennen.

Eine wichtige Quelle für das Wissen über Ihre Zielgruppe sind Personen in Ihrem Unternehmen, die unmittelbar mit den Nutzern zu tun haben, zum Beispiel:

• Support- oder Servicepersonal

• Vertrieb/Verkauf

unternehmensinterne Quellen



• Inbetriebnehmer

• Wartungspersonal

• Schulungspersonal

Weitere Quellen für eine Zielgruppenrecherche können sein:

• Internetforen und soziale Medien

• einschlägige Blogs

• Bewertungen in Onlineshops

• Tests und Artikel in Fach-/Zeitschriften

Doch Achtung! Unter Umständen sind die Käufer nicht unbedingt auch die Nutzer eines Produktes. Ein eindrückliches Beispiel für den Unterschied zwischen Käufer und Nutzer ist der sogenannte „Landmaschinen-Fall“, ein Gerichtsurteil aus den USA:

Ein Hersteller von Landmaschinen in den USA lieferte für seine Maschinen ordentliche Betriebsanleitungen mit. Für den US-amerikanischen Markt waren diese auf Englisch verfasst. Aufgrund einer Fehlbedienung geschah jedoch ein Unfall, es kam zur Klage und der Hersteller wurde für schuldig befunden. Denn: Der Hersteller hätte überprüfen müssen, wer die Zielgruppe ist bzw. wer die Landmaschinen tatsächlich bedient. Dann wäre ihm aufgefallen, dass überwiegend Spanisch sprechende Immigranten die Maschinen bedienen. Mindestens alle sicherheitsrelevanten Informationen hätten in der Folge auch auf Spanisch vorliegen müssen. (Quelle unbekannt, aus dem Gedächtnis)

Für technische Dokumentation, die über das Internet bereitgestellt wird, können besondere Möglichkeiten angewandt werden, die Zielgruppe besser kennenzulernen: Auf Webseiten, in Smartphone- oder Tablet-Apps oder ähnlichen Medien können Nutzer direkt Rückmeldungen zu konkreten Hilfe-Inhalten geben. Diese Bewertungen werden an die Autoren der Hilfe-Inhalte gesendet. Nachfolgend exemplarisch die Hilfe-Seiten zur Software Adobe Acrobat:

unternehmensexterne Quellen

Beispiel Landmaschinen-Fall

direktes Feedback von Nutzern der technischen Dokumentation



Abbildung 2: Onlinehilfe für Adobe Acrobat (Adobe 2015)

Abbildung 3: Onlinehilfe für Adobe Acrobat (Adobe 2015)

2.5.2 Was-macht-wer-Matrix

Welche Zielgruppe braucht welche Informationen? Eine sehr praktische Art, diese Fragestellung zu veranschaulichen, ist die Was-macht-wer-Matrix. Ein Beispiel:

Wer tut es?

Was ist zu tun? Spediteur Monteur Inbetrieb-

nehmer Bediener

Aufbau und Funktion

X X

Transport und Lagerung

X X

Montage X Inbetriebnahme X Bedienung X X Tabelle 2: Was-macht-wer-Matrix, Beispiel (vgl. Juhl 2002, 16)

Beispiel



Die Kopfzeile der Was-macht-wer-Matrix enthält die Zielgruppen, die berücksichtigt werden müssen. Die linke Spalte enthält die zu beschreibenden Tätigkeiten. Durch Kreuze in den jeweiligen Tabellenzellen kann dargestellt werden, welche Zielgruppe welche Informationen benötigt. Aus dieser Übersicht können im Wesentlichen zwei Erkenntnisse abgeleitet werden:

• Wer ist die Zielgruppe für das jeweilige Kapitel?

• Falls die Inhalte auf unterschiedliche Informationsprodukte aufgeteilt werden sollen (z. B. Montageanleitung und Betriebsanleitung): Welches Informationsprodukt muss welche Inhalte enthalten?

2.5.3 Persona-Methode

Bei der Persona-Methode werden fiktive, typische Vertreter – sogenannte „Personas“ – einer oder mehrerer Zielgruppen erdacht. Diese Personas erhalten typische Merkmale der jeweiligen Zielgruppe. Anschließend versucht zum Beispiel der Technische Redakteur, das (Informations-) Produkt mithilfe der Personas aus den Augen der Zielgruppe zu betrachten. Er fragt sich: „Würde Daniel diese Information verstehen?“ oder „Würde Margott diese Gestaltung ansprechend finden?“

Die einmal entworfenen Personas begleiten das Produkt durch den gesamten Entwicklungsprozess: von den ersten Produktentwürfen bis zum fertigen Produkt einschließlich der technischen Dokumentation.

Nehmen wir zum Beispiel die Persona „Daniel“:

„Beruf

Daniel (29) arbeitet als freiberuflicher Fotograf. Seine Aufträge bekommt er hauptsächlich aus der Industrie, er versucht aber auch, als Landschaftsfotograf Fuß zu fassen. Daher reist er sehr viel und hat vor allem in Asien Zustände gesehen, die er gerne verändern würde.

Freizeit

In seiner Freizeit macht Daniel gerne Sport, wie z. B. Klettern. Außerdem interessiert er sich für Kunst und besucht gelegentlich Ausstellungen. Seine Freunde, mit denen er gerne etwas unternimmt, sind ihm wichtig. Momentan ist Daniel Single und wohnt alleine in einer gemütlichen Wohnung.

Beispiel für eine Persona



Einkaufsverhalten

Umweltschutz ist für ihn genauso ein Thema wie fairer Umgang mit Menschen, da er schon viele Missstände gesehen hat. Auch bei Kleidung legt er viel Wert auf fairen Handel. Leider ist es sehr schwierig, Kleidung zu finden, die auch seinem Geschmack entspricht, da die Anbieter oftmals ein Öko-Image verkaufen.

Internetnutzung

Daniel nutzt verschiedene Angebote im Internet sehr aktiv und schreibt unregelmäßig in einem eigenen Blog über seine Reisen. Sowohl seine Bankgeschäfte als auch Kundenkontakte wickelt er online ab. Die Marke [xy] kennt er schon länger und bestellt sie manchmal über www.ebay.de. Auch auf der Seite www.armedangels.de kauft er gerne ein und beteiligt sich in der Community.“

(Usability-toolkit.de 2015)

2.6 Allgemeine Anforderungen an technische Dokumentation aus Sicht der Nutzer

Nachfolgend werden einige wichtige Anforderungen an technische Dokumentation erläutert. Das Ziel ist, Ihnen einen allgemeinen Eindruck von der Komplexität des Fachgebietes zu verschaffen.

2.6.1 Leicht verständlich

Der Aspekt der leichten Verständlichkeit ist sehr umfangreich. Es gibt eine Vielzahl von Aspekten, die Einfluss darauf haben, was von einer Zielgruppe gut verstanden werden kann:

Logische Reihenfolge der Inhalte

Die Inhalte eines Informationsprodukts sollen so angeordnet sein, wie es dem Gebrauch durch die Zielgruppe entspricht. Die Reihenfolge ist auf allen Inhaltsebenen zu berücksichtigen: Hauptkapitel, Unterkapitel, Abschnitte, Sätze.

Positivbeispiele logische Reihenfolge



Beispiel 1:

Eine Betriebsanleitung für eine Maschine enthält u. a. folgende Hauptkapitel: „Transport“, „Montage“, „Inbetriebnahme“ und „Betrieb“ in dieser Reihenfolge

Beispiel 2:

Eine Handlungssequenz enthält u. a. folgende Schritte: 1. Muttern lösen. 2. Abdeckung abnehmen.

Schlecht wäre die umgekehrte Reihenfolge:

1. Die Abdeckung abnehmen, nachdem die Muttern gelöst wurden.

Einfacher Satzbau, einfache Formulierungen

Es gibt gerade auch in der deutschen Sprache einen sehr großen Variantenreichtum, mit dem Sachverhalte ausgedrückt werden können. Viele Formulierungsweisen sind für technische Dokumentation jedoch nicht geeignet.

Als Technische Redakteure wollen wir Formulierungen, aus denen unmissverständlich und leicht nachvollziehbar hervorgeht, wer was womit tun soll, wo eine Gefahr lauert oder dergleichen.

Schlecht wäre beispielsweise folgende Formulierung:

1. Befestigen Sie die Schutzkappen an den auf eine vorgeschriebene Länge abisolierten Leitungsenden mit einer Flachzange.

Diese Formulierung ist aus zwei Gründen nicht geeignet:

• Sie ist wegen des Einschubs „auf eine vorgeschriebene Länge abisolierten“ zu komplex.

• Die Handlungsaufforderung wird vermischt mit Hinweisen („mit einer Flachzange“).

Verbessert könnte der ursprüngliche Satz so lauten:

1. Befestigen Sie die Schutzkappen an den Leitungsenden. - Die Leitungsenden sind auf eine vorgeschriebene Länge abisoliert. - Verwenden Sie zum Befestigen eine Flachzange.

Der Satzteil „den auf eine vorgeschriebene Länge abisolierten Leitungsenden“ im Ausgangssatz könnte auch als versteckte

Negativbeispiel

Negativbeispiel



Handlungsaufforderung gedeutet werden. Dann ist jedoch unklar, wie lang die „vorgeschriebene Länge“ ist. Soll der Nutzer selbst recherchieren? Der nochmals verbesserte Satz könnte wie folgt lauten:

1. Entfernen Sie die Isolierung der Leitungsenden auf eine Länge von je 15 mm.

2. Befestigen Sie die Schutzkappen an den Leitungsenden. - Verwenden Sie zum Befestigen eine Flachzange.

Die verbesserten Varianten des Ausgangssatzes sind zwar nicht kürzer, aber wesentlich verständlicher. Verständlichkeit hat in jedem Fall Vorrang vor Kürze.

Geeignete Terminologie

Je nach Zielgruppe kann es sinnvoll sein, bestimmte Fachwörter zu verwenden, Fachwörter zu vermeiden oder sie zumindest zu erklären.

Für die Zielgruppe der Ärzte könnte eine Bedienungsanleitung für ein medizinisches Gerät beispielsweise den Ausdruck „biphasischer Defibrillator“ enthalten. Für die Zielgruppe der medizinischen Laien wären stattdessen die Ausdrücke „2-phasiger Schockgeber“ oder nur „Schockgeber“ möglicherweise verständlicher.

Klare und übersichtliche Struktur und Gestaltung

Die Struktur, einschließlich der Kapitelgliederung, soll den Leser durch den Inhalt führen und ihm die Orientierung im Informationsprodukt erleichtern. Dies geht einher mit einer übersichtlichen Gestaltung. Die Gestaltung sollte die Inhaltsstruktur und die Textfunktionen unterstützen.

Der folgende Ausschnitt aus einer Gebrauchsanleitung ist sehr unübersichtlich:

Beispiel Terminologie

Negativbeispiel



Abbildung 4: Ausschnitt aus einer Gebrauchsanleitung mit schlechter Gestaltung (BOCA 2006)

Den Leser erwartet im Wesentlichen ein Textbrei. Die einzelnen Handlungsschritte, Hinweise und weiteren Informationen muss er sich mühsam zusammensuchen. Der Inhalt ist nicht strukturiert und nicht hilfreich gestaltet.

Wesentlich übersichtlicher ist der folgende Ausschnitt aus einer anderen Gebrauchsanleitung:

Abbildung 5: Ausschnitt aus einer Gebrauchsanleitung mit guter Gestaltung (Melitta 2013)

Die einzelnen Handlungsvoraussetzungen, Handlungsschritte und Zwischenergebnisse sind klar erkennbar. Der Inhalt wirkt aufgeräumt.

Positivbeispiel



Gegenüber dem Negativbeispiel (siehe Abbildung 4) wurden folgende Gestaltungsmittel verwendet:

• Farben

• Hervorhebungen durch Fettschrift und Kursivschrift

• Einrückungen

• Nummerierung

• Listenpunkte/Pfeile

• Symbole

• Schriftart ohne Serifen

Konsistenz

Konsistenz, also eine Gleichmäßigkeit, ist in mehreren Hinsichten anzustreben:

• Satzbau und Formulierungsmuster

• Gestaltung

• Terminologie

• Inhaltsstruktur

Mithilfe von Konsistenz kann der Leser intuitiv den Aufbau und den wesentlichen Inhalt eines Informationsproduktes erfassen und Wichtiges von Unwichtigem unterscheiden.

Inkonsistenz hingegen stiftet Verwirrung, wie in folgendem Beispiel für terminologische Inkonsistenz:

1. Defibrillator an Stromnetz anschließen. 2. Schockgeber einschalten.

Ein medizinischer Laie könnte sich hier fragen, ob „Defibrillator“ und „Schockgeber“ dasselbe ist. Die Sekunden der Unsicherheit könnten im schlimmsten Fall bereits das Ende eines Menschenlebens bedeuten.

Rechtschreibung und Grammatik korrekt

Alle Texte sollten nach den gültigen Rechtschreib- und Grammatikregeln verfasst sein. Kommafehler, Bezugsfehler, Rechtschreibfehler und dergleichen können zu Missverständnissen führen. Nachfolgend ein Beispiel für einen Bezugsfehler:

Negativbeispiel terminologische Inkonsistenz



„Wenn eine IF-Kontrollstruktur eine ELSE-Anweisung enthält, dann wird genau einer ihrer Blöcke ausgeführt.“ (tekom 2013, 60)

In diesem Beispiel ist der Bezug des Pronomens „ihrer“ unklar. Es könnte sich auf „IF-Kontrollstruktur“ oder auf „ELSE-Anweisung“ beziehen. Korrigiert könnte der Satz so lauten:

„Wenn eine IF-Kontrollstruktur eine ELSE-Anweisung enthält, dann wird genau ein Block der IF-Kontrollstruktur ausgeführt.“ (tekom 2013, 60)

Geeignete Landessprache

Informationsprodukte müssen in einer Landessprache verfasst sein, die von der Zielgruppe verstanden wird. So fordert beispielsweise die Maschinenrichtlinie: „Jeder Maschine muss eine Betriebsanleitung in der [Amtssprache] des Mitgliedstaats beiliegen, in dem die Maschine in Verkehr gebracht und/oder in Betrieb genommen wird.“ (Europäische Union 2006)

Dass dieser Aspekt durchaus nicht immer eine Selbstverständlichkeit ist, zeigt zum Beispiel der „Landmaschinen-Fall“, siehe Kapitel 2.5.1 „Zielgruppenanalyse“, Seite 17.

2.6.2 Gut leserlich

Die Leserlichkeit betrifft die optischen Eigenschaften eines Textes. Dazu zählen unter anderem:

Geeignete Typografie

Standard ist serifenlose Schrift. Serifenlose Schriften können im Allgemeinen am besten gelesen werden.

Geeignete Schriftgröße

Die Norm DIN EN 82079-1 empfiehlt für den Fließtext in Handbüchern und auf Bildschirmen eine Mindestschriftgröße von 10 Punkt, für Überschriften 12 Punkt. Für sehr kleine Produkte und Verpackungen werden mindestens 6 Punkt empfohlen (vgl. Beuth 2013, 35).

Gute Kontraste

Standard ist schwarze Schrift auf weißem Grund. Bei der Verwendung von Farben sollte sichergestellt werden, dass diese auch bei einem

Beispiel



Graustufen-Ausdruck noch ausreichende Kontraste bieten (vgl. Beuth 2013, 37).

Gut erkennbare Abbildungen

Abbildungen sollten stets in ausreichender Qualität verwendet werden, sodass sie sowohl am Bildschirm, als auch in Ausdrucken deutlich erkennbar sind.

2.6.3 Reibungsloser Zugang möglich

Bei der Erstellung von technischer Dokumentation sollte berücksichtigt werden, unter welchen Umständen die Zielgruppe sie voraussichtlich nutzen wird. Die Art der Darbietung soll dieses Nutzungsverhalten unterstützen und einen reibungslosen Zugriff auf die Informationen ermöglichen. Neben der Leserlichkeit (siehe Kapitel 2.6.2 „Gut leserlich“, Seite 25) sind hier beispielsweise noch folgende Aspekte relevant:

Hilfreiche Navigationsmittel

Neben Inhaltsverzeichnissen werden häufig auch Stichwortverzeichnisse gern von Lesern genutzt, um schnell bestimmte Informationen zu finden. Auch Griffregister können sehr nützlich sein. Diese Navigationsmittel sind jedoch bei der Erstellung der technischen Dokumentation mit einem erhöhten Aufwand verbunden. Das Kosten-Nutzen-Verhältnis muss auch hier abgewogen werden.

Geeignetes Medium

Das Medium, auf dem die technische Dokumentation ausgeliefert wird, darf dem Nutzer nicht den Zugriff auf die Informationen erschweren. Wird beispielsweise eine Gebrauchsanleitung nur als PDF-Dokument geliefert, nicht in Papierform, dann muss sichergestellt sein, dass der Leser einen Rechner mit der nötigen Software zur Verfügung hat, um das PDF-Dokument öffnen zu können.

Bei einem Drucker wird man davon ausgehen können, dass der Nutzer auch einen Rechner zur Verfügung hat. Bei einem Toaster wäre diese Voraussetzung jedoch nicht unbedingt gegeben. Beide Geräte haben sehr unterschiedliche Zielgruppen.

Beispiel



2.6.4 Zielgruppengerechter Inhalt und Umfang

Das Motto lautet: „So viel wie nötig, so wenig wie möglich!“

Die technische Dokumentation muss alle Informationen enthalten, die erforderlich sind, damit der Nutzer das Produkt gefahrlos verwenden und den Funktionsumfang ausschöpfen kann. Alles Weitere ist meistens überflüssig.

Je umfangreicher beispielsweise eine Gebrauchsanleitung ist, …

• … desto größer ist die Hürde für den Nutzer, die Gebrauchsanweisung überhaupt zu lesen,

• … desto schwieriger ist es für den Nutzer, einen Überblick über die Inhalte zu bekommen.

Nebenbei bemerkt steigen mit dem Umfang einer Anleitung auch die Kosten für die Erstellung der Gebrauchsanleitung, insbesondere für die Übersetzungen. Auch der Pflegeaufwand nimmt mit dem Umfang zu.

Häufige Negativbeispiele sind Gebrauchsanweisungen, die von den Entwicklern eines Produktes geschrieben wurden. Entwickler haben eine ganz andere Sichtweise auf ihr Produkt, sie halten andere Dinge für wichtig als die Nutzer des Produktes. Typische Fehler solcher Gebrauchsanleitungen sind:

• umfangreiche Beschreibungen technischer Hintergründe und Zusammenhänge, die für den Gebrauch des Produkts jedoch nicht relevant sind

• dadurch oft insgesamt ein unnötig großer Umfang

• unvollständige, nicht leicht nachvollziehbare Handlungsanleitungen, weil die Vorkenntnisse der Zielgruppe kaum berücksichtigt oder falsch eingeschätzt wurden

2.6.5 Korrekter Inhalt

Die Inhalte von technischer Dokumentation sollen selbstverständlich korrekt sein. Hierzu arbeiten sich Technische Redakteure in das betreffende Produkt ein, um es anschließend in ausreichender, zielgruppengerechter Tiefe beschreiben zu können. Eine enge Zusammenarbeit mit den Entwicklern des Produkts ist unbedingt nötig.

Fehlerquellen können jedoch auch in der Übersetzung der technischen Dokumentation liegen. Abhängig von der Qualifikation



und Motivation der Übersetzer und von der Qualität der Zusammenarbeit mit dem Auftraggeber können sich auch bei der Übersetzung Fehler einschleichen. Diese Fehler bleiben oft unbemerkt, weil der Auftraggeber die Zielsprache nicht beherrscht.

2.6.6 Sichere Anleitungen

Alle Sicherheitsstandards, die für eine Branche und für ein Produkt relevant sind, müssen selbstverständlich berücksichtigt werden. Das Ziel ist, dem Nutzer alle Informationen an die Hand zu geben, damit dieser das Produkt möglichst gefahrlos verwenden kann. Der Nutzer muss deshalb auch über Restrisiken aufgeklärt werden.

2.7 Allgemeine Anforderungen an technische Dokumentation aus Sicht der Hersteller

Die wichtigsten Anforderungen, die Produkthersteller im Allgemeinen an ihre technische Dokumentation stellen, wurden bereits in Kapitel 2.3 „Wozu professionelle technische Dokumentation?“ ab Seite 10 besprochen.

Der Aspekt der Wirtschaftlichkeit soll hier jedoch besonders betont werden. Ob ein Unternehmen sich ernsthaft mit der technischen Dokumentation beschäftigt, hängt letztendlich oft davon ab, ob diese als wirtschaftlich lohnend betrachtet wird – oder als bloßer Kostenfaktor. Auch technische Dokumentation muss wirtschaftlich sein.

Ein Unternehmen, das sich ohnehin keine Gedanken über das Wohlergehen seiner Zielgruppe macht, wägt ab, was wohl teurer wird: gelegentliche Schadenersatzforderungen oder professionell erstellte technische Dokumentation.

2.8 Vorgehensmodelle und Projektplan Das Erstellen von technischer Dokumentation – von den ersten Recherchen bis zur Auslieferung der Dokumente – folgt meistens einem bestimmten Schema. Wie dieses Schema aussieht, ist sehr unternehmensspezifisch und auch von persönlichen Arbeitsweisen des Technischen Redakteurs abhängig. Bei der Neuentwicklung oder Verbesserung eines solchen Schemas können einschlägige Vorgehensmodelle als Vorlage dienen. Zwei solcher



Vorgehensmodelle zum Erstellen von technischer Dokumentation werden nachfolgend vorgestellt.

2.8.1 Vorgehensmodell ALASKA

Das Vorgehensmodell ALASKA wurde von der Technischen Redakteurin Dr. Britta Görs entwickelt. Sie hat die sechs Schritte, die in ALASKA vorgesehen sind, von einem Vorgehensmodell abgeleitet, das im Fachgebiet der Mediation verbreitet ist.

A wie Auftragsklärung

• Was soll beschrieben werden und warum?

• Grober Auftragsablauf, Phasen

• Ist-Situation ermitteln und Soll-Situation festlegen

• Verteilung von Verantwortung

L wie Liste der Themen, Beteiligten und Rahmenbedingungen

• Welche Informationsquellen sind verfügbar?

• Bedingungen für Korrektur- und die Freigabephasen?

• Redaktionsleitfaden oder andere Standards vorhanden?

• Zu berücksichtigende Meilensteine des TR?

A wie Analyse des Produkts und der Zielgruppe

• Kennenlernen des Produkts

• Ermitteln der Zielgruppe(n) und deren typische Kenntnisse

• typischer Umgang der Zielgruppe mit dem Produkt

S wie Strukturieren, recherchieren, schreiben

• Erstellen eines ersten Entwurfs des Informationsprodukts

K wie Korrektur und Kontrolle

• Einholen von Rückmeldungen zum ersten Entwurf

• Einarbeiten der Rückmeldungen in das Informationsprodukt

• Erstellen des finalen Informationsprodukts



A wie Abschluss mit Freigabe der Technischen Dokumentation

• Freigabe des Informationsprodukts durch den Auftraggeber

• Übersetzung

• Publikation

(Görs 2010)

2.8.2 Vorgehensmodell nach DIN EN 82079-1

Der Anhang der Norm DIN EN 82079-1:2013 „Erstellen von Gebrauchsanleitungen – Gliederung, Inhalt und Darstellung“ enthält ein Vorgehensmodell, das folgende zehn Schritte für das Erstellen von Gebrauchsanleitungen vorsieht:

1. Produkt und Zielgruppe analysieren, Rahmenbedingungen festlegen

2. Planung und Projektmanagement

3. Konzeption des Informationsprodukts

4. Einbindung der Doku-Erstellung in die Produktentwicklung

5. Recherche

6. Inhaltserstellung

7. Qualitätsüberprüfung (z. B. Korrekturlesen)

8. Qualitätssicherung (z. B. Usability-Test)

9. Übersetzung

10. Medienproduktion

(vgl. Beuth 2013, 53 ff.)

2.9 Inhalt von technischer Dokumentation

2.9.1 Allgemeine Vorgaben durch Normen und Gesetze

Bei der Frage, welche Inhalte oder Themen technische Dokumentation enthalten soll, sind je nach Branche und Produkttyp eine Reihe von Vorschriften und Normen zu berücksichtigen. Es gehört zu den Aufgaben eines Technischen Redakteurs, die relevanten Vorgaben zu recherchieren.

Allgemeine Vorgaben zum Inhalt macht beispielsweise das Produktsicherheitsgesetz, § 6, Absatz 1:



„Der Hersteller [hat] bei der Bereitstellung eines Verbraucherprodukts auf dem Markt

1. sicherzustellen, dass der Verwender die Informationen erhält, die er benötigt, um die Risiken, die mit dem Verbraucherprodukt […] verbunden sind […] beurteilen und sich gegen sie schützen zu können […]“

(Gesetze-im-Internet.de 2015b)

Daraus lässt sich ableiten, dass Sicherheitshinweise und Warnhinweise sehr wichtig sind. Aber auch korrekte Handlungsanleitungen und – je nach Zielgruppe – Hintergrundwissen, zum Beispiel die Beschreibung von Funktionsprinzipien.

Einige EU-Richtlinien bzw. die entsprechenden nationalen Gesetze enthalten ebenfalls Vorschriften für den Inhalt von technischer Dokumentation. Die Maschinenrichtlinie (in Form der 9. ProdSV, siehe Kapitel 2.4.1 „Produktsicherheitsgesetz“, ab Seite 12) ist diesbezüglich eine der umfangreichsten Richtlinien. Sie enthält in Anhang 1 viele, zum Teil sehr detaillierte Vorschriften zum Inhalt von technischer Dokumentation. Ein Auszug:

„Jede Betriebsanleitung muss erforderlichenfalls folgende Mindestangaben enthalten:

• Firmenname und vollständige Anschrift des Herstellers und seines Bevollmächtigten; […]

• die für Verwendung, Wartung und Instandsetzung der Maschine und zur Überprüfung ihres ordnungsgemäßen Funktionierens erforderlichen Zeichnungen, Schaltpläne, Beschreibungen und Erläuterungen; […]

• eine Beschreibung der bestimmungsgemäßen Verwendung der Maschine; […]“

(Europäische Union 2006)

Auch in einigen Normen finden sich Vorgaben, welche Informationen in technischer Dokumentation enthalten sein sollten. Allen voran ist hier die DIN EN 82079-1 zu nennen, die sich in Kapitel 5 „Inhalt von Gebrauchsanleitungen“ relativ ausführlich, aber natürlich allgemein gehalten, mit dem Inhalt von technischer Dokumentation befasst. In Kapitel 5.1 fordert die Norm beispielsweise:

„Die Funktionalität der Produkte muss beschrieben werden und Fragen der Nutzer zum WO? WER? WAS? WANN? WIE? WARUM?

Produktsicherheits-gesetz

EU-Richtlinien

Normen



sollten vorweggenommen und passende Antworten gegeben werden.“

„Die Informationstiefe hängt von der (den) Zielgruppe(n) ab und den beabsichtigten oder erlaubten Aufgaben, die im Laufe des Produktlebens ausgeführt werden.“ (Beuth 2013, 20)

Und in Kapitel 5.8.2 „Installation“:

„Bei Produkten, die eine Installation erfordern, muss die Gebrauchsanleitung, soweit zutreffend, enthalten:

• Vorgehensweise zur Entfernung von Transport- und Verpackungssicherungen […]

• Checkliste der Dinge, die in der Packung enthalten sind […]

• Anschlussplan und/oder -tabelle

• Bedingungen für Zusammenbau und Montage […]“

(Beuth 2013, 20)

2.9.2 Fallbeispiel Kreissäge

Nachfolgend wird am Beispiel einer Kreissäge demonstriert, wie Schritt für Schritt eine Inhaltsstruktur, unter anderem auf Basis von Vorschriften aufgebaut werden kann. Begonnen wird mit den sehr allgemeinen Vorschriften, den Abschluss bilden sehr spezielle, produktspezifische Vorschriften und Themen.

Ausgangssituation

• Produkt: Kreissäge (stationär, elektrisch betrieben)

• Info vom Hersteller: Die Kreissäge wird fertig montiert zum Kunden geliefert.



Abbildung 6: Kreissägemaschine Hammer B3 basic (Miller 2015)

Standardinhalte im Allgemeinen

Die DIN EN 82079-1 schreibt für Gebrauchsanleitungen folgende Standardinhalte vor, soweit sie für die Zielgruppe relevant sind:

• Technische Daten

• Allgemeine Sicherheitshinweise

• Transport und Lagerung

• Inbetriebnahme

• Betrieb

• Instandhaltung

• Entsorgung

(Beuth 2013, 20 ff.)

Standardinhalte für Maschinen

Zunächst ist zu prüfen, ob die Maschinenrichtlinie für Kreissägen gilt. Hierzu lesen wir die Artikel 1 „Anwendungsbereich“ und 2 „Begriffsbestimmung“ der Maschinenrichtlinie. Aus diesen Artikeln geht hervor, dass die Maschinenrichtlinie hier Anwendung findet.

Anschließend lesen wir Anhang 1 der Maschinenrichtlinie, Kapitel 1.7.4.2 „Inhalt der Betriebsanleitung“. Für unsere Kreissäge sind unter anderem die folgenden Inhalte relevant:

• d) allgemeine Beschreibung der Maschine



• g) Beschreibung der bestimmungsgemäßen Verwendung der Maschine

• i) Anleitungen zur Montage, zum Aufbau und zum Anschluss der Maschine

• l) Angaben zu Restrisiken […]

• m) Anleitung für die vom Benutzer zu treffenden Schutzmaßnahmen […]

Standardinhalte für Holzbearbeitungsmaschinen

Mithilfe des tekom-Normenkommentars (www.tekom.de/dienste/normenkommentar.html) recherchieren wir nach speziellen Vorschriften für die technische Dokumentation von Kreissägen. Die Suche ist zwar zunächst erfolglos, doch eine Verallgemeinerung auf „Holzbearbeitungsmaschinen“ führt zu einem Treffer, nämlich zur Norm EN 859 „Sicherheit von Holzbearbeitungsmaschinen“.

Abbildung 7: Suchtreffer im tekom-Normenkommentar (tekom 2015b)

Die Norm EN 859 schreibt zusätzlich zu den bisherigen Standardinhalten folgende Inhalte vor:

• „a) eine Wiederholung der […] Kennzeichnungen, Piktogramme und der anderen Hinweise an der Maschine, und sofern erforderlich, Information zu ihrer Bedeutung“

• „c) einen Warnhinweis über Restrisiken: Staub, Lärm, […] Rückschlag“

• „f) wenn notwendig bei stationären Maschinen die Forderung, wie die Maschine am Fußboden befestigt werden muss“



(tekom 2015b)

Bisherige Standardinhalte

Aus den bisher berücksichtigten Normen und Richtlinien ergibt sich bereits folgende Inhaltsstruktur für die Gebrauchsanleitung der Kreissäge:

• 1 Sicherheit

• 1.1 Erklärung der Gefahrenzeichen 1.2 Allgemeine Sicherheitshinweise 1.3 Bestimmungsgemäße Verwendung 1.4 Schutzmaßnahmen 1.5 Restrisiken

• 2 Transport und Lagerung

• 3 Aufbau

• 4 Aufstellung und Inbetriebnahme

• 4.1 Kreissäge aufstellen 4.2 Kreissäge an elektrischen Strom anschließen

• 5 Betrieb

• 6 Instandhaltung

• 7 Entsorgung

• 8 Technische Daten

Weitere Vorschriften bestehen für die Kapitelinhalten, insbesondere gemäß der Norm EN 859. Beispielsweise müssen Warnhinweise zu Staub und Rückschlag enthalten sein.

Produktspezifische Inhalte

Über die bisherigen Vorschriften hinaus sind auch produktspezifische Inhalte notwendig, vor allem hinsichtlich der Bedienung und des Betriebs der Kreissäge:

• 5 Betrieb 5.1 Schiebetisch einstellen 5.2 Leisten schneiden 5.3 Nuten fräsen …



2.9.3 Konstruktion vor Instruktion Technische Dokumentation kann nicht und darf nicht dazu dienen, sicherheitstechnische Mängel eines Produktes auszugleichen!

Produkte müssen so weit wie möglich von vornherein sicher konstruiert und gegebenenfalls mit Schutzmaßnahmen versehen werden. Hierfür sind vom Hersteller entsprechende Risikobeurteilungen durchzuführen. Nur unvermeidliche Restrisiken müssen letztendlich in der technischen Dokumentation beschrieben werden.

2.10 Lernkontrolle Geschafft! Sehr gut! Dieses erste Inhaltskapitel war auch das umfangreichste. Damit Sie das neue Wissen gleich ein wenig festigen, beantworten Sie bitte die folgenden fünf Fragen:

1. Was ist der Unterschied zwischen interner und externer technischer Dokumentation?

2. Was sind die beiden wichtigsten Argumente dafür, technische Dokumentation professionell zu erstellen?

3. Welche deutschen Gesetze enthalten eine direkte Forderung nach technischer Dokumentation (auch wenn technische Dokumentation nicht als solche benannt wird)?

4. Welche Rolle spielen Zielgruppen in der technischen Dokumentation?

5. Welche Aspekte tragen zu einer guten Verständlichkeit von technischer Dokumentation bei?

Wozu standardisieren?


3 Wozu standardisieren?

3.1 Das „Schema F“ Mehr leisten in höherer Qualität, ohne mehr Ressourcen zu benötigen – das ist in der technischen Dokumentation wie auch in anderen Fachgebieten der Sinn von Standardisierung. Das „Rad nicht ständig neu zu erfinden“, sondern sich ein „Schema F“ zurechtzulegen, spart Zeit und führt zu gleichbleibend guten Ergebnissen – je nachdem, wie gut das „Schema F“ ist.

Es ist anfangs ein relativ hoher Aufwand, sich ein solches „Schema F“ zu überlegen. Aber wer sich nicht die Zeit nimmt, handelt im Grunde wie der berühmte Holzfäller: Der müht sich beim Fällen von Bäumen mit einer stumpfen Axt ab, weil er sich nicht die Zeit nimmt, seine Axt zu schärfen.

3.2 Standardisieren dem Leser zuliebe Das wichtigste, was wir als Technische Redakteure standardisieren können, sind unsere Inhalte und deren Strukturen. Unsere typischen Textsorten (hauptsächlich instruktiv, gelegentlich auch deskriptiv und argumentativ) eignen sich sehr gut dazu, standardisiert zu werden:

• immer die gleichen Formulierungsmuster

• immer die gleiche Terminologie

• immer die gleiche Gliederung

• immer die gleiche Gestaltung

Unsere Zielgruppen erwarten keine abwechslungsreichen und mitreißenden literarischen Texte. Sondern: Der typische Leser unserer Anleitung hat gerade ein Problem mit einem Produkt. Er greift zu unserer Anleitung, sucht im Inhaltsverzeichnis oder im Stichwortverzeichnis nach dem Kapitel, das die Lösung seines Problems verspricht. Er schlägt das Kapitel auf und möchte nun auf möglichst direktem Wege erfahren, wie er das Problem lösen kann.

Nein, der Leser möchte in dieser Situation nicht wissen, wie kunstfertig der Autor mit Sprache umgehen kann, wie kreativ er in MS Word Text formatieren kann und ob er über das Produkt genauso gut Bescheid weiß, wie der Entwickler. Der Leser möchte von vornherein

Mehr leisten in höherer Qualität

Erwartungen unserer Zielgruppen



die Gebrauchsanleitung so schnell wie möglich wieder beiseitelegen. Und diesem Wunsch kommen gleichförmige Formulierungsmuster und eine gleichförmige Inhaltsstruktur sehr entgegen. Der Leser kann sich dadurch intuitiv auf diese Gleichförmigkeit einstellen. Er erkennt das „Schema F“ und kann schnell die gesuchte Information finden, verstehen und umsetzen.

Dass alle anderen Kapitel genauso formuliert, strukturiert und gestaltet sind, erzeugt keine Langeweile. Denn unsere Informationsprodukte werden typischerweise nicht von der ersten bis zur letzten Seite durchgelesen. Und wenn doch, dann weiß der Leser immer noch, dass er eine Gebrauchsanleitung liest – eine Textsorte, bei der gerade Gleichförmigkeit und Eindeutigkeit erwünscht sind.

3.3 Standardisieren der Effizienz zuliebe

3.3.1 Die Bedeutung von Software-Algorithmen

Dank Standardisierung können auch in erheblichem Maße Kosten und Zeit eingespart werden, weil mehr Arbeit von Software-Algorithmen erledigt werden kann.

Algorithmen sind bekanntlich relativ dumm: Sie arbeiten entsprechend ihrer Programmierung lediglich Zeichenketten ab. Solange diese Zeichenketten in einem gleichförmigen Muster vorliegen, können Algorithmen rund um die Uhr arbeiten. Doch wehe, eine Zeichenkette weicht vom erwarteten, bei der Programmierung berücksichtigten Muster ab. Dann muss der Mensch eingreifen – was erhöhte Kosten verursacht und fehleranfällig ist.

Sehr deutlich wird dies am Beispiel von Translation-Memory-Systemen (TMS), zu Deutsch etwa Übersetzungsspeicher. Wie bereits erwähnt, ist das Senken von Übersetzungskosten für Unternehmen oft eines der wichtigsten Argumente, in professionelle technische Dokumentation zu investieren. TMS spielen hierbei eine zentrale Rolle. Schauen wir uns die Funktionsweise eines TMS daher einmal näher an:



3.3.2 Das Funktionsprinzip eines TMS

Ausgangssituation

Die Grundfunktion eines TMS ist es, Übersetzungspaare zu speichern. Ein Übersetzungspaar besteht aus einem Textschnipsel in einer Ausgangssprache und seiner Entsprechung in einer Zielsprache. Übersetzen muss weiterhin der Übersetzer. Einmal getätigte Übersetzungen werden jedoch vom TMS gespeichert und können künftig wiederverwendet werden, wenn ein Text wiederholt vorkommt.

Angenommen, ein Übersetzer erhält den Auftrag, die Gebrauchsanleitung zu Produkt A von Deutsch nach Englisch zu übersetzen. Der Übersetzer importiert die Gebrauchsanleitung in sein TMS. Da es der erste Auftrag zu dieser Art von Produkten ist, ist die Datenbank des TMS leer (vereinfacht ausgedrückt). Noch hat der Übersetzer deshalb zwar kaum einen Nutzen von dem TMS, doch im TMS finden bereits wichtige Schritte statt:

1. Beim Importieren der Gebrauchsanleitung zerlegt das TMS deren Inhalt automatisch in Segmente. Segmente sind Sätze, Tabellenzeilen, Listenpunkte, ganze Abschnitte oder dergleichen.

2. Der Übersetzer übersetzt im TMS die einzelnen Segmente. Den deutschen Satz …

„Windkraftanlagen lassen sich nach ihrer Rotationsachse in zwei Bauformen untergliedern.“

… übersetzt er beispielsweise ins Englische:

„Wind turbines can be separated into two types based by the axis in which the turbine rotates.”

3. Den deutschen Satz und seine englische Übersetzung speichert das TMS als Übersetzungspaar ab.

<uebersetzungspaar> <de>Windkraftanlagen lassen sich nach ihrer Rotationsachse in zwei Bauformen untergliedern.</de> <en>Wind turbines can be separated into two types based by the axis in which the turbine rotates.</en> </uebersetzungspaar>



Die Bedienoberfläche eines TMS sieht etwa wie folgt aus:

Abbildung 8: Translation-Memory-System across (Sousa 2013)

Nachdem der Übersetzer alle Segmente fertig übersetzt hat, exportiert er aus dem TMS ein Word-Dokument in der Zielsprache. Dabei werden alle Segmente – jetzt in der Zielsprache – in diesem Dokument wieder zusammengeführt.

Wiederverwenden von Übersetzungen

Nehmen wir an, der Auftraggeber möchte nun eine etwas abgewandelte Variante seines Produktes auf den Markt bringen. Er erstellt auf Basis der Gebrauchsanleitung für Produkt A eine neue Gebrauchsanleitung für Produkt B. So wie die beiden Produkte sind sich folglich auch die beiden Gebrauchsanleitungen sehr ähnlich.

Der Auftraggeber sendet die deutsche Gebrauchsanleitung B wieder dem Übersetzer. Der Übersetzer importiert sie in sein TMS – und kann nun viel Aufwand einsparen. Folgendes passiert:

1. Während des Imports zerlegt das TMS den Inhalt wieder in Segmente.



2. Das TMS prüft, ob die Segmente so oder ähnlich bereits übersetzt wurden. Beispielsweise stößt das TMS in Gebrauchsanleitung B auf den Satz …

“Windkraftanlagen lassen sich nach ihrer Rotationsachse in zwei Bauformen untergliedern.”

… und stellt fest, dass für diesen Satz bereits eine englische Übersetzung gespeichert ist, nämlich:

„Wind turbines can be separated into two types based by the axis in which the turbine rotates.“

3. Das TMS zeigt dem Übersetzer diese Übereinstimmung an. Der Übersetzer kann die frühere Übersetzung mit einem Klick übernehmen, anstatt den Satz neu zu übersetzen. Dem Auftraggeber berechnet er nicht den vollen Preis für die Übersetzung eines Satzes, sondern nur einen Bruchteil davon.

Fuzzy-Matches

Soweit der Idealfall. Doch was passiert, wenn im TMS ein Segment gespeichert ist, das nur so ähnlich ist wie das aktuell zu übersetzende Segment? Die Algorithmen eines TMS können solche nur teilweisen Übereinstimmungen erkennen. Man spricht hier von „Fuzzy-Matches“ (gegenüber „Exact-Matches“ bei genauer Übereinstimmung). „Fuzzy-Match“ bedeutet etwa „ungenauer Treffer“. Die Schwelle, bis zu der ein TMS solche Fuzzy-Matches anzeigt, wird meistens auf etwa 80 % festgelegt. Bei geringerer Übereinstimmung lohnt es sich nicht, erst eine vorhandene Übersetzung zu beurteilen, sondern der Übersetzer übersetzt gleich neu.

Mithilfe von Fuzzy-Matches kann zwar bereits ein bedeutender Teil der Übersetzungskosten eingespart werden. Es entstehen jedoch deutlich höhere Kosten als bei Exact-Matches. Nicht standardisierte, variantenreiche Formulierungen führen bei Übersetzungen somit zu Mehrkosten.

Angenommen, ein Technischer Redakteur hat in Gebrauchsanleitung B nicht „Windkraftanlagen“ geschrieben, sondern „Windenergieanlagen“, ein klassischer Fall von terminologischer Inkonsistenz:

“Windenergieanlagen lassen sich nach ihrer Rotationsachse in zwei Bauformen untergliedern.”



Inhaltlich sind „Windkraftanlagen“ und „Windenergieanlagen“ identisch, also synonym. Das TMS wird jedoch keinen Exact-Match anzeigen, sondern nur einen Fuzzy-Match oder gar keinen Match, wodurch unnötige Mehrkosten entstehen.

3.3.3 Rechenbeispiel für die Einsparung durch ein TMS

Für das nachfolgende Rechenbeispiel nehmen wir Folgendes an:

• deutscher Ausgangstext mit 5.000 Zeilen (je 55 Zeichen)

• Übersetzung DE-EN Neuübersetzung: 0,90 €/Zeile

• Übersetzung DE-EN Fuzzy-Matches: 0,40 €/Zeile

• Übersetzung DE-EN Exact-Matches: 0,10 €/Zeile

• Die Gebrauchsanleitungen A und B sind im Prinzip zu 90 % identisch.

Rechenbeispiel (vereinfacht):

• Ganz ohne TMS würden bei jeder Übersetzung die vollen Kosten anfallen:

• 5.000 x 0,90 € (Neuübersetzungen) = 4.500 €

• Mit TMS, aber vielen Inkonsistenzen im Ausgangstext, könnten beispielsweise folgende Kosten anfallen:

• 1.000 x 0,90 € (Neuübersetzungen) = 900 €

• 3.000 x 0,40 € (Fuzzy-Matches) = 1.200 €

• 1.000 x 0,10 € (Exact-Matches) = 100 €

• gesamt = 2.200 €

• Mit TMS und vorbildlicher Konsistenz könnten die Kosten nochmals drastisch sinken:

• 300 x 0,90 € (Neuübersetzungen) = 270 €

• 200 x 0,40 € (Fuzzy-Matches) = 80 €

• 4.500 (90 % der Sätze) x 0,10 € (Exact-Matches) = 450 €

• gesamt = 800 €

Sie sehen, dass Konsistenz sich tatsächlich lohnen kann. Skalieren Sie das obige Rechenbeispiel gedanklich einmal auf 10 Produktvarianten und 20 Sprachen. Und bedenken Sie, dass Deutsch-Englisch nur das günstigste Sprachpaar ist; Sprachpaare wie Deutsch-Chinesisch,



Deutsch-Japanisch usw. können leicht das Doppelte oder Dreifache kosten.

Bei Übersetzungen wird der Nutzen von Konsistenz oft am deutlichsten, aber auch in anderen Zusammenhängen sind Konsistenz und Standardisierung in der technischen Dokumentation unbedingt anstrebenswert.

Übrigens: Mithilfe von Modularisierung könnten auch die Kosten für Exact-Matches weitgehend eingespart werden, indem der Übersetzer nur noch Kapitel oder Abschnitte erhält, die tatsächlich geändert wurden.

3.4 Lernkontrolle Sehr gut! Auch das zweite Inhaltskapitel haben Sie geschafft. Verstehen Sie (spätestens) jetzt, weshalb Standardisierung in der technischen Dokumentation so wichtig ist? Überprüfen Sie es gleich einmal anhand dieser drei Fragen:

1. Welche Probleme können entstehen, wenn in einer Gebrauchsanleitung ähnliche Informationen (z. B. Handlungsaufforderungen) unterschiedlich dargestellt sind (Formulierung, Strukturierung, Gestaltung)?

2. Wie funktioniert ein Translation-Memory-System (TMS)?

3. Weshalb verursachen inkonsistente Formulierungen erhöhte Übersetzungskosten?

Methoden und Hilfsmittel zum Standardisieren von technischer Dokumentation


4 Methoden und Hilfsmittel zum Standardisieren von technischer Dokumentation

In diesem Kapitel lernen Sie einige Methoden und Hilfsmittel kennen, mit denen zentrale Aspekte der technischen Dokumentation standardisiert werden können.

4.1 Standardisieren der Inhaltsstruktur Die Standardisierung der Strukturen, in denen Inhalte erfasst werden, ist für technische Dokumentation von großer Bedeutung – neben der Standardisierung der Inhalte selbst. Folgende Werkzeuge und Methoden bieten sich an, um eine möglichst konsistente Inhaltsstruktur zu erhalten:

4.1.1 XML-basierte Inhaltsstrukturen

Mit XML können nahezu beliebige Inhaltsstrukturen erstellt werden. Die Einhaltung der Strukturen durch die Autoren kann erzwungen werden, was zu einem hohen Maß an Konsistenz führt.

Ein Beispiel für eine frei erfundene Inhaltsstruktur: <modul>

<titel>Drucker anschließen</titel> <einleitung>In diesem Kapitel lernen Sie …</einleitung> <handlsequenz> <schritt>Netzkabel an Steckdose anschließen.</schritt> <schritt>USB-Kabel an Drucker anschließen.</schritt> <schritt>USB-Kabel an Rechner anschließen.</schritt> </handlsequenz> </modul>

Mit sogenannten Document Type Definitions (DTDs) oder Schema-Definitionen kann genau festgelegt werden, an welcher Stelle welche Elemente stehen dürfen oder müssen. Hierzu ein exemplarischer Ausschnitt aus einer DTD, mit der die Inhaltsstruktur aus dem vorhergehenden Beispiel definiert werden könnte:

<!ELEMENT modul (titel,einleitung?,handlsequenz)> <!ELEMENT handlsequenz (schritt+)>

Beispiel

Strukturdefinition mit DTD und Schema

Beispiel



Die erste Zeile dieser DTD sagt aus:

• Es gibt ein Element namens modul.

• Innerhalb des Elements modul …

• … muss einmal das Element titel vorkommen

• … darf einmal das Element einleitung vorkommen

• … muss einmal das Element handlsequenz vorkommen

• … und zwar in genau dieser Reihenfolge

Die zweite Zeile der DTD sagt aus:

• Es gibt ein Element namens handlsequenz.

• Innerhalb des Elements handlsequenz muss mindestens einmal das Element schritt vorkommen.

Die oben aufgeführten XML- und DTD-Beispiele sind zwar sehr technisch. Als schreibender Technischer Redakteur kommt man nur selten mit dieser Syntax in Berührung. Dennoch ist es sinnvoll, das Prinzip von XML zu kennen, denn in der modernen technischen Dokumentation kommt XML in vielen Zusammenhängen zum Einsatz.

Für technische Dokumentation gibt es vorgefertigte, standardisierte Inhaltsstrukturen, sogenannte Informationsmodelle. Das bekannteste Informationsmodell ist DITA. Weitere Informationen über Informationsmodelle siehe Kapitel 7 „Weitere Standardisierungsmethoden und Informationsmodelle“ ab Seite 107.

Die Verwendung solcher Informationsmodelle hat gegenüber selbst entwickelten Inhaltsstrukturen wichtige Vorteile:

• Zeitersparnis: Informationsmodelle sind sofort anwendbar, sie brauchen nicht erst entwickelt zu werden. Dabei sollte nicht nur die Entwicklung des Informationsmodells selbst betrachtet werden, sondern auch die Entwicklung von Skripten (XSLT usw.), um beispielsweise HTML-Seiten oder PDF-Dokumente zu erzeugen.

• einfacherer Informationsaustausch: Unternehmen/Organisationen, die die gleichen Informationsmodelle verwenden, können einfacher Informationen miteinander austauschen. Denken Sie beispielsweise an Zulieferer im Maschinen- und Anlagenbau.

Informationsmodelle



• Standard-Redaktionssysteme verfügbar: In vielen Redaktionssysteme sind bereits ein oder mehrere Informationsmodelle standardmäßig implementiert. Somit entfallen die Kosten für die sonst notwendige unternehmensspezifische Implementierung.

• Austauschbarkeit der Autorenumgebung: Ein Unternehmen ist nicht aufgrund einer speziellen Inhaltsstruktur an ein Redaktionssystem oder einen Editor gebunden. Die Inhalte können relativ einfach in ein anderes System überführt werden, in dem das gleiche Informationsmodell implementiert ist.

(vgl. Ziegler/Krüger 2014, 14 f.)

4.1.2 Standardisierungsmethoden

Neben Informationsmodellen wie DITA gibt es allgemeine Standardisierungsmethoden, die unabhängig von XML und anderen Auszeichnungssprachen sind. Diese Standardisierungsmethoden lassen sich jedoch sehr gut mit Auszeichnungssprachen kombinieren.

Die bekannteste Standardisierungsmethode in der technischen Dokumentation ist das Funktionsdesign®. Dabei handelt es sich um ein Framework, einen Rahmen, mit dem eigene Inhaltsstrukturen entwickelt werden können. Das Funktionsdesign® stellt nur allgemeine Anforderungen an die Struktur (sowie an den Inhalt und an die Formulierungsweise) von Informationen. Auf dieser Basis entwickelte Inhaltsstrukturen können beispielsweise mit Formatvorlagen in MS Word oder mit XML technisch umgesetzt werden.

Ausführliche Informationen zum Funktionsdesign® siehe Kapitel 6 „Standardisierungsmethode Funktionsdesign“ ab Seite 76.

4.1.3 Normen und Richtlinien

Inhaltsstrukturen können auch mithilfe von Normen und Richtlinien standardisiert werden. Richtlinien, wie zum Beispiel die EU-Maschinenrichtlinie, sind je nach Produktart und Zielmarkt sogar verpflichtend.

Einige Normen und EU-Richtlinien machen Vorgaben zum Inhalt von technischer Dokumentation. Sie beeinflussen und vereinheitlichen somit die Inhaltsstruktur von Informationsprodukten. Innerhalb bestimmter Branchen, wie beispielsweise dem Maschinen- und



Anlagenbau, sind die technischen Dokumentationen der meisten Hersteller deshalb sehr ähnlich bezüglich der Inhaltsstruktur.

Weitere Ausführungen zu den inhaltlichen Vorgaben von Normen und Richtlinien siehe Kapitel 2.9 „Inhalt von technischer Dokumentation“ ab Seite 30.

4.1.4 Strukturebenen

Die Hilfsmittel und Methoden in den Kapiteln 4.1.1 bis 4.1.3 beziehen sich auf unterschiedliche Ebenen von Inhaltsstrukturen. Nachfolgend soll deshalb verdeutlicht werden, auf welchen Strukturebenen die Hilfsmittel und Methoden typischerweise Anwendung finden.

Tabelle 3: Ebenen von Inhaltsstrukturen

Strukturebene Beispiel Hilfsmittel/Methode zur Standardisierung

gesamte technische Dokumentation, informationsprodukt-übergreifend

Untergliederung der technischen Doku-mentation in eine Betriebsanleitung, eine Wartungsanleit-ung und eine Montageanleitung

Standardisierungs-methode

Grobstruktur eines Informationspro-dukts

Kapitel „Allgemeine Sicherheitshinwei-se“, „Transport“, „Inbetriebnahme“ usw.

Standardisierungs-methode, Normen, Richtlinien

Feinstruktur eines Informationspro-dukts, Struktur einzelner Kapitel

Struktur eines handlungsorientier-ten Kapitels = Kapiteleinleitung, Handlungsvoraus-setzungen, Hand-lungssequenz, Ergebnis

Standardisierungs-methode, XML, Normen, Richtlinien

Struktur einzelner Informationseinhei-ten

Beispiel: Struktur von Warnhinweisen = Signalwort, Art und Quelle der Gefahr, mögliche Folgen, Maßnahmen zur Gefahrenvermei-dung

Standardisierungs-methode, XML, Normen, Richtlinien



4.2 Standardisieren der Sprache Für das Standardisieren der Sprache in technischer Dokumentation ist die Einführung einer Standardisierungsmethode der erste, wesentliche Schritt (siehe Kapitel 4.1.2 „Standardisierungsmethoden“, Seite 46). Doch für konsistentes Vokabular, konsistenten Satzbau und konsistente Formulierungsmuster kann noch mehr getan werden:

4.2.1 Terminologiemanagement

Im Rahmen von Terminologiemanagement werden die Bedeutungen von Benennungen definiert. Anschließend wird für jede Bedeutung festgelegt, welche Benennung zu verwenden ist (innerhalb einer Sprache), alle Synonyme werden als nicht erlaubt eingestuft. Der Nutzen ist eine ein-eindeutige Verwendung von Benennungen:

• jede Benennung hat genau eine Bedeutung (keine Ambiguitäten bzw. Homonyme/Polyseme)

• jede Bedeutung wird mit genau einer Benennung (je Sprache) benannt (keine Synonyme)

Mehrdeutigkeiten bei der Verwendung von Benennungen werden somit ausgeschlossen.

Beispiel für Ambiguität:

Benennung „Wurzel“ hat Bedeutungen im Sinne von „Baumwurzel“ und im Sinne von „Zahnwurzel“

Beispiel für Synonym:

Benennungen „Schaltfläche“ und „Button“ haben dieselbe Bedeutung

Zur Unterstützung von Terminologiemanagement gibt es spezielle Software, sogenannte Terminologiemanagement-Systeme. Einer der bekanntesten Vertreter dieser Art von Software ist SDL MultiTerm:

-Anzeige- Seminare zum Thema Terminologiemanage-ment finden Sie auf www.technische-dokumentation.org.

Beispiele Mehrdeutigkeiten

https://www.technische-dokumentation.org/




Abbildung 9: SDL MultiTerm (Cornillie Consulting 2015)

4.2.2 Kontrollierte Sprache

Wesentlich umfassender als Terminologiemanagement sind kontrollierte Sprachen. Sie setzen Terminologiemanagement voraus, betrachten aber nicht nur die Benennungen (Terminologie) eines Fachgebietes, sondern die gesamte Fachsprache eines Fachgebietes.

Eine kontrollierte Sprache basiert auf einer natürlichen Sprache, beispielsweise auf Englisch. Die Vielfalt des Wortschatzes und der grammatischen Möglichkeiten ist jedoch stark eingeschränkt oder ganz abgeschafft. Der Wortschatz ist auf das Nötigste reduziert und für jedes zulässige Wort ist genau definiert, was es bedeutet und in welcher Form es verwendet werden darf.

Die bekannteste kontrollierte Sprache ist Simplified Technical Englisch (ASD-STE100). Das Regelwerk umfasst ca. 370 Seiten und enthält die beiden Teile „Writing Rules“ (Schreibregeln) und „Dictionary“ (Wörterbuch).

Nachfolgend einige Ausschnitte aus dem Regelwerk und aus dem Wörterbuch von Simplified Technical English (Stand 2013):

Simplified Technical English



Words (Wörter)

Abbildung 10: ASD-STE100, Words (ASD 2013)

Noun phrases (Substantivkomposita)

Abbildung 11: ASD-STE100, Noun phrases (ASD 2013)

Verbs (Verben)

Abbildung 12: ASD-STE100, Verbs (ASD 2013)

Sentences (Sätze)

Abbildung 13: AST-STE100, Sentences (ASD 2013)



Procedures (Handlungsabläufe)

Abbildung 14: ASD-STE100, Procedures (ASD 2013)

Descriptive writings (Beschreibungen)

Abbildung 15: ASD-STE100, Descriptive wirtings (ASD 2013)

Warnings, cautions, and notes (Warnhinweise und Sicherheitshinweise)

Abbildung 16: ASD-STE100, Warnings, cautions, and notes (ASD 2013)

Punctuation and word counts (Zeichensetzung und Wortzählung)

Abbildung 17: ASD-STE100, Punctuation and word counts (ASD 2013)



Writing practices (sonstige Schreibregeln)

Abbildung 18: ASD-STE100, Writing practices (ASD 2013)

Dictionary (Wörterbuch)

Erläuterungen:

• In der 1. Spalte der Tabelle sind nicht erlaubte Wörter kleingeschrieben, erlaubte Wörter sind großgeschrieben.

• In der 2. Spalte sind erlaubte alternative Wörter großgeschrieben.

Abbildung 19: ASD-STE100, Dictionary (ASD 2013)

Kontrollierte Sprache vs. gesteuerte Sprache

Die deutsche Benennung „kontrollierte Sprache“ ist von der englischen Benennung „controlled language“ abgeleitet. In der Fachliteratur wird die deutsche Lehnübersetzung zum Teil als



irreführend bezeichnet (vgl. Baumert/Verhein-Jarren 2012, 149). Denn „to control“ bedeutet nicht nur „kontrollieren“, sondern auch „steuern“ und „einschränken“.

Wie aus den oben aufgeführten Beispielen des Simplified Technical English hervorgeht, wird in einer kontrollierten Sprache nichts kontrolliert. Vielmehr handelt es sich um eine Einschränkung oder detaillierte Steuerung einer natürlichen Sprache. Insofern wären die Benennungen „eingeschränkte Sprache“ oder „gesteuerte Sprache“ treffender. Die Fachliteratur schlägt „gesteuerte Sprache“ vor. „Kontrollierte Sprache“ ist bisher jedoch die wesentlich geläufigere Benennung.

4.2.3 Sprachkontrollsystem

Mit zunehmender Anzahl von Regeln, die von den Technischen Redakteuren berücksichtigt werden müssen, wird der Einsatz spezieller Software zum Durchsetzen all dieser Regeln notwendig: sogenannte Controlled-Language-Checker bzw. Sprachkontrollsysteme.

Abbildung 20: Sprachkontrollsystem acrolinx eingebunden in MS Word (Acrolinx 2013)

In Sprachkontrollsystemen können sehr komplexe grammatische, orthografische, stilistische und Terminologie-Regeln hinterlegt werden. Auch die Regeln einer kontrollierten Sprache können in Sprachkontrollsystemen abgebildet werden. Texte können dann auf



Knopfdruck gegen all diese Regeln geprüft werden. Das Sprachkontrollsystem ist hierzu in die Autorenumgebung integriert, zum Beispiel in das Redaktionssystem oder in einen Editor wie MS Word®. Bei Fehlern können mit wenigen Klicks Änderungsvorschläge des Systems übernommen werden, siehe zum Beispiel das Kontextmenü in Abbildung 20.

4.3 Standardisieren der Gestaltung

4.3.1 Trennung von Inhalt und Layout

Bevor wir uns mit der Gestaltung von Inhalten beschäftigen, sollten wir zunächst lernen, die Gestaltung getrennt vom Inhalt zu betrachten. Die Trennung von Inhalt und Layout ist ein sehr wichtiges Prinzip der modernen technischen Dokumentation. Diese Trennung ist die Voraussetzung, um sauber mit Formatvorlagen oder Stylesheets arbeiten zu können und erleichtert wesentlich die konsistente, standardisierte Gestaltung von Informationsprodukten.

Trennung von Inhalt und Layout bedeutet, dass der Inhalt mit keinerlei Layoutinformationen versehen wird. Der Inhalt wird lediglich ausgezeichnet, das heißt, zum Beispiel eine Überschrift wird als solche gekennzeichnet. Mit XML könnte das so aussehen:

<ueberschrift>Trennung von Inhalt und Layout</ueberschrift>

(Das Tag „ueberschrift“ ist frei erfunden.) Das Layout wird separat definiert und aus dem Inhalt ausgelagert. Mit der Layoutsprache „Cascading Stylesheets“ (CSS) sieht das beispielsweise so aus:

ueberschrift {font-size:18pt; font-weight:bold; color:blue;}

Das Ergebnis ist die Überschrift „Trennung von Inhalt und Layout“ in Schriftgröße 18 Punkt, fettem Schriftschnitt und in Blau.

Angenommen, für die Ausgabe auf Smartphone-Bildschirmen soll die Schriftgröße aller Überschriften in einem Dokument von 18 auf 12 Punkt verringert werden. Ohne die Trennung von Inhalt und Layout – also bei direkt formatiertem Inhalt – müsste der Autor das betreffende Dokument öffnen, jede einzelne Überschrift mit dem Mauszeiger markieren und die Schriftgröße ändern. Dieses Vorgehen wäre aus mehreren Gründen schlecht:

• Es wäre sehr zeitaufwendig, denn jede Überschrift müsste einzeln formatiert werden.

Nachteile von Direktformatierung



• Es wäre fehleranfällig, denn der Autor könnte z. B. Überschriften übersehen oder eine falsche Schriftgröße wählen.

• Es würde die Vielfalt von Dokumentvarianten noch größer und unübersichtlicher machen, denn nun gäbe es nicht nur Dokumentvarianten je nach Produktvariante und Sprache, sondern auch noch je nach Ausgabemedium.

Der letzte Punkt bedarf weiterer Erläuterungen: Angenommen, Sie müssen Gebrauchsanleitungen für zwei Produktvarianten in zwei Sprachen erstellen. Das Ergebnis wären 4 Varianten einer Gebrauchsanleitung:

• Produkt „Super 8002“, deutsch

• Produkt „Super 8002“, englisch

• Produkt „Super 8004“, deutsch

• Produkt „Super 8004“, englisch

Wenn Sie nun auch noch manuell unterschiedliche Layoutvarianten erstellen müssten, wären es schon acht Varianten einer Gebrauchsanleitung:

• Produkt „Super 8002“, deutsch, Layout a

• Produkt „Super 8002“, deutsch, Layout b

• Produkt „Super 8002“, englisch, Layout a

• Produkt „Super 8002“, englisch, Layout b

• Produkt „Super 8004“, deutsch, Layout a

• usw.

Es ist kaum vorstellbar, auf diese Weise zum Beispiel 20 Produktvarianten in 30 Sprachen zu handhaben. Wenn dann die Marketingabteilung die Designrichtlinien ändert und alle Überschriften nicht mehr blau, sondern türkis sein sollen; oder wenn aufgrund neuer Erkenntnisse bestimmte Warnhinweise eingefügt oder verändert werden sollen … viel Spaß bei den Überstunden!

4.3.2 Formatvorlagen in MS Word, FrameMaker & Co.

Das Auslagern von Layoutinformationen geschieht in MS Word und anderen Schreib- oder DTP-Programmen mithilfe von Formatvorlagen.



Falls Sie nicht genau wissen, was Formatvorlagen sind und wie sie in MS Word erstellt werden können, lesen Sie bitte zunächst in der Hilfe von MS Word nach: https://goo.gl/E1ADH7 (gekürzte Adresse)

Abbildung 21: Liste der Formatvorlagen in MS Word und Zuordnung einer Formatvorlage zu einem Absatz

Abbildung 22: Formatvorlage einrichten in MS Word

Betrachten wir zum Beispiel die Formatvorlage „.Abbildung Titel“, siehe Abbildung 22. Alle Abbildungstitel eines Dokuments werden mit dieser Formatvorlage ausgezeichnet. Müssen nachträglich beispielsweise die Abstände unter allen Abbildungstiteln vergrößert werden, dann braucht diese Änderung nur einmal in der Formatvorlage „.Abbildung Titel“ vorgenommen zu werden. Dieser Vorgang dauert etwa 20 Sekunden, beim Ausprobieren unterschiedlicher Abstände vielleicht einige Minuten. Eine enorme Zeitersparnis ist das Ergebnis – und obendrein eine zuverlässige Konsistenz. Denn: Wenn tatsächlich alle Abbildungstitel mit der

Beispiel

https://goo.gl/E1ADH7



Formatvorlage „.Abbildung Titel“ ausgezeichnet wurden, dann haben auch wirklich alle Abbildungstitel die gleichen Abstände.

Ganz bewusst habe ich im vorherigen Satz betont: „Wenn tatsächlich […] mit der Formatvorlage […] ausgezeichnet wurden“. Denn Voraussetzung dafür, dass die Vorteile der Trennung von Inhalt und Layout genutzt werden können, ist eine disziplinierte, konsequente Auszeichnung aller Inhalte. Nur wenn Sie als Autor beispielsweise Abbildungstitel als solche kennzeichnen, kann die Software diese Textpassagen automatisch korrekt gestalten.

Die Notwendigkeit, Inhalte sauber auszuzeichnen, sollten Sie als Technischer Redakteur unbedingt verinnerlichen! Sie ist ein wichtiger Bestandteil von strukturierter, standardisierter technischer Dokumentation. Eine saubere Auszeichnung von Inhalten spielt in der modernen technischen Dokumentation in mehreren Zusammenhängen eine wesentliche Rolle.

Die Layouteinstellungen der Formatvorlagen können bei Bedarf einfach ausgetauscht werden. In MS Word verwendet man hierzu unterschiedliche Dokumentvorlagen. Alle Dokumentvorlagen müssen die gleichen Formatvorlagen enthalten, aber mit unterschiedlichen Layouteinstellungen.

Abbildung 23: Dokumentvorlagen austauschen in MS Word

4.3.3 Stylesheets

Für Stylesheets gilt im Wesentlichen das gleiche, wie im Kapitel 4.3.2 „Formatvorlagen in MS Word, FrameMaker & Co.“ für Formatvorlagen

Disziplin notwendig!

Dokumentvorlagen



ausgeführt wurde. Stylesheets sind lediglich eine andere technische Umsetzung.

Die Zuweisung von Stylesheets bzw. Layoutdefinitionen zu Inhalten kann technisch, je nach Editor oder Redaktionssystem, sehr unterschiedlich funktionieren. In XML-Schreibweise, die einem Technischen Redakteur aber normalerweise verborgen bleibt, sieht die Zuweisung eines Stylesheets zu einem XML-Dokument beispielsweise so aus wie in Abbildung 24, Zeile 2:

Abbildung 24: Zuweisung eines Stylesheets zu einem XML-Dokument

Im Beispiel wird dem XML-Dokument ein Cascading Stylesheet (CSS) zugeordnet. Beim Aufruf des XML-Dokuments in einem Browser wird das CSS gelesen und auf die XML-Elemente angewendet. Das Ergebnis könnte beispielsweise so aussehen:

Abbildung 25: Gestaltung eines XML-Dokuments durch CSS

Beachten Sie, dass auch die Nummerierung der Handlungsaufforderungen erst durch das Stylesheet erzeugt wird. Im XML-Dokument selbst (Abbildung 24, Elemente „schritt“ in Zeilen 17-18) ist keine Nummerierung enthalten. Dadurch ist es kein Problem, wenn einzelne Schritte entfallen, beispielsweise bei bestimmten



Produktvarianten. Die Nummerierung braucht nicht manuell korrigiert zu werden.

Um den Inhalt des XML-Dokuments mit einem anderen Layout darzustellen, braucht nur ein anderes Stylesheet angegeben zu werden (Abbildung 24, Zeile 2, Attribut „href“).

4.3.4 Cross-Media-Publishing

Die Vorgehensweise, ein Informationsprodukt für unterschiedliche Ausgabemedien und/oder in unterschiedlichen Layouts zu publizieren, wird „Cross-Media-Publishing“ genannt. Ausgabemedien können beispielsweise sein: PDF für den Druck, PDF für die Anzeige im Browser, Onlinehilfe, App für Smartphone oder Tablet.

4.3.5 Normen

Auch beim Standardisieren der Gestaltung können Normen nützlich sein. Die bekannte „Doku-Norm“ DIN EN 82079-1 (2013) beschäftigt sich in Kapitel 6 „Gestaltung von Gebrauchsanleitungen“ mit Themen wie Schriftgröße, Farben und grafische Symbole. Zum Beispiel: „Bei der Farbgebung muss berücksichtigt werden, dass Farben gewählt werden, die auch bei Schwarz-Weiß-Fotokopien oder dem Ausdrucken auf einem Monochrom-Drucker unterscheidbar sind.“ (Beuth 2013, 43)

4.4 Standardisieren von Abbildungen

4.4.1 Technische Eigenschaften von Abbildungen

Auch für Abbildungen sollten einheitliche Standards angewendet werden, zum Beispiel hinsichtlich folgender Aspekte:

Tabelle 4: technische Eigenschaften von Abbildungen

Eigenschaft-en

Beispiele Anmerkungen

Art der Abbildung

Foto, Illustration oder gerendertes Bild

Fotos sind im Allgemei-nen am einfachsten herzustellen, haben aber oft einen zu hohen Detailgrad und erfordern oft Retusche. Falls im Unternehmen bereits CAD-Daten vorhanden sind, sind viele Möglich-



keiten offen, z. B. von CAD-Modell abgeleitete Illustrationen, foto-realistische Bilder, Explosionszeichnungen usw.

Auflösung 90 dpi für Bildschirmausgabe, 300 dpi für Druckausgabe

Originalabbildung mit möglichst hoher Auf-lösung archivieren, damit bei Bedarf weitere Auflösungsvarianten erzeugt werden können

Abmessungen

maximale Höhe und maximale Breite von Abbildungen

Dateiformat JPG (pixelbasiert und verlustbehaftet), TIF (pixelbasiert und verlustfrei) oder SVG (vektorbasiert und verlustfrei)

SVG basiert auf XML und ist nur für Illustrationen bzw. nicht fotorealistische Abbildungen geeignet

4.4.2 Positionsnummern und Positionslinien

In Abbildungen werden oft Geräteteile o. ä. bezeichnet, so wie in Abbildung 26:

Abbildung 26: Positionsnummern und Positionslinien (eRockit 2012)

Argumente für Positionsnummern und Legenden

Aus folgenden Gründen ist es in der technischen Dokumentation Standard, Teilebenennungen nicht direkt in Abbildungen zu schreiben,



sondern stattdessen mit Positionsnummern und Legenden zu arbeiten:

• Abbildungen werden übersichtlicher

• Abbildungen enthalten weniger textuellen Inhalt.

• Teilebenennungen müssen nicht irgendwo in der Abbildung gesucht werden, sondern sie stehen übersichtlich in der Legende. Die zugehörigen Positionsnummern sind in der Abbildung logisch angeordnet, z. B. der Reihe nach im Uhrzeigersinn.

• Teilebenennungen können einfacher gepflegt werden

• Die Änderung einer Teilebenennung muss nur in der Legende vorgenommen zu werden, die Abbildung braucht nicht bearbeitet zu werden.

• Teilebenennungen können einfacher übersetzt werden

• Die Abbildungen selbst bleiben sprachneutral (außer Bildschirmfotos von Software), es entstehen keine Sprachvarianten je Abbildung.

• Übersetzer übersetzen Teilebenennungen nicht aufwendig im Bildbearbeitungsprogramm, sondern im ihrem Translation-Memory-System .

Gestaltung von Positionslinien

Positionslinien müssen von dem eigentlichen Gegenstand der Abbildung deutlich zu unterscheiden sein. Deshalb sollten Positionslinien wie folgt gestaltet werden:

• Farbe Schwarz

• ausreichende Dicke der Linien (vgl. Abbildung 26)

• keine Haarlinien, sondern etwa 0,5 bis 0,8 mm

• Positionslinien dicker als Linien der Illustration

• weiße Kontur (vgl. Abbildung 27)

• dadurch klare Abgrenzung von den Linien einer Illustration

• gute Sichtbarkeit der Positionslinie auch auf dunklen Flächen

• Positionslinie direkt auf das zu benennende Teil ziehen, nicht kurz davor enden lassen (vgl. Abbildung 27)



• dadurch unmissverständlich, welches Teil gemeint ist

• bei sehr kleinen Teilen, die durch Positionslinien überdeckt werden, mit Vergrößerungsausschnitten arbeiten

• immer gleichen, relativ flachen Winkel

• Winkel z. B. 15°, dadurch Unterscheidung von den 30°-Linien einer isometrischen Darstellung

• sauberes, übersichtliches Aussehen

• gleichmäßige Position der Linienenden (vgl. Abbildung 26)

• die Positionsnummern an den Enden der Positionslinien sollen möglichst auf einer Linie oder in einer Spalte stehen, nicht durcheinander; die Länge der Positionslinien kann entsprechend variieren

Abbildung 27: Positionslinie mit weißer Kontur, vergrößerter Ausschnitt aus Abbildung 26 (eRockit 2012)

Reihenfolge von Positionsnummern

Positionsnummern sollen in einer Abbildung in der logischen Zahlenreihenfolge, möglichst im Uhrzeigersinn stehen (vgl. Abbildung 26). Dies erleichtert dem Leser das Finden einzelner Positionsnummern.

In folgendem Negativbeispiel sind die Positionsnummern durcheinander angeordnet. Dadurch lässt sich eine bestimmte Positionsnummer nur schwer finden:



Abbildung 28: unübersichtliche Reihenfolge der Positionsnummern (Boca 2006)

4.5 Standardisieren der Prozesse Auch die Prozesse, nach denen die Informationsprodukte erstellt werden, sollten standardisiert werden. So ist eher eine gleichbleibend hohe Qualität gewährleistet, auch über einen längeren Zeitraum und im Team. Zudem erleichtert dies die Einarbeitung neuer Kollegen. Dieses Kapitel enthält eine kleine Auswahl von Methoden und technischen Möglichkeiten, mit denen Abläufe standardisiert werden können.

4.5.1 Vorgehensmodelle

Der Ablauf der Erstellung von technischer Dokumentation – von der Auftragserteilung und den ersten Recherchen, bis zur Auslieferung der fertigen Dokumente – kann sich an einschlägigen Vorgehensmodellen orientieren. Informationen hierzu siehe Kapitel 2.8 „Vorgehensmodelle “ ab Seite 7.

4.5.2 Redaktionssysteme

Moderne Redaktionssysteme können die Arbeit von Technischen Redakteuren enorm erleichtern. Unter anderem die folgenden Funktionen sind im Arbeitsalltag vieler Technischer Redakteure sehr nützlich:

• Variantenbildung: mit Hilfe von Filtermechanismen unterschiedliche Varianten eines Dokuments erzeugen, zum Beispiel mit unterschiedlichen Inhalten je nach Zielgruppe oder Produktvariante

• Inhaltsstruktur/Informationsmodell: Inhalte in konsistenten Strukturen erfassen



• Cross-Media-Publishing: Informationsprodukte für unterschiedliche Ausgabemedien und mit unterschiedlichen Layouts publizieren, ohne den Inhalt der Informationsprodukte bearbeiten zu müssen

• Workflow-Steuerung: Abläufe im Überblick haben, zum Beispiel mithilfe klar definierter Status-Reihenfolgen bis hin zur Freigabe von Inhalten

• Versionierung: alte Versionen von Modulen und Dokumenten jederzeit wiederherstellen

• Erzeugen von Übersetzungsaufträgen: zu übersetzende Inhalte mit wenigen Klicks exportieren und an einen Übersetzer senden, die übersetzten Inhalte wieder in das Redaktionssystem importieren

Übrigens: Die Bezeichnung „Redaktionssystem“ ist in der technischen Dokumentation synonym zu der Bezeichnung „Content-Management-System“. Präziser ist aber die Bezeichnung „Component-Content-Management-System“.

Abbildung 29: Redaktionssystem Smart Media Creator von EC-Systems, Editoransicht (Expert Communication Systems 2015)



4.5.3 Makros für Bildbearbeitung

Mit einigen Bildbearbeitungsprogrammen, unter anderem mit dem weitverbreiteten Adobe Photoshop, können viele Arbeitsschritte automatisiert werden. In Adobe Photoshop gibt es dazu sogenannte „Aktionen“. Ähnlich wie bei den aus MS Office bekannten Makros können mit Aktionen Schrittfolgen in Photoshop aufgezeichnet werden. Anschließend können diese Schrittfolgen automatisiert auf beliebig viele Bilder angewendet werden. Das spart Zeit und sorgt für eine gleichbleibende Qualität des Ergebnisses.

Abbildung 30: Aktionen in Adobe Photoshop CS

Mit Hilfe von Aktionen könnten beispielsweise mit einem Klick Original-Abbildungen mit Wasserzeichen versehen und in unterschiedlichen Auflösungen gespeichert werden.

4.5.4 Profile für PDF-Erzeugung

Fertige Informationsprodukte werden sehr häufig als PDF-Dokumente publiziert und verteilt. Auch die Erstellung von PDF-Dokumenten sollte daher standardisiert werden, um Zeit zu sparen und gleichbleibend gute Ergebnisse zu erhalten.

Bei der Erstellung von PDF-Dokumenten mit Adobe Acrobat können beispielsweise folgende Einstellungen vorgenommen werden, die Einfluss auf die optische Qualität und auf die Dateigröße des fertigen Dokuments haben:

• Version des PDF-Standards



• Dokumentauflösung

• Kompression von Bildern

• Einbetten von Schriftarten

Zum Erleichtern und Vereinheitlichen der PDF-Erzeugung gibt es in Adobe Acrobat die Möglichkeit, Einstellungen in Profilen zu speichern. Diese Profile und können später bei der Erzeugung neuer PDF-Dokumente einfach angewendet werden.

Abbildung 31: Profile in Adobe Acrobat

4.5.5 Dokumentvorlagen

Wer in Schreib- oder DTP-Programmen gelegentlich bestimmte Arten von Dokumenten erstellen möchte, legt sich am besten entsprechende Dokumentvorlagen an, beispielsweise für Gebrauchsanleitungen. Dokumentvorlagen können unter anderem Formatvorlagen, Muster-Kapitelstrukturen, Musterinhalte, Makros, Textbausteine oder Seiteneinstellungen enthalten. So braucht man beim Erstellen eines Dokuments nicht mit einem leeren Dokument zu beginnen. Das spart Zeit und die Inhalte werden konsistenter.

4.5.6 Formulare

Zum Erfassen von Informationen können Formulare entwickelt werden, z. B. für interne Besprechungen oder für neue Dokumentationsaufträge. Mit Hilfe von sinnvoll gestalteten Formularen liegen Informationen von vornherein in einer Form vor, die eine Weiterverarbeitung vereinfacht. Darüber hinaus können die



Felder eines Formulars auch als Checkliste dienen. Die Informationen sind dadurch häufiger vollständig; die Ausfüllenden vergessen seltener, bestimmte Informationen anzugeben.

4.6 Redaktionsleitfaden In diesem Kapitel erhalten Sie einen Überblick über Zweck und Inhalt eines Redaktionsleitfadens.

4.6.1 Definition und Nutzen eines Redaktionsleitfadens

Ein Redaktionsleitfaden ist ein zentrales, Regelwerk, in dem alle redaktionellen Festlegungen innerhalb einer Technischen Redaktion dokumentiert sind.

Ein Redaktionsleitfaden (oft auch „Styleguide“ genannt) hat folgende Vorteile:

• Informationsprodukte standardisieren

• Zeit und somit Kosten einsparen beim Erstellen von Informationsprodukten

• Qualität von Informationsprodukten steigern

Standardisierung

Die Standardisierung tritt ein, wenn alle beteiligten Technischen Redakteure die Festlegungen des Redaktionsleitfadens diszipliniert anwenden. Ein Redaktionsleitfaden hilft allen Beteiligten, einen Überblick über die Festlegungen zu behalten.

Kostensenkung

Eine Einsparung von Kosten tritt aus mehreren Gründen ein: Der wichtigste Faktor ist, dass über die einmal getroffenen Festlegungen nicht ständig neu diskutiert werden muss. Die hierfür eingesparte Zeit ist für ein Unternehmen bares Geld.

Neuen Kollegen erleichtert ein Redaktionsleitfaden die Einarbeitung in die Regeln. Es brauchen nicht ständig andere Kollegen gefragt und in ihrer Arbeit unterbrochen zu werden, stattdessen genügt ein Blick in den Redaktionsleitfaden.



Falls ein Redaktionsleitfaden auch Festlegungen für Prozesse enthält, kann dies zu einer Kostensenkung führen, wenn die Redakteure dank der Festlegungen effizienter arbeiten.

Qualitätssteigerung

Im Rahmen der Entwicklung eines Redaktionsleitfadens machen sich die Beteiligten viele Gedanken über die Festlegungen. Bei dieser Gelegenheit werden oft Normen und andere Fachliteratur studiert, manchmal werden externe Experten hinzugezogen. Das Ergebnis ist oft eine Qualitätssteigerung hinsichtlich der im Redaktionsleitfaden behandelten Aspekte.

4.6.2 Inhalt eines Redaktionsleitfadens

Redaktionsleitfäden sind so unterschiedlich wie die Unternehmen, die sie verwenden. Es gibt keinen Standard-Redaktionsleitfaden, sondern jedes Unternehmen entwickelt einen eigenen Redaktionsleitfaden. Selbstverständlich können und sollten bereits existierende relevante Standards berücksichtigt werden, beispielsweise die DIN EN 82079-1.

Die Bandbreite der Themen in einem Redaktionsleitfaden reicht von grundlegenden Festlegungen, wie zum Beispiel …

• Welche Informationsprodukte gibt es?

• Welche Inhalte sollen die jeweiligen Informationsprodukte enthalten?

• Wie sollen die Informationsprodukte aufgebaut sein?

… bis hin zu Detailfragen:

• Welche Formatvorlage soll für die Signalwörter in Warnhinweisen verwendet werden?

• Wie sollen Handlungsaufforderungen formuliert werden?

• Mit welchen Einstellungen oder Einstellungsprofilen sollen PDF-Dokumente erzeugt werden?

• Mit welcher Auflösung sollen Abbildungen gespeichert werden?

Wenn nur geringe Ressourcen in die Erstellung eines Redaktionsleitfadens investiert werden können, ist es sinnvoll, ihn nach Bedarf nur schrittweise zu erweitern. Es ist nicht unbedingt notwendig, sofort alles festzulegen, was möglicherweise einmal relevant werden könnte. Ein Redaktionsleitfaden ist ohnehin ein



Dokument, das lebt. Veränderte technische Möglichkeiten und neue Erkenntnisse sollten in den Festlegungen berücksichtigt werden.

Ferner gilt auch für einen Redaktionsleitfaden: So ausführlich wie nötig, so knapp wie möglich! Einerseits sollten die Festlegungen kurz begründet und mit Beispielen veranschaulicht werden. Andererseits soll ein Redaktionsleitfaden als Nachschlagewerk einigermaßen überschaubar bleiben. Ausführliche theoretische Begründungen, weshalb beispielsweise ein bestimmtes Formulierungsmuster das beste ist, sollten daher nicht in einem Redaktionsleitfaden stehen. Auch Regeln zur Gestaltung von Informationsprodukten enthält ein Redaktionsleitfaden kaum, denn in der modernen technischen Dokumentation braucht sich eine Technische Redakteurin kaum noch um die Gestaltung zu kümmern.

Einige große Unternehmen veröffentlichen ihre Redaktionsleitfäden, um brancheninterne Quasi-Standards zu schaffen. Bekannt sind beispielsweise die Redaktionsleitfäden von SAP und Microsoft:

• https://www.microsoft.com/Language/de-de/StyleGuides.aspx

• https://experience.sap.com/guidelines/

Weitere öffentliche Redaktionsleitfäden finden Sie hier: http://www.indoition.com/de/links-styleguides-redaktionsleitfaeden.htm.

4.6.3 Anwendung eines Redaktionsleitfadens

Ein Redaktionsleitfaden lebt davon, angewendet zu werden. Alle Betroffenen sollten frühzeitig involviert werden (mehr oder weniger stark), wenn die Entwicklung eines Redaktionsleitfadens geplant ist. Regeln, die Mitarbeitern stattdessen einfach vorgesetzt werden, werden oft nur widerwillig befolgt. Das Potenzial eines Redaktionsleitfadens kann so nicht voll ausgeschöpft werden.

Zur technischen Umsetzung in Unternehmen oder Abteilungen eignen sich Wikis sehr gut. Wikis sind browserbasierte Web-Content-Management-Systeme – mit einer Besonderheit: Die Inhalte können sehr leicht von jedem bearbeitet werden, entsprechende Berechtigungen vorausgesetzt. Bearbeitungen werden protokolliert und zu jedem Thema gibt es Diskussionsseiten.

Die bekannteste Wiki-Software ist Mediawiki. Diese Software ist auch die Basis für Wikipedia. Mediawiki ist Open-Source-Software und daher kostenfrei.

So ausführlich wie nötig, so knapp wie möglich!

https://www.microsoft.com/Language/de-de/StyleGuides.aspx

https://experience.sap.com/guidelines/

http://www.indoition.com/de/links-styleguides-redaktionsleitfaeden.htm

http://www.indoition.com/de/links-styleguides-redaktionsleitfaeden.htm



Abbildung 32: Wiki-Software "Mediawiki", hier als Basis von Wikipedia (Wikipedia 2015)

4.7 Lernkontrolle Sie haben in diesem Kapitel viele Möglichkeiten kennengelernt, wie man technische Dokumentation standardisieren kann. Welche fanden Sie am interessantesten? Beantworten Sie außerdem bitte die folgenden vier Fragen:

1. Was ist der Vorteil von XML mit Blick auf eine konsistente Inhaltsstruktur?

2. Worum geht es beim Terminologiemanagement?

3. Weshalb ist die Trennung von Inhalt und Layout so wichtig?

4. Was ist ein Redaktionsleitfaden?

Strukturierungsprinzipien


5 Strukturierungsprinzipien In diesem Kapitel erhalten Sie einen Überblick über die geläufigsten Strukturierungsprinzipien in der technischen Dokumentation.

In Informationsprodukten kommen häufig zwei oder mehr unterschiedliche Strukturierungsprinzipien vor, zum Beispiel je nach Hauptkapitel. Eines der Strukturierungsprinzipien ist in der Regel jedoch dominierend; in klassischen Gebrauchsanleitungen ist dies typischerweise die Strukturierung nach Handlungszielen.

5.1 Strukturierung nach Handlungszielen Informationsprodukte, die nach Handlungszielen strukturiert sind, sind naturgemäß am häufigsten anzutreffen in der technischen Dokumentation. Eine entsprechend strukturierte Gebrauchsanleitung könnte beispielsweise folgende Gliederung haben:

2 Drucker installieren 2.1 Drucker anschließen 2.2 Druckertreiber installieren 2.3 Druckertreiber konfigurieren

Dieser Aufbau greift mögliche Handlungsziele der Nutzer auf. Im obigen Beispiel hat der Nutzer einen Drucker gekauft und möchte nun wahrscheinlich wissen, wie er den Drucker installieren kann. Der Nutzer wird Schritt für Schritt zu diesem Handlungsziel geführt. Nach Erreichen des Handlungsziels „Drucker installieren“ ist der Drucker einsatzbereit.

5.2 Strukturierung nach Produktbestandteilen Dieses Strukturierungsprinzip orientiert sich am Aufbau eines Produktes. Die Gliederungspunkte entsprechen Teilen, Funktionen oder Merkmalen eines Produkts. Im Falle einer Software könnten dies beispielsweise die Bestandteile der Bedienoberfläche sein:

2 Dialogfenster Drucken 2.1 Reiter Einstellungen 2.2 Reiter Wartung

Als dominierende Strukturierung von Gebrauchsanleitungen ist diese Sichtweise ungeeignet. Der Nutzer erhält in so strukturierten Kapiteln

Beispiel

Beispiel



keine zusammenhängende Anleitung, sondern er muss sich die einzelnen Schritte selbst zusammensuchen.

Ein Nutzer könnte sich beispielsweise fragen, wo er in einer Software die Druckqualität eines Druckers einstellen kann. Bei der Strukturierung nach Produktbestandteilen gibt es jedoch kein Kapitel „Druckqualität einstellen“, sondern bestenfalls ein Kapitel „Reiter Einstellungen“. Der Nutzer muss hier selbst schlussfolgern, dass der Reiter Einstellungen im Dialogfenster Drucken wahrscheinlich relevant ist. Doch auch, wenn er das richtige Kapitel gefunden hat, erfährt der Nutzer nicht, in welcher Reihenfolge und worauf er klicken muss. Spätestens, wenn zum Erreichen eines Handlungszieles Einstellungen in mehreren Dialogfenstern vorgenommen werden müssen, wird der Nutzer eine so aufgebaute Gebrauchsanleitung schnell als nutzlos empfinden.

Geeignet ist dieses Strukturierungsprinzip jedoch für Referenzen, wie zum Beispiel Befehlsreferenzen für Programmiersprachen. In solchen Informationsprodukten oder Kapiteln ist es sinnvoll, alle Befehle aufzulisten und ihre Funktion oder Auswirkung zu beschreiben.

Ebenfalls geeignet ist dieses Strukturierungsprinzip für Kapitel, die einen Überblick über ein Produkt geben sollen, wie exemplarisch in den beiden folgenden Abbildungen:

Abbildung 33: Ausschnitt aus Gebrauchsanleitung eRockit (eRockit 2012, 4)



Abbildung 34: Ausschnitt aus Gebrauchsanleitung eRockit (eRockit 2012, 14)

5.3 Strukturierung nach Zielgruppen Informationsprodukte, die Inhalte für unterschiedliche Zielgruppen enthalten, können mit diesem Strukturierungsprinzip zum Beispiel in Dokumentteile oder Hauptkapitel eingeteilt werden. Innerhalb der einzelnen Dokumentteile/Hauptkapitel können dann auch andere Strukturierungsprinzipien angewendet werden. (Es ist also möglich, Strukturierungsprinzipien zu mischen.)

Im folgenden Beispiel orientiert sich die erste Gliederungsebene des Informationsproduktes an den Zielgruppen, die zweite Gliederungsebene an Handlungszielen:

2 MS Word für Einsteiger 2.1 Dokument erzeugen 2.2 Abbildung in Dokument einfügen 2.3 Tabelle in Dokument einfügen 3 MS Word für Fortgeschrittene 3.1 Formatvorlagen erstellen 3.2 Serienbriefe erstellen

5.4 Strukturierung nach Nutzungssituation Dieses Strukturierungsprinzip greift die Situation auf, in der sich der Nutzer befindet. Klassische Anwendungsfälle sind Kapitel oder Informationsprodukte für die Behebung von Störungen. Inhaltlich sind die betreffenden Kapitel handlungsorientiert, das heißt, der Nutzer erfährt Schritt für Schritt, wie er ein Problem lösen kann. Dennoch ist

Beispiel



diese Sichtweise eine etwas andere als bei der Strukturierung nach Handlungszielen.

Bei der Strukturierung nach Handlungszielen könnte es beispielsweise ein Kapitel „Gerät einschalten“ geben. Wenn sich das Gerät jedoch aufgrund eines Fehlers nicht einschalten lässt, sind andere, oft komplexere Handlungen notwendig.

Beispiel für eine Strukturierung nach Nutzungssituation, hier konkret nach Störungen:

5 Störungen 5.1 Drucker lässt sich nicht einschalten 5.2 Statuslampe blinkt 5.3 Drucker macht ungewöhnliche Geräusche

Informationen zur Störungsbehebung werden häufig auch tabellarisch dargestellt, wie in Abbildung 35:

Abbildung 35: Ausschnitt aus Betriebsanleitung Metz Drehleiter (Metz 2014, 184)

5.5 Card-Sorting als Hilfsmittel zur Strukturierung Es ist nicht immer offensichtlich, welche Inhaltsstruktur für eine Zielgruppe die beste ist. Im Zweifelsfall ist es sinnvoll, typische Vertreter der Zielgruppe zu befragen. Das Card Sorting ist eine geeignete Methode, um von einer Zielgruppe Rückmeldungen zu erhalten, welche Sicht sie auf bestimmte Themen hat und wie sie Inhalte strukturieren würde.

Beispiel



Abbildung 36: Card Sorting als Hilfsmittel zur Strukturierung (Optimal Product 2015)

Das Card Sorting hat seinen Ursprung im Webdesign und in der Software-Entwicklung. In diesen Fachgebieten wird die Methode vor allem dazu genutzt, zielgruppengerechte Menüstrukturen zu entwickeln. Alle Themen einer Website bzw. die Funktionen einer Software werden dazu auf einzelne Kärtchen geschrieben. Die Kärtchen werden unsortiert den Probanden vorlegt mit der Bitte, sie in einer für sie sinnvollen Weise zu sortieren.

In der technischen Dokumentation kann Card Sorting so angewendet werden, dass alle relevanten Themen auf einzelne Kärtchen geschrieben werden. Diese Kärtchen können dann von den Probanden sortiert und gegliedert werden.

5.6 Lernkontrolle In diesem Kapitel wurde Ihr Blick noch ein wenig mehr dafür geschärft, die Belange Ihrer Zielgruppe zu berücksichtigen. Beantworten Sie deshalb bitte folgende Frage:

1. Weshalb ist die Strukturierung nach Handlungszielen am sinnvollsten für eine typische Gebrauchsanleitung?

Standardisierungsmethode Funktionsdesign


6 Standardisierungsmethode Funktionsdesign

In diesem Kapitel erhalten Sie eine Einführung in die Standardisierungsmethode Funktionsdesign® sowie in die technische Umsetzung dieser Methode mit Formatvorlagen in MS Word.

Hinweis: Der Name „Funktionsdesign“ ist markenrechtlich geschützt. Die vollständige Bezeichnung lautet daher „Funktionsdesign®“. Zugunsten der besseren Lesbarkeit wird nachfolgend jedoch auf die ständige Wiederholung des Zusatzes „®“ verzichtet.

6.1 Was ist Funktionsdesign?

6.1.1 Definition

Funktionsdesign ist eine Methode zum Standardisieren und Strukturieren von technischer Dokumentation. Das Funktionsdesign bietet keine fertige Inhaltsstruktur, wie beispielsweise DITA. Vielmehr ist Funktionsdesign ein Hilfsmittel, um eigene Inhaltsstrukturen und Standards zu entwickeln.

Entwickelt wurde die Methode Funktionsdesign von Prof. Robert Schäflein-Armbruster und Prof. Jürgen Muthig (vgl. Schmeling 2014, 4).

6.1.2 Die vier Prinzipien

Die folgenden vier Prinzipien liegen dem Funktionsdesign zugrunde:

• Jede sprachliche Äußerung ist eine sprachliche Handlung.

• Jede sprachliche Handlung kann mittels konkreter Merkmale beschrieben werden.

• In der technischen Dokumentation gibt es eine begrenzte Anzahl möglicher funktionaler Einheiten.

• Jeder Satz enthält genau eine sprachliche Handlung.

Sehen wir uns diese Annahmen einmal näher an:



I. Jede sprachliche Äußerung ist eine sprachliche Handlung

Der Begriff „Handlung“ spielt darauf an, dass eine sprachliche Äußerung die Realität verändert. Der Sprecher oder Autor handelt mit seiner Äußerung; indem er neues Wissen vermittelt, verändert er die Realität des Zuhörers oder Lesers.

Auf dieser Sichtweise – der Sprechakttheorie – basiert das Funktionsdesign. Und es macht für die technische Dokumentation die bloße Feststellung zur Forderung: Jede sprachliche Äußerung soll eine Handlung sein, keine inhaltsleere Phrase.

„Handlung“ heißt hier auch „Absicht“. Das heißt, hinter jeder Äußerung soll eine konkrete Absicht des Sprechers oder Autors stehen. Eine Äußerung ohne besondere Absicht ist überflüssig.

Darüber hinaus soll auch klar sein, was genau die sprachliche Handlung des Autors ist bzw. welche Absicht er verfolgt. Unter Umständen können Äußerungen durchaus unterschiedlich interpretiert werden, wie das folgende Beispiel zeigt.

Angenommen, jemand sagt:

„Das Telefon ist kaputt“ (absichtlich ohne Satzzeichen)

Der Sprecher könnte mit dieser Äußerung sehr unterschiedliche Absichten verfolgen, zum Beispiel:

• Der Sprecher will lediglich jemanden darüber informieren, dass das Telefon kaputt ist und nicht funktioniert.

• Der Sprecher wirft jemandem vor, dass er das Telefon kaputtgemacht hat.

• Der Sprecher möchte sich vergewissern, ob das Telefon kaputt ist.

• Der Sprecher fordert jemanden auf, ihm ein anderes Telefon zu geben.

In der gesprochenen Sprache kann die tatsächliche Absicht des Sprechers vor allem durch entsprechende Betonung, Mimik und Gestik verdeutlicht werden, sowie durch den Kontext, in dem die Äußerung entsteht. Im Zweifelsfall kann der Hörer den Sprecher fragen, wie er etwas genau meint.

In der Schriftsprache gibt es die Möglichkeit der Rückfrage nicht. Und es sind andere Ausdrucksmittel als in der gesprochenen Sprache, die dabei helfen, die Absicht des Autors zu verdeutlichen:

… doch welche sprachliche Handlung ist gemeint?

Beispiel

Verdeutlichung der Absicht in der gesprochenen Sprache

Verdeutlichung der Absicht in der Schriftsprache



• die Gestaltung (unter anderem Typografie, Farben)

• die Formulierung

• die Reihenfolge der Informationen

Damit der Leser die Bedeutung dieser Ausdrucksmittel zweifelsfrei erkennen kann, ist außerdem Konsistenz sehr wichtig. Äußerungen mit der gleichen Absicht sollen auch gleich formuliert und gleich gestaltet sein, so wie in diesem Beispiel:

1. Lösen Sie die Schrauben der Rohrschellen. 2. Entfernen Sie die Rohrschellen. 3. Entnehmen Sie das Abflussrohr.

Im folgenden Negativbeispiel hingegen wird der Leser durch Inkonsistenz verunsichert, ob der Autor in den drei Äußerungen wirklich die gleichen Absichten hat:

1. Lösen Sie die Schrauben der Rohrschellen. 2. Entfernen Sie die Rohrschellen. 3. Das Abflussrohr kann nun entnommen werden.

Der letzte Schritt im obigen Negativbeispiel könnte entweder eine Handlungsaufforderung sein, wie die vorherigen Schritte. Dafür spricht die durchgehende Nummerierung. Oder es könnte lediglich eine Feststellung oder ein Ergebnis sein. Dafür spricht die Formulierungsweise. Solche Unklarheiten werden mithilfe des Funktionsdesigns beseitigt. Aus der Formulierung, Gestaltung und Reihenfolge von Informationen wird die Absicht des Autors deutlich.

II. Jede sprachliche Handlung kann mittels konkreter Merkmale beschrieben werden

Das Funktionsdesign geht davon aus, dass jede Art von sprachlicher Handlung anhand konkreter Merkmale erkannt werden kann. Um Konsistenz zu erreichen, werden diese Merkmale klar definiert, sodass jede sprachliche Handlung zweifelsfrei erkannt werden kann.

An dieser Stelle wird es Zeit, den Begriff „funktionale Einheit“ einzuführen. Eine „sprachliche Handlung“ im Sinne der Sprechakttheorie entspricht in der Fachsprache des Funktionsdesigns einer „funktionale Einheit“. Eine solche Einheit kann im Umfang ein Satz sein oder ein ganzer Abschnitt. „Funktional“ bezieht sich auf die Absicht bzw. auf den Informationszweck einer Einheit; jede Einheit soll eine Absicht bzw. Funktion haben – wie in der Sprechakttheorie vorgesehen.

Wichtigkeit der Konsistenz

Positivbeispiel Konsistenz

Negativbeispiel Inkonsistenz

funktionale Einheit



Im Rahmen des Funktionsdesigns wird für jede funktionale Einheit festgelegt:

• für welchen Informationszweck eine funktionale Einheit verwendet werden soll

• vor oder nach welchen anderen funktionalen Einheiten eine funktionale Einheit stehen darf oder muss

• wie die interne Struktur einer funktionalen Einheit sein soll

• wie eine funktionale Einheit gestaltet und ausgezeichnet sein soll

Weitere Ausführungen hierzu siehe Kapitel 6.2.1 „Die vier Ebenen des Funktionsdesigns“, ab Seite 82.

III. In der technischen Dokumentation gibt es eine begrenzte Anzahl funktionaler Einheiten

Es gibt Textsorten, für die genaue funktionale Differenzierungen und Festlegungen nicht sinnvoll wären. Denken Sie an Pressemitteilungen, Marketingbroschüren, literarische Texte und Ähnliches. Feinsinnige Bedeutungsunterschiede, absichtliche Mehrdeutigkeiten, Wortspiele und dergleichen lassen sich mit den Anforderungen des Funktionsdesigns kaum sinnvoll vereinbaren. Die Anzahl der funktionalen Einheiten wäre sehr groß und es wäre sehr mühselig, zwischen den funktionalen Einheiten zu differenzieren.

Das Funktionsdesign beschränkt sich daher auf die technische Dokumentation. In diesem Fachgebiet ist die Vielfalt funktionaler Einheiten relativ überschaubar und die einzelnen Funktionen sind klar abgrenzbar. Je nach Komplexität der Informationsprodukte und Granularität der funktionalen Einheiten beträgt die Anzahl der funktionalen Einheiten etwa 15 bis 100.

IV. Jeder Satz enthält genau eine sprachliche Handlung

In vielen Gebrauchsanleitungen, die nicht nach Funktionsdesign erstellt wurden, werden sprachliche Handlungen miteinander vermischt. Ein Beispiel:

„3. Nachdem Sie auf OK geklickt haben, wird das Fenster xy geschlossen.“

Dieser Satz enthält zwei sprachliche Handlungen:

Negativbeispiel



• „Nachdem Sie auf OK geklickt haben“ – damit könnte der Autor den Leser auffordern wollen, auf OK zu klicken.

• „wird das Fenster xy geschlossen“ – damit könnte der Autor den Leser informieren wollen, dass als Ergebnis des Klicks das Fenster nun geschlossen sein müsste.

Diese Vermischung von Absichten in einem Satz ist aus mehreren Gründen ungünstig:

• Der Autor zwingt sich nicht, sich bei jedem einzelnen Satz bewusst zu machen, was er eigentlich beim Leser erreichen möchte. Entsprechend leidet die Verständlichkeit insgesamt.

• Es entstehen Inkonsistenzen, die den Leser zusätzlich irritieren.

• Wie im Abschnitt „II. Jede sprachliche Handlung kann mittels konkreter Merkmale beschrieben werden“ (Seite 78) beschrieben, sollen für jede funktionale Einheit Festlegungen getroffen werden. Doch wie sollte dann mit Sätzen umgegangen werden, die mehrere funktionale Einheiten enthalten?!

Das obige Negativbeispiel könnte verbessert so aussehen:

3. Klicken Sie auf OK. [Handlungsaufforderung] >> Das Fenster xy wird geschlossen. [Ergebnis]

Übrigens darf eine funktionale Einheit durchaus aus mehreren Sätzen bestehen. Dies ist beispielsweise bei Kapiteleinleitungen oder beschreibenden Abschnitten oft der Fall. Jeder einzelne Satz hat dann eine eigene sprachliche Handlung und alle Sätze zusammen haben eine übergeordnete sprachliche Handlung.

6.2 Wie wird ein Funktionsdesign aufgebaut?

6.2.1 Die vier Ebenen des Funktionsdesigns

Bei der Planung eines Funktionsdesigns werden vier Ebenen berücksichtigt:

• Informationsprodukte

• Sequenzmuster

• funktionale Einheiten

• Auszeichnungselemente



(vgl. Schäflein-Armbruster 2004, 71ff)

Abbildung 37: Die vier Ebenen des Funktionsdesigns, mit Beispielen

Ebene 1: Informationsprodukte

Auf dieser obersten Ebene des Funktionsdesigns wird die Gesamtheit der technischen Dokumentation eines Unternehmens betrachtet. Im Zentrum steht die Frage, welche Zielgruppen welche Informationen benötigen. Als Antwort könnten unterschiedliche Informationsprodukte definiert werden, zum Beispiel:

• Transport- und Montageanleitung

• Inbetriebnahme- und Betriebsanleitung

• Wartungsanleitung

Auf dieser Ebene kann, je nach Bedarf des Unternehmens, auch die interne technische Dokumentation berücksichtigt werden.

Für die einzelnen Informationsprodukte kann beispielsweise festgelegt werden:

• an welche Zielgruppen sie sich richten

• welche Inhalte mindestens enthalten sein müssen (Grobstruktur)



Ebene 2: Sequenzmuster

Auf der Ebene der Sequenzmuster werden feste Gruppen von funktionalen Einheiten definiert. Solche Sequenzmuster können zum Beispiel sein:

• Abbildung, bestehend aus den funktionalen Einheiten:

• Abbildung_Bild

• Abbildung_Bildunterschrift

• Handlungssequenz, bestehend aus den funktionalen Einheiten:

• Handlungsaufforderung

• Warnhinweis

• Zwischenergebnis

• Ergebnis

Sequenzmuster dürfen verschachtelt werden. So kann beispielsweise das Sequenzmuster „Handlungssequenz“ das Sequenzmuster „Warnhinweis“ enthalten.

Für jedes Sequenzmuster kann beispielsweise festgelegt werden:

• wofür das Sequenzmuster verwendet werden soll

• Beispiel Handlungssequenz: Immer, wenn der Leser Schritt für Schritt zu einem Handlungsziel geleitet werden soll.

• vor oder nach welchen anderen Sequenzmustern oder funktionalen Einheiten dieses Sequenzmuster stehen darf oder muss

• Beispiel Handlungssequenz: nach Kapiteleinleitung

• aus welchen funktionalen Einheiten das Sequenzmuster bestehen darf oder muss

• Beispiel Handlungssequenz: bestehend aus den funktionalen Einheiten Handlungsaufforderung (obligatorisch), Warnhinweis (optional), Zwischenergebnis (optional), Ergebnis (obligatorisch)

Ebene 3: funktionale Einheiten

Funktionale Einheiten sind die wichtigste Ebene des Funktionsdesigns. Eine funktionale Einheit steht für einen Informationszweck. Typische funktionale Einheiten in Gebrauchsanleitungen sind unter anderem:



• Überschrift

• Handlungsaufforderung

• Zwischenergebnis

• Endergebnis

• Warnhinweis

• Abbildung

Im Rahmen des Funktionsdesigns soll jede funktionale Einheit genau definiert werden. Vorgeschlagen werden folgende Aspekte:

• Verwendung: Für welche Informationsabsicht bzw. Funktion soll diese funktionale Einheit verwendet werden? Ist diese funktionale Einheit obligatorisch oder optional?

• Sequenzierung: Vor oder nach welchen anderen funktionalen Einheiten darf oder muss diese funktionale Einheit stehen?

• innere Struktur und Formulierung/syntaktisches Muster: Wie sollen Inhalte dieser funktionalen Einheit formuliert werden oder aus welchen anderen funktionalen Einheiten soll diese funktionale Einheit bestehen?

• Gestaltung/explizite Kennzeichnung: Wie sollen Inhalte dieser funktionalen Einheit gestaltet werden? Wird die funktionale Einheit durch ein Symbol, Piktogramm oder durch Zeichen explizit gekennzeichnet (Warnhinweise z. B. durch das Signalwort „Gefahr“)?

(vgl. Schäflein-Armbruster 2004, 108)

Diese vier Aspekte werden im Funktionsdesign „Festlegungskategorien“ oder auch „Beschreibungsmuster“ genannt. Welche Aspekte festgelegt werden, ist jedoch nicht fest vorgegeben, sondern kann ebenfalls individuell entschieden werden. Unter den Gesichtspunkten der Trennung von Inhalt und Layout und des Cross-Media-Publishing ist es beispielsweise nicht unbedingt sinnvoll, die Formatierung der funktionalen Einheiten zu beschreiben. Denn:

• Die Formatierung variiert je nach Ausgabemedium.

• Es würde einen erhöhten Aufwand bedeuten, gestalterische Änderungen auch im Funktionsdesign dokumentieren zu müssen.

• Der Technische Redakteur in der Rolle des Autors interessiert sich ohnehin nicht für die Gestaltung.

Festlegungskategorien



Stattdessen könnte beispielsweise festgelegt werden, welche Formatvorlage in MS Word für eine funktionale Einheit verwendet werden soll.

Die Festlegungen für die funktionale Einheit „Handlungsaufforderung“ könnten beispielsweise so lauten:

• Verwendung: Immer, wenn der Leser zu einer Handlung aufgefordert werden soll.

• Sequenzierung:

• nach Kapiteleinleitung, Warnhinweis, Zwischenergebnis oder anderer Handlungsaufforderung

• vor Warnhinweis, Zwischenergebnis, Endergebnis oder anderer Handlungsaufforderung

• Formulierung: Infinitiv mit Verb-Erststellung und Sie-Anrede, zum Beispiel „Klicken Sie auf Anwenden.“

• explizite Kennzeichnung: keine

• Auszeichnung durch Formatvorlage: HS_Handlungsaufforderung

Wie im Abschnitt „In der technischen Dokumentation gibt es eine begrenzte Anzahl funktionaler Einheiten“ ab Seite 79 beschrieben, beträgt die typische Anzahl der funktionalen Einheiten in technischer Dokumentation etwa 15-100 Stück. Die Granularität, das heißt, wie fein funktionale Einheiten differenziert werden, hat auf diese Anzahl einen wesentlichen Einfluss.

So ist es beispielsweise ein großer Unterschied, ob ein Warnhinweis nur als eine funktionale Einheit betrachtet wird, oder ob er in Untereinheiten zerlegt wird. Angelehnt an das SAFE-Prinzip für Warnhinweise könnten statt nur einer funktionalen Einheit sechs funktionale Einheiten entstehen:

- Warnhinweis - - Warnhinweis Signalwort - - Warnhinweis Piktogramm - - Warnhinweis Art und Quelle der Gefahr - - Warnhinweis Folge - - Warnhinweis Handlungsaufforderung

Neben der Unterteilung von funktionalen Einheiten ist auch die Differenzierung zwischen ähnlichen Informationszwecken ein Aspekt.

Beispiel Festlegungskategorien

Granularität

Beispiel Granularität von funktionalen Einheiten



Ob beispielsweise Tabellen nicht funktional unterschiedlich, sondern gleich behandelt werden …

für alle Tabellen ein Sequenzmuster „Tabelle“, bestehend aus den funktionalen Einheiten „Tabellenkopf“, „Tabellenkörper“ und „Tabellenunterschrift“

… oder ob jede Art von Tabelle funktional unterschiedlich betrachtet wird:

Tabelle Wartungsarbeiten, Tabelle Ersatzteile, Tabelle technische Daten; entsprechend unterschiedliche Sequenzmuster, zum Beispiel „Tabelle technische Daten“ bestehend aus den funktionalen Einheiten „Tabelle TD Kopf, Tabelle TD Körper, Tabelle TD Unterschrift

Ähnliches bei Listen.

Welche Granularität sinnvoll ist, hängt davon ab:

• welche Ziele mit dem Funktionsdesign verfolgt werden

• wie komplex die Informationsprodukte sind

• welche anderen Prozesse oder Abhängigkeiten in der Technischen Redaktion eines Unternehmens berücksichtigt werden müssen

• wie die funktionalen Einheiten technisch umgesetzt werden können

Je feingranularer die funktionalen Einheiten differenziert werden, desto genauer können für einzelne Elemente Regeln festgelegt werden. Mit zunehmender Granularität wird es jedoch schwieriger, den Überblick über die funktionalen Einheiten zu behalten. Schließlich sollen die Technischen Redakteure effizient Inhalte produzieren. Hier muss – wie in vielen anderen Zusammenhängen auch – jedes Unternehmen einen eigenen Mittelweg finden.

Ebene 4: Auszeichnungselemente

Auszeichnungselemente bilden die unterste Ebene und die kleinsten Einheiten des Funktionsdesigns. Mit Auszeichnungselementen werden einzelne Benennungen oder Funktionen innerhalb von Sätzen markiert. Typische Auszeichnungselemente sind beispielsweise:

• Schaltflächenbenennung

• Menübefehl

Beispiel

Beispiel



• Fenstertitel

• Tastenbenennung

• Produktname

Im folgenden Beispiel wird der Titel eines Software-Dialogfensters mit dem Auszeichnungselement „fenstertitel“ markiert, und zwar innerhalb der funktionalen Einheit „ergebnis“ (hier auf Basis von XML):

<ergebnis>Das Fenster <fenstertitel>Einstellungen</fenstertitel> wird geöffnet.</ergebnis>

6.2.2 Ablauf einer Funktionsdesign-Planung

Die Standardisierungsmethode Funktionsdesign sieht für die Planung eines eigenen Funktionsdesign-Standards ein Vorgehensmodell mit sieben Schritten vor:

1. Analysieren und gegebenenfalls Verbessern der Prozesse, nach denen bisher technische Dokumentation erstellt, verteilt und archiviert wird

• Dieser Schritt ist optional. Beispielsweise könnte hier die Entscheidung getroffen werden, dass ein Redaktionssystem oder ein anderer Editor eingeführt wird.

2. Analysieren der derzeitigen Informationsprodukte und der zukünftigen Anforderungen an die Informationsprodukte

• Ein wichtiges Ergebnis dieses Schrittes ist ein Überblick, welche funktionalen Einheiten sich bereits aus den bisherigen Dokumenten ableiten lassen und welche zusätzlichen funktionalen Einheiten benötigt werden.

3. Klassifizieren der zukünftig relevanten Informationsprodukte

• In diesem Schritt wird der Informationsbedarf der Leser bzw. der Produktanwender analysiert. Ein nützliches Hilfsmittel ist hier die Was-macht-wer-Matrix, siehe Kapitel 2.5.2 „Was-macht-wer-Matrix“, ab Seite 18.

Beispiel Auszeichnungselement



• In diesem Schritt könnte beispielsweise festgelegt werden, dass es künftig eine Wartungsanleitung und eine Betriebsanleitung geben soll.

4. Definieren der funktionalen Elemente

• In diesem Schritt werden schließlich die funktionalen Einheiten, Sequenzmuster und Auszeichnungselemente festgelegt und beschrieben.

• Dieser Schritt ist der wichtigste für die Standardisierung und Strukturierung der technischen Dokumentation. Bei den Festlegungen sind die Aspekte der Sprechakttheorie zu berücksichtigen.

5. Dokumentieren der Festlegungen in einem Redaktionsleitfaden

• Dieser Schritt geschieht parallel zu Schritt 4. Die Festlegungen des Funktionsdesigns bilden üblicherweise den Kern eines Redaktionsleitfadens.

• In diesem Schritt sollen auch die empfohlenen Beschreibungsmuster berücksichtigt werden, siehe Kapitel 6.2.1 „Die vier Ebenen des Funktionsdesigns“.

6. Implementieren der funktionalen Elemente in die Autorenumgebung

• In diesem Schritt werden die funktionalen Einheiten, Sequenzmuster und Auszeichnungselemente beispielsweise in MS Word in Form von Formatvorlagen hinterlegt.

7. Schulen der Technischen Redakteure

• In diesem Schritt werden alle Technischen Redakteure in die Prinzipien des Funktionsdesigns, in die Festlegungen sowie ggf. in die neue Autorenumgebung eingewiesen.

• Im Idealfall wurden alle betroffenen Kollegen bereits im Vorfeld involviert, sodass sie nicht erst in dieser Phase von der Umstellung erfahren.

• Außerdem werden Musterdokumente erstellt, die den Technischen Redakteuren als Referenz dienen.

(vgl. Muthig/Schäflein-Armbruster 2014, 44 ff.)



6.3 Technische Umsetzung von Funktionsdesign

6.3.1 Formatvorlagen oder XML?

Die Ideen des Funktionsdesigns sind unabhängig von konkreten Werkzeugen. Die funktionalen Einheiten, Sequenzmuster usw. können mit unterschiedlichen technischen Mitteln umgesetzt werden. Es gibt im Wesentlichen zwei Kategorien dieser technischen Mittel:

• Formatvorlagen

• zum Beispiel in MS Word, Adobe FrameMaker (unstrukturierter Modus), Adobe InDesign oder LibreOffice Writer

• Auszeichnungssprachen

• hauptsächlich XML

• zum Beispiel in Adobe FrameMaker (strukturierter Modus) oder in einem XML-basierten Redaktionssystem

Eine Umsetzung mit Formatvorlagen hat zwei große Nachteile:

• Mit Formatvorlagen kann keine bestimmte Inhaltsstruktur erzwungen werden, so wie es mit XML möglich ist, siehe Kapitel 4.1.1 „XML-basierte Inhaltsstrukturen“ ab Seite 44. Die Konsistenz der Inhaltsstruktur hängt somit allein von der Disziplin des Autors ab.

• Aus Sicht des Autors erfolgt keine Trennung von Inhalt und Layout, siehe Kapitel 6.3.2 „Formatvorlagen und die Trennung von Inhalt und Layout“, ab Seite 89.

Die Arbeit mit Formatvorlagen hat jedoch niedrigere Einstiegshürden. Ein Schreibprogramm wie MS Word ist ohnehin auf den meisten Rechnern installiert und lässt sich relativ einfach bedienen. Formatvorlagen lassen sich sehr einfach erstellen. Das Implementieren und Anwenden eines XML-Informationsmodells ist technisch deutlich anspruchsvoller.

In der Praxis der technischen Dokumentation ist MSWord® am weitesten verbreitet. Im weiteren Verlauf dieses Kapitels konzentrieren wir uns deshalb auf MS Word. Der Autor verwendet MS Word (Windows-Variante) in der Version 2010. In anderen Versionen ist das Vorgehen prinzipiell ähnlich, lediglich einige Klickwege könnten unterschiedlich sein.

Konzentration auf MS Word



6.3.2 Formatvorlagen und die Trennung von Inhalt und Layout

Die Umsetzung von funktionalen Einheiten mittels Formatvorlagen hat gegenüber der Umsetzung mit XML einen Nachteil: Sie als Autor erleben nicht konsequent die Trennung von Inhalt und Layout. Formatvorlagen enthalten per Definition Layoutinformationen. Wenn Sie also einem Absatz eine Formatvorlage zuweisen, um ihn als bestimmte funktionale Einheit auszuzeichnen, dann weisen Sie diesem Absatz automatisch auch Layoutinformationen zu. Und dieses Layout ist im Falle von MS Word & Co. meistens auch das endgültige Layout, nicht bloß ein Vorschau-Layout.

Es gibt jedoch eine technische Sichtweise, die auch im Umgang mit Formatvorlagen ein Gefühl für die Trennung von Inhalt und Layout geben kann:

Indem Sie einem Absatz eine Formatvorlage zuweisen, weisen Sie ihm zwar auch Layoutinformationen zu, allerdings nur indirekt, weil die Layoutinformationen nun einmal an der Formatvorlage hängen. Eine direkte Layoutzuweisung fände statt, wenn Sie den Absatz direkt formatieren würden über die entsprechenden Symbole in der Symbolleiste.

Abbildung 38: Symbole für Direktformatierung in MS Word 2010

Sehr deutlich wird das, wenn wir uns den XML-Quellcode eines Word-Dokuments einmal ansehen. Dort sehen wir die unterschiedlichen Auswirkungen von Direktformatierung und Formatvorlagen-Verwendung. An den XML-Quellcode gelangen Sie, indem Sie ein Word-Dokument (dateiname.docx) entpacken, so wie man es auch mit Zip-Archiven tun kann. In dem entpackten Verzeichnis „word“ befinden sich u. a. die beiden XML-Dateien „document.xml“ und „styles.xml“.

Zunächst zwei Beispielabsätze:

Abbildung 39: Beispielabsätze für Direktformatierung (oben) und Formatvorlagen-Verwendung (unten)

durch Formatvorlagen nur indirekte Layoutzuweisung

XML-Quellcode eines Word-Dokuments



Der direkt formatierte Absatz sieht im XML-Quellcode („document.xml“) so aus:

Abbildung 40: Direktformatierung im XML-Quellcode eines Word-Dokuments

Die Layoutinformationen „Fettdruck“ (<w:b/>) und „Farbe Rot“ (<w:color w:val=“FF0000“/>) stehen zusammen mit dem Text (<w:t>…</w:t>) in einem Absatz (<w:p … </w:p>).

Anders ist der XML-Quellcode bei der Verwendung einer Formatvorlage (hier „Warnung“):

Abbildung 41: Formatvorlagen-Verwendung im XML-Quellcode eines Word-Dokuments

In diesem Absatz (<w:p … </w:p>) befinden sich keine Layoutinformationen, sondern nur die Angabe einer Formatvorlage (<w:pStyle w:val="Warnung"/>) sowie der Text (<w:t>…</w:t>). Die Layoutdefinition ist in eine gesonderte XML-Datei ausgelagert („styles.xml“):

Abbildung 42: Layoutdefinition einer Formatvorlage im XML-Quellcode eines Word-Dokuments

Sie sehen, bei der Verwendung von Formatvorlagen werden auch in MS Word Inhalt und Layout voneinander getrennt.



6.3.3 Die Funktionsdesign-Ebenen in MS Word umsetzen

Das Umsetzen der Funktionsdesign-Ebenen mit technischen Mitteln in MS Word ist relativ einfach:

• für jede funktionale Einheit wird eine Absatzformatvorlage erstellt

• für jedes Auszeichnungselement wird eine Zeichenformatvorlage erstellt

• für jedes Sequenzmuster kann ein Schnellbaustein erstellt werden

• Dokumentstrukturen können in Dokumentvorlagen vordefiniert werden

Falls Sie nicht sicher sind, was Absatzformatvorlagen, Zeichenformatvorlagen und Schnellbausteine sind und wie sie in MS Word erstellt werden können, lesen Sie bitte zunächst in der Hilfe von MS Word nach: https://goo.gl/E1ADH7

Funktionale Einheiten = Absatzformatvorlagen

Jedem Absatz kann genau eine Absatzformatvorlage zugewiesen werden. Absatzformatvorlagen eignen sich daher sehr gut zum Auszeichnen von funktionalen Einheiten, denn:

• Der Autor muss sich überlegen, was er schreiben möchte und eine passende Absatzformatvorlage auswählen.

• Ein Absatz kann aus einem oder mehreren Sätzen bestehen – genau wie funktionale Einheiten.

Abbildung 43: zugewiesene Absatzformatvorlage in MS Word

In Word muss also für jede funktionale Einheit eine Absatzformatvorlage erstellt werden. Als Benennung der Formatvorlagen empfiehlt sich der Name der entsprechenden funktionalen Einheit oder eine davon abgeleitete Kurzform.

Als fortgeschrittener Word-Anwender wenden Sie das Basierungsprinzip an. Das bedeutet, Sie bauen Absatzformatvorlagen aufeinander auf. Auf diese Weise können Layoutinformationen vererbt werden. Ein Beispiel:

Basierungsprinzip

https://goo.gl/E1ADH7



Abbildung 44: Vererbung von Layoutinformationen durch Basierungsprinzip von Formatvorlagen

In Abbildung 44 ist ersichtlich, dass die Formatvorlage „Handlungsaufforderung“ auf der Formatvorlage „Standard“ basiert. Alle Layoutinformationen von „Standard“ werden somit in „Handlungsaufforderung“ übernommen – und ergänzt oder überschrieben.

Die Formatvorlage „Standard“ enthält grundlegende, allgemeingültige Layouteinstellungen, beispielsweise die Schriftart und die Schriftgröße. Die Formatvorlage „Handlungsaufforderung“ übernimmt diese Informationen und ergänzt die Nummerierung und die Einrückung.

Der Vorteil: Viele Layouteinstellungen brauchen nur noch in einer Formatvorlage eingestellt zu werden. Wenn beispielsweise die Schriftart geändert werden soll, kann dies zentral in der Formatvorlage „Standard“ erledigt werden. Alle Formatvorlagen, die direkt oder indirekt auf „Standard“ basieren und in denen selbst keine andere Schriftart angegeben ist, verwenden dann die neue Schriftart.

Hierzu ein weiteres Beispiel: Warnhinweise. Angenommen, in ihrem Dokument verwenden Sie die Schriftart „Times New Roman“ mit Schriftgröße 11 Punkt. In Warnhinweisen soll jedoch die Schriftart „Arial“ verwendet werden. Sie können die Absatzformatvorlagen wie folgt aufbauen:

• Standard: legt Schriftart „Times New Roman“, Schriftgröße „11 pt“ und Schriftfarbe „Schwarz“ fest

• Warnhinweis: basiert auf „Standard“, legt Schriftart „Arial“ fest

• Warnhinweis_Signalwort: basiert auf „Warnhinweis“, legt Schriftfarbe „Rot“, Schrifteffekt „Großbuchstaben“ und Schriftschnitt „fett“ fest

• Warnhinweis_Gefahrenquelle: basiert auf „Warnhinweis“, legt Schriftschnitt „fett“ fest

• Warnhinweis_Maßnahme: basiert auf „Warnhinweis“, legt Nummerierung und Einrückung fest

Beispiel Basierungsprinzip in MS Word

Beispiel Basierungsprinzip bei Warnhinweis



So weit lässt sich das sehr gut mit den funktionalen Überlegungen des Funktionsdesigns vereinbaren. Doch Sie haben es sicher schon geahnt: Es kann vorkommen, dass nicht funktionale, sondern allein gestalterische Überlegungen das Anlegen zusätzlicher Absatzformatvorlagen erzwingen. Dazu zwei Beispiele:

Beispiel 1:

Handlungsaufforderungen sind üblicherweise nummeriert. Wenn eine Handlungssequenz jedoch nur eine Handlungsaufforderung enthält, dann möchten manche Technischen Redakteure diese einzelnen Handlungsaufforderungen nicht nummerieren. (Von dieser Praxis ist allerdings abzuraten. Mehr dazu in Kapitel 6.4 „Allgemeine Tipps“.) Um also eine alleinstehende Handlungsaufforderung nicht zu nummerieren, sondern beispielsweise mit einem Listenpunkt zu versehen, wird eine gesonderte Absatzformatvorlage benötigt – obwohl es sich funktional um eine ganz normale Handlungsaufforderung handelt.

Beispiel 2:

Aufzählungslisten enthalten gelegentlich zwei oder mehr Ebenen. Die unteren Ebenen werden funktional oft nicht von der oberen Ebene unterschieden, wohl aber gestalterisch, üblicherweise durch Einrückung. Auch hier ist also eine gesonderte Absatzformatvorlage erforderlich, um die abweichende Formatierung steuern zu können.

Die Ausnahme, dass Formatvorlagen auch aus gestalterischen Gründen erstellt werden, ist jedoch weitgehend auf die Arbeit mit Formatvorlagen beschränkt. Mit XML gibt es andere Möglichkeiten.

Nicht jede Formatvorlage muss unterschiedlich formatiert sein. Es ist kein Problem, wenn mehrere Formatvorlagen identisch gestaltet sind. Im Vordergrund stehen funktionale Überlegungen.

Auszeichnungselemente = Zeichenformatvorlagen

Auszeichnungselemente können in MS Word mit Zeichenformatvorlagen umgesetzt werden. So, wie aus Sicht des Funktionsdesigns Auszeichnungselemente innerhalb von funktionalen Einheiten stehen, so können aus Sicht von MS Word Zeichenformatvorlagen innerhalb von Absatzformatvorlagen stehen.

gestalterisch motivierte Formatvorlagen

Beispiele für gestalterisch motivierte Formatvorlagen



Abbildung 45: zugewiesene Zeichenformatvorlage in MS Word

Achten Sie auch bei Auszeichnungselementen auf funktionale Benennungen!

Angenommen, Sie als Autor möchten nach alter Gewohnheit etwas fett markieren, beispielsweise eine Schaltflächenbenennung. Sie haben gelernt, dass Direktformatierung tabu ist, also legen Sie kurzerhand eine Zeichenformatvorlage namens „fett“ an.

Stopp! Denken Sie funktional: Eigentlich geht es nicht darum, dass etwas fett sein soll, sondern dass etwas hervorgehoben sein soll. Ob es fett wird, ist zweitrangig. Also legen Sie eine Zeichenformatvorlage „Hervorhebung“ an.

Stopp! Wenn Sie alles, was hervorgehoben werden soll, mit derselben Formatvorlage „Hervorhebung“ auszeichnen, unabhängig vom Zusammenhang, dann können Sie später nicht differenzieren. Ob Schaltflächenbenennung, Fenstertitel, Signalwort oder Menübefehl – alles ist dann mit „Hervorhebung“ ausgezeichnet.

Wenn später beispielsweise Signalwörter nicht bloß fett, sondern auch rot sein sollen, haben Sie ein Problem:

• Sie können nicht einfach die Formatvorlage „Hervorhebung“ rot machen, denn dann wären auch Schaltflächenbenennungen usw. rot

• Sie können auf das Signalwort keine zweite Zeichenformatvorlage „Signalfarbe“ o. ä. anwenden. Auf ein Zeichen kann immer nur eine Zeichenformatvorlage angewendet werden, in diesem Fall „Hervorhebung“ oder „Signalfarbe“, nicht beide gleichzeitig

• Sie könnten eine Zeichenformatvorlage „Hervorhebung rot“ o. ä. erstellen, das wäre jedoch wieder layoutorientiert, also schlecht.

Also „Hervorhebung Signalwort“? Schon besser. Aber noch besser: Gleich alles funktional benennen und entsprechend unterschiedliche Formatvorlagen erstellen: „Schaltfläche“, „Fenstertitel“, „Signalwort“, „Menübefehl“ usw. Ob einige dieser Formatvorlagen erst einmal



gleich formatiert sind, ist egal. Denn im Vordergrund steht die funktionale Überlegung.

Sequenzmuster = Schnellbausteine

Ein Sequenzmuster ist eine zusammengehörige Gruppe von funktionalen Einheiten. Entsprechende Gruppen von Absatzformatvorlagen können in MS Word in Form von Schnellbausteinen gespeichert werden.

Wie ein Schnellbaustein erstellt werden kann, lesen Sie bitte gegebenenfalls in der Hilfe zu MS Word nach.

Sie könnten beispielsweise einen vollständigen Muster-Warnhinweis einschließlich Musterinhalte als Schnellbaustein in MS Word hinterlegen. Immer, wenn Sie einen Warnhinweis benötigen, brauchen Sie diesen nicht aus den einzelnen Absatzformatvorlagen zusammenzustellen, sondern Sie können einfach den entsprechenden Schnellbaustein einfügen und inhaltlich anpassen.

Informationsprodukte = Dokumentvorlagen

Im Rahmen des Funktionsdesigns wird für jede Art von Informationsprodukt unter anderem festgelegt, welche Grobstruktur eingehalten werden muss. Diese Grobstruktur brauchen Sie nicht jedes Mal neu aufzubauen, wenn Sie beispielsweise eine neue Gebrauchsanleitung erstellen. Stattdessen können Sie für jede Art von Informationsprodukt in MS Word eine Dokumentvorlage erstellen.

Dokumentvorlagen in MS Word verhalten sich weitestgehend wie normale Word-Dokumente. Das heißt, sie können in Dokumentvorlagen unter anderem alle benötigten Formatvorlagen anlegen und eine grobe Kapitelstruktur erstellen. Auch Musterinhalte und Standardinhalte können Sie in einer Dokumentvorlage hinterlegen.

Wenn Sie später auf Basis einer Dokumentvorlage eine neue Gebrauchsanleitung beginnen, werden alle Inhalte aus der Dokumentvorlage in das neue Dokument übernommen. Manche Änderungen an Dokumentvorlagen, z. B. an Formatvorlagen, können auch auf basierende Dokumente übertragen werden.



6.4 Allgemeine Tipps An dieser Stelle sind einige Tipps gesammelt, deren Einbettung in die anderen Kapitel sich nicht ergeben hat, die ich Ihnen aber dennoch mitgeben möchte:

Keine Leerabsätze und andere Direktformatierungen

Dass Direktformatierungen tabu sind, sollte inzwischen deutlich geworden sein. Seien Sie sich bitte bewusst, dass auch Leerabsätze eine Art von Direktformatierung sind! Sie steuern damit manuell den Abstand zwischen zwei Absätzen. Das sollten Sie jedoch ebenfalls über Formatvorlagen steuern.

Nicht die Formatvorlage „Standard“ verwenden

„Standard“ ist eine der (möglichst wenigen) Absatzformatvorlagen, die rein technisch und gestalterisch motiviert sind, nicht funktional. Sie ist direkt oder indirekt die Basis für alle anderen Absatzformatvorlagen. Zeichnen Sie keine Inhalte mit dieser Formatvorlage aus!

Auch alleinstehende Handlungsaufforderungen nummerieren

Manche Technische Redakteure plädieren dafür, eine Handlungsaufforderung nicht zu nummerieren, wenn sie die einzige in einer Handlungssequenz ist. Die dahinterstehende Überlegung ist die, dass der Leser ein „2.“ erwartet, wenn er ein „1.“ liest.

Diese Überlegung mag richtig sein, doch drei andere Überlegungen halte ich für wichtiger:

• Auch, wenn eine alleinstehende Handlungsaufforderung nicht nummeriert wird, wird gegen eine Erwartung verstoßen: Der Leser erwartet nämlich, dass Handlungsaufforderungen nummeriert sind. Er wird es als ebenso ungewöhnlich empfinden, dass diese Handlungsaufforderung nun plötzlich nicht nummeriert ist. Er könnte sich daran zwar gewöhnen und seine Erwartung erweitern. Er könnte sich aber genauso gut daran gewöhnen, dass manchmal nach dem „1.“ eben kein „2.“ kommt.

• Der Aspekt der Konsistenz, der schon in der ersten Überlegung enthalten ist: Der Leser erkennt an der Nummerierung sofort und „schon von Weitem“ eine Handlungsaufforderung. Diese



wichtige Erwartungshaltung und die Wiedererkennung sollten nicht gestört werden. Werden alleinstehende Handlungsaufforderungen beispielsweise mit Listenpunkten versehen, besteht tendenziell die Gefahr, dass der Leser dies für eine einfache Aufzählung hält.

• Konsequent weitergedacht ist auch ein alleinstehender Listenpunkt ungewöhnlich. Denn wenn man schon eine Liste beginnt, dann hat diese normalerweise mindestens zwei Listenpunkte. Also müsste aus der alleinstehenden Handlungsaufforderung oder dem Listenpunkt ein einfacher Fließtext werden. Auch echte nicht nummerierte Listen, beispielsweise Handlungsvoraussetzungen, müssten dann in Fließtext umgewandelt werden, wenn sie nur einen Listenpunkt haben. Diese Umwandlung wäre jedoch kaum automatisiert machbar, sondern würde manuellen Aufwand bedeuten.

Formatvorlagennamen mit einem Punkt o. ä. beginnen

Je nach Komplexität Ihres Funktionsdesigns kann die Formatvorlagenübersicht in MS Word eine Vielzahl von Formatvorlagen enthalten. Zu Ihren eigenen Formatvorlagen kommen außerdem die, die MS Word automatisch anlegt. Letztere kann man leider nicht vollständig ausblenden.

Damit Ihre eigenen Formatvorlagen zusammenhängend angezeigt werden und nicht zwischendrin Word-Formatvorlagen „herumschwirren“, empfehle ich, die Benennungen Ihrer Formatvorlagen mit einem Punkt o. ä. zu beginnen, also statt „Handlungsaufforderung“ zum Beispiel „.Handlungsaufforderung“. Ein Punkt braucht nicht viel Platz und ist relativ unauffällig.

Abbildung 46: Gruppierung von Formatvorlagenbenennungen mit Punkt am Anfang



6.5 Lernkontrolle Möchten Sie endlich selbst einmal eine Gebrauchsanleitung nach Funktionsdesign® erstellen? Einen Moment noch, bitte. Beantworten Sie zunächst wieder ein paar Fragen, um zu überprüfen, ob ich Ihnen das Thema auch wirklich verdeutlichen konnte:

1. Was sind die vier Ebenen des Funktionsdesigns?

2. Was ist eine funktionale Einheit?

3. Sollte eine einzelne Schaltflächenbenennung innerhalb einer Handlungsaufforderung mit einer funktionalen Einheit ausgezeichnet werden? Falls nicht, womit sonst?

4. Ist die folgende Auszeichnung auf XML-Basis sinnvoll?: <schritt>Klicken Sie auf OK. Die Software ist fertig eingerichtet.</schritt> Falls nicht, weshalb? Und wie wäre es besser?

5. Mit welchen Mitteln kann man die vier Ebenen des Funktionsdesigns in MS Word umsetzen?

6.6 Funktionsdesign-Muster Wenden wir das Funktionsdesign einmal gemeinsam praktisch an. Im Folgenden erstelle ich einen kleinen Ausschnitt einer Musteranleitung in MS Word. Wenn Sie mögen, vollziehen Sie die Schritte auf Ihrem Rechner direkt nach.

Für dieses Beispiel analysiere ich keine vorhandenen Dokumente (siehe Kapitel 6.2.2 „Ablauf einer Funktionsdesign-Planung“, ab Seite 86), sondern ich beginne „bei null“ und überlege, welche funktionalen Einheiten und Formatvorlagen benötigt werden. Die Liste kann im weiteren Verlauf jederzeit ergänzt werden. Anschließend leite ich aus der Musteranleitung Festlegungen in Form einer funktionalen Planung und von Sequenzmuster-Definitionen ab. Auf Basis dieser Festlegungen können dann weitere Anleitungen konsistent erstellt werden.

6.6.1 Musteranleitung nach Funktionsdesign® erstellen

Auf eine ausgefeilte Gestaltung wird im Rahmen dieser Musteranleitung verzichtet. Ich beschränke mich auf eine zweckmäßige, übersichtliche Gestaltung.



Vorbereitung

1. Öffnen Sie in Word ein neues Word-Dokument.

2. Klappen Sie die Formatvorlagenübersicht (FVÜ) in Word auf.

3. Lassen Sie in der FVÜ nur verwendete Formatvorlagen anzeigen.

4. Lassen Sie in der FVÜ die Formatvorlagen alphabetisch sortieren.

5. Entfernen Sie in der FVÜ unten das Häkchen „Vorschau anzeigen“.

6. Blenden Sie alle Steuerzeichen ein.

Deckblatt der Musteranleitung

1. Ändern Sie in der Absatzformatvorlage (AFV) Standard die Schriftart zu „Arial“.

2. Schreiben Sie: Produkt 123

3. Erstellen Sie die AFV .DB_Produkt.

• Formatierung: Schriftgröße 36, fett, zentriert, Abstand vor: 150, Abstand nach: 10

• Neu erstellte AFV werden automatisch dem aktuellen Absatz zugewiesen. Der aktuelle Absatz ist der Absatz, in dem sich der Cursor befindet.

• Neu erstellte AFV basieren zunächst immer auf der AFV, die dem aktuellen Absatz zuvor zugewiesen war.



Abbildung 47: Formatierung der Absatzformatvorlage „.DB_Titel“

4. Fügen Sie einen Absatzumbruch ein (Return-Taste drücken).

5. Schreiben Sie: Gebrauchsanleitung

6. Weisen Sie dem aktuellen Absatz die AFV Standard zu.

7. Erstellen Sie die AFV .DB_Dokumentart.

• Formatierung: Schriftgröße 24, fett, zentriert

8. Bearbeiten Sie die AFV .DB_Produkt: „Formatvorlage für folgenden Absatz“: .DB_Dokumentart



Abbildung 48: fertiges Deckblatt der Musteranleitung

Erstes Hauptkapitel der Musteranleitung

1. Fügen Sie nach „Gebrauchsanleitung“ einen Absatzumbruch ein.

2. Schreiben Sie: Allgemeine Sicherheitshinweise


4. Erstellen Sie die AFV .Überschrift 1.

• Formatierung: Schriftgröße 18, fett, Seitenumbruch oberhalb


6. Schreiben Sie: Kinder von dem Gerät fernhalten.

7. Erstellen Sie die AFV .Allg_Sicherheitshinweis.

• Formatierung: Aufzählungspunkt, Einzug links: 0, Abstand nach: 12

8. Fügen Sie einen Absatzumbruch ein.

9. Schreiben Sie: Während des Betriebs nicht in den Innenraum des Gerätes greifen.

Zweites Hauptkapitel der Musteranleitung

Die Beispieltexte in diesem Abschnitt sind der Bedienungsanleitung „Melitta 2013“ (siehe Quellenverzeichnis) entnommen.


2. Weisen Sie dem aktuellen Absatz die AFV .Überschrift 1 zu.



3. Schreiben Sie: Inbetriebnahme



6. Erstellen Sie die AFV .Überschrift 2.

• Formatierung: fett, Abstand vor: 12, Abstand nach: 6

7. Schreiben Sie: Espresso und Café Crème zubereiten



10. Erstellen Sie die AFV .HS_Voraussetzung.

• Formatierung: Abstand nach: 12 • „HS“ steht für „Handlungssequenz“

11. Schreiben Sie: Voraussetzung: Das Display zeigt die Bereitschaftsanzeige.

12. Markieren Sie „Voraussetzung:“.

13. Erstellen Sie die Zeichenformatvorlage (ZFV) .HS_Voraussetzung_Titel.

• Formatierung: fett • Die ZFV wird automatisch den markierten Zeichen zugewiesen.

14. Setzen Sie den Cursor an das Zeilenende und fügen Sie einen Absatzumbruch ein.


16. Erstellen Sie die AFV .HS_Hdlaufforderung.

• Formatierung: Abstand vor: 10, Abstand nach: 3, Nummerierung im Format „1.“

17. Schreiben Sie: Stellen Sie ein Gefäß unter den Auslauf.

18. Bearbeiten Sie die AFV .HS_Voraussetzung: „Formatvorlage für folgenden Absatz“: .HS_Hdlaufforderung


20. Schreiben Sie: „Drücken Sie die Taste ‚Espresso‘ oder ‚Café Crème‘.“

21. Markieren Sie „Espresso“.



22. Erstellen Sie die ZFV .HS_Taste.

• Formatierung: unterstrichen

23. Markieren Sie „Café Crème“.

24. Weisen Sie der Markierung die ZFV .HS_Taste zu.

25. Setzen Sie den Cursor an das Zeilenende und fügen Sie einen Absatzumbruch ein.


27. Erstellen Sie die AFV .HS_Zwischenergebnis.

• Formatierung: Aufzählungszeichen, Einrückung links: 1,3 cm

28. Schreiben Sie: Der Mahlvorgang und die Getränkeausgabe starten.


30. Weisen Sie dem aktuellen Absatz die AFV .HS_Hdlaufforderung zu.

31. Schreiben Sie: Entnehmen Sie das Gefäß.



34. Erstellen Sie die AFV .HS_Ergebnis.

• Formatierung: Einrückung links: 0,6 cm

35. Schreiben Sie: Im Display erscheint die Bereitschaftsanzeige.

Damit ist dieses kleine Beispiel fertig. Das Ergebnis sollte etwa so aussehen:

Abbildung 49: Kapitel "Bedienung" der Musteranleitung



6.6.2 Funktionale Planung

Eine funktionale Planung dient der Übersicht über alle funktionalen Einheiten und deren Verwendung. In der Funktionsdesign-Planung (siehe Kapitel 6.2.2 „Ablauf einer Funktionsdesign-Planung“, Seite 86) ist sie in Schritt 5 angesiedelt. Nachfolgend eine exemplarische Darstellung (Auszug):



Funktionale Einheiten und Auszeichnungs-elemente

Verwendung Inhalt Sequenzierung Formulierung Formatvorlage

Deckblatt Produkt obligatorisch; einmal auf dem Deckblatt

Produktname an erster Stelle auf einem Deckblatt

nur Produkt-bezeichnung; z. B. „Produkt 123“

.DB_Produkt

Deckblatt Dokumentart

obligatorisch; einmal auf dem Deckblatt

Benennung der Dokumentart

nach: Deckblatt Produkt

nur Dokument-bezeichnung; z. B. „Gebrauchs-anleitung“

.DB_Dokumentart

Überschrift 1 obligatorisch; einmal in jedem Hauptkapitel

Thema des Hauptkapitels

an erster Stelle eines Hauptkapitels

Adjektiv + Nomen oder nur Nomen; nominalisierte Verben mit Endung -ung; z. B. „Allgemeine Sicherheits-hinweise“, „Wartung“

.Überschrift 1

Überschrift 2 obligatorisch; einmal in jedem Unterkapitel zweiter Ebene

Thema des Unterkapitels

an erster Stelle eines Kapitels zweiter Ebene

bei handlungs-orientierten Kapiteln: Nomen (Singular) + Verb (Infinitiv); z. B. „Gerät anschließen“; bei beschreibenden Kapiteln: wie Überschrift 1

.Überschrift 2

Handlungssequenz Voraussetzung

optional; wenn bestimmte Voraussetzungen für eine Handlungs-sequenz angegeben werden sollen

Voraussetzungen, um die Handlungs-sequenz durchführen zu können

nach: Überschrift oder Einleitung; vor: erstem Schritt einer Handlungs-sequenz

Satz im Präsens; z. B. „Der Drucker ist an den Rechner angeschlossen.“

.HS_Voraussetzung

Tastenbenennung optional; in einer Handlungsaufforderung

Benennung einer Taste

innerhalb: Handlungs-aufforderung

z. B. „Abbrechen“

.HS_Taste

6.6.3 Sequenzmuster

Sequenzmuster Handlungssequenz:

• Verwendung: Wenn der Leser Schritt für Schritt zu einem Handlungsziel geführt werden soll.

• enthaltene funktionale Einheiten:

• Handlungsvoraussetzung, optional

• Handlungsaufforderung, obligatorisch



• Zwischenergebnis, optional

• Ergebnis, obligatorisch

Weitere Standardisierungsmethoden und Informationsmodelle


7 Weitere Standardisierungsmethoden und Informationsmodelle

Nachdem Sie in Kapitel 6 die Standardisierungsmethode Funktionsdesign® kennengelernt haben, möchte ich Ihnen in diesem Kapitel einen Überblick über einige alternative Standardisierungsmethoden sowie über einige Informationsmodelle geben, die für technische Dokumentation relevant sind.

7.1 Standardisierungsmethoden

7.1.1 Klassenkonzept-Technik®

Die Klassenkonzept-Technik® ist eine Methode, um Inhalte zu strukturieren. Fest verankert ist in dieser Methode auch die Modularisierung von Inhalten. Die Hauptbestandteile der Klassenkonzept-Technik® sind drei Klassen, in denen unterschiedliche Inhaltsebenen betrachtet werden:

• Topic-Klassen

• Link-Klassen

• Informationsgebilde-Klassen

Innerhalb der Klassen werden keine bestimmten Regeln vorgegeben. Es handelt sich, wie auch beim Funktionsdesign, lediglich um einen Rahmen für eigene Festlegungen, nicht um ein fertiges Regelwerk.

(Die Ausführungen in diesem Unterkapitel basieren auf Closs 2014, 75 ff.)

Topic-Klassen

Topics bzw. Module werden zunächst nach der Art der enthaltenen Informationen klassifiziert. Das Ergebnis könnten beispielsweise Handlungstopics und Beschreibungstopics sein; die Klassenkonzept-Technik gibt keine bestimmten Topic-Klassen vor. Für jede Topic-Klasse soll eine Musterstruktur festgelegt werden, denn beispielsweise Handlungstopics benötigen eine andere Inhaltsstruktur als Beschreibungstopics.



Über die Inhaltsstruktur hinaus sieht die Klassenkonzept-Technik weitere Festlegungen je Topic-Klasse vor, beispielsweise bezüglich des Umfangs, der Art des Inhalts, der Zielgruppe und des Benennungsschemas. Welche Kriterien berücksichtigt werden, obliegt dem Entwickler einer Inhaltsstruktur.

Link-Klassen

Gelegentlich ist es notwendig, in einem Topic auf einen anderen Topic zu verweisen. Das Anlegen solcher Querverweise wird im Rahmen der Klassenkonzept-Technik ebenfalls standardisiert.

In Link-Klassen kann festgelegt werden, von welcher Topic-Klasse auf welche andere Topic-Klasse verlinkt werden darf.

Informationsgebilde-Klassen

Nach welchem Muster Topics und Links zu Informationsprodukten zusammengestellt werden dürfen, soll in Informationsgebilde-Klassen definiert werden. Für unterschiedliche Informationsprodukte/-gebilde können unterschiedliche Regeln definiert werden.

7.1.2 Information Mapping®

Bezüglich der Strukturierung von Inhalten ist das Information Mapping® ebenfalls ein Rahmen, in dem eigene Festlegungen definiert werden müssen. Das Information Mapping® wurde nicht speziell für die technische Dokumentation entwickelt, ist aber dennoch auch in unserem Fachgebiet recht bekannt.

Details dieser Methode dürfen aus rechtlichen Gründen leider nicht hier beschrieben werden. Wie bei anderen Standardisierungsmethoden auch ist der Name „Information Mapping“ markenrechtlich geschützt. Die Entwickler dieser Methode unterbinden jedoch mit besonderem Nachdruck jede nicht genehmigte Verbreitung von Wissen über diese Methode: „Schulung und Verbreitung [von Information Mapping®] darf […] nur durch lizenzierte und zertifizierte Distributionspartner […] erfolgen. Die Vervielfältigung und Weiterverwendung der hier enthaltenen Informationen sind deshalb […] nicht gestattet.“ (Böhler 2014, 162 f.)



7.1.3 Zielprogrammierung

Im Mittelpunkt der Standardisierungsmethode „Zielprogrammierung“ steht das Ziel des Autors: Was soll mit dieser Information erreicht werden? Der Leser einer Gebrauchsanleitung soll im Idealfall fast nur Handlungsanleitungen lesen müssen, kaum theoretische Beschreibungen.

Die Zielprogrammierung sieht für Gebrauchsanleitungen folgende Arten von Informationen vor, die gleichzeitig die Grobstruktur bilden sollen:

• Leistungsbeschreibung: Art des Gerätes, Leistungsangebot, Nutzen, bestimmungsgemäßer Gebrauch

• Gerätebeschreibung: Überblick über die Bestandteile des Gerätes

• Tätigkeitsbeschreibung: Handlungsanleitungen zum Erreichen bestimmter Handlungsziele (Außer der klassischen Schritt-für-Schritt-Anleitung gibt es nach Juhl sieben weitere Formen, den Benutzer zur Handlung anzuleiten, zum Beispiel eine Abbildung des Handlungsergebnisses.)

• Beschreibung der Funktionsweise (optional): theoretische Beschreibung des Funktionsprinzips; nur relevant, wenn dadurch der Leser das Gerät besser bedienen kann

• technische Unterlagen (optional): zusätzliche Dokumente, falls relevant, zum Beispiel Schaltpläne, Ersatzteillisten usw.

(vgl. Juhl 2014, 125 ff.)

Für jedes der genannten Grobstruktur-Elemente sieht die Methode „Zielprogrammierung“ eine bestimmte Feinstruktur vor. Handlungsanweisungen, eine Form der Tätigkeitsbeschreibung, sollen der Zielprogrammierung zufolge beispielsweise so aufgebaut sein:

• Überschrift

• Ziel der Handlung

• optional: Überblick über die Handlung

• optional: Handlungsvoraussetzungen

• Handlungsschritte

• Handlungsergebnis

• Ausblick

(vgl Juhl 2014, 132)



Für die einzelnen Elemente der Feinstruktur gibt die Zielprogrammierung darüber hinaus Empfehlungen zur Formulierung. Beispiel für Handlungsschritte: Formulieren Sie die Handlungsschritte als Infinitiv [„Taste A drücken.“] oder als persönliche Anrede [„Drücken Sie die Taste A.“] (vgl. Juhl 2014, 134).

Des Weiteren werden Empfehlungen gegeben, welche Orientierungshilfen in Gebrauchsanleitungen enthalten sein sollten (z. B. Seitenzahlen, Stichwortverzeichnis) und wie bestimmte Informationen am besten vermittelt werden können (z. B. Beispiele, Glossar).

7.2 Informationsmodelle

7.2.1 DITA

DITA ist ein Informationsmodell auf Basis von XML. Das Informationsmodell wurde speziell für technische Dokumentation entwickelt und ist relativ weit verbreitet. Seinen Ursprung hat das Informationsmodell in der Software-Dokumentation, es ist darauf jedoch nicht beschränkt.

Fester Bestandteil von DITA ist die Modularisierung in Inhalten. Jedes Modul – in DITA „Topic“ – soll ein abgeschlossenes Thema behandeln, beispielsweise ein Handlungsziel. Nachfolgend ein exemplarischer Ausschnitt aus einer DITA-Struktur:



Abbildung 50: Informationsmodell DITA, Beispiel task-Topic (Oasis 2010)

„DITA“ steht für „Darwin Information Typing Architecture“. Im Einzelnen bedeutet dies:

Information Typing

Informationen werden in DITA typisiert. Dazu sind vier Topic-Typen vorgegeben:

• „concept“ für beschreibende Inhalte, z. B. Funktionsprinzipien

• „task“ für handlungsanleitende Inhalte

• „reference“ für Referenzbeschreibungen, z. B. Befehlsreferenzen von Programmiersprachen

• „glossentry“ für Glossareinträge

Je nach gewähltem Topic-Typ stehen für Inhalte unterschiedliche Strukturelemente bzw. XML-Tags zur Verfügung.

Der DITA-Standard enthält darüber hinaus Empfehlungen, wie bestimmte Arten von Informationen dargestellt werden sollten. Für das Element „shortdesc“ (Kurzbeschreibung) heißt es beispielsweise: „The short description should be a single, concise paragraph containing one or two sentences of no more than 50 words.“ (Oasis 2010)



Darwin

„Darwin“ steht für die Anpassbarkeit und für das Vererbungsprinzip von DITA. So können beispielsweise auf Basis der vorgegebenen Topic-Typen eigene, speziellere Topic-Typen definiert werden. Die Festlegungen der übergeordneten Topic-Typen werden dabei an die untergeordneten Topic-Typen vererbt.

Abbildung 51: Vererbungsprinzip in DITA, Beispiel für Topic-Typen

Da DITA unter einer Open-Source-Lizenz steht, kann die gesamte Struktur an eigene Anforderungen angepasst werden.

Architecture

„Architecture“ steht für den Standard selbst, für das Gerüst aus Topics, Topic-Typen, XML-Elementen usw.

DITA kann als Paket aus XML-Dateien, DTDs, XSL-Skripten usw. frei heruntergeladen werden unter www.dita-ot.org.

7.2.2 PI-Mod

PI-Mod ist ebenfalls ein Informationsmodell auf XML-Basis. „PI“ steht für die „Klassifizierung von [Inhalten] nach Produkt- und Informationskategorien“ (Ziegler/Steurer 2015), „Mod“ steht für das Prinzip der Modularisierung, auf dem PI-Mod aufbaut.

Zur Klassifizierung von Inhalten sind sieben Modultypen vorgesehen:

• descriptive (u. a. Aufbau- und Funktionsbeschreibungen, technische Daten, allgemeine Beschreibungen)

• task (Schrittanleitungen)

• task-intervals (Wartungspläne)

• tools (Werkzeuglisten)



• lubrication (Schmierpläne)

• diagnosis (Störungsbehebung)

• glossary (Glossare)“

(Ziegler/Steurer 2015)

PI-Mod ist im Umfeld des Maschinen- und Anlagenbaus entstanden, was sich deutlich in Modultypen wie „lubrication“ widerspiegelt. Mit diesen sehr speziellen Modultypen hat es jedoch noch mehr auf sich: Die in solchen Modulen enthaltenen, sauber ausgezeichneten Inhalte können automatisch zu Übersichtslisten verarbeitet werden. Aus Modulen, in denen Wartungstätigkeiten beschrieben werden, kann beispielsweise eine Wartungstabelle generiert werden. Der Standard enthält hierfür ausgefeilte XSLT-Skripte.

7.3 Lernkontrolle Wunderbar! Jetzt haben Sie schon das vorletzte Kapitel geschafft! Wie immer noch kurz ein paar Fragen zum Schluss:

1. Hat DITA etwas mit Modularisierung zu tun?

2. Was bedeutet „DITA“ eigentlich?

Single-Source-Publishing


8 Single-Source-Publishing In diesem Kapitel lernen Sie eine weitere wichtige Methode der modernen technischen Dokumentation kennen: das Single-Source-Publishing.

8.1 Was sind Single-Source-Publishing und Modularisierung?

Single-Source-Publishing bedeutet, …

• aus einer Quelle

• unterschiedliche Informationsprodukte

• für unterschiedliche Ausgabemedien

… zu publizieren.

Der Gesamtprozess des Single-Source-Publishings besteht aus den beiden Teilprozessen Single-Sourcing und Cross-Media-Publishing.

Gegenstand des Single-Sourcings ist das Zusammensetzen von Informationsprodukten aus Modulen. Solche Informationsprodukte können beispielsweise sein: Bedienungsanleitung und Wartungsanleitung für ein Produkt oder für unterschiedliche Produkte. Beim Cross-Media-Publishing werden diese Informationsprodukte schließlich für unterschiedliche Ausgabemedien publiziert, beispielsweise als PDF für den Druck, als Website für die Veröffentlichung im Internet, als App für Smartphones oder Tablets.

Die Inhalte müssen hierzu modular und medienneutral vorliegen. Der Aspekt der Medienneutralität bzw. der Trennung von Inhalt und Layout wurde bereits in Kapitel 4.3.1 „Trennung von Inhalt und Layout“ behandelt, weshalb nachfolgend hauptsächlich Single-Sourcing und Modularisierung betrachtet werden.

Die Methode der Modularisierung ist es, den Inhalt eines Informationsproduktes nicht einfach als Ganzes in ein Dokument zu schreiben, sondern den Inhalt in kleine Einheiten – in Module – zu zerlegen. Solche Einheiten können in unterschiedlichen Informationsprodukten wiederverwendet werden. Denken Sie beispielsweise an ein Unternehmen, das Fernsehgeräte produziert. Zwischen den Gerätemodellen gibt es zwar einige Unterschiede, aber auch viele Gemeinsamkeiten. Die entsprechenden gemeinsamen

-Anzeige- Seminare zu den Themen Single-Source-Publishing, Modularisierung und Redaktionssysteme finden Sie auf www.technische-dokumentation.org.





Inhalte der technischen Dokumentation brauchen dank Modularisierung nicht immer wieder neu geschrieben oder dupliziert zu werden, sondern sie werden zentral als Module abgelegt und können einfach und effizient wiederverwendet werden.

8.2 Vorteile von Modularisierung Die Einführung von Modularisierung bedeutet zunächst Aufwand. Im Allgemeinen können jedoch folgende Vorteile erwartet werden:

• vereinfachte Wiederverwendung von Inhalten

• mehrfach benötigte Inhalte werden nicht per Copy-&-Paste vervielfältigt, sondern an den benötigten Stellen nur referenziert

• verringerter Pflegeaufwand

• Inhalte sind nur einmal vorhanden und brauchen deshalb nur an einer Stelle (zentral) gepflegt zu werden

• verringerte Übersetzungskosten

• Übersetzer erhalten nur noch geänderte Module, keine ganzen Dokumente mehr (siehe Kapitel 3.3.3 „Rechenbeispiel für die Einsparung durch ein TMS“ ab Seite 42)

• vereinfachte Teamarbeit

• Inhalte können besser auf mehrere Redakteure aufgeteilt werden, Redakteure liefern Module

Dabei ist Modularisierung bzw. Single-Sourcing aber kein „Allheilmittel“: Wenn Wiederverwendungspotential, Übersetzung und cross-mediale Publikation für ein Unternehmen nicht relevant sind, kann es wirtschaftlicher sein, ohne Redaktionssystem zu arbeiten. Das sollte im Einzelfall analysiert werden.

8.3 Lernkontrolle Klasse! Sie haben dieses E-Book fast geschafft! Jetzt nur noch ein paar letzte Fragen, allein schon der Konsistenz wegen:

1. Wie stehen Modularisierung und Single-Source-Publishing miteinander in Verbindung?



2. Weshalb können durch Modularisierung Übersetzungskosten gesenkt werden?

Verzeichnisse und Sonstiges


9 Verzeichnisse und Sonstiges

9.1 Abbildungsverzeichnis Abbildung 1: Produktlebenszyklus nach ISO 9004 (ISO 9004-1 1994, zitiert

nach tekom 2015a) ............................................................... 9

Abbildung 2: Onlinehilfe für Adobe Acrobat (Adobe 2015) ......................... 18

Abbildung 3: Onlinehilfe für Adobe Acrobat (Adobe 2015) ......................... 18

Abbildung 4: Ausschnitt aus einer Gebrauchsanleitung mit schlechter Gestaltung (BOCA 2006) ..................................................... 23

Abbildung 5: Ausschnitt aus einer Gebrauchsanleitung mit guter Gestaltung (Melitta 2013) ..................................................................... 23

Abbildung 6: Kreissägemaschine Hammer B3 basic (Miller 2015) .............. 33

Abbildung 7: Suchtreffer im tekom-Normenkommentar (tekom 2015b) ..... 34

Abbildung 8: Translation-Memory-System across (Sousa 2013) ................. 40

Abbildung 9: SDL MultiTerm (Cornillie Consulting 2015) ............................ 49

Abbildung 10: ASD-STE100, Words (ASD 2013) ......................................... 50

Abbildung 11: ASD-STE100, Noun phrases (ASD 2013) .............................. 50

Abbildung 12: ASD-STE100, Verbs (ASD 2013) .......................................... 50

Abbildung 13: AST-STE100, Sentences (ASD 2013) .................................... 50

Abbildung 14: ASD-STE100, Procedures (ASD 2013) .................................. 51

Abbildung 15: ASD-STE100, Descriptive wirtings (ASD 2013) ..................... 51

Abbildung 16: ASD-STE100, Warnings, cautions, and notes (ASD 2013) ..... 51

Abbildung 17: ASD-STE100, Punctuation and word counts (ASD 2013) ...... 51

Abbildung 18: ASD-STE100, Writing practices (ASD 2013) ......................... 52

Abbildung 19: ASD-STE100, Dictionary (ASD 2013) ................................... 52

Abbildung 20: Sprachkontrollsystem acrolinx eingebunden in MS Word (Acrolinx 2013) ................................................................... 53

Abbildung 21: Liste der Formatvorlagen in MS Word und Zuordnung einer Formatvorlage zu einem Absatz .......................................... 56

Abbildung 22: Formatvorlage einrichten in MS Word ................................. 56

Abbildung 23: Dokumentvorlagen austauschen in MS Word ...................... 57

Abbildung 24: Zuweisung eines Stylesheets zu einem XML-Dokument ....... 58

Abbildung 25: Gestaltung eines XML-Dokuments durch CSS ...................... 58

Abbildung 26: Positionsnummern und Positionslinien (eRockit 2012) ......... 60



Abbildung 27: Positionslinie mit weißer Kontur, vergrößerter Ausschnitt aus Abbildung 26 (eRockit 2012) ............................................... 62

Abbildung 28: unübersichtliche Reihenfolge der Positionsnummern (Boca 2006) .................................................................................. 63

Abbildung 29: Redaktionssystem Smart Media Creator von EC-Systems, Editoransicht (Expert Communication Systems 2015) .......... 64

Abbildung 30: Aktionen in Adobe Photoshop CS ........................................ 65

Abbildung 31: Profile in Adobe Acrobat...................................................... 66

Abbildung 32: Wiki-Software "Mediawiki", hier als Basis von Wikipedia (Wikipedia 2015) ................................................................. 70

Abbildung 33: Ausschnitt aus Gebrauchsanleitung eRockit (eRockit 2012, 4) ........................................................................................... 72

Abbildung 34: Ausschnitt aus Gebrauchsanleitung eRockit (eRockit 2012, 14) ........................................................................................... 73

Abbildung 35: Ausschnitt aus Betriebsanleitung Metz Drehleiter (Metz 2014, 184) .................................................................................... 74

Abbildung 36: Card Sorting als Hilfsmittel zur Strukturierung (Optimal Product 2015) ..................................................................... 75

Abbildung 37: Die vier Ebenen des Funktionsdesigns, mit Beispielen ......... 81

Abbildung 38: Symbole für Direktformatierung in MS Word 2010 ............... 89

Abbildung 39: Beispielabsätze für Direktformatierung (oben) und Formatvorlagen-Verwendung (unten) .................................. 89

Abbildung 40: Direktformatierung im XML-Quellcode eines Word-Dokuments ........................................................................................... 90

Abbildung 41: Formatvorlagen-Verwendung im XML-Quellcode eines Word-Dokuments ......................................................................... 90

Abbildung 42: Layoutdefinition einer Formatvorlage im XML-Quellcode eines Word-Dokuments ................................................................ 90

Abbildung 43: zugewiesene Absatzformatvorlage in MS Word ................... 91

Abbildung 44: Vererbung von Layoutinformationen durch Basierungsprinzip von Formatvorlagen ............................................................ 92

Abbildung 45: zugewiesene Zeichenformatvorlage in MS Word ................. 94

Abbildung 46: Gruppierung von Formatvorlagenbenennungen mit Punkt am Anfang ................................................................................ 97

Abbildung 47: Formatierung der Absatzformatvorlage „.DB_Titel“ ............100

Abbildung 48: fertiges Deckblatt der Musteranleitung ..............................101

Abbildung 49: Kapitel "Bedienung" der Musteranleitung ...........................103



Abbildung 50: Informationsmodell DITA, Beispiel task-Topic (Oasis 2010) .111

Abbildung 51: Vererbungsprinzip in DITA, Beispiel für Topic-Typen ...........112

9.2 Tabellenverzeichnis Tabelle 1: Informationsprodukte im Produktlebenszyklus (tekom 2015a) ... 10

Tabelle 2: Was-macht-wer-Matrix, Beispiel (vgl. Juhl 2002, 16) .................. 18

Tabelle 3: Ebenen von Inhaltsstrukturen ................................................... 47

Tabelle 4: technische Eigenschaften von Abbildungen ............................... 59

9.3 Quellenverzeichnis ADOBE (2015): Acrobat Help / Crop PDF pages.

https://helpx.adobe.com/acrobat/using/crop-pdf-pages.html [Stand: unbekannt, zuletzt aufgerufen am: 06.08.2015]

ACROLINX (2013): Don’t Rewrite – Reuse. http://www.acrolinx.jp/platform-services/reuse/ [Stand: Dezember 2013, zuletzt abgerufen am: 17.08.2015]

ASD (2013): AeroSpace and Defence Industries Association of Europe - Simplified Technical English. Specification ASD-STE100. Issue 6, January 2013.

BAUMERT, ANDREAS/VERHEIN-JARREN, ANNETTE (2012): Texten für die Technik. Leitfaden für Praxis und Studium. Berlin Heidelberg.

BEUTH VERLAG GMBH (Hrsg.) (2013): DIN EN 82079-1:2013-06. Erstellen von Gebrauchsanleitungen - Gliederung, Inhalt und Darstellung - Teil 1: Allgemeine Grundsätze und ausführliche Anforderungen.

BOCA VERTRIEBS GMBH (2006): Bedienungsanleitung für Satellitenreceiver BOCA SR 400.

BÖHLER, KLAUS (2014): Die Strukturierungsmethode Information Mapping®. In: Standardisierungsmethoden für die Technische Dokumentation. tekom Hochschulschriften Band 16. Stuttgart.

CLOSS, SISSI (2014): Flexibilität und Standardisierung: die Klassenkonzept-Technik®. In: Standardisierungsmethoden für die Technische Dokumentation. tekom Hochschulschriften Band 16. Stuttgart.



CORNILLIE CONSULTING (2015): Terminologiemanagement. http://www.cornillie.de/dienstleistungen/beratung/terminologiemanagement/index.php [Stand: unbekannt, zuletzt aufgerufen am: 17.08.2015]

EROCKIT GMBH (2012): eRockit Benutzer-Handbuch. Stand 04/2012.

EUROPÄISCHE UNION (2006): Richtlinie 2006/42/EG des europäischen Parlaments und des Rates vom 17. Mai 2006 über Maschinen und zur Änderung der Richtlinie 95/16/EG (Neufassung).

EXPERT COMMUNICATION SYSTEMS GMBH (2015): Der Smart Media Creator – SMC. http://www.ec-systems.de/de/smart-media-creator/ [Stand: unbekannt, zuletzt aufgerufen am: 18.08.2015]

GESETZE-IM-INTERNET.DE (2015a): Gesetz über die Bereitstellung von Produkten auf dem Markt (Produktsicherheitsgesetz - ProdSG). § 3 Allgemeine Anforderungen an die Bereitstellung von Produkten auf dem Markt. http://www.Gesetze-im-Internet.de/prodsg_2011/__3.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]

GESETZE-IM-INTERNET.DE (2015b): Gesetz über die Bereitstellung von Produkten auf dem Markt (Produktsicherheitsgesetz - ProdSG). § 6 Zusätzliche Anforderungen an die Bereitstellung von Verbraucherprodukten auf dem Markt. http://www.Gesetze-im-Internet.de/prodsg_2011/__6.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]

GESETZE-IM-INTERNET.DE (2015c): Neunte Verordnung zum Produktsicherheitsgesetz (Maschinenverordnung) (9. ProdSV). § 3 Voraussetzungen für die Bereitstellung von Maschinen auf dem Markt oder die Inbetriebnahme von Maschinen. http://www.Gesetze-im-Internet.de/gsgv_9/__3.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]

GESETZE-IM-INTERNET.DE (2015d): Gesetz über die Haftung für fehlerhafte Produkte (Produkthaftungsgesetz – ProdHaftG). § 1 Haftung. http://www.Gesetze-im-Internet.de/prodhaftg/__1.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]

GESETZE-IM-INTERNET.DE (2015e): Gesetz über die Haftung für fehlerhafte Produkte (Produkthaftungsgesetz – ProdHaftG). § 3 Fehler. http://www.Gesetze-im-Internet.de/prodhaftg/__3.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]



GESETZE-IM-INTERNET.DE (2015f): Bürgerliches Gesetzbuch (BGB). § 823 Schadensersatzpflicht. http://www.Gesetze-im-Internet.de/bgb/__823.html [Stand: unbekannt, zuletzt abgerufen am: 06.08.2015]

GÖRS, BRITTA (2010): Alaska - alles klar?! Vorgehensmodell zur Erstellung Technischer Dokumentation. in Fachzeitschrift „technische kommunikation“, Ausgabe 6/2010 http://www.tekom.de/index.php?id=10195 [Stand: 06/2010, zuletzt aufgerufen am: 10.08.2015]

ISO 9004-1 (1994): Qualitätsmanagement und Elemente eines Qualitätsmanagementsystems – Teil 1: Leitfaden (ISO 9004-1:1994)

JUHL, DIETRICH (2015): Technische Dokumentation: Praktische Anleitungen und Beispiele. Berlin. 3. Auflage.

JUHL, DIETRICH (2014): Zielprogrammierung – fertige Strukturen für Bedienungsanleitungen. In: Standardisierungsmethoden für die Technische Dokumentation. tekom Hochschulschriften Band 16. Stuttgart.

MELITTA EUROPA GMBH & CO. KG (2013): Bedienungsanleitung CaffeO Barista T. Mel 001-1v5-1.0 | 2013-06.

METZ AERIALS GMBH & CO. KG (2014): Betriebsanleitung L32A XS Drehleiter. Ausgabe 04/2014.

MILLER GMBH & CO. KG (2015): Hammer Kreissäge-Fräsmaschine B3 basic. https://www.miller-maschinen.de/index.php?Kreissaege-Fraesmaschine-B3-basic-Hammer [Stand: unbekannt, zuletzt aufgerufen am: 10.08.2015]

MUTHIG, JÜRGEN/SCHÄFLEIN-ARMBRUSTER, ROBERT (2014): Funktionsdesign® – methodische Entwicklung von Standards. In: Standardisierungsmethoden für die Technische Dokumentation. tekom Hochschulschriften Band 16. Stuttgart.

OASIS (2010): Organization for the Advancement of Structured Information Standards. Darwin Information Typing Architecture (DITA) Version 1.2. http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html [Stand: 12/2010, zuletzt aufgerufen am: 25.08.2015]

OPTIMAL PRODUCT LTD (2015): Discover how other people organize your content. https://www.optimalworkshop.com/optimalsort [Stand: unbekannt, zuletzt aufgerufen am: 21.08.2015]



SCHÄFLEIN-ARMBRUSTER, ROBERT (2004): Planen, Strukturieren und Standardisieren mit Funktionsdesign.

SCHMELING + CONSULTANTS GMBH (2014): Funktionsdesign® - unsere Methode für Standardisierung und Strukturierung. http://www.schmeling-consultants.de/nc/publikationen/?fd=funktionsdesign_de_web.pdf [Stand: 27.08.2014, zuletzt aufgerufen am: 24.08.2015]

SOUSA, HELENA (2013): O papel das TAT na formação de um tradutor. https://hpatriciasousa.wordpress.com/2013/05/18/o-papel-das-tat-na-formacao-de-um-tradutor/ [Stand: 18.05.2013, zuletzt aufgerufen am: 18.08.2015]

TEKOM (2013): Leitlinie Regelbasiertes Schreiben. Deutsch für die Technische Kommunikation. 2. Auflage. Stuttgart.

TEKOM (2015a): Technischer Redakteur: Ein Medienberuf mit Zukunft. http://www.tekom.de/beruf-bildung/technischer-redakteur.html [Stand: unbekannt, zuletzt aufgerufen am: 04.08.2015]

TEKOM (2015b): tekom-Normenkommentar. EN 859 „Sicherheit von Holzbearbeitungsmaschinen“ http://www.tekom.de/dienste/normenkommentar/normenkommentar-singleview.html?tx_normenkommentar_fenormenkommentar%5Bnormenkommentar%5D=426&tx_normenkommentar_fenormenkommentar%5Baction%5D=show&tx_normenkommentar_fenormenkommentar%5Bcontroller%5D=Normenkommentar&cHash=4172a4946f42d2fcb264855b24aeebd3 [Stand: unbekannt, zuletzt aufgerufen am: 10.08.2015]

USABILITY-TOOLKIT.DE (2015): Persona: Daniel Storm. http://usability-toolkit.de/usability/praxisbeispiel/online-shop-wearitfair/erste-ergebnisse-personas/persona-daniel-storm/ [Stand: unbekannt, zuletzt aufgerufen am: 05.08.2015]

VDI 4500 Blatt 1 (2006): Technische Dokumentation. Begriffsdefinitionen und rechtliche Grundlagen. Düsseldorf.

WIKIPEDIA (2013): Milupa-Urteil. https://de.wikipedia.org/wiki/Milupa-Urteil [Stand: 05.04.2013, zuletzt aufgerufen am: 06.08.2015]

WIKIPEDIA (2015): Technische Dokumentation. https://de.wikipedia.org/wiki/Technische_Dokumentation [Stand: 25.02.2015, zuletzt aufgerufen am: 21.08.2015]



ZIEGLER, WOLFGANG/KRÜGER, MANFRED (2014): Standards für strukturierte technische Informationen – ein Überblick. In: Standardisierungsmethoden für die Technische Dokumentation. tekom Hochschulschriften Band 16. Stuttgart.

ZIEGLER, WOLFGANG/STEURER, STEPHAN (2015): Das Konzept von PI-Mod. http://www.pi-mod.de/index.php?option=com_content&view=article&id=11&Itemid=13&lang=de [Stand: unbekannt, zuletzt aufgerufen am: 31.08.2015]

9.4 Stichwortverzeichnis Abbildungen26, 59, 60, 61, 65, 68,

72 Absatzformatvorlage ..... 91, 93, 99 Acrobat ......................... 17, 65, 66 ALASKA ..................................... 29 Basierungsprinzip ............... 91, 92 Benennung ............................... 48 BGB ...................... 12, 15, 16, 121 Bürgerlichen Gesetzbuch .......... 15 Card Sorting ........................ 74, 75 Cascading Stylesheet ................ 58 Content-Management-System ... 64 Controlled-Language-Checker ... 53 Cross-Media-Publishing 59, 64, 83,

114 CSS ..................................... 54, 58 DIN EN 82079 .. 25, 30, 31, 33, 59,

68, 119 DITA...... 45, 46, 76, 110, 111, 112,

121 Dokumentvorlagen . 57, 66, 91, 95 DTD .................................... 44, 45 Editor ............................ 46, 58, 86 Exact-Match .............................. 42 explizite Kennzeichnung...... 83, 84 externe technische

Dokumentation ........................ 9 Fachbücher ............................. 126 Festlegungskategorien ........ 83, 84

Formatvorlage .. 56, 57, 68, 84, 89, 90, 92, 93, 94, 96, 100, 102

Formulare................................. 66 funktionale Einheit.. 78, 79, 80, 82,

83, 84, 89, 91 Funktionsdesign 46, 76, 77, 78, 79,

83, 85, 86, 91, 98, 107, 121, 122

Fuzzy-Match ........................41, 42 Gestaltung . 19, 22, 24, 37, 54, 59,

78, 83 Gliederung .................... 30, 37, 71 Granularität ................... 79, 84, 85 Information Mapping ....... 108, 119 Informationsmodell....... 45, 46, 63,

110, 112 Inhaltsstruktur .. 22, 24, 32, 35, 38,

44, 46, 63, 74, 76, 88, 107, 108 interne technische Dokumentation

............................................. 81 Klassenkonzept ....... 107, 108, 119 Konsistenz ................................ 24 kontrollierte Sprache ...........49, 52 Korrekturlesen ........................ 126 Leserlichkeit ........................25, 26 Makros ................................65, 66 Maschinenrichtlinie . 13, 25, 31, 33,

46 Mediawiki ................................. 69



Modularisierung . 12, 43, 107, 110, 112, 114, 115

Onlineseminare ....................... 126 Persona............................. 19, 122 Photoshop ................................. 65 PI-Mod .................... 112, 113, 123 Positionslinien ..................... 61, 62 Positionsnummern ........ 60, 61, 62 Produkthaftungsgesetz 12, 14, 120 Produktlebenszyklus ......... 8, 9, 10 Produktsicherheitsgesetz ... 12, 13,

30, 31, 120 Redaktionsleitfaden 29, 67, 68, 69,

87 Redaktionssystem .. 46, 54, 58, 64,

86, 88 Satzbau ........................ 21, 24, 48 Schnellbaustein................... 91, 95 Schriftgröße 25, 54, 55, 59, 92, 99,

100, 101 Sequenzierung .................... 83, 84 Sequenzmuster 80, 82, 85, 87, 88,

91, 95, 98, 105

Simplified Technical Englisch .... 49 Single-Source-Publishing ........ 114 Sprechakttheorie ........... 77, 78, 87 Stylesheet ...........................58, 59 Synonyme ................................ 48 Terminologiemanagement ...48, 49 TMS ............. 38, 39, 40, 41, 42, 61 Trennung von Inhalt und Layout

................ 12, 54, 57, 83, 88, 89 Übersetzung ...... 27, 30, 39, 41, 42 Verständlichkeit ............ 20, 22, 80 Vorgehensmodell .. 29, 30, 86, 121 Was-macht-wer-Matrix... 18, 19, 86 Wiki .......................................... 69 XML .44, 45, 46, 47, 54, 58, 59, 60,

86, 88, 89, 90, 93, 110, 111, 112

Zeichenformatvorlage . 91, 94, 102 Zielgruppe .. 16, 17, 18, 19, 20, 22,

25, 26, 27, 28, 29, 30, 31, 32, 33, 63, 74, 108

Zielprogrammierung 109, 110, 121

9.5 Über den Autor Marcel Saft hat Technische Redaktion ab 2004 auf dem 2. Bildungsweg an der Hochschule Karlsruhe studiert. 2009 schloss er sein Studium als Diplom-Technikredakteur (FH) ab. Nach drei Jahren als angestellter Technischer Redakteur bei einem Doku-Dienstleister bietet er seine Dienste seit 2012 als freiberuflicher Technischer Redakteur an.

Von 2014 bis 2020 war Marcel Saft als Honorardozent für technische Dokumentation für die Universität Rostock tätig. Seit 2014 unterrichtet er zukünftige Technikredakteure im Rahmen von tekom-akkreditierten Weiterbildungen.

Marcels erster Beruf ist Industriemechaniker.



9.6 Über dieses E-Book Dieses E-Book entstand im Sommer 2015 zunächst als Lehrbrief im Auftrag der Universität Rostock. Im Fernstudiengang „Technische Redaktion“ diente der Lehrbrief den Studierenden als Einstieg in dieses spannende Fachgebiet. Ich, der Autor dieses E-Books, unterrichtete in Rostock als Honorardozent die Themen „Standardisieren“ und „Onlinedokumentation“.

Nachdem der Studiengang leider eingestellt wurde, durfte ich den Lehrbrief anderweitig weiterverwenden. Aufgrund der sehr positiven Rückmeldungen von den damaligen Studierenden und von vielen Teilnehmern meiner Weiterbildungen und Seminare, entschied ich mich schließlich dazu, den Lehrbrief in Form dieses E-Books zu veröffentlichen.

Liebe Leserinnen und Leser, wenn Ihnen dieses E-Book geholfen hat, wenn für Sie Fragen offengeblieben sind oder wenn Sie Anregungen haben: Ich freue mich über Ihre E-Mail. Schreiben Sie mir gerne an [email protected].

Wenn Sie gerne etwas für dieses E-Book bezahlen möchten, schlage ich eine Spende an den NABU vor: www.nabu.de/spenden-und-mitmachen/index.html

9.7 Danksagungen Dank Nummer 1 geht an einen der Pioniere der technischen Dokumentation Dietrich Juhl für seine Mühe, dieses E-Book in Gänze zu lesen und zu kommentieren.

Dank Nummer 2 geht an den Korrekturlese-Profi Andreas Düpmann. Mit seinem Textschrubber hat er noch die letzten Buchstabendreher aus diesem E-Book herausgefischt.

Danke schön, Dietrich und Andreas!

9.8 Versionshistorie 01: 11.04.2020, Startversion

Die aktuelle Version des E-Books kann kostenfrei heruntergeladen werden unter www.technische-dokumentation.org. Dort können Sie auch einen Newsletter abonnieren, um z. B. über neue Versionen des E-Books informiert zu werden.


https://www.nabu.de/spenden-und-mitmachen/index.html

https://www.nabu.de/spenden-und-mitmachen/index.html

https://juhl.de/

https://besser-korrektur-lesen.de/


Dienstleistungen und Produkte


10 Dienstleistungen und Produkte Hier könnten auch Ihre doku-relevanten Produkte oder Dienstleistungen erwähnt werden. In den Kapiteln 2 bis 8 sind außerdem Anzeigen möglich. Interesse? Nehmen Sie Kontakt mit mir auf: [email protected]

Auf der Website www.technische-dokumentation.org können Sie Live-Onlineseminare, Videoseminare und Präsenzseminare zu Themen rund um die technische Dokumentation buchen, u. a. „Grundlagen der technischen Dokumentation“ und „Redaktionssysteme und Modularisierung“

Dienstleistungen, Seminare und einen kostenfreien Leitfaden rund um professionelles Korrekturlesen bietet Andreas Düpmann an. Sie finden sein Angebot unter der Adresse Fehler! Linkreferenz ungültig..

Dienstleistungen, Seminare und Fachbücher rund um die technische Dokumentation bietet Dietrich Juhl an. Er ist einer der Pioniere der technischen Dokumentation im deutschsprachigen Raum und sein Buch „Technische Dokumentation“ ist ein Standardwerk. Die Website von Dietrich Juhl: www.juhl.de



https://juhl.de/

Musterlösungen der Lernkontrollen


11 Musterlösungen der Lernkontrollen

11.1 Kapitel 2.10 1. Was ist der Unterschied zwischen interner und externer

technischer Dokumentation?

• Interne technische Dokumentation „beinhaltet alle technischen Informationen über ein Produkt, die im Unternehmen verbleiben“ (VDI 4500 2006, 4).

• Externe technische Dokumentation „beinhaltet alle technischen Informationen über Produkte, die […] für […] Anwender und Verbraucher bestimmt sind“ (VDI 4500 2006, 6).

2. Was sind die beiden wichtigsten Argumente dafür, technische Dokumentation professionell zu erstellen?

• das Unternehmen rechtlich absichern

• die Benutzer befähigen, das Produkt fehlerfrei zu verwenden

3. Welche deutschen Gesetze enthalten eine direkte Forderung nach technischer Dokumentation (auch wenn technische Dokumentation nicht als solche benannt wird)?

• Produktsicherheitsgesetz (ProdSG)

• Produkthaftungsgesetz (ProdHaftG)

• Bürgerliches Gesetzbuch (BGB) § 823

4. Welche Rolle spielen Zielgruppen in der technischen Dokumentation?

• Von der Zielgruppe eines Informationsproduktes hängen unter anderem der Inhalt, die fachliche Tiefe und die Terminologie ab.

5. Welche Aspekte tragen zu einer guten Verständlichkeit von technischer Dokumentation bei?

• logische Reihenfolge der Inhalte

• einfacher Satzbau und einfache Formulierungen

• geeignete Terminologie

• klare und übersichtliche Struktur und Gestaltung



• Konsistenz

• korrekte Rechtschreibung und Grammatik

• geeignete Landessprache

11.2 Kapitel 3.4 1. Welche Probleme können entstehen, wenn in einer

Gebrauchsanleitung ähnliche Informationen (z. B. Handlungsaufforderungen) unterschiedlich dargestellt sind (Formulierung, Strukturierung, Gestaltung)?

• Verständnisprobleme seitens der Leser

• Algorithmen können die Texte schlechter verarbeiten (beispielsweise bei der Übersetzung), dadurch erhöhte Kosten

2. Wie funktioniert ein Translation-Memory-System (TMS)?

• Ein TMS speichert Sprachenpaare von Textsegmenten. Bei erneuten Vorkommen von gleichen oder ähnlichen Textsegmenten zeigt das TMS dem Übersetzer entsprechende Treffer an. Der Übersetzer kann die Treffer übernehmen und ggf. anpassen.

3. Weshalb verursachen inkonsistente Formulierungen erhöhte Übersetzungskosten?

• Weil das TMS dann weniger Treffer liefert, als eigentlich möglich wären. Da ein TMS keinen Sinn erkennen, sondern nur Zeichenketten miteinander vergleichen kann, ist es darauf angewiesen, dass gleiche Inhalte auch gleich formuliert sind.

11.3 Kapitel 4.7 1. Was ist der Vorteil von XML mit Blick auf eine konsistente

Inhaltsstruktur?

• Mittels einer Document-Type-Definition (DTD) kann technisch eine bestimmte Inhaltsstruktur eines XML-Dokuments erzwungen werden.



2. Worum geht es beim Terminologiemanagement?

• Es geht um eine ein-eindeutige Verwendung von Benennungen.

3. Weshalb ist die Trennung von Inhalt und Layout so wichtig?

• Damit die Gestaltung von Informationsprodukten möglichst effizient und konsistent erfolgen kann.

4. Was ist ein Redaktionsleitfaden?

• Ein Redaktionsleitfaden ist ein zentrales, Regelwerk, in dem alle redaktionellen Festlegungen innerhalb einer Technischen Redaktion dokumentiert sind.

11.4 Kapitel 5.6 1. Weshalb ist die Strukturierung nach Handlungszielen am

sinnvollsten für eine typische Gebrauchsanleitung?

• Dieser Aufbau entspricht der Situation, in der sich ein Nutzer einer Gebrauchsanleitung typischerweise befindet. Der Nutzer hat ein Problem oder eine Frage und möchte möglichst direkt Antworten erhalten.

11.5 Kapitel 6.5 1. Was sind die vier Ebenen des Funktionsdesigns?

• Informationsprodukte

• Sequenzmuster

• funktionale Einheiten

• Auszeichnungselemente

2. Was ist eine funktionale Einheit?

• Eine funktionale Einheit steht für einen Informationszweck und enthält verschiedene Festlegungen für diesen.

3. Sollte eine einzelne Schaltflächenbenennung innerhalb einer Handlungsaufforderung mit einer funktionalen Einheit ausgezeichnet werden? Falls nicht, womit sonst?

• Nein, mit einem Auszeichnungselement.



4. Ist die folgende Auszeichnung auf XML-Basis sinnvoll?: <schritt>Klicken Sie auf OK. Die Software ist fertig eingerichtet.</schritt> Falls nicht, weshalb? Und wie wäre es besser?

• Nein, weil Handlungsaufforderung und Handlungsergebnis nicht funktional getrennt sind. Der zweite Satz ist kein Schritt und somit falsch ausgezeichnet. Verbesserung: <schritt>Klicken Sie auf OK.</schritt> <ergebnis>Die Software ist fertig eingerichtet.</ergebnis>

5. Mit welchen Mitteln kann man die vier Ebenen des Funktionsdesigns in MS Word umsetzen?

• für jede funktionale Einheit wird eine Absatzformatvorlage erstellt

• für jedes Auszeichnungselement wird eine Zeichenformatvorlage erstellt

• für jedes Sequenzmuster wird ein Schnellbaustein erstellt

• Dokumentstrukturen werden in Dokumentvorlagen definiert

11.6 Kapitel 7.3 1. Hat DITA etwas mit Modularisierung zu tun?

• Fester Bestandteil von DITA ist die Modularisierung in Inhalten. Jedes Modul – in DITA „Topic“ – soll ein abgeschlossenes Thema behandeln, beispielsweise ein Handlungsziel.

2. Was bedeutet „DITA“ eigentlich?

• „DITA“ steht für „Darwin Information Typing Architecture“.



11.7 Kapitel 8.3 1. Wie stehen Modularisierung und Single-Source-Publishing

zueinander in Verbindung?

• Modularisierung ist die Voraussetzung für Single-Source-Publishing.

2. Weshalb können durch Modularisierung Übersetzungskosten gesenkt werden?

• Übersetzer erhalten nur noch geänderte Module, keine ganzen Dokumente mehr.

Grundlagen der technischen Dokumentation

Documents

Transcript of Grundlagen der technischen Dokumentation