Effektivt arbete med grafik, Buu-klubbens webbjulkalender 2014

Buu-klubbens webbjulkalender är en årligen återkommande storsatsning hos svenska.yle.fi. Utmaningar uppstår på bred front, från manus till tekniska detaljer, från kodning till grafiskt finlir. Ett gott slutresultat kräver sakkunnighet på flere områden, och står och faller på gott samarbete inom teamet.

Från BUU-klubbens julkalender 2014

Det som tidigare ofta skapat huvudbry för mig som grafiker är den stora variationen i materialet som måste bearbetas. Spelen har ofta varit ensamstående helheter, och att få ihop 24st sådana till ett grafiskt fungerande paket är inte alltid det lättaste. Ofta har också en större grupp människor jobbat med enbart grafiken vilket ger ännu fler utmaningar vad gäller enhetlig stil och arbetsflöde. Miljöer, figurer och allehanda andra objekt har anpassats mer eller mindre framgångsrikt.

2014 jobbade vi lite annorlunda med grafiken än tidigare. Alla 24 spel var uppbyggda kring 5 olika miljöer: en källare, ett badrum, en trappa, ett vardagsrum och en vind. Grafiken levererades till mig som “paket”. Ett paket bestod av miljön och respektive objekt. Spelfigurerna, Rune och Holly, var också ritade av samma person.

En miljö fullproppad med diverse prylar såg till en början aningen avskräckande ut, men så fort arbetsflödet hittade sin form var det klart som korvspad. Då vi tidigare tampats med att få ihop visuellt kloka helheter ur material lite härifrån och därfrån, ritade av underskriven och ibland flere andra grafiker, hade jag nu tillgång till enhetliga helheter, genomgående i alla 24 spel. Då en och samma grafiker producerat varenda lilla detalj, är en av de största fördelarna den genomgående enhetliga känslan av att man är i samma “värld”.

Jag kunde nu koncentrera mig på att framställa all grafik till format som lämpar sig till spelproduktion. Det gick de facto väldigt fort att “plocka ut” alla bitar i sådan form som kodarna behövde för att sammanställa spelen jämfört med tidigare år. Dessutom kunde de grafiska elementen grupperas rätt tydligt för dem som jobbade med kodningen av spelen.

 

Analysering av webbjulkalendern 2014 som en komplett helhet får någon klokare människa sköta. Jag anser ändå att 2014 var året då vi gjorde framsteg åtminstone vad gäller arbetsflödet kring det grafiska. Att vi lyckades med detta anser jag bero på följande saker:
1) Grundlig planering av spelkoncept 2) Väl uttänkt arbetsflöde 3) Fungerande samarbete inom teamet.

Hur än tekniska lösningar o.dyl. ser ut i framtiden har vi åter igen många lärdomar att ta med oss till kommande projekt.

Mediekonvergensens nästa fas – att idka skogsvård i aska

Förra fredagen (23.1.2015) hörde jag bl.a. Emanuel Karlsten tala på Mediespråkseminariet. Han hade talat där senast tre år sedan, och inledde med att säga att han egentligen kunde ha valt att dra precis samma presentation som då i repris. För enligt Emanuel står hela mediebranschen stilla och ställer sig om igen samma fråga om vad som ska ske till näst. För att komma loss ur denna “catch 22” så tycker han att mediebranschen bör brinna, och likt efter en skogsbrand återuppstå ur askan.

Samtidigt så brukar det ju vara så att man inte alltid märker då ens egna barn växer, utveckling som sker rakt framför ens egna ögon går ibland en obemärkt förbi. Då jag ser på det blogginlägg som jag skrev till bloggen för tre år sedan med titeln “Att tänka webb” så känner jag nog igen den stagnation som Emanuel beskriver. Samma frågor och ambitioner är ännu aktuella. Men samtidigt har oerhört mycket utveckling skett. På mediebranschen i stort har utvecklingen varit snabb. Eller snarare har omvärlden och vår publiks mediekonsumtionsmönster förändrat radikalt.

De här yttre förändringarna har skett snabbare än vad traditionella mediehus klarar av att förändra sig, utan den skogsbrand inom organisationerna som Karlsten efterlyser. Om de strategier som kan krävas för att klara av anpassningen skrev jag nyligen om i Nya Argus.

Men samtidigt har alltså även stor förändring skett i verksamheterna. Hos oss på Svenska Yle har webben på riktigt (läs i budgeter och personalresursallokationer) fått prioritet. Olika delar av verksamheten är i lite olika lägen av utvecklingen, men det rör på sig. På sätt och vis är faktiskt läget lite liknande som efter en skogsbrand. Det finns nu ny mark och allehanda skott skjuter upp. Frågan är om man vill låta alla blommor blomma, odla fritt för var och en. Eller om man vill ha ett effektivt skogsbruk som låter höga furor snabbt resa sig i ordnade rader? Kanske idealet är en park, med mångfald under ordnade former. Men dit är det nog en bit väg ännu.

Kanske idealet är en park, med mångfald under ordnade former

Det jobbas mycket med att reda ut i utgivningen och göra scheman för webb. Det kan synas märkligt att schemalägga webbutgivning, är det inte just friheten från etermediernas tablåer vi vunnit i.o.m. digitaliseringen? Ja, i sig nog. Men om vi publicerar allt vi gör genast då det blir färdigt så får publiken betydligt svårare att hitta våra innehåll. Innehållen blir i regel klara under kontorstid, medan, delvis beroende på genre, i regel konsumeras andra tider. Och följetongen är betydligt lättare att följa (därav namnet) än ett stort block utgiven i en hop.

Men att omorgansiera verksamheten utan att ta det hela några steg vidare är också en reell risk. Det ger en illusion av förnyelse, då man bygger upp något gammalt på nytt. Emanuel Karlsten beskrev olika metoder att anpassa sig till det nya fältet; att bygga enligt nätets logik, anställa spridare av innehåll och communityredaktörer, använda teknik för att gynna innehåll. Allt kändes väldigt bekant från teknologi- och startupföretagsvärlden. Det är också många som funderat kring ifall mediehusen håller på förvandlas till teknologiföretag? Ja, är min mening. Vi gynnas av principerna för agil utveckling både inom utvecklingen av våra plattformer OCH våra innehåll. Följande tweet summerar det bäst:

 

Googles Eric Schmidt gjorde här i dagarna ett intressant utspel och sade att “internet kommer att försvinna”. Han syftade på att i takt med att allting blir uppkopplat så slutar vi lägga märke till nätet i sig, det “försvinner” och blir en integrerad del av vår verklighet. Jag tror att medier med fördel kan tänka lika om sina egna alster. De journalistiska innehållen är i en process där de håller på att omvandlas från att vara separata ritualer – morgontidningen, kvällsnyheterna, lördagsfilmen, söndags-Strömsö – och bli integrerade delar av vår vardag. De journalistiska innehållen blir som repliker i en daglig kommunikation via applikationer och onlinetjänster.

De journalistiska innehållen blir som repliker i en daglig kommunikation

Då bör man också fundera på funktionerna och formaten som man tidigare tagit för givna, håller t.ex. nyheterna på att bli en anakronism? Är det kanske bara bra ifall robotar börjar sköta en del av vår journalistik. Bör den journalistiska agendan sättas av big data? (Se tweeten nedan, allt detta diskuterades under #mediesprak.)

Så bör medierna brinna, brinner vi redan? Det kanske sist och slutligen kvittar vilka analogier som fungerar bäst som väckarklockor. För väckarklockor är nog något som krävs för att vi ska kunna blicka vidare och ta de steg som behövs för att överleva. I ett historiskt perspektiv så är faktiskt mediernas tillbakagång bara en liten svacka. Och informationsförmedlinegen- konsumtionen i bredare perspektiv har aldrig mått bättre i mänsklighetens historia än på internet. Så det finns alla möjligheter att gå vidare med vår verksamhet.

 

Visualising three years of development

About two and a half years ago I made a visualisation of the work on SYND so far. Much has happened since then, and with the three-year-anniversary of the first commits to the SYND repos rapidly approaching, I felt it was time to revisit gource and do another loop through the commit history. Presenting the three-year-mark of YDD development:

Much have changed since the previous visualisation, the biggest of the changes of course the creation of the two sub-branches of the project, SYND and FYND. It’s easy to see how much the project has expanded in scope and complexity since we started, something that would have happened even without the forking of the project.

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.

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

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

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

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

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

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

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

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

Karoliina Korhonen, nätanalytiker

DUI-heatmap Finland 2012

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

Heatmap
Heatmap of DUI-incidents at Helsinki area

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

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

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

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

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

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

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

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

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

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

Geocoding multiple addresses
Geocoding multiple addresses trough yahoo api

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

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

Geocoding one address
Geocoding a single address trough google api

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

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

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

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

The making of a Yle Drupal Distro (YDD)

From the start of the project (Swedish Yle’s New Drupal (SYND)) we had a goal to build it as a distro. What is better than that someone else can use the same code base? 🙂 With YDD we reached the internal distro milestone, an important step if we also some day want to be able to make it a public distro.

During January we spent two weeks making our own code more abstract (for some reason there is always something that gets hard coded), making new features that were wanted for the PoC (Proof of concept) of FYND (Finnish Yle’s New Drupal), setting up a new dev environment and splitting up the install profiles to support YDD, SYND and FYND.

The structure we decided to use is as follows: YDD contains the basic functionality that all sites should have. SYND and FYND each contain their separate modifications. Example; recipes, maktbasen and some Svenska Yle specific styling is found only in SYND. The themes in fynd_themes and synd_themes are subthemes of the theme in yle_themes.

The GIT structure and install profile logic:

FYND

YDD

SYND
fynd_modules
fynd_features
fynd_themes
fynd_profile
yle_modules
yle_features
yle_themes
synd_modules
synd_features
synd_themes
synd_profile

With this structure we are able to use a common core, and if needed add more functionality, translations or styling per site. Issues we ran into include views that were created when the system was in Swedish. It does not work to then switch the system to English before exporting, the view will be in Swedish.

Another issue was that a view that limited content based on a taxonomy was exported with the VID, and not the machine name of the taxonomy. Solved by changing the view so that the machine name was used in the filter.

We also had some displacements of fields and taxonomies. They had been placed in the wrong feature, so they were not available when some features needed by SYND were not enabled in FYND.

Moving theming to the features and modules was also something that we now needed to do. Not all the views that had styling was going to be used in both SYND and FYND.

The RSS feed generated by Views is one open question. It would be good to share them between the install profiles, but settings like Site name and headlines are hard coded in the view.

Being more thorough in with what is placed where and making sure that the language always was English would have made the process even smoother.

One thing we should have done in the early phase is to change the name on the live production install profile. That we tried to do it at the same time as we had moved some of the modules from yle_modules to synd_modules caused problems when migrating the production database.

The process itself turned out to be a good way to also do a review of the code. Even though we have had two external reviews (thanks Bala, @dasphere) it sometimes takes deep knowledge of a site to realize that something has unnecessary overhead. Having to split the site forces you to look at parts of the code that otherwise does not get looked at that often. We ended up merging and/or removing four features/modules.

Working with Jari Lana who does Drupal for Ylex, Oppiminen & co was also a good way to get a fourth review, from someone who also could make improvements directly in the code.

Even if FYND is never launched, the work will not go to waste. SYND has reached a new abstraction level, got new features and improvements. If the need arises, a new site can be up and running in no time.

Currently svenska.yle.fi is running on the new YDD + SYND setup.

Den tidvis vrickade diskussionen kring Flash och HTML5

I mitt tidigare inlägg presenterade jag ytligt hur vi jobbar med att animera material för Buu-klubbens webbsida i Adobe Flash.

För oss på svenska.yle.fi är diskussionen kring Flash och HTML5 nu högaktuell, och konkreta linjedragningar är att vänta inom snar framtid. Diskussionen har ju på bred front pågått en längre tid, och ibland reagerar man på hur generaliserande och flummig den som värst kan vara.

“Flash är ett problem”

Fel! Flash är inte ett problem. Flash är ett verktyg, och ifall man missbrukar det uppstår problem. Försöker man tvätta fönster med en hammare är det troligt att resultated blir ganska dåligt, och i värsta fall går saker och ting sönder.

Det man ser och hör allt för mycket av är attityder och åsikter som helt och hållet saknar grund, och tydligt beror på blind övertygelse. Vissa tar hela diskussionen väldigt personligt, och jag påstår att folk som är redo att kasta den ena eller andra lösningen ut genom fönstret utan desto mer åtanke har definitivt andra (ofta personliga) målsättningar i baktankarna.

Flash har under årens gång sträckt sig till så gott som allting man hittar på webben, på gott och ont. Exempel som alla känner till är animerade banners, spel och även hela webbsidor byggda uteslutande i Flash. Det är uppenbart att Flash inte är det klokaste alternativet till precis allt man kan göra med det, och därför ser jag det som mer än välkommet att det nu existerar utmanare för de plattformer och för de lösningar där Flash helt enkelt inte är det bästa möjliga.

Det man inte kommer ifrån är att Flash är ett utmärkt verktyg för produktion av spel, och i nuläge är det totalt omöjligt att rakt av ersätta det med HTML5.

HTML5

Vad gäller renodlad webbdesign är HTML5 perfekt. Det erbjuder obegränsade verktyg för designers att producera snygga dynamiska lösningar som har alla förutsättningar att fungera på varje plattform så fort understöd existerar. Det här är också ett exempel på ett delområde där man “missbrukat” Flash allt för länge. Missbruk av Flash har lyckligt vis (med tanke på användbarhet) minskat redan innan diskussionen ordentligt hettade till.
Att man nu kan ersätta Flash med HTML5 då man producerar t.ex. banners, datavisualiseringar eller enbart utveckla snyggare webbsidor är en strålande sak. Jag har personligen höga förväntningar för vad HTML5 och CSS3 i framtiden kan medföra.

Buu

Att införa HTML5 i arbetsproceserna för webbdesign är alltså ingen dålig sak alls. Farhågorna väcks då man börjar höra kommentarer riktade emot spelproduktionen. Att producera spel i HTML5, även lika avancerade som i Flash är ingalunda omöjligt. Exempel finns det gott om. Däremot handlar det om arbetsprocesser och resurser. En grundlig kartläggning av vad som krävs för att åstadkomma det vi nu gör vore på sin plats, förutsatt att nuvarande nivå är nånting vi vill bevara. Faktum är att ingen vet vad det i praktiken skulle kräva att exempelvis producera en motsvarande julkalender som vi erbjöd i år, genomförd i HTML5. Jag kan här och nu berätta att det i nuläget aldrig skulle lyckas pga. bristfälliga resurser och otillräckliga verktyg.
Alternativet skulle då vara att gå i en helt ny riktning, där det säkert finns möjligheter, men det skulle i så fall att ske på en bekostnad av mycket av det som nu är Buu-klubbens webbsida.
Det är upp till dem som fattar besluten att avgöra vilka linjer som skall dras för innehållet. Ett mardrömsscenario är en situation där man slänger in nya arbetsmetoder och processer och förväntar sig samma resultat som tidigare, trots solklara brister i kapacitet.

Realism och is i hatten

Lyckligt vis är det knappast realism att förkasta det ena eller det andra alternativet helt och hållet, utan att utnyttja alla fördelar så gott det går. Strävan till att bemöta användarna på alla tänkbara plattformer utan kompromisser i innehållet torde vara en självklarhet, och med tanke på den legacy vi har kommer Flash att vara en del av vår vardag ännu i långa tider. Vår uppgift är att presentera innehållet så att möjligast många kan utnyttja det. Samtidigt skall vi se till att experimentera med nya möjligheter och se till att också HTML5 med alla sina fördelar blir en del av det vi gör.

2013 kommer att bli väldigt intressant, inte minst vad gäller spelen på Buu-klubbens webbsida!

///Johan

Morr, den lever!

I skrivande stund närmar vi oss situationen då Buu-klubbens julkalender börjar vara packad och klar för 2012 (jo, jobbet fortsätter även om kalendern är publicerad). Kalendern på webben utsätts för höga förväntningar varje år även om resurseringen kan variera. Det handlar ju trots allt om en av de mest populära tjänsterna hos svenska.yle.fi.

Projektet i sin helhet består av otaliga delar, och man kunde säket skriva tiotals blogginlägg (eller noveller) ur alla möjliga synvinklar. Jag tänkte dock i korthet presentera den arbetsprocess som ligger bakom de animationer och grafik som utgör webbkalendern med några enkla exempel.

Kalendern är, liksom Buu-sajten överlag väldigt starkt präglad av en viss grafisk stil. Den grafiska stilen i sin tur är en kombination av “buu-världen” och det man ser i papperskalendern.

Papperskalendern beställer vi (förutom konceptplaneringen som sköts av oss) av underleverantörer och den är ett stort projekt för sig, men också en väldigt viktig del av det som är kalendern på webben. Den lägger definitivt en av grunstenarna för webbkalenderns utseende gällande såväl figurer som omgivning.

Vi har även i år samarbetat med Johanna Sjöström som är den duktiga grafikern bakom en stor del av grafiken på buu.yle.fi.

Vektorgrafik

Eftersom webbkalendern är byggd i Flash är vektorgrafik ett måste. Då papperskalendern illustreras fullständigt som vektor ger detta oss många möjligheter att utnyttja den månsidigt också på webben, och eliminera massor av onödigt arbete.

Symbiosen mellan Adobe Illustrator och Flash är oslagbar i denna process. I all sin enkelhet kan det handla om snabba och smidiga överföringar av objekt från det ena programmet till det andra. Editerings- och exporteringsmöjligheterna i vardera program ger oss alla tänkbara verktyg att jobba med. Figurer, omgivning och element av alla tänkbara slag kan flyttas, editeras, modifieras och framför allt överföras till Flash för att animeras precis så som vi vill, och känslan av att det handlar om en och samma helhet kvarstår.

Som exempel kan vi nämna spefiguren Morr. Morr, som är en av huvudfilurerna i julkalendern 2012, ritas i Adobe Illustrator av grafikern utgående från samma figur i TV-produktionen. AI-filen godkänns och skickas sedan till oss. Det är därefter hur enkelt som helst för mig att plocka spelfiguren in i Flash och väcka den till liv.

Spelfigurer i Adobe Illustrator.
Spelfigurerna i Adobe Illustrator.

Flash

Buu-klubbens webbsida är byggd helt och hållet i Flash. Vad betyder det då? Det betyder vektorgrafik, ActionScript, timeline-animationer, tweens och hela faderullan. Ja, egentligen är Adobe Flash en produkt som man kan producera lite vad som helst med, vad gäller grafik och animering.

Flash ger i animeringsväg 2 möjligheter, som absolut inte utesluter varann. Man kan animera med hjälp av ActionScript, eller använda sig av timeline-animering. Julkalendern utnyttjar båda. Med ActionScript byggs också de egentliga spelmotorerna som ligger bakom allting. Personligen fattar jag inte ett dyft av kod, så det är timeline hela vägen för mig.

För att fortsätta med exemplet Morr, utnyttjar jag bland annat olika tweens och bone-tool för att rätt snabbt och enkelt åstadkomma en figur som springer, hoppar, blinkar med ögonen, vickar på tårna, viftar med handen och med svansen. Allt detta utan att behöva göra några märkbara ingrepp på den grafik som Johanna försett oss med.

Hoppande Morr animeras i Adobe Flash.
Morr animeras i Adobe Flash.

ActionScript sköter som sagt också en stor del av animationerna. Som exempel kan nämnas hinderbanorna i årets kalender. De byggdes så att jag ritade alla grafiska element som behövs i Flash, delade upp dem i olika scener och skickade sedan iväg .fla-filen till vår kodare som kodade ihop allting till fungerande spel. Med ActionScript definieras de olika grafiska elementens beteenden.

Från skiss till färdig hinderbana.
Från skiss till färdig hinderbana.

Detta var alltså ett ganska kort och koncist exempel på hur vi jobbar när vi skapar delar av Buu-klubbens julkalender. Hoppas ni gillar kalendern både i pappers- och webbformat!

Funderingar kring framtiden med eller utan Flash i ett senare inlägg.
God Jul!

///Johan, grafiker på svenska.yle.fi