Was ist besser: Rohrstock oder XML?

Oder: Ist strukturiertes Authoring überhaupt notwendig und die Einrichtungskosten wert?

[Bei diesem Dokument handelt es sich um eine Zusammenstellung (in Übersetzung dieses Originals) folgender Beiträge vom 14. und 15.10.2003: http://groups.yahoo.com/group/wwp-users/message/19234, 19236, 19239, 19245, 19248 und 19253.
Ursprünglich drehte sich die Diskussion um die Frage, ob RoboHelp für FrameMaker (RHFM) zu einem Ersatz für WebWorks Publisher (WWP) als Konvertierungstool für Single-Source Lösungen werden kann, die auf Adobe FrameMaker-Dokumenten (FM) basieren. Der Dialog setzte sich wie folgt fort:]

Michael Müller-Hillebrand:
Nur strukturierte Dokumente gewährleisten meiner Meinung nach die erforderliche technische Qualität von Dokumenten, die eine fehlerfreie Konvertierung in andere Medien ermöglicht.

David Knopf:
Absolut meine Meinung. Wir haben langsam aber sicher all unsere Kunden davon überzeugen können, von unstrukturierten FrameMaker-Dokumenten auf eine strukturierte Authoring-Umgebung umzustellen. Viele dieser Kunden sind sehr zufrieden mit dem WebWorks-Help-Format und bleiben WebWorks daher treu. Für Entwickler von eher generischem HTML oder gar kompilierten HTML-Hilfen ist XML/XSL eine sehr attraktive Lösung.

Sean Brierley:
Das Problem beim strukturiertem Authoring ist der Aufwand… Mit einem unstrukturierten FM-Ansatz lässt sich im Prinzip dasselbe erreichen, und dies tun wir schon ziemlich lange.

David Knopf:
Nicht ganz. WebWorks selbst funktioniert zwar ebenso gut mit unstrukturiertem wie mit strukturiertem FrameMaker, aber es gibt einige sehr bedeutende Aspekte, die sich mit unstrukturiertem Authoring eben nicht umsetzen lassen, insbesondere folgende:

(1) Einrichtung und Durchsetzung von Strukturregeln, die eine angemessene, konsistente und korrekte Dokumentstruktur gewährleisten und sicherstellen, dass allen Inhalten korrekte Tags zugewiesen werden (mit dem willkommenen Nebeneffekt, dass WebWorks-Konvertierungen jedes Mal fehlerfrei funktionieren);

(2) Export und Import von XML, das anschließend entweder an andere Autoren weitergegeben werden kann, die mit anderen XML-kompatiblen Tools arbeiten, oder mit XSL in andere Formate konvertiert werden kann;

(3) Nachverfolgung und Verwaltung von Metadaten für Dokumente und die darin enthaltenen Elemente; und schließlich

(4) effektive Integration in CM/KM-Systeme, um die Wiederverwendbarkeit zu verbessern.

Zugegeben, diese Vorteile spielen bei Büros mit einem oder zwei Autoren kaum eine Rolle. Bei größeren Teams jedoch – und davon gibt es einige – machen diese Aspekte den entscheidenden Unterschied aus.

[Nun schaltete sich John Frazzini ein und kommentierte Davids Argumente zu den Vorteilen von strukturierten Dokumenten. Zur leichteren Lesbarkeit sind die Antworten im jeweiligen Zusammenhang dargestellt.]

John Frazzini:
Hmmm… Ich bin Davids Meinung, was seine Liste von Vorteilen strukturierter Dokumente angeht. Aber genau wie Sean bin ich noch nicht überzeugt, ob dies alles wirklich notwendig und die Einrichtungskosten wert ist. Natürlich bin ich begeistert von Single-Source Lösungen, die ja ähnliche Einrichtungskosten erfordern, aber strukturierte Dokumente gehen mir ziemlich auf die Nerven. Insbesondere…

David:
Nun… Ich widerspreche John nur selten, aber…

(1) Einrichtung und Durchsetzung von Strukturregeln, die eine angemessene, konsistente und korrekte Dokumentstruktur gewährleisten und sicherstellen, dass allen Inhalten korrekte Tags zugewiesen werden (mit dem willkommenen Nebeneffekt, dass WebWorks-Konvertierungen jedes Mal fehlerfrei funktionieren);

John:
Ich finde, eine gut entwickelte Vorlage (und ein großer Rohrstock) lösen das Problem wunderbar. Selbst in Teams von mehr als 20 Mitarbeitern kommt man ohne SGML-Lösungen aus, sofern jemand gekonnt den Rohrstock schwingt und den Autoren klar macht, wie man die Vorlage (FM- und WWP-Vorlage) korrekt einsetzt.

David Knopf:
Meinen Erfahrungen nach funktioniert dieser Ansatz in Teams von mehr als 20 Autoren im Allgemeinen absolut nicht. Vor allem wollen viele Autoren keinen Vorlagen folgen und tun dies deshalb auch prompt nicht. Selbst die wohlwollendsten Autoren überschreiben Formate. Und der Mensch mit dem Rohrstock (und die Editoren in Entwicklung und Produktion) müssen viel Zeit aufwenden, um fehlerhafte Dokumente und fehlerhafte Autoren zu korrigieren – Zeit, die man ansonsten in die Erstellung und Optimierung der Inhalte investieren könnte. In einer strukturierten Authoring-Umgebung übernimmt FrameMaker über 90 % des Rohrstockschwingens. Dies führt in allen mir bekannten Umgebungen zu einer Steigerung der Produktivität.

John:
Sicher könnte man einwenden, dass eine gut entwickelte Vorlage und ein großer Rohrstock dasselbe sind wie das Einrichten einer Struktur mittels SGML/XML, aber der Unterschied ist der, dass beim Anwenden von Vorlagen ein gewisser kreativer Spielraum besteht, wenn eine Vielzahl verschiedener Dokumenttypen produziert werden muss.

David:
Tja, hier besteht ein Unterschied in der Philosophie. Es gibt bestimmte Formen von Kreativität, die ich bei Autoren eben gerade nicht wünsche.
Zum Beispiel möchte ich nicht, dass Autoren so »kreativ« werden, Heading3-Überschriften direkt auf Heading1-Überschriften folgen zu lassen, ohne dass dazwischen eine Heading2-Überschrift steht;
ich möchte nicht, dass Autoren so »kreativ« werden, eine einzige Heading2-Überschrift unter einer Heading1-Überschrift einzufügen;
ich möchte nicht, dass Autoren die »kreative« Entscheidung treffen, Aufzählungslisten mit nur einem Aufzählungspunkt seien eine tolle Sache;
ich möchte nicht, dass Autoren die »kreative« Entscheidung treffen, Listen bräuchten keinen einleitenden Absatz;
ich möchte nicht, dass Autoren vor lauter »Kreativität« vergessen Abbildungsbeschriftungen hinzuzufügen, wo sie notwendig sind;
ich möchte nicht, dass Autoren vor lauter »Kreativität« in Tabellentiteln die Variablen für Fortsetzungen unter den Tisch fallen lassen.

Bevor wir uns jetzt die Köpfe heiß reden, ob genau diese Regeln »richtig« oder »falsch« sind, möchte ich gleich anmerken, dass diese Regeln natürlich nicht für alle Dokumente oder für alle Umgebungen zwingend sind. Dies sind nur Beispiele. Ich möchte damit nur verdeutlichen, dass man mit strukturierten Vorlagen Regeln so durchsetzen kann, dass die Autoren angehalten sind, gültigen Dokumentstrukturen zu folgen, und wenn sie dies nicht tun, erhalten sie Prüffehler. Kein Editor, Rohrstockschwinger oder Produktionsmitarbeiter muss sich mehr um diese Fehler kümmern. Und das ist in meinen Augen eine gute Sache.

John:
Das heißt: Statt den Autoren alles haarklein in einem Schema vorzuschreiben, gibt man ihnen eine Auswahl von Bausteinen an die Hand, zeigt ihnen, wie diese Bausteine eingesetzt werden, gibt ihnen noch ein paar korrekt formatierte Beispieldokumente – und dann lässt man sie spielen.

David:
Die meisten meiner Kunden wollen nicht, dass ihre Autoren spielen, sondern dass sie die bestmöglichen Inhalte in der kürzestmöglichen Zeit erstellen. Natürlich kann strukturiertes Authoring dies keineswegs garantieren, aber es ist definitiv eine große Hilfe.

John:
Es ist wie mit den Lego®-Bausätzen von früher und von heute. Wahrscheinlich bin ich noch von der alten Garde.

(2) Export und Import von XML, das anschließend entweder an andere Autoren weitergegeben werden kann, die mit anderen XML-kompatiblen Tools arbeiten, oder mit XSL in andere Formate konvertiert werden kann;

John:
Das ist meines Erachtens der einzige echte Vorteil von strukturiertem Authoring. Trotzdem warte ich noch immer vergeblich auf ein XML-kompatibles Tool, mit dem ich bessere Ergebnisse erzielen kann als mit einer gut designten Buchdatei.

David:
FrameMaker ist ein XML-kompatibles Programm, mit dem sich großartige Bücher erstellen lassen! Bei manchen meiner Kunden verwenden die Autoren High-end-Tools wie Epic oder XMetal, und das gesamte Publikationsteam arbeitet mit FrameMaker. Mit einer allgemein gültigen DTD kann jeder mit seinem bevorzugten (oder vom Vorgesetzten vorgeschriebenen) Tool am Authoring-Prozess teilnehmen. Die Bücher werden stets in FrameMaker erstellt, entweder aus nativen FrameMaker-Dokumenten oder indem XML-Instanzen, die in anderen Anwendungen erstellt wurden, in FrameMaker importiert und dort generiert und produziert werden.

John:
Es gibt Anwendungen, bei denen kleine Textkomponenten durch ein XML-System besser aufbereitet werden und die zu guten Ergebnissen führen, aber realistisch betrachtet gibt es weit mehr Anwendungen, bei denen ein Lernprozess für den Leser entwickelt werden muss.

David:
Ich finde nicht, dass strukturiertes Authoring und Entwicklung eines Lernprozesses für den Leser einander widersprechen.

John:
Wer auf diesen Zug aufspringt, wertet meiner Meinung nach die Fähigkeiten der technischen Autoren ab. Dieser Weg führt zu einem Einheitsbrei, den jeder produzieren kann und der nur den Anforderungen einer kleinen Minderheit gerecht werden kann (wie bei Fernsehsendungen und Drehbüchern: auf der einen Seite die Drehbucherstellung durch die Redaktion, auf der anderen Seite die sorgfältige Erstellung einer Erzählung, der die Zuschauer folgen können). Zugegeben, das spart auf Dauer Produktionskosten, aber wessen Anforderungen wird es wirklich gerecht?

David:
Tatsächlich zeigt mir die Erfahrung, dass die rigorose Umsetzung von Dokumenttypdefinitionen und Strukturregeln zu besseren und nicht zu schlechteren Inhalten führt, wenn es darum geht, den Bedarf der Leser und Anwender möglichst gut zu bedienen. Es steht außer Zweifel, dass gute technische Autoren auch ohne strukturiertes Authoring exzellente Inhalte erstellen können. Allerdings bezweifle ich, dass alle technischen Autoren in einem Unternehmen dieselbe Qualität erzielen können.

John:
Was die Konvertierung betrifft, kann WebWorks unstrukturierte Dokumente in jedes beliebige Format konvertieren, wenn gut durchdachte Vorlagen wie in Punkt (1) eingesetzt werden, sodass dies kein Problem darstellt.

(3) Nachverfolgung und Verwaltung von Metadaten für Dokumente und die darin enthaltenen Elemente;

John:
Ich bin nicht sicher, wozu das wirklich notwendig ist. Wenn Metadaten vorhanden sind, müssen diese natürlich nachverfolgt werden. Aber der strukturierte Ansatz erfordert Metadaten und schafft dadurch diesen Bedarf erst. Mit dem Ansatz unter Punkt (1) besteht keine echte Notwendigkeit, die Metadaten nachzuverfolgen.

David:
Wenn man ein Buch schreibt – oder meinetwegen fünf Bücher – spielen Metadaten höchstwahrscheinlich eine unbedeutende Rolle. Wenn ein Unternehmen aber technische Dokumente für Hunderte verschiedene Produkte und Produktversionen erstellt, erleichtern Metadaten die Identifizierung, Lokalisierung und Wiederverwendung der bereits vorhandenen Inhalte erheblich, sodass das Rad nicht immer wieder neu erfunden werden muss. Außerdem ermöglichen Metadaten die dynamische Erstellung von Inhalten basierend auf den speziellen Wünschen der Anwender oder Kunden.

(4) effektive Integration in CM/KM-Systeme, um die Wiederverwendbarkeit zu verbessern.

John:
Auch dies ist ein Vorteil, aber aufgrund von Punkt (2) widerspreche ich dem allgemeinen Nutzen.

David:
Und ich widerspreche diesem Widerspruch. CM/KM ist in kleinen Büros unbedeutend. In großen Unternehmen ist es von unschätzbarem Wert.

Zugegeben, diese Vorteile spielen bei Büros mit einem oder zwei Autoren kaum eine Rolle. Bei größeren Teams jedoch – und davon gibt es einige – machen diese Aspekte den entscheidenden Unterschied aus.

John:
Ich würde sagen, es hängt nicht von der Anzahl der Autoren sondern von der Art der zu erstellenden Inhalte ab.

David:
Ich glaube, beides spielt eine Rolle. Natürlich ist die Art der Inhalte von Bedeutung. Wenn ein Verleger Romane und Lyrik veröffentlicht, um das Beispiel auf die Spitze zu treiben, sind Strukturen natürlich völlig nutzlos. Bei technischen Dokumentationen und Schulungsmaterialien kann der Nutzen aber sehr groß sein. Ich glaube, die Gesamtgröße des Authoring-Teams spielt eine Rolle. Bei weniger als 6 Autoren können Konsistenz und Strukturen angemessen auf »die altmodische Weise« erzielt werden. Wenn aber Dutzende Autoren an verschiedenen Orten auf mehreren Kontinenten zusammenarbeiten, wird es um ein Vielfaches schwieriger, dieses Ziel ohne Strukturen zu erreichen.

John:
Wenn es Tausende einzelner Informationseinheiten gibt (z. B. Referenzdokumentationen), bringt eine Struktur große Vorteile (beim Produzieren kleiner Einheiten, die über XSL-Tools gesucht werden). Wenn man versucht, jemandem etwas beizubringen, ist Struktur natürlich wichtig, aber Flexibilität ist genauso wichtig.

David:
Das kommt darauf an. Manche Arten von Flexibilität sind gut. Andere sind schlecht. Die Flexibilität, gegen Grundregeln zu verstoßen, die eine Organisation für ihre Dokumentationen aufgestellt hat, ist schlecht.

[Nach einigen Augenblicken schrieb John Frazzini weiter (wieder versetzt mit Davids Antworten):]

John:
David, ich stelle mit Entsetzen fest, dass wir über all dies einer Meinung sind.

David:
Nun, wir sind zumindest nicht sehr weit voneinander entfernt.

John:
Ich stimme zu, dass die Notwendigkeit besteht, strukturierte Inhalte zu erstellen und Regeln aufzustellen, ich stimme zu, dass mit wachsender Größe der Dokumentation und der Autorenteams auch die Notwendigkeit von Strukturen wächst und dass dies die Leserfreundlichkeit im Allgemeinen steigert. Ich stimme sogar zu, dass die Verwendung eines strukturgeführten Ansatzes die Wahrscheinlichkeit besserer Dokumente drastisch erhöht.

Ich glaube, der grundsätzliche Punkt, in dem wir verschiedener Meinung sind, ist die Frage, wie sehr ein Tool dabei helfen kann oder nicht. Schließlich sind es die Autoren (oder bei meinem Ansatz der Rohrstockschwinger), die dafür verantwortlich sind, ob das System funktioniert oder nicht.

Ich glaube, du hast dies selbst am besten ausgedrückt:

Es steht außer Zweifel, dass gute technische Autoren auch ohne strukturiertes Authoring exzellente Inhalte erstellen können. Allerdings bezweifle ich, dass alle technischen Autoren in einem Unternehmen dieselbe Qualität erzielen können.

Ich würde noch weiter gehen und sagen, dass ich einige Zweifel habe, ob die meisten Unternehmen, die versuchen, strukturgeführte Authoring-Tools zu implementieren, tatsächlich die Vorteile erzielen, die sie zu erreichen versuchen.

David:
Natürlich können Unternehmen beim Implementieren von Strukturen schwere Fehler machen, aber dies gilt auch für den Single-Source-Workflow. Alle von mir genannten Vorteile setzen natürlich eine gute Implementierung voraus.

John:
Je nachdem, wer diese Struktur implementiert und ob diese Person dauerhaft in die Authoring-Umgebung einbezogen ist oder nicht (um Änderungen und Verbesserungen umzusetzen), können die Ergebnisse variieren.

Es ist also im Prinzip kein Unterschied, ob nun eine Person den Rohrstock schwingt oder einen Satz von DTDs erstellt.

David:
Außer, dass man der DTD und EDD nach deren Definition keine Gehälter bezahlen muss! Und die Person, die vorher den Rohrstock schwingen musste, kann nun die Zeit mit wichtigeren Dingen verbringen und zum Beispiel Inhalte erstellen oder optimieren.

John:
Wenn die Unternehmen nicht einsehen, dass für diese Aufgaben hochqualifiziertes Personal benötigt wird, werden beide Ansätze scheitern.

David:
Absolut. Erstellen von DTDs, EDDs und strukturgeführten Anwendungen ist nichts für Anfänger. 😉

John:
Einer der meistgenannten Gründe für die Entscheidung für den strukturgeführten Ansatz sind die niedrigeren Wartungskosten, und diesem Argument möchte ich deutlich widersprechen. Die Investition an Arbeitskraft und -zeit, die zur Wartung einer gut entworfenen unstrukturierten FM-Vorlage erforderlich ist, ist mehr oder weniger dieselbe, die bei DTDs nötig ist (denn auch die Struktur muss sich ändern, wenn neue Arten von Informationen hinzukommen). Wenn man weniger für Wartung ausgibt, dann bekommt man eben auch geringere Qualität.

David:
Dies entspricht nicht meinen Erfahrungen. Eine korrekte Implementierung vorausgesetzt, sollten Änderungen an DTD, EDD und Struktur ziemlich selten notwendig sein. Ich arbeite gerade mit einem Kunden zusammen, der seine Kern-DTDs zuletzt 1996 geändert hat. Mit anderen Worten hat es nunmehr 7 Jahre lang keine einzige Änderung an der Struktur gegeben. Während dieser 7 Jahre haben die Autoren schlicht korrekt strukturierte Inhalte erstellt. Es musste keine Zeit aufgewendet werden, Tag-Fehler der Autoren zu korrigieren. Die Zeit- und Kapitaleinsparungen waren ganz erheblich.

John:
Der einzige Vorteil ist ein geringfügig reduzierter Zeitaufwand für die Korrekturen, die David erwähnt hat (nicht befolgte Strukturen von Überschriften oder Listen usw.). Diese Einsparungen sind proportional zur Größe der Organisation, aber über die Bewertung dieser Ersparnisse kann man durchaus unterschiedlicher Meinung sein.

David:
Mann kann immer unterschiedlicher Meinung sein. 😉

Teilnehmer

• David Knopf, Knopf Online, San Francisco CA, U.S.A.
  http://www.knopf.com
  Beratung & Schulung für technische Autoren
• John Frazzini, TIBCO Software Inc., Palo Alto CA, U.S.A.
  http://www.tibco.com

Und als Stichwortgeber:

• Michael Müller-Hillebrand, cap studio, Erlangen, Germany
  http://cap-studio.de
• Sean Brierley, Haestadt Methods, Waterbury CT, U.S.A.
  http://www.haestad.com