Fazit

img_1962

Nachdem die New York Times 2012 ihre lange multimediale Geschichte “Snowfall” veröffentlichte, galt ihre Form – das sogenannte Scrollytelling oder Longread – als Königsdisziplin des Online-Journalismus – ähnlich wie das Feature im Radio oder der Dokumentarfilm im Fernsehen. Viele Medien taten es der NYT daraufhin gleich und veröffentlichten ihre eigenen Scrollytellings.

Während manche Geschichten eigens programmiert und gestaltet wurden, haben einige Medienunternehmen und ihre eigenen Tools für das Erzählen multimedialer Geschichten entwickelt. Der WDR beispielsweise veröffentlichte “Pageflow”, ein Scrollytelling-Format, das einfach zu befüllen ist und das viele öffentlich-rechtliche Medien in Deutschland adaptiert haben.

FireShot Capture 16 - Onlinefeature_ » Sammlung von Multimedia-Reportage_ - http___onlinefeature.de_
Screenshot onlinefeature.de

Herausforderungen für Scrollytelling

Heute, vier Jahre nach der Veröffentlichung von Snowfall, gibt es längst neue Trends im Online-Journalismus: Datenjournalismus, Virtual Reality und 360 Grad-Videos, um nur drei zu nennen. Und dennoch hat das Scrollytelling längst nicht ausgedient, kann es doch, wenn es gut gemacht ist, auf Grund seiner Multimedialität neue Formate Integrieren. Dennoch stehen Redaktionen, die Scrollytellings umsetzen wollen heute vor Herausforderungen:

  1. Scrollytellings sind aufwändig: Klar, lange Geschichten sind immer (recherche-)aufwändig, hinzu kommt dramaturgische Arbeit und am Ende auch noch die Post-Produktion. Je mehr Inhalt die Geschichte hat und je mehr (multimediale) Komponenten, desto größer ist der Aufwand.
  2. Viele Scrollytellings sind teuer, was daran liegt, dass viele Geschichten eigens programmiert werden oder durch die Zusammenarbeit eines großen, interdisziplinären Teams entstehen.  Viele Mitarbeiter und ein langer Produktionszeitraum machen Scrollytellings kostspielig. An Snow Fall arbeiteten zum Beispiel 16 Personen.
  3. Vorhandene Tools & Formate sind wenig flexibel. Natürlich gibt es auch schon Scrollytellingtools, die den Aufwand reduzieren sollen, indem es einzelne „Container“ gibt, die der Redakteur nur noch mit Inhalt und entsprechenden Medien befüllen muss – Pageflow zum Beispiel. Das Reportagetool wurde von Codevise zusammen mit dem WDR entwickelt und steht frei zur Verfügung. Es bietet eine Oberfläche, auf der Journalisten ihre Videos, Bilder und Texte einspeisen können, ist also eine Art reduziertes CMS. Allerdings ähneln sich viele mit Pageflow generierte Scrollytellings sehr – das Programm lässt nur begrenzten Gestaltungsspielraum, das Playerdesign ist veraltet und die Bedienung des fertigen Produkts teilweise nicht intuitiv.
  4. Vorhandene Tools & Formate sind veraltet. S.o.

Unser Ziel

Am Medieninnovationszentrum Babelsberg (MIZ) haben wir in den vergangenen Monaten daran gearbeitet ein multimediales Longreadformat für das deutschlandweite Onlineradio detektor.fm zu entwickeln, das

  1. einfach umzusetzen ist – ohne dass der Redakteur die eierlegende Wollmilchsau aus Programmierer Grafiker und Journalist sein muss.
  2. flexibel ist, was die Anpassung an verschiedenste Themen und ihre Dramaturgie angeht,
  3. sich einfach weiterentwickeln lässt und somit auf Dauer zeitgemäß bleibt,
  4. und sich in die tägliche Redaktionsarbeit von detektor.fm integrieren lässt.
  5. Nicht nur detektor.fm soll von dem Tool profitieren – wir wollen Redaktionen generell Impulse geben, wie sie multimediale, intuitiv bedienbare Geschichten entwickeln können.

Unsere Schwerpunkte

Musikjournalismus

In den USA ist das Musikmagazin Pitchfork ein leuchtendes Beispiel für die Integration innovativer Formate. Es war 2012 das erste bekannte Medium, dass mit der “Coverstory” über Daft Punk ein musikjournalistisches Scrollytelling veröffentlichte. Es folgten zahlreiche weitere „Coverstorys“.

Pitchfork
Screenshot: Pitchfork-Coverstory über Aphex Twin

Im deutschen Musikjournalismus gibt es hingegen selbst heute kaum innovative Formate, was vielleicht daran liegt, dass ein Großteil der Musikindustrie das Internet lange Zeit nicht als Chance, sondern als Gefahr gesehen hat. Ein unklares Urheberrecht stellt Nutzer und Produzenten insbesondere in Deutschland dazu auch noch vor die Frage, wie sie mit Musik im Netz umgehen dürfen. Innovative Ideen können sich dadurch nur schwer etablieren.

Wir schaffen ein Format mit Fokus auf Musikthemen und möchten dadurch dazu beitragen, den Musikjournalismus in Deutschland voranzubringen und ihn von eher traditionellen Formaten lösen.

Fokus auf Audioinhalte

Detektor.fm ist ein Radiosender – und produziert damit per se viel Audioinhalt. Dass soll auch beim neuen Scrollytellingformat nicht anders sein. Wir wollen Multimedia – aber mit einem Fokus auf Audio.

Der vorhandene Audioplayer von Detektor erwies sich als funktional zum Abspielen einzelner Interviews, hat allerdings nicht die Funktionen, die wir uns beim Einbetten in eine Geschichte wünschten. Am Anfang standen wir also auch vor der Frage: Wie kann ich welche Audios am besten integrieren, sodass sie der Geschichte an der entsprechenden Stelle einen Mehrwert bieten – und welche Tools eignen sich dafür?

Was soll ein gutes multimediales Format können?

Unser Ziel wares, nicht nicht nur einen elendig langen Artikel zu haben, durch den man sich durchscrollen muss, sondern Material- und Formenvielfalt zu haben. D.h.: Nicht nur Scrollen, sondern auch Klicken, Wischen – und das nicht nur von oben nach unten, sondern auch mal nach links und rechts. Vor allem soll es auch mobil gut funktionieren,  denn schon heute wischen die Nutzer eher auf ihrem mobilen Gerät, als auf dem Desktopcomputer zu scrollen.

Ein Format zum Geschichtenerzählen sollte daher flexibel sein – einerseits, was die Geschichte und ihre inhaltlichen Komponenten angeht, andererseits, was seine Weiterentwicklung angeht.

Wichtig ist uns dabei, dass wir Geschichten erzählen, in denen bestehende (Audio-)Inhalte nicht einfach “zweitverwertet” werden – den Eindruck erweckten viele Pageflows aus Deutschland – sondern dass wir eine Geschichte in der Form erzählen, die sie benötigt. Sprich: Wir wollen Audios und andere Medien dann benutzen, wenn sie einen Mehrwert bieten, nicht aus Selbstzweck.

Unsere Herangehensweise

Zunächst haben wir viel, viel recherchiert, wobei der Fokus auf anderen Scrollytellings, Scrollytelling-Formaten und Tools lag.

Scrollytelling und Tools

Dafür haben wir uns als allererstes haufenweise veröffentlichte Scrollytellings angeschaut und Fachartikel über Scrollytellings gelesen, um das zu extrahieren, was uns gefällt – und was nicht. So konnten wir herausstellen, was für uns ein “gutes Scrollytelling” ist (nachzulesen hier) und im nächsten Schritt genau festlegen, welche Funktionen unser eigenes Format haben soll.

Im zweiten Schritt haben wir uns auf die Suche nach Tools gemacht. Es gibt jede Menge speziell für WordPress und noch mehr, die sich generell über HTML einfügen lassen. Die Schwierigkeit bestand also darin, herauszufinden welche Tools sich für welche Funktionen eignen – und welche die besten sind. Viele gute Tools haben wir bei Bleiwüsten gefunden, einer Seite, auf der wöchentlich neue Storytelling-Programme für Journalisten vorgestellt werden.

Dummy & Dummy-Testing

Getestet haben wir die ausgewählten Tools schließlich im nächsten Schritt, der einen weiteren “Meilenstein” in unserer Projektlaufzeit dargestellt hat: Der Dummy (nachzulesen hier).

Screenshot der Umfrage zum Dummy
Screenshot der Umfrage zum Dummy

Genauso wichtig wie der Dummy war schließlich das Dummy-Testing, mit dem wir heraus- finden wollten, wie unser Dummy ankommt. Wir haben ihn nicht nur von detektor.fm und unseren Kollegen am MIZ begutachten lassen, sondern auch von Nutzern, die bisher nichts mit dem Projekt zu tun hatten. Nach einem kleinen Hörer-Aufruf von detektor.fm füllten schließlich 25 Personen unseren Fragebogen zum Dummy aus und gaben uns wertvolles Feedback (nachzulesen hier), das wir nun für die Verwendung der ersten richtigen Ausgabe verwenden konnten, dem vorerst letzten, wohl größten “Meilenstein”: Der ersten multimedialen geschichte bei geschichten.detektor.fm

Unser Ergebnis

… ist in unserer ersten Geschichte zu sehen: „Pop ist kein weißer, heterosexueller Mann“ bei geschichten.detektor.fm.

titelbild

Wir haben Video- und Audio-Interviews mit MusikerInnen, ExpertInnen und Frauen und Männern aus der Musikbranche geführt, Daten und Fakten recherchiert, zusammen zu tragen, in unseren roten Faden gebracht – und schließlich mit Hilfe unseres Formates in eine Form gegossen.

Wie das gelaufen ist, könnt ihr hier nachlesen.

Entscheidungen

Wir nutzen WordPress.

WordPress ist frei verfügbar und vielen Journalisten bekannt. Es ist intuitiv und einfach zu bedienen und dank vieler verschiedener Themes und Plugins flexibel im Look. In einen WordPress-Beitrag lassen sich außerdem viele verschiedene Elemente einfügen: 1. Schon in WordPress vorhandene Komponenten wie Bilder, Zitate etc. 2. Durch Plugins einfügbare Komponenten wie Galerien oder Slides und 3. Externe Tools und Medien wie Infogram, Thinglink und diverse soziale Medien

Wir nutzen verschiedene Plugins.

AesopDas Plugin Aesop-Story-Engine macht es Autoren einfach, verschiedene Elemente, sogenannte „Story-Components“ für die eigene WordPress-Geschichte zu nutzen, z.B. Maps, Galerien, Timeline, Parallax-Bilder, Rand-Zitate, Vorher-Nachher-Bilder u.v.m.

Slider Revolution:  Slider Revolution ermöglicht die Erstellung von “Slidern”. Hiermit kannst du deiner Geschichte neben der vertikalen Erzähllinie eine oder mehrere horizontale hinzufügen. Zudem können verschiedene Medien wie Videos, Text, Bilder und Audios (via Soundcite) integriert werden.

Wir nutzen viele verschiedene Tools.

  • für Audios: Slider Revolution
  • für Diagramme: Infogram
  • für Umfragen: Playbuzz
  • für annotierte Bilder: Thinglink
allsliders
Screenshot: Slider Revolution im Backend

Wir entwickeln Tools.

  • einen Audioplayer mit Kapiteln
  • eine Infobox

Die Integration von Audio

Unser Fokus im Longread soll, wie erwähnt, auf dem Medium “Audio” liegen. Da sich der vorhandene Audioplayer von Detektor nicht wirklich als Komponente einer Geschichte eignet, sondern eher zum Abspielen einzelner Beiträge, haben wir erst mit Hilfe von Design Thinking herausgefunden, was der für uns ideale Audioplayer für Funktionen braucht und uns dann auf die Recherche nach einem geeigneten Modell gemacht.

Was wir wollten – z.B. Kapitelmarker, die Möglichkeit Text und Bilder an die verschiedenen Kapitel zu heften, Teilbarkeit, Anpassbarkeit an den Look der Geschichte – gab es allerdings nicht wirklich auf dem Markt. Die meisten Audioplayer sind nicht sehr innovativ. Positivbeispiele sind Soundcite oder Tapewrite, allerdings sind beide Player kaum oder gar nicht flexibel und anpassbar.

Die Lösung: Wir programmieren uns unseren eigenen Audioplayer – bzw. wir bringen unsere Ideen zum Programmierer von detektor.fm, Torsten Baldes von den Medienfreunden.

Der neue Audioplayer

Nicht alle Ideen konnten umgesetzt werden. Beispielsweise war die Funktion, Text mit verschiedenen Kapiteln zu verlinken, nicht möglich. Für Bilder ließ es sich allerdings umsetzen. Zudem ist es nun möglich überhaupt Kapitel anzulegen. Über Kapitelmarker sind diese anwählbar, sowie über ein aufklappbares Kapitelmenü, in dem schließlich auch die Kapitelüberschriften zu sehen sind.

tessplayer
Screenshot: Kapitel-Audioplayer

Soundcite

Neben dem Audioplayer wollten wir noch eine Möglichkeit, kürzere Audios, wie O-Töne, in der Geschichte elegant unterzubringen. Mit Soundcite haben wir ein sehr geeignetes Tool gefunden, das es möglich macht, Audios direkt im Fließtext zu hinterlegen.

soundcite
Screenshot: Soundcite hinterlegt Fließtext mit Audios

Welche Probleme haben sich bei der Entwicklung ergeben?

Die größte Herausforderung lag darin, dass wir keine/n ProgrammiererIn direkt im Team hatten. Torsten Baldes von den Medienfreunden, hat zwar unsere Ideen umgesetzt – oder das, was von unseren Ideen umsetzbar war – bei der Entwicklung hat uns aber die Expertise und Erfahrung eines Programmierers sowie der regelmäßige Austausch mit ihm gefehlt. Gerade in Anbetracht der Entwicklung innovativer Formate ist das enorm wichtig – das hat uns nun die Erfahrung gelehrt.

Weitere Probleme waren personalbedingt. Zwei der drei Kolleginnen sind krankheitsbedingt nach drei bzw. vier Monaten ausgefallen. Das Projekt musste zunächst durch eine Person weitergeführt werden, Isabelle Klein, Ende September kam dann ein neuer Redakteur, André Beyer, mit ins Boot.

Gerade in einem so kleinen Team wie einem Dreierteam sind solche Ausfälle nur schwer abzufangen, was seinerseits sehr viel Koordinationsarbeit erfordert. Es gabe sehr viel Aufgaben, die nun statt von drei von einer Person übernommen werden mussten. Hinzu kam das Einarbeiten und Anweisen des neuen Redakteurs, was insgesamt nur mit viel mehr Präsenzzeit zu stemmen war, als angesetzt war – auch wenn das Projekt einen Monat verlängert wurde.

Andererseits war es schwierig alle Ideen und im Konsens getragenen Entscheidungen alleine weiterzuführen. Bei aller Organisationsarbeit blieb die kreative Atmosphäre und der Innovationsgeist leider auf der Strecke. Innovationen lassen sich einfach besser im Team und nicht unter großer Arbeitslast entwickeln.

Wie schaffen wir die Integration in den Redaktionsalltag?

Damit detektor.fm das von uns entwickelte Format einfach in den Redaktionsalltag integrieren kann, haben wir einen Leitfaden erstellt, indem ausführlich und Schritt für Schritt erklärt wird, wie ein Beitrag erstellt und mit verschiedenen Komponenten erzählt werden kann.

Wie kann ich mein eigenes Scrollytelling entwickeln?

Darüber Hinaus haben wir ein How-To-Do “für alle” auf unserem Blog veröffentlicht, das als Anleitung für einzelne Journalisten dienen soll, sich aber auch an Redaktionen wendet, die nicht die finanziellen Mittel für eigens programmierte Geschichten aufwenden können oder wollen – und die unser Format in abgewandelter Form benutzen wollen.

Hier geht’s zu How-to-do.

Welche Herausforderungen gibt es noch?

Es gibt jedoch ein paar Voraussetzungen ohne die es nicht geht.

  • Die an der Geschichte arbeitenden müssen keine Programmierer, aber technische Kenntnisse mitbringen: HTML-Grundkenntnisse sollte man mitbringen, ein Gespür für Ästhetik und Anordnung auch, sowie die Ausdauer und Freude daran, verschiedene Elemente auszuprobieren und der Story nach anzupassen.
  • Im Team arbeiten hilft: Ein Longread lässt sich immer gut im Team erstellen. Es muss natürlich nicht zu zweit getextet werden, aber gerade beim Einpflegen, Redigieren und Überprüfen auf verschiedenen Geräten usw. ist es von erheblichem Vorteil, wenn ihr das nicht alleine macht, sondern im Team. Das erspart Zeit und Nerven – gerade wenn der Autor der Story zwar ein hervorragender Autor ist, aber technisch nicht so versiert.
  • Die Story sollte schon im Vorhinein als Longread gedacht werden – und nicht vorhandenes Material “zweitverwerten”: Die einsetzbaren Elemente, Tools und Medien sollte man schon vor der Entstehung der Story zu kennen und somit sinnvoll einzusetzen. Klar, die Form folgt der Story, aber wer im Vorhinein weiß, welche Elemente er verwenden kann, wird sie später auch besser einsetzen können. Es ist nicht nur ungeschickt, die Story im Nachhinein in eine Form zu pressen bzw. in verschiedenen Elemente zu gießen, sondern meist fällt das auch auf.
  • Zeit einplanen: Neben der Recherche, dem Schneiden und Texten fällt, wie schon erwähnt, auch noch weiterer Aufwand an – das ganze in die Online-Form zu bringen, wir nennen das mal Post-Production. Die einzuplanen – plus einem zusätzlichen Puffer – ist extrem wichtig! Eine Story kann noch so schön geschrieben sein, wenn die Elemente nicht funktionieren oder blöd aussehen. Das ist nichts, was man „auf den letzten Drücker“ oder kurz vor Abgabefrist macht. Es ist einfach ein großer Teil der Arbeit
  • Das Format Weiterentwickeln: Damit das Format nicht in einem jahr schon veraltet ist, sollte man, was Tools angeht, auf dem Laufenden bleiben. So kann das Format ständig weiterentwickelt werden. Eine gute Quelle für neue, spannende Tools ist bleiwüsten.de.

 

Leave a Comment