Inhaltsverzeichnis
So viel wie in den letzten zwei Wochen habe ich lange nicht mehr über DITA gesprochen. Anstoß war die tekom-Jahrestagung in Wiesbaden. Dort ist DITA, ein XML-basierter Strukturierungsstandard für Technische Dokumentation, seit mehreren Jahren eines der Hype-Themen. Auch dieses Jahr war DITA wieder sichtbar vertreten – und mit einigen Leuten aus meinem Netzwerk habe ich vor, während und auch nach der Tagung noch heiß über DITA diskutiert.
Von wegen Allheilmittel
Was mich ehrlich ein bisschen wundert: Noch immer wird DITA von einigen als Allheilmittel verkauft. So als würde DITA alle Probleme für (vor allem Software-) Dokumentation mit einem Federstrich lösen. Aber das ist nicht so.
Was man aus meiner Sicht grundlegend verstehen muss: DITA ist das, was es ist – eine Strukturierungshilfe für Inhalte. Wer mit DITA arbeitet, legt sich auf eine (zugegeben sehr sinnvolle Art) fest, seine Daten erst zu klassifizieren und dann zu strukturieren. Für Handlungsanweisungen gibt es ein Topic “task”, erklärende Texte kommen in ein Topic “concept”. Oft redet man in diesem Zusammenhang auch von “Informationstypen”.
Was mir DITA aber nicht sagt: Nach welchen Regeln befülle ich die Informationstypen? Und: Welche Schreibregeln sind denn für meine Leser ganz grundsätzlich sinnvoll?
DITA – Ein sekundäres Phänomen
Diese grundlegende Definition kann nur ein Redaktionsleitfaden leisten. Ein Dokument also, das für alle relevanten sprachlichen Phänomene in meinen Texten verbindlich (und hoffentlich möglichst übersichtlich) festlegt, welche Regeln wo gelten.
Diese Regeln lassen sich aber nur beschreiben, wenn bereits der Leitfaden die Informationstypen definiert und die Regeln diesen Informationstypen systematisch zuordnet.
Und das bedeutet: Ein Redaktionsleitfaden funktioniert sehr wohl ohne DITA. Ohne Redaktionsleitfaden macht DITA aber keinen Sinn. DITA ist in diesem Zusammenhang ein sekundäres Phänomen.
Dazu passt übrigens auch eine Beobachtung, die ich bei unseren Kunden mache, die mit XML-basierten Redaktionsprozessen arbeiten. Semantische DTDs kommen immer mehr außer Mode. Die Typisierung und Klassifizierung, die diese leisten sollen, werden in einen Redaktionsleitfaden “vor”-verlagert. Und sobald ein Content-Management-System zum Einsatz kommt, spricht meist niemand mehr von DITA.
Vortragsfolien zum Thema „Redaktionsleitfaden“
Auf doctima.de gibt es unsere Vortragsfolien von der tekom-Jahrestagung zum Download. Wer sich näher mit dem Thema Redaktionsleitfaden beschäftigen möchte, findet in dem Tutorial, das ich zusammen mit Jörg Palm von DATEV gehalten habe, sicher den ein oder anderen Denkanstoß.
Da kann ich nur zustimmen. Bei einem DITA-Projekt kommt zuerst der Redaktionsleitfaden und dann überlegt man sich mit welchen DITA-Tags die einzelnen Elemente verbunden werden.
“Semantische DTDs kommen immer mehr außer Mode.”
Was ist hier genau gemeint? Am Ende ist doch die DTD notwendig, um das im Redaktionsleitfaden Definierte, abzuprüfen. Oder ist hier gemeint, dass “vorgefertigte” DTDs wie die von DITA aus der Mode kommen?
Ein sehr interessanter Beitrag, der genau auch meinen Nerv trifft. “DITA ist das, was es ist – eine Strukturierungshilfe für Inhalte.”. Aber nur auf den obersten Ebenen. Ziemlich schnell findet man sich in der Praxis dann aber in einem Wust von “p”, “ul” Elementen wieder, die außer der Verwendung von Elementen nichts mehr mit einer Informationsstrukturierung zu tun haben. Elemente werden für Zwecke missbraucht, für die sie gar nicht gedacht sind.
Und das eben dann, wenn DITA nicht auf die Anforderungen des jeweiligen Einsatzzweckes angepasst wurde. Dann findet man doch wieder unstrukturierten Inhalt eben im XML-Format wieder. Somit stimme ich zu, wenn DITA im Standard 1:1 zum Einsatz kommt, braucht es einen Redaktionsleitfaden.
Dann komme ich aber zum Schluß, wenn ich einen Redaktionsleitfaden brauche, der in diesem Fall sicherle mehrere bis viele Seiten einnehmen wird, warum dann DITA oder gar XML? Die XML-Struktur soll gerade dieses Dokument vermeiden, oder den Inhalt dieses Dokuments in jedem Fall erheblich verringern. Die Struktur soll den Anwender bei seiner Arbeit führen und Ihn jederzeit bei seinem tun unterstützen.
XML (oder DITA)-basisierte Prozesse müssen ohne Redaktionsleitfaden auskommen (vielleicht einen ganz kleines Dokument (1-2 Seiten) um das Grundkonzept zu erklären). Nur dann macht XML Sinn. Das ist möglich, wenn die Struktur den Erfordernissen des Einsatzzweckes genügt, also -nicht nur aber – an relevanten Stellen semantische Strukturen definiert hat. DITA ist in jedem Fall abzuspecken und ggf. um solche Strukturen zu erweitern. Wenn die Elementnamen dann noch sprechend und nicht abgekürzt sind, kommen Anwender mit einer kleinen Referenzdokumentation und ggf. einer Einweisung sehr gut klar.
XML ist nicht Mittel zum Zweck sondern soll in erster Linie den Anwender bei seiner Arbeit unterstützen. Ganz nebenbei purzeln dann automatisierte Publikationsprozesse heraus.
Back to the roots (Redaktionsleitfaden) ist aus meiner Sicht der Falsche Weg, sondern ist das Ergebnis unzulänglich umgesetzer Strukturen.
Für mich als Soloredakteur bedeutet DITA:
1) Durch das jahrelange strukturierte Schreiben bedarf es keines Redaktionsleitfades (solo sowieso) mehr. Was nicht heißt, dass man bestimmte Dinge nicht überdenkt und neu gestaltet.
2) Kostenloses! Single Source Publishing mit dem DITA-OT
3) Hoher Grad an Reuse/Wiederverwendug: sobald eine Schaltfläche umbenannt wird, brauche ich dies nur an einer Stelle aktualisieren
Großer Nachteil: DITA eignet sich nur für Redakteure, die sich in erster Linie als “Redakteure” verstehen. Für Mitarbeiter, die “nebenbei so schreiben”, ist DITA keine Lösung. D.h. für 90% aller Subject Matter Experts.
“DITA ohne Redaktionsleitfaden” is genauso intelligent wie “Doku ohne Redaktionsleitfaden”.
Guter Artikel. Die Kommentare zeigen, dass der Beitrag offenbar auf wunde und wichtige Punkte unserer Arbeit trifft. Danke!
Irritiert hat mich der Kommentar von Markus Wiedenmaier. Ich sehe leider nicht, dass eine (auch individuell angepasste) XML-Struktur einen Redaktionsleitfaden ersetzen kann. Sind dies nicht zwei verschiedene Ebenen? Wie kann ich per XML-Struktur Schreibregeln fassen? Insbesondere wenn ich an den Übersetzungsprozess denke, fehlt mir hier die Vorstellung.
Wenn ich den Kommentar des Kollegen richtig verstehe, gibt es eine XML-Struktur mit sprechenden Elementnamen, einen Leitfaden zur Konzepterklärung und eine Referenzdokumentation sowie eine Einweisung.
Aus meiner Sicht hat der Redaktionsleitfaden die Aufgabe, das Konzept und die Regeln der Dokumentation auszuführen. Eine Referenzdokumentation kann nur die Umsetzung beispielhaft demonstrieren, aber es fehlen die Erläuterungen und die Bereiche der Übersetzung, Verwaltung, Publikation sowie Archivierung sind ausgesparrt. Dies kann und sollte der Redaktionsleitfaden leisten. Daher stellt für mich ein Redaktionsleitfaden kein Rückschritt dar, sondern ist eine Möglichkeit der Reflexion und damit der Weiterentwicklung. Dabei beachten: Wie die XML-Struktur gibt es auch den Leitfaden nicht von der Stange zu kaufen.
Ein Redaktionsleitfaden (RLF) ist aus meiner Sicht ein Schritt in die Vergangenheit. Dabei spreche ich nicht davon, dass Prozesse und Voraussetzungen damit diese Prozesse funktionieren, nicht ausreichend zu dokumentieren sind. Das ist schon die Basis eines QMS und für ein QM-zertifiziertes Unternehmen (hoffentlich) Standard. Ein RLF, so zumindest mein Verständnis, soll den Anwender bei seiner täglichen Arbeit unterstützen, und das schafft ein so umfangreiches Werk nicht. In der Praxis sehe ich kaum einen RLF (mehr oder weniger umfangreich) neben dem Arbeitsplatz stehen, auf den regelmäßig zurückgegriffen wird.
Sprechen wir über die richtige Verwendung von Elementen, ist sicherlich irgendwo zu beschreiben, dass eine Handlungsanweisung im Falle DITA mit dem Element “task” und nicht einfach über eine Liste (ul/ol) zu erstellen ist. Diese Beschreibung entspricht der von mir erwähnten Referenz. Die Beschreibung auf dieser oberen Ebene reicht aber für das Verständnis und die richtige Verwendung der weiteren Elemente aus. Alles weitere (nämlich dass es Voraussetzungen, Werkzeuge, Schritte und Ergebnisse geben muss/kann) gibt die Struktur vor. Aus meiner Sicht der wichtigste Grund für (teilweise semantisches) XML. Hat der Redakteur also den richtigen Einstieg gefunden, ergibt sich alles weitere von selbst. Wenn es jetzt weitere Unterstützung in Form von Dokumentation braucht, muss diese Unterstützung durch eine ordentlich konfiguriere Anwendung (i.d.F. dem XML-Editor) angeboten werden. Die Struktur/der Editor muss die notwendige Unterstützung/Dokumentation zu dem Zeitpunkt bringen an dem die Information auch benötigt wird. Die Dokumentation ist in diesem Fall als Annotation in der XSD untergebracht und wird von der Anwendung kontextsensitiv bereit gestellt.
Schreibregeln können mit XML nur bedingt und an begrenzten Stellen abgebildet werden. Aber auch hier kann XML beispielsweise durch die richtige sprachabhängige Verwendungen von Anführungszeichen helfen. Für die Einhaltung von Schreibregeln (wie die Vermeidung von doppelter Verneinung in meinem 2.Satz) gibt es aber heute Systeme, die den Redakteure direkt beim Schreiben auf Regelverletzungen hinweisen, so dass diese Fehler direkt beim Schreiben behoben werden können. Im Idealfall werden Alternativen angeboten. Wieso müssen Regeln, die in einem System definiert sind, nochmals in einem Redaktionsleitfaden definiert sein? Die im System definierten Regeln sind möglichst intuitiv umzusetzen und müssen dem Anwender direkt bei seinem Tun unterstützen. Im Falle DITA/XML übernimmt hinsichtlich der Struktur der XML-Editor diese Aufgabe. Im Falle Schreibregeln das entsprechende Terminologie-/Stilprüfungs-System; im Falle Übersetzung das entsprechende TMS, im Falle Informationsverwaltung das CMS/RS etc. Was muss ich im Publikationsprozess überhaupt dokumentieren? Wenn im Vorfeld alles definiert ist, ist der Prozess halb- bis sogar vollautomatisiert! All das bietet die Technologie, und nicht erst seit heute.
Ich bin nicht gegen Dokumentation. Im Gegenteil, ich bin für mehr Dokumentation aber an den richtigen und sinnvollen Stellen. Soweit sind wir also nicht auseinander. In der technischen Dokumentation geht es heute darum Anwendern die Informationen JIT zur Verfügungung zu stellen; nämlich dann, wenn sie die Information brauchen. Warum setzen wir hier also nicht die gleichen Maßstäbe an: Es braucht eine ausführlichere, nennen wir es Systemdokumentation, in denen Prozesse, Entscheidungen etc. – also das Gesamtsystem – dokumentiert sind, keine Frage. Sie dient dem KVP; interessiert aber den Anwender bei der täglichen Arbeit recht wenig. Dann bleibt eine übersichtliche Referenzdokumentation unterstützt durch eine kontextsensitive Dokumentation übrig. In der Referenzdokumentation sind Informationen enthalten bei denen das System nicht in ausreichender Form führen kann (z.B. in welchen Formaten, Größen etc. sind Grafiken zu erstellen). Bei Systemeinführung oder Fluktuation ist eine Anwenderschulung unumgänglich, das macht auch ein RLF nicht obsolete. Auch ein RLF ist keine Garantie dass irgendein Prozess funktioniert. Er muss gelebt und nicht (nur) dokumentiert werden. Das Leben eines Prozesses erreicht man nur durch Akzeptanz.
Wenn ich es richtig verstehe, dann geht es um die Art und Weise der Dokumentation der redaktionellen Arbeit und nicht um die grundsätzliche Frage, dass zu dokumentieren ist. Ja, ein klassischer, gedruckter Redaktionsleitfaden erscheint recht altmodisch. Besser ist es ihn bzw. die Regeln in die Arbeitsumgebung zu integrieren, wie es in einem Redaktionssystem möglich ist. Ich denke, entscheidend ist, welche Ziele verfolge ich mit einem Redaktionsleitfaden. Dementsprechend muss ich das Medium, die Gestaltung wie auch die Integration auswählen.
Ja die Art und Weise und auch was(!). Ich muss Prozesse und Entscheidungen aber nicht die Regeln dokumentieren, denn diese sind im System hinterlegt; ggf. mit einer Referenz für den Benutzer wenn es zum Verständnis beiträgt.
Und dann welche Informationen werden dem Benutzer wie und wann zur Verfügung gestellt.
Die Kontextsensitivität kann man schon in einem XML-Editor integrieren. Dazu braucht es noch kein Redaktionssystem.
Entscheidend ist aus meiner Sicht, was als erstes da ist – ein Satz Sprachregeln, der auf die Bedürfnisse des Unternehmens und der Textsorte abgestimmt ist (nennen wir das mal kurz „Redaktionshandbuch“) oder eine XML-Struktur. Dass sich diese Sprachregeln dann in XML-Strukturen (und natürlich auch in DITA) abbilden lassen, ist logisch und in den meisten Fällen auch sinnvoll. Aber die linguistische Modellierung out of the box zu verwenden, wird in den meisten Fällen scheitern.
Natürlich kann und sollte man die Regeln auch eng in die Arbeitsumgebung integrieren. Für ein wirklich fundiertes Arbeiten reicht das aber nicht aus; es wird dann immer Zweifelsfälle geben, in denen der Redakteur mehr wissen muss als eine Tag-Bezeichnung oder das, was eine Kontexthilfe wiedergeben kann. Wer erwartet, dass Redakteure stur nach Schema F eine XML-Struktur mit Content befüllen, schöpft das Potenzial von Technischer Dokumentation nicht aus. Deshalb ist ein Dokument sinnvoll, das die impliziten Regeln einer DTD in einen Zusammenhang bringt und mit Hintergrundinformationen unterfüttert.
Zu guter Letzt: “Redaktionshandbuch” legt vielleicht das Missverständnis nahe, für uns aber ist bei dem Begriff keine Festlegung auf ein bestimmtes Medium gedacht.