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!

 

Ein Gedanke zu „tekom Frühjahrstagung 2012 – Dies und das“

  1. -Konzeptionelle Vorarbeit? Leitfaden? Standardisierung?
    -prozessunterstützende Software?
    -Konfigurationsaufwände und Datenmigration?
    -Überzeugungsarbeit bei fachfremden Chefs?

    Ich habe miterlebt, was passiert, wenn man die konzeptionelle Vor- und Nachbereitung und die anderen Punkte nicht berücksichtigt.
    Nachbereitung deshalb, weil man erst durch Ausprobieren mit eigenen Datenbeständen das CMS richtig kennenlernt. Da stößt auch die beste Schulung vorab an ihre Grenzen.

    Vernachlässigt man die Konzeptarbeit, hat man noch drei Möglichkeiten:
    1. teure Updates oder nachträgliche Konfigurationsanpassungen,
    2. Umstieg auf ein neues CMS oder
    3. alles wegschmeißen und Word aus der Mottenkiste holen.

Kommentare sind geschlossen.