Die Redakteuse

Kategorie: DITA

  • tekom15: Faster than agile

    So, nach der ganzen DITA-Aufregung kommen wir nun zu etwas völlig anderem. Naja, ein bisschen DITA ist auch dabei, aber hey, ihr wisst, wo ihr hier lest 😉

    Ich habe mir Jang Graats Vortrag „Faster than agile“ angeschaut. Gerade bin ich wieder mittendrin in einem agilen Projekt und da klang das doch vielversprechend.

    Vorab muss ich sagen, dass ich das Agile-Bashing hier etwas arg konstruiert fand. Jang kritisierte, dass wir als Redakteure in agilen SW-Projekten schnell dabei sind die ganzen Arbeitsweisen der Entwickler zu übernehmen: Versionsverwaltung, Nightly builds… Worum es ihm aber eigentlich geht ist, dass wir Redakteure uns von diesem Publikationsparadigma verabschieden sollen, d.h. zu einem definierten Zeitpunkt generieren wir alle Publikationen und liefern sie dann aus.

    Live-Content statt Publikation

    Die Probleme fangen da an: wenn man für mehrere Produkte, Variante, Endgeräte, Zielgruppen und Sprachen generiert, kommt schnell eine beachtliche Menge zusammen, die bei Updates publiziert werden muss. Das nimmt zum Einen viel Zeit in Anspruch und zum Anderen benötigt man viel Speicherplatz für die Vielzahl von Publikationen.

    Seine Lösung für die Zukunft ist das Live-Publishing von Content on demand, d.h. in dem Moment in dem ein Nutzer, die Seite aufruft, wird sie per XSLT generiert und angezeigt. Der XML-Content (hier war es DITA, was hier aber sekundär ist) liegt hierbei direkt auf dem Server. So bekommt der Nutzer absolut frischen Content und wir Redakteure müssen nicht mehr dem Umweg über Publizieren und dann Builds machen, sondern können Content-Änderungen direkt in die Welt raushauen. Zudem ist der Content direkt auf den Nutzer zugeschnitten, auf sein Endgerät, seine Sprache etc.

    Dazu stellte Jang auch einen Workflow vor, bei dem er über das HTML5-Attribut editable eine Möglichkeit gefunden hat, auch die generierte Seite zu bearbeiten und die Änderungen wieder in den DITA-Quelldatei zurück zu überführen. Was gerade bei kleinen Änderungen oder auch Reviews eine ziemlich praktische Angelegenheit ist, denn diese könnte man so sehr einfach auch SMEs machen lassen, ohne dass diese sich mit XML-Dateien herumschlagen müssen.

    Und wie geht das?

    Leider hab ich in dem Vortrag wirklich konkrete Ausführungen dazu vermisst, wie das ganze gelöst ist, wie der komplette Prozess im Detail aussieht (auch technisch gesehen), wie ich die DITA-Files organisiere, mit was publiziert wird. So war der Vortrag erst einmal nur ein kleiner Anstoß zum Überdenken schon ziemlich etablierter Arbeitsweisen und dass es auch anders geht.

    Ich hoffe, dass es bald konkreter wird – zumindest hat Jang angedeutet, dass er da eine richtige Lösung bauen (anbieten?) will. Ich werde mir diese Möglichkeit in den nächsten Wochen jedenfalls auch mal genauer anschauen.

    (Als ich übrigens einem Entwickler von diesem XSLT-On-Demand-Web-Publishing erzählte, schlug der allerdings die Hände über dem Kopf zusammen: Das gäbe doch nur Performance-Probleme und potentielle Sicherheitslücken. )

  • DITA & Deutschland

    Leider war ich in diesem Jahr nur am 2. Tag auf der tekom-Tagung und habe so die beiden Sessions verpasst, die sich eher kritisch mit DITA auseinander setzten oder wie Sarah O’Keefe sie zusammenfasste: DITA is bad. Die Tweets dazu waren sehr unterhaltsam und ich hätte die Diskussionen gerne live erlebt.

    Es hat sich hier wieder der Eindruck manifestiert, dass Deutschland ziemlich DITA-feindlich ist.


    Und das alles hat mich einmal zu einer kleinen Bestandsaufnahme inspiriert, die mir schon lange im Kopf herumschwirrt. (Und ja, ich hab schon ein bisschen überlegt, ob ich nach der ganzen Aufregung auf Twitter jetzt wirklich noch was dazu schreibe. Aber hey, wenn ich schon in den Blog-Flow komme, sollte ich besser nicht aufhören).

    Die Verbreitung in Deutschland

    Ich beobachte den deutschen Stellenmarkt seit gut 10 Jahren und seit ein paar Jahren auch den Projektmarkt, und tatsächlich kann ich DITA-Projekte oder Stellenausschreibungen, die DITA-Kenntnisse forderten, an einer Hand abzählen. Kleiner Hinweis: Man ist also zeitweise sehr gefragt, wenn man sich hierauf spezialisieren will, oder über lange Strecken gar nicht 😉

    Meine Erfahrung deckt sich ganz gut mit dieser Grafik von Keith Schengili-Roberts.

    Wie kommt das? Warum ist DITA in den USA so durchgestartet und hier in Deutschland (noch) nicht? Ich persönlich glaube nicht, dass es daran liegt, dass DITA in irgendeiner Weise schlecht wäre oder es hier total viel bessere Lösungen gäbe. Es gibt nie nur eine Lösung.

    DITA – Alter Wein in neuen Schläuchen?

    Soweit ich das beurteilen können arbeiten hier viele Unternehmen schon länger XML-basiert als es DITA gibt und dementsprechend haben sie schon eigene Standards und Prozesse. CMS-Hersteller haben entsprechende Lösungen entwickelt. Was also den Bereich Standardisierung/Modularisierung angeht, ist DITA hier erst einmal nichts Neues. Ist es also die Ablehnung nach dem Motto: „Alter Hut, machen wir schon viel länger.“ ? Das alleine kann es nicht sein, denn es gibt immer noch genug Firmen, die völlig unstandardisiert arbeiten und für die DITA genau das Richtige wäre.

    Alles eine Frage der Kultur?

    Sind die Deutschen vielleicht zu zögerlich? Ich kann mir gut vorstellen, dass das ein Faktor ist.  Gerade in den Branchen Maschinenbau/Elektrotechnik, die um xml-basiertes Arbeiten kaum drumherum kommen, ist man doch generell etwas vorsichtiger und konservativer. Man traut einem relativ neuen Standard vielleicht nicht so sehr (was sind in dem Bereich ganz ernsthaft schon 10 Jahre?) und verlässt sich lieber auf etablierte CMSe , weil das die vermeintlich sichere Schiene ist (Nur um es gesagt zu haben: ich hab nix gegen CMSe!).

    Und was ist dann mit der IT-Branche, die in Deutschland doch auch wahnsinnig wächst? An dieser Stelle bin ich etwas ratlos. Es gibt einige große Unternehmen, die DITA einsetzen, aber insgesamt ist auch hier DITA kein großes Thema.  Ist es so, dass die Doku hier noch weiter unten priorisiert wird, weil man nicht so starken rechtlichen Druck hat und deswegen „irgendwie“ arbeitet? Braucht man XML in der SW-Doku generell nicht so sehr? Was meint ihr?

    DITA, der Hammer und der Nagel, oder so

    Das muss ich noch kurz erwähnen: Obwohl ich ja schon ziemlich überzeugt bin von DITA, setze ich es auch nur da ein, wo es Sinn macht. Als Beraterin im Bereich TD ist es die Aufgabe herauszufinden, was der spezielle Kunde wirklich braucht. Und das eben nicht nach dem Motto: „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“ Berater und Firmen in allen Branchen arbeiten vielleicht oft so, aber das ist ein ganz anderes Thema. Auf jeden Fall fand ich das Zitat aus der gestrigen Session von Uwe Reißenweber (bitte beachten: von der DERCOM, dem Verband dt. CMS-Hersteller) wirklich großartig in seiner Ironie:

    Hey, es gibt immer mehr als eine Lösung  und in diesem Sinne:

  • Mit DITA um die Welt – tekom-Jahrestagung 2012

    Die tekom-Jahrestagung 2012 ist überstanden und es war mal wieder sehr interessant und schön dabei zu sein.

    Vorab gibt es hier erst einmal die Folien zu meinem Vortrag „Mit DITA um die Welt“. Der Rückblick folgt in den nächsten Tagen. Ich gehöre nicht zu den Schnell-Bloggern wie Kai oder Sarah, die ihre Eindrücke wirklich rasend schnell online hatten.

    Titelbild Vortrag Mit DITA um die Welt

    Und hier noch der Beweis, dass ich ihn tatsächlich gehalten habe 😉
    (Special thanks to Axel)

    Vortragsbild Marijana Prusina "Mit DITA um die Welt"

  • Wie weit sollte CMS-Abhängigkeit gehen?

    Diese Frage stelle ich mir, seit ich auf der tekom-Frühjahrstagung im Vortrag „Content-Management powered by PI-Mod“ von Stephan Steurer mit Special Guest Prof. Ziegler saß. PI-Mod ist ein XML-Standard für Dokumentation, der vor ca. 4 Jahren unter Federführung von Prof. Wolfgang Ziegler entstand und in den die Anforderungen aus vielen Kundenprojekten aus dem Maschinen- und Anlagenbau einflossen.

    Eine sehr interessante Eigenschaft von PI-Mod ist die Trennung zwischen den dahinterliegenden Konzepten und der Implementierungslogik. Das heißt PI-Mod liefert keine Mechanismen mit, die vorgeben wie z.B. wiederverwendet wird oder Dokumente aggregiert werden. Wenn man sich die Redaktionssysteme heutzutage so anschaut, hat da sowieso jedes seine eigene Verfahrensweise. Und indem man sicht mit PI-Mod nicht festlegt,  hat man eine sehr viel größere Freiheit bei der Auswahl eines Redaktionssystem.

    Das ist nun ein völliger Gegensatz zu DITA, das  out-of-the-box alles liefert, was das TR-Herz begehrt. Damit schreibt es aber auch gleichzeitig ziemlich viel vor. So muss man sich als DITA-einsetzende Redaktion dann fragen:

    • Nehme ich ein DITA-spezialisiertes CMS?
      Die Auswahl ist aktuell noch gering und damit die Chance hoch, dass es verschiedene andere Anforderungen nicht erfüllt.
    • Nehme ich ein CMS, benutze dessen Mechanismen für z.B. Publikation, Aggregation, und mache mich von dem CMS quasi abhängig?
      Eröffnet einem eine große Auswahl und damit eine größere Chance das in jeder Hinsicht richtige System zu finden.
    • Nehme ich ein CMS, lasse die Unterstützung der DITA-Mechanismen einbauen und bin somit systemunabhängig?
      Man hat jederzeit die Möglichkeit das CMS zu wechseln. Die Infrastruktur läuft auch (quasi) ohne CMS.

    Fazit

    Es ist eine leicht philosophische Frage, die kaum einfach so zu beantworten ist. Wer voll auf der DITA-Schiene fährt, möchte in der Regel gerne ziemlich viel selbst bestimmen können und da ist es nur logisch, dass man ein ungutes Gefühl dabei hat bestimmte DITA-Möglichkeiten nicht zu nutzen, sondern sich abhängig von den Systemgegebenheiten zu machen. Andererseits stellt sich auch die Frage, ob man je wirklich das CMS wechseln wird. In der Regel war es schon schwer genug das eine zu bekommen! Aber man weiß ja nie… Allerdings weiß man auch nie, ob man nicht vielleicht auch mal den Standard wechselt, weil es inzwischen ein viel besseren gibt?

    Wie seht ihr das?

  • Gelesen: DITA Best Practices

    Vor kurzem ist das Buch DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA von Laura Bellamy, Michelle Carey und Jenifer Schlotfeldt erschienen. Bei dem Wort „Architecting“ im Untertitel bin ich hellhörig geworden, denn die meisten Bücher, die derzeit auf dem Markt sind beschäftigen sich entweder stark mit den Basics (Warum soll ich DITA verwenden?) oder mit der Autorensicht (Wie schreibe ich in DITA?). Das ist zwar nicht verkehrt, aber viele weitere Infos musste man sich bisher dennoch eher im Netz zusammensuchen.

    Part I: Writing in DITA

    Dies ist der erste Teil des Buchs und handelt wie der Titel schon sagt alle Basics rund um das Schreiben mit DITA ab. Für jeden Topictyp gibt es ein einzelnes Kapitel in welchem anhand von konkreten Beispielen die wichtigsten Elemente gezeigt werden und eben auch Tipps, wie sie am besten zu nutzen sind. Manche Dinge sind ja z.B. aus der DITA-Referenz nicht unbedingt ersichtlich, wie z.B. der Unterschied zwischen choices und choicetable. Die Autorinnen benennen konkret in welchem Fall welches Element geeignet ist.

    Und einer der wichtigsten Sätze in diesem Zusammenhang ist vielleicht dieser:

    Avoid using  […] elements simply because they’re available.

    DITA bietet wirklich eine riesige Fülle an Elementen, aber man muss sie gar nicht immer alle verwenden.

    Ein besonderes Augenmerk legen die Autorinnen auf die shortdesc (short description) und so bekommt dieses unscheinbare Element ein eigenes Kapitel. Der Grund dafür ist, dass der Inhalt dieses Elements das erste ist, was der Nutzer zu sehen bekommt. Dieser Text erscheint in den Suchergebnissen oder Linkübersichten und  hilft dem Nutzer so zu entscheiden, wohin er navigieren soll. Das Kapitel enthält viele nützliche Negativ-und Positivbeispiele für short descriptions

    Part II:  Architecting Content

    Dieser Teil hat mich schlichtweg begeistert und hätte mir vor 4 Jahren ziemlich viel Recherchearbeit abgenommen. Hier verlässt man die reine Autorenschiene von Teil 1 und befasst sich wirklich mit dem Eingemachten von DITA. Es gibt eine sehr ausführliches Kapitel über Maps; wie man diese am besten aufbaut und welche Möglichkeiten man generell in Maps hat. Weiter geht es mit den verschiedenen Arten des Verlinkens in DITA, also Related links, relationship tables etc.

    Und dann kommen natürlich auch die Themen Metadaten, conditonal processing und Wiederverwendung dran.

    Fazit

    Zuerst muss ich noch erwähnen, dass das Buch noch einen 3. Teil namens „Converting and Editing“ enthält, den ich allerdings noch nicht gelesen haben.

    Jedoch finde ich die ersten beiden Teile des Buchs schon so gelungen, dass der Teil nun auch nicht so schlecht sein wird 😉 Das Buch besticht auf jeden Fall durch sehr viel Praxisorientierung und hält sich nicht lange mit irgendwelchen Grundlagen und Randinformationen auf: es gibt viele Beispiele, wie sie auch im Redaktionsalltag auftreten können, und sehr gut finde ich die Checklisten am Ende jedes Kapitels, die nochmal alles gut zusammenfassen und somit eine gute Referenz für den Alltag darstellen.

    Das Buch enthält allerdings keine Informationen zum DITA Open Toolkit und dem großen Thema Ausgabeformate, aber das hätte auch nicht wirklich in das Konzept gepasst, denke ich.

    Kurzum: Ich empfehle dieses Buch absolut, wenn man einen Rundumschlag von der Autoren- bis hin zur Informationsarchitekten-Ebene möchte.

  • 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