Die Redakteuse

Kategorie: Redakteurs Alltag

  • Jeder kann schreiben

    In diesem Beitrag zum Beruf des technischen Redakteurs habe ich bereits den Punkt „Undankbarkeit“ erwähnt. Wann immer es um Text (und auch um Grafik, wie ich von befreundeten Grafik-Designern weiß) geht, hat die Allgemeinheit die Vorstellung: „Ja, das schreib ich schnell selber zusammen.“ Oft kommen dabei Texte raus, die einem textliebenden Menschen den Magen umdrehen – egal ob es um Anleitungen,  E-Mail-  oder Anwendungstexte geht.

    Was ist „guter Text“?

    Ich führe die Diskussion, warum eben nicht jeder gut schreiben kann, ziemlich oft. Sehr gerne auch mit Entwicklern, die glauben, sie könnten die kleine Fehlermeldung mal eben schnell selber schreiben. Die Sache ist die: einige wenige können sogar ganz gute Texte schreiben, aber sehr viele eben nicht.

    Dabei fällt es mir teilweise schwer, überhaupt zu vermitteln, warum eben die Profis an die Texte gelassen werden sollten und warum es tatsächlich eine halbe Stunde bis Stunde dauern kann einen bestimmten Absatz zu formulieren bis er wirklich gut ist. Irgendwelche Messkriterien für guten Text will ich jetzt schon mal gar nicht beachten, denn bisher hat mich noch nichts überzeugen können.

    Für solche Diskussionen lege ich mir gerade eine kleine persönliche Sammlung an, die textliche „Lowlights“ aus den Bereichen Doku oder Software-GUI enthalten soll, die mir in den letzten Jahren so untergekommen sind – und die dazugehörige Überarbeitung natürlich. Dabei geht es mir nicht um Übersetzungsfehler, sondern die Patzer, die eben schon im Quelltext entstehen (und dann vielleicht zu noch kurioseren Übersetzungen führen). Einige werde ich mit euch teilen, andere werde ich nur im Offline-Leben aus der Kiste zaubern können.

    Meine Hoffnung ist, dass ich mit solchen konkreten Beispielen diese abstrakte Tätigkeit „Text schreiben“ mal irgendwie greifbarer machen kann.

    Warum muss es ein technischer Redakteur sein?

    Bei der DITA Europe Conference in Wien habe ich einen Partnervortrag von Tony Self gesehen, bei dem ein „Doku auf DITA umstellen“-Projekt vorgestellt wurde. In diesem Projekt wurde beschlossen, dass in der Firma gescheite Kundendokumentation benötigt wird (yay!). Da man aber keine Redakteure hatte, rekrutierte man aus der Qualitätssicherung rund um die Welt Mitarbeiter, die „nebenbei“ noch schreiben sollten. Für das „Drumherum“ und für die Organisation dessen holte man sich immerhin Tony ins Boot. Aber ehrlich gesagt hat mich dieses Vorgehen baff gemacht und es kamen mir sorgenvolle Gedanken wie „Wenn das jetzt immer mehr so machen, weil es ‚gut genug‘ ist, was ist dann meine Ausbildung noch wert?“.

    Beim Thema „TR-Redaktionssystem“ bemerke ich inzwischen auch oft, dass die Leute denken, dass man da einfach jeden davor setzen können muss. Ich vermute, dass dieser Irrglaube von der unglückseligen Benennung „Redaktionssystem /CMS“ herrührt, die die meisten Leute eben doch an ein Web-CMS denken lässt. Und bei einem Web-CMS ist es ja das Wichtigste, den Leuten das Editieren piepeinfach zu machen.

    Ein TR-Redaktionssystem soll das Editieren zwar auch einfach gestalten und die Leute von Technik und Layout fernhalten, aber der Punkt ist, dass hier doch sehr viel Basiswissen da sein muss, damit man so ein System effizient nutzt, z.B. in Sachen Modularisierung, Wiederverwendung, bedingtem Text, Übersetzungsmanagement, Standardisierung etc.

    (Ich will damit übrigens nicht sagen, dass ein TR unbedingt studiert haben muss. Wie überall gibt es auch hier sehr gute Quereinsteiger. Aber wenn man hergeht und einfach irgendjemanden nimmt und mit der Aufgabe ein Handbuch zu schreiben vor ein Redaktionssystem setzt… Naja, lustig wird das ziemlich sicher nicht… )

    Auf in den Kampf

    Ich will mir in der nächsten Zeit mal Gedanken dazu machen, wie ich fachfremden Leuten besser klar machen kann, was wir TRler eigentlich machen und warum wir es machen sollten und es nicht jeder kann. Und zwar einerseits in Hinblick auf das Thema „Schreiben“, aber auch im Hinblick auf Sachen wie „CMS/Übersetzungsmanagement/Workflows“.  Das wird ne recht schwierige Sache, aber hey – Informationsvermittlung sollte doch für eine/n TR kein Problem sein  😉

    Und wie führt ihr diese Diskussionen? Oder müsst ihr die etwas gar nicht führen? 🙂

  • Muttersprachen-Prinzip

    Mein letzter Blogpost wurde netterweise von Sarah O’Keefe übersetzt und im Scriptorium-Blog „wiederverwendet“. In Anbetracht der durchaus großen englischsprachigen Blog-Szene im Bereich Technische Redaktion habe ich mir schon oft überlegt auf Englisch zu schreiben, weil ich damit vermutlich ein größeres Publikum erreichen würde. Und Sarah hätte hier einfach nur verlinken können 😉

    Warum ich es nicht mache? Deutsch ist meine Muttersprache. Mein Englisch ist durchaus gut – ich habe ein recht gutes Sprachgefühl und kann einigermaßen flüssige Konversationen halten, wenn ich mich warmgeredet habe. Aber es kostest mich unglaublich viel mehr Zeit einen englischen Text zu verfassen, der in Inhalt und auch Ausdruck genauso rüberkommt wie eine deutsche Version. Da steht mir mein englisches Sprachgefühl sogar ein bisschen im Weg, weil ich irgendwie merke, wenn der Satz nicht passt, aber es nicht besser machen kann. Am Ende kann ich mir nicht sicher sein, dass der Text wirklich so rüberkommt, wie ich es mir gedacht habe, weil dafür dieses letzte Stück Sprachgefühl fehlt, das man nur bekommt, wenn man in der entsprechenden Kultur lebt oder aufgewachsen ist. Ganz zu schweigen davon, dass der enorme Zeitaufwand das Schreiben an und für sich vermutlich sehr schnell komplett lähmen würde…

    Für mich heißt das „Muttersprachen-Prinzip“ Texte ausschließlich in meiner Muttersprache zu verfassen, für einen Übersetzer heißt es ausschließlich in seine Muttersprache zu übersetzen. Am eigenen Leib erfahre ich oft, dass ich nur nach diesem Prinzip schreiben sollte. Doch immer wieder lese ich in Stellenanzeigen für Technische Redakteure die Anforderung „Dokumentation in deutscher und englischer Sprache“ verfassen. Und jedes Mal bin ich ein klein wenig ärgerlich, dass solche Anforderungen gestellt werden. Ein Grund für die Firmen ist sicherlich, dass es kostengünstiger und schneller ist, den Quelltext sofort in Englisch zu erstellen. Gerade wenn man in „exotischere“ Sprachen (asiatische Sprachen zum Beispiel) übersetzt, ist es leichter Übersetzer mit dem Sprachpaar „Koreanisch-Englisch“ zu bekommen als „Koreanisch-Deutsch“.

    Fazit
    Ich glaube, der Endkunde wird es immer irgendwie merken, wenn ein Nicht-Muttersprachler einen Text geschrieben hat. Zumindest hab ich die Erfahrung schon oft gemacht. Viele beachten diesen Aspekt nicht, wenn es um das Schreiben oder Übersetzen geht, bzw. ist er ihnen nicht bewusst. In der Realität sieht es nun aber leider doch so aus, als ob man als deutschsprachiger Redakteur auch immer öfter Englisch schreiben muss. Zu Lasten der Qualität… Aber vermutlich setzen hier viele Firmen auf das oft zitierte „Gut genug“.

  • Content-Management über Ordner und SubVersion

    Wie man meinem Blog entnehmen kann, beschäftige ich mich seit ca. 2 Jahren mit DITA. Anfangs haben wir unsere Daten über Ordner und SVN verwaltet. Inzwischen haben wir schon fast alles im Redaktionssystem drin – das SVN ist bald Geschichte. Da ich aber weiß, dass ein Redaktionssystem häufig zu den unerfüllten Träumen von technischen Redakteuren gehört, teile ich hier mal meine Erfahrungen mit DITA und SVN.

    Übersetzungsmanagement

    Die einzelnen Sprachen auf demselben Stand zu halten gestaltet sich schwierig. Man muss sehr diszipliniert sein, denn sonst vergisst man leicht, dass ein kleiner Fix in der einen Sprache auf die anderen übertragen werden sollte.

    Bei Änderungen an bestehenden Daten hat man das Problem, das man das Delta entweder manuell rauskopieren, übersetzen und dann wieder reinkopieren muss. Oder man gibt eben immer nur komplette Topics zur Übersetzung, auch wenn nur ein Satz neu ist (was aber schnell recht teuer werden kann).

    Verwaltung

    Versionshistorie ist Gold wert 🙂

    Dateileichen herauszufinden ist schwierig, z.B. wenn man in der Konzeptionsphase mehrere Topics angelegt hat und am Ende einige gar nicht braucht. Bei uns sind solche Leichen teilweise übersetzt worden, obwohl sie nie gebraucht wurden. Hier können kleine Skripte hilfreich sein, die alle Dateien listen, die in keiner Map referenziert sind.

    Man schludert schnell mit SVN-Kommentaren und am Ende weiß man selber nicht mehr, was man eigentlich mit  dem Kommentar „Änderung“ gemeint hat 😉

    Tags und Branches sind äußerst wichtig, damit man komfortabel an neuen Projekten arbeiten kann und immer noch gleichzeitig den aktuellen Online-Stand aktualisieren kann. Am Anfang hab ich nur auf dem trunk gearbeitet, was darin resultierte, dass ich im Projektverlauf keine Updates am Online-Stand machen konnte und als sich dann das Projekt verschob, alle Änderungen händisch zurücknehmen musste.

    Wenn man die Ordner erst einmal angelegt hat, wird es ziemlich kompliziert sie wieder zu reorganisieren, wenn man z.B. merkt, dass die Struktur doch nicht so gut ist. Zum einen können Referenzen zwischen Topics aus verschiedenen Ordnern kaputt gehen, zum anderen muss man im SVN aufpassen, dass man die Versionshistorie nicht verliert.

    Fazit

    Man kann auch topicorientiert schreiben und mit XML arbeiten ohne ein CMS zu benutzen. Eine Sache, die gern außer Acht gelassen wird, aber ich muss sagen, dass es nicht drauf ankommt welches Tool oder welche Standardisierungsmethode man verwendet – wichtig ist, was am Ende rauskommt!

    Wenn man als Redaktion also kein Redaktionssystem zur Verfügung hat und trotzdem mit DITA arbeiten will, ist eine Verwaltung über Ordner und SVN meiner Meinung nach eine super Alternative.  Die Benutzung von SVN ist sogar absolut obligatorisch, wie ich finde.

    Bei dieser Arbeitsweise müssen allerdings viele Dinge über Regeln und Workflows als „Denk dran“-Lösung abgedeckt werden, und die Erfahrung zeigt nun mal, dass man im Eifer des Projektgefechts nicht immer dran denkt.  Man kann zwar Skripte schreiben, die einem bestimmte Dinge abnehmen, aber am Ende muss man eben doch dran denken, das auch zu benutzen. Wenn sich mit der Zeit solche kleinen Fehler einschleichen, hat man irgendwann ein Problem. Man muss das Redaktionsteam außerdem ausführlich  schulen, denn die Grundfunktionen von SVN sind relativ schnell drin, aber gerade solche Dinge wie Tags/Branches/Merging sind nicht intuitiv.

  • Softwarelokalisierung: Formate und Arbeitsablauf

    Weiter geht es mit meiner angefangenen Serie zur Software-Lokalisierung für Technische Redakteure

    Formate und Tools
    Die Formate mit denen man sich auseinandersetzen muss, sind vielfältig. Es hängt von der eingesetzten Technologie ab und vielleicht auch von den Präferenzen der jeweiligen Entwicker. Mit diesen Formaten habe ich im Bereich von Webapplikationen am häufigsten zu tun:

    • PO-Dateien, oftmals bei Anwendungen mit JavaScript, PHP (z.B. WordPress)
    • selbst definierte XML-Dateien
    • Java Properties

    Jedes dieser Formate hat seine Eigenarten, wie etwas unterschiedliche Zeichenkodierungen (UTF-8, ISO-8859-1).  Bei Java Properties muss man Sonderzeichen beispielsweise gesondert kodieren – so wird aus einem „ü“ ein \u00fc. Glücklicherweise gibt es auch Editoren, die einem solche Späße übernehmen oder die das Editieren generell vereinfachen (für PO ist es z.B. PO Edit).

    Diese Formate sind einigermaßen gängig und können heutzutage auch von den allseits bekannten Translation-Memory-Systemen eingelesen werden, die dann diese Kodierung beispielsweise auch völlig selbständig im Hintergrund übernehmen.

    Datenaustausch und Pflege
    Der Datenaustausch findet bei uns meistens über das SubVersion der Entwicklung statt. Die Entwickler generieren leere Dateien mit IDs, wir checken diese aus, befüllen die IDs mit Werten (also Text) und checken sie wieder ein.

    Das initiale Betexten und Übersetzen solcher Textdateien ist noch eine schöne Sache. Man hat eine Datei von der man weiß, dass man sie nun komplett überarbeiten bzw. übersetzen muss.

    Unangenehm kann es dagegen werden, wenn bereits bestehende Textdateien um einige Zeilen erweitert werden. Das kann dann unter Umständen so aussehen:

    1. In der ellenlangen Datei nach der leeren ID suchen
    2. Einen Text eingeben.
    3. Diesen Text rauskopieren in eine Extra-Datei
    4. Diese Datei zu Übersetzung geben
    5. Die Übersetzung manuell in die ellenlange Textdatei zurückkopieren.
    6. sie dann herauskopiert, zur Übersetzung gibt und am Ende manuell die fertigen Übersetzungen in die Textdateien zurückpfriemelt.

    Wie man sieht: Eine sehr mühselige, zeitaufwändige und fehleranfällige Tätigkeit, die man ziemlich schnell mit Skripten automatisieren sollte. Man kann sich z.B. kleine Skripte bauen, die die neuen Strings automatisch in eine neue Datei extrahieren, die man dann bequmm betexten/übersetzen lassen kann. Und die Skripte bauen die Übersetzungen anschließend wieder zurück, so dass man sich diese fehleranfälligen Zwischenschritte sparen kann.


  • Arbeite mit DITA und sprich darüber?

    Ich war in den letzten Monaten häufiger in der Situation, das ich Kollegen aus anderen nicht-TR-Abteilungen erklären musste, wie wir in unserem Team eigentlich inzwischen Hilfe schreiben und warum manches nicht mehr so läuft wie früher.

    Das Wort DITA nehme ich dabei übrigens eigentlich nur ganz nebenbei in den Mund. Warum? Weil es den Damen und Herren total egal sein kann 🙂 Das ist jetzt nicht überheblich gemeint, aber es ist für sie ja auch gar nicht wichtig zu wissen,dass wir mit DITA arbeiten. Viele Leute konzentrieren sich oft viel zu sehr darauf einem zu erklären WIE sie etwas machen anstatt dass sie einem erklären WAS es den Beteiligten bringt. Oft beobachtet bei Entwicklern, die einem gern die Namen der neuesten Trendtechnologien um die Ohren hauen, die einen dann nur ratlos schauen lassen…

    In unserem Fall ist das Prinzip unserer neuen Arbeitsweise an und für sich beispielsweise das wirklich Essentielle:

    1. Standardisierung
    2. Topic-Orientierung
    3. Trennung von Inhalt und Layout

    Das sind die wichtigsten nach außen sichtbaren Vorteile und ich konzentriere mich lieber darauf diese transparent zu machen als dass ich groß DITA erkläre.

    Man muss hierbei bedenken, dass sich das Vehikel mit dem wir diese Prinzipien umsetzen, auch mal ändern kann.

    Die Abteilungen mit denen ich hier zusammen arbeite sind in der Regel vom Endergebnis betroffen und dann kann ihnen das WIE völlig egal sein. Sie müssen vor allem wissen warum sie die neue Arbeitsweise gut finden sollen 😉

  • Technische Redaktion – eine gute Wahl?

    Diese Woche bekam ich eine Anfrage einer zukünftigen TR-Studentin, die gerade etwas verunsichert ist:

    Seit ich die Zusage habe stolpere ich aber eigtl. nur noch über Berichte, wie langweilig und undankbar der Job als Technische Redakteurin sei und dass sowieso die meisten nicht lange in diesem Job durchhalten. Langweilig deswegen, weil es oft nur noch darum ginge, die von den Entwicklern gelieferten Texte in die Doku zu kippen. […] Wie beurteilst du denn die Punkte Langeweile und Undankbarkeit? Was denkst du, sollte man unbedingt mitbringen, wenn man diesen Beruf ausüben will?

    Suche dir eine interessante Branche
    Das ist für mich einer der wichtigsten Punkte. Bei mir waren es schon immer Software und Internettechnologien, die so mein Steckenpferd waren. Für mich sind die Recherche und das Ordnen meiner Ergebnisse mitunter die interessantesten Aspekte an der Arbeit und da sollte einen der Gegenstand doch etwas mehr interessieren. Einen Ausflug in die Elektrotechnik habe ich z.B. sehr schnell beendet, da ich kein besonderes Faible dafür habe. Ich konnte mich schon in die Materie einarbeiten, aber am Ende fiel es mir immer schwer mich in den Installateur oder Inbetriebnehmer hinzuversetzen – und dementsprechend habe ich sicherlich auch nicht die besten Hilfetexte meiner Laufbahn abgeliefert. Es war einfach nichts für mich.
    Suche dir deine Schwerpunkte

    Ich hab schon die Vielfalt des Studiums, des Jobs und der späteren Möglichkeiten erwähnt. Man kann sich seinen Schwerpunkt suchen und den möglichst bei der Jobwahl berücksichtigen. Wenn ich bspw. feststellen würde, dass ich nur Entwicklertexte in ein Worddokument reinkopieren und umformatieren soll… DAS ist  keine technische Redaktion.

    Mach was draus

    Was ist, wenn man schon im Job steckt und nicht so ganz zufrieden ist? Nun, ein Weg ist mal zu schauen, was der Horizont um einen hergibt. Also Augen offen  halten und selbst aktiv  werden. Was kann man bspw. im Team und in der Zusammenarbeit optimieren? Du merkst z.B. dass es doch immer wie zu Inkonsistenzen beim Schreiben kommt, weil der Redaktionsleitfaden nicht eindeutig ist. Hey, organisiere ein  regelmäßiges Review von Texten und ggf. das Update des Leitfadens. Oder du fängst mal an überall für Terminologiearbeit zu werben, weil diese aktuell nur von der TR betrieben wird.

    Bringe folgendes mit

    Neugier, Geduld (auch bekannt als:  Leidensfähigkeit und langer Atem), gute Strukturierungsfähigkeit, ein bisschen Unnachgiebigkeit (auch bekannt als: den Technikern mit 100 Rückfragen alles aus der Nase ziehen), ein bisschen Kämpfertum (auch bekannt als: und wir kriegen euch alle dazu diesen Term zu verwenden!). Und natürlich: einwandfreie Sprachkenntnisse und Interesse an Technik.

    Akzeptiere einiges… 🙂

    Gegen die Langweile kann man schon vorab sehr viel tun – das ist meine Meinung. Außer man ist vielleicht in einer sehr strengen und unflexiblen Umgebung, aber für mich wäre sowas schon mal gar nichts 😉

    Und nun zurUndankbarkeit… ja… das ist so. Jeder kann schreiben (handwerklich gesehen) und manche verstehen nicht einmal den Unterschied zwischen dem vom Entwickler geschriebenen Text und dem vom Redakteur (ok, das sind echt die ganz harten Nüsse, die man am besten ab sofort mit dem bösen Blick straft). An der TR wird gern gespart – mit Zeit,  Geld und Anerkennung. Manchmal kann man die Hilfe nicht so gut machen wie man gerne möchte, manchmal kriegt man doch wieder einen Term um die Ohren geklatscht, den das Marketing dann bitte doch anders haben möchte… Manchmal kriegt man einfach echt nur die Krise.

    Das muss man teilweise einfach ertragen können – und teilweise muss man einfach so kämpferisch sein und unermüdlich immer wieder die Wichtigkeit des eigenes Berufs betonen. Für mich ist dieser Beruf gerade wegen seiner Vielfalt noch immer genau mein Ding. Früher sah ich es als Makel ein Allrounder zu sein, so nach dem Motto: man kann viel, aber nichts zu 100%. Inzwischen weiß ich, dass auch 75-80% langen und genau das mein Vorteil ist 🙂

    Nachtrag: Sehr interessant hierzu ist auch der Artikel Tired of technical writing? How I revjuvenated my career

  • Technische Redaktion – More than words

    Vor kurzem gab es ein Ehemaligentreffen an der HS Karlsruhe an der ich meinen Master in Technischer Redaktion gemacht habe und bei dem auch Noch-Studenten dabei waren. Bei dieser Gelegenheit sollten Ehemalige Vorträge über ihre bisherigen Berufserfahrungen halten und da musste ich einfach darüber referieren, wie ich die Technische Redaktion inzwischen sehe 🙂

    Bei der letzten tekom-Tagung wurde ich von Studenten zum Thema „Was gefällt Ihnen besonders an dem Beruf des technischen Redakteurs?“ interviewt und spontan war meine Antwort: „Die Vielfalt!“ Bei der Erklärung meines Berufs sage ich zwar oft:  „Da schreibt man Hilfen, also Handbücher“, aber tatsächlich macht es doch den kleinsten Teil meiner tatsächlichen Arbeit aus. Und das hätte ich mir zu Studiumszeiten nicht wirklich träumen lassen 🙂 Für mich ist der Beruf der technischen Redakteurin unglaublich facettenreich und ich habe in den letzten Jahren sehr viele Facetten ausprobiert.

    Klassische Rollen

    Die klassische Rollendefinition wie ich sie aus dem Studium mitgenommen habe, sieht so aus:

    rollen_klassisch

    Das deckt sich ziemlich mit den Studieninhalten, die man hat. Hm, ist das wirklich alles?

    Wie es wirklich sein kann

    Die Erfahrungen aus den letzten Jahren ergeben für mich eine deutlichere Erweiterung der möglichen Rollen des Redakteurs:

    rollen_moeglich

    In meiner Laufbahn hab ich diese Rollen ausprobieren können und durch das Studium hab ich mich trotzdem dafür qualifiziert gefühlt. Denn man lernt ja im Studium nicht nur irgendwelche konkreten Fertigkeiten, also z.B. wie man Handbücher schreibt, sondern auch etwas allgemeinere Konzepte, wie z.B. „Wie mache ich etwas verständlich?“. Und genau das kann einen etwa zum User Experience Designer qualifizieren oder eben zum Produkttrainer. Genauso kann man mit dem Wissen aus Content-Management in den Bereich des Wissensmanagement einsteigen (WMS statt CMS eben 😉 ).

    Was ihr wollt…

    Ich habe zwischendurch immer mal die Phase gehabt, dass ich glaubte doch mal ganz klassisch Handbücher schreiben zu müssen, damit ich mal auch „richtige technische Redaktion“ mache. In dieser Zeit war ich äußerst unglücklich bei der Arbeit – es war einfach nichts für mich. Dass es tatsächlich ein unglaublicher Vorteil und total spannend ist, ein Allrounder zu sein (was für mich den TRler ausmacht), hab ich erst später erkannt. Es gibt einem nämlich die wunderbare Möglichkeit sich aus den vielen Richtungen, die man im Studium mitbekommt, eine oder ein paar herauszupicken. Das kann eine eher sprachliche Orientierung hin zum Autor und Terminologen sein oder eine eher technische hin zum XSLT-Entwickler oder Web-Entwickler etc.  Und am Ende steht im Berufstitel auf der Visitenkarte vielleicht gar nichts mit „Redakteur“ oder „Writer“, aber wie immer kommt es ja nicht so stark auf die Verpackung an 😉 Man muss sich dessen bewusst werden, was einem Spaß macht und einen wirklich interessiert (ja, ich weiß, das ist der schwere Teil). Und das ist meiner Erfahrung nach schon mal die halbe Miete 🙂

  • tekom-Jahrestagung 2009 #2 – Dating DITA

    Ich war in sage und schreiben einem DITA-Vortrag. Erstens gab es davon gar nicht so viele („Der Hype flaut ab“, wie ein CMS-Hersteller mir bestätigte), zweitens waren die meisten davon eher auf einem Anfängerlevel.

    Bei diesem Vortrag war ich fast geneigt nicht hinzugehen, da mir der Titel zuerst zu gewollt witzig vorkam. Ein Blick in den Tagungsband hat mich dann doch überzeugt.

    Hier ging es um einen rein semantischen Blick auf DITA – was ich zur Abwechslung mal sehr erfrischend fand. Das ganze hier spielte hier keine Rolle:  „Dann kannst du auch noch das machen – und Maps und Conref… und DITAVAL… das Open Toolkit und Spezialisierung“

    DITA – die Informationsarchitektur

    Im Blickpunkt stand: die Sicht des Redakteurs. Kann man als Redakteur relativ einfach mit der DITA-DTD arbeiten? Erschließen sich bspw. Elementnamen sofort („Self-documenting structure“), braucht man am Ende keinen Styleguide mehr?

    Ralf Steiner und sein Team haben sich DITA angeschaut und ihnen ist Folgendes aufgefallen

    • endlos viele Titles (searchtitle, navtitle, title) und keine gute Abgrenzung
    • Abgrenzung zwischen abstract und shortdesc unklar
    • das Schachteln von versch. Topictypen ist fragwürdig.
      Ich finde es schon fragwürdig, zwei tasks ineinander zu schachteln.
    • Unterschied zwischen choices und choicetable ist unklar.
      Für mich ist das eine Layoutsache, manchmal lassen sich Handlungsvarianten besser tabellarisch darstellen. Aber natürlich ist das wieder so eine Sache, weil man ja hier semantisch denken sollte und nicht layoutorientiert. Doch zu 100% lässt sich das nie trennen, wie ich festgestellt habe.
    • Was soll das info-Element, wo doch ein Task keine Hintergrundinfo geben soll?
      Nun ja, ganz ohne Hintergrundinfo geht es eben nicht. Ich platziere hier auch nur Hintergrundinfo, die sich auf den spezifischen Schritt bezieht, daher hab ich an dem Element nichts auszusetzen.
    • Wozu braucht man steps-unordered?
      Ja, allerdings, wozu? Ob die Steps später nummeriert werden oder als Bullets dargestelt werden, entscheidet sich doch erst beim Generieren.
    • Die Concept-Topics sind eine Glaskugel aus der man alles ableiten kann.
      Oh ja! Ich habe bis heute nur eine vage Idee, wie ich Concepts wirklich standardisieren soll.
    • Die Benennung der Element ist inkonsistent bzw. nicht sprechend. Man könnte eine dl auch deflist nennen, äquvalent zur linklist.

    Ich füge noch hinzu:

    • Abgrenzung zwischen context und shortdesc ist schwammig.
    • Wozu werden related-links ermöglicht, wenn man doch nur die Wiederverwendung damit erschwert und Relationship tables eigentlich viel besser sind?
    • Für Tasten gibt es kein Element! Wie soll den Software-Dokumentation ohne Tasten gehen? Ich habe uicontrol daher eben auch hierfür als Auszeichnungselement definiert.
    • Ich kann das p überall benutzen, aber sollte ich auch? Zum Beispiel innerhalb von note, li, shortdesc, context etc.

    DITA – ohne Styleguide? Lieber nicht…

    Das ist das Fazit von Ralf. Und da kann ich mich voll und ganz anschließen. Ich habe auch zuerst ein Funktionsdesign erarbeitet und dann quasi mit DITA verheiratet. Es sind einfach zu viele Elemente, die nicht eindeutig out-of-the-box zu befüllen sind. Und man hat ja auch bei der Strukturierung immer noch sehr viele Freiheiten, die am Ende dann auch nicht mehr wirklich Standardisierung bedeuten.

    Insgesamt ein sehr guter und gut gehaltener Vortrag, der sich mal dem gewidmet hat, auf das es am Ende ankommt: kann man gut damit arbeiten?

    PS: Zu viele Bilder der personifizierten DITA sind dann irgendwann auch nicht mehr witzig…

  • Task-Grenzen

    Beim Texten von Tasks gibt es etwas, was mich als Redakteur von Software-Doku seit den Anfangstagen als TR regelmäßig verrückt macht: wo hört ein Task auf und wo beginnt der nächste? Speziell bei Handlungen, die im Großen und Ganzen dasselbe Ziel haben, aber die man auf verschiedenen Wegen erreichen kann.

    1 Handlung = mehrere Varianten

    Ein gängiges Beispiel ist das Einfügen von Bildern, z.B. in ein Blog oder eine Website.

    Ziel: Bild in den Artikel einfügen

    Möglichkeiten zur Zielerreichung:

    • Bild vom PC hochladen
    • Bild aus dem Web verlinken
    • Bild aus vorhandener Galerie einfügen

    Die Handlungen sind in den ersten Schritten typischerweise identisch, aber unterscheiden sich dann in den meisten folgenden Schritten. Nur das Ziel ist am Ende dasselbe: ein Bild wurde eingefügt. Ich bin nie so ganz schlüssig, was ich in solchen Fällen tun soll.

    Option 1:Rigoroses Splitten

    ich teile das ganz rigoros in drei Topics auf. Der Nutzer sieht ganz spezifisch an der Topic-Überschrift um was es geht.

    • Bild vom PC hochladen
    • Bild aus dem Web verlinken
    • Bild aus vorhandener Galerie einfügen

    Das Problem ist, dass ich auf diese Weise ganz schön viele Topics produziere, die den Nutzer fast erschlagen. Zudem gibt es auch Nutzer, die nur wissen, dass sie ein Bild einfügen wollen, aber mit den drei Optionen einfach so nichts anfangen können. Und prinzipiell sucht wahrscheinlich auch ein erfahrener Nutzer eher nach „Bild einfügen“ als nach „aus dem Web verlinken“.

    Option 2: In ein Topic verpacken

    Es gibt einen Ort an dem der Nutzer nachschaut – bingo, da sieht er alles was zu dem Thema wissen muss.

    • Bild einfügen

    Das Problem ist, dass man so unter Umständen ganz schön lange Topics produziert – zudem kann man es kaum in die SITA-Struktur packen. Es gibt zwar Handlungsvarianten (choice), aber die beziehen sich meist auf einen Handlungsschritt, und nicht einen ganzen Handlungsstrang. Sowas wäre mir am liebsten:


    Um ein Bild hochzuladen, wählen Sie eine der folgenden Möglichkeiten:



    Um eine eigene Datei hochzuladen...
    ...


    Um eine Datei aus dem Web zu verlinken...
    ...


    Aber das lässt DITA nicht zu. Mir ist auch klar warum: damit fällt es einem leichter mehrere Topics in eins zu verpacken. Und man will ja immer nur ein Thema pro Topic. Dummerweise ist das Leben nicht immer so einfach. Hier würde ich mir zumindest mehr Flexibilität wünschen.

    Fazit
    Hält man sich streng an die DITA-Informationsarchitektur kann man eigentlich nicht anders als das auf 3 Topics zu splitten. Aber aus Nutzersicht gefällt es mir nicht.

  • Sollen wir uns ums Drucken drücken?

    Es ist dieser Satz, den man als Redakteur echt hasst:

    Liest das überhaupt jemand?

    Etwas überzogen könnte man antworten: Ja, ich hoffe es. ich weiß es nicht, aber ich hoffe es. Und falls dem nicht so ist, so soll bitte niemand eine Möglichkeit erfinden das nachzuprüfen, vielleicht werden wir sonst alle abgeschafft. Und das wäre echt doof.

    Das mal so nebenbei 😉 Eigentlich geht es hier mehr um die Frage: Wie stark werden gedruckte Handbücher genutzt?

    Gedruckte Handbücher – was Besonderes?

    Angeregt durch die Meldung, dass Daimler zukünftig nur noch „Schnelleinstiege /Erste Schritte“ drucken wird, während der Rest auf DVD geliefert wird, habe ich mal wieder über das gedruckte Handbuch nachgedacht.

    Es gibt hier viele Nostalgiker, die finden, dass ein Druckerzeugnis ein Produkt besonders aufwertet. „Das hat einen besonderen Charme“ war in einem Kommentar zum Heise-Artikel zu lesen. Natürlich ist ein fertiges, kleines Büchlein immer etwas Besonderes. Vor allem für den, der er es erstellt hat. Danach hat man nämlich was Hübsches und Handfestes in der Hand. Aber mal ganz ehrlich: was ist denn das für ein Argument? Auch Mist kann hübsch verpackt sein und (fast) kein Mensch kauft etwas wg. der tollen Bedienungsanleitung, die dabei ist.

    Die große Kiste im Redakteusen-Giftschrank

    Als Redakteurin beäuge ich Bedienungsanleitungen neu erstandener Produkte immer kurz, aber eigentlich nur aus beruflichem Interesse. Mit einem kurzen Blick scanne ich ab, ob Dilettanten am Werk waren, halb-standardisierende oder voll standadisierende Redakteure. Danach wandern die Anleitungen in die große Holzkiste im Schrank – für den Fall, dass ich sie mal brauche.

    Es gibt EINE Situation in der ich regelmäßig die Kiste öffne: immer dann, wenn ich Salz in meine Spülmaschine nachfüllen muss. Ich kann es mir e-i-n-f-a-c-h nicht merken und j-e-d-e-s Mal guck ich auch noch im falschen Kapitel der Anleitung.

    Darüber hinaus gab es in den letzten Monaten EINE weitere Situation, dass ich diese Kiste geöffnet habe. Ich wollte eine MP3-Datei als Klingelton auf mein Handy laden. Ich wusste von der damaligen Verkaufsseite, dass mein Handy das kann. Meine Bedienungsanleitung erwähnte das nicht und sie erwähnte auch nicht, dass sie nicht vollständig ist. Das hat mir dann das Internet erzählt.

    Kurz: diese Kiste ist bei mir eigentlich nur ein Platzverschwender.

    Und noch ein Geständnis: ich klicke, drücke, schiebe lieber wild rum, bevor ich in die Anleitung schaue. So sieht’s aus! Aber immerhin: wenn ich dann nicht weiterkomme, schau ich dann doch 😉

    Wann man das Gedruckte braucht

    Ich ganz persönlich brauche das Gedruckte v.a. für Dinge, die ich öfters, aber doch selten genug machen muss. Das sind in der Regel Dinge, die nicht am PC passieren. Im Falle der Spülmaschine hätte ich am liebsten ein kleines Blättchen, dass ich mir an die Küchenpinnwand heften kann.

    Im Auto brauche auch ich die Bedienungsanleitung recht selten, außer es ist ein neues Auto und ich will kurz die wichtigsten Dinge abchecken. ABER angenommen ich bin unterwegs und ein seltsames Lämpchen leuchtet plötzlich auf, dass ich nach all den Kilometern noch nie in meinem Auto gesehen habe. Wenn ich nun meine ausführliche Anleitung dabei habe, kann ich nachschauen, ob das bloß die Lampe für „Sie sollten mal langsam wieder über einen Wartungstermin nachdenken“ ist oder die für „Achtung, hier ist irgendetwas Ominöses/Kleines kaputt, das sofort repariert werden muss und dessen Austausch Sie 500 Euro kosten wird“.

    D.h. ich brauche das Gedruckte auch in Situationen in denen ich kaum andere Möglichkeiten habe an die entsprechenden Informationen zu kommen.

    Papierlose Anleitungen? – Jein

    Am Ende lässt sich auch hier nicht sagen: bald werden gar keine Anleitungen gedruckt. Zumindest hoffe ich, dass es nicht so kommt! Es hängt mal wieder stark von der Nutzungssituation ab,  in der sich ein Nutzer in der Regel befindet.

    • Internet-Anwendungen/Sofware: in dieser Situation ist man 2 Mausklicks von der ulimatven Informationsquelle entfernt. Warum aufstehen, die Kiste öffnen, die richtige Anleitung suchen und dann auch noch die richtige Seite? Und gerade bei Internet-Anwendungen ist die gedruckte Anleitung vermutlich auch noch hoffnungslos veraltet.
    • Heimgeräte (weiße Ware/Recorder/Handys): die Grundfunktionen handlich und übersichtlich. „Ich muss wissen, wie ich die neue Staffel von „24“ aufnehmen kann“
    • Maschinen/Autos/Rasenmäher/Jumbo-Jets etc: „Hilfe, explodiert das gleich, wenn das und das leuchtet/blinkt/piepst? Kann ich nun weiterfahren? „In dieser Situation bringt eine DVD herzlich wenig.

    Oder ist es am Ende dann eben doch nur der Nutzen für den Hersteller, der zählen wird?