Die Redakteuse

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 😉

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

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:

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:

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 🙂

In der Softwarebranche kommen technische Redakteure früher oder später mit dem Thema „Oberflächentexte“ in Berührung. Ob sie sie schreiben oder nur verwalten dürfen, variiert von Firma zu Firma.

Bei mir gehört das Betexten der Oberflächen zum Arbeitsalltag und hier möchte ich gerne mal berichten, wie sich das gestalten kann.

Terminologiekontrolle, Hilfe und Beta-Test
Ich sehe es als klaren Vorteil, dass ich die Produkte betexten darf. So kann ich nämlich von vorneherein für eine entsprechende Textqualität sorgen – mit dem richtigen Text in der Software entfällt oft so mancher Hilfetexte. Ich denke, jeder Redakteur musste schon die ein oder andere krude Formulierung von Entwicklern oder Produktmanagern umständlich in der Hilfe erklären…

Für einen Redakteur ist das Betexten der Oberfläche also eine wunderbare Möglichkeit, um für Verständlichkeit und Terminologiekontrolle zu sorgen, aber sie eignet sich auch wunderbar zur Recherche für die späteren Hilfetexte. Dabei ist man dann gleich Beta-Tester, der schon weit vor der Qualitätssicherung die ersten Bugs findet. Ich finde das sehr spannend, weil ich gerne Applikationen neu entdecke und dabei der erste Usability-Tester bin 🙂

Ein Feld, das sicher noch stärker von Redakteuren erobert werden muss 🙂

Wie funktioniert Software-Lokalisierung?
Nun aber mal zu den technischen Grundlagen: Glücklich kann man schon mal sein, wenn der Text überhaupt vom Code getrennt ist 😉 In der Regel machen das die meisten Software-Entwickler auch automatisch so. Erstens ist es für Entwickler übersichtlicher. Zweitens kann man so die Applikation leichter in verschiedenen Sprachen betreiben, was auch meistens gefordert ist.

Gerade im Web-Bereich gibt es verschiedene Möglichkeiten zur Anwendungsbetextung.
Gemeinsam ist den meisten, dass man man pro Sprache eine große Datei mit dem gesamten Anwendungstext hat. Für jede Stelle an der Text erscheinen soll, wird in der Software eine ID vergeben. Dieser ID ist dann in der Datei beliebiger Text zugeordnet: ein Wort oder sogar ganze Sätze.

Nehmen wir als Beispiel mal WordPress, die Blog-Software, die ich hier benutze. Im Screenshot seht ihr den deutschen Text angezeigt:
“

Und hier seht ihr, wie das ganze in der Sprachdatei aussieht:

#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "<b>Sofort</b> publizieren"


Die ID pub_202 wird in der Software als Platzhalter verwendet und je nach gewünschter Sprache wird der dazugehörige Text entweder aus einer deutschen oder bspw. englischen Sprachdatei gezogen. In der englischen Sprachdatei sieht der Eintrag so aus:

#: wp-admin/edit-page-form.php:202
msgid "pub_202"
msgstr "Publish <b>immediately</b>"


Bei einer Software wie WordPress kommt man auf stolze 3342 Texteinträge (Einträge, nicht Wörter!).

Soviel zu dem Grundlegendsten. Wie solche Dateien nun editiert werden können, was es bei der Software-Lokalisierung zu beachten gilt und welche Felsen man wie umschiffen kann… das seht ihr in den bald folgenden Posts 🙂

Es war etwas ruhig in den letzten Monaten. Das lag nicht zuletzt an einem äußerst spannenden Projekt mit DITA, das zwar genug Bloggenswertes ergab, aber auch dafür sorgte, dass ich gar nicht dazu kam zu bloggen bzw. auch mal nicht über DITA nachdenken wollte 🙂

Nichtsdestotrotz will ich meine Erfahrungen zum Thema „User assistance mit DITA“ gerne weitergeben und praktischerweise ist mein Vortragsvorschlag dazu für die tekom-Jahrestagung 2010 angenommen worden 🙂

Einen Vorgeschmack auf den Inhalt gebe ich euch schon hier und freue mich natürlich über jeden Zuhörer 🙂

Die Herausforderung: eine kontext- und tarifabhängige Software-Hilfe, die den Kunden in seinen ersten Schritten begleitet. Dieser Vortrag stellt den Projektverlauf vor, in dem diese „embedded help“ entwickelt wurde. Der Bogen wird dabei von den wirtschaftlichen Beweggründen über die technische Umsetzung mit DITA bis hin zu den Lessons learned gespannt. Einen Schwerpunkt bilden dabei die Möglichkeiten, die man mit DITA out-of-the-box hat, und jene, die man erst selbst entwickeln muss.