DrupalCon 2013 Prag och gemenskapens styrka

Jag hade nöjet att delta i DrupalCon 2013 i Prag. DrupalCon är i grunden en teknisk konferens där alla utvecklare som jobbar med Drupal samlas ihop. Just nu ligger fokus kraftigt på följande version, Drupal 8. Det är stora förändringar på väg, vilket väcker både stora förhoppningar och farhågor inom Drupalcommunityt.

DrupalCon 2013 Prag gruppbild
DrupalCon 2013 Prag gruppbild. CC By-SA Michael Schmid http://www.flickr.com/photos/x-foto/

Mindre aktörer är oroliga över att de inte längre ensamma skall kunna hantera en Drupalsajt, att de blir för komplexa. En del användare börjar använda Drupal på nya sätt så att de skär av trådarna mellan backenden (den tekniska bakgrunden) och frontenden (det som användarna ser på sina skärmar). Andra vill fortsätta att utveckla Drupal 7 ännu, eftersom det är ett fungerande system. Och ytterligare andra kan inte vänta på att Drupal 8 skall lanseras för att kunna utnyttja de nyheter som är på kommande. Klart är dock att fler utvecklare redan nu har bidragit till utvecklingen av Drupal 8 än av någon annan tidigare version.

Och det är verkligen mycket nytt, Drupal 8 innehåller över 200 nya egenskaper. Dries Buytaert, ”Drupals pappa”, tog i sin keynote särskilt upp Drupals samhälleliga betydelse, vad systemet möjliggör som ett open source webbpubliceringssystem. I linje med det fokuserade Dries också mycket på egenskaper som tillgänglighet (accessability), mångspråkighet och mobilanpassning i sitt tal. Det var också glädjande för mig att höra att en stor vikt lagts på att semantisk annotering i Drupal, huvudsakligen i linje med definitionerna i schema.org (mer om vårt arbete kring detta i ett senare inlägg).

Andra dagens keynote hölls av Lisa Welchman som pratade om vikten i att vårda den community som byggts upp. Det finns en paradox för öppna gemenskaper, där just öppenheten blir den drivande faktorn för tillväxt och kreativ gemenskap, vilket väcker krav på styrning, vilket riskerar kväsa communityt. Det här är något som man sett inom Drupalgemenskapen där dessa DrupalCons och också mindre träffar har varit fantastiskt inspirerande. Och den hjälp som utvecklarna ger till varandra helt gratis och av pur välvilja är helt fantastik. Och tänkt ur ett mer krasst affärsperspektiv otroligt prisvärd. För det arbete som gemenskapen gör och ger varandra är värd miljontals euro!

Men samtidigt kommer den andra sidan in. Då en verksamhet växer så börjar den spreta åt olika håll och kan inte längre fungera effektivt utan styrning. Men där måste man gå försiktigt tillväga. Och även styrning är något man kan göra tillsammans. Och på så vis övervinna paradoxen mellan den inspirerande och tillväxtgivande friheten och den potentiellt kväsande styrningen.

En lärdom som vi gärna kunde överföra till fler verksamhetsområden, inte minst journalistiken.

Nedan en Storify som samlar mitt twitterperspekiv på DrupalCon Prag:

Screenmirroring with Ipad to videomixer and backgroundscreens

Hi

I have done a video where I show an easy way to make a tacticalscorboard for example for a sportbroadcast. http://youtu.be/oU2MuJE9mok

The pros are fast building and cheap, the cons are a couple of seconds lag.

The functionality is all up to witch app you choose to use. I have tested 5 and did realativlly fast decided which is my personal favorite.

The psycical setup

– Ipad connected to AppleTV with Airplay screenmirroring (Ipad and AppleTV are in the same Wifi-network)

– AppleTV (3g) is connected (1080p) with HDMI-cable to BMD HDMItoSDI-miniconverter

– HDMItoSDI is connected with HD-SDI to BMD UpDownCross-miniconverter (1080i OUT)

– UpDownCross is connected to CasparCG-videoserver (HD-SDI)

– CasperCG is connected(HD-SDI) to background videoscreen and videomixer.

You can of course connect the UpDownCross straight to your videomixer and use an Aux for playing out to backgroundscreen. I prefer to use Caspar but it is one more computer.

hope you enjoy it

Markus

Switching Distros on a Running Site

As Mårten explained in an earlier post we decided to redo our installation profile into a more diversified model with a common core set of modules and with a differentiated set of modules for every site that will use the common core.

Splitting the previous Yle – profile that we used as a base for our installation from the beginning was easy enough. Just create two new installation profiles – Syndprofile and Fyndprofile that used most parts of the earlier Yleprofile and the parts that were specific for the two installations into their own sets of repositories, ie synd_modules and fynd_modules and so on. Starting development on the fynd-platform was also very successful and has since launced two successful projects: Kuningaskuluttaja and MOT.

However, on the svenska.yle.fi – platform, the change posed a lot of challenges to overcome, since we had to change installation profiles on a running site. And since a lot of the path settings to modules and themes are set in the database at installation time a lot of file paths would have to be changed. So when we first tried the easiest approach, just replacing the profiles/yleprofile installation folder with a profile/syndprofile we were left with a severely broken site, that couldn’t find any modules or themes, no matter how many times you tried to clear the cache. So it became clear that we had to do the changes directly into the production database.

So what we did was to dump the database into an sql file and doing a search and replace on every occurence of yleprofile to the new synprofile. We opted to slightly change the name to synprofile since there are a lot of serialized data that contains the path in the database as well.

We have around 500 000 nodes in our database at the moment, and a pretty large index, but using sed to do the search and replace the operation only took a few minutes to do, even though the sql file itself is getting close to 5 Gigabytes in size.

$ sed ‘s/yleprofile/synprofile/g’ < svenskaylefi.sql > svenskaylefi_synprofile.sql

This, however, was not enough in our case. We also had a couple of modules and our own theme settings and features that was not going to be used in the other distributions so we had to manually change the location of these. Fortunately most of the file path settings are stored in just a few tables.

system
registry and
registry_file

The paths are also stored in the cache tables so it is advisable to truncate them at the same time, especially

cache
cache_bootstrap and
cache_path

It took a few tries to get every step in this workflow to work out without problems, but when we finally figured out how to do it the migration process went pretty smoothly. Just one final hurdle gave us a bit of cold sweat when the site didn’t even bootstrap even though the migration process had otherwise gone smoothly. But, a manual flush of the memcache server solved that too.

 

Knytkonferans på SR i Stockholm

Den 5.4.2013 åkte en delegation bestående av Kristoffer, Mårten, Alexander och Joakim till Sveriges Radio i Stockholm för att delta i ett evenmang som av arrangörerna döpts till “knytkonferans”. För mig var konceptet nytt och jag ska beskriva det utgående från mitt nybörjarperspektiv. Totalt var vi 42 deltagare från SR, UR, SVT, ATG och Finska Svenska YLE.

Idén med en knytkonferans är att man inte bestämmer exakt vad som ska behandlas i förväg. I stället samlas alla som är intresserade av ett övergripande tema på ett gemensamt mötesställe och börjar med att brainstorma kring de exakta rubrikerna man vill ha workshoppar om.

Vårt övergripande tema var “följsam webb” eller RWD (Responsive Web Design), vilket innebär att man designar en webbsida som funkar olika och ser olika ut med olika skärmupplösningar. Det var ett mycket löst övergripande tema och väldigt få av workshopparna handlade egentligen om följsam webb. Temat valdes egentligen för att det är väldigt aktuellt och knyter samman alla deltagande bolags intressen.

När vi anlände till konferansen började vi med att skriva ner idéer till rubriker på stora, färggranna papper som sedan hängdes på väggen. Var och en fick sedan rösta på de rubriker som kändes intressanta genom att skriva sina initialer på lapparna. Till slut räknades rösterna och ett officiellt schema gjordes upp med de mest populära rubrikerna.

konferans

Här följer beskrivningar av några workshoppar som ordnades och som jag deltog i:

Öppet API

En av workshopparna handlade om APIer, dvs gränssnitt mellan data och applikation. Många av deltagarna, däribland också YLE, ansåg att de i framtiden kommer att föras heta diskussioner kring öppnandet av public service -bolagens data för offentligheten. Sveriges Radio har tagit ett av de första stegen och har sedan år 2010 ett öppet API som erbjuder vem som helst information om kanaler, program, avsnitt, låtlistor, nyheter osv. Vill vi t.ex veta vad som går på P3 idag öppnar vi URLen http://api.sr.se/api/v2/scheduledepisodes?channelid=164 och ser ingen vanlig webbsida, utan ett XML-formaterat dokument med den önskade informationen.

Ett API innebär en mångsidig, väldokumenterad lista med kommandon (t.ex “scheduledepisodes” som ovan), som applikationsutvecklare kan använda för att utföra olika sökningar och komma åt olika listor i ett maskinvänligt format. När ett bolag öppnar sitt API på detta sätt, så tar man samtidigt bort alla hinder för andra utvecklare att utveckla egna tjänster som är beroende av bolagets data.

Jag har själv som programmerare kämpat med motsvarande problem utan API. För flera år sedan prenumererade jag på satellitkanalpaketet Viasat och fick förutom en massa filmkanaler också ett helt drös svenska tv-kanaler. Problemet var att Viasat i Finland inte hade någon programtablå och det var i praktiken omöjligt för oss i familjen att veta vilket program som går vid en viss tid på en viss kanal. Det enda jag kunde göra var att försöka tolka strukturen på HTML-koden på flera olika webbsidor med den information jag behövde och skriva ett program som “stjäl” informationen om tv-program och klockslag från de olika kanalerna och sparar dem i min egen databas. Mitt system gick ofta sönder pga att strukturen förändrades, eller pga att jag inte hade tolkat den rätt. Det var heller inte tal om att jag kunde publicera min egen tablå med “stulen” information för andra Viasatkunder i Finland.

Ett API löser det här problemet och ger mig ett löfte om kontinuerlig, väldokumenterad tillgång till programdata. Dessutom använder jag datan på ett sanktionerat sätt och behöver inte vara rädd för att sprida den vidare om licensen tillåter det. Ett öppet API ska dessutom per definition få användas fritt och informationen spridas vidare. Jag kunde t.o.m ta betalt för min Viasat tablå, bara jag tar betalt specifikt för appen och inte informationen.

SR erbjuder också tillgång till programinnehåll via sin API. Man kan t.ex lyssna live på deras radiokanaler (också i Finland) från URLen

http://sverigesradio.se/topsy/direkt/[channelid].mp3

… där man ersätter [channelid] med lämplig kanal-id. T.ex P1 har id 134 och vill man veta flera kanal-id:n kan man lista dem alla på adressen http://api.sr.se/api/v2/channels/, som naturligtvis också är en del av APIt.

Vid vår workshop lyftes naturligtvis också flera orosmoment fram och det blev snart uppenbart att ett API inte är helt problemlöst. Det gäller helt enkelt att väga fördelarna mot nackdelarna. Ett problem som av vissa uppfattas som ganska allvarligt är att om vi öppnar tillgången till information så behöver man i princip inte besöka t.ex SR:s webbplats för att lyssna på radioprogram. Jag lyssnar t.ex på P1 medan jag skriver detta med en direkt länk jag fick från SRs API och i min bläddare ser det ut så här: En spelare på en i övrigt totalt svart sida.

Screen Shot 2013-05-06 at 6.05.41 PM

Utvecklare kallar detta fenomen för “cherrypicking”. Besökare kan välja det innehåll de vill ha och undviker eller går miste om allt annat innehåll, som t.ex puffar för andra kanaler, teasers för artiklar och helt enkelt resten av SR:s innehåll som live-radio användare förut har blivit mer eller mindre påtvingade. Det fanns ganska varierande åsikter om hur stort problemet egentligen är, men en ganska stark röst tyckte att det kanske inte ingår i public service uppdraget att styra folks konsumtion av information utöver vad det själva önskar ta del av.

Ett annat problem som togs upp var piratism: All data som öppnas kan stjälas, dvs sparas på den egna hårddisken och sedan spelas upp flera gånger, modifieras och t.o.m spridas vidare eller användas i egna produktioner. Somliga anmärkte att risken inte egentligen är större nu än förut: Live radio på internet har ju funnits långt före APIer blev aktuella. Ett API är egentligen bara en ny, välstrukturerad och väldokumenterad version av vad vi redan länge erbjudit.

En stor utmaning med ett öppet API är att det faktiskt ska vara det: Öppet. Det innebär inte bara att alla ska ha rätt till åtkomst, utan att åtkomsten också måste planeras i första hand för hela världen och först i andra hand för bolagets interna bruk. Ganska många bolag har börjat sin API karriär med att bygga interna verktyg utgående från en API filosofi och då går det lätt så att APIet måste designas om totalt när det öppnas för allmänheten. Ett API som i första hand tillgodoser interna behov fungerar inte tillräckligt allmängiltigt för att fylla den stora allmänhetens krav. Man kan alltid lappa på med nya funktioner och justera hur existerande egenskaper fungerar, men i många fall kommer man ganska snabbt till slutsatsen att man måste bygga APIet med öppenhet som grundförutsättning från början för att det verkligen ska vara öppet i alla avseenden.

Motståndare till öppna APIer kommer ofta med argument som till exempel kan verbaliseras med “dom stjäl vårt innehåll”. Då menar man att bolaget producerar en mängd fina program och annat innehåll som sedan tredje parter kan ta åt sig och paketera om, utan att behöva anstränga sig för att innehållet ska hålla god kvalitet. Ett gott exempel är när en tredje part gjorde en applikation för iOs som kunde spela upp SR:s radioprogram utan att SR hade kontroll över hur innehållet presenterades. Debatten destilleras ganska snabbt till frågan: Ska public service uppdraget inkludera kontroll av presentationssättet, eller är det viktigaste att informationen kommer ut till allmänheten? Om vi svarar ja på frågan, så måste vi acceptera det faktum att bolagets egen webbplats och egna appar någon dag kan överskuggas av en produkt som tillverkats och till och med säljs av någon tredje part som bara “lånar” vår data.

Avslutningsvis kan man säga att vi kom till ett konsensus om att det är väldigt bra och till och med viktigt att public service bolags information kommer ut så effektivt och transparent som möjligt. Det kändes som att så gott som alla deltagare har planer på att skapa någon form av öppet API i framtiden för att ge ut sin data. Tidtabellerna varierar, men kanske huvudsaken är att viljan nu finns, även på ganska hög administrativ nivå.

Avancerade Javascript applikationer

Följande workshop handlade om avancerade Javascript applikationer. Jag ska inte skriva så mycket om det, eftersom ämnet är ganska nytt för mig.

Med avancerade JavaScript applikationer menar man webbplatser som inte är traditionella sajter över huvud taget med förflyttning från sida till sida via länkar. I stället strävar dessa applikationer att ge användaren känslan av en s.k “desktop applikation”, vilket ibland innebär ett totalt nytänkande av funktionslogiken på webben: Man stannar i samma vy en stor del av, eller kanske till och med hela besöket och sidans innehåll manipuleras med hjälp av JavaScript. JavaScript kan kanske karakteriseras som ett lättviktar scriptspråk som ofta används i samband med HTML på webbsidor för att göra upplevelsen rikare. Det är t.ex ofta JavaScript som kollar att man fyllt i en valid epost-adress i något formulär på webben och sedan hindrar en från att skicka formuläret före man korrigerat adressen. Då man använder JavaScript till större funktioner kan det bli ganska komplicerat, inte minst för att olika bläddrare ska manipuleras på lite olika sätt. För att underlätta det här arbetet har man skapat olika JavaScript frameworks eller ramverk, som de heter på svenska.

Det finns nästan skrattretande många ramverk för JavaScript. Med framework eller ramverk menas en samling verktyg och kanske en användningsmodell för utförande av specifika uppgifter. Ett ramverk möjliggör inget som inte kan göras med “vanlig” JavaScript, utan paketerar endast funktioner som ofta behövs till ett lättanvändligt gränssnitt för utvecklare. På det sättet behöver inte varje utvecklare uppfinna hjulet på nytt. Ett av de absolut populäraste JavaScript ramverken heter jQuery och kunskaper om det är nästan ett grundkrav för webbutvecklare idag. Det är emellertid viktigt att inse att när man talar om dessa avancerade JavaScript applikationer, så är jQuery helt fel verktyg. Det innehåller helt enkelt inte de rätta hjulen som inte ska behöva uppfinnas på nytt. Vi måste i stället vända oss till ramverk som utvecklats specifikt för uppgiften. Som exempel kan nämnas ember.js och backbone.js.

Efter att ha undersökt Ember ytterligare på webben och läst några tutorials, så är jag ganska imponerad. Jag ser en väldig potential och ett ökande behov att göra vissa webbtjänster mera applikationslika. Ember inför en MVC (model – view – controller) paradigm på JavaScript nivå i webbutveckling och det är något som vi väntat på länge. Det som är lite förvånande är att det känns ganska tystlåtet kring både Ember och Backbone för tillfället. Det är som om de hade en lite mindre, väldigt trogen skara anhängare, men att det stora genombrottet ännu låter vänta på sig. Jag ska definitivt hålla ögonen öppna och överväga i vilka sammanhang man kunde dra nytta av den här sortens ramverk, men att t.ex konstruera hela sin webbplats kring en såpassny och kanske till och med marginell teknologi känns ganska riskabelt. Jag hoppas intresset ökar i framtiden.

Även i gruppen som samlades under knytkonferansen för att diskutera avancerade JavaScript applikationer var det ganska tystlåtet. Av drygt 10 deltagare fördes nästan hela diskussionen av två personer som hade tidigare erfarenhet av tekniken och resten var bara hälsosamt nyfikna på vad det hela egentligen handlar om. En viktig del av vårt arbete går ut på att undersöka och evaluera nya tekniker och i vilken utsträckning vi kunde ha nytta av dem i vårt arbete. I det ljuset var workshoppen långt i från onödig, trots att den utspelade sig på en tämligen abstrakt nivå för många av oss.

Public Service

Dagens sista knyt-workshop handlade om det public service uppdrag som nästan alla deltagare har gemensamt via sin arbetsplats.

Den här workshoppen förde diskussionen i en lite mindre teknisk och mera ideologisk riktning. Det var främst två ämnen som steg till ytan: För det första hade vi mandatet om public service i kristid och hur t.ex ett öppet API kan äventyra den servicen pga större risk för dataintrång. Det finns förstås ett argument för att den största säkerheten uppnås då man stänger av all åtkomst till ett system, men eftersom vår uppgift är förmedling av information, så är det inte praktiskt möjligt. Några portar måste alltid lämnas öppna.

En möjlig lösning, som inte kräver så tunga restriktioner är att splittra servicen och erbjuda t.ex ett öppet API via andra kanaler än den egentliga informationskanalen. Då störs inte den officiella informationskanalen i samma utsträckning om API systemet överbelastas på flit eller av misstag. Denna typ av redundans är enligt många säkerthetsspecialister närmast ett grundkrav. Man bör också komma ihåg att ett fullständigt slutet system inte är någon garanti för osårbarhet. Speciellt i kristid är det väldigt många länkar som är sårbara i kedjan: privatpersoners internetuppkopplingar, bolagens internetuppkopplingar, strömtillförsel osv. Därigenom känns det logiskt ohållbart att “stänga APIer för att kunna garantera funktion i kristid”.

Det andra ämnet handlade om insamling och användande av statisik. Grundproblemet är att det är förknippat med vissa ideologiska problem att samla in statisik om besökares aktivitet på en webbplats och sedan erbjuda datan åt allmänheten t.ex via ett öppet API. Informationen kan användas för kommersiella syften genom att företag profilerar användare och deras beteende. Om besökarstatistiken t.ex visar på ett kraftigt ökat intresse för motorcyklar, så kunde företag ändra på sin verksamhet och mera aggressivt börja marknadsföra motorcyklar och relaterade produkter för att därigenom öka sin försäljning. Ska public service bolag ens indirekt hjälpa kommersiella aktörer att maximera sin vinst?

En ännu allvarligare aspekt är att besökarstatistik som är tillräckligt detaljrik kunde användas för att identifiera enskilda besökare och därigenom analysera vilka sidor de surfat på. En lösning är att dels anonymisera data, men också presentera den endast i sammanfattad form, så att inte enskilda mönster så lätt kan utläsas.

Ett relaterat problem gäller överlåtande av data åt en tredje part som tillhandahåller en statistikservice. Med det menar man t.ex att ett public service bolag utnyttjar Googles eller någon annans statistiktjänst för att få fram data om vilka sidor som är populärast, vilken väg besökare navigerar och varifrån de kommer. Argumentet mot att använda t.ex Googles statistiktjänst är att vi ger Google ännu mera makt än de redan har om vi avslöjar exakt vilken trafik webbplatsen haft och exakt hur enskilda besökare rört sig från artikel till artikel. Den mängd information Google har gör att de mycket exakt kan profilera användare och presentera riktad marknadsföring med sina sofistikerade algoritmer.

Motsidan av argumentet är att det helt enkelt är nödvändigt att använda en tredje parts statistikverktyg om vi ska kunna få jämförbar statistik mellan olika bolag. Alla kan inte ha en egen statistikservice eftersom siffror mätta med olika metoder inte är statistiskt jämförbara och eftersom man till och med kan manipulera siffrorna för att visa den statistik som önskas.

Ett alternativ vore om en statlig instans erbjöd en officiell statistikservice i stil med Google Analytics, men som kunde garanteras vara icke-kommersiell. Frågan är då om allmänheten hellre överlåter sin statistiska data åt Google eller åt staten, “big brother”. Osökt återvänder man till tanken om att det bästa kanske ändå är att fullständigt transparent erbjuda samma data åt alla. Då vet var och en exakt vilken data som finns tillgänglig och hur den kan användas av olika intressegrupper.

Det anmärktes också att public service bolagen ju producerar sina tjänster med skattemedel och att allt som produceras: artiklar, program, webbplatser, statistik, mm. borde överlåtas helt öppet till folket som betalar för tjänsten.

Slutkommentarer

Knytkonferansen var ett första experiment för att se hur den här typen av forum fungerar för att skapa intressanta och givande sessioner kring olika ämnen. Det känns som att väldigt viktiga och intressanta ämnen togs upp och att vi inte hade särskilt stora svårigheter att hitta de relevanta frågorna. Eftersom grupperna saknade ordförande hände det ofta att vi då den reserverade tiden tog slut märkte att vi hunnit diskutera endast några få frågor och att det kanske hade funnits flera viktiga ämnen att ta upp. En ordförande kunde ha reagerat då gruppen fastnat vid ett visst ämne för länge och styrt diskussionen vidare.

Som helhet var dagen lyckad och jag hoppas vi får chans att delta igen!

konferans2

Workshop om public service. 

Jag, Joakim

jj

Efter snart tre månader på Svenska Yles “utgivning webb” börjar det bli dags att presentera mig själv: Hej, jag heter Joakim, kallas för Jocke och jag är kodare.

Det råder ganska spridda åsikter om vad en kodare är och vem som får kalla sig kodare. Vissa purister tycker inte att jag får använda titeln, eftersom jag endast skriver program i språket PHP som är ett s.k scriptspråk och tolkas av datorn utan att programmeraren först behöver översätta det till maskinkod. Samma purister får hjärtslag när någon som “bara” arbetar med HTML kallar sig för kodare. Ovannämnda hör till mina huvudsakliga verktyg och för enkelhetens skull brukar jag ändå presentera mig som kodare.

Här är mitt försök att definiera kodande och samtidigt en beskrivning av vad jag gör här på YLE: En kodare löser logiska problem och skriver sedan ner lösningen på ett språk som han behärskar och som stöds av servern. Pluspoäng fås om man skriver ner lösningen på ett sådant sätt att också andra kodare förstår den. Vill man vara extra öppen, så kan man skriva koden så att hela världen kan ha nytta av den och till och med vidareutveckla den. Då måste man följa vissa riktlinjer och koda på en ganska allmän nivå i stället för att välja lösningar som endast kan utnyttjas av vår begränsade nisch. Jag gillar den sortens öppenhet och det var en glad överraskning då jag fick höra att man också på YLE värdesätter öppenhet och att det finns stora satsningar för att göra det vi håller på med mera öppet.

Min officiella titel är “webbutvecklare” och här på YLE ska jag i första hand arbeta med webbsajten svenska.yle.fi och specifikt som Drupalexpert.

Kanske man bättre förstår vad jag sysslar med om jag get ett konkret exempel: När YLEs redaktörer skriver webbartiklar, så ska varje artikel helst förses med nyckelord som är relevanta för det man skriver om. Orden kan inte väljas hur som helst, utan ska sökas från en ordlista, en s.k “ontologi”. En av mina första uppgifter var att se till att redaktörer kan tagga sina artiklar med ord också från andra ontologier än standardontologin, “koko”. Som konkret exempel kan man nämna “mesh”, som innehåller medicinska termer och ska användas av Webbdoktorns redaktörer. Som kodare tacklar man uppgiften steg för steg: Först måste jag se om jag över huvud taget kan söka mesh-termer från ONKIs tjänst. När jag kan göra det på teknisk nivå måste jag fundera hur en redaktör vid inmatning av en artikel lättast specificerar att nyckelord ska sökas från t.ex mesh. Det finns många alternativ: man kan välja från en s.k rullgardinsmeny, man kan kryssa för en eller flera ontologier med s.k checkboxar och så kan jag som kodare kräva att en redaktör vet att man ska fylla i ontologins namn före sökordet, t.ex “mesh:huvudvärk”. Det sistnämnda är ett bra alternativ om endast väldigt få ska använda andra ontologier. Vi vill gömma funktionen för dem som aldrig behöver den, för att inte verktyget ska bli svårare att använda.

Jag ska återgå till presentationen. Jag är i skrivande stund 37 år gammal och har jobbat som webbutvecklare och utbildare för samma företag i drygt 15 år före jag kom till YLE. Utbildningarna skedde till 90% i samarbete med Arcada och jag har stått tusentals timmar i klassrum både på Drumsö och i Arabia när Arcada flyttade dit. Nästan all utbildning har skett inom fortbildningen för vuxna elever och kurserna har handlat om allt från fotografering och Microsoft Excel till programmering i olika språk, som PHP, HTML (förlåt, purister), JavaScript och Flash Actionscript.

När jag kom till YLE hade jag inte speciellt djupa kunskaper om Drupal, eftersom jag i omkring 10 år arbetat med en konkurerande produkt, ett eget innehållshanteringssystem som gör ungefär samma saker som Drupal. Det var intressant att märka att många av de lösningar som finns i Drupal är saker som jag själv har funderat på och det var därför inte särskilt svårt att “komma in” i Drupals sätt att göra saker och reglerna för hur man skräddarsyr lösningar.

I mitt tidigare liv som utvecklare arbetade jag mycket och ofta med olika webbprojekt. Den stora skillnaden mellan mitt liv då och nu var att organisationen var så liten att jag ofta “fick” vara med och t.o.m ansvara för hela processen: Det första mötet med en ny kund, skrytande med tidigare projekt, genomgång av kundens specifikationer och önskemål, frågor om budget, planering av en offert som passar in i nyssnämnda, utarbetande av tidtabell, förverkligande av layout, html, javascript, css, php, databas, kommunikation med kunden per email, telefon och regelbundna möten under projektets lopp, registrerande av webbadress, konfigurering av server och e-post, testande, buggfixar, avslutande av projektet, klagomål… Exempel på projekt vi gjorde var webbshoppar, valmaskiner, auktionssystem, ekonomisystem, “vanliga” webbsidor och många helt skräddarsydda lösningar för vad kunden sade sig behöva.

Det som övergången till YLE har medfört är en möjlighet att få fokusera på färre saker och göra dem mera ordentligt. Jag var en sorts allt-i-allo och nu ser jag mig mera som webbutvecklare eller kodare som också får vara med och visionera och planera ibland, men som ändå huvudsakligen arbetar med ett ganska snävt område. Faran med att, som jag tidigare gjorde, jonglera så många uppgifter och t.o.m olika projekt samtidigt är att kvaliteten lätt blir lidande. Speciellt som man hela tiden begränsas av slutsumman på en offert som oftast ligger i den lägre ändan av vad som är mänskligt möjligt. Risken är också att man är för fokuserad på “the bottom line” och inte kan vara stolt över att man gjort nåt fint, utan endast då firman tjänat en massa pengar.

I mitt privata liv dras jag främst till olika kreativa hobbyer, som fotografering, chiliodling, matlagning, bakning, pianospel, hemrenovering. Jag bor i ett hundra år gammalt hus med många flagande ytor och spruckna väggar och försöker så småningom lära mig rätt sätt att ta hand om stället. Datorer ligger också ganska nära hjärtat och när min son nu nått den mogna åldern av tre år, så är det intressant att se hur han tar till sig teknologi. Det tog förvånansvärt länge för honom att förstå varför det ska finnas tv-program som kommer bara en gång och ett visst klockslag. Han är också ytterst förbryllad när man talar i telefon med nån utan att se personens videobild. I hemlighet avundas jag honom som fötts till en värld som är så mycket mera teknologiskt avancerad än min var på sjuttitalet. Jag tror det säger en del om hur jag är som människa och mitt motto eller min livsfilosofi kunde egentligen uttryckas som “visa mig flera coola saker!”. Det känns som att många här på YLE tänker i liknande banor, så jag kände mig både hemma och välkommen från början.

Varför kan jag inte bestämma exakt var bilden/videon/citatet finns?

Det korta svaret:

Vi vet inte exakt hur innehållet kommer att visas beroende på om användaren har en mobil, pekdator eller dator. Vi vet heller inte vad som kommer att vara det sätt som användarna använder sig av om bara några år. Därför gör vi flera designmönster som systemet kan välja bland. Det bäst passande mönsteret visas till användaren utgående de parametrar vi kan avläsa om användarens utrustning.

Responsive design - så ser demon ut på big screen, laptop, tablet och mobil

Då jag säger att vi inte vet hur innehållet kommer att se ut så är det mer relationen mellan innehållsbitarna som vi inte känner till. Att kolla på sin egen dator med en viss webbläsare/skärmupplösning och utgående från det bestämma var radbrytningar skall finnas (för att ge ett visst utseende) är bortkastad tid och grus i maskineriet.

Samma sak gäller om det är en bilds/videos/bildgalleris placering till höger/vänster eller vilken storlek den skall ha. Systemet behöver kunna bestämma designmönster utgående från apparaten.

Ett exempel: Om Text-tv skulle använda samma innehåll som webbtjänsten skulle ett radbyte i rubriken ställa till problem då rubrikerna i Text-tv alltid bara är en rad.

Detta sätt att styra utseendet framtidssäkrar vårt innehåll. Vid systembyten är den stora stötestenen hur utseendet skall migreras. Med detta upplägg så kan vi bygga nya designmönster som passar det nya systemet utan att gammal formatering av innehållet blir i konflikt med det nya.

Det långa svaret:

Yle har bestämt att öppna sitt innehåll och börja använda sig av API:n (Application Programming Interface) (Yle avaa sisältöjään, pysy kuulolla! ). Under en av de många workshops som hölls då den strategin utformades talades det mycket om innehållsstrategi (content strategy).

Vad är det då? I korthet: Innehåll som är formaterat på ett sätt som gör att det kan användas på ett mångfacetterat sätt. På detta sätt framtidssäkras innehållet. Ett talande exempel om värdet av innehåll gavs av Karen McGrane: Tv-guide (Amerikansk tidning) beslöt sig länge före det fanns elektroniska programguider i tv, på webben eller i mobilen att skriva en kort-, medel- och lång- textbeskrivning av programmen. Ingen visste var texterna skulle användas, eller exakt hur de skulle användas. Video: Karen McGrane: Adapting Ourselves to Adaptive Content – An Event Apart

Det var intressant att få dessa exempel, för det är den linje vi också valt utan att ha följt med diskussionen om innehållsstrategi (content strategy). Förutom att vi inte tillåter att man själv kan bestämma var och hur bilder etc. placeras har vi heller inte en förhandsgranskningsmöjlighet. Orsaken var att vi vill att man inte skall stirra sig blind på att hur artikeln ser ut på den dator som man skriver den på.

Den design lösning som vi använder oss av upptäcker om man kommer till svenska.yle.fi med mobil, pekdator eller dator och anpassar sig därefter. För att det skall vara möjligt behöver vi veta att viss information alltid finns tillgänglig.

Exempel: Om en bild eller text saknas så har vi inget att visa, och behöver då i designmönstret planera för det.

Ibland finns det info som systemet inte klarar sig utan (t.ex. rubrik, beskrivning). Vi designar därför för olika format (med format menar jag att det finns en viss mängd information, t.ex. rubrik, ingress, bild, länk som man använder som modell då man gör ett designmönster).

Då nya apparater kommer ut på marknaden så kan vi designa för dessa utan att det blir en konflikt med de existerande designmönstren. Det förutsätter dock att formatet är väl uttänkt och inte används på ett motstridigt sätt.

Exempel: Vi kan visa text i fet stil inne i brödtexter på den vanliga webbplatsen. I någon applikation som vi bygger så kanske det inte är möjligt.

Då Yle går in för att använda sig av API:n kommer vi också att vara beroende av att ha format och designmönster. Om vi vill hämta programinfo så behöver vi kunna lita på att vi alltid får ut rubrik, beskrivning och sändningstid. Om någon annan använder svenska.yle.fi:s artikel API så behöver de i sin tur kunna lita på att de får ut artiklar som är just vad det står att de är: artiklar. Om artikeln inte är en ren artikel så är det inte möjligt för dem att bygga egna designmönster som fungerar i alla situationer.

Ett bra exempel på där det inte ännu fungerar så bra är svenska.yle.fi/regioner (en ny version är på kommande). Orsaken det inte fungerar väl är att vi inte alltid vet om det finns en bild, samt att rubrik- och textlängd ibland varierar kraftigt. Designmönstret klarar i detta fall inte av att kompensera variationen i innehållets format. Det är också till format som dessa som sammanfattningen (ingressen) behövs som ren text (utan bilder, bildgallerier eller videon).

Då formatet inte går att lita på fungerar inte designmönstret:
Regioner - problem
Så som det borde se ut:
Regioner - hur det borde se ut

Värdet av att ha ett innehåll som inte sitter fast i ett utseende kan vi se på svenska.yle.fi då vi nu håller på och migrerar material från våra gamla sajter. Från nyhetssajten gick det bra då formatet var i gott skick och hade en tydlig struktur. Därför kan vi nu använda dem, och t.ex. på Radio Vega automatiskt lyfta in artiklar som publicerades just nu, men för tio år sedan.

Vi hade inte samma tur med Mat & fritid där artiklarna till 100% hade layoutstyrning inne i själva texterna. Dessa artiklar ser nu inte så bra ut som vi skulle vilja, och det kommer inte att gå att göra designmönster som fungerar felfritt då nya användningssätt uppstår.

Publiksiffror för svenska.yle.fi, tidsperioden 1.5 – 31.12.2012

Bara några korta kommentarer till bildpaketet, som laddats upp här nedan.

Jag blandar lite, för i kurvorna använder jag unika webbläsare som ”valuta”, medan jag i  topplistorna använder sidvisningar.

Eftersom flera av artiklarna tagit sig med på listan tack vare att de är sk. snackisar, ville jag ha sidvisningar. Jag misstänker nämligen att samma människor öppnat artikeln gång på gång på gång för att läsa diskussionen och kommentera mera.

Jag har också parat ihop kurvorna med kriteriet att de alla skall rymmas på samma bild. Därför är också X3M:s kurva ensam – alla andra kurvor ser så flacka ut i samma bild!

Håll också ett öga på de totala sidvisningarna i topplistorna. Vink till hur du tolkar det? Läs totala sidvisningar i första topplistan och jämför de kommande listorna med den…

Eftersom vi under 2012 bytte till Comscore Digital Analytix, så gäller siffrorna inte för riktigt hela året. Alla listor och kurvor är för perioden 1.5 – 31.12.2012.

ps. De veckorna kulturkurvan ligger på noll är en bugg. Jag jobbar på att fixa det.

Karoliina Korhonen, nätanalytiker

DUI-heatmap Finland 2012

A month ago I created a heatmap visualization of driving under influence records in Finland 2012. The story and visualization itself were fairly popular on svenska.yle.fi during the week of the release, ranking up to be the most read news-article (see inrikes category artikel.har-aker-rattfylleristerna-fast-se-karta.sivu). It also raised a fair amount of feedback trough the comments section about usability of heatmap visualizations in general.

Heatmap
Heatmap of DUI-incidents at Helsinki area

Heatmaps are a bit tricky to use as visualizations. XKCD-comic has tackled the essence of it. If a map correlates heavily with the population distribution, it may only tell to the viewer what people can already expect, things happen where there is a lot of people. Also when the visualization is dynamic, you get more details on demand. When you zoom in, you’ll see more details and when you zoom out you see less details..which can mean that there will be a huge red blob on top of a map at certain distance.

The data for the map was acquire by a journalist via a information request to police. We received it as an excel-form with 20352 lines of raw data of DUI incidents in Finland. Data included an identification number to police records, municipal area and a mysterious area code, street-address of incident, weekday of incident and date and time of incident. As usual the data was somewhat ‘dirty’ and required thorough clean-up to make it fit our needs.

Screen Shot 2013-03-21 at 12.44.34 PM
Raw-data in Excel

Data itself may reveal patterns and information about measurement and how it was collected. In our case we noticed that the naming convention of incident addresses is fairly imaginative. There’s an address-field that police officers fill in, among other things, when they report the DUI incidents into the system. This field should contain an address of incident so it can be pinpointed if necessary. However there doesn’t seem to be an unified practice of reporting the addresses.

Address field seems to be filled in many different ways which makes the exact pinpointing of the incident later on a fairly difficult task. For example an incident address that has happened at crossroad of two roads might be marked as road1 X road2, or road1, road2 crossroad or road2xroad1 or  road1 at crossroad road2 etc. Or the address-field has been used to give more information about place of incident instead of just an address, i.e. Address xyz, from the yard.

My personal favourite version of the data in the address field was ‘Kylän Kohdalla Jäällä’ = ‘at the region of the village on the ice (lake)’, which couldn’t be more vague in terms of locating the exact spot.

Sure, all these addresses could probably be pinpointed by someone with knowledge of local surroundings, but for outsiders the location stays a mystery. For a future implementation of such a system I’d highly recommend adding the possibility to insert longitude and latitude coordinates field. But enough ranting and back to the topic.

The dataset is fairly large (20k+ addresses) and if one wants to get a overview of geographically distributed data one method to approach this is to plot incidents on to a map. But what tool to use?

I personally prefer to use existing methods and tools to visualize and gain insight on data and after googling for a while I bumped into a heat map javascript library called Heatmap.js. So it was chosen as a prominent technology to implement the test-case. A random city of choice was chosen -Tampere.

The next task was to figure out how to translate this given data from excel-format into a format that Heatmap.js accepts. Heatmap.js uses a list of longitude and latitude coordinates and a weight of how many incidents are at those coordinates. The weight can be calculated in Excel by counting the amount of occurrences of addresses, but the addresses need to be converted into coordinates. This conversion of address into longitude and latitude is usually referred to as geocoding.

Geocoding multiple addresses
Geocoding multiple addresses trough yahoo api

There exists a fair amount of web-based tools to quickly geocode a single address into gps coordinates. I used http://www.gpsvisualizer.com/geocoder/. It’s probably not the best, but it gets the job done. The downside of it lies in the ability to geocode multiple addresses. Gpsvisualizer.com offers an ability to use yahoo geocoder for multiple addresses, but sadly it’s fairly inaccurate in Finland. For example I tried to geocode street-addresses from Tampere and ended up getting a wad of similar coordinates.

But it’s possible to geocode a single address at a time with Google geocoder at gpsvisualizer.com, which gives much more accurate readings, but as you would guess it is also a lot slower method. As I had a deadline breathing down my neck and 20k+ addresses to geocode I gave it a shot. In my case roughly a week of typing and copy+pasting, so clearly a slow method.

Geocoding one address
Geocoding a single address trough google api

A slightly better way to do this is to use Google geocoder api and create your own geocoder. This is the method I would use to geocode multiple addresses now if I’d have to do another address based visualization. But at the time I was working on this the deadline was looming on and I was busy with getting the visualization forward. So I accepted the fact that I’d be spending a considerable amount of time on smashing the same button combination over and over.

Screen Shot 2013-03-21 at 4.36.09 PM
Geocoding multiple addresses trough google api

After the data was in a appropriate format for visualization tool it was a fairly straightforward job to fine tune it and release it.

Well, what I learned from the project or at least reconfirmed, is that 80 percent of the time goes into purifying, transforming and fiddling with the data to get it into a format that can be represented and the rest 20 percent is fine-tuning and adding extra functionalities into it. An interesting dataset and a fun project, and when the data is interesting it seems to translate fairly well into ‘news’.