Wiederverwendbarkeit um jeden Preis?

Das Prinzip der Wiederverwendbarkeit ist etwas, das die Software-Entwicklung und die technische Redaktion gemein haben: Redundanz ist böse 😉

Deswegen macht es mir auch eher Spaß Entwicklern zu erklären, worum es bei meiner Arbeit vor allem geht: sie verstehen nämlich (meistens) ziemlich schnell, welche Probleme wir als Redakteure haben (und warum es Probleme sind!) und wie man die dann z.B. durch Verwendung von XML lösen kann.

Die Kolumne „Be pragmatic, not dogmatic“ von Joachim Arrasz hat mich an einige Gedankengänge und Diskussionen zum Thema Wiederverwendung in der Doku erinnert. Die Essenz der Kolumne ist, dass man nicht um jeden Preis immer alles standardisiert und wiederverwendbar machen sollte. Denn am Ende könnten die Mühen dafür höher sein, als der eigentliche Nutzen.

Ich habe so einen Fall z.B. selbst erlebt/produziert. Als ich entdeckte, dass man in DITA auch auf Map-Ebene wiederverwenden kann und so also z.B. einzelne Kapitel wiederverwenden kann, war ich im Wiederverwendungshimmel. Also habe ich die Hilfe, an der ich damals schrieb, sehr sorgfältig in etliche Maps unterteilt – ich könnte es ja mal wiederverwenden. Der Nachteil an der Sache war, dass es nicht so ganz einfach ist den Überblick über so viele Sub-Maps zu behalten. Man muss nach ein paar Wochen erst einmal wieder durchschauen, was wohin referenziert wird etc.

Das Ende vom Lied war, dass ich bis zuletzt keine einzige dieser Maps wiederverwendet habe und mich eigentlich immer geärgert habe, wenn ich mit den vielen kleinen Maps arbeiten musste.

Fazit

Joachim sagt in seinem Artikel:

Die „spätere mögliche Nutzbarkeit“ ist für mich sogar ein Showstopper. Dieses Argument habe ich schon so oft gehört, dass es mir in den Ohren klingelt. An dem Tag, an dem diese Wiederverwendbarkeit wirklich greifen würde, kann man immer noch das Refactoring anstoßen und sich zu diesem Zeitpunkt den Mehraufwand einholen.

Ich denke, man muss einfach sorgfältig nach Anwendungsfall entscheiden wie stark man seinen Standards bis zum Ende folgt. Das spätere Umarbeiten (Refactoring) kann durchaus günstiger sein. In meinem Fall wäre es sinnvoller gewesen auf den konkreten Anwendungsfall zu warten und dann eben Zeit zu investieren, die Maps umzustrukturieren.

Umfrage: Wer nutzt eigentlich DITA?

Ich melde mich aus dem Blog-Nirwana und will zu allem Überfluss, dass meine Leser mal ganz kurz aktiv werden. Ganz schön frech 😉

Ich habe auf diversen Konferenzen schon mal hier und da nachgehakt, wer in Deutschland denn eigentlich mit DITA arbeitet. Es gibt immer zahlreiche Vorträge, die auch gut besucht sind, aber wer arbeitet denn wirklich damit?

Kurz: Mich interessiert sehr wie verbreitet der Einsatz meines Lieblings-Standards eigentlich ist und daher starte ich eine ganz einfache Ja/Nein-Umfrage. Vielleicht mag der eine oder die andere auch kurz kommentieren, warum man damit arbeitet / nicht arbeitet, wie die Erfahrungen sind etc. Bitte gerne weiterleiten, retweeten, liken, plussen 🙂

[poll id=“2″]

Redakteuse live „DITA – Grundlagen und Tipps für Einsteiger“

Im Rahmen der Abendveranstaltungen der tekom-Regionalgruppe Baden halte ich am 23.02. in Karlsruhe einen kleinen Vortrag zu meinem Lieblingsthema 🙂

Für alle DITA-Interessierten mit Grundkenntnissen in XML und Standardisierung gibt es einen kleinen Rundblick mit folgenden Punkten:

* Was ist DITA?

* Für welche Einsatzzwecke ist DITA geeignet?

* Was sind die Vor- und Nachteile?

* Was kann man alles mit DITA anstellen?

* Wie steigt man am besten in die DITA-Welt ein?

Weitere Informationen zu Anmeldung und Ort finden sich direkt auf der Webseite der Regionalgruppe. Ich freue mich über zahlreiche Zuhörer 😉

EDIT: Hier ein Bericht zum Termin 🙂

Linkklassen und Usability

Das DITA-Open Toolkit unterscheidet im XHTML-Output zwischen Links auf Concepts, References und Tasks. Konkret werden die Links wie hier angezeigt:

Mal abgesehen davon, dass die vom Open Toolkit mitgelieferten deutschen Standard-Überschriften „Zugehörige Konzepte/Tasks“ etwas wunderlich klingen, bin ich persönlich kein Freund dieser Aufteilung der Links.

Ich habe z.B. an der Hochschule gelernt, dass solche Topic-Beziehungen klassifiziert und standardisiert werden sollten. Zum Beispiel indem man festlegt, welche Topictypen einander verlinken dürfen und wie. Das finde ich auch absolut okay und notwendig, denn so kann man verhindern, dass unsinnige Link-Urwälder entstehen in denen jedes Topic jedes andere Topic verlinkt, was dann am Ende nicht mehr sehr hilfreich für den Nutzer ist.

Aber: ich bin mir nicht sicher, ob diese Klassifizierung dem Nutzer an dieser Stelle unbedingt so vermittelt werden muss. Hat der Nutzer tatsächlich etwas davon, wenn ich ihm sage: hier kannst du verwandte Anleitungen finden und hier verwandte Erklärungen? Manchmal weiß der Nutzer doch selbst gar nicht so genau was er sucht und ist so eine Klassifizierung nicht vielleicht einfach nur ein Stolperstein?

In meinen Augen ringt so eine Aufteilung dem Nutzer noch einmal eine Entscheidung zuviel ab, die er auf der Suche nach der passenden Information treffen muss.  Er muss sich dann nochmal fragen: „Ja, was such ich denn eigentlich?“ und ehrlich gesagt ist man nicht in der Stimmung über so etwas nachzudenken, wenn man Hilfe sucht. Daher plädiere ich dafür verwandte Links unter einer Überschrift zusammenzufassen. Mir geht diese Aufteilung auf Nutzerseite einen Schritt zu weit und sie hat so ein bisschen was von „Ich mach es so. Weil ich es kann.“

Wie seht ihr das? Was macht ihr mit Links auf verwandte Themen und warum?

Terminologie: DITA und DITA Open Toolkit

Desöfteren ist mir aufgefallen, dass hier und da die Terme „DITA“ und „DITA Open Toolkit“ miteinander vermischt werden – das mag ich als strenge Redakteuse nicht leiden. Beispiel: „DITA generiert das so und so.“ Jetzt muss ich einfach mal damit aufräumen und sagen:

ditaOT

DITA
Hier handelt es sich um die Darwin Information Typing Architecture. Das ist im Großen und Ganzen eine Ansammlung von DTDs und dahinter stehenden Konzepten, wie z.B. der Topic-Orientierung und der Vererbung/Spezialisierung. Hier wird also definiert, wie ich Topics schreibe und welche Elemente verwende. DITA an und für sich ist also mehr als eine Art Konzept und Regelwerk zu sehen.

DITA Open Toolkit
Wohingegen es sich beim DITA Open Toolkit um einen Baukasten mit verschiedenen Tools handelt, der etwas aus dem zaubert, das ich anhand des obigen Regelwerks produziert habe. Es ist eine schöne Ansammlung von Skripten und Stylesheets, deren Zusammenspiel am Ende aus den in DITA-XML geschriebenen Topics einen bestimmten Output (xhtml, pdf…) erzeugt. Das Toolkit ist also zur Transformation da, was eben auch heißt, dass man ohne das Toolkit trotzdem immer noch DITA „machen“ kann. Man könnte das gesamte Transformationsgerödel prinzipiell auch selber schreiben. Das Toolkit wurde im Endeffekt dafür entwickelt, um die Leute nicht vor eine große Hürde zu stellen, wenn sie DITA benutzen möchten, sondern ihnen schon direkt eine Transformationsbasis mitzugeben.

That’s all folks