Rapid Collaborative Writing

Heute, 11.02 Uhr, eine 92 Seiten umfassende Analyse beim “Mainzer Medien Disput 2009″ abgegeben zum Thema “Begrenzter Journalismus. Was beeinflusst die Entfaltung des Qualitätsjournalismus”.

Den Ergebnissen möchte ich hier nicht vorgreifen. Verraten will ich nur so viel: áIn der Analyse haben wir – das sind Miriam Bunjes, Geribert Jakob und ich, eine Reihe von negativen Nachrichtenfaktoren ausgearbeitet, die von Interviewpartnern kommentiert wurden. Der Mehrwert besteht für mich ganz persönlich darin, dass ich nun für meine Seminare im Rahmen der Initiative Nachrichtenaufkärung endlich einen guten und passenden Seminar-Reader habe. Denn die negativen Nachrichtenfaktoren begründen, warum relevante Nachrichten und Themen nicht die Aufmerksamkeit erhalten, die sie erhalten könnten. Geht man davon aus, dass die primäre Aufgabe des Journalismus darin besteht, Öffentlichkeit herzustellen, sind es die negativen Nachrichtenfaktoren, welche über ádie Qualität des Journalismus bestimmen.

Hier möchte ich aber ein wenig darüber erzählen, wie diese Analyse eigentlich nur mit Hilfe “kooperativer Technologien” rechtzeitig fertig gestellt werden konnte.

Geribert Jakob fragte mich erst in der ersten Oktoberwoche an, ob ich Interesse an dem Auftrag hätte. Abgabe sei allerdings bereits der 30.10. Am Termin ließ sich auch nichts rütteln – denn die Druckerei brauchte ja auch noch etwas Zeit.ááNachdem die Vertragsgrundlagen in ihren Grundzügen geklärt werden konnten, fing ich erst am 8. Oktober an, mich ernsthaft mit dem Thema zu beschäftigen. Mir war schnell klar, dass wir uns nicht mit verschiedenen Dokumentversionen herumschlagen und dabei wertvolle Zeit verlieren dürften. Denn: Jeder sollte jederzeit sehen können, wo der andere stand.áGeribert, der das Vor- und Nachwort schrieb, musste beispielsweise jederzeit Einblick in meine Arbeiten haben können. Außerdem sollte Miriam Bunjes mir am Ende noch zwei Tage für fehlende Textbausteine beistehen können. Dabei würden wir nahezu zeitgleich an denselben Kapiteln arbeiten müssen. Schließlich sollten auch in den letzten Tagen während des Lektorats noch Textänderungen möglich sein.

Weil die Zeit fehlte, auf dem Hochschulserver ein eigenes Projektwiki einzurichten, beschloss ich kurzerhand es einmal mit Google Docs zu versuchen. Bislang hatte ich das immer abgelehnt – zum einen, weil Google eh schon viel über uns weiß, zum anderen, weil Google etwas merkwürdige AGBs hat.

Rückblickend lässt sich sagen: Es hat gut geklappt, auch wenn es noch einige Bugs gibt, die einem das Leben schwer machen können. Zunächst aber das Positive:

Für jedes Kapitel legte ich ein extra Dokument an. Jedes der insgesamt zwölf Interviews wurde ebenfalls in einem extra Dokument dokumentiert. Auf diese Weise konnte ich die Interview-Dateien gezielt auch für die Interviewpartner freischalten. Allerdings nutzte nur ein einziger Interviewpartner die Möglichkeit, die Datei in Google Docs selbst zu bearbeiten. Die anderen erhielten den Text sowohl direkt in der E-Mail wie auch als Word-Anhang – alles eine Sache von ein paar Klicks. Zurück kamen die Korrekturen nur in einem Fall als Word-Datei, die ich in die alte Datei umkopierte, die anderen korrigierten direkt den E-Mail-Text.

Just während unseres Projekts überraschte Google mit einem neuen, sehr nützlichen Feature: So kann man jetzt ganze Ordner für weitere Personen freischalten. Ich zog also jedes neue Dokument in den Projekt-Ordner, den ich für alle direkt Beteiligten wie Co-Autoren und Lektorat freigab.áAuf diese Weise musste ich nicht, wie zuvor, jede Datei einzeln freigeben. Nützlich war außerdem, dass sich die Dokumente bündelweise auswählen und in einem anderen Format wie PDF oder Word exportieren lassen. Auf diese Weise war das Projekt innerhalb von 10 Sekunden komplett archiviert.

Der Workflow unter uns klappte wunderbar – musste allerdings nur ein einziges Mal eine Unterbrechung von mehreren Stunden hinnehmen, als sich unser Lektorat aka Lorenz Lorenz-Meyer für diese Zeit auf einem transatlantischen Flug befand und die vorher heruntergezogenen Dateien per Word bearbeitete. Sobald wieder ein WLAN zur Verfügung stand, wurden die Dateien wieder hochgeladen.

All das war sehr nützlich. Eher ärgerlich war jedoch, dass Google Docs seine Schwierigkeiten hat, den Text auch in ein lupenreines XML zu transformieren. Das heißt: Wird ein Text mehrfach formatiert, werden bei einer Umwandlung in eine Word-Datei auch Formatierungen berücksichtigt, die scheinbar längst gelöscht sind. So erscheint etwa ein einfacher Text in Überschriftengröße. Arbeiteten die Co-Autoren zunächst in ihrem Textprogramm, um den Text später in Google Docs zu kopieren, entstanden auf geheimnisvolle Weise Leerzeichen mitten in Wörtern – vermutlich alte Trennzeichen. Kopierte man diesen Text am Schluss áerneut nach Word, so entstanden wiederum neue Leerzeichen. Hatte man den Text allerdings ausschließlich in Google Docs bearbeitet, war dieses Problem nicht zu erkennen. Ein weiteres Problem bestand darin, dass Google Docs die Überschriftengröße nicht genau umsetzte. Überschrift 1 wurde zwar auch in Word zu Überschrift 1, Überschrift 3 wurde jedoch zu Überschrift 4. Unbrauchbar!

Ich hatte in zwei früheren Projekten mit MediaWiki gearbeitet. Dort gab es solche Formatierprobleme nicht – wohl weil man über die Wiki-Syntax die Formatierung direkt kontrollieren konnte. Allerdings hätte eine Einarbeitung in diese Syntax ebenfalls einen gewissen zeitlichen Mehraufwand erfordert.

Gleichwohl scheint das Korrigieren und Lektorieren im Wiki etwas besser zu funktionieren. Zwar hat auch Google Docs eine Versionierung, doch Änderungen werden nicht über eine farbliche Änderung angezeigt. Die Lektoren mussten daher ihre Änderungen selbst farblich markieren.

Fazit: Das Formatierungsproblem ist sehr ärgerlich, da man den gesamten Text nach dem eigentlichen Lektorat erneut prüfen muss. Für das nächste Projekt suche ich daher ein WYSIWYG-Wiki, das das Verschicken und Exportieren einzelner Dateien unterstützt. Vermutlich wird das dann Socialtext sein.


Beitr├Ąge zu verwandten Themen:

  1. Rapid Collaborative Writing: Ein Buch in 5 Tagen

About Christiane Schulzki-Haddouti

Freie IT- und Medienjournalistin. Hat dieses Blog 2007 im Rahmen der KoopTech-Analyse eingerichtet. Seit Beendigung des Projekts f├╝hrt sie es als Multi-Autorenblog weiter. Sie f├╝hrt ein pers├Ânliches Blog auf ihrer Homepage.
This entry was posted in Anwendungen, Medien and tagged , , , , , . Bookmark the permalink.

6 Responses to Rapid Collaborative Writing

  1. Pingback: Tweets die KoopTech ╗ Titelgeschichte ╗ Rapid Collaborative Writing erwńhnt -- Topsy.com

  2. Ich hatte bezüglich GDocs ähnliche Bedenken wie du, habe es ein paar Mal für Notizen genutzt und ein wenig rumgetestet, bin dann letztlich aber bei Zoho (http://www.zoho.com/) geblieben. Ehrlich gesagt ist mir bis jetzt nicht klar, warum das zumindest hierzulande so unbekannt ist und gegenüber GDocs so weit ins Hintertreffen gerät. Die Funktionen sind wesentlich besser ausgebaut und “wordiger” als bei Google. Zum Im- und Export von Dateien kann ich nicht viel sagen. Die paar Mal, die ich das genutzt habe, traten keine Probleme auf (wohl auch weil die Formatierungen nur sehr einfache waren). Kollaboratives Arbeiten in einem kleinen Team von vier Leuten war allerdings überhaupt kein Problem.

  3. Hallo!

    Ja, mit Zoho habe ich auch gute Erfahrungen gemacht, wobei mich aber diese Aufteilung in verschiedene Apps und Plattformen etwas gestört hat. Das erforderte immer wieder einen separaten Einwahlprozess, wenn man die App gewechselt hat. Aber das liegt jetzt auch schon zwei Jahre her. Vielleicht hat sich das auch schon wieder geändert. Ich denke, für GoogleMail-Nutzer liegt GoogleDocs nur einen Klick weit entfernt. Das ist einfach eine Frage der gefühlten Nähe.

  4. Pingback: links for 2009-11-01 – synapsenschnappsen

  5. Wittkewitz says:

    Ich empfehle meinen Kunden immer cubetree oder glasscubes für Firmen mit vielen Betriebssystemen und Kulturen und denen, die eh nur Microsoft Produkte nutzen dann DocVerse, aber bei ziipa gibt es noch Dutzende andere solcher Dienste zu finden…
    Naja, und ein DokWiki, MediaWiki oder TWiki aufzusetzen dauert auch nicht länger als einen Tag. Wenn es denn unbedingt ein Wiki sein soll. Schlank geht es mit box.net oder dropbox, da kann jeder auf seiner gewohnten mobilen oder eben stationären Umgebung bleiben und hat nur einen Projetordner, was in vielerlei Hinsicht sicher und komfortabel ist.

  6. Pingback: KoopTech » Titelgeschichte » 10+ Faktoren fŘr den Qualitńtsjournalismus

Comments are closed.