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

tiistai 28. marraskuuta 2017

WebView on datajournalistin uusi Internet Explorer

Kun Tim Berners-Lee vuonna 1990 kehitti nykyisin tuntemamme netin ensiaskeleet hänellä ei varmasti ollut käsitystä minkälaisen vallankumouksen hän aiheuttaisi. Berners-Lee on edelleen keskeinen hahmo, koska hän toimii netin standardointia ja suosituksia hoitavassa W3C-organisaatiossa.

Netin alkuaikoina käytänteistä käytiin perustavanlaatuisia kamppailuja kun päädyttiin esimerkiksi käyttämään Javascriptiä. Tuolloin suosituimmat selaimet Netscape Navigator ja Internet Explorer vetivät kehitystä omiin suuntiinsa (Kuva 1). Esimerkiksi CSS:n osalta tilanne on ollut erityisen ongelmallinen näihin päiviin asti.

Tämänkaltaiset ilmoitukset olivat hyvin tavallisia 2000-luvun taitteessa. (Kuva 1)
Nykyisin selainmarkkinoita hallitsevat Mozilla Firefox, Internet Explorer (Edge), Chrome ja Safari. Esimerkiksi Yle Uutisten sivuilla nämä neljä kattavat noin 90 % liikenteestä (lähde Google Analytics). Standardien noudattamisen osalta ollaan viime vuosina menty huimasti eteenpäin, mutta etenkin Internet Explorer oli pitkään piikki netinkehittäjien lihassa ja kirjoitinkin aiheesta vuonna 2012.

Vuosi 2012: "Toimiiko Internet Explorerissa"

Nykyisin tilanne Internet Explorerin suhteen on kehittäjän näkökulmasta uusien versioiden myötä  paljon siedettävämpi. Toisaalta myös, että IE:n osuus käytöstä on pudonnut huomattavasti.

Vuosina 2012–2016 nähtiin kuitenkin hyvin merkittävä mobiilikäytön kasvu. Nykyisin Yle Uutisten käytöstä yli puolet tulee mobiililaitteista kun vuonna 2012 osuus oli noin 10 % (lähde Google Analytics).

Ennen mobiilin tuloa netin kehitystyötä pystyi teskemään riittävän natiivisti ja kattavasti yhdellä tietokoneella. Mobiilikäytön kasvu tarkoitti, että päätelaitteiden ja selainten määrä kasvoi rajusti, joka taas johti siihen, ettei toteutusten testaaminen kaikilla päätelaitteilla ja selaimilla enää ollut mahdollista.

/* Good browsers */
opacity: 0.5;

/* IE 8 */
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";

/* IE 5-7 */
filter: alpha(opacity=50);

Esimerkki siitä miten Internet Explorer tuli esimerkiksi huomioida CSS-tyyleissä.

Vuonna 2012 IE:llä toimimattoman toteutuksen saattoi vielä räätälöidä IE:lle toimivaksi, mutta mobiilimaailmassa tämä räätälöinti ei enää ollut käyttöympäristöjen määrästä johtuen mahdollista. Tässä uudessa tilanteessa standardien noudattaminen ja yhteiset netin käytänteet tulivat yhä tarkeämmiksi. Kehittäjän tuli voida luottaa, että jos hän noudattaa netin standardeja ja suosituksia toimii toteutus kaikissa päätelaitteissa.

Mobiilin alkuvuosina tilanne oli kaoottisempi ja ongelmat olivat teknisen lisäksi myös sisällöllisiä rajatusta näytönleveydestä johtuen (responsive = "toimii myös mobiilissa" ja mobile-first = "toimii myös desktopissa").

Vuosi 2015: "Toimiiko mobiilissa"

Verkko on toimintaympäristöltään siinä mielessä hyvin erityislaatuinen, että kehittäjä ei voi juurikaan määritellä tai rajata käyttäjän päätelaitetta. Esimerkiksi tehtäessä televisio-ohjelmaa toimintaympäristö ja jakelukanava on melko selkeästi määritelty. Tai jos kehityksen kohteena on HSL:n kortinlukijan käyttöliittymä, jossa päätelaite on vakioitu, ei järjestelmän tarvitse olla samalla tavalla skaalautuva kuin kehitettäessä nettipalveluita.

Verkossa päätelaitetta, käytettävissä olevia teknologioita eikä jakelukanavaa voi käytännössä rajata mitenkään. Toteutuksen tulisi skaalautua niin, että se toimii niin desktop-selaimella ADSL-yhteydellä kuin hitaammalla yhteydellä älykellosta. Toisaalta toteutuksen tulisi olla käytettävä yhtälailla esimerkiksi TV:stä kaukosäätimellä. Huomioon tulisi ottaa myös, että toisissa päätelaitteissa ei ole käytössä esimerkiksi Javascriptiä, Flashiä tai Javaa.

Tämä heterogeenisuus ei ole ongelma jos kaikki pelaavat yhteisten pelisääntöjen mukaan. Yhteisten pelisääntöjen noudattaminen on mahdollista, koska (suuria) laitevalmistajia on kuitenkin rajallinen määrä.

Tuorein haaste verkon kehityksessä on kuitenkin ns. WebView-kerros. WebView on älypuhelin sovelluksen (applikaatio) ominaisuus, jossa verkkosisältöä voidaan näyttää suoraan sovelluksessa.

Sovelluskehittäjälle tämä tarjoaa mahdollisuuden rakentaa nettisivusto ja tarjoilla sitä periaatteessa sellaisenaan applikaationa. WebView:tä käytetään myös natiiveissa sovelluksissa verkkosisältöjen tarjoilemiseen suoraan applikaatiossa ilman, että käyttäjää tarvitsee ohjata esimerkiksi puhelimen Safari-selaimeen. Sovelluksen näkökulmasta tämä on mukavaa, koska käyttäjä ei poistu sovelluksesta.

Etenkin jälkimmäisessä tapauksessa WebView:n tekee ongelmalliseksi se, että sovelluskehittäjä voi melko mielivaltaisesti ottaa käyttöön ja poistaa netin ominaisuuksia WebView:ssä.

Esimerkiksi tuoreessa Ilmakehä-jutussamme Ampparit-sovelluksen Webviewssä ei ilmeisesti oltu sallittu iPhonessa allowsInlineMediaPlayback-ominaisuutta, koska videosisällöt aukesivat määrittelystä poiketen koko ruudussa (full screen).

Vuosi 2017: "Toimiiko WebViewssä"

WebView on siinä mielessä haasteellinen, että virheiden korjaaminen siinä on erittäin vaikeaa ellei jopa mahdotonta. WebView on kehittäjälle mustalaatikko, jonka ominaisuuksista ja toiminnasta on todella vaikea saada palautetta.

Kuitenkaan toimivuutta WebViewssä ei voi ohittaa, koska esimerkiksi pikaviestin sovelluksissa (Facebook, Twitter) jaetut linkit jaetaan hyvin usein juuri WebViewssä. Toisaalta meillä Ylellä WebViewtä käyttävät myös Uutisvahti ja Yle.fi-applikaatio. Toisaalta taas erittäin suosittu WhatsApp avaa linkit (vielä) Safarissa.

Kehitys kehittyy!

torstai 6. maaliskuuta 2014

Python hoitaa, eli kuinka Plus-deski kokeili screen scrapingia

Kun keskustelu Keva-johtaja Merja Ailuksen työsuhde-eduista oli jatkunut jo jonkin aikaa, Yle:n toimittaja Jarno Liski alkoi pyöritellä mielessään kysymyksiä: kuinka kannattava työsuhdeasunnossa asuminen on, kuka siitä todella hyötyy ja millä tavalla työsuhdeasuminen otetaan verotuksessa huomioon. Hänen lähtöoletuksensa oli, että työsuhdeasuntojen verotusarvo vastaisi huonosti asunnoista vapailla markkinoilla maksettavaa vuokraa.

Liski otti yhteyttä Plus-deskin tuottaja Juho Salmiseen, joka lähti yhdessä Teemo Tebestin kanssa viemään asiaa eteenpäin. Lopputulos on nähtävissä täällä.

Verottajan väite syyniin

Verottajan mukaan asuntojen verotusarvo vastaa keskimäärin 90-prosenttisesti asunnosta pyydettyä vuokraa. Esimerkiksi 700 eurolla vuokrattavan asunnon verotusarvon pitäisi olla noin 630 euroa. Tämä tuntui kuitenkin pitävän huonosti paikkansa. Ideana olikin tutkia, minkä suuruisia verotusarvoja asunnot todellisuudessa saavat ja kuinka hyvin verotusarvo vastaa asunnoista pyydettävää vuokraa.

Verottaja määrittelee työsuhdeasunnoille laskukaavan, jonka avulla verotusarvo määritellään asuntokohtaisesti. Verotusarvon laskennassa vaikuttavat asunnon sijainti (pääkaupunkiseutu/muu maa), pinta-ala sekä valmistumisvuosi. Työntekijä saa asuntoedusta lisähyötyä silloin, kun verotusarvo on todellista markkina-arvoa selkeästi alhaisempi, koska tällöin hänen verotuksensa on keveämpi kuin sen tulisi olla.

Teemo ja Juho pohtivat, miten asiaan pääsisi käsiksi. Verottajan kaavan pitäisi tuottaa arvo, joka on hyvin lähellä markkinahintaa. Jarno Liskin idea oli kerätä suuri määrä olemassa olevien vuokra-asuntojen tietoja ja laskea asunnoille verottajan kaavan avulla verotusarvo.

Suomessa on muutama suuri vuokra-asuntoja listaava verkkopalvelu, joiden dataa olisi mahdollista käyttää verottajan kaavan testaamiseen. Käsityönä verotusarvon ja markkina-arvon kattava vertailu ei kuitenkaan onnistuisi, sillä vuokra-asuntoja on sivustoilla tuhansia.

Oli siis kirjoitettava koodinpätkä, jonka avulla pystyttäisiin keräämään tietyn verkkopalvelun vuokra-asuntoja koskeva data, laskea niiden perusteella asunnoille verotusarvo ja analysoida saatuja arvoja. Datan keräämiseen käytettävää menetelmää kutsutaan ruudunraavinnaksi (engl. screen scraping, tuttavallisesti screippaus). Asuntojen tiedot voisi poimia miltä tahansa vuokra-asuntoja listaavalta sivustolta. Teemo käytti tässä tapauksessa Alma Median ylläpitämän Vuokraovi.com-palvelun tietoja.

Koodi ja tietokanta valmiiksi

Ruudunraapijan kirjoittamiseen Teemo päätti käyttää Python-kieltä. Screipatessa kirjoitettu koodi käy järjestelmällisesti läpi verkossa olevia nettisivuja, poimii sivulta halutut elementit ja siirtää ne tietokantaan. Tietokannaksi Teemo valitsi ennestään tutun MongoDB:n. MongoDB sopi käyttötarkoitukseen hyvin, koska noSQL-tietokannassa datalle ei tarvitse määrittää tarkkaa rakennetta etukäteen, vaan sitä voidaan täydentää ja muokata tarpeen mukaan.

Kun Teemo laittoi homman aluilleen 29. marraskuuta, Vuokraovi-palvelussa oli tarjolla noin 6 000 vuokra-asuntoa eri puolilta Suomea. Yhdelle hakutulossivulle saa näkyviin kerrallaan 10–30 vaihtoehtoa, joten tarvittavien kyselyjen määrän minimoimiseksi Teemo sääti määrän maksimiinsa. Näin screipattavaksi jäi hieman yli 200 erillistä sivua, jolla jokaisella oli 30 asuntoa. (Kuva 1)

Helmikuussa 2014 Vuokraovi-palvelussa oli tarjolla n. 8 100 vuokra-asuntoa. (Kuva 1)
Datan keräämistä mutkisti se, että kaikki tarvittavat tiedot eivät löytyneet tältä hakutulossivulta. Koodin tuli käydä läpi myös jokaisen asunnon oma sivu, sillä asunnon rakennusvuotta ei mainita kaikkien asuntojen listauksessa. Kyselyjä piti siis lopulta tehdä 200 hakutulossivuille ja 6 000 yksittäisten asuntojen omille sivuille.

Teemon ensimmäinen ajatus oli kokeilla ScraperWiki -palvelua, jota hän oli kuullut käytettävän screippaukseen. Palvelu on ollut etenkin toimittajien suosiossa ja Teemo ajatteli, että palvelun testaamisen jälkeen hän voisi opettaa sen käyttöä muille toimittajille.

ScraperWiki mahdollistaa esimerkiksi Python-koodin kirjoittamisen ilman erillisten ohjelmointiympäristöjen asentamista. Siksi palvelu sopii esimerkiksi journalisteille, joilla ei usein ole mahdollisuutta tai taitoa asentaa kaikki tarvittavia ohjelmistoja. Teemo päätyi kuitenkin tekemään toteutuksen omalla koneella omassa ympäristössä, koska tämä oli lopulta hänelle kätevämpää.

Scraper käy läpi HTML-koodia ja tallentaa määritellyt osiot talteen myöhempää käyttöä varten. (Kuva 2)
HTML-merkkauksen siivouksessa ja käsittelyssä Teemo käytti hyväkseen BeautifulSoup-nimistä Python-kirjastoa. BeautifulSoup on kirjasto, jonka avulla verkkosivuilla käytetty HTML-merkkaus voidaan muuttaa koneelle ymmärrettävään muotoon. Lopulta koodi ryömi Vuokraovi.comin sivuja muutaman tunnin ajan. Ajo tehtiin vielä uudelleen lopullista uutista varten 2. joulukuuta.>

Trouble shooting vei aikaa

Kun Teemo testasi koodia ensimmäisiä kertoja, koodi ei hakenut dataa halutulla tavalla. Vian etsintään menikin hetki. Lopulta Teemo tajusi tutkiessaan HTTP-pyyntöä, että Vuokraovi.com -sivusto asetti Internet-selaimessa tukun evästeitä, eli cookieita, joiden puute esti scraperin toiminnan. Hän päätteli, että asian korjaamiseksi samaiset evästeet tulisi asettaa myös tietokoneohjelman tekemään HTTP-pyyntöön. Tällöin HTTP-pyyntö vaikuttaisi Vuokraovi.comin näkökulmasta täysin samanlaiselta kuin jos sen tekisi esimerkiksi Google Chrome -selaimella. (Kuva 3)

HTTP-pyyntöihin liittyvät evästeet näkee Google Chrome -selaimessa Inspect Element -valikon takaa. (Kuva3)
Joskus screipatessa voi käydä niin, että jos pyyntöjä tehdään suuri määrä, palvelin voi tulkita ne vihamielisiksi ja estää ne. Vuokraoven tapauksessa reilut 6 000 pyyntöä hukkui luultavasti normaalin verkkoliikenteen sekaan. Screippausta suunnitellessa kannattaa kuitenkin miettiä, voiko rajoituksista tulla ongelmia. Esimerkiksi hakukoneyhtiö Google tunnistaa tehokkaasti koneellisesti tehtävät haut ja estää ne, koska koneellisesti tehtävät haut ovat osa heidän maksullista palveluaan.

Toteutus on ladattavissa avoimena lähdekoodina (CC-BY-SA 4.0) Ylen Github-sivulta.

Yhden päivän työ

Ennen julkaisua aineistosta siivottiin pois sellaiset kohteet, joista puuttui jokin tarvituista tiedoista, kuten rakennusvuosi, sekä autotallit ja kalustetut asunnot. Näin aineistosta saatiin vertailukelpoista. Karsimisen jälkeen pohja-aineistoksi jäi noin 5 000 vuokra-asunnon tiedot. MongoDB:stä data tulostettiin .csv-muodossa ja vietiin Googlen Spreadsheets-taulukkolaskentaohjelmaan, jossa lopullinen verotusarvolaskenta tehtiin. Aineisto on ladattavissa Ylen sivuilta Excel-muodossa.

Jutun teknisten osien toteuttaminen järjesteltävine taulukoineen kesti noin työpäivän verran, joskin homma olisi sujunut nopeammin, jos eväste-ongelman selvittämiseen ei olisi mennyt aikaa. Jatkossa vastaavanlaisia toteutuksia tehtäessä evästeet osataan ottaa paremmin huomioon.

Eräs aineistosta tehty havainto oli, että erot markkinavuokrassa suhteessa verotusarvoon olivat alueellisia. Niinpä juttu sai otsikon: Asuntoedusta hyötyy eniten Helsingissä ja kehyskunnissa – katso oman kuntasi tilanne. Jutun yhteydessä käyttäjä sai tutkia asuntojen markkinavuokran ja verotusarvon eroa sekä kunnan että postinumeroalueen perusteella.

Aineisto myös paljasti, että verotusarvon ja markkina-arvon välinen vastaavuus oli keskimäärin 73 prosenttia, siis huomattavasti verottajan edustajan ilmoittamaa 90 prosenttia pienempi.

Juttu ei ollut varsinainen yleisömenestys. Asuntoedusta nauttii Suomessa alle 20 000 henkilöä, joten kohdeyleisökään ei ollut järin suuri. Vaikuttavuutta ei voida kuitenkaan mitata pelkästään lukijamäärän perusteella.

Screippaus-kokeiluna juttu oli Plus-deskille uusi aluevaltaus ja on hyvin todennäköistä, että tulevaisuudessa tällaisia omaan datan hankintaan perustuvia "skuuppeja" tulee enemmän.

Laita siis Python töihin!

Heidi Kähkönen
Kirjoittaja on vapaa toimittaja ja datajournalismikouluttaja
Twitter:  @heidikahkonen

perjantai 8. maaliskuuta 2013

Suomen kuntien koordinaattitiedot

Olemme tekemässä PlusDesk:ssä juttua, johon tarvitsemme Suomen kuntien sijaintien koordinaattitiedot. Sijaintitiedot ilmaisevat kaupungin sijainnin maapallolla korkeus- ja leveyskoordinaattien avulla. Nämä tiedot ovat saatavilla Wikipedia:n artikkelista: Luettelo Suomen kuntien koordinaateista. Kiitos Teemu:lle vinkistä.

Wikipedia-artikkelin data ei ole kuitenkaan nykyisen kuntatilanteen mukaista ja tarvitsimme nimenomaan vuoden 2013 kuntatilanteen mukaiset koordinaattitiedot (vuonna 2013 Suomessa on 320 kuntaa).

Olisin voinut rajata Wikipedia:sta löytyneen koordinaattisisällön vastaamaan nykytilannetta, mutta päädyin sen sijaan ottamaan Google Chrome:n Scraper-lisäosalla nykyisen kuntalistauksen toisesta Wikipedia-artikkelista nimeltä Luettelo Suomen kunnista ja syöttämään tiedot GPS Visualizer -palveluun. Palvelu geokoodaa annetut osoitetiedot WGS84-muodossa oleviksi korkeus- ja leveyskoordinaateiksi valitun rajapinnan avulla (Yahoo tai Google). Syötin kuntien nimet palveluun muodossa "{Kuntanimi}, Finland", jotta välttyisin sekaannuksilta mahdollisesti muualta maailmasta löytyviin vastaavan nimisiin paikkoihin. (Kuva 1)

GPS Visualizer -palvelu hyödyntää avoimia rajapintoja osoitetietojen geokoodauksessa. (Kuva 1)
Keräämäni data, jonka oikeellisuuteen kannattaa suhtautua varauksella, on saatavilla täältä:
Tulen tarkistamaan datan oikeellisuuden vielä myöhemmässä vaiheessa, mutta yksittäiskokeilujen osalta koordinaattitiedot näyttäisivät pitävän paikkansa. Keräämäni datan avulla loin sitten pudotusvalikon, josta käyttäjän on mahdollista valita haluamansa kunta, jonka jälkeen ohessa oleva kartta tarkentuu kyseisen kunnan kohdalle. (Kuva 2)

Käyttäjän on pudotusvalikosta mahdollista tarkentaa haluamaansa kuntaan. (Kuva 2)
Pudotusvalikon HTML-koodi näyttää siis yksinkertaisuudessaan seuraavalta:

<select id="selector">
   <option value="">Valitse kunta</option>
   <option value="">- - - - </option>
   <option data-lat="61.167408" data-lon="23.867642">Akaa</option>
   <option data-lat="63.00285" data-lon="23.803185">Alajärvi</option>

   <option data-lat="64.158003" data-lon="24.299759">Alavieska</option>
   <option value="...">...</option>
</select>


Kyseistä HTML-koodia en tallenna sellaisenaan sivun lähdekoodiin vaan luon valikon lennossa oheisella JavaScript-koodilla.

$.ajax({
  url: jsonUrl + '/data/kunnat.json',
  method: "GET",
  dataType: "json",
  success: function(data) {
    $.each(data, function(index, municipality) {
      $('#selector').append('<option data-lat="' + municipality.lat + '" data-lon="' + municipality.lon + '">' + municipality.m + '</option>');
    });
  }
});


Tämä pienentää sivun kokoa eli painoa ja pienentää siten latausaikaa, mutta toisaalta toki lisää selaimelle aiheutuvaa prosessointi kuormaa. Sivun pieni paino on kuitenkin tärkeämpää etenkin mobiilikäytössä. Nykyisille selaimille ja laitteille kyseisenkaltainen prosessointi on hyvin kevyttä.

(Muokkaus klo 8:26: JSON-muodossa data on ~16 kilotavua kun vastaava HTML-muotoinen data olisi ollut ~21 kilotavua. Ero on siis etenkin prosentuaalisesta näkökulmasta merkittävä. Toki myös pyyntöjen määrä olisi hyvä minimoida kuten @Duukkis osuvasti huomioi.)

Koodissa näkyvä kunnat.json on luotu aiemmin mainitusta Google-dokumentista lataamalla se .csv-muodossa koneelle ja syöttämällä tämä .csv-muotoinen data Mr. Data Converter -palveluun. JSON on yleisesti verkossa tiedon välitykseen käytetty tiedostomuoto. Kuntien koordinaattitiedot sisältävä .json-tiedosto näyttää seuraavalta:

{"m":"Akaa","lat":61.167408,"lon":23.867642},
{"m":"Alajärvi","lat":63.00285,"lon":23.803185},
{"m":"Alavieska","lat":64.158003,"lon":24.299759},
{"m":"Alavus","lat":62.586607,"lon":23.617282},
...


Tässä hieman valoa siihen miten käsittelen ja hyödynnän dataa. Julkaisemme itse toteutuksen, jossa käytämme tätä pudotusvalikkoa toivottavasti ensi viikon aikana, joten siitä kuulette vasta sitten.

maanantai 10. joulukuuta 2012

Datajournalisti vs. Internet Explorer

Tämä on tarina turhautumisesta ja liian pitkäksi venyneestä päivästä.



Tein yhteistyössä Eva Koskisen ja Pekka Palmgrenin kanssa Radar:lle muutaman visualisoinnin koskien amerikkalaisen Capital Group -investointipankin sijoituksia suomalaisissa pörssiyhtiöissä. Aiheesta julkaistu juttu löytyy täältä: Radar: Anonyma ägare på finska börsen

Visualisointien toteutus ja kasaaminen oli melko suoraviivainen ja nopea prosessi, koska käytin olemassa olevia komponentteja. Tämä oli tarkoituksenmukaista sillä muutamassa päivässä, jotka minulla oli aikaa ei ollut mahdollista lähteä toteuttamaan mitään laajempaa omaa ja uudenlaista toteutusta.

Juttuun toteuttamiani tiedonvisualisointikomponentteja oli kolme:
  1. pallovisualisointi, joka kuvaa Capital Group:n sijoitusten suuruutta yrityksissä. (Kuva 1)
  2. taulukko, josta on mahdollista vertailla tietoja perustuen yrityksen omiin kotisivuihin ja muualta kerättyihin tietoihin. (Kuva 2)
  3. pylväsdiagrammi, joka mahdollistaa valittujen yritysten omistajatietojen tarkastelun. (Kuva 3)
Pallovisualisointi kuvasi Capital Group:n sijoitusten arvoja eri yrityksissä. Värit oli asetettu satunnaisesti USA:n lipun väreihin. (Kuva 1)
Taulukosta oli mahdollista vertailla yksittäisen yrityksen omistajalistaa kahden eri lähteen perusteella. (Kuva 2)
Pylväsdiagrammista oli mahdollista selata halutun yrityksen suurimpia omistajia perustuen vaihtoehtoisesta tietolähteestä kerättyihin tietoihin. (Kuva 3)
Pallovisualisoinnin (Kuva 1) toteutin perustuen esimerkkiin, joka löytyy täältä:
http://vallandingham.me/vis/gates/

Samaa lähdekoodia on hyödynnetty mm. New York Times:n toteuttamassa visualisoinnissa, jossa käsitellään USA:n budjettia.

Pylväsdiagrammin toteutin D3-Generator -palvelun avulla. Muokkasin palvelun tuottamaa koodia vain niin, että käyttäjän oli mahdollista valita pudotusvalikon avulla tarkasteluun haluamansa yrityksen tiedot.

Taulukkovisualisointi toteutettiin leipätekstin sekaan sellaisenaan HTML:n ja CSS:n avulla. Kyseessä oli siis tavallinen <table>-HTML-taulukko.



Interaktiiviset visualisoinnit toteutin D3.js-JavaScript-kirjaston avulla. Kirjasto mahdollistaa graafisten elementtien yksinkertaisemman toteuttamisen samaan tapaan kuin jQuery helpottaa tavallisten JavaScript-toiminnallisuuksien toteuttamista. D3.js-kirjasto tarjoaa valmiita funktioita ja toiminnallisuuksia, joiden avulla esimerkiksi kuvassa 3 nähtävien pylväiden piirtäminen onnistuu vain muutaman koodirivin avulla.

D3.js:ää on käytetty maailmalla paljon ja se on Raphaël-kirjaston ohella yksi eniten käytetyistä JavaScript-kirjastoista mitä tulee interaktiviisten visualisointien toteuttamiseen selainympäristöissä. Vaikka D3.js on yleisesti käytetty ei se kuitenkaan ole ongelmaton kaikkien selainten suhteen. Tai pikemminkin kaikki selaimet eivät noudata Internet-standardeja siinä määrin, että D3.js:llä toteutetut visualisoinnit toimisivat niissä aina suoraan. Syyttävä sormi osoittaa tässä etenkin Internet Explorer -selaimeen ja sen vanhempiin versioihin (IE 8 ja vanhemmat).

Myös toteuttamani visualisointien kohdalla jouduin toteamaan, etteivät ne toimi IE 8:n ja vanhemmilla selaimilla. Virheilmotukseksi selain antaa:

CSSStyleDeclaration undefined

joka aiheuttaa, että koko D3.js-kirjasto jää määrittelemättä eikä visualisointi toimi siten lainkaan. Google:n avulla ongelmaan löytää D3.js:ään ja kyseiseen virheilmoitukseen linkittyviä aiheita, mutta mitkään niistä eivät tarjonneet toimivaa ratkaisua, jota olisin voinut hyödyntää.

Tilanne oli sinällään erittäin turhauttava, että visualisointi toimi hienosti missä tahansa modernissa selaimessa. Kuitenkin kun Yleisradio:n hiljainen lupaus on tuottaa sisältöä kaikille kansalaisille velvoittaa se ottamaan huomioon kaikki kohderyhmät. En kuitenkaan halunnut jättää toteutusta tämän lupauksen takia julkaisematta, koska olin käyttänyt jo suhteellisen paljon aikaa visualisointien toteuttamiseen.

Vaihtoehtoina oli pyrkiä korjaamaan virhe ja tekemään D3.js:stä paremmin yhteensopiva Internet Explorer -selaimen kanssa, mutta sinällään tämä tie olisi voinut olla hyvinkin kivinen ja aikataulullisesti haastava, koska toteutus tuli saada ulos seuraavana päivänä. Ratkaisuni oli päätyä toteuttamaan visualisoinneista erilliset versiot vanhemmille selaimille, jotka eivät vaatisi niin monimutkaisia JavaScript-toiminnallisuuksia.

Pallovisualisoinnille (Vis 1) toteutin version, joka toimii myös IE:llä (Vis 2) ottamalla kuvankaappauksen alkuperäisestä versiosta ja lisäämällä kuvankäsittelyohjelmassa eri yritysten tiedot visualisoinnin päälle käsin. Eli sen sijaan, että käyttäjän oli mahdollisuus osoittaa palloja hiirellä näytettiin hänelle kaikki data kerralla (joka ironisesti ehkä osoittautui kyllä paremmaksikin tavaksi esittää data).

Interaktiivinen D3.js toteutus näytti yritysten tiedon käyttäjän viedessä hiiren halutun yrityksen päälle. (Vis 1)
Staattisessa kuvassa kaikki yritysten tiedot olivat esillä heti. (Vis 2)
Pylväsdiagrammivisualisoinnissa taas otin kuvankaappaukset kaikista yksittäisten yritysten tiedoista (Kone, Sampo, Nokian Renkaat, Orion ja Nokia) ja muutin toteutusta niin, että datan interaktiivisen uudelleen piirtämisen sijaan visualisointia hallitaan CSS+JavaScript -toiminnallisuuden avulla. IE:lle optimoitu toteutus toimii niin, että kun käyttäjä klikkaa haluamaansa yritystä, piilottaa JavaScript-koodi CSS:n avulla kaikki muut kuin käyttäjän valitseman yrityksen kuvat näkyvistä. Tämänkaltainen toteutus on siinä määrin yksinkertainen, että edes IE ei pysty sen implementoinnissa epäonnistumaan. (Vis 3 & Vis 4)

Interaktiivisessa pylväsdiagrammissa käyttäjän oli mahdollista osoittaa yksittäisiä pylväitä saadakseen lisätietoja. (Vis 3)
Internet Explorer -selaimelle toteutetussa versiossa yrityksen valinta oli tehty linkkien avulla, jotka mukautuvasti näyttivät ja piilottivat kuvia. (Vis 4)
Leipätekstiin interaktiiviset visualisoinnit upotettiin <iframe>:n avulla seuraavasti:

<!--[if (lt IE 9)&(!IEMobile)]>
<iframe src="http://svenska.yle.fi/dataviz/capitalgroup/juttu3/fallback/index.html?l=se" width="400" height="560" frameborder="0" scrolling="no" style="overflow:hidden;">Laddar...</iframe>
<![endif]-->

<!--[if gte IE 9]><!-->
<iframe src="http://svenska.yle.fi/dataviz/capitalgroup/juttu3/index.html?l=se" width="400" height="560" frameborder="0" scrolling="no" style="overflow:hidden;">Laddar...</iframe>
<!--[endif]-->


Koodissa käytetään IE:n tunnistamia conditional comments -lausekkeita, jotka mahdollistavat IE:lle erityisten koodipätkien kirjoittamisen. Kyseisessä koodissa IE 9:ää vanhemmille selaimille tai IE:n mobiiliselaimelle näytetään yksinkertaistettu "fallback" versio toteutuksesta.

Internet Explorer yhteensopivuuden toteuttaminen vei aikaani siitä kun olisin voinut viimeistellä visualisointeja paremmiksi ja selkeämmiksi, joka aiheutti etenkin pallovisualisoinnin (Vis 1) kohdalla, että en ollut lopputulokseen täysin tyytyväinen.

http://stefanvermaas.nl/wp-content/uploads/2012/08/internet_explorer_fail.jpeg
Suosittelen kaikille esimerkiksi Google Chrome, Mozilla Firefox tai Safari -selaimia, joita käyttäessänne teette minun ja monen muun web-sovelluksia kehittävän ihmisen elämän todella paljon helpommaksi.

perjantai 6. heinäkuuta 2012

Esittelyssä datajournalistin työkalut, Osa 1

Datajournalismi kuten tekniikka usein vaatii tuekseen oikeat ja tehokkaat työkalut.
Vasarallakin saa laudan poikki, mutta saha toimii tarkoitukseen paremmin.
Ajattelin tuoda esiin viisi sellaista työkalua, joita itse käytän ja joiden käyttämisen koen olevan jokaisen datajournalismista kiinnostuneen opeteltavissa. Aloitan kuitenkin helppokäyttöisimmästä, jotteivät ei-teknisimmät henkilöt putoa heti matkasta.

SharedCount


SharedCount on yksinkertainen palvelu, joka mahdollistaa linkkien sosiaalisen median näkyvyyden tutkimisen. Palveluun on mahdollista linkittää mikä tahansa www-sivun osoite ja palvelu kertoo kuinka monta kertaa sivu on jaettu Facebook:ssa, Twitter:ssä, LinkedIn:ssä, Google+:ssa jne. Esimerkiksi Youtube-videota "The Canucks of Vancouver" on jaettu sosiaalisissa medioissa seuraavasti.

Palvelu on siis hyvin yksinkertainen käyttää ja siihen nähden se tarjoaa hyvin arvokasta tietoa sisältöjen leviämisestä sosiaalisessa mediassa. Sosiaalinen media on tärkeä osa datajournalismia ja siten myös sosiaalisen median toiminnan ymmärtäminen kuuluu siihen tärkeä osana. Toisaalta myös omien blogikirjoitusten ja vastaavien tuotosten leviämisen seuraaminen on SharedCount:n avulla kätevää.

Huomiotavaa etenkin kehittäjille on, että palvelu tarjoaa myös JSON-rajapinnan.

Google Trends


Mentäessä esiteltäviä palveluita eteenpäin tällä helppokäyttöisyysperiaatteella tulee seuraavaksi eteen Google Trends. Google Trends on nimensä mukaisesti Google:n työkalu, jolla on mahdollista tutkia hakusanojen suosiota. Palvelu ei ole kovinkaan tunnettu etenkään verrattuna Google:n muihin tuotteisiin, mutta ehdottomasti tutustumisen arvoinen. Palvelu toimii niin, että hakukenttään syötetään haluttu lista sanoja pilkuilla eroteltuna, jonka jälkeen palvelu kertoo kuinka paljon kyseisiä hakusanoja on Google:n avulla etsitty. Esimerkkinä tein haun suomalaisista kaupunkien nimistä, joissa on 2000-luvulla tapahtunut ampumistapauksia. (Kuva 1)

Suomalaisten kaupunkien hakusanojen suosiossa näkyvät selkeästi traagiset tapahtumat. (Kuva 1)

Google Trends:stä ovat selkeästi nähtävissä ampumistapauksien ajankohdat ja niiden vaikutus hakusanojen suosioon. Mielenkiintoinen kuriositeetti on, että kaupunginnimen suosio hakusanana on pienentynyt vuosien saatossa.

Google Trends on oiva työkalu tarkoitukseensa, joskin siltä ei kovin paljon enempää tule odottaa.

CometDocs


CometDocs:iin törmäsimme tässä blogissa edellisen viestin yhteydessä. Kyseessä on työkalu, joka muuntaa palveluun lähetetyt .pdf-dokumentit helpommin käsiteltäviin Excel tai Word -muotoihin. Palveluun on siis mahdollista lähettää taulukkodataa sisältävä .pdf-dokumentti ja palvelu muuntaa dokumentin parhaansa mukaan taulukkolaskentaohjelmien ymmärtämään .xls-muotoon.

Muunnokset eivät aina ole täydellisiä, koska .pdf-dokumenttien rakenteen tulkitseminen ei ole yksikäsitteistä. Esimerkiksi välilyönnit ja askelsarkaimet (tab) sekoittavat etenkin taulukkodatan tulkintaa. Yksittäisten virheiden korjaaminen jälkikäteen Excel:ssä on kuitenkin nopeampaa kuin koko datan siirtäminen käsin .pdf-dokumentista taulukkolaskentaohjelmaan. Vastaavanlaisia palveluita löytyy Google:lla useita ja myös esimerkiksi Acrobat Reader Pro -versiosta löytyy tämä vastaava toiminnallisuus.

CometDocs-palvelun huonona puolena pitäisin sitä, että palveluun joutuu antamaan sähköpostiosoitteensa, joka ei aina ole järkevää ja tätäkin palvelua käytettäessä suosittelen käyttämään jotain ei-niin-tärkeää sähköpostiosoitetta.

Scraper


Keskusteltaessa datajournalismista kuulee usein puhuttavan erilaisten raapijoiden, skreippereiden ja ryömijöiden toteuttamisesta. Erilaisia ryömijöitä ja keräimiä on tämänkin blogin yhteydessä käsitelty. Keräimet toteuteutaan usein ohjelmoimalla etenkin jos tekijällä on tähän kompetenssia ja kiinnostusta, mutta olemassa on myös työkaluja, joilla tietoa voidaan kerätä Internetistä ilman kovaa insinööritaustaa.

Erittäin näppärä työkalu tiedon keräämiseen löytyy Google Chrome -lisäosana ja on nimeltään Scraper. Scraper:n käyttämiseksi tarvet siis Google Chrome -selaimen, jota suosittelen muutenkin pääasialliseksi selaimeksi kenelle tahansa. Scraper:n asentamisen jälkeen toiminnallisuutta voi käyttää millä tahansa www-sivulla klikkaamalla haluaamaansa kohdetta ja valitsemalla kontekstivalikosta "Scrape Similar...", jonka jälkeen ruudulle aukeavasta ikkunasta ovat nähtävissä kaikki muut sivulta löytyvät vastaavankaltaiset sisällöt (Kuva 2).

Valitsemalla kontekstivalikosta "Scrape similar..." voit hakea ja tallentaa tietoa www-sivulta. (Kuva 2)

Olen itse käyttänyt Scraper:a mm. ihmisten Facebook-kavereiden hakemiseen ja tallentamiseen, koska Facebook ei suoraan tätä toiminnallisuutta tarjoa. Facebook-kavereiden tapauksessa lataan ensin kaikki halutun käyttäjän Facebook-kaverit selaimeni sivulle, jonka jälkeen klikkaan yhtä heistä ja valitsen "Scrape Similar...", jolloin Scraper tunnistaa kaikki sivulta löytyvät vastaavat sisällöt eli juuri nämä halutut kaverit. Scraper:lla haetut tiedot on mahdollista viedä Google Docs -palveluun, josta ne voi ladata edelleen vaikka omalle koneelle Excel:ssä käsiteltäväksi.

Scraper Similar -toiminto ei aina suoraan toimi oikein vaan "polkua", jonka takaa samankaltaista sisältöä haetaan voi joutua muokkaamaan. Haettava sisältö määritellään XPath-kielen (pikaopas) avulla, joka vaatii hieman teknisempää ajattelua, mutta jota ei välttämättä siis tarvitse käyttää jos "Scrape Similar..." -toiminnallisuus osaa suoraan palauttaa haluttavat sisällöt.

Google Fusion Tables


Tämänkaltaista listaa tehdessä ei varmaan voi ohittaa Google Fusion Tables:a. Kyseessä on Google:n toteuttama palvelu, joka on erikoistunut taulukkomuotoisen datan visualisoimiseen sekä eri datakokoelmien yhdistämiseen. Palvelusta löytyvät komponentit mm. perinteisten viiva-, piirakka- ja pylväsdiagrammien tekoon, mutta palvelulla on myös mahdollista luoda kartta- sekä verkostovisualisointeja.

Palvelu toimii osana Google Drive -palvelua ja uusia Fusion Tables -taulukoita pääsee luomaan Uusi -> Lisää -> Taulukko -polun takaa, jonka jälkeen palvelu pyytää lataamaan palveluun taulukkotiedoston. Tietoa voidaan syöttää mm. .csv ja .kml-muodoissa, joista jälkimmäinen on etenkin pinta-alojen esittämiseen tarkoitettu tiedostomuoto. (Kuva 3)

Uusien Fusion Tables -dokumenttien luominen löytyy More -painikkeen takaa. (Kuva 3)

On huomioitavaa, että Fusion Tables on nimenomaan valmiin datan visualisointityökalu. Datan muokkausmahdollisuudet palvelussa ovat hyvin rajalliset, joten data kannattaa rakentaa mahdollisimman valmiiksi paikallisessa taulukkolaskentaohjelmassa tai Google Spreadsheet:ssä.

Loistava itseopiskelumateriaali Google Fusion Tables:n käyttöön (Tekijä: Tommy Kaas).



Tässä muutamia sovelluksia ja ohjelmia, joista itselleni on ollut hyötyä ja joiden käyttäminen ei lähtökohtaisesti vaadi koodaamista. Toivottavasti tästä on hyötyä.