Af Ekstra Bladets redaktionelle udviklingsteam
(Hvis du ikke allerede har set/oplevet den fortælling, som dette blogindlæg handler om, kan du se den her).
De fleste har nok set The New York Times’ fantastiske digitale fortælling ‘Snow Fall’, der har været med til at sætte nye standarder for, hvordan fortællinger kan leveres på nettet. ‘Snow Fall’ er en fuldskærmsfortælling om et sneskred, der fandt sted i februar 2012, og i fortællingen tages læseren med på en imponerende rejse, og fortællingen bliver præsenteret og animeret, efterhånden som brugeren scroller sig igennem.
Det er naturligvis en fortælleteknik, som vi i Ekstra Bladets redaktionelle udviklingsteam (du kan læse mere om os her og se eksempler på vores arbejde) gerne ville eksperimentere med – lidt som Kristeligt Dagblad har gjort med deres ‘Syriens fordrevne’ – og samtidig ville vi gerne udnytte, at vi har udvikler-kompetencer i teamet, hvilket kan give fortællingen noget ekstra.
Så da Poul Madsen fortalte os, at en journalist var i gang med at skrive om hele gidselhistorien og gerne ville have os med ind over, så vi det som en god anledning til at kaste os ud i at sprænge rammerne for journalistik på ekstrabladet.dk – og måske endda, med lidt held, dansk netjournalistik generelt.
Her er det vigtigt at nævne, at der var 16 mennesker involveret i produktionen af ‘Snow Fall’. På det tidspunkt var vi 2 i teamet. Fra starten var det altså klart, at vi ikke kunne nå samme tekniske niveau og finesse.
Tidligt i forløbet tog vi en snak med journalisten, Kristian Kornø, for at høre om, hvad projektet gik ud på, og vi aftalte, at de tre, der skrev på det, ville sende en synopsis, når den var klar. En af de vigtigste ting, vi har lært i vores arbejde (vi har eksisteret siden februar 2012) er, at det er ekstremt vigtigt at have et tæt samarbejde med den/de journalister, der arbejder med indholdet. Det betød, at vi fik tilsendt hele kapitel 1 og den samlede synopsis, da den lå klar.
Efterhånden som arbejdet skred fremad, fik vi nys om, at der var en mulig løsladelse under opsejling. Det betød, at vi måtte rette ind efter kendsgerningerne, og den odiøse plan om at lave en interaktiv fortælling over hele gidseldramaet blev droppet. I stedet valgte vi at satse på det, der var beskrevet i det kapitel, vi havde fået tilsendt, og som ville gøre sig bedst som interaktiv fortælling: Kapringen.
I gang med arbejdet
Vi (i mellemtiden var vi blevet udvidet med en ekstra mand, vores avisgrafiker, så vi nu var tre i teamet) tog derfor et møde med journalisterne, og efter nogle afklaringer omkring formater og hvad, der kan lade sig gøre, blev vi enige om, at fokusere på kapringen og holde resten af fortællingen som en føljeton i avisen.
Vores grafiker, Mikkel, havde kort forinden været på en messe for nyhedsgrafik i Spanien. I vidensdelingens navn havde han præsenteret de mest interessante ting fra konferencen for resten af teamet, så vi havde nogle interessante ting derfra, vi kunne læne os op ad og blive inspireret af. Blandt andet El Mundos videoanimation lavet i anledning af tiåret for skibet Prestige, der sank og forårsagede en oliekatastrofe. Du kan også læse mere om det på Wikipedia. Både El Mundos video og vores fortælling foregik til søs, så det var oplagt at skæve til spanierne.
Herefter var det i gang. Vi fik den nyeste version af kapitel 1 tilsendt og gik i gang med at bygge en fortælling oven på de begivenheder, kapitlet handlede om. Dette blev gjort i et tæt samarbejde med Anders, der er udvikler, og Mikkel, der leverede grafikken – blandt andet en 3d-model af skibet, Leopard, og andre grafiske elementer, der kunne bruges.
Nøgleordene for vores produktion var ‘handling’, altså at brugeren skal aktiveres for at opleve den lineære fortælling og ikke blot sidde passiv og iagttage en række animationer, der udspiller sig på skærmen. Samtidig var det vigtigt at indbygge de grafiske elementer i fortællingen, således at skellet mellem grafik og tekst blev nedbrudt. Fortællingen, de visuelle virkemidler og grafikken skulle opleves som en naturlig helhed, og ikke som en artikel, der blot var lavet grafik til. Derfor besluttede vi, at brugeren aktivt skulle scrolle sig gennem fortællingen, som samtidig animerer sig for brugeren de steder, hvor det giver mening.
På den måde kunne vi sikre en naturlig sammensmeltning af tekst og grafik og samtidig indbygge animationer, uden at brugeren ville være nødt til at aktivere animationerne ved at klikke. Animationerne sker ganske simpelt løbende, mens brugeren scroller og læser.
Undervejs blev der tilføjet ting, mens andre blev taget fra – blandt andet ville vi gerne have tegnet Leopards planlagte og reelle rute, mens brugeren scrollede igennem præsentationen, men det viste sig umuligt indenfor den tidsramme, vi havde til rådighed, og blev derfor droppet igen.
Til de nysgerrige: Lidt om teknikken
Rent teknisk begrænsede vi vores brug til to JavaScript-biblioteker, jQuery og skrollr.js. Et bibliotek er i denne sammenhæng kort fortalt en masse funktioner og kode, som man kan referere til, når man programmerer – derved bliver det lettere og hurtigere at skrive koden, altså at få arbejdet gjort.
Begge biblioteker gjorde, at vi hurtigt fik en demo, og at vi kunne teste en række ideer. Det betød også, at den kode vi skrev, relativt nemt kunne overføres til ældre browsere som Microsoft Internet Explorer 8 – noget som ellers kan være lidt af en hovedpine.
Igennem hele arbejdet sørgede vi for at have demoer undervejs (vi arbejder tit under overskriften ‘Demo fast’), så det er let at rette ind, hvis noget skal rettes. Vi fik ikke vist produktionen til journalisterne så mange gange, som vi gerne ville, men de så den – og kom med rettelser – inden lanceringen, og det var trods alt det vigtigste, da tiden strammede til.
Mobil, hvad med mobil?
I forbindelse med testfasen (man skal altid teste sine ting – altid) opdagede vi, at den farligt flotte og lækre produktion fungerede knapt så godt på mobil. Det skyldtes, at skrollr.js-biblioteket har visse begrænsninger på mobiltelefoner (smartphones) og tablets, såsom Apples iPad. Det virker, men oplevelsen er ikke optimal hvis produktionen bliver stor. Animationerne går for langsomt, hvilket gør navigationen besværlig for brugeren – og dét går ikke.
Igen med tanke på deadline og det muliges kunst besluttede vi at bygge en separat mobilversion. I mobilversionen undlod vi at bruge skrollr.js, den nemme løsning, og holdt produktionen til ren HTML- og CSS-kode samt få linjer jQuery. HTML (HyperText Markup Language) er det sprog, hjemmesider oftest er skrevet i og CSS (Cascading Style Sheets) bestemmer, hvordan siden skal se ud, for eksempel farver, størrelser og skrifttype.
Derved lod vi mobiludgaven af fortællingen bestå udelukkende tekst og billeder. Det havde den positive effekt, at produktionen blev meget hurtigere at hente for brugerne på mobil, hvilket er en stor del af det at skabe en bedre oplevelse. Og da vi i mellemtiden var blevet klar over, at fortællingen skulle lanceres/publiceres en søndag, ville der være mange besøg fra netop mobiltelefoner.
Vi brugte programmeringssproget PHP til at indentificere hvilken enhed (computer eller mobil), brugeren sidder med. Det betyder, at vi kan sende brugeren til enten en mobil- eller desktop-/computer-version, så brugeren får den udgave, der passer til, om han/hun sidder foran en computer eller med en telefon. Det er normalt ikke en metode vi er tilhængere af i teamet, da vi forsøger at arbejder ud fra en resposive design tankegang (du kan læse retningslinjer for responsive web design), men vi så umiddelbart ikke andre løsninger indenfor tidsrammen.
Tablet-brugere blev sendt til desktopversionen, om end produktionen virkede lidt tung på tablet.
Vi ville, naturligvis, gerne have gjort mobilversionen endnu bedre, men vi må samtidig huske, at det er indholdet, der er det vigtigste. Godt indhold kan klare sig uden smarte former, men smarte former kan aldrig klare sig uden godt indhold.
Erfaringer
Igennem vores arbejde med en så anderledes og ny form for fortælling som kapringen, lærte vi en masse ting. Her er nogle af de vigtigste:
- Som altid, og måske lidt åbenlyst, er vi dybt afhængige af at være i tæt samarbejde med dem, der skriver/leverer selve indholdet. I dette tilfælde fik vi leveret hele kapitel 1 og en synopsis for, hvordan hele fortællingen skulle bygges op. Det er uundværligt materiale at have, inden man så meget som går i gang.
- Kommunikation, kommunikation, kommunikation. Vi oplevede flere gange, at publiceringen af vores produktion blev rykket – fordi den spillede tæt sammen med den føljeton, der skulle gøre i avisen. Derudover arbejdede vi noget af tiden også på vores produktion til Søllerødgadebomben, så der var risiko for prioritetsforvirring. Under det hele blev vi dog holdt orienteret – og var ikke bange for at spørge ind, hvis vi var i tvivl om noget. Det fungerede.
- Hele processen, på tværs af medier og platforme, er afhængig af, at der er en person, der udelukkende har som opgave at håndtere netop processen og vide, hvad der skal laves – og hvem der laver det.
- Vi endte med en produktion, der lidt levede sit eget liv – udenfor ekstrabladet.dk-rammerne. Det kan både være godt og skidt, men for os understregede det, at vi har behov for en skabelon og nogle rammer til disse ting, der netop sprænger rammerne. Det er et arbejde, vi skal i gang med nu. Blandt andet havde fortællingen sit eget domæne (‘php.ekstrabladet.dk’), det skal vi i hvert fald undgå fremover.
- Vi ville også gerne have holdt de visuelle virkemidler, animation etc., ‘i live’ lidt længere igennem fortællingen, men af tidshensyn blev det ikke denne gang – så det har vi stadig til gode 🙂
Historien fortsætter:
Du kan læse resten af historien om gidslerne her »