EBU Data Journalism Community eyes growth, further collaboration in 2020

Countries and members that have already made use of the data projects provided by the EBU News Exchange include Ireland (RTÉ), Germany (DW), France (FR24), Poland (TVP), Croatia (HRT), Switzerland (SRF), Finland (Yle). The Map was made with Mapchart.

We are nearing the end of the decade and I thought it was a good moment to catch up with you in terms of the data journalism initiative. If you are not familiar with the initiative you can catch up with the previous posts from this blog.

I have just two points!

FIRSTLY we have continued to share data stories and visualisation for you via the News Exchange and Social Newswire and we are keen to do this also in the future.

Here are some examples of the stories that we have provided to the members.

• Visualisation of Bitcoin value skyrocketing over the course of its existence
• Animation shows the evolution of the Arctic ice cap surface from 1979-2019
• Animation shows changes in temperature per country from 1901-2016

For example SRF/Switzerland used the Polar Ice Cap video on the SRF News Instagram account and the video got over 12,000 views. Another example comes from TVP/Poland who made use of the Bitcoin visualisation on their Facebook account. And just today DW/Germany released the temperature animation on their DW News Twitter account.

–––––––––––––––––––––

SECONDLY I’m keen to support the collaboration between EBU members. In September we organised a meeting in Hamburg for the members and we are planning to have the next event in the spring. We are also working together with the EBU Academy.

We are also looking into supporting data journalist exchange. We have a great community but we should and could learn more from each other. One way to accomplish this is to work with each others hands-on.

Tarjoilu ja puhutteleva kerronta – hyvän datajutun anatomia?

Julkaisimme 5. marraskuuta jutun:

• "Haaveiletko eläkkeestä? Katso laskurista, milloin eläke alkaa ja kauanko se kestää"

Viikkoa aiemmin Helsingin Sanomat julkaisi jutun:

• "Rahaa ei kartu niin kuin pitäisi: Näistä syistä suomalaisten eläkemaksuja uhkaa korotus – selvitä HS:n laskurilla, milloin voit jäädä eläkkeelle"

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.

Luulitko olevasi suomalainen? Testaa! – 6 syytä menestykseen

Julkaisimme nelisen kuukautta sitten 28.4.2014 Yle Uutisten sivuilla testin otsikolla "Luulitko olevasi suomalainen? Testaa!".

Juttu oli mieletön hitti. Tähän päivään mennessä sitä on kommentoitu, tykätty ja jaettu Facebookissa yli 130 000 kertaa. ComScore-palvelun tuottaman raportin mukaan juttu on tähän mennessä klikattu auki yli 600 000 kertaa. Huikeita lukuja. Aikaisemmin Yle Uutisten luetuin juttu oli kerännyt noin 350 000 klikkiä – Facebook-ennätyksen ollessa noin 50 000 toimintaa.

Aloitimme jutun työstämisen pari kolme viikkoa ennen julkaisua, jolloin kokoonnuimme – noin viiden hengen porukalla – pohtimaan mitä haluamme tehdä. Tarkoituksenamme oli tehdä jotain sellaista kiinnostavaa verkkoon, joka tukisi Eve Väyrysen ja Sean Ricksin EU-kiertuetta ja toisi sille näkyvyyttä. Suurempana kokonaisuutena juttu kiinnittyi lähestyneisiin eurovaaleihin. (Kuva 1)

Testi toimi lähtölaukauksena Even ja Seanin EU-kiertueelle. (Kuva 1)

Mielestäni seuraavat kuusi asiaa ovat tunnistettavissa tämän jutun menestyksen takaa.

• Onnistunut kysymysten asettelu
• Yksinkertainen ja kompakti käyttöliittymä
• Päätelaiteriippumattomuus
• Personoitu somejako
• Dataa, ei dadaa
• Monimediallinen toteutus

Onnistunut kysymysten asettelu

Lähtökohtamme oli, että halusimme tehdä jonkinlaisen testin tai koneen, joka yllättäisi tekijänsä siitä näkökulmasta, että emmehän me eurooppalaiset yksilöinä juurikaan poikkea toisistamme. Teknisen toteutuksen osalta otimme esikuvaksemme aikaisemmin keväällä julkaisemamme Leijonakone:en.

Tavoitteenamme oli tuoda sinällään kaukaisilta tuntuvat euroaiheet lähemmäksi yksilöä. Halusimme kysyä mieluummin oletko luottavainen omaan talouteesi kuin, että tulisiko mielestäsi EU:n kriisimaita tukea. Halusimme, etteivät kaikki kysymykset liittyisi tiukasti esimerkiksi politiikkaan tai talouteen vaan ihan ihmisten jokapäiväiseen käyttäytymiseen kuten kahvin juontiin. Tämän kaltaisten arvoihin ja käyttäytymiseen liittyvien kysymysten kautta halusimme määritellä, jokaiselle testin tekijälle minkä EU-maan kansalaisten keskiarvoa hän muistuttaa eniten.

Halusimme, että kysymykset olisivat samaistuttavia ja selkeitä. Tämänkaltaisissa testeissä tai kyselyissä jo yksi vaikea kysymys saattaa aiheuttaa, että tekijä turhautuu ja jättää testin kesken. Halusimme myös välttää sellaisia kysymyksiä, jotka eivät olisi relevantteja jollekin ihmisryhmälle. Kysymysten tulisi olla sellaisia joihin voi nopeasti muodostaa jonkun mielipiteen.

Vastuu kysymysten valitsemisesta jäi lopulta Sean Ricks:in harteille, mutta etenkin viimeistelyvaiheessa käytimme aikaa isommalla porukalla miettien mitkä kysymykset lopulta päätyivät testiin ja missä järjestyksessä kysymykset olivat.

Yksinkertainen ja kompakti käyttöliittymä

Suunniteltaessa käyttöliittymiä on usein hyvä pyrkiä tiiviiseen ja yksinkertaiseen ilmaisuun, jossa keskitytään olennaiseen. KISS-ajattelumalli on aivan ehdottomasti lempisuunnitteluperiaatteitani.

Oletko suomalainen -testissä tämä onnistui erityisen hyvin. Kymmenen kysymystä ja vastausvaihtoehdot sisältänyt käyttöliittymä saatiin rakennettua niin, että se mahtui useimmilla laitteilla yhdelle ruudulle. Tämä on hyvä, koska tällöin testin tekijällä on heti käytössään visuaalinen vinkki siitä mitä ja kuinka paljon hänen tulee tehdä saavuttaakseen lopputulos. Pitkät lomakkeet, jotka on jopa jaettu useammalle sivulle, ovat luontaantyöntäviä.

Tämän lisäksi kysymyksiin vastaaminen oli tehty mahdollisimman helpoksi. Emme esimerkiksi käyttäneet teknisesti vastauskomponentteina valintapainikkeita (radiobutton), joita on niiden pienuuden takia vaikea klikata tai täpätä, joka voi olla turhauttavaa. Olemme empirian kautta havainneet, että ihmiset yrittävät usein painaa juurikin sitä pientä valintapainikkeen palluraa vaikka valinnan tekeminen suuremmaltakin alalta (esimerkiksi klikkaamalla tekstiä). Oli siis perusteltua rakentaa täysin uniikki tapa valita vastaus. (Kuva 2)

Käyttöliittymä oli yksinkertainen ja kompakti. (Kuva 2)

Päätelaiteriippumattomuus

Mobiili, mobiili ja vielä kerran mobiili. Oletko eurooppalainen -testin kävijoistä yli 40 % tuli julkaisuviikolla mobiililaitteista. On siis ensiarvoisen tärkeää, että sisällöt ovat kulutettavissa mahdollisimman laajalla laiteskaalalla. Ei voida olettaa, että lukija etsisi sisällön uudelleen käsiinsä esimerkiksi kotonaan jos hän on nähnyt sen esimerkiksi bussissa mobiililaitteella, jossa se ei ole toiminut.

Testasimme testin toimivuuden yleisimmillä mobiililaitteilla ennen julkaisua. Testilaitteistona meillä oli ainakin:

• Android-puhelin
• Iphone-puhelin
• Windows Phone 8-puhelin
• iPad ja iPad -mini-tabletit

Pyrimme aktiivisesti myös, että toteutamme verkon sisältöä erityisesti mobiilikäyttö mielessä. Eli pohdimme miten tämänkaltainen testi olisi mahdollisimman kiva tehdä ja esittää mobiililaitteilla. Kun tilaa on lähtökohtaisesti käytössä vähemmän auttaa se keskittymään olennaiseen (KISS). Ja useinkaan mobiilissa toimivaa versiota ei ole ongelma laajentaa työpöytäkäyttöön sopivaksi kun taas työpöytäkäyttöön suunnitellun toteutuksen sovittaminen mobiililaitteille vie potentiaalisesti paljon aikaa. (Kuva 3)

Mobiiliversiossa kysymykset sijoitettiin vastausvaihtoehtojen päälle ja vastauksen valintapainikkeista tehtiin isompia. (Kuva 3)

Personoitu somejako

Uutissisältöjen näkyvyydessä sosiaalinen median rooli kasvaa tasaisesti. Suuria lukijamääriä on nykyään mahdotonta saavuttaa ilman merkittävää somepresenssiä. Kaikki Yle Uutisten sisällöt onkin mahdollista jakaa normaalin jakotoiminnallisuuden kautta, jolloin lukija jakaa linkin kyseiseen sivuun.

Tämän kaltaisissa testeissä on kuitenkin hyvä, että lukija voi jakaa suoraan testistä saamansa tuloksen. Eli tässä tapauksessa kertoa minkä maan kansalaisia hän muistuttaa eniten.

Se, että sosiaalisessa mediassa jaetaan erityisesti testistä saatu tulos eikä vain linkkiä testiin, motivoi kokemuksieni mukaan myös muita tekemään testin. On hyvin tavallista esimerkiksi, että joku jakaa oman testituloksensa Facebook:ssa ja muut kommentoivat tätä jakoa omilla tuloksillaan. Syntyy keskustelua, joka taas herättää kiinnostusta sisältöön ja nostaa muutenkin – esimerkiksi Facebook:n silmissä – sisällön arvoa ja näkyvyyttä.

Eurooppalaisuustestissä panostimme myös erityisesti jakokuvaan. Pyrimme aina siihen, että jakokuva olisi jotain muuta kuin geneerinen Yle-logo, mutta Eurooppatestissä teimme vielä erikseen jokaiselle tulokselle eli maalle oman jakokuvan eli maakohtaisen passin. Tämä pieni yksityiskohta toi jakamiseen vielä jotain erityistä kun somessa pystyi jakamaan uuden EU-passinsa. (Kuva 4)

Jokaiselle maalle oli kirjoitettu personoitu kuvaus. Testin tulos oli mahdollista jakaa sosiaalisessa mediassa. Kuva maan passista välitettiin somejaon mukana. (Kuva 4) 

Dataa, ei dadaa

Vaikka testi oli leikkimielinen oli sen taustalle kerätty hyvin tarkkoja aineistoja. Käytimme lähteinä Eurostat:ia, Eurofound:ia, World Resources Institute:a ja YK:ta. Aineistojen perusteella pystyimme luomaan maakohtaiset profiilit, joita sitten verrattiin lukijan antamiin vastauksiin.

Maakohtaiset profiilit luotiin niin, että aineistojen perusteella jokainen maa laitettiin jokaisen kysymyksen osalta kategorioihin 1–5 (eli samat viisi kuten toteutuksessa olevat vastausvaihtoehdot).

Kategorisointi tehtiin tasajaolla niin, että katsottiin jokaisen aineiston vaihteluväli ja jaettiin tuo vaihteluväli viiteen tasaväliseen kategoriaan. Tämän jälkeen katsottiin jokaisen maankohdalla, että mihin kategoriaan maa sijoittuu omalla arvollaan. Esimerkiksi kahvin juonnin osalta Luxemburgin arvo oli niin suuri verrattuna muihin, että tasavälisessä kategorisoinnissa vain luxemburgilaiset saivat arvon viisi. Näin esimerkiksi suomalaiset tippuivat neloskategoriaan ja esimerkiksi teetä juovat britit kuuluivat vain vähän kahvia kuluttavaan ykkös-kategoriaan.

Teknisesti testi toimi datan osalta niin, että näitä maiden profiileja verrattiin lukijan antamiin vastauksiin ja laskettiin minkä maan vastauksia nämä muistuttivat eniten.

Vaikka testi siis oli leikkimielinen se ei kuitenkaan ollut humpuukia.

Monimediallinen toteutus

Yle:llä meillä on mahdollista hyödyntää meidän monikanavaista julkaisuportaalia.

Eurooppalaisuustestin kohdalla tämä näkyi niin, että otimme sen osaksi eurovaalien puheenjohtajatenttejä. Testi teetettiin jokaisella Aamu-tv:ssä vierailleella puoluejohtajalla. Eli saman verkosta löytyvän testin, jonka jokaisen oli myös itse mahdollista käydä täyttämässä.

Tämä piti osaltaan testin pinnalla viikkojen ajan kun eri puoluejohtajat kävivät Aamu-tv:n vieraina. Kaikkien puheenjohtajien tulokset myös analysoitiin ja käsiteltiin verkossa vielä erikseen.

Ensimmäisenä testi teki heti Jyrki Katainen. (Kuva 5)

Puoluejohtajat testasivat oman henkisen kotimaansa Aamu-tv:n puheenjohtajatenttien yhteydessä. (Kuva 5) 

Myös useissa radiolähetyksissä käsittelivät aihetta ja kertoivat esimerkiksi testillä saadun oman henkisen kotimaansa.

Social network analysis of one's Facebook friends

This blog post is in English as you may have noticed. It is made for a training session held at Södertörn University for the Swedish media organizations.

Objective:
Create a network visualization of one's Facebook friends.

Requirements:
Gephi, Python, MongoDB, Google Chrome, Scraper, Google Account

0. Network visulialization examples 

First here are some of examples where network analysis has given insigth to the given story.

1. Social network analysis of a shooter suspect's Facebook friends
2. Probing the murky web of foreign ownership in Finnish firms
3. Spotlight - Party of the True Finns and islamophobia

As you can see network visualizations can be used in various ways. They can be used both in the background and also as an interactive end user application.

 1. Get your Facebook friends

Your own Facebook friends data is available through Facebook API. To access your Friends list through Facebook API browse to address:
https://graph.facebook.com/me/friends?access_token={place_valid_access_token_here}

A valid access token can be acquired from Graph API Explorer. (Pic 1)

You can get your own Facebook friends data from Facebook API in JSON format fairly easily. (Pic 1)

But only your own Facebook friends data is available through the API. So if you desire to get the friends data of any other profile it is vital to know that it is not available through Facebook API. So if you want to make a social network analysis of your friend's Facebook friends you need to make a little detour.

The detour here is called screen scraping. Screen scraping is a method where we use the computer to read the data what we see on our screen. We do this while computers are much faster doing it and make less mistakes. At simplest screen scraping is done from one page but it can be done from any number of pages.

A tool called Scraper is a very good for doing this when we just need to scrape data from one to two pages. Scaper is Google Chrome addon. if you desire to know more see a tutorial by Jens Finnäs.

For scraping we will use Facebook's mobile interface while it has much simpler outlook. This is nice when doing screen scraping because we have to deal with less code.

The following steps allow you to screen scrape your own friends list (that was also available through the API).

1. Go to your Friends list. It is located at https://m.facebook.com/{place_your_username_here}?v=friends
2. First scroll down as many times you need to get all of your friends to show on the screen. To achieve this it is quite handy to used the pagedown functionality. You may experience problems if you have more than 500 friends or so.
3. Next open the context menu while clicking one of your friend and from the context menu select scrape similar. You need to have the Scraper plugin installed and enabled. (Pic 2)
4. After clicking scrape similar you'll get a new window. On the left side you can define what you are scraping for and on the right side you see what you get. (Pic 3)
5. To define what you are looking for you need to use either XPath or jQuery. The default selection is XPath and that suits us. Enter the following code without the quotes into the available field "//div[@class='_4mn c']/a" and click Scrape. What the code says is that we want to get the anchor elements (aka. links) which are located under a <div>-element which has class attribute value "_4mn c". In the section columns set XPath to "@href". That tells the code to fetch the @href parameter from those anchors.
6. Export the dataset to Google Docs and open the document in Google Docs. Remove unnecessary columns B to E.
7. Download the data as a .csv-file to your local computer. File -> Download as -> Comma separated values (.csv, current sheet)

(Pic 2)

(Pic 3)

 2. Create the connections between friends

Now we have a .csv-file of all your friends. From this we could make a network visualization which would show that all your friends are connected to you.

What we want to do is to figure out how your friends are connected which each other. This can be accomplished via Facebook API's Friend property which allows us to ask wheater to Facebook profiles are friends with each other. This is nice while you can do this for any two Facebook profiles regardless of their privacy settings.

Key point here is that one can't ask Facebook API who are all the friends of a Facebook profile. But one can ask one-by-one wheather to profiles are friends. So if you have a list of Facebook profiles it is possible to make the network. And as you may have realized we have list while we have screen scraped it. This also means that sometimes you can't get the profile list you deside due user's privacy settings. For example users can hide their friends list from users that they have not friended.

But how to use the Friend property. One can access it via Graph API Explorer which we already used to acquire the proper access token.

With Graph API Explorer we could make the network by hand by entering all the queries to Graph API one-by-one. For example the query:

"SELECT uid1 FROM friend WHERE uid2 = 635279474 AND uid1 = 732028610"

tells us whether these to user id's are friends with each other. But for any larger network this would be a pain in the ass while you would have to make hundreds and hundreds of queries. (Pic 4)

(Pic 4)

Fortunately this is not the case. I have written a Python script that does the work for us. But unfortunately I'm quite sure that the script won't work out of the box for most users.

Download the script.

Place the script file in some good place where you can access it. Copy also the .csv-file that same folder. Next open terminal, browse to that folder and run:

python facebook_network.py {filename} ({use_existing = True|False})

for example:

python facebook_network.py teemo_tebest.csv False

When you are asked for an access token please refer to Graph Api Explorer to get one. You may phase several problems while running the script. First check that you have Python installed. Secondly you need a running MongoDB. Thirdly you need to have atleast two Python libraries installed called pyfacegraph and pymongo. (Pic 5)

The script need to be run in terminal environment. (Pic 5)

The script runs for a while. First it fetches all the metadata available from the profiles. After that the script forms the connecions between the users. After all is done the script outputs the data into a network file format.

3. Visualize the data with Gephi

Now that we have the data in a network format (.gexf) we can visualize it with available tools. One great and free tool is called Gephi.

If you failed to form your own dataset you can download and example dataset.

First open Gephi and use the basic file opening functionality to open the .gexf-file created in the previous step. You'll see a pop up window that gives you an overview of the data. After Gephi has loaded the data you'll see a junk of data. (Pic 6)

The data is layouted randomly when the file is loaded for the first time. (Pic 6)

Without adjusting any settings we don't get much out of the data. We can zoom into it and point single nodes to see the edges leaving from it but that is just it.

What we need to do is to define the layout algorithm, the node size and the color values for the nodes to get more out of the data.

Just to make clear:
Node: balloon
Edge: connection between nodes.

For social networks a layout algorithm called ForceAtlas2 is a proper choise so we will use that. Check that your settings are as in the picture. (Pic 7)

ForceAtlas is great for social networks. Other available layout algorithms include for example Geo Layout. (Pic 7)

After you hit run you'll see the magic happening in just a few seconds. The nodes are settled in the network based on the edges between them. Meaning that the nodes which have more connections between each other are grouped closer to each other and the nodes that have less connections to each other are torn apart.

Next you want to define the colors and the node sizes. But before then you need to count some figures. Mainly you want to run Modularity and Eigenvector centrality. Modularity will divide the nodes into groups and eigenvector centrality will allow us to define the node size. (Pic 8)

Statistics can be calculated from the right side. (Pic 8)

Now we can use these figures to define the colors. (Pic 9)

You can change the colors if you want. (Pic 9)

And the node sizes. (Fig 10)

You may define the min and the max node size. (Pic 10)

After doing so your network could look example like this. (Pic 11)

The separate groups are in different colors defined by Modularity and the node sizes tell how central the node is in the network. (Pic 11) 

You can zoom into the groups and point out single nodes to see the edges. To enable the labels click the small arrow icons below the network. (Pic 12)

You may enable the node labels. (Pic 12)

You are all done. You may adjust your colors and nodes sizes. You can test for example to use the gender information to define the colors. You can also try other layout algorithms to see what is available.

See also Olli Parviainen's great slides about visualizing your Twitter network with Gephi. Slides 8 to 17 show you the main visualizing steps inside Gephi that we've also used here.

4. Summary

Using network visualizations to show the connections between your Facebook friends or social media connections in general is a great way to make insight.

There are also several Javascript tools available that enable you to publish your network online as an interactive visualization:

• Gexf-js
• Sigma.js

Network visualizations are not that familiar way of visualization for a common user. Not like bar charts or maps. People tend not to understand what they are about and call them these odd spyderweb visualizations.  From this perspective I am not that eager to publish them online. But for professionals like journalists and programmers network visualizations can give real good insigth into the data. Knowing how to do network visualization gives you most often an unique perspective that no one else have thought of.

PlusDesk ja elämää hetkessä

Olen nyt ollut kaksi viikkoa osa Yle Uutisten PlusDesk-toimitusta. PlusDesk on Uutis- ja ajankohtaisorganisaatioon perustettu toimitus, jonka tehtävä on auttaa mm. uutis- ja urheilutoimituksia netin omaisten sisältöjen toteuttamisessa. Ajatuksena on, että PlusDesk yhdessä toimituksien kanssa tuottaa netinomaista sisältöä netin ehdoilla. Tarkoitus ei siis ole, että vastuu nettijuttujen tekemisestä jää pelkästään PlusDesk:n vastuulle.

Tiimimme kuuluu kaksi tuottajaa (Juho Salminen ja Mika Pippuri), kolme graafikkoa (Juha Rissanen, Stina Tuominen ja kolmas vielä vielä nimeämätön henkilö) sekä yksi toimittaja/datajournalisti eli allekirjoittanut. Toimintamme on orientoitumisviikon jälkeen tällä viikolla pyörähtänyt käyntiin ihan juttujenkin toimesta ja olemmekin ehtineet olemaan mukana yhteensä viiden eri julkaistun jutun teossa. Yhtenä tavoitteenamme on avata prosessejamme mahdollisimman paljon niin sisäisesti kuin talon ulkopuolellekin ja tässä kuvaus eräästä jutusta, jolle oli ominaista etenkin eläminen ajassa.

---

Perjantaiaamuna Yle Uutiset uutisoi, että brittiläinen professori Nick Trefethen oli kehittänyt uuden laskukaavan laajalti painonhallinnassa käytetyn painoindeksin laskemiseen. Verrattuna alkuperäiseen uusittu indeksi painottaa hieman eritavalla laskennassa käytettäviä ihmisen pituutta ja painoa. Alkuperäinen Adolphe Quetelet keskimä malli laskee painoindeksin niin, että paino jaetaan pituuden neliöllä:

paino (kg) / pituus (cm) * pituus (cm)

Trefethen:n kehittämässä mallissa paino kerrotaan 1,3:lla ja pituus korotetaan potenssiin 2,5. Kaava on siis muotoa:

1,3 * paino (kg) / pituus (cm) ^2,5

Toinen tuottajistamme Mika Pippuri keksi puolenpäivän aikaan, että voisimme pikaisesti kyhätä tähän uuteen malliin perustuvan laskentakoneen, jonka avulla lukijat voisivat nopeasti laskea oman "uuden" painoindeksinsä ja verrata sitä vanhaan. (Kuva 1)

Kuvankaappaus artikkeliin upotetusta painoindeksikoneesta. (Kuva 1)

Innostuinkin ideasta siinä määrin, että jätin työnalla olleen kiireettömämmän projektin kesken ja lähdin toteuttamaan painoindeksikonetta. Intuitioni oli lähteä toteuttaa HTML-muotoista lomaketta ja sille PHP-käsittelijää, joka nappaisi lomakkeelta lähetetyt tiedot ja palauttaisi käyttäjälle vastauksen. Mika kuitenkin löysi valmiin JavaScript-pohjaisen koodin pätkän painoindeksin laskentaan, joka ohjasi minut toteuttamaan laskurin JavaScript:llä. JavaScript toteutus oli myös lähtökohtaisesti parempi, koska se ei pakottanut käyttäjää lataamaan sivua uudelleen ja oli siten mukavampi käyttää. Jälkikäteen hieman ärsyttää, että lähtökohtani ei ollut JavaScript-pohjainen ratkaisu, mutta tämä pistettäköön perjantain ja erittäin kiireisen viikon piikkiin.

Tämänkaltaiset erikoistoteutukset viemme Yle Uutisten sivuille ns. ulkoisina upotuksina. Toteutuksien koodit sijoitamme erilliseen ympäristöön käyttämämme Escenic-järjestelmän ulkopuolelle ja tuomme ne Escenic:iin ulkoisena sisältötyyppinä. Ulkoinen sisältötyyppi määrittelee itselleen kolme resurssia:

• HTML tai PHP resurssi
• CSS-resurssi(t)
• JavaScript-resurssi(t)

Tämä ulkoinen sisältötyyppi on mahdollista liittää normaaliin uutisartikkeeliin samaan tapaan kuin esimerkiksi kuva. Samoja ulkoisia sisältötyyppejä on mahdollista käyttää useaan kertaan, mutta tällä hetkellä ulkoinen sisältö voidaan sijoittaa vain joko artikkelin alkuun tai loppuun. Tällä samalla tekniikalla tuomme järjestelmään myös esimerkiksi Google:n sisällöt kuten kartat (Google Maps) ja lomakkeet (Google Form).

Toimituksellisesti teimme vielä sellaisen päätöksen, että sijoimme painoindeksikoneen erilliseen artikkeliin sen sijaan, että olisimme päivittäneet sen osaksi aiheesta jo kirjoitettua artikkelia. Näin saimme toteutuksellemme paremman näkyyden, koska saavutimme paremmin myös ne käyttäjät, jotka olivat jo lukeneet alkuperäisen aamulla julkaistun jutun.

Painoindeksikone nousikin nopeasti sivuston luetuimmaksi jutuksi ja piti paikkansa aina siihen asti kun ehdin poistua toimistolta. Vertailuluku seuraavaksi luetuimpaan juttuun viimeisimmän tunnin aikajaksolla mitattuna oli sen suuntainen, että tämä painoindeksikoneemme oli n. kolme kertaa luetumpi kuin koko yle.fi-domainin seuraavaksi luetuin sivu.

Selkeimpänä kehitysideana tuli itselleni mieleen, että olisi ollut kätevää ja käyntimäärien kannalta positiivista jos painoindeksikoneen antaman tuloksen olisi voinut jakaa Facebook:ssa ja muissa palveluissa. Koimme kuitenkin, koska kello alkoi lähennellä iltapäivää, että on tärkeämpää saada toteutus vain mahdollisimman nopeasti julki. Seuraavalla kerralla kun prosessit ovat muutenkin suoraviivaistuneet varmaankin otamme myös tämän aspektin huomioon tämänkaltaisissa toteutuksissa.

Edit: Muokatta Stina Tuomisen nimi oikeaksi ja lisätty linkki JavaScript-koodiin, jonka pohjalta toteutusta lähdettiin tekemään.

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ä.

Hyvinkään ampumistapaus

Hyvinkäällä perjantain ja lauantain välisenä yönä tapahtuneen ampumistapauksen jälkipuinti on eri medioissa ollut tilanteelle ominaisen aktiivista. Tuttuun tapaan myös erilaiset keskustelupalstat ovat täyttyneet aiheeseen liittyvästä keskustelusta. Esimerkiksi Muropaketti-foorumi on nyt ja aikaisemmien tapauksien yhteydessä täyttynyt aktiivisesta keskustelusta. Lisäksi Twitter on nostanut arvoaan suomalaisten tapahtumien tiedonhaun välineenä. #Hyvinkää-hashtagia käytettiin aktiivisesti ja esimerkiksi @tuomaspeltomaki:n Twitter-tilistä sai ajantasaisimman tiedon koskien Poliisin lauantaiaamuna järjestämää tiedotustilaisuutta.

Epäillyn ja uhrien nimet sekä taustat ovat siis olleet nettikansan tiedossa jo pitkään. Poliisi itsessään ei ihmisten henkilöllisyyksiä paljasta vedoten yksityisyyden suojaan ja muihin teknisiin perusteisiin. Uteliaita ihmisiä on kuitenkin vaikeaa estää pääsemästä heitä kiinnostavan tiedon äärelle kun ihmisten etsiminen netin avulla on niinkin yksinkertaista ja nopeaa. Petteri Järvinen otti asiaan kantaa eilen blogissaan otsikolla "Netti tietää sen, mitä poliisi ei kerro".

Itsekin Googletin tämän valtamedioissa mainitun ja käsitellyn epäillyn julkisen Facebook-profiilin, koska halusin tehdä verkoston hänen kaveripiiristään. Lataushetkellä hänellä oli kavereita 64, joten katoa on käynyt, koska enimmillään kavereita on lukemani perusteella ollut lähempänä tai yli 100. Tein kuitenkin analyysin jäljellä olevien kavereiden välisistä yhteyksistä. (Kuva 1)

 Epäillyn Facebook-kaveriverkosto on tiheä, josta voidaan päätellä, että he ovat kaikki samasta fyysisestä ympäristöstä. Miehet (89%) kuvattu sinisellä ja naiset (11%) punaisella. (Kuva 1)

Ajattelin, että olisi mahdollista, että epäillyllä olisi jokin ns. normaalin koulukaveriympäristön ulkopuolinen kaveriryhmä, joka voisi selittää hänen käyttäytymistään jollain tavalla. Näin ei kuitenkaan ollut vaan henkilön Facebook-kaverit ovat verkostoituneet toistensa kanssa keskenään tiheästi eikä vahvaa ryhmäytymistä ole havaittavissa. (Kuva 1)

Visualisoinnin ja aikaisempien kokemuksieni perusteella voin tehdä oletuksen, että henkilön kaverit ovat näin ollen samasta fyysisestä ympäristöstä ja tuntevat toisensa. Toisin sanoen epäilty tuskin on muuttanut nuoruutensa aikana paikkakunnalta toiselle tai muuten ollut tekemisissä kovinkaan paljon kotipaikkakuntansa ulkopuolisten ihmisten kanssa. Facebook-kaveriverkosto ei myöskään anna kuvaa siitä, että henkilöllä olisi kovinkaan paljon esimerkiksi netin kautta hankittuja ystäviä, koska he erottuisivat verkostossa useampina yksittäisinä pisteinä. Nyt 64:n kaverin joukossa on kuusi henkilöä, jotka eivät ole epäillyn muiden kavereiden kanssa kavereita.

Näillä mietteillä mielenrauhaa kaikille.

Verkostoanalyysiä televisiossa

Viime viikolla esitetyssä Spotlight-ohjelmassa (nähtävissä Yle-Areenassa kuukauden ajan) käsiteltiin suomalaisten poliitikkavaikuttajien kytköksiä äärijärjestöihin (Kuva 1). Ohjelmassa olivat esillä etenkin Perussuomalaispoliitikkojen kytkökset Finnish Defence League:en (FDL), joka on English Defence League:n (EDL) suomalainen alijärjestö. Ohjelma on osa juttusarjaa, joka käsittelee islaminvastaisten järjestöjen toimintaa, jota Spotlight:n lisäksi tekemässä on myös Silminnäkijä. Aihe on tällä hetkellä ajankohtainen ja keskustelua herättävä.

Spotlight on tutkivan journalismin ajankohtaisohjelma, jota lähetetään Yle Fem -kanavalla torstaisin. (Kuva 1) 

Ohjelmassa tietoa Perussuomalaispoliitikkojen ja FDL:n yhteyksistä etsittiin erityisesti Internetistä kerättyjen tietojen avulla. Etenkin Facebook:sta kerätyt tiedot olivat keskeisessä osassa, mutta Perussuomalaisia FDL:ään liittävää materiaalia kerättiin myös blogeista ja muista Internetlähteistä.

Olin mukana ohjelman tekemisessä toteuttaen ohjelmassa nähtävät verkostovisualisointigrafiikat. Visualisoinnit on toteutettu Gephi-ohjelmistolla ja data niihin on kerätty Facebook:sta. Toteutettuja verkostoja käytettin itse ohjelmassa lähinnä inserttigrafiikkana (Kuva 2), mutta niitä hyödynnettiin intensiivisesti ohjelmanteon aikana. Verkostoanalyysejä tulkitsemalla oli mahdollista nähdä kuinka keskenään verkostoitunut tutkittava joukko Facebook:ssa oli. Verkostoanalyysin voima sosiaalisten suhteiden tulkitsemisessa on vahva.

Verkostoanalyysia käytettiin ohjelmassa taustagrafiikkana. Televisiossa monimutkaisten verkostojen yksityiskohtainen käsitteleminen olisikin vaikeaa. (Kuva 2) 

Tämä on ensimmäisiä kertoja kun suomalaisen televisio-ohjelman toteutuksessa on käytetty  verkostoanalyysiä (kuulen mielelläni jos vastaavanlaisia toteutuksia on ollut aiemmin). Kiitos tästä kuuluu Marko Hietikolle, joka rohkeasti lähti asiaa viemään eteenpäin ja oli kiinnostunut tekemään yhteistyötä eri osaajien kanssa.

Teknisesti taustatyö tehtiin jo mainitulla Gephi-ohjelmistolla (Kuva 3), jonka käyttöä Facebook-verkostojen toteuttamisessa on kuvattu aikaisemmassa viestissä: "Facebook-verkostojen visualisointi". Gephi:stä TV-ruudulle visualisoinnit vietiin kuvan- ja ruudunkaappausohjelmistojen avulla. Esimerkiksi Silverback-ohjelmisto osoittautui tässä loistavaksi työkaluksi. Lopullinen stilisointi, kuten Spotlight:n graafisen ilmeen lisääminen, työstettiin yhteistyössä graafikon kanssa.

Verkostovisualisoinnista voitiin nähdä kuinka keskenään verkostoitunut tutkimuksen alla oleva joukko ihmisiä Facebook:ssa oli. Ohjelmassa käsitellyt henkilöt merkitty punaisella. (Kuva 3)

Olisi mielenkiintoista antaa ohjelman tekoa varten kerätty raakadata ja toteutetut visualisoinnit laajemminkin jakoon, mutta yksityisyyteen ja muihin tekijöihin liittyvistä syistä tämä ei ainakaan nyt ole mahdollista.

Facebook-verkostojen visualisointi

SPOILER: tämä postaus käsittelee teknistä sanastoa.

Innostuin tällä viikolla tutkimaan miten Facebook-verkostoja olisi mahdollista kerätä ja visualisoida vastaavalla tavalla kuten olen aikaisemmin visualisoinut Twitter-verkostoja sekä keitä @TuomasEnbuske seuraa. Enemmän tai vähemmän tunnetusti Facebook on kitsaampi jakamaan tietojaan Graph-rajapintansa kautta kuin mitä Twitter oman rajapintansa kautta, mutta rohkaistuin kuitenkin yrittämään tehtyäni ensin Olli Parviaisen kanssa kansanedustajien kaveruusverkoston sekä nähtyäni miten Jens Finnäs oli onnistunut tekemään vastaavanlaisen toteutuksen Ruotsin parlamentista.

Graph-rajapinta

Facebook:lla on siis olemassa Graph-niminen rajapinta, joka mahdollistaa Facebook-datan käsittelyn koneellisesti. Lähinnä rajapinta on varmasti tarkoitettu erilaisille Facebook-applikaatioille, mutta sitä on mahdollista käyttää myös muuten. Yksinkertainen Graph-rajapintakysely, joka palauttaa halutun käyttäjän (tässä tapauksessa allekirjoittaneen) tiedot (kuten ID, sukupuoli, nimi, jne.) voidaan suorittaa syöttämällä seuraava osoite selaimeen:

graph.facebook.com/teelmo.

Rajapintaa voidaan kutsua yhtälailla käyttäjän käyttäjänimellä kuin Facebook:n käyttäjä-ID-arvolla. Toisin sanoen kysely:

graph.facebook.com/635279474,

tuottaa saman vastauksen. Tiedot ovat haettavissa Graph-rajapinnan kautta kenestä tahansa Facebook-profiilista huolimatta siitä miten suljettu tai avoin profiili on. Rajapinnalta on mahdollista kysyä myös monia muita asioita, mutta esimerkiksi satunnaisen käyttäjän Facebook-kavereiden hakeminen ei ole mahdollista edes vaikka olisit kyseisen käyttäjän kaveri. Muiden kuin itsensä kavereiden hakeminen onnistuu rajapinnan kautta jos käyttäjä on sallinut tietojensa jakamisen applikaatiolle, jonka ylläpitäjä olet. Omat Facebook-kaverit rajapinnan kautta saa haettua.

Python + MongoDB = voitto

Kuten edellä näytettiin on Graph-rajapintaa mahdollista selata käsipelillä selaimen avulla, mutta käsiteltäessä suurempia datajoukkoja tulee tiedon keräämisestä tällä tavoin raskasta. Näin ollen erinäiset ohjelmointikielet ja niillä rakennetut scriptit eli lyhyet kertaalleen ajettavat ohjelmakoodit tulevat apuun. Käytetyllä ohjelmointikielellä ei ole suurta merkitystä vaan valinta kannattaa tehdä sen pohjalta, joka on itselle tutuin ja luontevin. Hyviä vaihtoehtoja kuitenkin ovat ainakin Python, Ruby ja Facebook:n tapauksessa etenkin PHP, koska suurin osa Facebook:n koodiesimerkeistä on kirjoitettu sillä. Itse valitsin kuitenkin Pythonin, koska halusin jatkojalostaa omaa Python osaamistani.

Pythonille löytyy useampia Facebook Graph API -kirjastoja, mutta ainakin pyFaceGraph-nimisen kirjaston avulla Graph-rajapinnan käyttö on todella yksinkertaista. Tässä yksinkertainen koodin pätkä, joka hakee käyttäjän tiedot kirjaston avulla jos käyttäjän tietoja ei ole jo aikaisemmin haettu ja tallennettu tietokantaan.

>>> from facegraph import Graph
>>> g = Graph()
>>> ...
>>> username = 'teelmo'
>>> # Check that username is not already in MongoDB
>>> if not users.find({"data.username": fusername}).count():
>>>    user = g[username]()
>>>    print user.id
'635279474'

Tietojen tallentamisessa hyödynsin MongoDB:tä, joka on NoSQL-tietokanta. MongoDB soveltuu käytettäväksi tämänkaltaisissa scripteissä, jotka hakevat tietoa netistä, koska tiedon eheydestä eikä rakenteesta tarvitse välittää samalla tavalla kuin käytettäessä esimerkiksi MySQL:ää tai muuta SQL-pohjaista tietokannanhallintajärjestelmää. MongoDB hyödyntää tiedon tallentamisessa JSON-formaattia, joka on myös formaatti, jossa Graph-rajapinta palauttaa hakutulokset.

Kuvassa 1 nähdään miten scripti hakee annettujen käyttäjien tietoja Graph-rajapinnalta. Tässä tapauksessa suurin osa haettavista käyttäjistä on jo aikaisemmin noudettu lokaaliin tietokantaan, mutta yhden käyttäjän osalta tiedot haetaan Graph-rajapinnasta.

Pythonilla ja MongoDB:llä toteutettu keräin, joka hakee annettujen käyttäjien tiedot Facebookin Graph-rajapinnasta. (Kuva 1)

Facebook:n Graph API ei rajoita tietojen hakemista samalla tavalla kuin Twitter (150 pyyntöä tunnissa), mutta satunnaisesti joitain virheitä esiintyy. Ongelmatilanteissa auttaa kun tiedot tallennetaan lokaalisti MongoDB:hen eikä tietojen hakemista tarvitse siten aloittaa ongelmatilanteissa alusta.

Käyttäjien tiedot kyllä, mutta miten yhteydet?

Graph-rajapinnan tarjoamat toiminnallisuudet on listattu täällä. Rajapinnan avulla saadaan siis kysyttyä suoraan mm. käyttäjien, tapahtumien ja sivujen tietoja. Käyttäjien välisiä yhteyksiä, tapahtumaan osallistujia tai sivujen tykkääjiä ei rajapinnan perustoiminnallisuuksilla kuitenkaan saa haettua.

Apuun tulee kuitenkin Graph-rajapintaa laajentava Facebook Query Language (FQL). FQL mahdollistaa Graph-rajapinnan kautta saatavien tietojen hakemisen SQL:n kaltaisella kyselykielellä. Esimerkiksi Facebook:n käyttäjä-ID:tä vastaava käyttäjänimi on mahdollista hakea seuraavalla kyselyllä:

SELECT username FROM user WHERE uid = 635279474

Käyttäjien välisten kaveruussuhteiden kyseleminen on mahdollista friend-taulusta. On huomioitavaa, että kaveruussuhteita on mahdollista kysyä myös sellaisten käyttäjien välillä, jotka muuten ovat piilottaneet profiilinsa. FQL:ää on mahdollista kokeilla erityisellä Graph API Explorer -työkalulla. FQL:n käyttäminen edellyttää OAuth-tunnistautumista ja ns. "Access token" täytyy välittää kyselyiden mukana.

Toteutin myös yhteyksien hakemisen Python-scriptillä. Apuna käytin Pythonille löytyvää requests-kirjastoa. Tässä yksinkertaisuudessaan ja lyhykäisyydessään FQL-kyselyn toteuttava koodinpätkä:

>>> import requests
>>> ...
>>> fql_query = "SELECT uid2 FROM friend WHERE uid1 = 635279474 and uid2 = %d" % uid2
>>> fql = "/fql?q=%s&access_token=%s" % (fql_query, access_token)
>>> try:
>>>    r = requests.get(domain + fql)
>>> except:
>>>    print "Error occured"


FQL-kysely palauttaa ne käyttäjä-ID-arvot, jotka täsmäävät annettuun hakuun. Eli hakiessani olenko kaveri käyttäjien A, B ja C kanssa palauttaa Facebook niiden käyttäjien ID:t, joiden kanssa haetuista olen kaveri.

Tulokset kirjoitin .gexf-muodossa ja visualisoinnin tein Gephi-nimisellä verkostojen visualisointiohjelmalla. Gephi:n käyttöön en mene tässä sen syvällisemmin, koska olen käsitellyt sitä jo aiemmin tässä blogissa ja tyydynkin vain viittaamaan Olli Parviaiseen luomiin ohjeistuksiin.

Summa summarum

Yhteenvetona voitaneen todeta, että Facebook:sta on mahdollista muodostaa kaveruusverkostoja vastaavasti kuin aikaisemmin olen näyttänyt Twitter:stä. Facebook:n kohdalla joutuu hieman enemmän tekemään käsityötä datan keräämisessä, mutta lopputulos on täysin vastaava. Erona Twitter-verkostoihin on, että Facebook:sta kerätyistä kaveruusverkostoista muodostuu paljon rypästeisempiä (Kuva 2). Eri ryhmät kuten lapsuuden ystävät, koulukaverit, työkaverit ja sukulaiset ovat hyvin vähän tekemisissä toistensa kanssa, mutta ovat linkittyneet keskenään hyvin paljon.

Facebook-kaveriverkostoni. Eri ryhmät erottuvat toisistaan erittäin selkeästi. Solmuja verkostossa on 206 ja yhteyksiä 1878. (Kuva 2)

Twitter:ssä taas ihmiset ovat enemmän verkostoituneet keskenään yli sosiaalisten tai fyysisten rajojen (Kuva 3). Twitter:n demografia poikkeaa toki hyvin paljon Facebook:sta, mutta mielestäni tämä kertoo, että Twitter:ssä seurataan kiinnostavia henkilöitä ja itse asiaa, joka johtaa samoista asioista kiinnostuneiden ihmisten tiheisiin verkostoihin. Toisaalta voidaan vetää myös se johtopäätös, että julistan Twitter:ssä vain yhden aihealueen ilosanomaa ja jos aihealueita olisi useampia nähtäisiin näistä eri aihealueista kiinnostuneet ihmiset omina ryppäinään.

Twitter-seuraajaverkostoni. Ihmiset ovat verkostoituneet keskenään hyvin tiheästi. Solmuja verkostossa 149 ja yhteyksiä 1209. (Kuva 3)

Voidaan kuitenkin tehdä sivistynyt arvaus, että Facebook:ssa seurataan ihmisiä, jotka ovat tuttuja fyysisestä maailmasta kun taas Twitter:ssä seurataan ihmisiä, jotka ovat kiinnostavia. Tässä toki kyseessä vain yhden ihmisen Facebook-kaverit ja Twitter-seuraajat, joten kovin pitkälle meneviä johtopäätöksiä ei voida tehdä, mutta olen havainnut samankaltaisen trendin esiintymisen myös muissa testitapauksissa.

Stay tuned!

"Ryömin juuri kaikkia @TuomasEnbuske:n seuraajia Keitä me kaikki ollaan Seuraavaksi @alexstubb Siinä taitaakin olla kaikki suom. Twitteristit" - https://twitter.com/#!/teelmo/status/185680267548168192

Twitter-verkostoanalyysia Gephi:llä

Innostuin viime viikonloppuna kokeilemaan ensimmäistä kertaa omatoimisesti miten Twitter-dataa on mahdollista visualisoida. Olen aiemmin tutkinut ja työstänyt paljon erilaisia sosiaalisia verkostoja, mutta ennen en ole laittanut todella käsiä rasvaan Twitterin osalta. Osittain tähän on ollut syynä se, että olen mieltänyt Olli Parviaisen jo avanneen kaikki Twitterin salat tämän osalta eikä asiaan vihkiytyminen näin ollen ole tuntunut mielekkäältä. Pisteet tämän vaikutelman luomisesta Ollille :) Sisäinen devaajanluonteeni kuitenkin siis vei voiton ja lähdin kehittelemään jotain omaa.

Twitter tarjoaa monipuoliset mahdollisuudet datansa käsittelyyn rajapintansa kautta. API:lla (Application programming interface) on mahdollista hakea automaattisesti oikeastaan kaikki se tietosisältö, joka on käyttäjälle muutenkin nähtävissä. Tämä on poikkeuksellista esimerkiksi verrattuna Facebook:n Graph API:in, jonka kautta tietoa on mahdollista hakea rajoitetummin. Tästä syystä Facebook-datan hakeminen on omalta osaltani tapahtunut hyvin paljon käsityönä kuten "Kansanedustajat Facebookissa – kuka on kenenkin kaveri?" -tapauksen yhteydessä.

Päädyin rakentamaan Twitter-datan avulla verkoston käyttäjistä/Twitter-tileistä joita seuraan. Henkilökohtaisella Twitter-tilini seurannassa ~90:ntä tiliä, joten tästä seurasi suoraan verkoston solmujen lukumäärä. Yhteydet solmujen välille rakensin sen perusteella miten seuraamani henkilöt seuraavat keskenään toisiaan. Lopputuloksena syntyi sosiaalisen verkosto, joka havainnollistaa seuraamieni henkilöiden keskenäiset suhteet, suhteiden perusteella muodostuvat ryhmät ja näiden ryhmien asemoitumisen toisiinsa nähden.

Keräsin datan käyttäen Python-ohjelmointikieltä ja tein tulostuksen verkostodatalle soveltuvassa GraphML-muodossa, jota visualisointiin käyttämäni visualisointityökalu Gephi ymmärtää. Gephi:ssä käytin tulosten latomiseen ForceAtlas2-algoritmia, jonka olen todennut käytännön kokemusten kautta toimivan hyvin etenkin pienten sosiaalisten verkostojen visualisoimiseen. Värikoodauksen tein dataan käsin määrittelemällä jokaisen solmun sille olennaiseen kategoriaan. Solmun koko kuvastaa astesummaa eli solmuun suuntautuvien yhteyksien määrää. Toisin sanoen solmun koko kuvaa suoraan Twitter-tiliä seuraavien Twitter-tilien määrää verkostossa. Yhteydet solmujen välillä ovat suunnattuja. Annotoinnin ja jälkikäsittelyn tein Paintbrush-nimisellä ohjelmalla. (Kuva 1)

Sosiaalinen verkostoni Twitter:ssä visualisoituna Gephi:llä. (Kuva 1)

Visualisointi vahvistaa hyvin niiden eri ryhmien olemassaolon, jotka todellisuudessakin ovat olemassa verkostossani, mutta lisäksi visualisoinnista voidaan nähdä miten nämä ryhmät sijoittuvat suhteessa toisiinsa. Esimerkiksi TTYläiset erottuvat visualisoinnissa hyvin selkeästi muista ryhmistä erilleen. Tulkitsen tämän johtuvan toisaalta siitä, että seuraamani TTYläiset eivät ole kaikkein aktiivisimpia Twitter-käyttäjiä mutta toisaalta siitä, että heillä ei ole mitään syytä seurata Yleläisiä tai datajournalismi-ihmisiä. Myös Yleläiset erottuvat visualisoinnissa selkeästi omana joukkonaan, mutta he taas asettuvat selkeästi lähemmäksi datajournalismi-ryhmää kuin TTYläiset, jonka voidaan mieltää olevan ihan ammatillisestikin luontevaa. Nämä kolme ryhmää (1. TTY, 2. YLE ja 3. Datajournalismi) ovat verkostoni suurimmat ja selkeimmät, joten näen, että tällä erää on mielekästä tässä tulkita vain ne ja jättää muut pienemmät ryhmät tässä erää huomioimatta.

Kuvissa 2, 3 ja 4 nähdään eräiden muiden käyttäjien Twitter-verkostot. Verkostot on toteutettu samoilla periaatteilla kuin edellä kuvattu oma verkostoni sillä erotuksella, että solmujen väritys on tehty Gephi:n Modularity-luokittelun avulla. Lisäksi näissä verkostoissa esiintyvät Twitter-tilit on anonymisoitu, koska haluan esittää ne vain esimerkin omaisesti enkä pyrkiä sen tarkempaa tulkitsemiseen. Tarkempi tulkinta vaatisi tutustumista verkostoissa oleviin Twitter-tileihin, jotta voitaisiin ymmärtää miksi tietyt ryhmät ovat lähempänä toisiaan kuin toiset.

Kuvien 2, 3 ja 4 verkostoista nähdään miten verkoston ulostulo on hyvin erilainen eri käyttäjille. Toisilla käyttäjillä nähdään hyvin pitkälle keskenään verkostoituneet ryhmät kun taas toiset käyttäjät seuraavat toisistaan täysin riippumattomia Twitter-tileistä koostuvia ryhmittymiä.

Kuvassa 2 nähtävä verkosto on niin tiheä, että tarkkojen tulkintojen tekeminen yleisnäkymästä on vaikeaa. Verkostojen tulkinnassa onkin tärkeää, että analysoinnin yhteydessä dataa voidaan selata mm. "details on demand" -periaatteella.

Tiheiden verkostojen tulkinta on usein vaikeaa jos verkostoa ei ole mahdollista rajata tai zoomata. Gephi mahdollistaa datan rajaamisen erilaisten filtereiden avulla ja verkostoa on mahdollista zoomata. Yleiskuvan merkitys on kuitenkin tärkeä, koska sen avulla nähdään ne alueet, jotka voisivat olla kiinnostavia jatkotutkimuksen kannalta. (Kuva 2)

Kuvassa 3 nähtävän verkoston erityispiirre on kahden sisäisesti tiiviin ryhmän heikko vuorovaikutus keskenään. Jos kyseessä tässä olisi yrityksen kahden eri osaston välinen kommunikaatio olisin hyvin huolestunut yrityksen sisäisen viestinnän toimivuudesta.

Twitteriä on mahdollista käyttää hyvin monella eri tavalla. Tämän kyseisen henkilö seuraa selkeästi kahta erillistä toisistaan riippumatonta ryhmää ihmisiä, jotka voivat poiketa toisistaan esimerkiksi kiinnostuksen  tai spatiaalisesti. (Kuva 3)

Kuvan 4 verkostossa osa ryhmistä on eriytynyt omaan lokeroonsa kun taas toiset ryhmät ovat verkostoituneet keskenään.

Tämän käyttäjän verkostossa tietyt ryhmät erottuvat hyvin selkeästi omiin lokeroihinsa, mutta oikealta löytyvä klusteri on taas hyvin vahvasti verkostoitunut keskenään. (Kuva 4)

Kuten huomataan vaatii verkostoanalyysi aina rinnalleen tuntemusta visualisoitavana olevasta ilmiöstä. Pystyn tulkitsemaan omaa verkostoani melko luotettavasti, koska tunnen minkälainen ilmiö on kyseessä ja tiedän mitä verkostossa olevat solmut ovat. Tulkinnasta tulee kuitenkin heti hankalampaa kun verkostossa esiintyvät solmut ja yhteydet tai ylipäänsä verkostossa nähtävä ilmiö ei ole tuttu. Onkin väärin olettaa, että verkostoanalyysi olisi jonkinlainen Hopea Luoti, joka suoraan ratkaisisi monimutkaisia ongelmia ja vastaisi kysymyksiin. Verkostoanalyysi toimii ongelmien ratkaisun tukena ja toisaalta antaa suuntaa sille  mistä ratkaisua voisi lähteä etsimään.

Seuraavat askeleet Twitter-analyysin osalta ajattelin ottaa siihen suuntaan, että kaivan verkoston ihmisten seuraajista sen sijaan, että katson keitä ihmiset seuraavat. Uskoisin tämän näkökulman tuottavan mielenkiintoisia tuloksia kun analyysi kohdistetaan yhteiskunnallisesti tärkeisiin ihmisiin kuten poliitikkoihin.

Keep on Tweeting...