Die Redakteuse

So, drei anstrengende Tage liegen hinter mir… Ich weiß gar nicht wo ich eigentlich am besten anfangen soll… Deswegen fang ich mal mit Vorträgen an, die ich besonders gut fand.

Analyzing User Assistance Deliverables: Developing Your Optimum Documentation Library – Nicoletta Bleiel

Das Hauptaugenmerk des Workshops lag auf den verschiedenen Arten von Hilfepublikationen. Der Titel ließ mich anfangs hoffen, dass es vor allem darum gehen würde, wie man für sich rausfinden kann, welche Publikationen für einen am besten sind.
Hier hat sie eigentlich nicht viel Neues erzählt

• Interview mit dem Support, Schulungstrainern, Power Usern
• Lesen von Kundenforen
• Vor-Ort-Besuche (den Nutzer in der Situation beobachten in der er das Produkt benutzt)

Andererseits hätte es mich fast schon gewundert, wenn sie mir hätte viel mehr erzählen können. Das Problem ist ja nicht gerade neu 🙂

Hilfe vor 2.0

Damit war dieser Teil auch schon vorbei und der Hauptteil beinhaltete einen Rundumschlag von den althergebrachten Hilfeformaten bis hin zu allerlei Web 2.0.-Technologie abgeliefert. Und das war auch ziemlich cool.
Die Historie der Hilfeformate war echt interessant. Dazu hat sie eine kleine Matrix ausgegeben in der sie alle Publikationsformen des Vortrags mit Details, Vor- und Nachteilen gelistet hat.

Angefangen hat es bei QuickHelp und WinHelp, die weit vor meiner TechRed-Zeit waren. Und weiter ging es mit dem „Assistance Escalation Path“, der von Microsoft entwickelt wurde:

• Well designed UI
• Assistance directly in UI
• Help pane and help center
• user community
• Support

Tja, ich hätte ja von Microsoft nicht gedacht, dass da auch so schlaue Sachen bei rauskommen. Aber in der Tat ist das Konzept für die „Longhorn help“ ziemlich cool und auch genau mein Plan für die Zukunft 🙂

Das war die „traditionelle“ Welt, also das Leben vor 2.0.

Wie aktiv ist das „read/write“ web?

Zum Leben in 2.0 hat sie einen super Überblick über alles gegeben, was irgendwie zu diesem ominösen Phänomen gehört. Beim Thema „read/write web“, also das Internet in dem man sich selbst aktiv beteiligen kann anstatt zu lesen, ging es auch um die Participation inequality. Ich kannte dieses Begriff bisher nur von Jacob Nielsen, der die 1-9-90-Regel aufgestellt hat. Was so viel heißt, wie 1% der User beteiligt sich sehr stark, 9% ab und an und 90% sind lediglich Leser oder Zuschauer. Das heißt, es kann zwar jeder mitmachen, aber die wenigsten tun es wirklich.
Umso erstaunter war ich mit diesem Vorwissen als Nicky eine aktuelle Analyse von Forrester zeigte, in der diese Zahlen deutlicher positiver ausfielen, d.h. Dass es in der Regel sogar 18% an aktiven Usern gibt. Forrester bietet auf der Webseite außerdem ein kleines Profililing-Tool, in dem nachprüfen kann, wie sich die Beteiligung auf eine bestimmte Altersklasse in einem bestimmten Land aufteilt. So dass man quasi für seine Zielgruppe nachprüfen kann, ob es sich überhaupt lohnt, seinen Nutzern aktives Web zu bieten.

Wikis, blogs and social networking

Weiter ging es natürlich mit Wikis, wobei mich wieder ein klein wenig das DITA-Wiki-Fieber packte 🙂 Dabei erwähnte sie, wie sie einmal ein Wiki einführen wollte. Um die Leute wohlgesonnen zu stimmen, gab sie eine Hawaii-Party mit Cocktails und Barbecue (wikwiki heißt ja „schnell, schnell“ auf hawaiianisch). Und dann kam sie zufällig mit dem Wiki um die Ecke und streute die Saat auf der Party. Fand ich großartig 😀

Natürlich kamen auch zur Sprache: Podcasts, Blogs, Social Networks, RSS. Das Schöne war hier, dass sie hier immer wieder Anstöße gegeben hat, dass man einfach mal für sich abprüfen sollte, ob man irgendetwas davon benutzen kann, um Produktinformation zu verbreiten. Viele dieser Medien würden zwar wohl eher für Marketing passen, aber man solle den TechRed-Gedanken hier auch mal weiterdenken. Beispiele waren hier: Blogs zu einem bestimmten Microsoft-Produkt, in denen Mitglieder aus diesem Produktteam über neue Feature oder Verwendungsmöglichkeiten bloggen. Produkttrainings, die über Podcasts oder Vodcasts verbreitet werden. Oder auch Facebook-Gruppen zu bestimmten Produkten. Sehr witzig fand ich auch dass HP beispielsweise twittert oder es eine myspace-Seite für Kraft Scheibletten gibt (die heißen in den USA natürlich anders, aber das hab ich schon wieder vergessen…).

Fazit

Es hat mich zumindest dazu gebracht mal wieder ein Stück weiter über den Tellerrand zu schauen als ich es schon tue 😉

Der Rundumschlag war auf jeden Fall sehr gut für Leute geeignet, die in diesem ganzen Web 2.0-Wahnsinn noch gar nicht so drin waren oder gar nicht über eine Verknüpfung mit TechRed nachgedacht haben. Selbst für mich gab es hier einige interessante Neuheiten zu erfahren. Supergut war, dass Nicky den Folientext auf Handouts gepackt hat und außerdem noch irreviel Links zu allen Themen mitgegeben hat. Der Vortrag wurde wohl schon mal in auf der DocTrain gehalten (allerdings hat sich bis zur tekom noch einiges daran geändert) und so sah das aus:

Ich bin Wiki-Fan.

Ich bin DITA-Fan.

Bei beidem geht es um Topics. Hmm…

Ist doch klar, dass DITA2Wiki mir den Mund wässrig macht. Es ist zwar nur eine Beta, aber DAS würde ich wirklich sehr gerne ausprobieren. Seufz…

Ich bin schon gespannt wie ein Flitzebogen. Erstens war ich noch nie bei der Tagung (für meinen ersten Job war das nicht so relevant und als Student hatte ich für solche Sperenzchen kein Geld und keine Zeit).

Zweitens trifft das Programm derart meinen Nerv, dass ich vermutlich Probleme haben werde mich zu entscheiden, wo ich hingehe. Hier ein kleiner Auszug aus meiner Liste 🙂

• User assistance: What’s ahead?
• Die Kunst der Modularisierung – Informationsbausteine zweckmäßig definieren
• Rollen, Workflow, Dynamik: Informationsmodellierung zur User assistance in Zeiten von SOA
• Wie gut spricht Ihr TM-System DITA, XLIFF und Co.
• Adobe AIR: Die neue Betriebssystemübergreifende Basis für Onlinehilfen

DITA und Informationsarchitektur sind für mich zweifellos Pflichtthemen, aber zur Zeit tut sich auch sehr viel im Hinblick auf User assistance und neuen Tools / Darbietungsformen für Hilfe. Hier sehe ich noch sehr viel Potential, da die Welt sich biel zu lange nur auf der Schiene der PDF-Handbüch und CHM-Hilfen bewegt hat. Ich bin selber Hilfe-User und weiß, dass es mich selbst mal nach besseren Lösungen dürstet.

Nun denn, wenn ich nicht so ein lauter Tastatur-Hacker wäre und dies hier schon ein Blog für die Masse wäre 😉 , würde ich total cool live bloggen. Aber so werde ich mich wahrscheinlich einfach abends im Hotelzimmer an ein Resümee machen.

Für die technische Doku bin ich nun ein absoluter Anhänger der Topicorientierung. Der Anspruch ist hier nicht für eine bestimmte Ausgabe zu schreiben, sondern die Bedienung eines Produkt zu beschreiben und ggf. die Hintergrundinformationen, die man dazu benötigt. Aus diesen Beschreibungen kann man sich später die verschiedensten Dokumentypen zusammenbauen, vom Schnell-Start-Guide bis zum Kompletthandbuch.

Nun starten die meisten Leute eine traditionelle Doku (also ein klassiches Word – oder Framemaker-Handbuch) damit ein Inhaltsverzeichnis zu erstellen. Im Endeffekt ist das auch nicht der schlechteste Ansatz, nur funktioniert er mit Topicorientierung zusammen nicht so gut, wie ich feststellen konnte.

Denn so bald man anfängt sich auf die Endausgabe, also z.B. das Benutzerhandbuch, zu konzentrieren, fängt man an, die Topics so zu schreiben, dass sie in die Struktur reinpassen, die man sich vorher zusammengestrickt hat. Aber so passiert es eben auch leicht, dass sie später in andere Strukturen, für die man das Topic braucht, eben nicht reinpassen. Man fällt selbst so schnell in die lineare Struktur hinein, dass man die Topicorientierung sehr leicht aus den Augen verliert.

Deshalb heißt es für mich ganz klar: zuerst kommt das Topic und später irgendwann die Struktur in der es zufällig auch existiert.

Party-Small-talk kommt immer irgendwie zu der Frage: „Und was machst du so?“. Schon als Germanistikstudentin war das für mich der wahnsinnig nervige Punkt einer Konverstaion, weil auf meine Antwort, dass ich eben Germanistik studiere, das Gespräch in Richtung Arbeitslosgkeit und Sinnhaftigkeit eines solchen Studiengangs ging. Super!

Aber es sollte noch schlimmer kommen: nämlich als ich mir den Studiengang und den Beruf als technische Redakteurin aussuchte. So ähnlich wie hier 🙂

( via savagechicken.com)

Nach dem Satz „Ich arbeite als technische Redakteurin“ werde ich meistens gefragt, ob ich bei der lokalen Tagenszeitung arbeite – oder mich blickt ein komplett ratloses Gegenüber an, wie im Comic. Fängt man dann an über Handbücher zu erzählen, wird entweder schnell das Thema gewechselt („Das ist schon ziemlich langweilig, oder?!“) oder aber man darf sich Anekdoten darüber anhören wie schlecht doch alle Bedienungsanleitungen dieser Welt sind.

Und wie ist es nun wirklich?

Ich würde sagen, es ist wie im jeden anderen Job auch: good times and bad times.
Mich persönlich reizt vor allem der Prozess der Wissensvermittlung. Idealerweise sucht man sich als Redakteur eine Branche aus, die einen wirklich interessiert: bei mir ist das Software und Internet. Mir macht es Spaß Software zu entdecken und mir alles darüber anzueignen bis ich an dem Punkt bin, an dem ich anfangen kann dieses Wissen weiterzugeben.

Und das ist der Punkt: Eine Handlungsanweisung zu schreiben („Klicken Sie…“) ist hier echt mal keine Schwierigkeit. Das kann jeder! Was nicht jeder kann, ist

• filtern, was dokumentiert werden muss und was nicht
• die Info so zu strukturieren, dass sie den Nutzer optimal begleitet

Wie spreche ich welchen Nutzer an und in welcher Struktur verpacke ich das?

Das ist für mich das Schwierige und Herausfordernde an meiner Arbeit. Und damit ist es auch das Spannendste, denn jedes Produkt ist anders. Der schwierige Teil ist immer das Konzept hintendran zu finden, denn erst dann kann man anfangen zu schreiben.

Wie war das mit der Germanistik?

Ich habe für mich gelernt, dass es wichtig ist beim Studium den eigenen Neigungen unbedingt nachzugehen. Sehr oft habe ich mit der Wahl gehadert, weil man danach natürlich nicht mit einem fertigen Beruf dasteht, sondern einfach nur mit einem Bachelor of Arts in meinem Fall. Aber mich hat das Germanistikstudium gelehrt wie ich mir möglichst viel Information zu einem Thema aneigne, dieses Wissen dann auf ein bestimmtes Thema hin fokussiere, es strukturiere und in Text presse. Ich habe festgestellt, dass es egal, ob es sich hier um Auto- und Hetereostereotypen im Rolandslied des Pfaffen Konrad handelt oder um Feature X der Software Y: es ist ein Grundpfeiler meiner heutigen Arbeit, den ich nicht missen möchte!