Bra flyt för Yle Arenan

Yle Arenan har bra flyt för tillfället. Åtminstone om man ser på statistik. Antalet uppspelningar ökade år 2014 med cirka 15 procent.

”Konkurrenternas” siffror visar en nedåtgående tendens.

Bland svenskspråkiga program var KAJ:s julkalender den kanske största publikmagneten i Arenans historia.

Samtidigt som publiken strömmar till pågår febril utveckling bakom kulisserna. Detta för att kunna möta ökande belastning på systemen och ökande kvalitetskrav. Publikens engagemang har förutom i statistiken synts även på den respons som Arenan får in. Tekniska problem har flera gånger under året drabbat Arenan och besökarna har varit snara med att rapportera felen.

Arenans besökarmängder är redan nu cirka två gånger större än Ruutus eller Katsomos. Enligt statistiktjänsten Comscore är tendensen tydlig. Arenan visade ett ökande antal uppspelningar – cirka 15 procent under år 2014 – medan Ruutu och Katsomo visade en svagt nedåtgående tendens särskilt mot slutet av året.

Enligt MikroPC är Yle Arenan överlägsen etta då det gäller TV på nätet i Finland. Tidningen MikroPC valde Yle Arenan till årets fenomen år 2014 (http://yle.fi/yleisradio/ajankohtaista/mikropcn-vuoden-ilmio-palkinto-yle-areenalle).

Statistik för Arenan, Katsomo och Ruutu
Miljoner starter per tjänst år 2014. Källa: comScore (Yle), comScore (MTV), Drupal (Nelonen Media).

 

Kajs julkalender hade under perioden 1.12.2014 – 25.1.2015 totalt 559 459 visningar enligt statistiktjänsten Comscore. I siffran ingår uppspelningar via webbsidor och via mobila applikationer. I tabellen nertill syns uppspelningar per ”lucka”.

 

Statistik från Comscore
KAJ:s julkalender 2014, visningar per ”lucka” via webbsidor och mobila applikationer. Källa: comScore.

 

 

Linking metadata terms in two languages between two sites

Today yle.fi/aihe added the same-as link function to the Finnish terms. This makes it possible for users of yle.fi/aihe and Svenska.yle.fi (the Swedish pages got the function a while ago) to move between the metadata term page on the respective sites.

asiasana-urheilu

term-idrott

See http://svenska.yle.fi/term/koko/idrott-httpwwwysofiontokokop48399 and http://yle.fi/aihe/termi/koko/urheilu-httpwwwysofiontokokop48399

We also added a source link to http://finto.fi/koko/en/page/p48399

Two teams, two sites – one year with a shared Drupal distro at Yle

Today one year ago FYND (Finnish Yles New Drupal) launched it’s first site. Read about the work that went into the preparations here.

It has been a year of shared development when we really have seen the advantages of working on the same distro, and working with open source.

One of the first things we decided on was to work as two teams in a similar way to how NBC Universal works with their Drupal sites (or cells if you want to compare to how Supercell works).

”Clash of Clans and Hay Day were each developed by teams of just five developers. Even now they are global smashes each has a team no bigger than 15.” Ilkka Paananen in Wired Magazine

Is Five the Optimal Team Size? …the cost per function point of a team of size 7 was $566 and that of a team of size 14 was $2970 – Jeff Sutherland…If you have 3 team members, then you will have 4 communication channels, if you have 4 then you have 9. I think the formula is m-1^2. In my opinion, a small team of 4 or 5 is ideal. – PMHut

One idea that also was put forward was that we should work as one big team (quite common in big organisations I guess). We did however pursue the idea of having two teams, since we assumed this would make us more focused and productive. It would also allow us to better understand the business goals and needs if we got them independently from two sources (Svenska Yle and Yle Luovat sisällöt).

Issues in YDD

One year on we are happy with the end results, as the distro has continued steadily on its development path.

The main advantages with two teams and two sites have been:

  • Twice the amount of tasks have gotten done – everyone benefits
  • Maintaing the distro core is a shared task
  • You focus on the task at hand – not a zillion tasks all over the place
  • When there has been a module problem, there has been a clone site to compare with
  • We can mitigate the risk when a new function or module is activated, as we can share the burden by activating it on one of the sites before activating it on the other
  • It has been possible to compare notes, and get an “external” view on different tasks
  • External human & tech resources can be shared between the teams
  • Cross reviewing (using pull requests)
  • Documentation and best practices are better maintained as you clearly see the need and gain. In our case two semi separated teams provide better quality assurance than before
    • One observation is that quality assurance has gone up. One theory we have discussed is that it is because the teams see the other team as an outside party. The team members become aware that someone else will suffer if they write bad code or do not test their code. Just like in open source development where many eyes check the code, we are doing the same on a low level.

Main disadvantages:

  • Time is needed for co-ordinating
  • Time is needed to separate the settings for the two sites, but this would be needed just by the fact that we are running sites with two different languages
  • Risk for conflicting business goals – but this has been kept at bay by clearly stating that the purpose of the system is to provide articles publishing according to subjects.
  • If you break something you will get blamed

Some of the functionality we have shared over the last year:

  • API connections
  • New version of the Image Management System
  • New meta data solutions for Finto and Freebase

The structure we made on the technical side has worked out nicely, and we have not run into any problems that we have been unable to solve.

We have also found that the business goals are quite similar, and it has not been a problem to agree on changes in the shared core functions.

There has also been spillover in other areas. The content teams can check out what the other teams are doing and get inspired to do the same in their own site.

Workflow

When there is a request for a new feature the product owner of svenska.yle.fi checks with the product owner at yle.fi/aihe (or vice versa) if they also are interested. If they are we will make it for both SYND and FYND (YDD wide). Depending on the type of issue and how important it is for the sites we will negotiate about which team builds it. Maintenance issues have been shared 50/50.

If it is not a shared goal it will be made for the site that requested it – or it might not get made at all. This is a good checking point, if the feature is not of interest in another site that has almost the same functionality it might not be such a crucial feature after all.

We have a shared issue backlog, but we separate the issues as for both SYND and FYND, or only one of them.

In one month we will celebrate two years with SYND. More about that later.

Panda.js

logo2_200x200

I started to work at Yle over a year ago as a full-time HTML5 game developer. With prior experience in HTML5 game development I chose to start developing with the Impact Game Engine since it had the features that matched the project goals at the time.

I soon realised that Impact lacked in features, it fell short on features like mobile support, tweening engine, particle engine, Web Audio, Spine animation, Retina support etc. Since I really liked the architecture of Impact, I started to develop the missing features as a plugins to the engine. At the time when I was building plugins for Impact I discovered a new 2D renderer engine called Pixi.js, that really impressed me with it’s performance on both desktop and mobile. Unlike Impact, Pixi also supported WebGL, which will speed up games even more in the future since it can utilize the graphics processor for rendering. Instantly I found myself implementing the Pixi renderer and utilizing it in my projects.

After a year of developing for Yle BUU with Impact, I noticed that i could turn my Impact plugins and all my knowledge into a whole new game engine, that’s when I started to work on Panda.js engine.

After some discussion I got a green light from Yle to release Panda as an open source project and on the 11th of February, I released the Panda website and source code at GitHub. With the engine, I also released open source Flappy Bird clone called Flying Dog as a technology demo.

Two weeks after the release, Flying Dog has reached over 1.4M gameplays, the Panda website has had 6.600 unique visitors (most from US and Russia), dozens of tweets and 150 stars on GitHub.

Go ahead and thrash your keyboard, test it out and create something mad with it and contribute. I will be updating, bugfixing and continue the development of Panda, but the development will primarily be centered around the needs of the Yle BUU projects.

http://www.pandajs.net

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.

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.

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

Öppen data från Svenska Yle för Pondus-hackathon

Svenska Yle har nu snart i ett år haft sin Drupalsajt i bruk. Mycket arbete återstår ännu, men vi har bl.a. nyhetartiklar och Strömsömaterial från år 2002 publicerat på den nya plattformen, och nya helheter migreras fortlöpande. Inom kort skall bl.a. Webbdoktorn och X3M migreras.

Som vi skrivit en hel del om här på bloggen så strävar vi efter att arbeta för öppenhet och kvalitativ metadata. Även här är arbetet ännu i sin mitt, mycket är också redan gjorts. Bland annat så publicerar vår webbstatistik öppet här på bloggen och vi annoterar vårt material följandes standarder som Pondus och Dublin Core, använder det nationella ontologiska bibliotekets termer och annoterar det i koden med RDFa och mikrodata. Vi skall ännu komplettera dessa metadata med geografisk information och information om aktörer (personer, företag, myndigheter, föreningar, osv.) innan vår annotering känns tillräckligt komplett. Sedan återstår att bygga ett öppet API för att tillhandahålla publiken våra data.

Pondus

Men vi ger nu i samband med Pondus Open Data Hackfest som ordnas tisdagen den 5.3.2013 av Pondus-konsortiet en förhandstitt på det data vi har att erbjuda. All data finns ju redan tillgänglig via källkoden till våra webbsidor, men vi har nu för hacket byggt ett hjälpmedel för att komma åt det, i väntan på en egentligt API.

Vår datajournalist och -analytiker nummer ett Jarno byggde i python med mechanize ett script som går igenom de data vi har tillgängligt på våra webbsidor. Innehållet är ett två månaders smakprov (.csv, 30Mb) från början av 2013, och innehåller utan särskilda avgränsningar data av det artikelmaterial vi har publicerat på vår Drupalplattform.

Närmare specifikationer finns publicerade i Pondus wiki. Det är frågan om rådata med en stor del av ursprungskoden bevarad. Vi valde att göra på detta sätt istället för att formatera dessa data så att deltagare i hacket fritt kan använda sig av materialet enligt de användningar de kan tänkas hitta på.

Dessa data inkluderar ponduskategorier (inkl URI), KOKO-termer (inkl URI), licens, datatyp, språk, titel, textinnehåll, författarinformation, bildinformation och kommentarinformation. I wikin hittar man också ”skrapningsreceptet” som man kan koppla t.ex. till vilket som helst av våra RSS-flöden för att utvinna mer data för specifika applikationer.

Detta är ett blygsamt första steg, men vi är ändå väldigt entusiastiska och det skall bli spännande att se hur vårt material utnyttjas i hacket. Det är det som är en av de finaste sakerna med öppen data. Man släpper ut den i världen, och vet aldrig vad den växer sig till, och vad den kommer att ge tillbaka. Det är ett fint potential som sluten data aldrig kommer att ha, och det är något vi gärna vill fortsätta att erbjuda vår publik.

PS. Hacket är öppet för vem som helst att delta i, och det finns flera andra intressanta datasamlingar att använda sig av. Häng med, och ta chansen att vinna 2000€. Mera info om tillställningen och data finns här.

Expertinformationens dilemma i det öppna informationssamhället

Christine de Pisan, L'Epistre d'Othea
Christine de Pisan, L’Epistre d’Othea.
Prudence, Wisdom and Knowledge

Jag hade det stora nöjet att delta i Helsingfors universitets alumniförenings expertpanel och diskutera hur öppen data påverkar forskningen och journalistiken. Med i panelen var rektor Thomas Wilhelmsson, professor Henrik Meinander, kommunikationskonsult Carl-Gustav Lindén samt undertecknad, ordet leddes av Jessica Parland-von Essen. Diskussionen blev intressant och påvisade hur det verkligen finns gemensamma utmaningar för den akademiska och journalistika verksamheten, något som också Harvardprofessorn Clayton Christensen skrivit om nyligen.

Diskussionens kretsade kring öppen data, fri tillgänglighet (open access som HU förtjänstfullt engagerat sig i), expertrollen, tolkningsföreträdet och framför allt utmaningen i att i sin verksamhet nå ut till publiken.

Upphovsrätter

I öppnandet av data och information är det oftast upphovsrätterna som ställer till med problem. Få forskare publicerar själv sina material under CC-licens eller motsvarande öppna licenser. Och då texter ges ut via förlag eller tidskrifter överförs ofta upphovsrätter till dem. Vilket kan få den märkliga konsekvensen då universitetens bibliotek köper in dyra tidsskrifter som innehåller forskning som utförts på universitetet och getts helt avgiftsfritt till tidskrifterna. Vilket i sin tur förhindrar fri vidare spridning av ursprungstexten, som Kristina Weimer förtjänstfullt påpekade i sin publikkommentar efter diskussionen.


(Tack för tipset om videon som jag plockade härifrån, mer om licenser också på Esstter här. Kolla också denna undersökning (pdf) ifall avigsidorna av CC-NC intresserar)

På motsvarande vis är upphovsrätterna ett stort hinder för Yle att sprida särskilt tv- och radioinnehåll. Detta gäller såväl ambitionerna att öppna arkiven som att distribuera de nya programmen friare och tillhandahålla dem längre online. Läs mer om de juridiska problemen kring detta här och om Yles förfrågan om ändring till framtidsutskottet här (båda på finska).

Aningen oroväckande är också att trots goda intentioner både i Finland från myndighetshåll (pdf) och från medborgarhåll och inom EU, lyckas lobbyorganisationer häpnadsväckande direkt påverka lagstiftningen.

Mångfald

Öppen information och öppna kanaler för också med sig avigsidor. I första hand ett överflöd av information, och ett tilltagande mått brus och också ren desinformation. (Obs att årets Media Information #m13i den 15.10.2013 kommer att handla om detta.) Den väsentliga skillnaden från tidigare är att alla kan publicera sig idag. Inte minst Wikipedia har blivit en kunskapens högborg som delvis konkurrerar med universiteten och biblioteken. Och sk. MOOC:s erbjuder gratis utbildning online. På motsvarande vis har sociala medier, bloggar och medborgarjournalistik diversifierat informationsförmedlingen i det som traditionellt varit journalistikens områden.

Här kan kuratering vara en metod för att öppet och genomskinligt både inom forskning som journalistik visa på processen och informationsflödet i respektive verksamhet. För det finns en väsentlig skillnad här gentemot största delen av det massiva informationsflödet och åsiktsyttringarna online. Både journalistiken och forskningen behandlar information enligt vedertagen praxis och utför ett avsevärt arbete i att validera och bearbeta informationen.

Förändrade konsumtionsvanor och utmaningar

Det förändrade informationslandskapet för med sig tre stora utmaningar som flera branscher delar idag:

  1. Att öppet göra kvalitativa innehåll
  2. Att nå ut till publiken
  3. Att fylla en funktion för publiken

Distributionsproblemet ligger i att nå ut till en publik som inte längre läser tidningar, ser på tv-kanaler, lyssnar på radiokanaler eller anmäler sig till kurser vid universitet. De föredrar att aggregera sina innehåll, läsa, titta och lyssna på flera källor ur ett globalt urval. Och gör allt detta via flera olika tekniska och uppkopplade plattformer. Och fattar beslut om vilka innehåll de konsumerar primärt enligt för dem tillförliga rekommendationer. Dessa rekommendationskällor har lite gemensamt med de traditionella auktoriteter som mediehus och universitet som har haft tolkningsföreträdet då det gäller rekommendation av lämpligt informationsinnehåll.

Det gäller alltså att se till att innehållen och informationen finns tillgänglig på de plattformer publiken använder. Och att se till att de fyller en uppgift i de konsumtionsvanor publiken tagit till sig. För medieinnehållens del handlar t.ex. detta uppgiftsfyllande att under den tid publiken äter sitt morgonmål ge en bild av vad som står på agendan idag (evenemang, snackisar), vad som skett som man bör känna till (nyheter), eller t.ex. att fylla tiden medan man åker allmänna transportmedel eller väntar hos tandläkaren. Då konkurerar medieinnehållen med musik, spel, kommunikation på sociala medier, osv, som finns tillgängliga via smarttelefoner. Det är i denna globala konkurens som medierna måste kunna hävda sig och fortfarande fylla relevanta uppgifter och funktioner för sin publik. Dito universiteten.

 

EDIT: Här kan ni se diskussionen.

5 days to first pilot-webcast

Its now 5 days to go to our first week. On tuesday we will try to make the first pilot (which will not be webcasted)

I have realized that  I will have about half of the the stuff I need. My biggest fear is that my cameras should arrrive to Finland on monday so I would have 1 night to get them working. In a way its nice to know that the lights and the light-rigging wont be ready so its I can work with secondary solutions. On the solutions I have made the following as mixer I will use Sony MCS-8M and the cameras will be Panasonic AG-AF101 and HE160-robotcameras.

The fun part is that the parts that I have seems to be working quite well so I’m semi-confident that most of the things will run smoothly.

I attach new pictures from the studiofloor and the controlroom

markus

x3m_2_1x3m_2_2x3m_2_3x3m_2_4x3m_2_5