(Dieser Text habe ich auch auf datenjournalist.de veröffentlicht. Dort gibt es auch interessante Kommentare dazu.)
Mit diesem etwas vereinfachten Statement von mir trat Natalia Karbasova auf Twitter eine kleine Diskussion zu Datenjournalismus (DDJ) und Programmierkünsten los, die zeigt, dass diese Frage alles andere als beantwortet ist. Vielleicht, weil wir hierzulande noch keine klare Vorstellung davon haben, wie guter Datenjournalismus entstehen kann. Und was er überhaupt ist.
Die Diskussion ums Programmieren lohnt also. Bisher verläuft sie allerdings ziemlich schwarz-weiß, scheint mir: Wer Programmieren kann, ist dafür, der Rest ist dagegen. Egal, ob er tatsächlich nicht programmieren will, es sich nicht zutraut, oder einfach keine Chance sieht, die Zeit fürs Lernen und Ausprobieren aufzubringen.
Ich starte hier den Versuch, die Diskussion aufs Inhaltliche zu lenken: Wo und wie hilft es Datenjournalisten konkret, coden zu können?
Damit es nicht langweilig wird, schlage ich mich ganz auf die Seite der Coder: Ich glaube, dass Datenjournalisten programmieren können sollten. Alle Datenjournalisten. (Es gibt valide Argumente, warum jemand in einer gut ausgestatteten Redaktion weniger dringend programmieren können muss als ein freier Journalist. So wie es auch viele verständliche Gründe gibt, warum so viele Journalisten gar nicht programmieren. Aber das ignoriere ich mal.)
Man muss dazu sagen, was mit „Programmieren“ gemeint ist. Man muss sicher nicht interaktive High-End-Visualisieren selbst schreiben können, komplizierte Big Data-Scraper oder neuartige Datenbank-Frontends.
Was Datenjournalisten können sollten
Von einigen wichtigen Dingen sollte man aber nicht nur schon einmal gehört, sondern sie am besten auch selbst ausprobiert haben. Hier meine persönliche Liste, welches Know-how erstrebenswert wäre (teilweise ist das nicht Programmieren im engeren Sinne):
-
R (freie Sprache für Statistik, Datenanalyse und -visualisierung)
-
Zusätzlich (oder als Ersatz für R) eine flexible „Offline“-Programmiersprache, z.B. Python
-
Ein Bisschen Regex (universelle „Suchen-und-Ersetzen“-Sprache)
-
Das Terminal (Betriebssystem-Shell) und seine wichtigsten Befehle (inkl. Installation von Softwarepaketen „per Hand“)
-
Grundkenntnisse von SQL und Datenbanken
-
Javascript (und am besten auch eine Idee von jQuery)
Nicht, dass ich das alles selbst perfekt beherrschen würde. Zum Beispiel an Punkt 5 hapert es bei mir ziemlich. Ohnehin bin ich ein „Copy- und Paste“-Selfmade-Programmierer, der vor allem seine eigenen alten Programmschnipsel (und im Internet gefundene) immer wieder neu zusammenklebt. Meistens mache ich das ohne vernünftige IDE, und ohne Google und Stack Overflow geht sowieso fast gar nichts.
Aber selbst bescheidenen Kenntnisse machen den Unterschied. Wer wenigstens im Ansatz programmieren kann, arbeitet nicht nur sauberer, effizienter und effektiver. Ihm eröffnen sich neue datenjournalistische Welten, glaube ich.
Dafür ist es zwar unabdingbar, sich in der Welt der Webprogrammierung einigermaßen zurecht zu finden (HTML, Javascript & Co). Noch wichtiger ist aber, eine „Offline“-Sprache wie Python oder R (mein Favorit) zu beherrschen, um Daten zugänglich zu machen, analysieren und grafisch aufbereiten zu können.
Mehr und bessere Daten
Die interessantesten Daten liegen leider nicht fertig als Excel- oder CSV-Dateien auf der eigenen Festplatte herum. Sie stehen auf irgendwelchen Internetseiten, kommen in PDFs, speziellen XML-Strukturen oder anderen mehr oder weniger bekannten Formaten daher. Um an solche Daten zu kommen, muss man sie scrapen, das heißt aus ihrer komplizierten Datenstruktur herausschälen, und sie in einem einfachen Format abspeichern, mit dem man dann weiter arbeiten kann.
Aber das geht nur, indem man programmiert. Es gibt zwar auch Tools, die einem das programmierte Scrapen vermeintlich abnehmen. Aber zumindest für größere Datensatz geht das eigentlich nur mit selbst geschriebenem Code – am besten auf dem eigenen Rechner (u.a. wegen der Anpassungsfähigkeit an unsaubere Details im Datensatz, wegen des Tempos und wegen der Notwendigkeit, die Daten offline zu sichern).
Auch kleine Datensätze, die schon offline vorliegen (z.B. der Textinhalt eines PDFs), lassen sich mit ein bisschen Regex im Texteditor manchmal wesentlich schneller und sauberer scrapen als mit ausgefeilteren Tools.
Dateien müssen gar nicht so groß sein, um Excel in die Knie zu zwingen. Die fantastischen 1.048.576 Datenzeilen, mit denen man Excel 2013 inzwischen angeblich füttern darf, relativieren sich ganz schnell, wenn man halbwegs anspruchsvolle Rechenoperationen darauf loslässt. Wer einmal versucht hat, Spalten verschiedener Datenblätter in einer größeren Tabelle (ab ca. 10.000 Zeilen wird’s schwierig) per SVERWEIS zu verknüpfen, der stellt schnell fest, dass Excel nach jedem Arbeitsschritt so lange rechnet, dass man erstmal Tee trinken gehen kann. Viel Tee. Und wenn man wieder kommt, ist Excel abgestürzt und alles ist futsch.
Ein kleines R-Programm macht das Ganze in Sekundenbruchteilen. Wie in anderen Programmiersprachen auch ist das Matchen bzw. Mergen von Daten (also die im DDJ so wichtige „SVERWEIS-Prozedur“) in R eine Standardroutine, die ebenso wie (konditionales) Sortieren, (kompliziertes) Filtern oder beliebige Datenabgleiche auch auf großen Datensätzen quasi in Nullzeit möglich sind. Dabei dürfen die Datensätzen auch komplex sein. Wobei „komplex“ im deutschen DDJ ja schon heißt: mehr als die zwei Datendimensionen, auf die Excel-Tabellen beschränkt sind (weil der Bildschirm zweidimensional ist).
Man mag einwenden, dass solche „Super“-Datensätze doch im normalen datenjournalistischen Alltag fast nie vorkommen. Stimmt vielleicht. Aber das ist ja gerade das Problem. Denn der Grund dafür ist nicht, dass es solche Daten nicht gäbe. Wir nutzen sie bloß nicht, weil wir sie nicht im Blick haben. Und wir haben sie nicht im Blick, weil wir gar nicht darauf eingestellt sind, mit ihnen handwerklich umzugehen (indem wir nämlich programmieren).
So liegen zum Beispiel in den deutschen Forschungsdatenzentren Individualdaten zu den verschiedensten Themen, auf die im Prinzip auch Journalisten Zugriff bekommen könnten (ich habe das in meinem Post zu OpenMicroData beschrieben). Aber das geht per se nur, wenn man ein entsprechendes Programm an das FDZ schickt, das die journalistisch gewünschte Aufbereitung (inklusive Anonymisierung) der Mikrodaten macht.
Wir lassen die wertvollsten Datenschätze journalistisch verrotten. Weil wir nicht programmieren.
Bessere Grafiken
Ähnliches gilt für Grafiken: Das Standardtool Excel ist extrem beschränkt. Das ist natürlich kein Wunder, sobald man über Online-Grafiken spricht. Dafür ist Excel ja gar nicht gedacht. Und auch für hochwertige Printgrafiken haben Profis schon immer spezielle Grafiksoftware verwendet.
Die grafische Analyse von Daten ist im DDJ-Workflow aber noch weit vor dem Gedanken an ein optisches Endprodukt wichtig (obwohl viele Projekte fälschlich mit ebendiesem starten). Sie sind eigentlich ein unschlagbares Mittel, um Daten schnell zu begreifen und Besonderheiten darin zu finden. Visualisierungen sind also ein journalistisches Bewertungs- und Selektions-Mittel zu einem Zeitpunkt, an dem die Daten noch fest in der Hand des Datenjournalisten sind, selbst wenn er mit einem ganzen Heer von Webprogrammierern und Grafikern zusammenarbeiten darf. Für eine gelungene datenjournalistische Analyse fehlen einer Tabellenkalkulation aber wichtige Grafiktypen.
Ein Histogramm kriegt man in Excel vielleicht noch hin, obwohl es keine Standardfunktion ist. Aber es gibt zum Beispiel keinen Scatter-Plot, der gleichzeitig die Datenpunkte beschriften kann (so dass man etwa in einer Punktwolke aller deutschen Kreise mit Lebenserwartung (X-Achse) und Einkommen (Y-Achse) auch noch den Namen des Kreises angeben kann, um ihn einfach abzulesen). Und jede Art von Kartierung ist bei Excel völlig Fehlanzeige, ebenso wie viele anderen Visualisierungstypen (Hier zur Anregung ein paar Grafik-Beispiele in R).
Nun kann man sich natürlich in seinem gewohnten Excel-Workflow behelfen, indem man für zusätzliche Grafiktypen zusätzliche Software benutzt. Zum Beispiel das freie QGIS für Karten. Das gibt aber einen Bruch im Datenworkflow. Will man am Dateninput der Grafik etwas ändern (sie z.B. filtern, die Bezugsgröße ändern, sie skalieren oder standardisieren), dann muss man zurück zur Tabellenkalkulation gehen, die Neuberechnungen dort machen, die Daten neu ex- und importieren, um dann erst die neue Darstellung im Visualisierungsprogramm zu machen. Das ist nicht nur aufwändig, das produziert auch Fehler.
Das eigentliche Problem dabei ist aber: Es führt dazu, dass der Schritt zurück zur Neuberechnung der Datengrundlage gar nicht erst gemacht wird. Zu aufwändig (verständlicherweise). Und wieder hat die Begrenztheit der Tools den DDJ begrenzt. In einem sauberen Programmcode hätte es evtl. gereicht, nur ein paar Parameter zu verändern.
Freuen dürften sich auch die Grafikabteilungen, wenn sie Visualisierungsvorlagen nicht mehr als Excel-Screenshots bekommen, sondern als Vektoroutput (für Sprachen wie R oder Python sind PDF oder SVG kein Problem), so dass sie die Grundstruktur der Plots nicht gänzlich neu bauen müssen. Programmiert man seine Grafiken, kann man durch ein paar Codezeilen auch jeden Bereich beliebig beschriften, schraffieren, Daten einfärben oder kommentieren. Das Ergebnis ist eine professionelle, elektronische Grafikvorlage, die Missverständnisse und Fehler beim gestalterischen Feinschliff weitgehend ausschließt.
Daten besser analysieren
Auch für die statistische Analyse sind Tabellenkalkulationen leider nur begrenzt geeignet. Mal schnell ein Histogramm zu machen (in R: hist(data)) geht in Excel leider nicht so wirklich schnell. Will man dort auf Ausreißer testen oder auf andere Auffälligkeiten und Zusammenhänge in den Daten, ist ganz Schluss (gemeint sind echte statistische Tests, multivariate Regressionsansätze bzw. statistische Verfahren, die aussagefähiger sind als einfache Analysen wie etwa eine Quantil-Abschätzung per Boxplot oder ein Korrelationskoeffizient).
Ein datenjournalistisches Luxusproblem? Ich glaube nicht. Ist es nicht eine journalistische Grundregel, erstmal die Relevanz einer Nachricht zu bewerten? Und bedeutet das bei der journalistischen Arbeit mit Daten nicht, dass man das (auch) mit Statistik tun muss?
Ich glaube, dass viele Journalisten solche Analysen sehr gerne machen würden. Wenn sie bloß könnten. Und wenn sie sie bloß kennen würden. Aber das ist schwierig, denn Excel kennt sie ja nicht.
Excel hält uns dumm.
Fehlerfreier, transparenter und nachvollziehbarer Workflow
Dabei geht es gar nicht nur darum, was Excel (oder z.B. Libre Office) alles nicht kann. Natürlich ist eine Programmiersprache immer überlegen, weil sie universell angelegt ist. Und natürlich gibt es sehr guten Datenjournalismus, für den der Funktionsumfang einer Tabellenkalkulation ausreicht.
Doch auch in solchen Fällen würde ich Excel in Frage stellen. Weil es Fehler verschleiert und es unmöglich macht, (fehlerhafte) Arbeitsschritte nachzuvollziehen (und damit rückgängig zu machen und zu korrigieren). So sehr man sich auch Mühe gibt, jeden Zwischenschritt der Datenverarbeitung irgendwo im Spreadsheet abzulegen und zu kennzeichnen, irgendwann kommt mit Sicherheit das erste Copy & Paste, die erste Summe über den Autofilter oder der erste unabsichtliche Klick in die falsche Zelle. Und Schwupp hat man sich einen pulitzerverdächtigen Datenwert erzeugt, der mit der Realität herzlich wenig zu tun hat.
Dafür kann man Excel nicht verantwortlich machen. Es ist nicht für lückenlose Nachvollziehbarkeit gemacht. Tabellenkalkulationen haben in diesem Sinn kein dauerhaftes „Gedächtnis“ für die vorherigen Arbeitsschritte. Programmcode schon. Genauso ist ein Computerprogramm ja definiert, als exakte Abfolge von Arbeitsbefehlen.
Darum zwingt das Programmieren von seinem Wesen her zu der Art von Arbeiten, die sauberer Datenjournalismus eigentlich verlangt. Ich glaube, dass Programmieren vom Prinzip her die richtige Denkweise für DDJ ist. Eine Datenaufbereitung (und/oder Visualisierung), die programmiert ist, kann ich nicht nur selbst jederzeit auf Fehler überprüfen. Auch jeder andere kann das, wenn ich ihm meinen Code gebe.
Würde man sich dann auch noch trauen, den Code zu veröffentlichen, wäre das eine neue Stufe der (daten-)journalistischen Transparenz. Einfach nur die Daten online zu stellen (wie bisher), ist ja eigentlich Augenwischerei. Erst dem Verarbeitungsalgorithmus kann man ansehen, ob die Daten nicht (unabsichtlich) völlig verbogen wurden.
Das Ganze könnte einen schönen Nebeneffekt haben: Wir kämen weg von dieser befremdlichen Idee, unsere aus Transparenzgründen veröffentlichten Daten ausgerechnet bei Google abzulegen. Und damit im Schoß eines Unternehmens, das sich zwar allzu gerne als Vorreiter von „Open Data“ darstellt, aber eigentlich ganz andere, ökonomische Interessen hat.
Für die meisten Programmiersprachen eignen sich nämlich offene Datenformate viel besser, die dann gemeinsam mit dem Code auf dem (redaktions-)eigenen Server abgelegt werden könnten. Zum Beispiel als CSV in Unicode. Damit wäre man man nicht nur das Google-Problem los, sondern endlich auch das proprietäre XLS-Format (auch das neue XLSX ist nicht wirklich offen). Und unsere Daten wären auch dann noch lesbar, wenn Microsoft mit dem Flop von Office 2055 längst in die Pleite geritten ist.
Automatisieren – effizient arbeiten (Kosten sparen!)
Programmieren ist unter Journalisten auch deswegen so unbeliebt, weil es als Zeitfresser gilt. Das ist zu kurz gedacht. Und – wenn man über die Kosten von Arbeitszeit spricht – falsch gerechnet. Es stimmt zwar, dass Programmieren zu Beginn sehr aufwändig und herausfordernd ist. Aber irgendwann kommt der Punkt, wo sich das amortisiert.
Nicht ohne Grund verweist Sylke Gruhnwald vom NZZ-Team Reporter/Daten im Interview mit datenjournalist.de auf einen Leitsatz, der über ihrem Schreibtisch hängt: „If you have to do something more than once… automate.“ (Ursprünglich ist der Satz aus einem Vortrag von Paul Bradshaw )
„More than once“ kommt im DDJ eigentlich ständig vor: Ähnliche Datensätze bereinigen, ähnliche Tests machen, ähnliche Regionaldaten mit Polygonkoordinaten matchen, ähnliche (Geo)JSONs exportieren, ähnliche Plots oder Karten bauen…
Der Aufwand fürs Programmierenlernen relativiert sich übrigens, wenn man bedenkt, wie viel Zeit man als Nichtprogrammierer investieren muss, um sich in die vielen (immer wieder neuen) Online- und Offline-Tools einzuarbeiten. Warum nicht bei einer (offenen) Programmiersprache bleiben, in der es dank weltweiter Community für jeden denkbaren Fall die passenden Routinen bereits gibt?
Momentan klebt der DDJ unnötigerweise am Google-Tropf der „Killer-Tools“. Eine DDJ-Welt ohne Google fände ich wesentlich charmanter. Sie wäre ein Stück unabhängiger.
Und warum Javascript?
Für die Kernarbeit der Datenanalyse reicht eine einfache „Offline“-Sprache wir R oder Python. Eine davon zu lernen, halte ich für das Wichtigste.
Weil aber im DDJ so oft interaktiv online visualisiert wird (und sich DDJ auf diesem Gebiet so wunderbar profilieren kann), habe ich in meine persönliche Liste der DDJ-Programmierkenntnisse auch Online-Programmierung mit aufgenommen. Das heißt vor allem: Javascript. Denn das ist und bleibt die Sprache, die das Internet bewegt.
Nun ist die Webprogrammierung eine Welt für sich, und ich würde die endgültige Umsetzung einer Visualisierung fast immer einem Vollblutprogrammierer überlassen. Bei allem Respekt vor diesen Profis sollte man aber nicht vergessen, dass sie keine Journalisten sind. Es ist wichtig, dass Datenjournalisten und Webprogrammierer einigermaßen auf Augenhöhe miteinander reden können. Sonst ist es kein Wunder, dass wir einen DDJ erleben, der manchmal ohne Maß und Ziel von den technischen Möglichkeiten getrieben wird, aber nicht von journalistischen Kriterien. Damit sich das ändert, müssen sich beide anstrengen: Unsere Helden der IT ebenso wie wir. Für uns heißt das: Mehr vom (Web-)Programmieren verstehen.
Auf Twitter kam das Argument, dass Datenjournalisten vor allem gute Projektmanager sein müssten. Das ist sicher richtig. Aber was nutzt mir das beste Projektmanagement, wenn ich mich dabei auf die so überzeugend moderne D3-Programmierung meines IT-Profis einlasse, ohne z.B. zu wissen, dass das Ergebnis im Bundestag oder meiner Stadtverwaltung gar nicht aufrufbar ist? Um ein Programmierprojekt bei der Chefredaktion (oder dem Verlag) durchzuboxen, kann es auch extrem hilfreich sein, selbst einschätzen zu können, wie groß der Aufwand fürs Coden ist.
Wir müssen als Datenjournalisten nicht jede Frag der Webprogrammierung beantworten können. Aber wenn wir nicht genug davon verstehen, wissen wir nicht, welche Fragen wir unseren Programmierern stellen müssen.
Auch wo es keine Programmierer gibt, kann ein bisschen Javascript schon einen großen Unterschied machen: Man muss gar nicht so viel können, um eine Google-Karte mit Fusion Tables (Daten und Karte in Googles Händen) zu ersetzen durch eine einfache Karte mit Openlayers (Daten auf dem eigenen Server, Karte z.B. OpenStreetMap).
Die Weltsprache sprechen
Aus meiner Sicht hat Programmieren so viele Vorteile, dass ich mich manchmal frage, wo unsere großen Vorbehalte dagegen herkommen. Ich hege einen gewissen Verdacht, dass sie auch kulturell bedingt sind. Das quasimathematische Denken und Arbeiten in Algorithmen geht wahrscheinlich schwer mit der Schöngeistigkeit zusammen, in der sich nicht nur die Edelfedern unter den Journalisten zuhause fühlen.
Um so überraschter war ich, als ich kürzlich im Feuilleton der Süddeutschen Zeitung (Print!) vom 26./27. Juli 2014 eine ganze Doppelseite zum Programmieren fand, die einen bemerkenswerten Aufruf enthielt: „Sprachlos – warum man das Coden lernen sollte“.
Hauptargument des Textes: Programmieren sollte in einer computerisierten Welt völlig normal sein. Weil fast alles und jedes programmiert ist, ist Programmieren quasi die Weltsprache von heute. In Großbritannien steht ab diesem September angeblich Programmieren auf dem Lehrplan der Schulen, in Estland (dort wurde Skype erfunden), coden schon Erstklässler.
Ich habe mal gelernt, dass es die Aufgabe des Journalismus ist, unsere Wirklichkeit zu spiegeln bzw. zu reflektieren (nachdem wir selektiert und bewertet haben). Wenn Programme unsere Welt aber inzwischen so sehr prägen, sollte eigentlich jeder Journalist den „Globalen Code“ verstehen lernen.
Nicht, dass ich damit in absehbarer Zeit rechnen würde. Aber vielleicht stünde es uns Datenjournalisten gut, Vorreiter zu sein? Dann könnten wir auch unseren Kollegen aus den anderen Ressorts die Welt (noch) besser erklären.
0 Kommentare…