Fachbeiträge
Mehrdimensionale Dokumente für mehrdimensionale Strukturen
Fast schon eine Binsenweisheit: Elektronische Medien verlangen eine andere Informationsaufbereitung als das Medium Papier, es gilt “nur” die medienspezifischen Vor- und Nachteile zu berücksichtigen. So bieten sich für den Bildschirm statt einer linearen Informationsstruktur wie im gedruckten Buch mehrdimensionale Gliederungen an, bei denen die Information nur noch an einer Stelle vorgehalten wird. Verweise statt Redundanz also – aber wie lassen sich diese vielfältigen Verweise sinnvoll generieren und verwalten? Alexander von Obert demonstriert einige Anwendungsbeispiele, die mit dem Autorensystem Schematext realisiert wurden.
Von Alexander
Inhaltsübersicht:
Wer heute Gedanken zu Papier bringen will, sucht unwillkürlich
nach dem roten Faden. So handhaben wir es seit Generationen. Allerdings
ist uns in den letzten Jahren das Papier als primärer Informationsträger
abhanden gekommen. Der Bildschirm ist in so mancher Beziehung ein
schlechter Ersatz, er bietet aber auch ganz eigene Vorteile. Die
lassen sich aber bei Dokumenten bislang nur begrenzt nutzen. Speziell
gilt das für die Möglichkeit, mehrdimensionale Gliederungen
(mehrere "rote Fäden") zu nutzen und eine bestimmte
Information nur noch an einer Stelle zu halten.
Es ist nur
zu verständlich, dass neue Werkzeuge auf Herkömmlichem
aufbauen; wirklich neue Ideen brauchen Zeit zum Reifen. Wer sich
die ersten Gutenberg-Bibeln ansieht, entdeckt kaum Unterschiede
zu den Handschriften dieser Zeit – der entscheidende Unterschied
war die Möglichkeit zur vergleichsweise preiswerten und schnellen
Vervielfältigung. Die wertvollen Handschriften wurden auswendig
gelernt. Inhaltsverzeichnis, Index usw. waren deshalb überflüssig.
Es dauerte rund 100 Jahre, bis die preiswertere Herstellung der
Bücher das Auswendiglernen überflüssig machte, die
Bedürfnisse der Nutzer sich entsprechend wandelten und Inhaltsverzeichnisse
oder Indizes zum selbstverständlichen Bestandteil von Büchern
wurden.
Einen ähnlichen
Schritt vollziehen wir gegenwärtig, ohne dass wir so viel Zeit
hätten: Das Buch mit seiner unveränderlichen Struktur
des “Vorne" und “Hinten" löst sich auf
in viele kleine Informationseinheiten. Aber noch bleibt meist die
herkömmliche lineare und hierarchische Struktur erhalten. Egal
ob Frontpage oder XML: Verstöße gegen die eine –
lineare – Struktur bleiben der Sonderfall. Das typische Ergebnis:
Sobald der Nutzer ein Detail gefunden hat und an einer anderen Stelle
im Dokument weitermachen will, muss er sich einige Dinge merken
oder notieren und die nächste Stelle in einem neuen Schritt
suchen.
Viele Website-Designs
versuchen, diese Suche so einfach wie möglich zu machen: Über
eine Navigationsleiste stehen die obersten Kapitel immer zur Verfügung,
und die Struktur der Website bleibt so flach wie möglich. Die
Suche wird so zwar müheloser, es bleibt aber eine Suche. In
vielen Fällen wüsste der Autor sehr wohl, wohin der Nutzer
eigentlich möchte. Allein: Kaum ein Werkzeug unterstützt
solche Querverbindungen gut genug. Spätestens wenn bei der
Pflege des Dokuments einzelne Knoten verändert oder entfernt
werden, kann kaum ein Werkzeug alle Querverbindungen jederzeit überblicken
und prüfen.
 |
Der Stand der Technik: Die Navigationsleiste ermöglicht jederzeit den Zugriff auf die einzelnen Kapitel, die in sich möglichst flach strukturiert sind. Der Nutzer kann jede Seite über ein paar Mausklicks erreichen, aber er muss nach wie vor selbst suchen. |
Wie sähe
die Alternative aus? Jede Seite müsste Verweise zu allen Seiten
enthalten, die den Nutzer im aktuellen Zusammenhang interessieren
könnten. Ein paar Beispiele:
- Ein Software-Tutorial enthält Verweise zu den Detailbeschreibungen im Referenzteil, und der Referenzteil enthält wiederum Verweise auf das Tutorial.
- Ein elektronischer Tagungsband enthält direkte Verweise zwischen den Vorträgen und ihrem Referenten – wieder in beiden Richtungen.
Konventionell
würde man Einführungshandbuch und Referenzhandbuch nebeneinander
legen und mit beiden Büchern parallel arbeiten – mit Fingern
in beiden Bänden. Am Bildschirm geht das nicht. Die Möglichkeit,
mit jeweils einem Mausklick hin- und herzukommen, sollte aber eine
gute Alternative sein.
Der elektronische
Tagungsband liefert sogar eindeutigen Mehrwert: Ein gut organisierter
Tagungsband enthält z.B. ein nach Themenschwerpunkten sortiertes
Vortragsverzeichnis und ein Personenregister. Die Möglichkeit,
mit einem Mausklick vom Vortrag zur Referentenvorstellung und mit
dem nächsten zu einem anderen Vortrag des gleichen Referenten
zu springen, ist da eindeutig komfortabler.
 |
Hier hat der Nutzer direkten Zugriff auf alles, was ihn unmittelbar interessieren könnte: Die Vortragsliste des Themenschwerpunkts (Track), die alphabetische Vortragsliste (samt einer Möglichkeit zum “Blättern") und die Referentenvorstellung. Der gesamte Kopf dieser Seite entstand automatisch aus der Dokumentenstruktur. |
Ein weiterer
Schritt ist, die sowieso nötigen Referenzen mehrfach auszuwerten:
Wenn das Autorenwerkzeug weiß, wer der Referent eines Vortrags
ist – warum sollte es den Namen des Referenten dann nicht gleich
selbst in den Vortrag einsetzen? Damit erreicht man einen enormen
Vorteil: Alle diese Verweise werden zwangsweise konsistent und lassen
sich auch viel leichter pflegen.
Nehmen wir
an, zwei der Referenten unserer Tagung hießen Hans Meier;
im Korrekturlauf stelle sich aber heraus, einer davon hieße
Hans Maier. Bei herkömmlichen Autorensystemen hätte der
Lektor das große Problem, die Vorträge der beiden Referenten
auseinander zu halten. Mit Hilfe des oben beschriebenen Referenzmechanismus
lassen sich Probleme wie dieses ganz leicht lösen: Die eine
Referentenvorstellung wird geändert; alle anderen Vorkommen
des Namens sind nur Referenzen, die automatisch folgen.
 |
Das Inhaltsverzeichnis der Zeitschriftenausgabe 2-99 entsteht allein aus der Struktur des Quelldokuments: Der Artikel CL16 stammt von Ursula Reuther www.tc-forum.org. |
Aus den letzten
Ausführungen wird klar, dass das Quellformat des Autorenwerkzeugs
und das Ausgabeformat kaum identisch sein können: Handelsübliche
Formate wie PDF, XML und HTML verfügen nicht über die
entsprechenden Mechanismen – weshalb XML-Systeme häufig
mit Datenbanken arbeiten und dadurch sehr aufwendig sind. Grundsätzlich
ist das nichts Neues: Winword-Dateien werden vorzugsweise mit Winword
be- und verarbeitet, um am Ende ausgedruckt oder nach HTML, XML
oder PDF umgewandelt zu werden.
Wenn das Autorensystem
aber, wie schon angedeutet, sehr viel mehr als bislang üblich
über das Dokument weiß, dann kann es auch in die Ausgabe
viel tiefer eingreifen:
- Die Ausgabe in handelsübliche Formate kann recht individuell an Format oder Verwendungszweck angepasst werden, indem z.B. bestimmte Teile des Dokuments ausgeblendet werden.
- Die Struktur des Dokuments kann unterschiedlich interpretiert werden.
Als Beispiel
für den letzten Punkt bietet sich die Korrektur- und Übersetzungsphase
einer Online-Dokumentation an:
- Im normalen Einsatz besteht Online-Dokumentation aus vielen kleinen und kleinsten, unabhängigen Seiten. Für die Korrektur können z.B. alle Seiten dieses Typs alphabetisch sortiert und zu einem einzigen Dokument verbunden werden.
- Für die Übersetzung des Dokuments kann man das Dokument nicht nur wie eben beschrieben linearisieren. Man kann dabei auch all jene Teile ausblenden, die ohnehin aus Referenzen automatisch erzeugt werden. Ergebnis: Der Übersetzer muss jeden Text im Quelldokument nur einmal übersetzen. Natürlich braucht er die offizielle Fassung als Referenz, aber er spart durchaus die Hälfte der Übersetzungsarbeit und gewinnt an Konsistenz.
Die
hier beschriebene Arbeitsweise ist nur mit wenigen Werkzeugen möglich.
Eines davon ist Schematext.
Damit wurden auch die hier gezeigten Beispiele erzeugt. Das ausgesprochen
eigenständige Konzept dieses Werkzeugs macht es schwer, eine
aussagekräftige Liste von Eigenschaften zu erstellen. Deshalb
sollen hier ein paar Hinweise auf das Funktionsprinzip genügen:
Schematext
arbeitet mit Strukturbeschreibung und -prüfung, ganz ähnlich
wie SGML/XML-Systeme mit einer DTD (document type definition). Allerdings
kennt diese Strukturbeschreibung nicht nur das Aneinanderreihen
und Verschachteln von Informationseinheiten, sondern auch Verweise.
- Jedes Element (sowohl Informationseinheit als auch Verweis) erhält einen bestimmten Typ, d.h. es erhält eine genau beschriebene Aufgabe, einen genau beschriebenen Kontext und auch zahlreiche Eigenschaften.
- Für unterschiedliche Zwecke (Ausgabeformate, Dokumentarten) können die Eigenschaften eines Elements unterschiedlich eingestellt werden. Verweise des Quelldokuments können je nach Bedarf z.B. unterdrückt, als Verweistexte formuliert oder zum Einkopieren der anhängenden Informationseinheit verwandt werden.
- Zahlreiche Ausgaben können aus der Umgebung der jeweiligen Informationseinheit abgeleitet werden.
Je höher
der Automatisierungs- und Abstraktionsgrad eines Werkzeugs ist,
um so komplexer wird seine Konfiguration. Während sich Winword
mit ein paar VBA-Scripts recht einfach an die Anforderungen eines
Arbeitsplatzes anpassen lässt, erfordern SGML/XML-Autorensysteme
ziemlichen Aufwand und einschlägige Spezialisten. Auch Schematext
lässt sich vom durchschnittlichen Büroangestellten nicht
konfigurieren.
Völlig
anders sieht es aus, wenn der Spezialist solche komplexen Systeme
sauber konfiguriert hat und die Nutzer einweist: Es entsteht eine
Arbeitsumgebung, die optimal an den Anwendungsfall angepasst ist
und dem Nutzer ein komfortables, rationelles Arbeiten ermöglicht.
Ganz nebenbei werden die erzeugten Dokumente wartungsfreundlicher,
einheitlicher und konsistenter.
