Die Redakteuse

Autor: Marijana Prusina

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

  • Und jetzt?

    So, es sind also nur locker-flockige 2,5 Jahre seit dem letzten Blogpost vergangen. Ich schiebe das Blog-Thema ja schon so eine Weile vor mir her. Soll ich es archivieren? Wie fange ich wieder an? Über was blogge ich? Nach 1 Jahr Elternzeit müssen sich die Synapsen ja auch erst einmal wieder auf das Thema Redaktion & Co. einstellen. Und mit einem Mama-Blog verschone ich euch mal 😉

    Und bevor ich anfange einen Redaktionsplan zu erstellen und sonst irgendwelche tollen Masterpläne, sag ich einfach mal: Da bin ich wieder. Und ich werde wieder öfter da sein 🙂

     

     

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

  • Eine Unkonferenz – Barcamp Karlsruhe 2012

    Den Begriff „Barcamp“ hatte ich schon öfter mal gehört, aber so richtig bewusst habe ich mich damit nicht beschäftigt. Bis ich dieses Jahr mitbekommen habe, dass es ein Barcamp in Karlsruhe gibt.

    Ein Barcamp ist eine Unkonferenz und zwar in dem Sinne, dass es im Vorfeld zwar ein Thema (hier war es allgemein „Netzkultur“), aber kein Tagungsprogramm gibt und überhaupt alles ziemlich flexibel ist (Mehr Hintergrundinfos bei Wikipedia). So ist ein Barcamp eine offene Plattform, um sich auszutauschen und der wichtigste Grundgedanke ist, dass jeder aktiv mitgestalten kann, d.h. wer möchte, kann eine Session halten und diskutieren ist sowieso erwünscht.

    Es sind in der Regel Privatpersonen, die das ganze organisieren. Die Teilnahme und Verpflegung sind kostenlos, weil Firmen als Sponsoren geworben werden.

    Wie läuft ein Barcamp ab?
    Man trifft sich morgens. Danach stellt jeder, der an dem Tag eine Session (die Form ist frei: Vortrag/Workshop/Diskussion) halten will, kurz sein Thema vor und fragt, ob jemand daran Interesse hat. Ich glaube, bei der Frage hält jeder, der ein Thema vorstellt, kurz den Atem an und hofft, dass sich überhaupt jemand meldet. So ging es jedenfalls mir als ich mein Thema „Content strategy“ vortrug 😉 Aber glücklicherweise gingen einige Hände in die Höhe 😉

    Nach Menge der Interessenten wird dann ein Raum auf dem großen Sessionplan gewählt – und zack hat man ein Tagesprogramm vor sich.

    Bei diesem Barcamp gab es ein buntes Sammelsurium an Themen, was ich persönlich sehr spannend fand, denn man kommt auch mal mit ganz anderen Themen in Berührung. Ich selbst habe so unterschiedliche Themen wie „Hacking via USB“, „Change management“ oder „Selbstfindung“ besucht – das zeigt ja schon mal die große Bandbreite.

    Zwischen den ganzen Sessions wurden wir hervorragend verköstigt und hatten es überhaupt sehr entspannt. Hier ein Riesenlob an die Organisatoren!

    Fazit
    Ein Barcamp ist, was man selbst draus macht – und das finde ich richtig gut! Ich schaue ja bekanntlich gerne über den Tellerrand und das war die perfekte Veranstaltung, um genau das in einer lockeren Atmosphäre zu tun. Barcamps gibt es übrigens zu den verschiedensten Themen und nicht nur unbedingt IT-bezogen, wie z.B. das GrillCamp zeigt 😉

  • Wie weit sollte CMS-Abhängigkeit gehen?

    Diese Frage stelle ich mir, seit ich auf der tekom-Frühjahrstagung im Vortrag „Content-Management powered by PI-Mod“ von Stephan Steurer mit Special Guest Prof. Ziegler saß. PI-Mod ist ein XML-Standard für Dokumentation, der vor ca. 4 Jahren unter Federführung von Prof. Wolfgang Ziegler entstand und in den die Anforderungen aus vielen Kundenprojekten aus dem Maschinen- und Anlagenbau einflossen.

    Eine sehr interessante Eigenschaft von PI-Mod ist die Trennung zwischen den dahinterliegenden Konzepten und der Implementierungslogik. Das heißt PI-Mod liefert keine Mechanismen mit, die vorgeben wie z.B. wiederverwendet wird oder Dokumente aggregiert werden. Wenn man sich die Redaktionssysteme heutzutage so anschaut, hat da sowieso jedes seine eigene Verfahrensweise. Und indem man sicht mit PI-Mod nicht festlegt,  hat man eine sehr viel größere Freiheit bei der Auswahl eines Redaktionssystem.

    Das ist nun ein völliger Gegensatz zu DITA, das  out-of-the-box alles liefert, was das TR-Herz begehrt. Damit schreibt es aber auch gleichzeitig ziemlich viel vor. So muss man sich als DITA-einsetzende Redaktion dann fragen:

    • Nehme ich ein DITA-spezialisiertes CMS?
      Die Auswahl ist aktuell noch gering und damit die Chance hoch, dass es verschiedene andere Anforderungen nicht erfüllt.
    • Nehme ich ein CMS, benutze dessen Mechanismen für z.B. Publikation, Aggregation, und mache mich von dem CMS quasi abhängig?
      Eröffnet einem eine große Auswahl und damit eine größere Chance das in jeder Hinsicht richtige System zu finden.
    • Nehme ich ein CMS, lasse die Unterstützung der DITA-Mechanismen einbauen und bin somit systemunabhängig?
      Man hat jederzeit die Möglichkeit das CMS zu wechseln. Die Infrastruktur läuft auch (quasi) ohne CMS.

    Fazit

    Es ist eine leicht philosophische Frage, die kaum einfach so zu beantworten ist. Wer voll auf der DITA-Schiene fährt, möchte in der Regel gerne ziemlich viel selbst bestimmen können und da ist es nur logisch, dass man ein ungutes Gefühl dabei hat bestimmte DITA-Möglichkeiten nicht zu nutzen, sondern sich abhängig von den Systemgegebenheiten zu machen. Andererseits stellt sich auch die Frage, ob man je wirklich das CMS wechseln wird. In der Regel war es schon schwer genug das eine zu bekommen! Aber man weiß ja nie… Allerdings weiß man auch nie, ob man nicht vielleicht auch mal den Standard wechselt, weil es inzwischen ein viel besseren gibt?

    Wie seht ihr das?

  • Konferenz für Informationsarchitektur 2012 – Rückblick

    Ich interessiere mich schon lange für Informationsarchitektur – wie baut man Informationen so auf, wie stellt man sie so dar, dass sie möglichst einfach gefunden werden? Das klingt auch erst einmal einfach nach der Beschreibung eines technischen Redakteurs 😉 Eine gute Beschreibung einer Konzepter/Informationsarchitekten-Stelle gibt es bei designerdock.

    Mir wurde die Konferenz für Informationsarchitektur schon vor längerer Zeit empfohlen, und so hab ich nicht lange gezögert als ich sah, dass das Schwerpunktthema für 2012 „Content Strategy“ heißen sollte 🙂

    Da war ich also mit einem unhippen Thema „Doku im Umfeld der Content Strategy“ unter all den Konzeptern, denen in der Regel dieser wohlbekannte, sofort latent gelangweilte Ausdruck über das Gesicht huschte, wenn ich das Wort „Dokumentation“ erwähnte und den wohl jeder TRler zur Genüge kennt 😉

    Content-Strategy nur als Werkzeug im Pre-Sales
    In den Vorträgen ging es in der Regel vor allem um einen Aspekt in der Content Strategy: die Pre-Sales-Phase. Wie konvertiere ich einen Website-Besucher zu einem zahlenden Kunden? Das war’s. Das lässt sich vielleicht damit erklären, dass hier relativ viele Agenturen vertreten waren, die in der Regel mit einem speziellen Auftrag betraut sind und die Firmen nicht unbedingt langfristig begleiten. Und wie mir bestätigt wurde, sind die Kunden am Ende auch nur darauf fokussiert auf Ihren Webseiten die Konversionsrate zu erhöhen.

    Das Bewusstsein für ein allumfassendes Produkterlebnis bei dem man nicht nur den Neukunden becirct, sondern auch den Bestandskunden hegt und pflegt, scheint sowohl in Firmen als auch in Agenturen noch nicht so stark zu sein. Die After-Sales-Phase spielt meiner Meinung nach eine große Rolle, um eine Marke zu stärken, und Dokumentation bzw. Support-Material gehört hier zum zentralen Content. Aus Marketing-Sicht ist dieser Content halt so wahnsinnig „unsexy“, dass er gerne ausgespart wird, anstatt dass man mal darüber nachdenkt, dass JEDER Content letztendlich Marketing ist und wie man diesen Content verbessern kann. Da sehe ich noch großes Potential!

    IAK12-Schnipsel

     Know thyself (Margot Bloomstein)

    Diese Aussage fasst gut zusammen, was ich desöfteren hören konnte: Am Anfang von allem steht die Kernbotschaft, die man als Unternehmen vermitteln möchte. Sie ist die Grundlage für jedwede Strategie und Kommunikation. In einem Vortrag zur Kommunikationsstrategie vom Taschenhersteller Freitag konnte man sehr schön sehen, wie die Unternehmenskommunikation von dem speziellen Freitag-Geist durchdrungen ist und damit eine Einheit nach außen bildet. Wenn man nicht weiß, was man vermitteln soll, kann das Wie fast nur schief gehen.

    Information gestalten. Nicht Gestaltung mit Informationen füllen (Fabian Lang)

    In vielen Firmen ist es Gang und Gäbe, das erst designt wird und dann am Ende der Texter noch seinen Text „reinhämmert“. Wenn dann beispielsweise eine Überschrift der 2. Ebene konzipiert wird, aber der Texter da eigentlich nichts Sinnvolles reinzuschreiben hat, ist das sein Problem. In der Regel wird er dann irgendwas reinschreiben, auch wenn man diesen Text eigentlich nicht braucht. Deswegen ist es wichtig, dass auch die Texter in die Konzeption miteinbezogen werden, so dass sie ihr Feedback und ihren Text frühzeitig miteinbringen können. Sonst passiert beim Aufeinandertreffen von Konzept und Content eben das hier  (ein Schnappschuss aus Fabians Vortrag):

    Change-Management

    Content betrifft oft sehr viele verschiedene Mitarbeiter in einem Unternehmen, und jeder folgt seinem eigenen Weg. Für eine erfolgreiche Content-Strategy ist es aber erforderlich, dass sich alle auf einen Vision einigen und an einem Strang ziehen. Wie schafft man das? Laut Stefan Freimark:

    • Schwächen aufzeigen und den Handlungsbedarf verdeutlichen
    • Alle Betroffenen einbeziehen: mit regelmäßigen Meetings, Newslettern, alle an einen Tisch setzen

    Fazit

    Es war durchaus interessant, das Thema „Content-Strategy“ mal aus der Konzepter-Perspektive zu sehen. Rückblickend hätte ich   gerne einen Vortrag auf der Konferenz gehalten, um mal die TR-Perspektive an den Konzepter zu bringen. Der Blick auf einen komplette Produkterfahrung wird nämlich langfristig noch sehr wichtig werden, wie ich denke. Und spätestens als in einem Vortrag plötzlich das Wort „DITA“ an der Wand stand (wobei ich noch nicht genau verstanden habe, warum…), war ich mir sicher, dass hier auf jeden Fall irgendwann eine Annäherung stattfinden wird.

    Ein bisschen gestört hat mich, dass es den Referenten mit einer Vortragszeit von nur 35 Minuten oft nicht möglich war, richtig in die Tiefe zu gehen. Ich fände 45 Minuten angemessener und 15 Minuten Pause langen eigentlich auch vollkommen 🙂

    Ansonsten: Die Location in der Zeche Zollverein Essen war toll – in den Pause konnte man mal kurz durch das Museum schlendern und abschalten. Die Idee jedem Teilnehmer Methodenkarten zu einem Thema zu geben, damit man diese untereinander tauscht, war auch klasse, denn man hatte einen guten Anknüpfungspunkt für Gespräche.

    Methodenkarten zum Thema "Content Strategy" auf der iak12

     

     

     

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