Was ist Single-Source-Publishing?

Wörtlich übersetzt bedeutet das Schlagwort aus einer Quelle veröffentlichen. Das Ziel der meisten Ansätze ist, aus einem Quelldokument Ausgaben in mehreren Formaten zu erzeugen - etwa gedrucktes Handbuch und Online-Hilfe. Das Thema ist aber etwas vielschichtiger, als es allgemein diskutiert wird.

Der konventionelle Ansatz:
Ein Quelldokument, mehrere Ausgabeformate

Das gemeinsame Merkmal solcher Ansätze ist, daß der Autor ein Quelldokument mit speziellen Eigenschaften versieht, die eine sinnvolle Konvertierung in mehrere Formate ermöglicht. Solche Quelldokumente müssen sich an bestimmte Vorgaben halten, damit die automatische Umsetzung fehlerfrei funktionieren kann. Gewöhnlich gibt es bestimmte Äquivalenzen; eine Überschrift bedeutet den Anfang eines neuen Topics in der Online-Hilfe und ein Verweis auf einen Glossareintrag wird zu einem Link, der ein Pop-Up-Fenster öffnet. Auch gibt es praktisch immer Möglichkeiten, bestimmte Informationen nur in bestimmten Ausgabemedien zu verwenden - also etwa Screenshots in der kontextsensitiven Online-Hilfe auszublenden.

Typische Vertreter dieser Technik sind Winword-Aufsätze wie Doc-to-Help oder Office-Help. Sie versprechen einen deutlichen Rationalisierungsgewinn unter der Voraussetzung, daß (Papier-) Handbuch und Online-Hilfe praktisch identische Inhalte haben. Auch fällt es auf diesem Weg relativ leicht, statt HTML-Help Javahelp o.ä. zu erzeugen. Manchmal wird es allerdings ziemlich umständlich, mit festen 1:1-Beziehungen zwischen irgendwelchen Papier- und Online-Merkmalen zu arbeiten.

Eine leistungsfähigere Variante des Single-Source-Publishing können XML-Systeme bieten, weil sie ihre Inhalte auf einer abstrakteren Ebene auszeichnen. Es gibt eben mehr als Kapitel mehrerer Hierarchieebenen oder Tabellen. Statt dessen weiß der Rechner "das ist ein Warnhinweis" oder "hier ist die Gerätebezeichnung". So werden bedeutend abstraktere Umsetzungen möglich, die den jeweiligen Zielmedien gerechter werden. Logisch, daß solche Systeme bedeutend mehr Konfigurationsaufwand erfordern. Die Hersteller werden dem oft dadurch gerecht, daß sie voll vorkonfigurierte Programmpakete für bestimmte Einsatzzwecke anbieten. Bei XML-Systemen bietet sich z.B. Docbook als Basis an.

Sonderwünsche des Anwenders lassen sich in XML-System zwar in weiten Grenzen erfüllen, werden aber schnell teuer: Die Strukturbeschreibung (DTD) der Dokumente muß erweitert, die Ausgabefilter müssen an vielen Stellen und für jedes einzelne Ausgabemedium angepaßt werden. Kaum ein Technischer Redakteur wird hier noch selber die Hand anlegen können, anders als bei der Anpassung von Druckformaten bei den Winword-Aufsätzen.

Weg vom linearen Dokument

Alle bislang geschilderten Ansätze bauen auf einer bevorzugten Anordnung der Information auf, dem linearen Dokument. Dabei bestehen Bedürfnisse, ein Dokument aus einzelnen Bausteinen aufzubauen:

• Bestimmte Teile eines Handbuchs sind vom Inhalt des Handbuchs unabhängig und werden getrennt gepflegt - etwa die allgemeinen Warmhinweise oder das Verzeichnis der Servicestellen.
• Viele Produkte eines Herstellers sind sich ähnlich, entsprechend tauchen manche Passagen in vielen Anleitungen auf. Die sollen dann immer einheitlich sein und müssen eigentlich auch nur einmal übersetzt werden. Im Extremfall kann der Technische Redakteur auch fremdsprachliche Anleitungen zusammenstellen, indem er die entsprechenden Textbausteine in der neuen Sprache wie im deutschen Original zusammensteckt. Falls noch ein paar Details fehlen, übergibt er genau die in die Obhut des Übersetzers. Als Hintergrundinformation bekommt der Übersetzer vielleicht eine zielsprachliche Fassung der Anleitung, in der noch ein paar Absätze deutsch sind.
• Wenn ein solcher Baustein geändert wird, dann sollte die Änderung möglichst auch in allen anderen zukünftigen Verwendungen eingesetzt werden; bereits freigegebene und veröffentlichte Anleitungen dürfen aber nachträglich nicht mehr verändert werden.

Solche Anforderungen erfüllen Content-Management-Systeme. Im Endausbau kann die Fertigungssteuerung die halbautomatische Produktion der Anleitungen anstoßen: Aus der Stückliste des Produkts ergibt sich der Inhalt der Anleitung. Das Zielland bestimmt die Ausgabesprache und ggf. muß noch die Gestaltung der jeweiligen (Handels-) Marke berücksichtigt werden. Am Ende des Produktionsprozesses steht ein Print-on-Demand-System, das genau die gewünschte Anzahl von Anleitungen produziert. Ein Druckschriftenlager gibt es nicht mehr. Der Technische Redakteur macht in erster Linie Qualitätssicherung, betreut ggf. die beschriebenen Übersetzungsarbeiten, und schreibt nur noch sehr selten komplette Anleitungen neu.

Der nächste Schritt:
jede Information nur noch einmal halten

An einem Problem haben alle bisher geschilderten Ansätze wenig geändert: Viele Informationen erscheinen im Quelldokument an vielen Quellen, entsprechend unsicher ist ggf. der Änderungsdienst. Ändert eine Firma ihren Namen, so kann man alle Vorkommen des Namens einfach durch Volltextsuche finden. Geht es dagegen z.B. um Funktionsänderungen bei Software, fällt das Finden aller Instanzen der Information bedeutend schwerer.

Einen Ansatz, den ich schon gelegentlich ausprobierte, ermöglicht das Autorensystem Schematext: Das Quelldokument wird zunächst entsprechend der Struktur des Produktes aufgebaut, die Strukturen der letztlich erzeugten Dokumentationen ist ein gleichberechtigtes, völlig getrenntes Thema. Für derartige Mechanismen gibt es mittlerweile mit Topic Maps nach ISO 13250 auch einen Formalismus. Ein Beispiel, um das Vorgehen zu illustrieren:

• In einem Programm ermögliche ein bestimmtes Modul die Ein- oder Ausgabe bestimmter Werte. Genau die beschreibt ein Datenmodul im Autorensystem.
• Überall in der Anleitung, wo diese Werte benutzt werden, wird das Datenmodul (per Verweis) eingebunden.
• Das Quelldokument enthält so u.a. die Information dieses Datenmodul wird an folgenden Stellen benutzt. Eine entsprechende Information sollten die Programmierer aus ihrem Entwicklungssytem erhalten können, es gibt also eine völlig neue Möglichkeit der Qualitätssicherung für die Dokumentation.
• Wenn die Programmierer ein Modul ändern, dann braucht auch der Technische Redakteur nur noch eine Stelle zu ändern.

Ein bestimmer Baustein kann also an vielen Stellen verwendet werden. Zudem lassen sich Abhängigkeiten berücksichtigen, die sich aus der jeweiligen Umgebung ergeben. Hat das Programm beispielsweise einen Expertenmodus, so lassen sich in der Ausgabe die fortgeschrittenen Funktionen im Kapitel Die ersten Schritte ausblenden. Das ist ggf. eine Eigenschaft der Datenmodule, die Parameter für den Expertenmodus beschreiben.

Das Quelldokument, sofern es überhaupt noch als solches existiert, enthält also zwei oder mehr gleichberechtigte Giederungen. Dabei ist es

• nicht erforderlich, daß jede Gliederung auch alle Datenmodule nutzt,
• völlig normal, wenn ein Datenmodul vielfach eingebunden wird,
• durchaus möglich, daß ein Datenmodul seinerseits wieder aus Datenmodulen mit unterschiedlichen Eigenschaften besteht und sich diese Eigenschaften in jedem Ausgabemedium unterschiedlich auswirken,
• oft sinnvoll, daß bei der Ausgabe Informationen erscheinen, die aus Struktur des Quelldokuments algorithmisch und über diverse Zwischenstufen gewonnen wurden.

Das Quelldokument wird so immer mehr zu einer Sammlung von Datensätzen, ähnlich wie der Inhalt einer Datenbank. Mit derartigen Mechanismen entstehen in dieser Website die Navigationsspalten. Ein Beispiel für eine bewußt unvollständige Gliederung ist auf der Indexseite dieser Werbsite die Liste Die letzten Änderungen und die daraus automatisch erzeugten roten Pfeile mit der gleichlautenden Bezeichnung in den entsprechenden Detailseiten. Damit können die Stammbesucher dieser Website durch jene Seiten blättern, an denen ich zuletzt wesentliche Änderungen machte.

Zum Ende noch ein komplexeres Beispiel aus dem Wissensmanagement - für einen Kunden erzeugte ich hier eine Intranet-Website mit 2.900 Seiten und 94.000 Links:

• Bei der Reparatur von Baugruppen gebe es Informationen, die über die Materialnummer der Baugruppe zugänglich seien. In Datenmodulen vom Typ Materialnummer stehen aber ausschließlich Informationen, die wirklich nur mit diesem einen Typ von Baugruppe verbunden sind. Dazu gehört weder der Verwendungsnachweis (in jeder Anlage stecken Baugruppen mit unterschiedlicher Materialnummer) noch der Name des Entwicklers - der hat ja noch mehr Baugruppen entwickelt.
• Für jede zur Reparatur vorgelegte Baugruppe wird ein Datenmodul vom Typ Seriennummer/Reparaturnummer angelegt. Hier werden z.B. Fehlerbeschreibung und ergriffene Maßnahmen dokumentiert, die Materialnummer steht aber ausdrücklich nicht darin; die wird durch eine Beziehung zum entsprechenden Datenmodul vom Typ Materialnummer eingebunden.
• Entsprechend gibt es einen Datenmodultyp Anlage, der mit dem Datenmodultyp Materialnummer über eine Beziehung vom Typ Verwendungsnachweis verbunden ist.
• Mit Datenmodulen vom Typ Anlage kann ein Datenmodul vom Typ Fehlercodeliste verbunden sein.

Mit dieser Datenmodellierung ist es jetzt kein Problem mehr, in die Ausgabeinstanz eines Datenmoduls vom Typ Seriennummer/Reparaturnummer Links zu den Fehlercodelisten jener Anlagen einzubinden, in denen die Baugruppe benutzt wird. Auch lassen sich Kreisläufer erkennen und verlinken, indem bei allen Baugruppen mit der gleichem Materialnummer die Seriennummern verglichen werden.

Fazit

Früher gab es für Technische Redakteure in erster Linie Werkzeuge, die sich bis auf die Schreibmaschine zurückführen ließen. Auf der anderen Seite entstanden Programmsysteme wie Datenbanken, die völlig andere Einsatzgebiete haben. Der Graubereich zwischen beiden Systemen wird immer kleiner mit der Folge, daß der Technische Redakteur mit immer abstrakteren Werkzeugen arbeiten muß und zunehmend den Kontakt zum Papier verliert - selbst dann, wenn sein Endprodukt noch auf Papier ausgeliefert wird.

Diese Seite bookmarken bei: