Autor: Marijana Prusina

  • Links auf Online-PDFs

    Heute: ein großartiger Fehler!
    Ich habe in meinem Topic einen Link auf ein PDF im Internet gesetzt.
    <xref href="http://redakteuse.de/blubber.pdf" format="pdf" scope="external">User Guide</xref>

    Im HTML-Output hat der Link auch super funktioniert, ABER im PDF-Output hat der Link nicht funktioniert.
    Aaah! Ich ahnte Böses in die Richtung, dass ich hier schon wieder geFOPpt werde und damit erst einmal gar nichts tun kann bis ich nicht ein neues PDF-Tool habe. Und so ist es auch. Nun muss ich irgendeinen Workaround finden, der vermutlich so aussehen wird, dass ich auf eine HTML-Seite verlinken muss (das geht nämlich wiederum) auf der der Nutzer dann selbst auf das PDF klicken muss. Ein unschöner, unnötiger Schritt. Aber so sieht es erst einmal aus 🙁

    Das war der Punkt, wo ich mich wieder an die Tugend erinnert habe, die ich dereinst als einsame Redakteurin unter lauter Software-Entwicklern gelernt habe: fluchen, was das Zeug hält, wenn es blöde Bugs gibt 😉

  • Topics strukturieren

    Eine typische Doku-Situation geht so: Man hat zwei Kapitel, die inhaltlich unter einen Oberkapitel passen und um die Struktur übersichtlicher zu machen, packt man die Zweikapitel mit ihren Überschriften unter eine Ober-Überschrift (siehe unten).

    1 Installation
    1.1 blubTunes installieren
    So installieren Sie…bla
    1.2 blobTunes installieren
    So installieren Sie…

    Ein Problem stellt sich mir aber dar, wenn ich so etwas in DITA umsetzen möchte. Ich schreibe also zwei Topic und stelle beim Zusammenstellen zu einer Map fest, dass ich die in einem Inhaltsverzeichnis eigentlich unter eine Ober-Überschrift packen möchte. Was mache ich nun?

    Es ist definitiv keine angebrachte Lösung ein Topic zu erstellen, das bis auf die Überschrift leer ist. Das ist zumindest meine Meinung. Daher bin ich auch der Suche nach einer anderen Lösung, die keinen unnötigen Topic-Overhead produziert.

    Nun gibt es für Maps das Element <topichead>, das in der Map einen Eintrag anlegt, der nur als Titel fungiert und nicht auf ein Topic verlinkt werden muss. Aber momentan sieht das wohl so aus, dass im Inhaltsverzeichnis der Inhalt dieses Elements zwar vorkommt, aber im Textfluss es keine solche Überschrift gibt. Im PDF-Output hatte es sogar gar keine Auswirkung 🙁

    Ich werde hier mal weiterrecherchieren. Mal wieder ein Problem, das ganz sicher sehr viele Redaktionen haben, wenn es um DITA geht, nur Lösungsmöglichkeiten findet man keine…

  • Topic-Orientierung

    Das Topic

    Ein Wort, das nun spätestens seit DITA eingeschlagen ist wie eine Bombe und in vieler Munde ist. In der Welt der Software-Hilfen ist das Topic an und für sich schon länger präsent, da dort die Hilfe in Form von Einzelartikeln präsentiert wird. Oftmals wurde hier aber nicht topic-orientiert geschrieben, sondern eben wirklich nur die Präsentationsform der vielen einzelnen Artikel gewählt.

    Doch Topic-Orientierung bedeutet vor allem, dass ein Topic ein Thema behandelt. Und zwar ein einziges, das für sich alleine stehen kann: beispielsweise muss die Beschreibung eines Luftballons getrennt von sein von der Beschreibung wie man ihn aufbläst. Außerdem muss ein Topic kontextunabhängig sein, d.h. ich muss die Beschreibung zum Aufblasen auch verstehen können ohne das Topic mit der allgemeinen Beschreibung gelesen zu haben. Schließlich ist ein Topic in einer Online-Hilfe auch immer ohne Kontext erreichbar.

    Ein weiteres Kernkonzept ist auch, dass ein Thema nur in einem Topic beschrieben wird – und nur in einem! Man schreibt also nicht dreimal dieselbe Information auf, weil das eine für die HTML-Hilfe ist, das eine für das Quickstart-PDF und das andere für das Kompletthandbuch-PDF. Man hat eine Quelle!

    Das bedeutet im nächsten Schritt aber auch, dass man Topics idealerweise ohne Hinblick auf die Erscheinungsform schreibt , d.h. als Autor bin ich losgelöst von der Endausgabe. Das Topic muss in möglichst vielen Dokumentationsprodukten funktionieren können, in verschiedenen Strukturen, sei es in Handbuch A oder Handbuch B, und in verschiedenen Endformaten, sei PDF, HTML oder CHM.

    Die Topic-Klasse

    Eine Topic-Klasse ist eine Bauanleitung für verschiedene Topic-Arten. Ich stelle z.B. fest, dass in meiner Doku ein bestimmtes Schema vorherrscht, z.B. Frage-Antwort und dann halte ich das als Schema fest und beschreibe genau wie man diese Topics nach dem Schema aufbaut.

    Das Festlegen von Topic-Klassen erleichtert einerseits das Schreiben (ich weiß, wo was hingehört) und andererseits das Rezipieren des Textes (ich erkenne Muster und finde mich besser zurecht).

    In DITA gibt es drei Topic-Klassen:

    • Concept: Für Hintergrundinformationen, also den klassischen Prosa-Text.
    • Task: Für Handlungsanleitungen, also den klassischen „Klicken Sie auf…“-Text.
    • Reference: Für Übersichten, Referenzen, Tabellen, z.B. Befehlsübersichten.

    Was soll der Hype?

    Die Frage ist nun natürlich, was das alles bringt:

    • Fröhlicher Nutzer: Die Nutzer lesen selektiv und nicht linear. Ein kompakter, auf ein Thema konzentrierter Informationshappen kommt diesem Verhalten entgegen. Will ein Nutzer was MACHEN, liest er Artikel mit der Überschrift „XY machen“, also Tasks, und will er was genauer WISSEN, liest er Artikel mit der Überschrift „XY – die Grundlage“, also Concepts.
    • Fröhlicher Autor: Ich muss nicht für jedes Topic das Rad neu erfinden, sondern orientiere mich an den Klassen. Topics erleichtern mir außerdem die Wiederverwendung von Inhalten (wenn ich es richtig mache!). Endlich nicht mehr alles doppelt und dreifach schreiben, sondern nur einmal. Endlich nicht mehr eine Änderungen an zwei Stellen durchführen und eine vergessen, sondern einmal und damit überall ändern.

    Klingt einfach…
    … isses aber nich‘ 😉 Es gibt ein paar Spielregeln zu beachten, die für alle gelten und ein paar, die sich jede Firma selbst schreiben muss. Darum geht es in der nächsten Zeit.

  • Screenshots ändern leicht gemacht

    Jeder Redakteur für web-basierte Software kennt das Problem, dass die Software, die man zum Doku schreiben benutzt, oft etwas anzeigt, was der Kunde in der Doku so nicht sehen soll.
    Zum Beispiel steht irgendwo noch „Beta-Version“ im Text oder es werden Testdaten angezeigt („Sie sind als Test Testosteron eingeloggt.“). Man macht also einen Screenshot und ändert den Text ziemlich umständlich in Photoshop. Kurz: eines der nervigen Elemente im Redakteursalltag.

    Für die Webentwicklung nutze ich den Firebug schon recht lange. Das ist ein Firefox-Addon mit man dem das HTML, CSS und Javascript einer Seite live editieren kann. D.h. man kann beispielsweise die Farbe ändern und es wird einem direkt im Browser angezeigt, wie sich das auf die Seite auswirkt. Das Add-on ist vor allem zum Fehlerfinden und CSS-Ausprobieren außerordentlich praktisch.

    Und bis heute bin ich nicht drauf gekommen, dass man Firebug eben auch dazu nutzen kann, das ganz oben genannte Problem zu umgehen (zum Glück war einer meiner Kollegen so schlau). Man editiert die Seite im Firebug und ersetzt oder löscht den unerwünschten Text. Ich habe hierzu einfach mal den Header-Text dieses Blogs geändert.

    So kann man direkt einen Screenshot machen bei dem man danach nicht in Photoshop herummachen muss bis man die richtige Schrift und Schriftgröße hat usw.

    Dass ich da nicht früher drauf gekommen bin… Liegt vielleicht auch daran, dass es ne Weile her ist, seit ich das Problem hatte, da ich ja kaum noch Kundendoku schreibe.

    PS: Nein, das ganze gibt nicht für den Microsoft Internet Explorer. Und wer’s noch nicht wusste: der IE ist doof 😉

  • Lokalisieren mit DITA

    Eigentlich ist es eine ganz einfache Sache bei DITA: man setzt xml:lang-Attribut auf die gewünschte Sprache/Sprachvariante und zack, sind die Standardtexte (so etwas wie „Achtung“, „Voraussetzung“ u.ä.) lokalisiert. DITA bringt schon eine ganze Latte von Sprachdateien mit sich, die diese Texte enthalten und zwar unter DITA_OT/xsl/common.

    Nun habe ich diese Dateien erweitert und das hat in der Standardsprache meiner Pilot-Doku (en-us) auch super geklappt das einzubinden. Als ich nun diese Doku in das britische Englisch (also en-gb) übersetzen wollte, wurden die Standardtexe weiterhin aus der Sprachdatei für en-us eingebunden. Ein kurzer, erfolgreicher Test mit der Lokalisierung ins Deutsche hat ergeben, dass die Lokalisierung an und für sich schon funktioniert, aber nur die Sprachvariante en-gb nicht.

    Und was war des Rätsels Lösung? In der strings.xml wird definiert für welche Sprache welche Sprachdatei verwendet werden soll und da stand glatt für alle Sprachvarianten einer Sprache immer eine „Hauptsprache“ drin. Das heißt in allen Englischvarianten stand en-us als Standard drin, bei Deutsch beispielsweise de-de und so weiter.

    Natürlich war das nirgends dokumentiert, aber dank Community war auch das dann gelöst – und zwar so:

    ALT: <lang xml:lang=“en- gb“ filename=“strings-en-us.xml“
    NEU: <lang xml:lang=“en- gb“ filename=“strings-en-gb.xml“ />

    Ich hatte schon etwas Angst bekommen, dass das Problem komplizierter ist, weil es einige Artikel gab, in denen stand, dass beim PDF-Generieren die Lokalisierung anders läuft. Allerdings ist das nur so, wenn man pdf2 nutzt. Immerhin etwas Gutes hatte es an dieser Stelle, dass wir noch FOP nutzen 😉

  • GeFOPpt

    Wir befinden uns mit DITA noch in einer Pilotphase, d.h. das ganze muss erst einmal so wenig wie möglich kosten, weil man ja nicht weiß, ob der Weg vielleicht doch nicht der Richtige ist. Das heißt also wir nutzen einfach das, was im Open Tool Kit mitgeliefert wird.

    Beim PDF-Output hat sich aber ein Layoutmangel gezeigt, der mir die ganze Zeit schon Kopfzerbrechen bereitet und zwar die Absatzkontrolle. Ganz häufig wird zwischen Überschrift und dazugehörendem Text ein Seitenumbruch gemacht (ist das dann auch ein Schusterjunge?). Jedenfalls ging es mir nicht in den Kopf, dass so ein typografischer Grundsatz bei den vorgefertigten DITA-Stylesheets nicht dabei ist. Flugs mal in die XSL-Dateien geschaut, hab ich festgestellt, dass das entsprechende FO-Attribut keep-with-next.within-page sehr wohl auf always gesetzt ist.

    Aaah, welcher komische Bug verursacht das denn dann?

    Das gute alte 2003
    Tja, nach einigem Googlen konnte ich feststellen, dass FOP 0.20.5 dieses Attribut nicht unterstützt. Kein Wunder, dass es nicht klappt. Aber noch seltsamer finde ich eigentlich, dass das DITA Open Tool Kit diese uralte Version von 2003 mitliefert. Das ist doch echt seltsam. Vor allem findet man nirgends eine Info dazu, warum diese Version benutzt ist oder ob und welche Probleme man hat, wenn man die neue 0.95 nutzt.

    Ich habe die schwere Vermutung die DITA-Leute sind gar nicht so open-source-geil, sprich: keinen Bock auf Frickeln.

    Übrigens finde ich diesen Sprung in der Versionierung auch sehr witzig: eben noch 0.20.5 nun schon ne 0.9er 😉

    fop 0.95 ins DITA-OT
    Also nix wie los und testen, ob man die 0.95 nicht einfach selbst inetgrieren kann. Leider musste ich mich dazu aber nun mal intensiv mit der DITA-Installation beschäftigen. Bisher hatte ich hier immer den XMetal DITA Edition laufen und der hat einem solcherlei Ding gut abgenommen.

    Ich habe mich vor allem an diesen Thread gehalten (http://tech.groups.yahoo.com/group/dita-users/message/8222) und habe also wild in den Konfigurationsdateien herumkonfiguriert, bin aber gnadenlos gescheitert. Am Ende des Threads folgt übrigens das Resümmee, dass selbst wenn man 0.95 zum Laufen bekommt, die Ergebnisse eh nicht so berauschend sind.  Das motiviert zum Aufgeben! Der echte Gnadenschuss für FOP bei uns folgte aber als das Schriftenproblem auftauchte. Doch dazu später mehr…

  • Darwin’s Kartoffeln

    Da verarbeite ich doch gerade die Kartoffeln zum Mittagessen, als mir da was auffällt…

    Die Arbeit lässt einen auch nie in Ruhe!

  • Kurzer Prolog

    Beweggründe dieses Blog zu beginnen
    Ich bin eine begeisterte Anhängerin davon mein (Un-)Wissen zu teilen und das werde ich hier tun. Und zwar erst einmal aus völligem Eigennutz. Ich befinde mich gerade in einer megaspannenden Phase bei der ich viel Neuland betreten werde. Einige dieser Erfahrungen werde ich hier preisgeben, damit ich das ganze nicht vergesse. Denn es kommt ja vielleicht jemand vorbei, der auch was Schlaues dazu zu sagen hat, es vielleicht besser gemacht hat oder einfach mal sehen will, was andere so treiben.

    Wer ist die denn?
    Ich bin eine technische Redakteuse mit Germanistikhintergrund und ergründe in meinem Team zur Zeit die Untiefen der Redaktionsrevolution. Wir wollen alles neu machen, weil auch uns endlich der Ruf des Single-Source-Publishing erreicht hat und wir ihm jetzt auch folgen dürfen. Dabei fliegen einem die dollsten Sachen um die Ohren: XML, DITA, CMSe ohne Ende, User assistance u.v.m. Es geht um neue Herangehensweisen an die Nutzerbedürfnisse, neue Hilfeangebote, damit auch neue Informationsarchitekturen und neue Wege Text zu schreiben.

    Und: JA, technische Redaktion kann Spaß machen 🙂