Auf dem Weg zum XML-basierten Redaktionssystem

Inhalte

• Der Start
• Das Ziel
• Die Probleme
• Das Fazit

Der Start

Unser Team umfasst fünf interne Redakteure (z.T. mit Übersetzer-Ausbildung bzw. englische Muttersprachler) und - je nach Auftragslage - bis zu drei externe Redakteure. Bisher arbeiteten wir mit gängigen Software-Tools: Adobe FrameMaker wurde für die Handbücher und verschiedene Hilfe-Tools wie Republicorp Virtual Media HDK und Sinterphase ForeHelp für Online-Hilfen verwendet. Die Dokumente wurden mit Hilfe des Funktionsdesigns (nach den Professoren Robert Schäflein-Armbruster und Jürgen Muthig) strukturiert; dazu dienten formalisierte Textstrukturen mit ca. 40 entsprechend angepassten Formaten.

Das Ziel

Wir wollten die üblichen Vorteile einer Datenbank-Lösung nach dem Single-Source-Publishing-Prinzip: granulierte und wiederverwendbare Informationseinheiten, konsistente Strukturen und automatisierte Produktion aus "einer Quelle". Nach den schlechten Erfahrungen mit Versionswechseln der vergangenen Jahre war uns außerdem eine plattformunabhängige Speicherung sehr wichtig, was XML ins Spiel brachte. Ein spezielles Problem sollte mit dem Umstieg zusätzlich gelöst werden: Immer wieder hatten wir in der Vergangenheit mit dem Datenaustausch zwischen Entwicklern und Redakteuren zu kämpfen; mit XML erhofften wir uns eine kompatible und dauerhafte Lösung.

Die Probleme

Die erste Hürde stellte die zukünftige Struktur der Dokumente dar - wir mussten über die zu verwendende DTD (Document Type Definition) entscheiden. Eine "Fertig"-DTD kam für unsere Bedürfnisse nicht in Frage, eine komplette Neuentwicklung hätte einen unverhältnismäßigen Aufwand bedeutet. So entschieden wir uns für einen anderen Ansatz: Das bereits verwendete Informationsmodell des Funktionsdesigns beibehalten und gleichzeitig die Meta-Strukturen des - für uns neuen - Information Mapping^® nutzen. Dabei wird die Information in sogenannte Maps gegliedert, die in sich geschlossene Informationseinheiten darstellen. Die Maps wiederum setzen sich aus einer begrenzten Anzahl (7 +/- 2) von Blöcken mit definiertem Informationstyp (z.B. Überblick, Fakten, Prozess) zusammen. Dazu begannen wir mit einer DTD auf Basis des Information Mappings^® und entschieden dann über entsprechende Anpassungen in einem zweitägigem Workshop. Hier konnten alle Redakteure mitwirken und ihre Erfahrungen einbringen, denn gerade das detaillierte Wissen um die Besonderheiten der einzelnen Dokumentationen war in dieser Phase sehr wichtig. Durch diesen Ansatz ergab sich außerdem eine hohe Akzeptanz und Transparenz der DTD. Letztendlich stellt ja die streng formale Typisierung einer DTD einen "verschärften" Redaktions-Leitfaden dar; die entsprechenden Festlegungen werden - so unsere Erfahrung - am Besten gelebt, wenn alle Redakteure beteiligt (oder zumindest gut informiert) sind.

Gute Motivation war auch beim Umgang mit der zweiten Hürde entscheidend, dem Editieren der Dokumente in XML. Für die erfahrenen DTPler stellte der Kontakt mit einer "sperrigen" Auszeichnungssprache wie XML zunächst eine Art "Kulturschock" dar. Im klassischen Desktop Publishing (DTP) hatte der Autor noch die totale Kontrolle über Struktur, Inhalt und Darstellung - während bei einer XML-Umgebung Struktur und Darstellung schon vorgegeben sind. Dabei bieten die Editoren viele nützliche Features wie Templates und Anpassungen; eine echte Akzeptanz erfolgte aber erst nach einem bewussten Umdenkprozess. XML erfordert einfach den Verzicht auf bestimmte liebgewordene Arbeitsweisen und bietet gleichzeitig durch die konsequente Trennung von Inhalt und Darstellung ganz neue Möglichkeiten. Beschwichtigungen sind nach unserer Erfahrung fehl am Platz; die Redakteure waren sehr lernfähig und haben sich an das veränderte Arbeiten mit einer Struktur überraschend schnell gewöhnt - nachdem sie die Vorteile erkennen und praktisch nutzen konnten.

Die dritte Hürde war wieder struktureller Art: Die vielgepriesene Wiederverwendung erwies sich in der praktischen Umsetzung zunächst als arbeitsintensive Grundlagenarbeit. Auch nach dem sauberen Granulieren der Informations-Einheiten bleibt es schwierig, wiederverwendbare Einheiten eindeutig zu identifizieren. Dabei musste noch unterschieden werden zwischen unveränderlichen Einheiten und solchen, die wiederum in verschiedenen Versionen vorliegen konnten. Dieses Zusammenspiel wurde zunächst erfasst und dann in sogenannten Master-Listen katalogisiert; trotz der Unterstützung des Datenbank-Systems wird aber - auch bei der notwendigen Pflege - bei diesem Thema weiterhin Koordination und Disziplin der Redakteure notwendig sein. Auch muss noch abgeklärt werden, ob unsere Kunden in der Entwicklung diese standardisierten Informations-Einheiten akzeptieren oder auf individuellen Formulierungen beharren.

Neben diesen "großen" Problemen gab und gibt es noch einige weitere Bereiche, die wir zu Anfang des Projektes unterschätzt hatten:

• Projektdokumentation: Sowohl die Festlegungen zu DTD und Layout als auch die notwendigen Umstellungen im Arbeitsablauf müssen in geeigneter Form festgehalten werden; ein komplett neuer Redaktionsleitfaden ist zur Zeit am Entstehen.
• IT-Unterstützung: Hier ist ein kompetenter Ansprechpartner in der IT-Abteilung unbedingt notwendig - und zwar genau für den Datenbank-Typ, der im Redaktionssystem eingesetzt wird. Da viele Firmen jedoch IT-politische Festlegungen haben, müssen diese Rahmenbedingungen unbedingt im Vorfeld geklärt werden.
• Feinabstimmungen: Während der Testphase hat sich herausgestellt, daß doch noch Änderungen an der DTD und an den Layout-Regeln notwendig sind. Dabei handelt es sich oft "nur" um Kleinigkeiten, aber die Aufwände - vor allem bei strukturellen Änderungen - sind z.T. doch erheblich.

Das Fazit

XML ist mehr als ein Format; für uns als Umsteiger änderte sich (fast) alles. Wir mussten neue Denkweisen akzeptieren, Detaillösungen finden und Arbeitsabläufe neu definieren. Der Umstieg wurde damit nicht nur zur Frage der neuen Tools; die Einführung ist nicht umsonst mit einem IT-Projekt verglichen worden. Die typischen Fehler wie mangelnde Kommunikation, schlechte Budget-Planung und unzureichende Einbindung der Betroffenen können solch ein Projekt scheitern lassen.

Gerade die langen Entscheidungsphasen und die oft anstrengenden Testläufe im Pilot-Betrieb machten es immer wieder nötig, das Team zu motivieren. Dazu gehörte es, die späteren Vorteile immer wieder ins Bewusstsein zu rücken; keine leichte Aufgabe, da die Datenbank erst befüllt werden musste und die Vorteile zu diesem Zeitpunkt nur virtuell waren. Der Umstieg auf XML bringt nach unserer Erfahrung erst mittel- bzw. langfristig greifbaren Nutzen.

Gerade deshalb erschien es uns beim Umstieg wichtig, klar zu vermitteln, wohin die Reise geht und wie jeder einzelne Redakteur individuell profitieren kann. Das Gefühl, dass jeder über den Erfolg mit entscheidet, war ausschlaggebend; tiefgreifende Umwandlungen in der Arbeitsweise kann man nur mit den Kollegen, nicht über ihre Köpfe hinweg, durchführen.