Wiederverwendbarkeit um jeden Preis?

Das Prinzip der Wiederverwendbarkeit ist etwas, das die Software-Entwicklung und die technische Redaktion gemein haben: Redundanz ist böse ;-)

Deswegen macht es mir auch eher Spaß Entwicklern zu erklären, worum es bei meiner Arbeit vor allem geht: sie verstehen nämlich (meistens) ziemlich schnell, welche Probleme wir als Redakteure haben (und warum es Probleme sind!) und wie man die dann z.B. durch Verwendung von XML lösen kann.

Die Kolumne “Be pragmatic, not dogmatic” von Joachim Arrasz hat mich an einige Gedankengänge und Diskussionen zum Thema Wiederverwendung in der Doku erinnert. Die Essenz der Kolumne ist, dass man nicht um jeden Preis immer alles standardisiert und wiederverwendbar machen sollte. Denn am Ende könnten die Mühen dafür höher sein, als der eigentliche Nutzen.

Ich habe so einen Fall z.B. selbst erlebt/produziert. Als ich entdeckte, dass man in DITA auch auf Map-Ebene wiederverwenden kann und so also z.B. einzelne Kapitel wiederverwenden kann, war ich im Wiederverwendungshimmel. Also habe ich die Hilfe, an der ich damals schrieb, sehr sorgfältig in etliche Maps unterteilt – ich könnte es ja mal wiederverwenden. Der Nachteil an der Sache war, dass es nicht so ganz einfach ist den Überblick über so viele Sub-Maps zu behalten. Man muss nach ein paar Wochen erst einmal wieder durchschauen, was wohin referenziert wird etc.

Das Ende vom Lied war, dass ich bis zuletzt keine einzige dieser Maps wiederverwendet habe und mich eigentlich immer geärgert habe, wenn ich mit den vielen kleinen Maps arbeiten musste.

Fazit

Joachim sagt in seinem Artikel:

Die “spätere mögliche Nutzbarkeit” ist für mich sogar ein Showstopper. Dieses Argument habe ich schon so oft gehört, dass es mir in den Ohren klingelt. An dem Tag, an dem diese Wiederverwendbarkeit wirklich greifen würde, kann man immer noch das Refactoring anstoßen und sich zu diesem Zeitpunkt den Mehraufwand einholen.

Ich denke, man muss einfach sorgfältig nach Anwendungsfall entscheiden wie stark man seinen Standards bis zum Ende folgt. Das spätere Umarbeiten (Refactoring) kann durchaus günstiger sein. In meinem Fall wäre es sinnvoller gewesen auf den konkreten Anwendungsfall zu warten und dann eben Zeit zu investieren, die Maps umzustrukturieren.

Geschrieben in DITA,Erweiterter Horizont,Softwaredokumentation | 4 Kommentare

tekom 2011 – Content Strategy

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.

Geschrieben in Erweiterter Horizont,Nice to know | 6 Kommentare

Die Redakteuse schreibt auch für dich!

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 :-)

Logo mp dokumentation

Geschrieben in Beruf,Nice to know | 4 Kommentare