Dokumente versus Topics

(Auszug aus "DITA - Der neue Standard für Technische Dokumentation" von Johannes Hentrich)

Noch immer ist in der Technischen Dokumentation das gedruckte Handbuch das zentrale Medium. Da kann auch die Tatsache nicht darüber hinwegtäuschen, dass der Computer und die auf ihm verwendeten Online-Hilfen einen immer größeren Raum in der Technischen Dokumentation einnehmen.

Das mit der Erstellung eines Buchs angewendete Paradigma ist bei den Technischen Redakteuren so tief verwurzelt, dass eine lineare Anordnung der Inhalte und das entsprechend buchgerechte Verfassen der Inhalte fast automatisch erfolgt.

Dabei ist das Konzept, das hinter Topics steht, einfach und schnell zu verstehen. Es gilt eine Frage zu beantworten, sodass inhaltlich eigenständige Informationseinheiten entstehen.

Die Praxis zeigt jedoch, dass das Schreiben von Topics häufig als eine unvollständige Art des Schreibens empfunden wird. Das Verfassen von Topics widerspricht in vielem dem, was der Technische Redakteur über das Schreiben gelernt hat.

So stehen beim klassischen Schreiben zu Beginn die Überlegungen, welches Informationsprodukt geschaffen werden soll. Sind es beispielsweise eine Bedienungsanleitung, eine Installationsanweisung oder ein Anwenderhandbuch? Das zu erstellende Informationsprodukt wird dann in die Hände eines Technischen Redakteurs gegeben, der sich fortan mit der Erstellung des Dokuments befasst.

Die dokumentenzentrierte Erstellung von Technischer Dokumentation ist heute eine gängig anzutreffende Vorgehensweise in vielen Technischen Redaktionen.

Sobald festgelegt wurde, welche Art von Dokument anzufertigen ist, wird als Nächstes ein Inhaltsverzeichnis erstellt, in welchem die Struktur und damit die in Zukunft im Dokument befindlichen Inhalte festgelegt werden. Dabei bedient man sich häufig einer Top-Down-Strategie, das heißt, der mögliche Inhalt wird in einzelne Kapitel, Abschnitte und manchmal sogar schon in Absätze gegliedert. Dabei wird genau überlegt, in welcher Reihenfolge die einzelnen Kapitel im Buch erscheinen sollen oder müssen und wie die „Übergänge“ zwischen den einzelnen Kapiteln zu bewerkstelligen sind. Bei dieser Vorgehensweise wird häufig die zu vermittelnde Information über verschiedene Kapitel oder Abschnitte vergeteilt, mit der Absicht, in einem früheren Kapitel einführende Informationen zu bieten und dann in einem späteren Kapitel die Details zu präsentieren. Diese typische „buchartige“ Präsentation von Informationen geht mehr oder minder immer davon aus, dass ein Handbuch vom Leser wie ein Roman gelesen wird: vorn anfangen und sich dann bis zum Schluss durchbeißen.

Oft dient das Inhaltsverzeichnis dazu, Entscheidungsträgern einen Einblick in die Arbeit des Technischen Redakteurs zu gewähren. Das Inhaltsverzeichnis wird dann als Entscheidungsgrundlage herangezogen, ob das Dokument in der geplanten Form erstellt werden soll.

Danach beginnt der Erstellungsprozess, der jedoch nicht linear sein muss. Es ist durchaus möglich, dass zuerst die Kapitel 3 und 4 erstellt werden, bevor die beiden ersten Kapitel geschrieben werden. Dennoch kann man hier von einem linearen Schreiben sprechen, da die Konzeption des Dokuments dahin gehend ausgerichtet ist, dass die Kapitel einer bestimmten Reihenfolge gehorchen, was bedeutet, die Kapitel können nicht beliebig im Dokument platziert werden. Die Linearität in einem Dokument wird durch zwei Elemente hergestellt: die Verwendung von Bezügen und die Herstellung eines Kontexts. Die damit verbundenen Konstrukte und Formulierungen sorgen dafür, dass Inhalte aus Büchern nur schwer zu Topics zu separieren sind, denen Bezüge und Kontexte fremd sind.

Layoutzentriertes Erstellen von Inhalten

Wenn heute ein Autor ein Buch bei einem Verlag veröffentlichen will, so muss er dem Verlag nur den Inhalt liefern. Die Produktion des Buchs, das heißt insbesondere die Gestaltung des Layouts, das Setzen des Textes und die Einbindung der Grafiken wird vom Verlag übernommen. Davon kann ein Technischer Redakteur, wenn er ein Handbuch erstellen muss, in der Regel nur träumen.

Nach wie vor muss ein Technischer Redakteur bei einem Handbuch meist nicht nur die Inhalte erstellen, sondern er muss zumindest auch fortwährend das Layout kontrollieren. Er muss ständig gleichzeitig der Herrscher über zwei Produktionsprozesse sein.

Sollen zum Beispiel mit Word oder FrameMaker gedruckte Handbücher erstellt werden, so erweisen sich Seitenumbrüche oft als eine wahre Sisyphus-Arbeit. Hier noch einen Absatz auf die Schnelle dazu, dort noch einen Absatz löschen, weil die Inhalte falsch oder nicht mehr aktuell sind, und schon wieder besteht die große Gefahr, dass irgendwo im Dokument die Seitenumbrüche nicht mehr stimmen. Ein wahrer Albtraum, wenn der Abgabetermin unmittelbar bevorsteht.

Häufig fällt die laufende Kontrolle des Layouts auch dann nicht weg, wenn man in Publishing-Werkzeugen mit strukturierten Dokumenten arbeitet, wie das beispielsweise bei FrameMaker mit SGML/XML der Fall ist. Zwar steuert eine vorgegebene Struktur die mögliche Eingabe von Inhalten, aber oft nur in sehr eingeschränktem Maße das Layout. So ist auch hier der Technische Redakteur nicht davon befreit, das Layout stets im Auge zu behalten.

Die WYSIWYG-Redaktionswerkzeuge haben seit ihrem Aufkommen das layoutzentrierte Erstellen von Inhalten kultiviert. Obwohl der Inhalt genauso wenig ohne Layout auskommen kann wie das Layout ohne Inhalt, bedeutet jedoch die gleichzeitige Produktion, dass häufig nichts Halbes und nichts Ganzes entsteht. Denn wenn sich der Technische Redakteur auf die Inhalte konzentrieren muss, kann er ständig durch das Layout abgelenkt werden, weil vielleicht eine Tabelle wegen einer zusätzlichen Zeile unglücklich umgebrochen wird oder weil plötzlich ein Loch im Dokument klafft, da eine Grafik entfernt werden musste. Umgekehrt kann bei einer Layoutkontrolle der Technische Redakteur ein Fehler in der Terminologie auffallen, der im gesamten Dokument korrigiert werden muss. Das kann dann zur Folge haben, dass das Layout nicht mit der Konsequenz geprüft wird, wie das eigentlich notwendig wäre.

Das layoutzentrierte Erstellen von Inhalten hat aber noch eine weitere schwerwiegende Konsequenz zur Folge: Inhalte werden fast ausschließlich für einen bestimmten Kontext erstellt. Häufig handelt es dabei um einen printbasierten Kontext, das heißt, Inhalte werden in einer buchgerechten Form verfasst. Damit verbunden ist in der Regel eine implizite Voreingenommenheit, wie Inhalte geschrieben und organisiert werden müssen. Diese auf dem Buchparadigma basierenden Annahmen erweisen sich aber oft als wenig hilfreich, wenn es darum geht, Inhalte für andere Medien zu produzieren. Online-Hilfen sind hier als markantestes Beispiele zu nennen, die nicht dem Buchparadigma unterliegen, weder vom Layout noch von den benötigten Inhalten her.

Besonders schwierig wird es für den Technischen Redakteur dann, wenn er Online-Hilfen mit Programmen erstellen muss, die für das layoutzentrierte Erstellen von Inhalten konzipiert worden sind. Dies geschieht häufig dann, wenn zum Beispiel mit Word die Print-Dokumentation erstellt wurde und dann, „der Einfachheit“ wegen daraus noch die Online-Hilfe generiert werden soll. Technisch ist das durchaus möglich. Den daraus gewonnenen Ergebnissen sieht man jedoch in den allermeisten Fällen an, dass sie das Produkt einer layoutzentrierten Produktionsweise sind.

Problemfall: Redaktionsumgebung

An leistungsfähigen Software-Werkzeugen zur Erstellung von Technischer Dokumentation gibt es keinen Mangel. Für die Erstellung von Handbüchern reicht die Palette von komplexen Textverarbeitungsprogrammen bis hin zu ausgefeilten Publishing- beziehungsweise Satzsystemen. Auch bei der Erstellung von Online-Hilfen kann ein Technischer Redakteur auf ausgefeilte Software-Werkzeuge zurückgreifen – von einfachen Editoren für HTML-Seiten bis hin zu kompletten Entwicklungsumgebungen für umfangreiche Online-Systeme.

Obwohl viele Systeme in ihrer Funktionalität sehr umfangreich sind, bleibt ihr Einsatzgebiet auf ein bestimmtes Gebiet beschränkt. So sind zum Beispiel Word und FrameMaker vor allem dazu gedacht, Dokumente für den Printbereich zu erstellen, auch wenn es zahlreiche Zusatzmodule gibt, die es ermöglichen sollen, mit diesen Systemen auch Online-Hilfen erstellen zu können. Die meisten Werkzeuge sind eben darauf ausgerichtet, Informationsprodukte für ein bestimmtes Medium erzeugen zu können.

Selbst dann wenn das Werkzeug die Speicherung der Daten in einem medien-neutralen Datenformat wie XML erlaubt, ist die Produktion der Inhalte alles Andere als medienneutral. So scheint es daher bei einem XML-Editor stets wichtiger zu sein, dass die WYSIWYG-Funktionalität im vollen Umfang gegeben ist, als dass die XML-Dokumente validiert werden können. Der Gedanke, Inhalte zu produzieren, von denen zunächst nicht bekannt ist, wie sie in den Ausgabemedien aussehen, ist für den Technischen Redakteur nach wie vor befremdlich.

Daher fällt es Technischen Redakteuren, die es bisher gewohnt waren dokumenten- und layoutzentriert Informationsprodukte zu produzieren, besonders schwer, sich auf eine topicbasierte, vom Dokument losgelöste Produktion von Inhalten einzulassen. Und die Umstellung fällt noch schwerer, wenn bestehende Software-Werkzeuge, die bisher auf ein layoutzentriertes Publizieren ausgerichtet waren, zu einem XML-Editor umgerüstet werden und dabei der Technische Redakteur im Glauben belassen, dass sich nichts weiter geändert hat, als dass die Dokumente jetzt in XML abgespeichert werden müssen.

Das Erstellen topicbasierte Informationen erfordert daher eine konsequente Unterstützung in der verwendeten Redaktionsumgebung. Eine Loslösung vom Buchparadigma muss auch durch die entsprechenden Werkzeuge unterstützt werden. Mit zunehmender Popularität von DITA werden die XML-Editoren immer komfortabler, sodass die neue Schreibtechnik, das heißt die Erstellung von Topics, auch von dieser Seite mehr und mehr unterstützt wird. Bleibt nur noch der Schritt, den Technischen Redakteur davon zu überzeugen, dass auch das Schreiben von Topics „richtiges“ Schreiben bedeutet.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema DITA bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2008 XLcontent Verlag
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "DITA - Der neue Standard für Technische Dokumentation" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

XLcontent Verlag, Pflegerstraße 40, 81247 München