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?