Auf dem Weg zum XML-basierten Redaktionssystem

Dieses fiktive Interview möchte dazu beitragen, eine Lücke zu schließen.

Ja hallo, der Herr Ex-Kollege! Seitdem du in der neuen Firma bist, sieht man sich ja nur noch bei den Fachtagungen - wenn man sich über den Weg läuft.

Hallo zurück - voll im Stress halt! Unser Projekt mit Database Publishing hält mich total auf Trab; Besprechungen, Workshops, Probleme lösen: der übliche Wahnsinn.

Hm, bei uns wird seit der letzten tekom-Tagung auch ganz schön gegrübelt: "XML oder nicht?", ist glaub' ich bei vielen jetzt die Frage. Wie habt ihr das denn angepackt? So groß ist euer Haufen doch auch wieder nicht.

Na ja, wenn du nach den Datenblättern der Anbieter und Dienstleister gehst, ist ja alles kein großes Ding: Single-Sourcing, Datenbanken und XML und alle deine Probleme sind gelöst. Aber der Umstieg ist nicht so leicht - wir sind seit den ersten Planungen jetzt schon ein Jahr beschäftigt. Und groß sind wir sicher nicht. Wir sind im Team fünf interne Redakteure und - je nach Auftragslage - bis zu drei Externe.

Ihr habt doch vorher auch mit FrameMaker gearbeitet, oder?

Ja, die gängigen Tools halt: FrameMaker wurde für die Handbücher verwendet und verschiedene Hilfe-Tools wie HDK und ForeHelp für die Online-Hilfen. Aber wir wollten mehr - wie auf dem Wunschzettel: granulierte und wiederverwendbare Informationseinheiten, konsistente Strukturen und automatisierte Produktion aus einer Quelle. Außerdem haben uns die Versionswechsel in den vergangenen Jahren wirklich genervt; aber mit XML speichert man ja versions- und plattformunabhängig. Und für unsere Entwickler wollten wir auch ein Zuckerl: Datenaustausch
unserer Dokumente zwischen Entwicklung und Redaktion. Kompatibler als mit XML geht's wirklich
nicht.

Klingt doch alles ganz gut. Wo hat's denn dann gehakt?

Haken kann man nicht sagen, es ist halt doch recht komplex. Eigentlich waren es drei Hauptprobleme. Zum einen mussten wir uns entscheiden, wie wir unsere Dokumente neu strukturieren. Bisher hatten wir ja Funktionsdesign nach Schäflein-Armbrüster und Muthig und die dazu entsprechend angepassten Formate für Anweisungen, Warnungen und so. Aber mit XML brauchten wir ja eine DTD. Eine "Fertig"-DTD kam für uns nicht in Frage, und eine komplette Neuentwicklung hätte einen Riesenaufwand bedeutet. So haben wir es dann ganz anders gemacht: Funktionsdesign beibehalten und gleichzeitig Information-Mapping® nutzen. Dabei zerlegt man die Information in so genannte Maps, die in sich geschlossene Informationseinheiten darstellen. Die Maps wiederum setzen sich aus einer begrenzten Anzahl von Blöcken mit genau einem Informationstyp zusammen; also z. B. Überblick, Fakten, Prozess usw. Wir haben uns mit einer DTD auf Basis von Information-Mapping zusammengesetzt und sie angepasst - zweitägiger Workshop, ich sag's dir! Alle waren mit dabei, haben ihr Know-how eingebracht und diskutiert, wie wir's am besten machen.

Hey, so was hält aber ganz schön auf, oder?

Klar, aber dadurch musste auch jeder den Festlegungen zustimmen. Letztendlich stellt so eine streng formale DTD ja einen "verschärften" Redaktionsleitfaden dar - und wenn alle zugestimmt haben, kann hinterher auch keiner meckern.

Klingt so, als ob ihr da als Team mit einer guten Motivation rangegangen seid.

Die haben wir auch gebraucht - du hättest mal hören sollen, als die ersten mit XMetaL und strukturiertem FrameMaker gearbeitet haben. Das war wie eine Art Kulturschock für unsere erfahrenen DTPler. Dabei kann man eigentlich viele Features ganz gut nutzen: Arbeiten mit der Gliederung, ganze Struktur-Templates und solche Anpassungen. Aber du musst halt bewusst umdenken.

Aber werben die nicht immer damit: "So einfach wie Word"?

Ich weiß nicht; wenn ich schon strukturiert arbeite, will ich auch sehen was ich tue. Ich glaube, man unterschätzt da die Redakteure; unsere Leute haben sich an das neue Arbeiten mit einer Struktur recht schnell gewöhnt - nachdem sie die Vorteile erst einmal erkannt haben.

Hm, also umdenken muss ich bei einem anderen neuen Tool ja auch. Aber du hast vorher von drei Problemen geredet - was kam denn noch daher?

Das war wieder so ein tolles Verkaufsargument: die viel gepriesene Wiederverwendung. Die hat nur Arbeit gemacht. Nach dem Zerlegen mussten wir erst mal rausfinden, welche wiederverwendbaren Einheiten wir eigentlich haben. Und dann noch unterscheiden zwischen unveränderlichen Einheiten - und davon gab's gar nicht so viele - und solchen, die wiederum in verschiedenen Versionen vorlagen. Zum Schluss haben wir eine Art Katalog geschnitzt, so genannte Master-Listen. Aber die müssen jetzt natürlich gefüllt und vor allem gepflegt werden - das nimmt dir auch ein Datenbank-System nicht ab. Und ich bin gespannt, ob unsere Entwickler damit einverstanden sind, wenn es in Zukunft nur noch standardisierte Formulierungen für ihre Dialoge und Setups gibt.

Also irgendwie werd' ich das Gefühl nicht los, ihr habt da so ziemlich alles auf den Kopf gestellt.

Stimmt, wir mussten umdenken, Abläufe neu definieren, viele Lösungen im Detail suchen. Das ist im Prinzip ein ausgewachsenes IT-Projekt. Wenn du da Fehler beim Planen, beim Budget und vor allem bei den Leuten machst, kann das ganz schön schief gehen.

Na toll, du machst einem wirklich Mut, das muss ich sagen.

So schlimm ist's nun auch wieder nicht. Natürlich ist es nicht einfach - gerade als Team die Motivation hoch zu halten. Also ab und zu 'nen Kuchen zur Projektbesprechung mitbringen.

Also wie, Bestechung?

Nee, nur eine kleine Aufmunterung! Wichtig ist, dass jeder weiß, wohin die Reise geht und wie er davon profitieren kann. Das Gefühl, dass jeder über den Erfolg mitentscheidet, war wirklich gut - so etwas kann man nur mit den Kollegen durchziehen, nicht über ihre Köpfe hinweg.

Und wie geht's jetzt weiter? Produziert ihr schon mit dem neuen System?

Wir sind gerade in der Startphase - alle neuen Projekte werden jetzt schon in XML gemacht. Aber frag' mich besser bei der nächsten Tagung wie's gelaufen ist - sonst verpass' ich meine
Bahn.