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!