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.