|
Aktuelle Artikel und Nachrichten rund um die technische Dokumentation finden Sie im Nachfolgemagazin der doculine news, den transline tecNews
Cross-Media-Publishing
mit Schematext
Artikel
erschienen in
Ausgabe November 1998
Von
Alexander von Obert
Inhaltsübersicht:
Software-Dokumentation
ist ein ziemlich stressiges Geschäft: Während langer
Phasen der Software-Entwicklung gibt es für den technischen
Redakteur kaum verwertbare Informationen. Mit seiner sprachlichen
Kompetenz könnte er eigentlich so manches beitragen, aber
wer läßt ihn? So ballt sich alles auf die letzte Entwicklungsphase
zusammen, und selbst dann ist das Herstellen von Screenshots ein
höchst riskantes Unterfangen: Heutige Entwicklungswerkzeuge
sind objektorientiert und ermöglichen deshalb, systematische
Änderungen am Programm durchzuführen. Elemente einer
bestimmten Art erhalten ihre Eigenschaften von einer einzigen
Definition – eben der Definition des Objekts.
Eine
einzige Programmänderung kann sich so auf höchst komplexe
Art an vielen Stellen des Programms auswirken. Was der Compiler
für den Programmierer automatisch erledigt, muß der
Redakteur mit viel Gehirnschmalz nachvollziehen. Oder er muß
ganz einfach sämtliche Fenster durchgehen, um diese Änderungen
in der Programmoberfläche zu finden und die Dokumentation
entsprechend anzupassen. Nur wenige Werkzeuge leisten dem technischen
Redakteur dabei wirkliche Hilfe.
Objektorientierung:
Voraussetzung für Cross-Media-Publishing
Besonders
problematisch wird die Arbeit des technischen Redakteurs dann,
wenn er für das Programm Dokumentation in verschiedenen Medien
erstellen soll. Mit herkömmlichen Werkzeugen wird sein Spielraum
schnell auf den kleinsten gemeinsamen Nenner aller benutzten Medien
reduziert:
- Wer sein
Handbuch in DIN A5 quer produziert, kann daraus am Bildschirm
gut lesbare PDF-Dateien erzeugen.
- Werkzeuge
wie Doc-to-Help arbeiten mit einem sorgfältig austarierten
System von Analogien, die sich gleich brauchbar am Bildschirm
und auf dem Papier verwenden lassen.
All diese
Werkzeuge stehen in einer viele Jahrhunderte alten Tradition:
Sie drücken inhaltliche Aspekte indirekt durch Gestaltung
aus. Der Rechner kann mit einem elektronischen Dokument aber bedeutend
mehr anfangen, wenn er irgendwelche Rückschlüsse auf
den Inhalt eines Dokuments nicht indirekt erschließen muß,
sondern ganz offiziell erfährt und verwalten kann.
In letzter
Konsequenz bedeutet das, daß ein Dokument eine exakt definierte
Struktur bekommt, die aus Elementen mit genau definiertem Typ
besteht. Welches Element in welchem Strukturzusammenhang und für
welches Ausgabemedium wie ausgegeben werden soll, ist eine völlig
getrennte Frage.
Ein Element
kann ganz einfach sein – etwa ein einzelnes Wort, das die
Information eines bestimmten Typs enthält. Es kann aber auch
aus verschiedenen Elementen zusammengesetzt sein und intern eine
komplexe Struktur enthalten. So war bislang ein Kapitel "alles
von einer Kapitelüberschrift bis unmittelbar vor die nächste
Kapitelüberschrift oder zum Ende des Dokuments". Entsprechende
Methoden, ein komplettes Kapitel mit der Suchfunktion zu markieren,
kennt jeder technische Redakteur.
Ein objektorientiertes
Werkzeug ermöglicht, gezielt auf das ganze Kapitel zuzugreifen,
und weiß z.B. auch, daß es darin nur ein Element vom
Typ "Kapitelüberschrift" geben darf. Mit all diesem
Wissen über das Dokument kann das Autorenwerkzeug oder der
Formatierer viel tiefer in die medienspezifische Aufbereitung
des Dokuments eingreifen als bisher und z.B. wesentliche Teile
des Ausgabeformats nach festen Algorithmen erzeugen.
Eine gewisse
Ähnlichkeit besteht zu den Serienbrief-Funktionen mancher
Textprogramme: In der Formatdatei setzt man Platzhalter für
Anrede, Wohnort usw. ein. Aber all das sind Insellösungen
für spezielle Aufgabenstellungen und keine abstrakten, allgemeinen
Ansätze wie die Objektorientierung der Softwaretechnik.
In einigen
Jahren wird uns mit XML eine ganz neue Art von Autorensystemen
überrollen, die solche objektorientierten Ansätze verfolgen.
Einstweilen gibt es unterhalb sündhaft teuerer SGML-Infrastruktur
nur recht wenig, was die Bezeichnung objektorientiertes Autorensystem
verdient. Einen der interessanteren Ansätze verfolgt die
Schema GmbH in Nürnberg
mit ihrem Werkzeug Schematext.
Die folgenden
Beispiele zeigen dieses Werkzeug beim Erzeugen von HTML. Das ist
aber nur eines von mehreren denkbaren Formaten – MIF oder
RTF zur Übernahme nach Framemaker oder Winword mit dem Ziel
Papier eingeschlossen.
Alles braucht einen Typ
Was bringt
die Typisierung nun in der Praxis? In einem Hypertext z.B. das
automatische Setzen von wenigstens 80% der Links. Abgesehen vom
Link von der Eröffnungsseite zur Seite "Indices"
sind alle Links im folgenden Beispiel automatisch erzeugt nach
dem Algorithmus "Alle Detailseiten und alle Veranstaltungsseiten
müssen im Index erscheinen."
 |
|
Abb.
1: Indexeinträge entstehen automatisch nach dem Algorithmus
"Detail-Seiten und Veranstaltungshinweise werden in
den Index aufgenommen".
|
Das erscheint
aber erst mit einigen zusätzlichen Überlegungen radikal
anders als bisher. So kann systembedingt keiner dieser Links verlorengehen
oder vergessen werden. Sobald ein entsprechender Knoten erstellt
oder gelöscht wird, erscheinen oder verschwinden sämtliche
Referenzen.
Sehen wir
uns als nächstes den Inhalt des Indexknotens an:
 |
|
Abb.
2: Schematext kennt den vollständigen Algorithmus zum
Erstellen dieser Seite; manuelle Eingriffe sind überflüssig.
|
Diese Seite
wurde mit einer einzigen, unauffälligen Ausnahme automatisch
erzeugt: Das Änderungsdatum wird manuell eingegeben, um hier
genauere Kontrolle zu behalten und z.B. mit dem Beseitigen eines
Tippfehlers nicht eine Datumsänderung auszulösen. Die
Links zu den Detailseiten und zu den Veranstaltungen werden eindeutig
auseinandergehalten und die Indexeinträge alphabetisch sortiert.
Sobald eine Seite umbenannt wird, ändert sich auch der Eintrag
im Index - gegebenenfalls einschließlich der alphabetischen
Sortierung.
Die Automatisierung
geht aber noch deutlich weiter. Der Knoten "Brot darf weiter
ohne Handbuch verkauft werden" betrifft eindeutig sowohl
den Handbuchschreiber Hans-Rudolf als auch den Bäcker Frühauf.
Also werden (ausnahmsweise manuell) Links von diesen beiden Seiten
angelegt, der Link vom Index erscheint automatisch:
 |
|
Abb.
3: Der Autor verbindet den Knoten vom Typ "Details"
mit zwei Knoten vom Typ "Firma", die restliche
Hypertext-Struktur erzeugt (oder entfernt) Schematext algorithmisch.
|
Betrachtet
man die daraus erzeugte Seite, erscheinen die Rückwärts-Links
zum Bäcker und zum Handbuchschreiber. Das ist zwar keine
Eigenschaft von HTML, aber solche Rückwärts-Referenzen
kennt auch manches andere Werkzeug. Überraschend sind aber
die Verweise zu Labskaus und Sonntagsbrötchen, denn hier
wirkt ein wesentlich abstrakterer Mechanismus mit:
 |
|
Abb.
4: Der Autor legt den Namen und die Verbindungen zu den
beiden Firmen fest. Den Rest der Seite erzeugt das Programm
automatisch (also auch immer gleich).
|
Die Sonntagsbrötchen
sind der "Schwesterknoten bezüglich des Bäckers"
und der Labskaus ist der "Schwesterknoten bezüglich
des Handbuchschreibers". Dieser Mechanismus ermöglicht
das chronologische Durchblättern aller Schwesterknoten, ohne
über den Mutterknoten gehen zu müssen. Der Autor legt
nur noch die Reihenfolge fest, alles andere erledigt das Autorenwerkzeug.
Ganz nebenbei
enthält jede Seite automatisch Links zur Eröffnungsseite,
zum Index und zum Schreiben einer E-Mail an den Autor, aber das
sind konstante Elemente und folglich auch mit vielen anderen Werkzeugen
möglich. Das hier benutzte Hypertextsystem mit 16 Knoten
bringt es so auf deutlich über 80 Links. Manuell wäre
das bereits ein Wartungsalptraum.
Die hier
gezeigte Umsetzung des elektronischen Dokuments ist nur eine von
vielen Ausgabemöglichkeiten. Die Struktur kann mit anderen
Algorithmen auch anders umgesetzt werden. Eine sogenannte Linearisierungs-Funktion
erlaubt etwa festzulegen, in welcher Reihenfolge die einzelnen
Seiten in der Papierform erscheinen sollen. Man wird wohl für
die einzelnen Firmen Kapitel erzeugen und die Details in Unterkapitel
umsetzen. Unsere Seite "Brot darf weiter ohne Handbuch verkauft
werden" wird man vielleicht dem Bäcker zuschlagen und
zum Handbuchersteller nur einen Verweis erzeugen.
Anders die
Veranstaltungen: Die werden auf einer Seite "Veranstaltungen"
zusammengefaßt. Das ist alles kein grundsätzliches
Problem, denn das Autorenwerkzeug kann die unterschiedlichen Elemente
des Systems problemlos auseinanderhalten.
...aber
erst planen!
Eine ganz
typische Eigenschaft solcher inhaltlich strukturierter Systeme
fällt auf: Der Autor bekommt einen recht genauen (oder auch
starren) Rahmen geliefert, den er mit kleinen, genau umrissenen
Inhalten zu füllen hat. Beim Aufbau der Struktur werden bereits
Überschriften und Verweise festgelegt. Zusammen mit dem Seitentyp
und dem entsprechenden Kapitel des Style Guides weiß der
Autor ohne große Erklärungen, was er jetzt schreiben
muß.
So bahnt
sich auch eine Art der Arbeitsteilung an, die bislang so nicht
denkbar war: Der Projektleiter definiert die einzelnen Seiten
oder Kapitel und ihren Zusammenhang, der Autor braucht diesen
exakt vorgegebenen Rahmen nur noch mit Maschinenhilfe auszufüllen.
Für jedes Element findet er im Redaktionshandbuch eine Anleitung,
so daß Strukturierung, Eindringtiefe und Formulierungen
einfach und einheitlich sichergestellt werden können. Wer
sich von einer solchen Arbeitsweise in seiner "künstlerischen
Freiheit" eingeschränkt fühlt, sollte eines bedenken:
Er schafft kein Kunstwerk, sondern ein standardisiertes Industrieprodukt.
Die in den
Bildern gezeigten Seiten ohne redaktionellen Inhalt sind bereits
mit einer Vielzahl von Elementen versehen. Für den Autor
ist das außerordentlich bequem, weil er sich hier um nichts
mehr zu kümmern braucht. Aber irgendwann muß dieser
ganze Rahmen ausformuliert worden sein.
Hier schlägt
die Stunde des Spezialisten: Kaum eines dieser Werkzeuge ist einfach
zu konfigurieren, egal ob Framemaker + SGML oder Schematext. Andererseits
sind das Aufgaben, die nur gelegentlich anfallen – einmal
bei der Konzeption des Systems und dann bei systematischen Änderungen
und Erweiterungen. Sind diese Änderungen aber einmal eingebaut
und ausgetestet, kostet die Umgestaltung des ganzen Systems nur
noch einen einzigen Übersetzungslauf. Wer sagt denn, daß
so etwas nur bei der Programmentwicklung denkbar ist...
|
