Notizen zum Datenjournalismus

Im Hamburg drängelten sich dieser Tage rund 100 Menschen – die meisten Journalistinnen und Journalisten, aber auch jede Menge Programmierer/innen, und viele waren wohl irgendwie beides – bei Gruner+Jahr bei einer Tagung des Netzwerks Recherche, um etwas über Datenjournalismus zu erfahren. Hier ein paar Notizen, Videos, Links und Tweets.

Erkenntnis Nr. 1: Das Thema Datenjournalismus nimmt auch in Deutschland Fahrt auf. Journalisten werden in absehbarer Zeit nicht mehr über die Runden kommen ohne Grundkenntnisse über das Beschaffen, Nutzbarmachen, Auswerten und Visualisieren von Daten. Das scheint auch Verlagen und anderen Medienunternehmen zu dämmern.

Erkenntnis Nr. 2: Teamwork gewinnt an Bedeutung. Es braucht Journalisten, Programmierer und Gestalter – allesamt mit Spezialkenntnissen, aber auch der Fähigkeit, die anderen Bereiche “mitzudenken”.

Erkenntnis Nr. 3: Ohne Excel geht goar nix.

Ein bisschen Theorie …

Brant Houston (Twitter), der Professor an der Universität Illinois ist und dort data driven journalism (schöne, temporeiche Bezeichnung;)) lehrt, erinnert daran, wie alt Datenjournalismus ist: 1969 stellt Philip Meyer seine Social Science Methods vor und postuliert schon 1973 in seinem Buch “Precision Journalism”: “You have to understand data”. Adrian Holovarty schreibt 2006 so etwas wie das Manifest des Datenjournalismus. Im selben Jahr tritt in Deutschland mit dem Informationsfreiheitsgesetz eine wichtige rechtliche Grundlage in Kraft.

Aber bei der Tagung wird auch klar: Ein Rechtsanspruch auf Daten bedeutet nicht, dass der Datenjournalismus freie Bahn hat. Da gibt’s zum einen (und glücklicherweise) den Datenschutz, und nicht nur Rechtsanwalt Jan Mönikes, mit großem Hintergrundwissen zur (und großer Sympathie für die) Open-Data-Bewegung, meint: “Rohdaten können immer problematisch sein”. Und das sind zum anderen die Behörden, deren (pardon) teilweise Bräsigkeit – und ihr Faible für PDF. Wenn sie denn geliefert werden, liegen die Daten zumeist in diesem Format vor, das erst einmal zeit- und kostenaufwändig in eine maschinenlesbares Datei (Excel!) umgewandelt werden muss.

Brant Houston erinnert aber auch daran, dass die Grundsätze des Berufs natürlich auch im Datenjournalismus gelten. “Adoption of new tools does not mean elimination of old.” Und: “Credibilty is all.” Plausibilitätscheck, mehrere Quellen, diese Dinge. Houston beispielsweise gibt sich nicht mit nur einer Datenbank zufrieden, ebenso wenig wie mit nur einem Interviewpartner.

Und: “I still like newspapers – no internet connection or password required”.

Fallen und Fehlerquellen

Henk van Ess hat mir persönlich sehr gut gefallen. Mit offenem Charme erzählte der Journalist aus Holland von den Fehltritten des Datenjournalismus, Projekten, die in die Hose gingen, aber auch von einem, das geklappt hat: Die Suchmaschine Cablesearch hilft verzweifelten Journalisten, sich etwas besser im Dschungel der Wikileaks zurechtzufinden.

Seine Empfehlungen, kurz zusammengefasst:

• Journalist – Coder – Designer: Gib nie nur einer dieser Personen im Team das Oberkommando für das gesamte Projekt.
  Aber: Gib auch nie KEINEM von ihnen die Verantwortung.
• Du musst nicht alles selber machen. Nutze Crowdsourcing – aber nimm nie den Erstbesten, der auf dein Angebot so schnell antwortet, dass er die Jobbeschreibung eigentlich gar nicht richtig gelesen haben kann.
• Kenne die Arbeitsfelder der anderen, damit du präzise Instruktionen geben kannst. “Hire coders, don’t become one. But know the concept behind.”

Die Präsentation von Henk van Ess auf Slideshare.

… und ganz viel Praxis!

Beispiel: Interaktive Grafik zur Berlin-Wahl

Zwei Datenjournalisten (ok ok, mit Programmierkenntnissen), drei Monate Vorbereitungszeit, kreative Ideen, keine Angst vor den (kostenlosen) Google Tools und ein Wahlleiter, der mitdenkt: Aus diesen Zutaten lässt sich so etwas Cooles wie die interaktive Karte zur Berlin-Wahl machen. Julius Tröger, Datenjournalist in Diensten der Berliner Morgenpost (Twitter, Blog, Google+), der das Projekt mit umgesetzt hat, erläuterte auf der Tagung in Hamburg das Rezept. Seine Präsentation findet sich auf Slideshare.

Die fünf Schritte zum Glück zur Grafik:

1.) Daten besorgen (z.B. Bundes-/Landeswahlleiter) und bereinigen: Alles, was man nicht braucht, fliegt raus; alle Datensätze (z.B. jeder Wahlbezirk/jedeer Wahlkreis ) bekommen eine eindeutige ID

2.) Bereinigte Daten in Google Fusion Tables hochladen, das daraus eine Datenbank macht.

3.) Daten in FT visualisieren – etwa als Punkte auf einer Karte

4.) Diagramme erstellen (z.B. Stimmenverteilung in einem Wahlkreis) mit Google Chart Tools und, zusammen mit weiteren Zahlen/Fakten, per HTML in Infofenster einbetten

5.) Kartensteuerung und Layout umsetzen mit Fusion Tables Layer Builder

Optional:

Karte schöner machen mit Maps Style Wizard

Sehr cool finde ich auch diese Visualisierung der Politiker im Berliner Abgeordnetenhaus, die man sich nach Bezirk, Ausschuss, Alter, Herkunft usw. filtern kann.

Fallstricke:

• Daten werden in der Regel als csv/xls angeliefert, aber kml-Dateien zur Geocodierung gibt’s von den Ämtern (noch) nicht. Folge: Gebiete (z.B. Wahlbezirke) müssen händisch nachgezeichnet werden. Dafür kann man ein kostenloses Polyline-Tool von Google nutzen.
• Die interaktive Karte muss mit Testdaten immer wieder auf Herz und Nieren geprüft werden. Dazu braucht es hilfsbereite Wahlleiter, die Testdaten im Original-Format zur Verfügung stellen. Am Wahltag selbst sollten alle Arbeitsabläufe durchgetestet sein und “sitzen”, um “nur noch” die Original-Daten einzutragen. Im Falle der Berlinwahl-Grafik hat das zwei Leute sechs Nachtstunden lang beschäftigt.
• Google verlangt für die kommerzielle Nutzung von Maps Geld – ab 2500 Zugriffe/Tag (und, soweit ich weiß, erst wenn die über 30 Tage hinweg erfolgen); Alternative: Premier Key für 10.000$

Beispiel: Zugmonitor

Nach einem halben Jahr Denk-, Entwicklungs- und Umsetzungsarbeit ist im März der Zugmonitor von sueddeutsche.de online gegangen – rechtzeitig zum Ende der Vorschlagsfrist für den Grimme Online Award. Das ist sicher nur Zufall. Gut möglich aber, dass das Projekt ausgezeichnet wird. Und damit sind wir schon beim Dilemma: Renommee ist hierzulande immer noch so ziemlich das maximal Erreichbare für ehrgeizige digitale Projekte. Nicht, dass das nichts wäre. Trotzdem frage ich mich, um wieviel schneller sich digitaler Journalismus entwickeln könnte, wenn es nur gelänge, damit gutes Geld zu verdienen.

Der Zugmonitor, eine interaktive HTML5-Anwendung, die auf die Verspätungsdaten der Bahn zurückgreift und sie in Echtzeit auf einer Karte sichtbar macht, ist jedenfalls “keine Cashcow”, sagt Wolfgang Jaschensky, Homepage-Chef von sueddeutsche.de – das darf man wohl mit Fug und Recht einen Euphemismus nennen. Sueddeutsche.de hat mehrere Redakteure auf die journalistische Entwicklung des Projekts angesetzt und mit der technischen Umsetzung die Agentur Open Data City von Lorenz Matzat (Twitter) beauftragt, die auch Projekte für taz.de und Zeit Online gemacht hat. Das scheint derzeit das Mittel der Wahl für Verlage: Fachwissen projektbezogen einzukaufen statt Spezialisten dauerhaft einzustellen. Solange Datenjournalismus nur punktuell eine Rolle spielt, wird das wohl so bleiben, aber auf Dauer werden Verlage die Fachleute im Haus haben. (Selbst Nokia stellt Datenjournalisten ein!)

Datenbanken finden und nutzen

Das Web steckt voller Daten. Und die stecken – in aller Regel – in einer Datenbank. Eine herkömmliche Google-Suche scheitert daran meist, weil

• Google Datenbanken nicht indiziert
• sich Datenspeicher hinter Formularen verbergen
• Daten sich in nicht optimierten Dokumenten oder eingebetteten Anwendungen verstecken …

Was also tun, um Datenbanken dennoch zu finden und auszulesen?

Hier ein paar simple, aber wirkungsvolle Empfehlungen von Journalist und Recherchetrainer Marcus Lindemann (Twitter):

Für die Nerds unter den Journalisten hat Sebastian Mondial (Twitter, Google+) auf der Tagung einige coole Tricks verraten.

Phoneview ist eine Art Röntgen-Software für Apps. Sie zeigt die Inhalte ein App an, zum Beispiel die Datenbank, die hinter den Kulissen der App werkelt (und oft offline verfügbar ist). Die so indentifizierte App-DB lässt sich auf dem Rechner speichern und dort öffnen – mit einem weiteren Tool namens SQlite (zugleich der Name des Formats, in dem App-Datenbanken vorliegen).

Doch wozu sollte man das tun? Zum Beispiel, um eine Terminplaner-App der EU auszuwerten und aus der Datenbank eine Statistik zu erstellen, in der sich die eine oder andere Geschichte finden kann. Oder, um alle Standorte von Filialen eines Unternehmens in eine Tabelle zu exportieren und daraus eine Karte zu generieren, statt sich die (eh öffentlich zugänglichen) Adressen mühsam eine nach der anderen zusammenzusuchen. Darum geht es bei der Nutzung dieser Hilfsmitteln nämlich meist: Daten, die bereits veröffentlicht sind, einzusehen, komplett herunterzuladen und in maschinenlesbare Formate zu bringen.

Die Datenbank-Abfrage einer Website spuckt nur eine HTML-Tabelle aus? Kein Problem: Das Firefox-Addon Table Tools macht daraus eine beliebig filterbare Excel-Tabelle, die man nach Auffälligkeiten (also: Geschichten) durchsuchen kann.

Mashups sind wahre Datenbank-Quellen, die man mit dem Werkzeug Charles zum Sprudeln bringen kann. Da geht so: Man ruft eine Internetanwendung (z.B. eine Karte) auf, die jemand unter Nutzung einer Datenbank erstellt hat (z.B. alle McDonalds-Filialen), lässt sich von der zwischengeschalteten Software (Kostenpunkt derzeit: 50 Dollar) zeigen, welche Suchanfragen beim Aufrufen der Karte wohin geschickt werden – et voila: Schon kennt man die dahinter liegende(n) Datenbank(en) und kann sie ggf. nutzen.

Zu guter Letzt: Gesammelte Tweets zur Tagung