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 – Dies und das

CMS-Coaching von Nebil Messaoudi

Nebil teilte in diesem Kurztutorial seine bisherigen Erfahrungen mit CMS-Einführungen mit uns. Wenn man selbst schon einmal ein CMS eingeführt hat, kommt einem einiges bekannt -nur zu bekannt-  vor. Manch einer konnte sich auf die Schulter klopfen und sagen: „Ja, das haben wir zum Glück von Anfang an beachtet“, aber so richtig rund scheint es am Ende wohl nirgends zu laufen, wenn es um CMSe geht:

(Dieser Tweet wurde dann auch von einigen Entwicklern aus meiner Timeline retweetet 😉 )

Was laut Nebil häufig vergessen wird, ist die konzeptionelle Vorarbeit, also erst einmal die Umstellung auf standardisierte Dokumentationserstellung mit Leitfäden, Standardisierungskonzept, Terminologie etc. Letzten Endes ist ein CMS nur eine Software, das Prozesse unterstützt – die Prozesse muss man sich aber immer noch selbst ausdenken. Gern verdrängt wird von TR-Abteilungschefs auch die Tatsache, dass es mit dem CMS-Kauf nicht getan ist: jetzt fängt nämlich der Spaß mit der Datenmigration oder -neuerfassung und kontinuierlicher Weiterentwicklung an. Und hier sollte von Anfang an schon genug Budget miteingeplant werden. Gerade wenn man fachfremde Doku-Chefs hat, müssen die Redakteure hier sehr viel Überzeugungsarbeit reinstecken. Denn da hört man schon mal gerne den Spruch: „Aber ihr habt doch da jetzt so ein tolles Redaktionssystem. Das kann doch alles“ – und dem muss man von Anfang an entgegenwirken. Denn leider kann das System nie direkt alles, was man braucht.

Ein weiteres Thema war die Frage: Wie erleichtert man Redakteuren, die bisher vor allem mit DTP gearbeitet haben den Umstieg auf XML? Gerade bei diesem Thema hat sich eine längere Diskussion entsponnen. Hier einfach mal eine Sammlung der Publikumsstimmen:

  • „Als Redakteur muss man ja nicht unbedingt programmieren können, deswegen sollte man XML als Auszeichnungssprache verkaufen und das Wort ‚Programmierung‘ am besten gar nicht erwähnen. Nur gegenüber der Geschäftsleitung sollte man XML als möglichst kompliziert darstellen – das heißt Budget!“
  • Quereinsteiger-Redakteure müssen richtig mit eingebunden werden. Es hilft nichts, wenn nur der eingekaufte Freelancer das CMS bedienen kann oder nur der Kollege, der TR studiert hat.

Weitere Empfehlungen waren:

  • das CMS mit echten Daten zu befüllen, auch wenn es um Tests geht, weil man so das genaueste Bild bekommt, wenn man testet
  • externe CMS-Coaches zu beauftragen, um sicherzustellen, dass man auf dem richtigen Weg ist.

JavaScript-Frameworks von Edgar Hellfritsch

Ich habe den Mobil-Hype bisher so ein bisschen aus der Ferne verfolgt. Bisher hatte sich einfach keine Gelegenheit ergeben in diesem Bereich zu arbeiten und jetzt wollte ich es mal genau wissen.

Edgars Vortrag hat einen sehr guten Überblick darüber verschafft, wie das aktuell so läuft bei der Entwicklung für mobile Endgeräte und im Endeffekt gibt es drei Wege:

  • Native Entwicklung: Man programmiert eine richtige App, die man sich aus dem jeweiligen Store herunterladen muss. Leider ist das im Fall von Apple richtig kompliziert (Anmeldung des Entwickler-Accounts, Anmeldung der App) und dann muss man auch noch eine neue Programmiersprache lernen (Objective C). Hinzu kommt, dass für jede Plattform (iOS, Android) eine eigene App entwickeln muss, was auf die Dauer ziemlich suboptimal ist.
  • Web-Entwicklung: Man programmiert quasi eine Webseite, die ganz normal auf einem Webserver abgelegt wird und dann über den Browser der mobilen Endgeräte abgerufen wird. Das hat den Vorteil, dass man auf jeden Fall plattformunabhängig arbeitet und eben nicht redundant. Man kann alles selbst per CSS gestalten, hat aber keinen Zugriff auf Gerätefunktionen, wie z.B. die Kamera.
  • JavaScript-Frameworks als Mittelding: Ein Framework ist eine Art Gerüst, oder auch Bibliothek, die verschiedene häufig benötigte Funktionen beinhaltet, die man direkt benutzen kann, ohne sie erst einmal mühsam zusammenprogrammieren zu müssen.  JavaScript-Frameworks für Mobiles wie jQuery Mobile oder Sencha Touch bringen also z.B. einen Standard für GUI-Elemente mit, so dass man sich nicht selbst dauernd mit dem CSS-Styling befassen muss. Je nachdem kann man auch auf die Geräteschnittstellen zugreifen.

Ich hab jetzt auf jeden Fall Lust bekommen mehr in dieser Welt herumzuspielen!

 

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!

 


 

Communities für alle!

In meinem letzten Post  habe ich es schon angeschnitten: das Thema „Lokalisierung von Communities“.  (Ich konzentriere mich hierbei weiterhin vor allem auf Hilfe-Communities, d.h. Plattformen, die Hilfetext enthalten, die auch durch die User bearbeitet werden können.(

Es ist ein ziemlich ungeliebtes Thema, fürchte ich. Ich kann mich noch daran erinnern, wie beim Content-Strategy-Tag der tekom-Tagung 2011 eine Publikumsfrage dazu gestellt und recht schnell übergangen wurde.

Wie sieht es bei schon existierenden Communities aus?

In den Open-Source-Communities ist Lokalisierung der Hilfe-Communities oft kein Thema: Es gibt in der Regel eine Sprache und das ist Englisch. Das ist schlichtweg am einfachsten, damit Leute aus aller Herren Länder sich beteiligen können. Ein Beispiel ist auch hier die ubuntu-Community.

Teilweise gibt es auch den Ansatz, dass es pro Sprache eine eigene Community gibt. Da werden oft die wichtigsten Artikel übersetzt oder in der entsprechenden Sprache neu geschrieben, wie z.B. Mozilla. Oder es sind ganz eigenständige Communities pro Sprache wie bei Wikipedia.

Alles eine Frage der Organisation

Letztlich sind es vor allem konzeptionelle Fragen, vor denen man hier steht:

  • Lokalisiert man überhaupt?
  • Wer lokalisiert: die Community oder die Firma?
  • Übernimmt man das alteingesessene Prinzip, dass es eine Quellsprache gibt und dann entsprechend in die Zielsprachen übersetzt wird?
    So kann man zwar gewährleisten, dass eine Redaktion den Überblick über alles hat, aber man kann nicht davon profitieren, wenn in einer Zielsprachen-Community ein guter Artikel erstellt wird.
  • Lässt man jede Länder-Community ihr eigenes Ding machen?
    So muss jede Länder-Community das Rad neu erfinden und das kostet natürlich mehr.
  • Setzt man auf eigene Länder-Communities, die aber mit einander kooperieren?
    Wenn ein spanischer Artikel hilfreich ist, sollte es möglich sein diesen in die anderen Sprachen zu übersetzen, d.h. jede Sprache sollte Quellsprache sein können. So profitiert man am besten vom Community-Effekt.

Die Frage, ob man überhaupt lokalisiert, hängt an der Frage, ob das Unternehmen international tätig ist. Wenn ja, muss auch lokalisiert werden. Immerhin sollen die Kunden ja was kaufen und das erreicht man immer noch am besten, wenn man diese in der Landessprache anspricht. 

Bei der Organisation der Länder-Communities würde ich dieseVariante wählen: Pro Sprache eine Community, wobei ein Grundstock an Content bei allen gleich ist, und dieser von der Firma selbst lokalisiert wird. So könnte die Firma sicherstellen, dass grundlegendste Artikel wirklich überall verfügbar und up-to-date sind. Außerdem können Artikel aus jeder Sprache auch in die anderen Sprachen übersetzt werden, wenn sie als hilfreich erachtet werden. So profitiert die Firma auch vom Community-Effekt. Von einer Vorstellung kann man sich sicherlich verabschieden: Die Communities synchron zu halten. Dafür passiert in diesem Umfeld zu schnell zu viel.

Diese Variante bedeutet aber auch: Man wird für die Betreuung auch für jeder Sprache einen eigenen Community-Manager benötigen. Und diese gilt es alle auf dem aktuelle Stand zu halten. Hier verziehen sich dann sicherlich schon die ersten Gesichter von den Ressourcen-Verantwortlichen. 😉

Fazit

Ich denke, es ist nicht unmöglich, kommerzielle mehrsprachige Communities aufzubauen, aber es ist eine große organisatorische Herausforderung. Und ich würde zu gerne wissen, ob es solche kommerziellen Communities schon da draußen gibt – ich bin nur im Open-Source-Umfeld fündig geworden. Kennt ihr welche?

Community Management und technische Kommunikation

In den letzten Monaten ist das Thema „Die Zukunft des Technischen Redakteurs“ ziemlich präsent gewesen. Mit den trendigen Themen Crowdsourcing und Community stellt man sich als technischer Redakteur so langsam die Frage: „Verlier ich meinen Job an die Crowd in der Cloud?“.

Ein mögliches Betätigungsfeld, oder besser gesagt: ein Feld bei dem wir Redakteure uns was abschauen können, ist das Community-Management. Ich kannte den Begriff Community-Manager eigentlich nur von Spiele-Foren und habe das nicht besonders ernst genommen – in meinem Kopf waren das „nur“ Forenadministratoren (Asche auf mein Haupt, jaja). Wie ich mich jetzt mit dem Begriff „Community“ im Umkreis technischer Kommunikation auseinandergesetzt habe, ist mir der Begriff „Community Manager“ wieder eingefallen. Ich suchte, ich fand – und war erstaunt. Da ist ja richtig was los! Das ganze ist gar keine Randerscheinung irgendwelcher Nerd-Foren, sondern ein immer stärker werdender Berufszweig, in Deutschland sogar mit einem eigenen Verband, dem Bundesverband Community Managament (BVCM).

Und was ist Community-Management?

Community Management ist die Bezeichnung für alle Methoden und Tätigkeiten rund um Konzeption, Aufbau, Leitung, Betrieb, Betreuung und Optimierung von virtuellen Gemeinschaften sowie deren Entsprechung außerhalb des virtuellen Raumes. Unterschieden wird dabei zwischen operativen, den direkten Kontakt mit den Mitgliedern betreffenden, und strategischen, den übergeordneten Rahmen betreffenden, Aufgaben und Fragestellungen. (Quelle: BVCM)

Der Begriff „Community“ ist also sehr weit gefasst: darunter fällt ein Forum, wie auch der Kreis an Twitter-Followern oder Facebook-Fans. Wenn man sich Stellenanzeigen anschaut, merkt man allerdings, dass es da noch kunterbunt zugeht. Community Manager, Social Media Manager – so ein richtiger Unterschied ist da häufig noch nicht zu bemerken.

Und was hat das mit technischer Kommunikation zu tun?

Ich denke, wir Redakteure können von Community Managern einiges lernen. Der Trend Hilfe-Communities heißt einerseits, dass wir Redakteure nicht mehr alles schreiben, was an den Kunden geht. Das ist der Punkt, der uns ein wenig Zukunftsangst verschafft. Andererseits bietet er eben auch neue Möglichkeiten. Das „Entstehen“ von Community Managern zeigt, dass man eine Community eben nicht einfach so sich selbst überlassen kann. Es muss immer ein paar geben, die ein wenig lenken, hier und da Leute zur Ordnung rufen und die grobe Richtung im Auge behalten, ganz egal ob es sich um ein Spieleforum, eine Facebook-Seite oder ein Hilfeportal handelt.

Und da kommen wir Redakteure dann doch noch ins Spiel.

Von den Community-Managern können wir  lernen, wie man eine Community aufbaut, wie wir die Nutzer so miteinbeziehen, dass sie sich engagieren, wie wir mit Konflikten (oder wie man heute auch sagt: Shitstorms) umgeht etc.

Zusammen mit den Fähigkeiten eines Redakteurs könnten sich außerdem die folgenden Aufgaben ergeben: eine gewisse Grundstruktur vorgeben, einen Grundstock an Content ausäen, Redaktionsleitfäden konzipieren, Hilfe-Artikel aus der Community lektorieren, Feedback einarbeiten, Übersetzungen anstoßen und auch weiter selbst Artikel schreiben, bloß eben nicht mehr alleine 🙂

Wie kann so eine Hilfe-Community aussehen?

Ein interessantes Beispiel ist  die ubuntu-Community. ubuntu ist eine sehr populäre Linux-Distribution, die von der Firma Canonical gesponsert wird. Einer der Community Manager ist der Canonical-Mitarbeiter Jono Bacon, der auch das sehr lesenswerte Buch The Art of Community: Building, Managing, and Supporting Cooperation Over the Internet geschrieben hat.

Ich habe diese Community als Beispiel genommen, weil sie verschiedene Arten der Beteiligung ermöglicht: Entwickler können entwickeln, Grafiker mitdesignen und Schreibwütige eben auch dokumentieren.

Der Doku-Bereich gliedert sich dabei in 2 Teile: die offizielle System-Dokumentation, die mit der Distribution ausgliefert wird und bei der nur bestimmte Mitglieder mitwirken dürfen und die Community-Doku bei der jeder mitmachen kann. Es gab wohl auch schon Überlegungen, diese 2 Doku-Bereiche zu einem zu verschmelzen, aber ich vermute, über die „offizielle“ Doku wollen sie doch noch mehr Kontrolle haben, damit auch wirklich kein Mist drinsteht, und das ist im Community-Bereich dann doch etwas schwieriger zu überblicken.

Sind Hilfe-Communities die Zukunft?

In einigen Bereichen sicherlich. Was Open-Source angeht, sind sie sogar schon Realität. Im Firmenumfeld wird es in einigen Bereichen sicherlich immer mehr kommen. Für manche wird aber sicherlich die folgende Frage immer ein Showstopper sein: wer ist denn eigentlich haftbar, wenn in einem Community-Hilfe-Artikel etwas Falsches steht und daraus Schaden entsteht? Und auch die Frage der Übersetzung ist da meiner Meinung nach ziemlich schwierig. Klar, kann man das auch die Community machen lassen, aber wenn man Ende ein Produkt mit Doku ausliefern muss, kann man sich evtl. doch nicht drauf verlassen. Um eine Community zu schaffen, muss man ein Stück Kontrolle aufgeben, aber die Frage ist, ob es nicht ein gewisses Maß an Kontrolle gibt, das man als Firma einfach behalten muss, um nicht in die Bredouille zu geraten.

Ich glaube, dass der Community-Trend uns Redakteure nicht die Jobs kosten wird. Zum einen, weil manche Dokus aus rechtlichen Gründen einfach nicht in die Community gegeben werden können 😉 Zum anderen sehe ich eher einfach nur die Entstehung einer neuen Facette für Leute mit TR-Fähigkeiten – und zwar eine sehr spannende 🙂