Ny version av IMS på svenska.yle.fi

Efter fem år och 165 000 bilder är det dags att ge IMS (Image management system) som används på svenska.yle.fi ett ansiktslyft. Den nya IMS-versionen har nya funktioner och ett nytt utseende. Om allt går enligt plan tas den i bruk onsdag 26.3.

För alla användare betyder det vissa förändringar, här kommer några skärmdumpar och info om förändringar:

Man öppnar IMS på samma sätt som tidigare
Man öppnar IMS på samma sätt som tidigare. Nu kan man också öppna bilden för redigering genom att klicka på bilden.
Så här ser första vyn ut där man kan välja vad man vill göra
Så här ser första vyn ut där man kan välja vad man vill göra
Bläddra och välj bild
Bläddra och välj bild
Vy man ser då en ny bild har laddats upp
Vy man ser då en ny bild har laddats upp

Om den bild man laddar upp inte är tillräckligt stor varnar systemet om detta. Minimistorlek är 1600×900. Systemet tillåter dock allt som är större än 640×360 px.

Det finns skäl att alltid eftersträva en så stor bild som möjligt. På svenska.yle.fi börjar vi nu använda en bild som är 880×495 px. Om bilden inte uppfyller den storleken kommer vi att förstora den artificiellt. Man kan jämföra med hur man gör med 4:3 bilder som sänds i tv som 16:9.

En annan aspekt är att högupplösta skärmar tas i bruk i allt större utsträckning. Det gör att vi väldigt snart är tvungna att ta i bruk en ännu större storlek fast vår bildbank i IMS inte har tillräckligt stora bilder. Ladda därför alltid upp bilden i största möjliga storlek.

Beskärning går nu att göra i 16:9-, 1:1- och 2:3-format
Beskärning går nu att göra i 16:9-, 1:1- och 2:3-format

Till de bildversioner som besökarna på svenska.yle.fi ser använder vi en automatiskt ansiktsigenkännings-funktion ifall en manuell beskärning saknas, vilket fungerar i 70-90% av fallen. Det ersätter med andra ord inte att en människa beskurit bilden. Då du skall beskära de enskilda formaten klickar du på respektive miniatyrversion (som automatiskt visar en förhandsversion av slutresultatet).

Om beskärningar inte gjorts så ser bilden ut så här för administratorer, så att man skall ha en möjlighet att se att bilden inte är beskärd.
Om beskärningarna saknas ser bilden ut så här för administratörer. Orsaken är att man då ser att bilden behöver beskäras.

Då du väljer en bild skall du alltid kontrollera att beskärningen är korrekt. I föregående version av IMS sparades inte beskärningsdatan eftersom beskärningarna sparades direkt i den enskilda bildfilen. Det ledde till att vi inte kunde återskapa hur bilden varit klippt tidigare. Oberoende av det så behöver en människa kontrollera 1:1- och 2:3-formaten som är helt nya och saknar beskärning.

Detta gör att en okänd procentandel av våra bilder nu är klippta på ett icke kontrollerat sätt (skedde per automatik vid migreringen).

Om du ser en bild som behöver korrigeras kan du öppna den i IMSen genom att gå in och redigera artikeln. Väl inne i artikeln öppnar du den specifika bilden i IMSen genom att klicka på bilden.

De enskilda fälten har fått förklaringar:

För att andra skall hitta din bild lönar det sig att  skriva bra taggar. Separera taggarna med kommatecken,

För att personer som har en synnedsättning också skall veta vad som visas på bilden är ALT-fältet obligatoriskt.

För att personer som har en synnedsättning också skall få veta vad som visas på bilden är ALT fältet obligatoriskt.

Detta fält var tidigare inte obligatoriskt. Om du redigerar en gammal bild blir du därför tvungen att skriva beskrivningen.

Till de nya funktionerna hör:

  • I de situationer som svenska.yle.fi av layoutmässigaskäl behöver veta bildens format och storlek kommer 16:9 formatet att användas
  • Exempel: En bild som du laddar upp kommer alltid att finnas också som 16:9. Om bilden är satt som huvudmedia i en artikel kommer den med nuvarande layout aldrig att visas som 1:1 eller 2:3. 1:1-, original- och 2:3-beskärningen kan du använda inne i en artikels brödtext genom att då du sätter in bilden välja en av dem.
  • Inne i artiklar kan man välja att en bild är 1:1, 16:9, originalformat eller 2:3
  • Inne i artiklar kan man välja att en bild är viktig, den kommer då att visas i ett större format än en bild som är insatt som standard
  • Du kan ladda ner en bild i den storlek som Arenan behöver direkt från IMS
  • Bilderna levereras nu via en CDN (Content Distrubution Network) som gör att bilden levereras snabbare för att den kommer från ett datacenter som är nära användaren
  • Rotera bilden direkt i IMS
  • Bilderna kan visas i vilken pixel-storlek som helst, vilket gör att vi kan skapa bättre användarupplevelser. Vi kan ladda bilder exakt så stora som de på riktigt behöver vara, och användaren behöver inte ladda ner en för tung bild.
  • IMS kan stänga av visningen av alla bilder i svenska.yle.fi om vi av ngn orsak måste minska på hela sajtens vikt. Kan bli aktuellt t.ex. vid en DoS-attack.
  • ”Ersätt bilden”-funktionen beaktar att bildens bredd/höjd kan ha ändrat

De första dagarna kommer bilderna på svenska.yle.fi och admin att vara lite långsammare, men snabbas upp vartefter fler och fler av bilderna har visats och lagras i CDN:ens cache.

Tack till Rasmus och Tero för deras insatser.

Video på nätet gör revolution

Videokvalitet på nätet utvecklas just nu i rask takt. För några år sedan fick vi nöja oss med resolutioner på 240p, 360p eller 480p. I dag har 1080p blivit en allmän standard medan vi med god fart är på väg mot 2160p.

video_resolutioner2

Siffrorna står för antalet vertikala bildpunkter, så att exempelvis 1080p betyder 1080
bildpunkter lodrätt och 1920 bildpunkter vågrätt. Resolutionen 4K, även kallad Ultra HD
eller UHD, är fyra gånger så hög, det vill säga 3840 gånger 2160 bildpunkter.

Videotjänsten Youtube erbjuder sedan fem år tillbaka 1080p och accepterar sedan tre år tillbaka även 2K, 4K och till och med 8K. Filmtjänsten Netflix erbjuder i sin europeiska version de flesta filmerna i 1080p och planerar inom kort börja testa 4K.

Hårdvaran ute på marknaden har allmänt hunnit ikapp med 1080p. Mobiltelefoner och pekplattor som klarar ”Full HD”, eller 1080p, har på allvar etablerat sig under det gångna året.

Beträffande Ultra HD eller 4K har marknaden ännu en bit att gå. Datorskärmar och TV-apparater som klarar 4K har på allvar dykt upp först under år 2013. Priserna är ännu på en nivå som avskräcker de flesta konsumenterna. Samtidigt har konsumentinriktade videokameror som klarar 4K dykt upp på marknaden.

Högre videokvalitet kräver högre bandbredd. Nätuppkopplingar som klarar av att strömma video i 1080p är i dag vanliga i Finland. Uppkopplingar som klarar 4K börjar likaså bli allt mer tillgängliga. En uppkoppling på 10 Mbps (megabitar per sekund) räcker i allmänhet för 1080p, medan en uppkoppling på närmare 100 Mbps brukar rekommenderas för att 4K ska fungera problemfritt.

Videokvalitet handlar inte bara om resolution utan även bland annat om kompression, som för de högre resolutionerna på nätet ofta innebär ”H.264” eller ”AVC”. Den högre videokvaliteten kräver mera kraft av den hårdvara som ska ”packa upp” videoströmmarna, vilket ställer högre krav på bland annat processorer och grafikkort.

Var befinner sig då Yle Arenan då det gäller bildkvalitet? Arenan erbjuder i dag (december 2013) en resolution på maximalt 360p, vilket motsvarar 360 bildpunkter på höjden och 640 bildpunkter på bredden. Bandbredden är 654 kbps (kilobitar per sekund) för bilden och 96-128 kbps för ljudet.

Som jämförelse kan nämnas att den ”gamla vanliga” TV-resolutionen i Europa, införd på 1950-talet, är 720 gånger 576 bildpunkter (PAL).

Under år 2014 ska Yle Arenan enligt planerna börja ge tekniska möjligheter att erbjuda video i 1080p. Ändringarna går hand i hand med att Yle så småningom ska börja erbjuda alla sina TV-kanaler i 1080i.

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:

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.

Så flyttade vi tio års arbete

Finnairplan i farlig situation” lyder en rubrik publicerad på Yles webbnyheter onsdagen den 30 oktober 2002, klockan 10.35. Den rubriken inledde ett årtionde med verktyget ”Nyhetswebben”.

Ett decennium och 225 000 artiklar senare har Nyhetswebben ersatts av ett nytt system, ”Drupal”. Men de gamla nyheterna finns kvar.

Hur flyttar man tio års arbete mellan två olika system? Det var en utmaning som Svenska Yles webbavdelning stod inför år 2012. Nyhetswebben är ett lättviktigt internt verktyg, medan Drupal är ett komplext öppet verktyg.

Till att börja med sammanställde vi en ”Entity Relationship”-modell som visualiserar hur nyheternas databas är uppbyggd. ER-modellen avslöjar relationer mellan databasens tabeller och kolumner. Denna information hjälpte oss utveckla skript för att pussla ihop artiklarna.

ER-modell

Följande steg var att kartlägga innehållet. Den gamla nyhetssajten bestod ju inte enbart av nyheter, utan även av kolumner, fördjupningar och bloggar, med mera. Kartläggningen hjälpte oss besluta vilka delar av innehållet som skulle migreras, och i vilken ordning.

Vi undersökte och utvecklade tekniska migreringsmetoder. Vi beslöt exportera innehållet från den gamla databasen som en XML-ström (Extended Markup Language) och importera den genom Drupal-modulerna ”Feeds Import” och ”XPathParser”.

Två delar

Migreringen består huvudsakligen av två delar; dels av en exportdel som skapar en XML-ström ur det gamla systemet, dels en importdel som fogar in XML-strömmen som artiklar i det nya systemet.

Exportdelen utgörs mer tekniskt av ett PHP-program som kör MySQL-kommandon i databasen. Programmet pusslar ihop enskilda informationsbitar till artiklar. Artiklarna blir separata objekt i XML-strömmen, så att varje enskild informationstyp får en egen XML-tagg. En utmaning i exportdelen var att ”tvätta” dataströmmen så att avvikande eller korrumperade informationsbitar inte skulle söndra importen.

Den tekniska utvecklingen utmynnade i detaljerade planer. Detta var första gången vi migrerade ett så stort antal artiklar till ett nytt system och vi ville vara säkra på att processen skulle fungera.

Redan de första testerna visade att Drupal inte kan hantera 225 000 artiklar utan prestandaproblem. Det behövdes mellanlagring bland annat via programvarorna ”Memcache” och ”Varnish” för att höja prestandan till en acceptabel nivå. Ytterligare skapade Drupal för varje artikel ett visst antal lyft – lika många lyft som antalet avdelningar artikeln hade funnits i. Detta gjorde att det totala antalet artiklar i Drupal steg till mer än en halv miljon.

Testerna visade också att importen måste köras stegvis för att undvika tekniska avbrott, så kallade ”timeouts”. Vi skapade ett ”Drush”- (Drupal Shell) kommando som kunde köra importen i mindre paket. Detta kommando kördes i sin tur av ett ”Linux Shell”-skript automatiskt i etapper om hundra artiklar åt gången. Hela importen av de gamla nyhetsartiklarna tog ungefär sju timmar i anspråk.

Migreringen fortsätter

Importen av gammalt innehåll har fortsatt med bland annat ”kulturen.fi” där vi använde samma migreringsmetod som för nyheterna. I detta projekt testade vi också att importera artiklar direkt från RSS-filer (”Rich Site Summary”), vilket fungerar nästan lika bra. RSS är en sorts XML. Problemet med RSS-filer är dock att deras syntax är mer begränsad.

För ett tredje projekt, ”Maktbasen”, importerade vi icke-standardiserad information i form av så kallade entiteter, så som personer, företag och kommuner. Det fanns en del halvfärdiga importmetoder tillgängliga ute på fältet, men det effektivaste sättet för oss var att importera entiteterna direkt till Drupals databas.

Drupals entiteter består av en huvudtabell där innehållet hålls ihop av ett unikt ID, samt enskilda tabeller för alla fält som ingår i en viss entitet.

Migreringen av innehåll har fortsatt med bland annat Mat och fritid. För Mat och fritids recept använde vi en likande XML-generator som för nyheterna, men skapade en ny importör, eftersom recepten fick en egen innehållstyp i Drupal.

För resten av sajtens artiklar använde vi nyhetsimporten som vid det här laget hade utvecklats till en generell importör för artiklar. Denna XML-importör kan numera användas för i princip vilken typ av innehåll som helst som kan översättas till XML.

Fotnot:
Verktyget ”Nyhetswebben”, skapades ursprungligen av Robert Tamm. Nyheterna, tidigare ”Internytt”, har även använt andra webbverktyg. Artiklarna från tiden före oktober 2002 verkar dock till största delen ha gått förlorade.

Nyhetswebben 2.1

Vill du jobba med datajournalistik eller spel? Ansökningstiden har utgått.

Den 22.11 2012 gick vi ut med att vi söker efter två utvecklare till Svenska.yle.fi. Det här är en stor grej för oss på Svenska Yle då vi inte haft en möjlighet att verkligen utvidga vårt team så här sedan början på 2000-talet, trots att behovet ökat markant på 12 år. De jobb vi nu lediganslagit, ett webbutvecklarjobb med inriktning på spel och ett webbutvecklarjobb med inriktning på datajournalistik, visar också klart på vilka delområden Svenska Yle satsar på. Vi valde avsiktligt att inte gå på Monty Python-linjen den här gången eftersom man inte kan upprepa en likadan reaktion två gånger. Förra gången vi sökte en webbutvecklare som ersatte en person som slutat gick det nämligen så här.

Båda jobben är mycket intressanta och ger den personen som får jobbet möjlighet att jobba med ett team som är framåt och otroligt duktigt.

Det har redan länge stått klart att vi behöver mer krut för att kunna presentera innehåll som datavisuliseringar och stöda datajournalistiken på Svenska Yle. Trots att vi inte haft en enda dedikerad person för jobbet så har vi lyckats skapa en hel del journalistiskt innehåll utgående från tillgänglig data. Orsaken till att det lyckats är att en av Finlands främsta personer när det gäller datajournalistik finns i vårt team, Teemo Tebest, som har gett oss en insikt i hur mycket man verkligen kan göra med den data vi har tillgång till. Det mest uppmärksammade projektet vi gjort är Maktbasen http://svenska.yle.fi/maktbasen, men vi har också jobbat fram Svenskfinland som fem storkommuner utifrån datan i Maktbasen. Därutöver har vi haft mindre projekt, till exempel Alkoholkartan och Hjälp Kalle. När vi nu utökar vårt team med en webbutvecklare som skall ha som sin huvuduppgift att jobba med datajournalistik blir det en hel del annat att se fram emot.

Varje år har BUU-klubbens webbsatsningar och spel skapat glädje och förtjusning hos både barn och vuxna. Det är helt klart ett monsterjobb som har skötts med små resurser och med stor passion. Nu ser vi en stor potential och en massa outforskade möjligheter i den barnwebbsproduktion vi kan skapa, men vi klarar inte av att göra mera utan att få förstärkning. Pia Manns är den person som drivit produktionen och även i år skapar en helt fantastiskt fin julkalender som kommer att tvinga föräldrarna att slita loss sina barn från datorerna så att de själva skall hinna spela. Det paradigmskifte vi nu har framför oss är att kunna nå ut till alla mobila plattformar, som pekplattor och telefoner, men det går inte att direkt lösa med den teknik vi använder idag. Personen vi är ute efter ska kunna se potentialen i koncepten då det gäller att anpassa dem till andra plattformar, men också att kunna göra själva jobbet. Det gäller ju inte enbart BUU, utan man har hela Svenska.yle.fi som spelplan, ja varför inte även finska Yle om det blir tid över för att kunna göra spel av journalistiskt innehåll tillsammans med hela vårt team.

Bilderna med plock ur BUU-klubbens e-post respons

 

jagfyläråridagsnälajörnyaspel

 

hei buuglup minä aijon pelata paljon teidän pelejä ne ovat  kivoja pelejä
ja hyvin keksitty ja heippa minä alan nyt pelaamaan

 

– Häj jag vill att ni lagar nya häst spell och ett nyt bill spell.

 

BUU-KLUPPEN ON KIVA PAIKKA MÄ JA MUN PIKKUSISKO PELATAA SITÄ MELKEIN AINA KUN ON TYLSÄÄ

 

jag tykär at ni har brasidår måna pusar å kramar

 

hei minä en pidä saha pelistä voisitko laittaa jotain pelejä kiitos

Theme layer i Drupal 8 – DrupalCon

Under Drupalcon i Munchen kunde man bekanta sig med de projekt som är på gång inför Drupal 8 (planerad lansering Augusti 2013). Det projekt som kommer att påverka flest användare är Spark / Dries tillkännagivande av Spark. Spark är en WYSIWYG editor som fungerar direkt på sidan, responsiv layout designer, mobil verktygsfält och mobil anpassningar. Allt detta gör det mycket lättare att se hur de ändringar man gör ser ut.

En demo hur Spark fungerar

Spark kommer att finnas som contrib för D7, och målet är att bli del av Core i D8.

Kärnan i Spark utgörs av Aloha Editor som Drupalcon till ära tillkännagav att de ändrat sin licenseringsmodell så att Aloha kan användas i Drupal utan restriktioner.

Aloha Editor är den mest imponerande WYSIWYG editor jag sett. Det är inte bara kodmässigt en bra lösning, utan den ger också användaren en mycket bättre användarupplevelse – mer i stil med hur man redigerar text i Word eller Google Docs. Den klarar till och med av att hantera text som kopieras från Word utan att markupen blir full av onödig kod.

En klar fördel med Spark är också att ”förhandsgranska”-funktionen blir onödig. Detta för att ändringarna man gjort ligger färdigt framme med rätt utseende. På samma sätt som i ett textbehandlingsprogram kan man fritt ändra, för att sedan spara då man själv är nöjd.

Vi funderar på att antingen ta i bruk Spark på Drupal 7 eller att testa Aloha Editorn ovanpå våra befintliga lösningar. Att sätta den på de existerande redigeringssidorna (ej inline i frontend) vore enbart i sig lockande då redigeringsupplevelsen blir så mycket bättre.

Ett annat mål är att snabba upp front end, då den just nu i många system, inte bara Drupal tar en oproportionerligt stor del av tiden. Se t.ex. ”The performance golden rule”.

På BoF (Birds of a feather) diskussionerna om Drupal 8 talades det mycket om Twig som den nya lösningen för templat-lagret. Det verkar som om det råder en konsensus om att det är den bästa vägen framåt. Det jag främst tycker verkar fint är att man kan hämta ut innehållet ur Arrayn på ett tydligare sätt. Många funktioner flyttar också ut från templaten.

Här kan du se presentationen och höra ljudet från A designer-friendly theme system in Drupal 8?

Om du vill testa Twig finns det ett sandbox projekt här. Nackdelar som det talades om är Twigs licens-modell som ännu inte är kompatibel med Drupals, och att Twig som system på ett sätt introducerar ett till lager i templatsystemet.

@JohnAlbin visade också sin kartläggning av theme layer i D7 jämfört med D8. Det är en viss skillnad i komplexitet 🙂 Uppdatering 11.9 – här kan du jämföra kartläggningen av D7 med den i D8.

Det talades också om möjligheten att skapa genriska hooks, vilka kunder återanvändas av contrib moduler. Skulle isåfall kunna betyda mindre templat-kod i modulerna. Blir intressant att se om det blir av.

Kan också notera att temandet väcker större intresse, t.ex. tog sittplatserna slut vid åtminstone två tillfällen.

Missa heller inte Drupal 8: What you need to know.

Övrigt
@emmajanedotnet höll en bra presentation av vad man bör tänka på då man väljer bastema. Det här skulle jag själv ha velat höra för ett och ett halvt år sedan. Frågan är ifall ngt kunnat göra jämförelsen då, rätt mycket har ju hunnit hända. Har du inte valt bastema ännu, kolla på denna.

DrupalCon 2012 München

En del av Svenska.yle.fi hade möjligheten att som en skolningsresa delta i årets europeiska Drupalkonferens som i år ordnades i München. För mig var detta mitt första Drupalevenemang så jag visste inte riktigt vad som väntade. Då Robert Douglass dök upp i öppningen av DrupalCon iklädd dirndl och några minuter senare salen genomljöd av 1800 programmerare som joddlade steg nog orosmålen några pinnsteg …

Men snabbt blev det nog klart att ovannämnda hör till den familjära atmosfär som präglar Drupalcommunityn, och själva programmet var ytterst intressant och mångsidigt. Stor fokus låg på utvecklingsarbetet med D8, följande version av Drupal. Det arbetet är nu inne på slutrakan och de funktioner som skall med bör vara klara i december. Lansering planerad till augusti 2013. Tills dags dato har över 600 webbutvecklare arbetat med D8.

 

Utvecklingen av D8 visar på flera intressanta spår för Drupal. Ett av dem är implementeringen av php-ramverket Symfony. Detta innebär en fortsättning på breddningen av Drupals verktygspalett till externa open source-lösningar, en utveckling som redan tidigare inletts med implementeringen av javascriptbiblioteket jQuery i D7. Det här var ett spår Henri Bergius var inne på i sin keynote Decoupling content managment. I hans mening är fortfarande samtliga CMS monoliter, som borde brytas ner.

 

Utvecklingsarbetet med arkitekturen i D8 forsätter med fokus på att ytterligare underlätta såväl testning, lansering och uppgradering genom att hålla olika lager mellan innehåll, frontend och backend separata. Ett annat steg är de stora framsteg som gjort i användarvänlighet och WYSIWYG-uppdatering i D8 i och med Spark-projektet och Alhoa-editorn. Imponerande grejer! Se själv:

Förutom det mer tekniska snacket jag i ärlighetens namn stundvis hade svårt att hänga med i, kom där också många intressanta saker fram som mer berör mitt eget konceptutvecklarperspektiv. Både Dries Buytaert och Anke Domscheit-Berg pratade om hur Drupal använts för att främja genomskinlighet, samarbete och deltagande mellan myndigheter och medborgare, dvs. det sk. Government 2.0.

 

Drupal har också framgångrikt använts av ideella organisationer som behöver ett system för att med minimala instegskostnader få upp en webbplats. Öppna ”distron” är här till stor hjälp, de är liksom nycklarna-i-handen-färdiga-att-tas-i-bruk webbpaket. En intressant presentation på DrupalCom handlade om ett av dem, OpenAid.

Andan av open source kändes starkt på många håll. Förrutom ovan nämnda OpenAid så var det Sony-sponsorerade projektet med views i Drupal6 ännu i färskt minne. De investerade miljoner i utvecklingspengar för att bygga mångspråkiga sajter för fans till de stjärnor som de har hos dem. De släppte sedan allt vad du utvecklat öppet till Drupal-gemenskapen. Som sedan dess bidragit med vidareutveckling som skulle ha kostat oräkneliga miljoner . Samma kungstanke ligger bakom initiativet Large Scale Drupal (LSD) där de största aktörerna som använder Drupal samarbetar med stora utvecklingsprojekt. Jag ställde i detta sammanhang en representant från NBC frågan om detta är besvärligt ur konkurenssynvinkel, han menade att det inte är så. ”Det är ju innehållet vi konkurerar med, inte de tekniska verktygen vi använder för att publicera innehållet. Dessutom gav detta oss bra insyn och samarbete med hur t.ex. Disney löst en del problem som vi också haft”.

Utöver det officiella programmet var korridorsnacket, Birds of a Feather-sessionerna (spontana möten kring av deltagarna föreslagna ämnen) och möjligheterna att träffa de främsta experterna inom området verkligen givande. Vi fick t.ex. stor hjälp och härligt meningsutbyte av Lin Clark och Stéphane Corlosquet, de ledande krafterna inom semantisk webb och Drupal. Och Dan ”dman” Morrison gjorde en code review av Svenska Yles Onki-modul mitt under pågående konferens. Mer om allt detta kommer så småningom här på Utvecklingsbloggen.

Just dessa möten, gemenskapen, samarbetet (och det goda ölet i München) blev de stora behållingarna av DrupalCon 2012 Munich.

 

It’s all about the community

Group Photo* DrupalCon Europe 2012. Munich, Germany

PS. gratis Drupal-klistermärken till den som kan hitta bloggpostförfattaren från bilden ovan 🙂