Die Redakteuse

Auf der Jahrestagung 2011 gab es die so genannten Trendthemen, welchen dann jeweils ein gesamter Vortragsstrang an einem Tag gewidmet wurde: „Mobile Dokumentation“ und „Content Strategy“. Von ersterem Thema habe ich leider gar nichts mitbekommen, weil ich zum Einen auf  einem 1,5stündigen Workshop war und zum Anderen dann parallel stattfindende Vorträge vom Thema her bevorzugen musste. Sehr schade, aber das war mein persönliches Pech.

Dafür habe ich dann mehrere Vorträge der „Content Strategy“-Reihe mitgenommen, die von Scott Abel moderiert wurde, der im Übrigen auch eine sehr tolle Keynote zur Tagung gehalten hat, die auch sehr in Richtung Content Strategy ging.

Ich habe mal ein paar Schnipsel zu dem Thema festgehalten, die sich mir eingeprägt haben.

„Technical communication IS marketing even if it doesn’t know it’s marketing.“ (Scott Abel)

Der Satz hat mir unheimlich gut gefallen. Das Hilfeangebot ist ab dem Produktkauf DIE eine Kommunikationsschnittstelle zum Kunden. Ab diesem Zeitpunkt sind im Marketingunterlagen und die Webseite egal, denn nun geht es an die Produktnutzung. Und es ist fatal, dass diese Kommunikation häufig vernachlässigt wird, weil es „nur die Doku ist“, denn sie hat die Chance den Kunden in einer negativen Situation mit dem Produkt eventuell nochmal positiv zu stimmen. Und wir alle lieben doch zufriedene Kunden 😉

„The user doesn’t care about your org chart.“ (Noz Urbina)

Der Nutzer hat immer eine ganzheitliche Produktsicht – im Gegensatz zu den Firmen selbst, die sich häufig in historisch gewachsenen Strukturen verstricken und darüber vergessen, wie es dem Nutzer eigentlich so geht. Dem ist es egal wie eine Firma organisiert ist, am Ende braucht und will der Kunde eine Produkterfahrung aus einem Guss. Das heißt z.B., dass überall dieselben Informationen erhältlich sein müssen.

„Software does not only act on content – it provides content.“ (Ray Gallon)

Ray zielt hier darauf ab, dass heutzutage eine größere Verschmelzung zwischen der Software- und der Content-Welt besteht. Software ist heutzutage eben auch Informationslieferant und auch diese Informationen müssen geplant, erstellt und verwaltet werden.

Content ist nicht gleich Content

Eine Sache ist mir  besonders aufgefallen: der Content-Begriff wurde hier weit gefasst und nicht nur auf technische Kommunikation im Sinne von Anleitungen begrenzt. Bei „Content Strategy“ geht es darum, eine ganzheitliche Produktkommunikation aufzubauen, oder wie es Noz Urbina sagte: „Breaking down information silos.“

Technische Kommunikation ist dann eigentlich „nur“ ein Teilaspekt, aber das Know-How, dass die technischen Redaktionen vielfach im Bereich des Single-Source-Publishing besitzen, macht sie sicherlich zu denjenigen in einer Firma, die prädestiniert sind, eine solche Produktkommunikation mit umzusetzen. In der TR hat man sich einfach schon mit allen Fragen des Contents beschäftigt, die bei den anderen Abteilungen vielleicht jetzt erst zum Thema werden.

Zum Blogpost von techwriterkai gab es hierzu auch einen umfassenden Kommentar von Scott Abel, der auch nochmal herausstellt, dass es für ein tatsächliches Umsetzen von einer „Content Strategy“ fast noch wichtiger ist, z.B. supergut präsentieren zu können, sich in Manager hineindenken zu können, sich mit Dingen wie ROI etc. auseinander setzen zu können.

Nur: Wo lernt man solche Dinge eigentlich? Kann man sie lernen? Sollten solche Aspekte stärker im TR-Studium berücksichtigt werden? Im Aufbaustudium zur Führungskraft Technische Redaktion der tecom.ch ist z.B. ein Block „Kommunikation im Unternehmen“ drin, was ich sehr interessant finde. Ich hatte das z.B. gar nicht im Studium und habe da dann eher von Kollegen lernen müssen, die schon länger im Spiel sind.

Fazit

Ich mag meinen Beruf, weil er mir so viele Entwicklungsmöglichkeiten bietet (ok, manchmal verdamme ich das auch, denn man muss sich ja doch auch für etwas entscheiden 😉 ). Deswegen finde ich es immer spannend, neue Möglichkeiten aufgezeigt zu bekommen. Und hier ist es eben der Fakt, dass es vielleicht in Zukunft nicht mehr nur bei der technischen Kommunikation bleiben wird.

Oder wie Scott Abel bei Kai kommentierte:

It’s an exciting time to be in the content industry.

Hier und da konnte man es schon von Twitter ahnen und der eine oder andere wusste es: ich arbeite ab sofort freiberuflich als Technische Redakteurin.

Ich werde weiterhin hier als Redakteuse schreiben, aber wer nun auch mit mir zusammenarbeiten will, darf gerne zu mp dokumentation rübergehen.

Heute mache ich mich auch auf den Weg zur tekom-Jahrestagung – also vielleicht sieht man sich ja 🙂

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″]

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? 🙂

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 🙂