Die Redakteuse

Schlagwort: tekom

  • tekom15: Faster than agile

    So, nach der ganzen DITA-Aufregung kommen wir nun zu etwas völlig anderem. Naja, ein bisschen DITA ist auch dabei, aber hey, ihr wisst, wo ihr hier lest 😉

    Ich habe mir Jang Graats Vortrag „Faster than agile“ angeschaut. Gerade bin ich wieder mittendrin in einem agilen Projekt und da klang das doch vielversprechend.

    Vorab muss ich sagen, dass ich das Agile-Bashing hier etwas arg konstruiert fand. Jang kritisierte, dass wir als Redakteure in agilen SW-Projekten schnell dabei sind die ganzen Arbeitsweisen der Entwickler zu übernehmen: Versionsverwaltung, Nightly builds… Worum es ihm aber eigentlich geht ist, dass wir Redakteure uns von diesem Publikationsparadigma verabschieden sollen, d.h. zu einem definierten Zeitpunkt generieren wir alle Publikationen und liefern sie dann aus.

    Live-Content statt Publikation

    Die Probleme fangen da an: wenn man für mehrere Produkte, Variante, Endgeräte, Zielgruppen und Sprachen generiert, kommt schnell eine beachtliche Menge zusammen, die bei Updates publiziert werden muss. Das nimmt zum Einen viel Zeit in Anspruch und zum Anderen benötigt man viel Speicherplatz für die Vielzahl von Publikationen.

    Seine Lösung für die Zukunft ist das Live-Publishing von Content on demand, d.h. in dem Moment in dem ein Nutzer, die Seite aufruft, wird sie per XSLT generiert und angezeigt. Der XML-Content (hier war es DITA, was hier aber sekundär ist) liegt hierbei direkt auf dem Server. So bekommt der Nutzer absolut frischen Content und wir Redakteure müssen nicht mehr dem Umweg über Publizieren und dann Builds machen, sondern können Content-Änderungen direkt in die Welt raushauen. Zudem ist der Content direkt auf den Nutzer zugeschnitten, auf sein Endgerät, seine Sprache etc.

    Dazu stellte Jang auch einen Workflow vor, bei dem er über das HTML5-Attribut editable eine Möglichkeit gefunden hat, auch die generierte Seite zu bearbeiten und die Änderungen wieder in den DITA-Quelldatei zurück zu überführen. Was gerade bei kleinen Änderungen oder auch Reviews eine ziemlich praktische Angelegenheit ist, denn diese könnte man so sehr einfach auch SMEs machen lassen, ohne dass diese sich mit XML-Dateien herumschlagen müssen.

    Und wie geht das?

    Leider hab ich in dem Vortrag wirklich konkrete Ausführungen dazu vermisst, wie das ganze gelöst ist, wie der komplette Prozess im Detail aussieht (auch technisch gesehen), wie ich die DITA-Files organisiere, mit was publiziert wird. So war der Vortrag erst einmal nur ein kleiner Anstoß zum Überdenken schon ziemlich etablierter Arbeitsweisen und dass es auch anders geht.

    Ich hoffe, dass es bald konkreter wird – zumindest hat Jang angedeutet, dass er da eine richtige Lösung bauen (anbieten?) will. Ich werde mir diese Möglichkeit in den nächsten Wochen jedenfalls auch mal genauer anschauen.

    (Als ich übrigens einem Entwickler von diesem XSLT-On-Demand-Web-Publishing erzählte, schlug der allerdings die Hände über dem Kopf zusammen: Das gäbe doch nur Performance-Probleme und potentielle Sicherheitslücken. )

  • DITA & Deutschland

    Leider war ich in diesem Jahr nur am 2. Tag auf der tekom-Tagung und habe so die beiden Sessions verpasst, die sich eher kritisch mit DITA auseinander setzten oder wie Sarah O’Keefe sie zusammenfasste: DITA is bad. Die Tweets dazu waren sehr unterhaltsam und ich hätte die Diskussionen gerne live erlebt.

    Es hat sich hier wieder der Eindruck manifestiert, dass Deutschland ziemlich DITA-feindlich ist.


    Und das alles hat mich einmal zu einer kleinen Bestandsaufnahme inspiriert, die mir schon lange im Kopf herumschwirrt. (Und ja, ich hab schon ein bisschen überlegt, ob ich nach der ganzen Aufregung auf Twitter jetzt wirklich noch was dazu schreibe. Aber hey, wenn ich schon in den Blog-Flow komme, sollte ich besser nicht aufhören).

    Die Verbreitung in Deutschland

    Ich beobachte den deutschen Stellenmarkt seit gut 10 Jahren und seit ein paar Jahren auch den Projektmarkt, und tatsächlich kann ich DITA-Projekte oder Stellenausschreibungen, die DITA-Kenntnisse forderten, an einer Hand abzählen. Kleiner Hinweis: Man ist also zeitweise sehr gefragt, wenn man sich hierauf spezialisieren will, oder über lange Strecken gar nicht 😉

    Meine Erfahrung deckt sich ganz gut mit dieser Grafik von Keith Schengili-Roberts.

    Wie kommt das? Warum ist DITA in den USA so durchgestartet und hier in Deutschland (noch) nicht? Ich persönlich glaube nicht, dass es daran liegt, dass DITA in irgendeiner Weise schlecht wäre oder es hier total viel bessere Lösungen gäbe. Es gibt nie nur eine Lösung.

    DITA – Alter Wein in neuen Schläuchen?

    Soweit ich das beurteilen können arbeiten hier viele Unternehmen schon länger XML-basiert als es DITA gibt und dementsprechend haben sie schon eigene Standards und Prozesse. CMS-Hersteller haben entsprechende Lösungen entwickelt. Was also den Bereich Standardisierung/Modularisierung angeht, ist DITA hier erst einmal nichts Neues. Ist es also die Ablehnung nach dem Motto: „Alter Hut, machen wir schon viel länger.“ ? Das alleine kann es nicht sein, denn es gibt immer noch genug Firmen, die völlig unstandardisiert arbeiten und für die DITA genau das Richtige wäre.

    Alles eine Frage der Kultur?

    Sind die Deutschen vielleicht zu zögerlich? Ich kann mir gut vorstellen, dass das ein Faktor ist.  Gerade in den Branchen Maschinenbau/Elektrotechnik, die um xml-basiertes Arbeiten kaum drumherum kommen, ist man doch generell etwas vorsichtiger und konservativer. Man traut einem relativ neuen Standard vielleicht nicht so sehr (was sind in dem Bereich ganz ernsthaft schon 10 Jahre?) und verlässt sich lieber auf etablierte CMSe , weil das die vermeintlich sichere Schiene ist (Nur um es gesagt zu haben: ich hab nix gegen CMSe!).

    Und was ist dann mit der IT-Branche, die in Deutschland doch auch wahnsinnig wächst? An dieser Stelle bin ich etwas ratlos. Es gibt einige große Unternehmen, die DITA einsetzen, aber insgesamt ist auch hier DITA kein großes Thema.  Ist es so, dass die Doku hier noch weiter unten priorisiert wird, weil man nicht so starken rechtlichen Druck hat und deswegen „irgendwie“ arbeitet? Braucht man XML in der SW-Doku generell nicht so sehr? Was meint ihr?

    DITA, der Hammer und der Nagel, oder so

    Das muss ich noch kurz erwähnen: Obwohl ich ja schon ziemlich überzeugt bin von DITA, setze ich es auch nur da ein, wo es Sinn macht. Als Beraterin im Bereich TD ist es die Aufgabe herauszufinden, was der spezielle Kunde wirklich braucht. Und das eben nicht nach dem Motto: „Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.“ Berater und Firmen in allen Branchen arbeiten vielleicht oft so, aber das ist ein ganz anderes Thema. Auf jeden Fall fand ich das Zitat aus der gestrigen Session von Uwe Reißenweber (bitte beachten: von der DERCOM, dem Verband dt. CMS-Hersteller) wirklich großartig in seiner Ironie:

    Hey, es gibt immer mehr als eine Lösung  und in diesem Sinne:

  • Mit DITA um die Welt – tekom-Jahrestagung 2012

    Die tekom-Jahrestagung 2012 ist überstanden und es war mal wieder sehr interessant und schön dabei zu sein.

    Vorab gibt es hier erst einmal die Folien zu meinem Vortrag „Mit DITA um die Welt“. Der Rückblick folgt in den nächsten Tagen. Ich gehöre nicht zu den Schnell-Bloggern wie Kai oder Sarah, die ihre Eindrücke wirklich rasend schnell online hatten.

    Titelbild Vortrag Mit DITA um die Welt

    Und hier noch der Beweis, dass ich ihn tatsächlich gehalten habe 😉
    (Special thanks to Axel)

    Vortragsbild Marijana Prusina "Mit DITA um die Welt"

  • Redakteuse live – tekom Jahrestagung 2012

    Die tekom-Jahrestagung in Wiesbaden rückt näher und selbstverständlich bin ich wieder dabei. Auch in diesem Jahr gibt es einen großen Track zum Thema „Content Strategy“, der wieder mit einer Vielzahl an interessanten Vorträgen lockt. Aber auch ansonsten klingt das Programm sehr vielversprechend und daher wird es wieder wie immer schwer sich zu entscheiden, in welchen Vortrag man letztlich geht.

    Ganz besonders würde ich mich freuen, wenn der eine oder andere sich für einen meiner Vorträge entscheidet 🙂

    Mit DITA um die Welt
    Hier erfahrt ihr alles, was ihr wissen müsst, um eure DITA-basierte Dokumentation fit für die Welt zu machen.

    The strategic technical communicator
    In diesem englischsprachigen Panel sprechen Nicky Bleiel, Sarah O’Keefe, Tony Self und ich über berufliche Strategien für Technische Redakteure. Dabei werde ich vor allem über Strategien für angehende Freiberufler sprechen – ein Thema, das bei mir ja noch relativ frisch ist.

    PS: Am Dienstagabend gibt es im Foyer eine kleine Welcome Party von Atlassian und k15t Software, die nun auch als Location für ein TR/techcomm-Tweet-up dient. Man sieht sich spätestens dort 🙂

  • Nachtigall, ick hör dir twittern!

    „Twitter? Darüber kann man Leute kennen lernen?“ Das war die Reaktion eines mir nahestehenden Nicht-Twitterers als ich ihm erzählte, dass ich die eben zufällig getroffene Dame über Twitter kennen gelernt hatte. Tja, und wie ich dann so erzählte, wie toll das mit dem Twittern sein kann, ja, da dachte ich mir, dass könnte ich euch doch auch mal erzählen. Denn ein bisschen mehr TRler könnten da draußen schon twittern 🙂 Daten und Fakten zum Thema „TRler und Twitter“ findet  übrigens in der Zusammenfassung von Utes Thesis. (Während ich diesen Artikel hier schrieb, kam dann auch grad ihr neues, gut zu meinem passendes Blog-Posting Was Social Media für mich nicht ist raus).

    Twittern ist Kommunizieren

    Um die TR-Twitterei zu fördern, gab es auf der tekom-Frühjahrstagung die folgende Aktion: Wer die meisten werbefreien Tweets twitterte, sollte eine Freikarte zur Jahrestagung 2012 in Wiesbaden gewinnen. Ich fand die Aktion ziemlich gut. Leider hat sie nicht so ganz den gewünschten Effekt gehabt, denn die Tweets mit dem Hashtag #tekomf12 waren am Ende tatsächlich zur Mehrzahl entweder von mir oder eben von Firmen (oder einer gewissen Tagungshelferin – kleiner Wink an dieser Stelle). Ich freu mich natürlich, dass ich nun eben gewonnen habe, aber so fast alleine zu twittern fühlt sich eigentlich gar nicht so toll an. Warum? Weil Twittern nicht nur Publizieren, sondern auch Kommunizieren bedeutet (ein Umstand, den übrigens sehr viele Firmen völlig vernachlässigen). Konferenz-Twittern macht deutlich mehr Spaß, wenn man auch die Sichtweisen anderer lesen kann. Gerne lese ich auch was von Vorträgen, die ich nicht besuchen kann. Eine Konferenz ist zwar an und für sich schon ein soziales Ereignis, aber Twitter bringt noch eine weitere soziale Ebene hinzu. So weiß ich schon vor der Konferenz meist, welche Leute noch so hingehen und wen ich treffen kann – man hat so ein bisschen ein Klassentreffen-Gefühl.

    Was bringt Twittern?

    Das liegt ganz bei einem selbst. Ich selbst habe Twitter erst einmal nur aus Neugier ausprobiert und mal ab und zu eine Meldung abgesetzt, z.B. wenn ich einen neuen Blogpost geschrieben hatte. Die Leute, denen ich folge, habe ich über verschiedene Blogs und wieder andere Twitterer gefunden. Darunter sind andere TR-Leute aus der ganzen Welt, die mich mit Links und News über die neuesten Trends auf dem Laufenden halten. Aber ich folge auch Leuten, deren Tweets ich einfach gerne lese, und die gar nichts mit der TR-Welt zu tun haben. Ich selbst habe in meinen Tweets schon einen starken Fokus auf meinem Beruf, aber ab und zu twittere ich auch was Privates. Manche ziehen da eine harte Grenze und haben einen beruflichen und einen privaten Account. Mir ist das zu anstrengend und daher twittere ich nun eben so wie ich eben twittere.

    Richtig interessant wurde die Twitterei für mich als ich anfing mit anderen Twitterern in Kontakt zu treten, d.h. auf ihre Tweets zu antworten oder sie zu retweeten. Und so kam es dann, dass ich mit der Zeit den einen oder anderen Twitterer im sog. „Real life“ traf. Die meisten auf der tekom-Jahrestagung und manch eine auch einfach im Büro einen Stock über mir 😉 Und das waren eigentlich immer tolle Begegnungen – auch wenn man manchmal Probleme hat, die Leute bei ihrem echten Namen zu nennen, wenn man sie die meiste Zeit unter einem Pseudonym kennt 😉

    Fazit

    Mir hat das Twittern gerade in fachlicher Sicht sehr viel gebracht und mir auch zu einigen netten Bekanntschaften verholfen – das will ich definitiv nicht missen. Daher will ich noch mehr TRler ermutigen sich Twitter mal anzuschauen (ein paar allgemeine Twitter-Erklärungen  finden sich in diesem Artikel von Markus Nickl) und loszutweeten.  Es ist angezwitschert! 🙂

    EDIT: Martin hat einen Tagungs-Twitter-Guide geschrieben. Sehr empfehlenswert!

  • tekom Frühjahrstagung 2012 – Experience Design

    So, bevor ich in mein wohlverdientes Wochenende bei 26°C entschwinde, hier noch schnell die ersten Eindrücke, so lange sie noch frisch sind 😉

    Ich war bisher noch auf keiner Frühjahrstagung, aber da sie diesmal in meiner schönen Heimatstadt Karlsruhe stattfand, gab es keine Ausrede. Erster Eindruck: sehr familiär im Vergleich zur riesigen Jahrestagung. Die Frühjahrstagung ist einige Nummern kleiner. Den bleibendsten Eindruck des ersten Tages hat die Keynote gemacht:

    Marc Hassenzahl „Freude durch Technik? Vom Vermeiden von Problemen zum freudvollen Erlebnis“ 

    Die Tagung begann mit einem „Exoten“ unter all den  Redakteuren, wie er sich selbst nannte: Marc Hassenzahl, Psychologe und Professor  im Industrial Design an der Folkwang Universität der Künste in Essen.

    Die Keynote hat mir sehr gut gefallen: es dreht sich rund um das Gestalten von Erlebnissen. Die zentrale Erkenntnis ist, dass in der heutigen Gesellschaft kein besitzorientiertes Denken mehr herrscht („Ich bin so toll, ich fahre nen Mercedes.“), sondern dass Erlebnisse in den Vordergrund rücken („Ich habe den Yeti am Mount Everest gesehen.“). Wir wollen also ein Produkt, das Spaß macht, uns positive Erlebnisse verschafft. Die wahnwitzigsten und ausgefeiltesten Funktionen helfen nicht, wenn das Ding keinen Spaß macht! Als Beispiel für ein gelungenes erlebnisorientiertes Produkt nannte Hassenzahl u.a. das Wake-Up Light von Philipps, das einen sanft mit immer heller werdendem Licht weckt. Es sei kein besonders hübsch designtes Produkt und auch die Funktion wäre im Endeffekt nur eine Zeitschaltuhr mit Glühbirne – aber es verschafft dem Benutzer ein gutes Erlebnis, wenn er jeden Morgen sanft davon geweckt wird. Und das kann ich auch aus ganz eigener Erfahrung bestätigen 🙂

    Im Fokus der Produktentwicklung muss also eigentlich erst die Erlebnisentwicklung stehen: man muss sich überlegen, was für ein Erlebnis man schaffen will und dann das zugehörige Produkt bzw. dessen Funktionen designen. Plakativ gesagt: Form follows fun.

    Ich fand diesen nicht direkt redaktionsbezogenen Vortrag sehr erfrischend – und  exotisch war er für die Welt der technischen Redakteure ganz uns gar nicht. Das hätte ich Marc Hassenzahl noch gerne gesagt 🙂  Schließlich sind wir ja federführend an der Erstellung von Produkten beteiligt, und zwar: Informationsprodukten. Diese gehören zum eigentlichen Produkt und müssen genauso Teil eines positiven Produkterlebnisses sein. Der Vortrag hat auf jeden Fall Spaß gemacht und mir einige neue Perspektiven gezeigt. Gerne mehr davon!

     


     

  • 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.

  • Redakteuse live „DITA – Grundlagen und Tipps für Einsteiger“

    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 🙂

  • tekom 2010: Documentation for Software Engineers

    In meinem ersten Job wurde ich zur Betreuung der internen Dokumentation und des Firmen-Wikis eingestellt. Die Vision damals war, dass ich mal tüchtig aufräume und danach alle Abteilungen in der Firma tolle Dokumentation haben. Nun, das wäre super gewesen 🙂 Aber ich musste feststellen, dass das so einfach nicht ist. Es kommt zum einen darauf an, um was es sich für eine Abteilung handelt ( PR? Marketing?Personal? Entwicklung? Wenn ja, welche Richtung? etc), denn die Anforderungen sind dann natürlich unterschiedlich. Dazu hätte ich mich im Detail mit jeder Abteilung und ihrer Dokumentation auseinander setzen müssen. Eine Person alleine kann das für eine große Firma nicht schaffen – und: die Abteilungen müssen am Ende trotzdem auch immer noch selbst Dokumentation schreiben. Das war für die meisten die größte Überraschung damals 😉

    In dem Vortrag „Documentation for Software Engineers“ von Ulrike Parson habe ich nun einiges erfahren, wie man das Thema interne Dokumentation angehen kann. Und es hat meine oben erwähnten Erfahrungen bestätigt.

    Zielgruppen
    Auch bei interner Dokumentation ist es wichtig sich über die Zielgruppe Gedanken zu machen. Das wird bei diesem Thema oft vergessen – es ist ja „nur“ für intern. Die Zielgruppe ist hier der Software-Entwickler und seine verschiedenenen Ausprägungen. Frei übersetzt teilte Ulrike Parson sie wie folgt auf:

    • Den Praktiker:
      • will loslegen
      • benötigt Code-Kommentare, Code-Beispiele
    • Den Gründlichen:
      • liest zuerst einmal die Grundlagen
      • benötigt Hintergrundinfo zu API/Framework, Beschreibung allgemeiner Programmieraufgaben (Error handling, Lokalisierung &Co.)
    • Bedarfsleser
      • Liest bei konkreten Fragen nach
      • Benötigt Code-Kommentare, Hintergrundinformationen und Code-Beispiele

    Anhand dieser Zielgruppenanalyse schlüsselt sie dann auf, welche Dokumenttyen geliefert werden müssen, um diesen Anforderungen gerecht zu werden. Und auch wie sie geliefert werden müssen, z.B. als PDF oder Wiki mit Feedback-Funktion, Index etc.

    Die Rolle des technischen Redakteurs
    Ich habe von Entwicklern schon so oft gehört, dass sie endlich mal dokumentieren müssten oder endlich mal „gescheit dokumentieren“ müssten. Gleichzeitig hab ich mich immer gefragt: wie könnte ich dabei helfen? Immerhin heißt es doch auch „technische Dokumentation“, was ich studiert habe 😉

    Inwieweit der technische Redakteur die Entwickler beim tatsächlichen Dokumentieren unterstützen kann, hängt natürlich stark davon ab, wieviel Programmierwissen und -erfahrung er selbst hat. Aber es ist ununmgänglich, dass die Entwickler auch selbst dokumentieren – wer etwas selbst macht, weiß einfach am besten darüber Bescheid. Frau Parson hat sehr schön gezeigt, dass der Redakteur auch ohne selbst viel zu schreiben, doch sehr viel hier mitarbeiten kann.

    So können die Aufgaben des Redakteurs aussehen:

    • Zielgruppen- und Bedarfsanalyse
    • Dokumentationsworkflows erstellen
    • Terminologie erarbeiten, pflegen und bereitstellen
      • gerade in der Entwicklung lebt so manch uralter produktname ewig weiter
      • Missverständnisse untereinander werden vermieden
    • Neue Texte redigieren/korrigieren
    • Neue Texte evtl. schreiben
    • Strukur der Dokumentation entwickeln und überwachen
    • Dokumentvorlagen bereitstellen

    Und wenn man sich das mal genau anschaut, sieht man wieder, dass das ganz klassische Redakteursaufgaben sind. Nur ist der Fokus nicht so sehr darauf alles auch selbst zu schreiben, sondern viel mehr zu recherchieren, strukturieren, den Entwicklern eine Basis zu geben.

    Als praktisches Beispiel wurde abschließend noch ein Wiki gezeigt, das vor allem von den Entwicklern befüllt wird. Von der Redakteursseite wurde eine Grundstruktur angelegt und auch verschiedene Templates, damit die Entwickler nicht vor einer weißen Seite stehen und nicht wissen wo sie anfangen sollen. Der Redakteur überwachte nun die Entwicklung der Dokumentation und greift hier und da korrigierend ein. Zudem gibt es einen Freigabeprozess, so dass man auch wirklich nur qualitativ hochwertige Dokumentation publiziert.

    Für den einen oder anderen Software-Entwickler klingt das ganze vielleicht nach zu viel Reglement, aber ich habe schon zuviel schlechte und veraltete SW-Dokumentation gesehen und das klingt für mich nach einem plausiblen Weg aus der Misere.

    Fazit

    Ein hochinteressanter Vortrag (als PDF), der auch mal neue Wege für Redakteure aufgezeigt hat, die nicht in der klassischen Schiene liegen, aber am Ende doch perfekt auf das Skillset passen. Vielen Dank dafür! 🙂

  • tekom Jahrestagung 2010 – Rückblick

    So, es ist geschafft 🙂

    Ich habe den Beinahe-Laptopausfall und die Vor-Vortrags-Nervosität halbwegs überstanden und ich denke, mein Vortrag ist ganz gut angekommen. Aber Genaueres weiß ich erst, wenn die Feedback-Bögen eintreffen. Und da bin ich äußerst gespannt! Meine Folien werde ich demnächst hier veröffentlichen sind nun unter Downloads erhältlich.

    Nun, wie sah es mit dem Rest der Tagung aus?

    Das Zielgruppen-Problem

    Bei mir und bei vielen anderen (u.a. auch im neuentdeckten Blog von Jason A. Nichols), herrschte ein wenig Unmut darüber, dass man in vielen Fortgeschrittenen- oder Experten-Vorträgen dann doch wieder mit sehr vielen Basics konfrontiert wurde. Ich weiß schon gar nicht mehr in welchem Vortrag das war, aber als man anfing uns zu erklären, dass Standards gut sind, da kam ich mir etwas veräppelt vor (das gehört für mich zur Grundausstattung des Redakteurs!). Vielen fiel es sichtlich schwer, den Vortrag zielgruppengerecht aufzubereiten. Vielleicht fehlt aber auch ein genaue Beschreibung der Klassifikationen „Einsteiger – Fortgeschrittene -Experten“? Ich habe mir rückblickend nämlich überlegt, dass ich meinen Vortrag wohl besser als „Für Experten“ eingestuft hätte, aber so richtig sicher bin ich mir nicht. Daher mein Vorschlag an die tekom, da vielleicht mal den Versuch einer detaillierten Klassifikation zu starten. Als Zuhörer ist es wirklich sehr ärgerlich, wenn man sich in einem Vortrag wiederfindet, der einfach gar nicht passt. Ich kann mir gut vorstellen, dass sich viele die Investition in die nächste Tagung nochmal gut überlegen.

    Die Idee von Urs Klenke nicht mehr so viele verschiedene Vorträge anzubieten, aber dafür ausgewähltere und diese auch zu wiederholen, finde ich prinzipiell auch ganz gut, wobei es organistorisch bestimmt ziemlich kompliziert wäre…

    iPad, iPhone, ePub

    Das war definitiv der Hype in diesem Jahr. Vieles war hier noch recht theoretisch – ich hoffe im nächsten Jahr auf erste richtige echte Beispiele!

    User assistance

    Der Hype dauert immer noch an, wobei ich da weiterhin hoffe, dass es auch hier noch mehr echte Beispiele geben wird. Die Theorie ist so langsam bekannt – jetzt will ich sehen was andere machen 🙂

    … und der Rest

    Es war einfach mal wieder nett so komplett unter „seinesgleichen“ zu sein und sich über das Fach austauschen zu können – und auch so einige Leute mal „in echt“ zu treffen 😉 Zielgruppen hin oder her – es waren immer noch Vorträge dabei, die einem hier und da wieder einen neuen Denkanstoß gegeben haben. Ich werde mir zum Beispiel in nächster Zeit einige Gedanken dazu machen, wie ich eventuell eine Verknüpfung meiner Hilfedateien mit den Textdateien unserer Applikationen hinbekommen kann, so wie in dem Vortrag „User Interface-Texte in der Dokumentation„.

    Und last but not least: endlich ist mir bei einem von Tony Selfs Vorträgen eine Frage eingefallen! Dafür wird man nämlich mit einem echten Aussie-Koala belohnt 😉

    Tony-Self-Koala

    EDIT: einen interessanten Rückblick bietet auch Sarah.