Näytetään tekstit, joissa on tunniste PlusDesk. Näytä kaikki tekstit
Näytetään tekstit, joissa on tunniste PlusDesk. Näytä kaikki tekstit

maanantai 9. heinäkuuta 2018

Ylen Eläkepeli – mitä tehtiin?

Julkaisimme Ylellä 1.7. Eläkepelin (Kuva 1).

Ylen Eläkepelin tarkoitus oli antaa lukijoille ymmärrystä siitä millä asioilla on vaikutusta tulevaan eläkekarttumaan. (Kuva 1)
Lähtökohtana meillä olivat Eläketurvakeskuksen (ETK) pitkän aikavälin laskelmat. Raportissa oli arvioitu kuuden eri muuttujan kehityksen vaikutusta eläkkeisiin. Nämä muuttujat olivat:
  • syntyvyys
  • kuolevuus
  • työllisyys
  • maahanmuutto
  • eläkesijoitusten tuotto
  • ansiotason kasvu
Näitä muuttujia oli arvioitu todennäköisimmän skenaarion lisäksi myös mahdollisessa positiivisessa ja negatiivisessa skenaariossa. Eli esimerkiksi työttömyyden osalta todennäköinen skenaario lähti siitä, että työllisyys pysyy noin nykyisessä 72 %:ssa kun taas negatiivinen skenaario oletti, että työllisyys laskee alle 70 %:n. Positiivinen kehitys taas oletti, että työllisyys kehittyisi erityisen myönteisesti. Skenaarioille oli laskettu euromääräiset vaikutusarviot eläkkeiden suuruuteen, mutta lisäksi myös miten kehitys vaikuttaa työeläkemaksuihin.

Nämä tiedot oli laskettu kaikille muuttujille kaikissa skenaarioissa aina vuoteen 2085 asti. Raportti oli siis erittäin kattava ja perusteellinen katsaus tulevaisuuteen nykytiedon valossa.

Meillä oli ajatus, että tästä olisi mahdollista rakentaa jonkinlainen journalistinen peli tai kone, joka kasvattaisi lukijoiden ymmärrystä eläkkeiden muodostumisesta ja siitä mitkä asiat vaikuttavat eläkkeen suuruuteen. Toisaalta yksi jo projektin alkuvaiheessa meitä puhututtanut asia oli tulevatko nykyiset 20–40-vuotiaat ikinä saamaan eläkettä.

"Saanko minä koskaan eläkettä"

Tämänkaltaisille projekteille, joissa ollaan luomassa jotain täysin uutta, on ominaista, että ajatukset ja ymmärrys siitä mitä ollaan tekemässä poikkoilevat hyvin paljon. Esimerkiksi välillä pidimme keskiössä työeläkemaksujen muutosta ja toisaalta välillä olimme rakentamassa peliä, jossa pelaaja kulkisi läpi vuosikymmenten kohti eläkkeelle pääsyään. Nämä ideat korvaantuivat projektin kuluessa toisilla tai ne sulautuivat osaksi muita ideoita.

Meitä oli ydintiimissä tekemässä Eläkepeliä 4–5 henkilöä, graafinen suunnittelija, toimittaja, 1–2 tuottajaa ja allekirjoittanut koodarina. Ja kun ideat vaihtuivat oli välillä haastavaa pitää kaikki kartalla siitä mitä ollaan jossain pienemmässä ryhmässä keskusteltu. Toisaalta myös aika ja muut yhtäaikaiset projektit tuovat haastetta kun ei ole mahdollista keskittyä tekemään vain yhtä asiaa. Tulee tilanteita, että "mitäs me nyt oltiinkaan tekemässä?".
  • Voittava resepti: koodari + graafikko + toimittaja (+tuottaja)
Näistä syistä oli myös hyvin haastavaa sovittaa sisältö, visuaalisuus ja tekniikka yhteen kun ajatus sitä mikä olisi lopputuote vaihteli useasti. Piirsimme todella paljon erilaisia havainnekuvia paperille ja muistilapuille, jotta ymmärtäisimme paremmin toisiamme ja ylipäänsä sitä miltä lopullinen tuote voisi näyttää. Nämä eivät kuitenkaan korvanneet tietokoneella selattavissa olevaa prototyyppiä, joka vasta avasi silmämme siitä miltä kokonaisuus tulisi näyttämään ja esimerkiksi miten tekstit tulisi kirjoittaa, jotta kokonaisuus etenisi jouhevasti.

Pyrimme yleensä PlusDeskissä rakentamaan mahdollisimman aikaisessa vaiheessa jonkinlaisen klikattavan demon, koska keskustelu sen äärellä on paljon helpompaa kun kaikki voivat näprätä sitä puhelimillaan. Tässä projektissa ongelma vain oli, että sisältö oli riippuvainen visuaalisuudesta ja toisaalta visuaalisuus oli riippuvainen sisällöstä. Ja tekniikka eli omaa elämäänsä näiden kahden rinnalla. Tavallaan konkreettinen tekninen demo oli mahdollista rakentaa vasta kun olimme lukinneet sisällölliset asiat, mutta sisällöllisten asioiden lukitseminen oli haastavaa ilman konkreettista teknistä demoa.



Lopputuotteessa keskityimme kuuden muuttujan euromääräisiin vaikutuksiin. Vaihtoehtoina olisi ollut kuvata vaikutusta työeläkemaksuun tai eläkkeen suuruus suhteessa palkkoihin. Euromääräinen vaikutus oli lopulta hyvin looginen vaihtoehto, koska eurot ovat ymmärrettävimmät. Laitoimme peliin mukaan myös vaikutuksen työeläkemaksuun, koska se meillä oli, mutta jälkikäteen ajatellen pelin viesti olisi ollut yksinkertaisempi jos tuloksena jokaisen valinnan jälkeen olisi tullut vain yksi arvo.

Omasta kokemuksesta usein datajutuissa ja datajournalismissa sorrutaan siihen, että ei osata rajata ja valita kiinnostavinta näkökulmaa. Näytetään lukijoille liikaa dataa, koska meillä sitä nyt kerrankin on. Ja kun tavallaan lopputuote sisältää liikaa informaatiota, tulee jutusta liian monimutkainen ymmärtää ihmiselle, joka on tullut uutissivuille viettämään aikaa. Etenkin monimutkaisten ilmiöiden kuvaamisessa tulisi kiinnittää huomiota siihen mikä on ensimmäinen tunnelma ja tuntuma kun juttuun tullaan. Onko sisältö sellaista, jonka lukija ymmärtää ja johon hän haluaa syventyä.

Tämä näkyy hyvin myös tämänkaltaiten pelien käytössä. Tutkimme sitä miten pitkälle ihmiset, jotka artikkelin avaavat etenevät pelissä. Tulokset näyttivät, että ihan pelin alkuvaiheessa eli muutaman ensimmäisen valinnan aikana menetetään todella suuri osa lukijoista. Eli olisimme voineet panostaa vielä enemmän pelin alkuun ja siihen, että ihminen jäisi pelin pariin. Positiivista kuitenkin oli, että jos lukija eteni pelissä pidemmälle hän erittäin todennäköisesti eteni sen myös loppuun asti. Eli tavallaan jos lukija pääsi yli alkujärkytyksestä hän koki jutun ja pelin erittäin mielekkäänä.



Projekti oli erittäin mielenkiintoinen ja jutusta saatiin paljon positiivista palautetta. Jutun koettiin antaneen ymmärrystä monimutkaisesta ilmiöstä, joka olikin tavoitteena. Negatiivinen palaute liittyi pitkälti siihen, että peli antoi tuloksia, jotka eivät yksilön kohdalla tuntuneet todellisilta. Tähdensimmekin siksi juttuun julkaisupäivänä, että luvut ovat ikäluokan laskennallisia keskiarvoja eivätkä suoraan kerro yksilön tulevasta eläkkeestä.

tiistai 15. marraskuuta 2016

Tarjoilu ja puhutteleva kerronta – hyvän datajutun anatomia?


Julkaisimme 5. marraskuuta jutun:

Viikkoa aiemmin Helsingin Sanomat julkaisi jutun:
Molemmat jutut käsittelivät eläkeuudistusta ja molemmissa jutuissa oli laskuri, johon käyttäjä pystyi syöttämään omat tietonsa, joiden perusteella laskettiin eläkeikä. Jutut olivat siis datan ja kerrontatavan näkökulmasta samankaltaiset ja siksi niitä on mielenkiintoista verrata.

Kun juttuja katsotaan Facebook-lukujen valossa ne näyttäytyivät hyvin eri tavalla. Ylen juttu keräsi 55 347 Facebook-toimintoa, HS:n juttu 175 toimintoa. Pelkästään Facebook-lukujen valossa Ylen juttu, vaikkakin julkaistu viikko HS:n jutun jälkeen, oli yli 300 kertaa suositumpi. Miksi Ylen juttu oli suositumpi?

Yritän vastata tähän kysymykseen etenkin laskurin näkökulmasta. Jutun leviämiseen ja suosioon vaikuttavat toki merkittävästi myös jutun otsikko, tekstisisältö sekä julkaisuajankohta, mutta jätän nämä näkökulmat tässä huomiomatta ja keskityn laskuriin.

Sijoittelu


Olemme Ylellä omaksuneet käytännön, jossa tämän kaltaiset interaktiiviset toteutukset – kuten laskurit – sijoitetaan jutun alkuun, heti otsikon, ingressin ja pääkuvan jälkeen. Poikkeamme tästä käytännöstä oikeastaan vain pitkien listojen yhteydessä. Mielestämme, etenkin kun otsikossa on viittaus laskuriin, tulee laskurin olla heti jutun kärkenä.

HS:n jutussa laskuri oli sijoitettu jutun leipätekstin sekaan jutun keskivaiheille. Näemme, että lukijan – joka tulee käyttämään nimen omaan otsikon perusteella laskuria – kannalta on hankalaa kun laskuri pitää etsiä jutun lomasta. Emme usko, eikä meillä ole dataa joka osoittaisi, että juttua luettaisiin esimerkiksi enemmän kun laskuri sijoitetaan leipätekstin lomaan. Ajattelemme mieluummin, että kun lukija saa hänelle mielenkiintoista ja personoitua tietoa heti jutun alussa kiinnostuu hän lukemaan tätä kautta myös itse jutun.

Laita laskuri jutun ensimmäiseksi elementiksi, se on hyvää palvelua ja lunastat otsikossa tehdyn lupauksen.

Puhuttelu ja personointi


Yle ja HS hyödynsivät molemmat laskureissaan Eläketurvakeskukselta saatuja laskelmia. Oleellista oli siis pukea tämä viranomaisilta saatu tieto kiinnostavaan muotoon. Tämänkaltaisissa laskureissa on hyvin tärkeää miten ihmisiä puhutellaan ja minkälaista tietoa heille annetaan. Kuvissa 1 ja 2 nähdään Ylen ja HS:n versio. Kiinnittäisin itse huomiota ainakiin seuraaviin asioihin:

  • Yle: "Syntymävuosi ja syntymäkuukausi" vs. HS: "Kerro, milloin olet syntynyt"
  • Yle: "Pääset eläkkeelle 34 vuoden 10 kuukauden kuluttua" vs. HS: "Tässä iässä voit aikaisintaan jäädä eläkkeelle 66 v ja 11 kk"
  • Yle: "Täyden eläkkeen saat heinäkuussa 2054" vs. HS: "Tavoiteikäsi eläkkeelle jäämiselle on 69 v 9 kk"

Ensinnäkin syntymäkuukauden kysyminen tekee laskurin tuloksista huomattavasti henkilökohtaisempia, ja lukijalle tulee olo, että laskuri selkeästi kertoo minulle jotain. Toiseksi eläkkeellepääsyhetken ilmaisusta tulee huomattavasti konkreettisempi kun kerrotaan montako vuotta ja kuukautta eläkkeellepääsyyn on vielä aikaa. Kolmanneksi on hyvä välttää byrokraattiselta maistuvia termejä kuten "tavoite-eläkeikä", jotka eivät ole lukijalle tuttuja.

Yksittäisenä huomiona myös Ylen laskuriin toteutettu aikalaskuri, joka laski päiviä, tunteja, minuutteja ja sekunteja kohti eläkettä koettiin hauskana lisänä, joka toi lisäarvoa ja teki saadusta tuloksesta erityisen henkilökohtaisen.

Tee toteutuksesta mahdollisimman henkilökohtainen, samaistuttava ja käytä arkikieltä, tekniset yksityiskohdat ja termit voit avata jutussa.

Kuvankaappaus Ylen eläkelaskurista. (Kuva 1)
Kuvankaappaus HS:n eläkelaskurista. (Kuva 2)

Tuloksen jakaminen


Ylen laskuriin oli toteutettu normaalien artikkelin jakotoiminnallisuuksien lisäksi mahdollisuus jakaa oma henkilökohtainen tulos Facebookissa ja Twitterissä (Kuva 3 ja Kuva 4). HS:n laskurissa tällaista mahdollisuutta ei ollut.

Personoitu jakomahdollisuus edistää jutun leviämistä muille alustoille. Sosiaalisen median kautta juttu löytää helposti moninkertaisesti yleisöjä verrattuna, että juttua levitetään vain oman uutispalvelun etusivun kautta. Havaintojemme mukaan jutun suosio korreloi suoraan sen kanssa miten paljon siihen tullaan suhteellisesti sosiaalisen median kautta. Toisi nsanoen ei ole enää olemassa hittiä ilman merkittävää sosiaalisen median presenssiä.

Anna lukijalle mahdollisuus jakaa tulos, ihmiset haluavat jakaa itseään koskevia harmittomia tietoja sosiaalisessa mediassa, joka taas synnyttää keskustelua aiheesta.

Ylen jutussa tulos oli mahdollista jakaa Facebookissa. (Kuva 3)
Ylen jutussa tulos oli mahdollista jakaa Twitterissä. (Kuva 4)

Lisäarvon tuottaminen


On oleellista, että laskuri pystyy tarjoamaan jotain sellaista journalistista lisäarvoa, joka ei ole helposti ihmisten saatavilla muuten. HS:n tekemän laskurin tiedot ovat yhtälailla katsottavissa suoraan Eläketurvakeskuksen toteuttamasta laskurista (Kuva 5). Ylen laskurissa oltiin eläkeellepääsyiän lisäksi laskettu montako vuotta siihen vielä on sekä kerrottiin montako vuotta elinaikaodotteen mukaan eläkkeellä ehtii elää. Ylen laskuri siis tuotti lisäsarvoa verrattuna olemassa oleviin toteutuksiin ja siten palveli lukijaa. Kaikki tiedot olivat olemassa, mutta ne paketoitiin lukijalle lisäarvoa tuottavalla tavalla.

Kerro jotain uutta ja yllättävää, pienetkin näkökulmaerot tekevät ihmeitä ymmärrettävyydelle ja viestin välittymiselle.

Kuvankaappaus Eläkeuudistus-sivustolta. (Kuva 5)



Olin itse keskeisessä roolissa tekemässä Ylen juttua.

perjantai 22. heinäkuuta 2016

Kohti parempia uutissisältöjä – PlusDeskin havaintoja

Meillä on PlusDeskissä tavoitteena kehittää omaa, mutta koko Yle Uutisten, kerrontaa suuntaan, joka houkuttelee enemmän ja uusia yleisöjä sisältöjemme pariin. Haluamme myös, että jutuissa vietetään enemmän aikaa. Yle Uutiset on siirtynyt sivulatausten mittauksesta sivuilla vietettävän kokonaisajan mittaukseen.

Olemme PlusDeskissä keränneet havaintoja, miten lukijoita voidaan sitouttaa sisältöihin. Kokoan tässä muutamia havaintojamme, joita olemme hiljaisena tietoa keränneet toimintamme aikan. Havainnot eivät ole itseisarvoja vaan esitystapa täytyy aina miettiä sisällön ehdoilla. On kuitenkin huomioitavaa, että samansuuntaisia huomiota tulee myös ulkomailta.

Älä piilota, tuo esille


Ensimmäinen havainto on, että sisältöä ei kannata piilottaa klikkauksen taakse. Sanotaan, että jos käyttäjän täytyy klikata sen täytyy tapahtua jotain todella poikkeuksellista. Internetissä käyttäjän näkökulmasta vierittäminen on halpaa, klikkaukset ovat kalliita.

Pitkissä jutuissa tämä näkyy niin, että teemme mieluummin juttuja joita vieritetään "Kauniista Pelistä Tuli Ruma Mafia – Kuinka Pomot Tahrasivat Jalkapallon" kuin juttuja, jotka on jaettu välilehdillä alisivuiksi "Venäjän varjo Walesin taivaalla – sota Ukrainassa sähköistää Naton huippukokouksen". Lukijan on vaivattomampaa selata juttua vierittämällä kuin klikata välilehtiä. On myös niin, että kun juttu jaetaan välilehtiin täytyy lukijan hoksata, että juttu jatkuu vielä ja että jossain on navigaatio. Usein kuitenkin rakennamme pitkiin juttuihin jonkinlaisen sisäisen navigaation tukeaksemme jutun rakennetta kuten Fifa-jutussa on tehty. Rakenne tukee lukijan ymmärrystä ja toimii siten sisällysluettelona.

Älä piilota tietoa sivutuksen taakse

Laskureissa ja lomakkeissa jos meillä on meillä on jokin tulos Riittääkö nettisi nopeus? – Katso miten mobiiliyhteys toimii kunnassasi" on hyvä näyttää heti jokin esimerkki. Mobiiliyhteysjutussa olisi voinut olla näkyvillä suoraan jonkin kaupungin tiedot. Tällöin lukijalle olisi heti syntynyt kuva siitä mitä tietoja lomakkeeseen tulee syöttää ja mitä tietoja hän saa "Katso Ylen homekoulukoneesta, onko teidän koulussanne ollut sisäilmaongelmia". On kuitenkin tärkeää, ettei lukijalle välity oletusvalinnasta sellaista mielikuvaa, etteikö tietoja voisi muuttaa.

Anna esimerkkinäkymä

Grafiikoiden osalta meille tulee usein pyyntöjä jos osan grafiikan tiedoista voisi laittaa klikkauksen taakse. Kartoissa tämä "tarve" korostuu. Halutaan esimerkiksi asettaa kartalle pisteitä, joita klikkaamalla kohteesta saisi lisää tietoa. Näissä tilanteissa pyrimme ohjeistamaan, että jos vain mitenkään on sisällöllisesti mahdollista laitettaisiin kaikki tiedot suoraan näkyviin eikä mitään piilotettaisi klikkauksen taakse. Jos tämä ei ole mahdollista pyrimme pohtimaan vielä jos grafiikan voisi jakaa useampaan osaan. Analytiikkamme kertoo hyvin yksiselitteisesti, että aina kun vaadimme lukijaa valitsemaan menetämme suuren osan yleisöistä. Se, että teemme valintoja sisällön suhteen ja näytämme vain oleellisimmat tiedot on journalistista valintaa, jota meidän toimituksena oletataan tekevän lukijan puolesta.

Älä jätä journalistista valintaa lukijalle

Interaktio ei toki ole kiellettyä. Toisissa jutuissa se on välttämätöntä ja olennaista "Paljonko lainaa, montako neliötä? Asuntokone kertoo, missä sinulla on varaa asua". Esimerkiksi kun dataa on paljon täytyy sen selaamiseen rakentaa jonkinlainen käyttöliittymä. Niiden rakentamisessakin kuitenkin valintojen määrä kannattaa pyrkiä minimoimaan ja pyrkiä tarjoamaan lukijalle mahdollisimman valmis kokonaisuus. Itse mukailen tällaisten datakäyttöliittymien suunnittelussa Shneidermanin mantraa:

"Quick overview, Details-on-demand"

Eli pyrimme antamaan lukijalle nopean kokonaiskuvan ja ymmärryksen asiasta. Asuntokoneessa tämä toteutuu kartan värityksellä, joka tukee ymmärrystä siitä millä alueilla asuntojen hinnat ovat korkeita. Jos lukija on kiinnostunut hänellä on mahdollisuus syventyä aineistoon tarkemmin muuttamalla kartan rajausta, tarkastelemalla yksittäisten alueiden hintoja ja vertaamalla alueiden hintoja suhteessa omaan palkkatasoonsa. Nämä lisävalinnat lisäävät ymmärrystä aiheesta, mutta pelkästä alkunäkymästä lukija saa esimerkiksi kuvan siitä, että pääkaupunkiseudulla asuntojen hinnat ovat ympäröiviä alueita korkeampia. Toinen hyvä käyttöliittymien suunnittelussa hyödynnettävä preiaate on KISS.

Kiinnitä huomiota jutun rakenteeseen


Toinen – etenkin pidempiin juttuihin liittyvä havainto – on, että kiinnitä huomiota jutun silmäiltävyyteen ja visuaaliseen asetteluun. Pelkkä hyvä teksti tuntuu lukijasta helposti raskaalta jos jutussa ei ole keventäviä visuaalisia elementtejä, kuten väliotsikoita, lainauksia, kuvia ja faktalaatikoita. Räätälöidyissä toteutuksissa visuaalisuus voidaan ottaa keskiöön "He valvovat rajojamme – tervetuloa työvuoroon itärajalle", mutta visuaalisista keveyttä on mahdollista tuoda myös perinteisemmin keinoin rakennettuihin juttuihin "Henkilökuva: Kemin katujen pikkukingi – kuinka Mika Ranta tuli perustaneeksi Soldiers of Odinin".

Lisää luettavuutta visuaalisilla elementeillä

Laskureiden ja koneiden osalta tämä rakenteen miettiminen näkyy niin, että pyrimme aina sijoittamaan ne jutun alkuun "Mikä on Suomen yleisin nimipäivä? Se selviää Ylen nimipäiväkoneesta". Näin otsikossa lukijalle tehty lupaus täyttyy mahdollisimman nopeasti eikä lukien tarvitse etsiä niin sanottua konetta jutusta. Jos lukija on kiinnostunut aiheesta hän lukee kyllä jutussa olevan leipätekstin. Poikkeuksena tähän ovat pitkät taulukot "Ministeriö julkaisi sote-laskelmia – Katso kotikuntasi tilanne", jotka sijoitamme usein lyhyen leipätekstin jatkoksi jutun loppuun.

Lunasta otsikossa tehty lupaus

Jutun rakenteessa mietimme usein myös milloin juttu kannattaa julkaista yhtenä kokonaisuutena ja milloin se taas kannattaa pilkkoa useammaksi artikkeliksi. Mitään kovin selkeää ohjetta tähän ei ole, mutta usein esimerkiksi datavetoisissa jutuissa kuten Asuntokoneessa julkaisimme niin sanotun featurejutun erillisessä artikkelissa "Kolmikymppiset ovat asuntomarkkinoiden häviäjiä – "Mistä nuoret löytävät rahat asuntoihin?"". Tämä on usein luontevaa, koska muuten yksittäisestä jutusta tulee sisällöllisesti erittäin runsas, mutta toisaalta myös tällä tavalla voimme tehdä jutuille omat erilliset sisältöjään kuvaavat otsikkonsa.

Eräs ohjenuora yhden vai useamman jutun ongelmaan voisi olla, että jos jutussa on useita uutisia ne kannattaa julkaista omilla vetävällä otsikoillaan ja rytmittää niiden julkaisu vuorokauden eri vaiheisiin. Jos taas juttu on yksi yhtenäinen kokonaisuus se kannattaa julkaista sellaisena eikä pakottaa lukijaa etsimään kokonaisuuksien osia eri jutuista.



Yritä aina asettua lukijan asemaan. Missä juttua luetaan, mistä laitteesta, mitä lukijan tarvitsee tietää ymmärtääkseen mistä on kyse, kenelle juttu on ylipäänsä tehty, mikä on kiinnostavaa. Luetuta juttusi muilla. Kysy mielipiteitä ihmisiltä, jotka eivät ajattele kuten sinä.


tiistai 19. heinäkuuta 2016

Yle Uutisten Plus-toteutuksien kehitys

PlusDesk on Yle Uutisissa toimiva tiimi, joka toteuttaa Yle Uutisten verkkosivuille niin sanottuja Plus-toteutuksia. Plus-toteutukset ovat uutisjuttuja, joita ei ole mahdollista toteuttaa julkaisujärjestelmässä. Toisinsanoen esimerkiksi interaktiiviset tai datajournalistiset toteutukset – kun ne vaativat jonkinlaista erityistä verkonkerrontaa – tehdään yhteistyössä PlusDeskin kanssa. Konkreettisesti tällaisia toteutuksia ovat olleet muun muassa:

PlusDesk on toiminut vuoden 2013 alusta eli nyt kolmen ja puolen vuoden ajan. Tänä aikana Plus-toteutuksien toteuttaminen ja julkaiseminen on kehittynyt monilla tavoin. Aloitimme julkaisemisen Ylen verkkolevyn nurkalta, josta on sittemmin luovuttu. Nyt olemme siirtymässä käyttämään AWS-palvelua ja projektikohtaisia Git-repositorioita.

Toteutusten kehitys


Tällä hetkellä PlusDeskissä työskentelee neljä kehitystyötä tekevää henkilöä. Käytössämme on niin Linux- kuin Mac-koneita. Meillä on kaikilla henkilökohtaiset kehitysympäristöt, jotka pyörivät lokaalisti. Kehitysympäristöjen ylläpito ja päivittäminen on pääasiassa käyttäjän vastuulla.

Kehitystyön kannalta olennaista on, että toteutuksia voidaan kehittää ja testata omilla laitteilla mahdollisimman pitkälle ja mahdollisimman vaivattomasti. Tämä helpottaa toteutusten julkaisemista, kun jo kehitysvaiheessa toteutukset testataan mahdollisimman autenttisessa ympäristössä. Eli rautalangasta väännettynä, kehittäjillä on omalla koneellaan kopio Yle Uutisten verkkosivuista, jossa he pystyvät testaamaan kehittämäänsä toteutusta ja näkemään miten toteutus toimii suhteessa muuhun sivustoon. (Kuva 1)

Lokaalisti toimiva kehitysympäristö helpottaa toteutusten testaamista. Kehitysympäristö on kuvankaappaus Yle Uutisten artikkelisivusta. (Kuva 1)

Toteutukset upotetaan suoraan Yle Uutisten sivupohjaan, joten kehittäjän on halutessaan mahdollista rikkoa (muuttaa) koko sivuston toimintaa. Pyrimme hallitsemaan tätä mahdollisuutta rajaamalla kaikki toteutukset koskemaan vain niitä elementtejä, jotka liittyvät itse toteutukseen. Tämä rajaaminen estää, etteivät koodit vaikuta mihinkään toteutuksen ulkopuolisiin elementteihin. Se, että toteutukset asetetaan suoraan sivupohjaan (esimerkiksi iFrame-upotuksen sijaan) kuitenkin mahdollistaa sen, että kehittäjän on helppoa manipuloida myös sivupohjaa niin halutessaan.

Toteutukset noudattavat tiedosto- ja kansiorakenteeltaan aina samaa muotoa, joka on kuvattu alla.

js/
data/
css/
img/
index.html

Näiden lisäksi projekteissa voi soveltuvasti olla mukana esimerkiksi audio, video tai script -nimisiä kansioita. Eri osa-alueet on siis jaettu omiin kansioihinsa. CSS-tyylitiedostot löytyvät omasta css/-kansiosta. Javascript-tiedostot eli toimintalogiikka löytyy js/-kansiosta ja niin edelleen. Käytämme toteutuksissa aina tätä samaa rakennetta, joka helpottaa projektien hallinnointia jälkikäteen ja eri kehittäjien kesken.

Koodauksessa pyrimme käyttämään apuna hyväksi havaittuja ja luotettuja kirjastoja kuten D3.js, jQuery ja Highcharts. Aina tarpeen mukaan käytämme projekteissa myös uusia kirjastoja, mutta näiden käytössä olemme tarkkoja, että ne toimivat varmasti kaikilla laitteilla. Soveltuvasti käytössämme on myös Three.js:n, Reactin ja Angular.js:n kaltaisia kirjastoja. Kirjastot tarjoillaan projekteille joko staattisina tiedostoina tai Node-moduuleina.

Javascriptissä käytämme niin ES5:sta kuin ES6:sta. CSS:ssä meillä on käytössä niin LESS kuin SASS. Nämä kehittäjästä ja projektista riippuen.

Yksinkertaiset projektit pyrimme pitämään mahdollisimman yksinkertaisina (KISS).

Alusta asti olemme käyttäneet Git-versionhallintaa. Versionhallinta mahdollistaa muun muassa koodien jakamisen kehittäjien kesken, mutta myös toteutusten versioinnin. Tähän päivään asti meillä on ollut jokaisen vuoden projekteja varten yksi repositorio, mutta nyt olemme siirtymässä käyttämään projektikohtaisia repositorioita. Projektikohtaiset repositoriot mahdollistavat ketterämmän versionhallinnan hyödyntämisen. Jatkossa nimeämme repositoriot seuraavasti:

"vvvv-kk-projektin_nimi"

Eli esimerkiksi 2016-06-asuntokone. Aikaisemmin kansiorakenne oli muotoa vvvv/kk-projektin_nimi. Meillä on komento, joka luo projektin perustamisen yhteydessä uuden repositorion (myös remoten).

Testaus


Testaamme toteutuksiamme vaihtelevasti, mutta etenkin uudet teknologiat isoimmat projektimme testaamme kattavasti eri laitteilla ja eri ympäristöissä. Tämä tarkoittaa, että kokeilemme toteutuksia puhelimilla, tableteilla, Mac- ja Windows-koneilla sekä eri selaimilla. Meillä on erikseen testaamiseen hankittuja laitteita.

Testaamiseen hyödynnämme Google Chrome DevTools:a, Xcode Simulator:a ja Ghostlab-ohjelmistoa.

Pyrimme siihen, että kaikki toteutuksemme toimivat teknisesti kaikilla nykyisillä laitteilla ja ympäristöillä.

Teemme myös käyttäjätestejä mahdollisuuksien mukaan.

Julkaistavan version buildaaminen


Olemme siirtymässä ja pääosin jo siirtyneet projektien "buildaamiseen". Buildaaminen tarkoittaa, että teemme Plus-toteutuksien koodeista erillisen julkaistavan version. Julkaistavat versiot asetetaan projekteissa public/-nimiseen kansioon, jonka alta löytyy käytännössä sama kansiorakenne kuin yllä kuvatulla kehityspuolella. Public-kansiossa asuvat vain tiedostot joita julkaistava versio tarvitsee.

Käytössämme on muutamia rinnakkaisia buildaustyökaluja, mutta useimmat meistä käyttävät työkalua nimeltä Gulp (olisi mahdollista käyttää myös Grunt:a. Olemme integroineet Gulp:n Sublime Gulp:lla Sublime Text -editoriin, jota käytämme koodin kirjoittamiseen (Kuva 2).

Gulp tarkkailee muutoksia tiedoissa ja suorittaa buildin. (Kuva 2)

HTML, CSS ja JS tiedostoille Gulp suorittaa omat tehtävänsä. Javascript-tiedostojen buildaus tekee seuraavat toiminnot (Suluissa ovat käytettyjen Node-moduulien nimet):

Lint tarkistaa koodin syntaksia, Browserify tekee koodeista selaimessa toimivia, Uglify minifoi koodin, Sourcemaps mahdollistaa minifoidun koodin palauttamisen, Livereload kertoo selaimelle tiedostojen muuttuneen.

CSS-tiedostoille buildi tekee toiminnot:

Less muuntaa Less-syntaksin selaimen ymmärtämään CSS-muotoon, Cleancss minifoi koodin, Sourcemaps mahdollistaa minifoidun koodin palauttamisen, Livereload kertoo selaimelle tiedostojen muuttuneen.

HTML-tiedostoille ajetaan:

Htmlmin minifoi koodin, Livereload kertoo selaimelle tiedostojen muuttuneen.

Gulp rakentaa buildin public/-kansioon, jonka sisältö siirretään julkaisua varten julkisen verkko-osoitteen taakse. Tulevaisuudessa tämä julkinen paikka on AWS:ssa. AWS on pilvipalvelu, jonka kautta voidaan jakaa helposti ja tehokkaasti staattisia tiedostoja. Aikaisemmin olemme käyttäneet Ylen omia verkkolevyjä minne tiedostot on siirretty käsin. AWS:n myötä tämä tiedostojen siirtäminen automatisoituu. Tässä suhteessa yhtenäistämme käytäntöjä Ylen sisäisesti.

Toteutuksen siirtäminen julkaisujärjestelmään


Julkaisujärjestelmämme on nimeltään Escenic. Esceniciä käytetään Yle Uutisten sisällön luomiseen ja tallentamiseen. Escenicistä tiedot haetaan rajapinnan (Yle API) avulla yle.fi/uutiset-sivustolle. Plus-toteutuksien osalta Esceniciin luodaan erillinen sisältötyyppi nimeltä "Ulkoinen sisältö". Ulkoiselle sisällölle määritellään kaikki resurssit, joita toteutus tarvitsee eli tämä tarkoittaa HTML, CSS ja JS-tiedostoja. (Kuva 3)

Asetamme julkaisujärjestelmäämme projektin tarvitsemat resurssit. Tässä esimerkiksi Asuntokoneen ulkoinen sisältö. CSS ja JS resursseja voi tarvittaessa olla useita. (Kuva 3)
Ulkoinen sisältö voidaan sitten liittää uutisartikkelissa mihin tahansa haluttuun paikkaan, jolloin HTML-sisältö liitetään haluttuun kohtaan. CSS- ja JS-tiedostot menevät niille varattuun paikkaan sivupohjassa. Aikaisemmin ulkoiset sisällöt oli mahdollista sijoittaa vain jutun alkuun tai loppuun.

maanantai 9. marraskuuta 2015

PlusDeskin 15 luetuinta juttua vuonna 2015

Ajattelin, että olisi hyödyllistä listata ja lyhyesti analysoida luetuimmat Yle Uutisten jutut vuoden 2015 ajalta, joita PlusDesk on ollut tekemässä. Miksi jutut ovat olleet luettuja ja mikä on ollut PlusDeskin rooli niissä.

PlusDesk on siis osa Yle Uutisia ja meidän tehtävämme on tehdä verkon erityissisältöjä, jotka poikkeavat perinteisestä verkonkerronnasta esimerkiksi esitystavaltaan.



Ylen Vanhusvahti


Tyyppi: Palvelu
Aihe: Vanhuspalvelut
FB-luku: 3 353

Vanhusvahti on palvelu, joka kattaa valtavan määrän aineistoa liittyen kuntien vanhuspalveluihin. Aineistot on kerätty koneellisesti THL:n verkkopalvelusta, jossa ne ovat esitetty hajanaisesti. Vanhusvahtiin nämä tiedot on koottu yhteen palveluun ja käyttöliittymään, jossa tietojen selaaminen on mahdollista. Vanhuspalvelut koskettavat suurta osaa suomalaisista ja niihin liittyvä tieto lainsäädännöstä alkaen on monille epäselvää. Vanhusvahti täyttää siis olemassa olevaa tiedontarvetta.

Vanhusvahdin osalta PlusDeskin rooli on keskeinen, koska millään muotoa näin laajalti ja käytettävästi kaikkien kuntien tietoja ei oltaisi voitu esittää perinteisin muodoin.

Puolue hukassa? Testaa kenen joukoissa seisot


Tyyppi: Testi
Aihe: Vaalit
FB-luku: 4 733

"Puoluekone" on eduskuntavaalien alla julkaistu vaihtoehtoinen vaalikone, joka katsoo äänestyspäätöstä puoluekeskeisesti. Vaalien alla monet vaaliaiheiset sisällöt ovat hyvin vetäviä, mutta testin muotoon puettu puoluekone haastaa lukijan miettimään kysymyksiä eri tavalla kuin jos juttu olisi kirjoitettu tekstimuotoon. Myös koneen visuaalinen ilme, johon on haettu tunnelmaa eduskunnasta, tukee sitoutumista kysymyksiin.

Paljonko kaltaisiasi on uudessa eduskunnassa? Täällä se selviää


Tyyppi: Testi
Aihe: Vaalit
FB-luku: 20 817

"Kaltaisuuskone" on eduskuntavaalien jälkeen julkaistu kone, jolla voi testata miten kansanedustajien demografia on yksiyhteen lukijan demografian kanssa. Tarinaa olisi ollut hyvin vaikea kertoa pelkän tekstin tai kuvien avulla. Somesuosio oli erittäin laaja, koska ihmiset halusivat jakaa oman tuloksensa.

Testaa itsesi: Oletko tiukka vai lempeä tuomari?


Tyyppi: Testi
Aihe: Oikeus
FB-luku: 25 226

"Tuomaritesti" on melko perinteinen testin muotoon puettu juttu, jossa sen sijaan, että kerrottaisiin tekstin avulla suomalaisista oikeuskäytännöistä asetetaan lukija asemaan, jossa hänen täytyy miettiä omaa oikeudenkäsitystään. Tuomaritestiä on näkökulmasta riippuen mahdollista pelata joko niin, että yrittää vastata kuten tuomarit ovat tuominneet tai sitten oman oikeudentajun näkökulmasta. Somenäkyvyys oli laaja, koska aihe puhututtaa ihmisiä. Tällä tavalla juttuun on pystytty pukemaan myös yllätyksellisiä elementtejä, joka tukee suosiota.

Millainen teini olet? Tee nuorten trendisanatesti


Tyyppi: Testi
Aihe: Nuoret
FB-luku: 30 245

"Trendisanatesti" on hyvin perinteinen aihelähtöinen testi, joka linkittyy Ylen Uutisluokka -projektiin. Ei toimisi samalla tavalla tai tehokkuudella pelkkänä tekstijuttuna ilman pelillistä testimäisyyttä. Merkittävä somenäkyvyys toi suuren osan lukijoista.

Kuka on oikeistolaisin, kuka liberaalein? – Katso, miten ehdokkaasi asettuu poliittiselle nelikentälle


Tyyppi: Datajuttu
Aihe: Vaalit
FB-luku: 3 290

Eduskuntavaalien alla julkaistu datajuttu, jossa suuri määrä aineistoa. Juttu oltaisiin voitu toteuttaa staattisina kuvina, joista olisi saanut yleisilmeen puolueiden arvoista, mutta jutussa on myös suuri arvo sillä, että pystyy selaamaan yksittäisten ehdokkaiden tietoja. Kyseisessä jutussa PlusDeskin rooli oli siinä, että juttu saatiin toimimaan ja julkaistua Yle Uutisten ympäristössä. Toteutus ja ideointi tapahtui Yle Uutisten ulkopuolella.

Professori arvioi personal trainerin ruokalistan: "Outoa ettei näitä kyseenalaisteta enempää"


Tyyppi: Erityistaitto
Aihe: Terveys
FB-luku: 14 452

Melko perinteinen juttu puhuttavasta ajankohtaisesta aiheesta. Juttuun rakennettu kaksipalstainen erityistaitto ei tuonut merkittävää lisäarvoa jutulle. Suosio perustui enemmän ihmisten kiinnostukseen terveysuutisista.

Jäätkö luokalle vai saatko ehdot? Testaa pärjäätkö alakoululaisille


Tyyppi: Testi
Aihe: Nuoret
FB-luku: 2 642

"Peruskoulutestin" vetovoima perustuu hyvin vahvasti ihmisten haluun testata itseään. Tämänkaltaiset räätälöidyt testit ovat PlusDeskin työlle ominaista. Somesuosio jäi melko vaatimattomaksi, mutta ehkä syynä oli lopulta testin vaikeus ja kun ihmiset jäivät luokalle ei huonoa tulosta haluttu jakaa eteenpäin.

Väsyttääkö aamulla, valvottaako illalla? Testaa itsesi ja katso tutkijan vinkit


Tyyppi: Testi
Aihe: Terveys
FB-luku: 6 395

"Unitestin" suosion takana on sama mieltymys itsensä testaamiseen kuin peruskoulutestillä.

Väärinymmärretyn Päällikön päiväkirja


Tyyppi: Feature
Aihe: Urheilu
FB-luku: 8 058

Olli Jokisen päiväkirja on ainoa top 15 jutun joukkoon nouseva tekstivetoinen juttu (höystetty toki myös kuvilla). Suosion takana on varmasti vahva ja ainutlaatuinen tarina jääkiekkoilijasta, joka ei ikinä ole ollut juuri julkisuuden parrasvaloissa. Toisaalta myös esillepano on näyttävä, joka tukee osaltaan vaikutelmaa tarinan ainutlaatuisuudesta. Tarina sinänsä olisi elänyt itselläänkin, mutta visuaalisilla elementeillä juttu nostettiin vielä omalle tasolleen.

Näin testaat kuntosi – oletko kovemmassa kunnossa kuin kaverisi?


Tyyppi: Testi
Aihe: Terveys
FB-luku: 1 276

Räätälöity ihmisten terveyteen liittyä testi. Videovetoinen juttu, jossa PlusDeskin panos oli lähinnä somesuosion tukemiseen liittyvät ominaisuudet.

Tulokone – Katso, kuinka asuinalueesi tulotaso on kehittynyt


Tyyppi: Datajuttu
Aihe: Verotiedot
FB-luku: 424

Tulokone on jo useampivuotinen tuote, joka kerää vuodesta toiseen huippulukuja lukijamäärissä mitattuna. Todella iso data paketti, jonka toteuttaminen vaatii erityisosaamista niin substansista kuin verkon omaisuudesta.

Paperimies, maisteri ja nuori jäävät työttömiksi – ja kuinkas sitten käykään?


Tyyppi: Erityistaitto
Aihe: Talous
FB-luku: 921

Kolmen jutun paketti puristettuna yhteen juttuun. Kiinnostavasti otsikoitu, joka on tuonut varmasti suuren osan liikenteestä. Paketoinnin osalta PlusDeskin rooli oli tärkeä, koska muuten juttu olisi levinnyt moneen osaan.

Tässä ovat vuoden 2014 suurituloisimmat – katso koko maan ja maakuntien eniten tienanneet


Tyyppi: Lista
Aihe: Verotiedot
FB-luku: 295

Veropäivän perinteinen juttu, joka kerää lukijoita vuodesta toiseen. PlusDeskin rooli on kuitenkin merkittävä, että tiedot saadaan julkaistua maakunnittain ja koko maan osalta heti aamulla.

Kätilö kärsii lisien leikkauksista eniten – Yle selvitti lisien leikkausten vaikutukset yli 200 ammattiin


Tyyppi: Lista
Aihe: Talous
FB-luku: 7 863

Järjestettävä ja haettava lista uutisjutun yhteydessä, joka syventää juttua yksilön näkökulmasta on usein paljon luettu. Mahdollisuus peilata omaa tilannetta jutun näkökulmaan on mielenkiintoista. Perinteisesti tämänkaltainen jutun personoituvuus on jäänyt tekemättä.



Suurin osa jutuista siis oli sellaisia joissa PlusDeskin rooli oli vitaali. Toisaalta nähdään, että testit ovat suosittuja sisältötyyppejä. Ja aiheena vaalisisällöt ovat paljon lukijoita vetäviä.



Muokkaus 9.11.2015 klo 19.00: Jutut eivät ole missään järjestyksessä. FB-luvut on katsottu SharedCount-palvelun avulla ja ovat Facebook-toimintojen (tykkäykset, jaot, kommentit) yhteenlaskettuja lukuja.

maanantai 21. syyskuuta 2015

PlusDeskin tavoitteet

Työskentelen Yle Uutisissa tiimissa nimeltä PlusDesk. Meitä on tiimissa kaksi tuottajaa, kaksi koodaajaa ja kolme graafikkoa.

Yhdessä muiden tiimien – kuten politiikka, talous, urheilu – kanssa teemme verkkoon uutisjuttuja, jotka poikkeavat esitystavaltaan tai sisällöltään perinteisestä uutisjutun muodosta. Teemme esimerkiksi käyttöliittymiä dataan, laskureita ja erikoistaittoja. Oikeastaan kaiken mihin sisällönhallintajärjestelmämme ei taivu.

Esimieheni pyysi minua listaamaan tavoitteeni. Sama kysymys esitettiin kaikille tiimin jäsenille. Mielestäni kysymys oli siinä määrin mielenkiintoinen, että päätin vastata siihen näin blogissa.



Kysymys kuului.

Millaisia juttuja haluat olla tekemässä jatkossa?

Kysymykseen sai vastata aihe, laajuus tai metodi -lähtöisesti.



Mielestäni vastaus on kiteytyy yksinkertaisesti

"Meidän täytyy tehdä sellaisia juttuja ja journalismia, joita muut Yle Uutisissa Suomessa eivät pysty tekemään."

Mitä tämä sitten tarkoittaa aiheen, laajuuden tai metodin näkökulmasta.



Aihe


PlusDeskin tulisi mielestäni tarttua ensisijaisesti journalistisesti isoimpiin ja tärkeimpiin aiheisiin. Esimerkiksi tällä hetkellä tiimimme työpöydällä olevien aiheiden pitäisi sivuta hallituksen sisäpoliittisia toimia tai pakolaiskriisiä.

Miksi? Koska nämä aiheet ovat erityisen yhteiskunnallisen huomion kohteena. Tämän takia osaaminen, jota meiltä löytyy tulisi olla valjastettu näiden asioiden selvittämiseen. Etenkin jos koetaan, että PlusDesk on Yle Uutisten verkon kerronnan keihäänkärki

Konkreettisesti tarkoitan, että meidän tulisi tehdä nyt enemmän juttuja kuten "Täältä turvapaikanhakijat tulevat – klikkaa ja tutki" ja vähemmän juttuja kuten "Hei hei Facebook! Tällaisen sosiaalisen median nuoret saivat tilalle".

Miksi? Ensinnäkin koska nuoret ovat aiheena ajaton, pakolaiskriisi tapahtuu juuri nyt. Toisaalta koska "nuorisojuttu" olisi voitu julkaista myös ilman meidän panostamme, "pakolaiskriisijuttua" taas ei tässä laajuudessa.

Tätä ei tarvitse ymmärtää niin, ettei meidän tulisi tehdä omia aiheita. Tai etteikö osaamistamme voisi hyödyntää myös kepeämpien aiheiden käsittelyssä.

Laajuus


Juttujen laajuus ei mielestäni ole millään tavalla itseisarvo, ei sen kannalta miten paljon jutun tekemiseen käytetään aikaa, kuin ei myöskään sen kannalta miten laajoja jutut ovat kuluttaa.

Jokaisen tarinan ja uutisen kohdalla on tarkoituksenmukaista pohtia laajuus erikseen. Joskus on hyvä kertoa aiheesta kattavasti eri näkökulmista, kun taas toisinaan on oleellista selvittää yksittäinen asia selkeällä tavalla.

Mielestäni kaltaisemme tiimin tulisi pystyä toimimaan yhtälaisesti nopeassa kuin pitkässä aikaikkunassa. Tämä on myös minulle tekijänä motivoitavaa kun prosessit ovat eri pituisia. On puuduttavaa tehdä vain pitkiä projekteja ja toisaalta stressaavaa jos aikaraja on aina huomenna.

Metodi


Metodia eli esitystapaa sivusin itseasiassa edellisessä postauksessani, joka herätti melko paljon keskustelua.

Mutta jos puhutaan siitä, minkälaista muotoa haluaisin olla tekemässä niin mielestäni PlusDeskin kaltaisen tiimin osaaminen tulee parhaiten hyödynnetyksi kun luomme jotain uutta ja kokeilemme. Toki aina sisältö edellä.

Toisaalta tämä tarkoittaa, että toistuvat muodot, jotka olemme havainneet toimiviksi kuten "järjestettävä taulukko", "erikoistaitto" tai "visa" tulee toteuttaa toimittajan työkaluiksi.

Muotojen toistuvuus ei ole tabu, mutta olemme PlusDeskissä muodon ammattilaisia, jolloin itseääntoistava työ ei inspiroi. Ja työ joka toistaa itseään on lopulta tarkoitettu automatisoitavaksi.

keskiviikko 29. heinäkuuta 2015

Näin syntyi eduskuntavaalituloksen analyysijuttu

Teimme PlusDesk:ssä kevään eduskuntavaaleihin liittyen useampia juttuja.

Yksi niistä oli vaalitulosta analysoiva juttu "Kokeile, miltä vaalitulos näyttää, jos vain koulutetuimmat tai sairaimmat olisivat äänestäneet", jossa vaalitulosta katsottiin kunnittain viiden demografisen muuttujan kautta. Muuttujiksi olimme valinneet:
  1. tulot
  2. koulutus
  3. työttömyys
  4. eläkeläisten osuus
  5. terveys
Niin sanotun 100 kuntaa -koneen lähteenä käytettiin Tilastokeskuksen Kuntien avainluvut -aineiston tunnuslukuja 1) valtionveronalaiset tulot, 2) korkea-asteen tutkinnon suorittaneiden osuus, 3) työttömyysaste sekä 4) eläkkeellä olevien osuus väestöstä. Tiedot väestöltään 5) terveimmistä ja sairaimmista kunnista perustuivat THL:n sairastavuusindeksiin.

Lukijan oli mahdollista valita näkyville viiden eri muuttujan ääriarvot. (Kuva 1)

Jutun idea oli, että valitulla muuttujalla vaalitulos laskettiin ottaen huomioon vain 100 kuntaa.

Esimerkiksi jos muuttujaksi valitaan "koulutus" vaalitulos lasketaan niin, että otettiin huomioon vain 100 vähiten tai korkeiden koulutetun kunnan äänet. Vastaavasti jos muuttujaksi valittiin "tulot" pystyi näkemään miten vaalitulos olisi rakentunut jos vain Suomen pieni- tai suurituloisimmat kunnat olisivat äänestäneet. Idea oli lainattu ulkomailta.

Ajatuksenamme oli hypoteesi siitä, että vasemmiston kannatus korostuisi pienituloisissa kunnissa kun taas porvaripuolueiden kannatus olisi huipussaan suurituloisissa kunnissa. Toki näin suoraviivaisesti ei voi ajatella, mutta kantava ajatus analyysissa oli tämänkaltainen. Eli, että puolueiden voimasuhteet ovat riippuvaisia ihmisten demografisista ominaisuuksista.

Äänestysdatat saimme Ylen vaalipalvelun rajapinnan kautta. Tiedot tulivat sieltä .json-formaatissa.

Kehityskaari

Ensimmäisessa vaiheessa toteutimme uutissovelluksen niin, että valitsemalla muuttujan näki vaalituloksen jakautumisen puolueittain pylväsdiagrammeina. Eli lopullisen toteutuksen sen osuuden, joka näkyy sovelluksen vasemmassa laidassa. Tämä oli oikeastaan vähimmäisvaatimus toimivalle sovellukselle. (Kuva 2)

Pylväsdiagrammit esittivät äänestystuloksen valitulla 100 kunnalla sekä verrattuna todelliseen äänestystulokseen, jotta vertailu olisi helppoa. (Kuva 2)

Nopeasti kuitenkin tajusimme, että olisi tuloksen lisäksi hyödyllistä nähdä mitkä nämä 100 kuntaa ovat joista vaalituloksen laskenta tapahtuu ja missä päin Suomea ne sijaitsevat. Näin lisäsimme pylväsdiagrammin rinnalle Suomen kuntakartan, jossa esitetään valitut 100 kuntaa korostevärillä. (Kuva 3)

Valitulla muuttujalla laskennassa käytetyt kunnat korostettiin sinisellä. (Kuva 3)

Pelkkä kuntien esittäminen kartalla tuntui kuitenkin nopeasti liian kapealta näkökulmalta ja tajusimme, että olisi kiva tietää myös äänestystulos yksittäisten kuntien osalta. Lisäsimme tämän aineiston selattavaksi kartalle niin, että osoittamalla kuntaa näki yksittäisen kunnan äänestystuloksen. (Kuva 4)

Osoittamalla näki miten kannatus jakautui puolueittain yksittäisessä kunnassa. (Kuva 4)

Huomiot

Teknisesti tuote siis eli koko kehitysprosessin ajan. Tämä on luontevaa nykyaikaisessa ketterässä ohjelmistokehityksessä. Uusia ominaisuuksia lisätään toimivan tuotteen ympärille kun tarve niille havaitaan. Tätä voidaan kutsua esimerkiksi prototypoinniksi.

Datajournalismin ja uutissovelluksen rakentamisessa tämänkaltainen ketterä kehittäminen on erityisen luontevaa ja tehokasta, koska tilanteet voivat muuttua nopeasti ja mahdollisuus niiden ennakoimiseen on rajallista.

Ei ole tarkoituksenmukaista etukäteen määritellä syvällisesti mitä ollaan tekemässä ja lyödä lukkoon projektin alkuvaiheessa mikä on lopullinen toteutustapa, koska ymmärrys jota näiden päätösten tekemiseen vaaditaan rakentuu vasta kun sovellusta aletaan tekemään.

perjantai 8. toukokuuta 2015

Nuijamaan rajamiehillä oli todella hyvä pito

Julkaisimme Yle Uutisten sivuilla 6.5. jutun "He valvovat rajojamme", joka kertoo rajavartioiden työstä Nuijamaalla. Juttu on erikoistaitettu, jossa on annettu suuri tila kuville ja videoille. Materiaalia jutussa on paljon eli juttu on siis pitkä lukupaketti. Jutussa edettiin vierittämällä alaspäin kuten netissä on luontevaa. (Kuva 1)

Juttu Nuijamaan rajavartioista julkaistiin keskiviikkona kello 11 jälkeen. (Kuva 1)
Juttu keräsi noin 20 000 klikkausta.

Juttu jakautui kuvien, videoiden ja grafiikoiden myötä 15:sta kokonaisuuteen. Seurasimme miten pitkälle lukijat vierittivät sivua. Tallensimme tiedon kun käyttäjä saavutti kokonaisuuden alun.

Ensimmäisen kokonaisuuden alkuun vieritti noin 18 000 käyttäjää. Heti alussa menetettiin siis noin 10 % kävijöistä. Tämän jälkeen pito oli todella hyvä. Loppuun asti jutun vieritti 11 600 käyttäjää eli noin 60 %:a kävijöistä. Tämä on todella suuri osuus, koska aikaisemmin olemme nähneet lähempänä 10–20 % olevia lukuja. Toki edelleen ymmärryksemme lukujen takana perustuu pieneen otantaan. Emme ole vielä tarpeeksi usein mitanneet kuinka kuinka pitkälle tämänkaltaisia pidempiä juttuja vieritetään.

Jotain perusteluja hyvälle pidolle voidaan kuitenkin etsiä julkaisuajasta. Juttu julkaistiin selkeästi päivällä – kello 11 jälkeen – jolloin ihmiset ovat työpaikoillaan tietokoneiden ääressä. Yleinen sääntö meillä julkaisulle on, että paras julkaisuaika on heti aamulla, mutta tästä ehkä opimme, että tämänkaltaisten erikoistaitettujen juttujen kohdalla viisautta voidaan hakea myös muunlaisesta julkaisuajankohdasta.

Tilastonikkareille


Luvut ovat Google Analyticsin yksilöidyt tapahtumat -lukuja.

Jutun lukijamäärä: 20 028
  1. osion alkuun: 18 176
  2. osion alkuun: 17 340
  3. osion alkuun: 16 240
  4. osion alkuun: 15 318
  5. osion alkuun: 14 981
  6. osion alkuun: 14 512
  7. osion alkuun: 13 774
  8. osion alkuun: 13 579
  9. osion alkuun: 13 142
  10. osion alkuun: 13 074
  11. osion alkuun: 12 516
  12. osion alkuun: 12 451
  13. osion alkuun: 11 928
  14. osion alkuun: 11 702
  15. osion alkuun: 11 432

maanantai 27. huhtikuuta 2015

Yli 2 miljoonaa "swaippausta", Kandideitti oli menestys

Julkaisimme vaalien alla Kandideitti-nimisen sovelluksen, joka tunnettiin myöhemmin myös Vaalitinder-nimellä.

Kandideitti oli eräänlainen minivaalikone, jonka avulla sopivaa ehdokas etsittiin viiden asiakysymyksen kautta perustuen pelkästään ehdokkaiden kasvokuvaan, ikään ja etunimeen. Idea oli lainattu suositusta treffipalvelu Tinderistä.

Ehdokkaat saattoi joko hyväksyä tai hylätä annettujen tietojen perusteella. (Kuva 1)

Kandideitin tarkoitus oli lisätä erityisesti sellaisten ihmisten kiinnostusta vaaleihin, jotka eivät tavallisesti vaaleista innostu. Miten tämä tavoite täytty lukujen valossa?

Google Analytics -lukujen mukaan Kandideitillä oli noin 50 000 yksilöityä käyttäjää. Nämä käyttäjät hylkäsivät ja hyväksyivät ehdokkaita 2 150 000 kertaa. Eli reilut kaksi miljoonaa kertaa. Sovelluksen käyttäjät olivat siis erittäin ahkeria. Keskimäärin yksittäinen käyttäjä kävi läpi yli 40 ehdokasta, joka on todella suuri luku.

Tämä kertoo, että Kandideitti löysi erittäin aktiivisen käyttäjäryhmän, joka koki sovelluksen siinä määrin erittäin hyödylliseksi, että sen parissa viettiin paljon aikaa. Vaikeampi kysymys on arvioida ovatko nämä käyttäjät olleet etenkin sellaisia, jotka eivät muuten kiinnostu vaaleista. Ja vielä vaikeampi kysymys on saiko Kandideitti nämä ihmiset äänestämään tai vaikuttiko Kandideitti heidän äänestyspäätökseensä.

Kuten odottaa saattoi oli hylkääminen (1 800 000) erittäin paljon hyväksymistä (350 000) yleisempää. Löytöjä syntyi noin 57 %:ssa hyväksymisistä, joka on käytännössä sama kuin löydölle asetettu raja-arvo (3/5 asiakysymyksestä tuli olla samaa mieltä).

Kävijämäärä oli lopulta pienoinen pettymys. Odotimme jutulle yli 100 000 klikkausta, mutta jäimme tavoitteesta. Jutulla on tällä hetkellä ComScoren mukaan noin 79 000 klikkiä. Mutta ehkä näissä luvuissa näkyy juuri se, että Kandideitti oli kuitenkin lopulta pienemmän kohderyhmän niche-palvelu verrattuna Ylen muihin vaalituotteisiin (Vaalikone ja Vaaligalleria).

maanantai 9. helmikuuta 2015

Ohjeilla on väliä ja reagointi kannattaa

Julkaisimme tänään 9.2.2015 jutun jossa käsittelimme pääkaupunkiseudun ikääntymistä. Juttuun olimme tehneet kartan josta ikääntymistä oli mahdollista tarkastella alueittain. (Kuva 1)

Uutissovelluksella pystyi tarkastelemaan ilmiötä monista eri näkökulmista. (Kuva 1)
Uutissovellusta oli mahdollista käyttää monella tavalla. Ilmiötä saattoi tarkastella pitkällä aikajaksolla koko pääkaupunkiseudun tasolla tai ottaa tarkasteluun vain yksittäisen alueen.

Aamulla kello 8–9 välillä tarkkailimme miten eri toiminnallisuuksia sovelluksessa käytettiin ja havaitsimme, että yksittäinen alue valittiin tarkasteluun yllättävän harvoin. Uutissovelluksessa saattoi siis valita tarkasteluun yksittäisen alueen tiedot. (Kuva 2)

Klikkaamalla aluetta sai nähtäväkseen valitun alueen tiedot viivadiagrammina. (Kuva 2)
Oletuksemme oli, etteivät ihmiset tajua, että karttaa on myös mahdollista klikata. Mietimme Plus-tiimimme kanssa miten voisimme tukea tämän toiminnallisuuden löytymistä.

Päätimme lyhyiden keskustelujen pohjalta yksinkertaisesti lisätä osoittaessa avautuvaan tietoikkunaan lisätekstin, että klikkaamalla saat lisätietoa. (Kuva 3)

Lisäsimme toteutukseen ohjeen jossa kehotettiin osoittamisen lisäksi myös klikkaamaan aluetta. (Kuva 3)
Mitä tapahtui? Alueen valitsemisen suosio alkoi välittömästi nousta ja siitä tuli sovelluksen käytetyin ominaisuus.

Toki myös muilla tekijöillä on vaikutusta tähän kuten, että yhdeksän jälkeen ihmisten työpöytäkäyttö kasvattaa suosiotaan suhteessa mobiilikäyttöön.

Summasummarun reaaliaikaisen käytön seurannan avulla pystymme reakoimaan nopeasti ja parantamaan uutissovellusten toimintaa.

maanantai 26. tammikuuta 2015

Puolet kävijöistä klikkaa yli kolme kertaa

Julkaisimme Yle Uutisten sivuilla perjantaina 23.1.2015 jutun "Omistusasuminen saattaa lisätä työttömyyttä – katso kuinka paljon omalla alueellasi on vuokra-asumista". Juttu keräsi viikonlopun aikana n. 46 000 yksilöityä sivun katselua (Google Analytics).

Jutun oheen olimme toteuttaneet uutissovelluksen, jonka avulla lukija pystyi tarkastelemaan postinumeroittain kuinka monta vuokra- ja omistustaloutta alueella on. Aineisto esiteltiin graafisesti sekä numeerisesti. Lisäksi sovellus kertoi postinumeroalueella asuvien ihmisten ammattiaseman jakautumisen. (Kuva 1)

Laskurista pystyi katsomaan minkälaisessa omistussuhteessa taloudet asuvat valitulla postinumeroalueella. (Kuva 1)

Aineistot hankittiin Tilastokeskuksen Paavo-palvelusta, josta ne saa ladattua tiedostoina tai rajapinnan kautta. Postinumerokohtaiset aineistot ovat olleet avointa dataa 14.1.2015 lähtien. Ruututietokanta on edelleen Tilastokeskuksen maksullinen palvelu.

Mittasimme kuinka paljon jutussa ollutta uutissovellusta käytettiin. Google-raportin mukaan postinumero valittiin n. 25 000 yksilöidyn käyttäjän toimesta. Eli n. 55 % jutun lukijoista käytti konetta vähintään kerran. Yhteensä postinumero valittiin koneella 84 000 kertaa eli keskimäärin yksittäinen käyttäjä valitsi postinumeroalueen n. 1,8 kertaa. Kuitenkin kun 45 % ei käyttänyt konetta ollenkaan on luku konetta ylipäänsä käyttäneiden osalta huomattavasti suurempi eli noin n. 3,3 kertaa.

Luvut ovat hieman parempia kuin osasin odottaa. Meillä ei kuitenkaan ole vielä tarpeeksi vertailuaineistoa, että voisimme yksikäsitteisesti numeroihin perustuen sanoa, että uutissovellus toimi hyvin ja että sitä osattiin ja haluttiin käyttää. Se, että keskimäärin konetta käyttänyt henkilö tarkasteli sen avulla yli kolmea postinumeroaluetta kertoo siitä, että aineisto on koettu hyödylliseksi ja kone on toiminut. Hypoteettisesti tämän luvun voisi olettaa olevan lähempänä kahta (edellinen ja nykyinen asuinpaikka).

Suosituimmat postinumeroalueet löytyivät Helsingistä ja muista suurista kaupungeista. Suurten aineistojen kohdalla kun valittavissa on esimerkiksi yli 3 000 postinumeroaluetta kannattaa meidän jatkossa miettiä onko järkevää tukea näiden suosituimpien alueiden löytymistä. Nyt postinumeroalueet olivat valittavissa kunnittain aakkosjärjestyksessä. Toisaalta suosituimpienkin aineistojen suosio oli kaikista valinnoista vain prosentin luokkaa. (Kuva 2)

Suosituimmat postinumeroalueet löytyivät Helsingistä ja muista suurimmista kaupungeista. (Kuva 2)

Se minkä keräämämme aineisto myös kertoo on, että koneella onnistuttiin hakemaan mobiilikäyttöliittymässä, jossa valinta tehtiin kirjoittamalla ei valitse, myös paljon alueita, joita ei ole olemassa. Tähän täytyy myös jatkossa kiinnittää huomiota.

Kooditeknisesti tämänkaltaisen käyttötiedon keräämisen implementointi on hyvin yksinkertaista. Tässä esimerkki tästä toteutuksesta ja postinumeroalueen valinnan käytön seurannasta. (Kuva 3)

Käytännössä yhdellä koodirivillä pystyy Google-analyticsiin lisäämään tapahtumien seurannan. (Kuva 3)

Lisää tapahtumien seurannasta voit lukea Google Analytics -dokumentaatiosta.

maanantai 13. lokakuuta 2014

Asuntojen myyntitietokonetta käytettiin kolmessa päivässä yli 250 000 kertaa

Perjantaina 10.10.2014 julkaisimme Yle Uutisten sivuilla jutun, joka käsitteli osakehuoneistojen arvojen kehitystä pitkällä aikavälillä, vuosina 1987–2013. Jutun yhteyteen oli rakennettu kone, josta hintojen kehitystä oli mahdollista tarkastella postinumeroalueen tarkkuudella. (Kuva 1)

Asuntokoneesta pystyi esimerkiksi tarkastelemaan Hervannan neliöhintojen kehitystä vuosittain. (Kuva 1)

Keräsimme koneen käytöstä numeerista dataa. Keräsimme:
  • sivun latausmäärä (174 000)
  • talotyypin valinta (139 000)
  • postinumeroalueen valinta (256 000)
  • vertailualueen valinta (5 700)
  • vuoden valinta (84 000)
Luvut ovat aikajaksolta 10.–12.10.2014 eli viime perjantaista sunnuntaihin.

Sivun latausmäärä


Sivun latausmäärän keräsimme normaaliin tapaan ComScore-ohjelmalla. Ylen mittakaavalla 174 000 sivulatausta on selkeästi viikkotason hitti. Vertailukohdaksi vuoden 2014 luetuin juttu on kerännyt yli 600 000 sivulatausta eli aivan sillä tasolla ei liikuta, mutta aina kun juttu on viikon luetuin voidaan olla tyytyväisiä.

Potentiaalia suurempiinkin lukijamääriin olisi tietysti ollut, koska useimmilla meistä on koti vaikka se omistusasunto ei olisikaan.

Talotyypin valinta


Jotta konetta pystyi käyttämään täytyi ensiksi valita halusiko tutkia aineistoa koskien kerrostaloja vai pari/rivitaloja. (Kuva 2)

Aluksi koneessa täyty valita halusiko tarkastella kerrostalohuoneistoja vai pari/rivitalohuoneistoja. (Kuva 2)

Talotyyppi valittiin 139 000 kertaa. Raa'asti yksinkertaistamalla siis 35 000 sivulataajaa tai 20 %:a sivulataajista ei käyttänyt konetta ollenkaan. Näin suoraviivaisesti lukuja ei tietenkään voi tulkita, koska yksittäinen sivun lataaja on voinut valita talotyypin useaan kertaan. Toisaalta taas yksittäinen henkilö on voinut palata uutiseen jo käytettyään konetta.

Mutta jos oletetaan karkeasti, että 80 %:a jutun lukijoista on ymmärtänyt käyttää jutusta löytyvää toiminnallisuutta – joka poikkeaa siitä mitä Ylen uutisjutusta normaalisti voi odottaa – voidaan tätä lukemaa pitää hyvänä.

Syitä näin korkeaan osuuteen voidaan löytää esimerkiksi siitä, että käyttöliittymä on ollut tarpeeksi yksinkertainen, jotta se on ollut ymmärrettävä ja siitä että sisältö on tarjoiltu niin mielenkiintoisesti, että lukija on kokenut sen riittävän kiinnostavaksi.

Olisi mielenkiintoista saada jatkossa statistiikkaa siitä miten tämä 80 % esimerkiksi vertautuu siihen kuinka moni lukee normaalin uutisjutun loppuun asti. Olemme tällä hetkellä kehittelemässä tähän liittyviä työkaluja.

Jatkotoimenpiteinä pyrimme myös jatkossa mahdollisimman selkeisiin ja yksinkertaisiin käyttöliittymiin. Uutissisällöissä on tärkeää, että lukija pääsee mahdollisimman nopeasti kiinnostavan sisällön äärelle.

Kerrostalot (71 000 valintaa) olivat muuten minimaalisesti pari/rivitaloja (68 000 valintaa) kiinnostavampia.

Postinumeroalueen valinta


Teknisesti postinumeroalueen valinnan toteuttaminen oli haastavaa, koska postinumeroita on yli 3 000. Etenkin mobiililaitteilla näin laajan aineiston hakeminen ja suodattaminen käy laitteelle raskaaksi.

Lopulta päädyimme ratkaisuun, jossa mobiililaitteilla ja työpöytäkäytössä postinumeroalueen valitseminen toimii hieman eri tavalla. Työpöytäkäytössä postinumeroalueita on mahdollista selata sekä hakea, mutta mobiililaitteilla mahdollisuus selaamiseen jätettiin pois.

Julkaisuhetkellä mobiili toimi samalla tavalla kuin työpöytä, mutta saadun palautteen pohjalta kehitimme konetta lennosta. Muutokset olivat käytössä ennen puoltapäivää kun juttu julkaistiin aamulla puoli seitsemän aikaan.

Työpöytäkäytössä hyödynsimme Chosen-nimistä kirjastoa, joka muuntaa HTML-muotoiset <select>-listat haettaviksi (Kuva 3). Mobiilikäytössä käytimme jQuery UI:n autocomplete -toiminnallisuutta (Kuva 4).
Työpöydäkäytössä postinumeroalueita pystyi selaamaan ja hakemaan. (Kuva 3)
Mobiilikäytössä postinueroita pystyi vain hakemaan. (Kuva 4)

Valitsemamme toteutustapa osoittautui ainakin käyttötilastojen valossa toimivaksi. Yksittäinen postinumeroalue valittiin koneen avulla 256 000 kertaa. Tämä tarkoittaa karkeasti, että yksittäinen lukija käytti konetta postinumeroalueen datan tarkistamiseen keskimäärin kaksi kertaa.

Tämä kertoo, että aineisto on kiinnostanut ja käyttöliittymä sen tarkasteltuun on ollut toimiva. Käytännössä tietysti käyttäjistä löytyy tehokäyttäjiä, jotka ovat valinneet mahdollisesti useita kymmeniä alueita ja sitten on käyttäjiä, jotka ovat valinneet vain yhden alueen.

Huomion arvoista on myös, että asuntokoneen käyttäjistä 38 % tuli mobiililaitteista (puhelin ja tabletti). Aamulla ennen tekemiämme mobiilikäyttöön liittyneitä parannuksia osuus oli lähempänä 20 %:a. Eli tehdyt parannukset olivat tarpeen.

Suosituimpia hakuja olivat Helsinkin eri alueet sekä suurten kaupunkien keskustat:
  1. 00100 Helsinki Keskusta / Helsingfors centrum (2 138 valintaa)
  2. 20100 Turku Keskus / Åbo centrum (1 597)
  3. 00530 Kallio / Berghäll (1 574)
  4. 37800 Toijala keskus / Toijala centrum (1 420)
  5. 33100 Tampere Keskus / Tammerfors centrum (1 383
  6. 00200 Lauttasaari / Drumsö (1 361)
  7. 40100 Jyväskylä Keskus / Jyväskylä centrum (1 132)
  8. 90100 Oulu Keskus / Uleåborg centrum (1 126)
  9. 00500 Sörnäinen / Sörnäs (983)
  10. 00320 Etelä-Haaga / Södra Haga (981)
Toijalan keskustan nouseminen listalle selittyy sillä, että se oli pudotusvalikon ensimmäinen valinta, koska alue kuuluu nykyään Akaaseen, joka on aakkosjärjestyksessä Suomen ensimmäinen kunta.

Huomionarvoista on, ettei suosituinkaan alue kerännyt kuin noin prosentin valinnoista. Aineistoa tarkasteltiin siis hyvin laajasti. Eri aluevalintoja tehtiin yhteensä vajaa 2 000 kappaletta.

Jatkossakin kannattaa siis panostaa siihen, että erilaiset valinnat ovat mahdollisimman hyvin käytettävissä eri laitteilla. Etenkin jos ne ovat keskeisiä sovellusten käytön kannalta. Se, että aineistoa on tutkittu laajasti kertoo myös siitä, että tämänkaltaiset koneet jotka palvelevat kaikkia ovat toimivia. Meillä kaikilla on omat alueelliset kiinnostuksen kohteemme ja se on oma napa joka kiinnostaa.

Vertailualueen valinta


Perjantaina iltapäivällä julkaisun jälkeen toteutin koneeseen vielä lisätoiminnallisuuden, jonka avulla oli mahdollista vertailla yhtä aikaa grafiikassa kahta aluetta. (Kuva 5, Kuva 6)

Vertailualueiksi pystyi ottamaan esimerkiksi Hervannan ja Tampereen Keskuksen. (Kuva 5)
Grafiikassa valittujen alueiden hintakehityksen pystyi näkemään yhtä aikaan, joka helpotti vertailua. (Kuva 6)

Mahdollisuus vertailualueen valintaan ei ollut siis mukana jutun julkaisusta lähtien vaan se lisättiin vasta myöhemmin iltapäivällä. Tästä huolimatta voisaan sanoa, että toiminnallisuuden käyttö jäi hyvin pieneksi. Vertailualue valittiin vain 5 700 kertaa kun siis yksittäinen postinumeroalue valittiin näkyville 50 kertaa useammin.

Syitä miksi vertailualuetoiminnallisuutta ei käytetty voidaan hakea monista näkökulmista. Toisaalta toiminnallisuus oli käyttöliittymällisesti esillä melko huomaamattomasti. Se löytyi postinumeroaluevalinnan alta oikealta puolelta linkkinä. Tämä poikkesi muusta koneen käyttöliittymästä ja voi olla, että yksinkertaisesti toiminnallisuutta ei löydetty. Voi myös olla, että lukijoille riitti, että he pystyivät katsomaan heitä kiinnostavia alueita. Vertailu tällä tavalla muihin alueisiin ei ollut sisällöllisesti kiinnostavaa.

Tämä on kuitenkin hyvä tutkiskelun paikka, että tämänkaltaisissa toteutuksissa kannattaa keskittyä pääasiallisiin toiminnallisuuksiin ja siihen, että niistä tehdään mahdollisimman toimivia. Erilaiset lisätoiminnallisuudet ja sellaiset "olisi kiva jos tässä voisi tehdä vielä vaikka tätä ja tuota" -pyynnöt ja niiden arvo kannattaa miettiä tarkasti. Onko niistä todellista hyötyä vai ovatko ne vain aineistoon tutustuneen toimittajan ja koodarin päässä kiinnostavia.

Hyvä nyrkkisääntö moniin visualisointeihin ja datan esittämiseen on "Quick overview, details on demand". Yksityiskohdat (details) voidaan myös tarjota esimerkiksi mahdollisuutena ladata aineisto Excel-tiedostona.

Ostovuoden valinta


Koneessa oli myös mahdollista syöttää lisävalintana ostovuosi. Ostovuoden syöttäminen oli lisävalinta. Syöttämällä asuntotyypin ja postinumeroalueen lukija sai oikeastaan jo oleellisimman informaation näkyville, mutta jos hän syötti edelleen asunnon ostovuoden kerrottiin hänelle yksityiskohtaisempaa tietoa asunnon arvon kehityksestä valitusta ostovuodesta vuoteen 2013. (Kuva 7)

Valitsemalla ostovuoden lukija sai tietoa millä tavalla valitulla alueella asuntojen hinnat ovat kehittyneet ostovuodesta vuoteen 2013. (Kuva 7)

Ostovuosi valittiin 84 000 kertaa, jota pidän yllätyksellisen korkeana arvona ottaen huomioon, että suuri osa lukijoista ei edes omista omaa asuntoa. Toisaalta ostovuoden valinta jäi käyttöliittymällisesti hieman taka-alalle, koska hinnan kehitystä kuvaava grafiikka piirrettiin heti postinumeroalueen valinnan jälkeen. Visuaalinen grafiikka oletettavasti vangitsee ilmestyessään katseen itseensä. Oma näkökulmani olikin ensin, ettei tätä ostovuoden valintaa kannata toteuttaa koneeseen ollenkaan.

Ostovuoden valinta kuitenkin koettiin hyödylliseksi, koska jälleen karkeasti voidaan sanoa, että 60 %:a koneen käyttäjistä löysi tämän toiminnallisuuden ja hyödynsi sitä. On siis nähtävä, että tämänkaltaiset toiminnallisuudet ja lisävalinnat, jotka tuovat suoraa lisäarvoa lukijalle ja antavat perspektiiviä aineistoon hänen omasta näkökulmastaan ovat hyödyllisiä.

Suosituimmat vuosivalinnat olivat:
  1. 1987 (9 866 valintaa)
  2. 2013 (8 425)
  3. 2010 (5 267)
  4. 2012 (5 103)
  5. 2011 (4 674)
  6. 2000 (4 262)
  7. 2008 (3 625)
  8. 2009 (3 585)
  9. 2007 (3 573)
  10. 2005 (3 472)
Vuoden 1987 suosio selittyy sillä, että se oli aineiston ensimmäinen vuosi ja samalla pudotusvalikon ensimmäinen valinta. Vuotta 2000 taas selittää, että jutussa käsiteltiin yhtenä näkökulmana hintojen kehitystä vuosina 2000–2013. Lukijoita siis kiinnosti verrata jutussa tehtyä havaintoja omaan alueensa kehitykseen.

Muuten nähdään, että ihmiset ovat olleet kiinnostuneita suhteellisen tuoreesta kehityksestä. Voidaan tehdä myös sellainen hypoteesi, että, koska koneessa valittiin useimmin esimerkiksi Helsingin keskustan alueita, joissa on paljon pieniä asuntoja ovat koneen käyttäjät myös tämänkaltaisten asuntojen ostajia ja pienissä asunnoissa usein asutaan isompia lyhyempi aika.



Yhteenvetona voitaneen todeta, että tämänkaltainen uutissisältöjen tarkempi käyttöanalytiikka tuottaa erittäin arvokasta ja mielenkiintoista dataa. Pystymme todentamaan ja kumoamaan oletuksiamme, jonka myötä toivottavasti jatkossa kehitämme aina vain parempia ja helppokäyttöisempiä uutissovelluksia.

Olemme jo nyt vieneet keräämäämme dataa osaksi päätöksentekoa, joka on tietysti olennaista, että emme vain kerää dataa, koska se on mahdollista.