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 🙂

Gelesen: DITA Best Practices

Vor kurzem ist das Buch DITA Best Practices: A Roadmap for Writing, Editing, and Architecting in DITA von Laura Bellamy, Michelle Carey und Jenifer Schlotfeldt erschienen. Bei dem Wort „Architecting“ im Untertitel bin ich hellhörig geworden, denn die meisten Bücher, die derzeit auf dem Markt sind beschäftigen sich entweder stark mit den Basics (Warum soll ich DITA verwenden?) oder mit der Autorensicht (Wie schreibe ich in DITA?). Das ist zwar nicht verkehrt, aber viele weitere Infos musste man sich bisher dennoch eher im Netz zusammensuchen.

Part I: Writing in DITA

Dies ist der erste Teil des Buchs und handelt wie der Titel schon sagt alle Basics rund um das Schreiben mit DITA ab. Für jeden Topictyp gibt es ein einzelnes Kapitel in welchem anhand von konkreten Beispielen die wichtigsten Elemente gezeigt werden und eben auch Tipps, wie sie am besten zu nutzen sind. Manche Dinge sind ja z.B. aus der DITA-Referenz nicht unbedingt ersichtlich, wie z.B. der Unterschied zwischen choices und choicetable. Die Autorinnen benennen konkret in welchem Fall welches Element geeignet ist.

Und einer der wichtigsten Sätze in diesem Zusammenhang ist vielleicht dieser:

Avoid using  […] elements simply because they’re available.

DITA bietet wirklich eine riesige Fülle an Elementen, aber man muss sie gar nicht immer alle verwenden.

Ein besonderes Augenmerk legen die Autorinnen auf die shortdesc (short description) und so bekommt dieses unscheinbare Element ein eigenes Kapitel. Der Grund dafür ist, dass der Inhalt dieses Elements das erste ist, was der Nutzer zu sehen bekommt. Dieser Text erscheint in den Suchergebnissen oder Linkübersichten und  hilft dem Nutzer so zu entscheiden, wohin er navigieren soll. Das Kapitel enthält viele nützliche Negativ-und Positivbeispiele für short descriptions

Part II:  Architecting Content

Dieser Teil hat mich schlichtweg begeistert und hätte mir vor 4 Jahren ziemlich viel Recherchearbeit abgenommen. Hier verlässt man die reine Autorenschiene von Teil 1 und befasst sich wirklich mit dem Eingemachten von DITA. Es gibt eine sehr ausführliches Kapitel über Maps; wie man diese am besten aufbaut und welche Möglichkeiten man generell in Maps hat. Weiter geht es mit den verschiedenen Arten des Verlinkens in DITA, also Related links, relationship tables etc.

Und dann kommen natürlich auch die Themen Metadaten, conditonal processing und Wiederverwendung dran.

Fazit

Zuerst muss ich noch erwähnen, dass das Buch noch einen 3. Teil namens „Converting and Editing“ enthält, den ich allerdings noch nicht gelesen haben.

Jedoch finde ich die ersten beiden Teile des Buchs schon so gelungen, dass der Teil nun auch nicht so schlecht sein wird 😉 Das Buch besticht auf jeden Fall durch sehr viel Praxisorientierung und hält sich nicht lange mit irgendwelchen Grundlagen und Randinformationen auf: es gibt viele Beispiele, wie sie auch im Redaktionsalltag auftreten können, und sehr gut finde ich die Checklisten am Ende jedes Kapitels, die nochmal alles gut zusammenfassen und somit eine gute Referenz für den Alltag darstellen.

Das Buch enthält allerdings keine Informationen zum DITA Open Toolkit und dem großen Thema Ausgabeformate, aber das hätte auch nicht wirklich in das Konzept gepasst, denke ich.

Kurzum: Ich empfehle dieses Buch absolut, wenn man einen Rundumschlag von der Autoren- bis hin zur Informationsarchitekten-Ebene möchte.

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.