HTML5 annonser – begrensninger og muligheter

De fleste er enige at overgangen fra Flash til HTML5 har vært en god ting – vi har nå mer tilgjengelige nettsider som også gir gode brukeropplevelser på mobil. Men hvorfor har denne overgangen frem til nå uteblitt for nettannonser utenfor mobilmarkedet? 

(English readers; please refer to my previous post or read my presentation notes.)

Denne artikkelen er et forsøk på å oppsummere mitt foredrag om HTML5 annonser på Gulltaggen 2015. Jeg har også uthevet en del viktige ord for de som liker å skumme igjennom. Artikkelen er ment som en innføring fra virkeligheten til et produksjonsbyrå målrettet mot alle som jobber med display-annonsering på nett.

Tingenes behagelige tilstand

“If it works, don’t fix it” er et mantra som alltid er like aktuelt i digitale løsninger, og nettannonser er intet unntak. Flash er et verktøy som har vært som skreddersydd for effektivt å skape animerte nettannonser for animatører, designere og utviklere. Teknologien har også muliggjort at én enkelt fil fungerer likt på tvers av alle nettlesere, operativsystemer, nettsider og annonsesystemer. Med HTML5 annonser kan man dessverre ikke ta noe av dette for gitt lengre.

Animering og justering er kjapt og lett med Flash.

I Flash har man et grensesnitt hvor man kjapt kan animere elementer på en tidslinje. Hvis f.eks. kunde vil ha katten rotert og tennisballen mindre, så tar det kun et par sekunder.

Hvis Flash fungerer så bra, hvorfor må vi gå videre?

I dag produserer Apt ca. 60% av annonsene i Flash og resten med HTML5 hvor det i hovedsak er materiellspesifikasjonen fra mediebyrå som bestemmer hvilket teknologi som skal benyttes. Som regel blir da Flash målrettet mot desktop og HTML5 for mobil. Dette er en oppskrift som ikke kan fortsette av flere grunner:

  • Mobil spiller som kjent ikke Flash og vi får da ikke gjenbrukt kode i de tilfellene det må produseres samme budskap for begge plattformer.
  • Har du en kunde som sitter på Mac og bruker Firefox eller Safari, så har du kanskje hørt at denne kombinasjonen i mange tilfeller blokkerer Flash. Mac har også en strømsparingsfunksjon som i Safari også kan stoppe Flash fra å kjøre. Utfordringene er i begge disse tilfeller at nettleseren sier til annonsesystemet den faktisk kan spille av Flash, så fallback vises heller ikke. Resultatet er i stedet at annonsøren betaler for at bruker blir vist en ganske så skummel advarsel.
  • Flash er et lukket filformat som er eid av Adobe, det er ikke en god ting at ett selskap skal bestemme hvordan innhold på nettet skal utvikle seg.
  • Det er bare jaggu meg på tide! Det er lenge siden vi sluttet å bruke Flash i nettsider og dette er noe vi må igjennom før eller siden. De aller fleste systemer og nettsider er nå klare for å ta i mot HTML5 annonser, så hvorfor ikke starte i dag?
Flash blokkert

Firefox (øverst) og Safari (nede) på Mac blokkerer Flash hvis den ikke er oppdatert til siste versjon, som er tilfellet for mange brukere, inkludert undertegnede. De fleste brukere opplever at oppdatering av Flash i seg selv er et irritasjonsmoment.

Ny teknologi gir nye utfordringer

Med all ny teknologi er det noen nye utfordringer, har du f.eks. noen gang hjulpet foreldre med sin nye smartmobil? F.eks. slått av ordlisten på tastaturet? Bruk av HTML5 til annonser har også noen nye utfordringer som man bør kjenne til.

  • Forskjellige standarder fra aktører som AdForm, Doubleclick, INMA, Widespace osv. opererer med forskjellige spesifikasjoner på hvordan HTML5-annonser skal kodes. I tillegg kan nettstedene operere med egne krav utover dette. Resultatet er at vi i mange tilfeller må versjonere annonser ikke bare for størrelses-formater, men også for kombinasjonene av spesifikasjoner nevnt over.
  • For å kunne utforme kreative løsninger, og samtidig kunne lage annonser som fungerer på standardene til alle annonsenettverk er vi dessverre avhengig av å håndkode (programmere) HTML5 annonser. Dette er en veldig tidkrevende manuell prosess sammenliknet med å animere i Flash som også gjør justeringer krevende.
  • Animatører og designere som tidligere har kunne brukt Flash må nå i mange tilfeller lære seg koding av HTML-annonser, da animasjonsverktøy for HTML5 enten ikke er gode nok ennå, eller at de er låst til et annonsenettverk.
  • Mange av våre kunder ønsker å bruke sine profilfonter for å opprettholde sin visuelle identitet. Flash håndterte dette på en genial måte og komprimerte kun informasjon for de bokstavene som ble brukt i annonsen. I HTML kan en profilfont ta mesteparten av kb-grensen (filstørrelse) alene, som kan føre til at vi i verste fall må lagre tekst som bilder. I noen tilfeller får vi dog lov til å laste fontene på etterskudd, men da kan brukeren oppleve et “blink” hvor annonsen plutselig endrer utseende.
  • Ofte komponerer vi animasjoner, miljø og landskap ved å bruke flere lag bilder som er delvis gjennomsiktige. Disse bildene bruker png-filformatet som komprimerte bedre i Flash. Dette fører til at vi i flere tilfeller må nøye oss med visuelt enklere løsninger for å holde filstørrelsen nede.
  • Annonsene kan se forskjellig ut i forskjellige nettlesere, dette gjelder særlig hvordan fonter vises. Annonsene må testes i mange forskjellige nettlesere, og evt. mobile enheter. Man må også akseptere at Internet Explorer 9 ikke støtter (CSS3) animasjoner slik at man mister de fine overgangene mellom budskapene.
Håndkoding av Pusefinn annonse

HTML5 annonser må håndkodes som er en tidkrevende og manuell prosess. Alle verdier for formatering, posisjonering, størrelser og animasjoner må beregnes og tastes inn. Dette fører også til at justeringer blir tilsvarende krevende, og man bør helst ha budskapene spikret på skissestadiet.

Kommunikasjon mellom alle involverte parter og prosjektledelse også tar mye mer tid med mer korrespondanse rundt formater, spesifikasjoner, samt flere returer og tekniske justeringer. Dette tar selvfølgelig mer tid for alle parter.

Vi får ofte materiellspesifikasjoner sent, med veldig kort produksjonstid så er det faktisk problematisk å nå fristene når HTML5 annonser skal produseres. Vi er da avhengig av å kunne starte opp produksjon tidligere enn før.

Ikke gå ennå, det er også mange fordeler!

På dette tidspunkt virker det nok som om jeg er en gammel bitter Flash-utvikler som vil tilbake til “the golden days”, det er heldigvis ikke sant. Det er en del store utfordringer, men de vil bli betraktelig mindre ettersom teknikken utvikler seg.

Det er også mange gode fordeler vi kan dra nytte av med en gang

  • Som på nettsider så støtter HTML5 innhold som er responsivt, altså som fungerer på forskjellige skjermstørrelser. Den samme teknikken kan vi bruke i annonser, og lage annonser som tilpasser seg den plassen som er avsatt. Dette vil på sikt kunne redusere produksjonstid brukt til å versjonere til de forskjellige formatene.
  • Ingen ønsker å diskriminere med vilje, og det finnes mange der ute med funksjonsnedsettelser som vil kjøpe produktene dine. Fordelen med HTML5 er at det er mye lettere å skape innhold som møter kravene til universell utforming.
  • Det er mye lettere å lage annonser med dynamisk innhold i HTML5. F.eks. kan man skreddersy annonsen til å tilpasse seg hvor brukeren er, hva slags vær det er der eller hvor mange som har influensa i området. Dagbladet har eksperimentert en del med dette, og bla.a. oppdaget at annonser som inneholder stedsnavn fra små steder fungerer særdeles bra. Fordelen er da at det er annonsenettverket som henter ut posisjonen via geolokasjon, uten at man trenger å spørre brukeren.
  • HTML5 er et åpent, demokratisk format. Det vil si at kildekoden til en annonse kan leses, og endres av alle. Det muliggjør at et for eksempel et annonsenettverk, eller ansatte i et medie kan endre koden til en annonse for at det skal fungere i deres system.
  • I HTML5 annonser kan vi også bruke en ny teknologi for 3D-grafikk som heter WebGL. Enkelt forklart vil det si at vi i nettleseren kan gjøre det en Playstation 2 kan. Om det så er spill eller applikasjoner hvor man kan manipulere 3D objekter. 3D grafikk inneholder dog mye informasjon, så slik funksjonalitet vil nok mest være aktuelt å aktivere med et klikk i en annonse.
  • INMA er på vei til å jobbe ut en spesifikasjon hvor målet er at norske medie-aktører skal følge. Det vil lette jobben vår som produksjonsbyrå ved at det vil bli færre standarder å versjonere til.
Responsiv annonse

HTML5 gjør det mulig å lage responsive annonser som tilpasser seg alle formater, dette kan spare produksjonstid som vanligvis brukes på versjonering.

Hva må vi alle gjøre?

For at overgangen til HTML5 skal bli levelig for alle er det viktig at vi alle gjør en ekstra innsats for å minimere frustrasjon, feil og tidsforbruk. Vær ekstra tydelig i din kommunikasjon, og ikke anta at den andre parten vet hva de skal lage uten detaljert informasjon. Hold deg kontinuerlig oppdatert på endringene i medier, spesifikasjoner og annonse-systemer.

For at produksjonsbyrå skal kunne ha en sjans til å lage annonser som blir godkjent uten feil foreslår vi at medieplaner/materiellspesifikasjoner oppgraderes. Vi ønsker da at teknisk kontakt hos medie, annonsesystem og mediebyrå er synlig med mobil og e-post. I tillegg ønsker vi at hver linje er beskrevet med:

  • Størrelse/format, f.eks. 100% x 250px
  • Maksimal filstørrelse
  • Link til oppdatert detaljert spesifikasjon med synlig versjonsnummer. Da er det nemlig lett å oppdage endringer.
  • Link til mal på en tom eller enkel annonse som vi kan ta som utgangspunkt. Også denne bør ha versjonsnummer.

matspecDette hadde eliminert gjettingen og antakelsene i hele prosessen som skaper mye frustrasjon med bla.a. retur av annonser fordi de er skrevet med en annen spec.

Midlertidig konklusjon

Vi må da i denne overgangen forstå at ny teknologi ikke alltid gjør enklere og billigere. I tilfellet overgangen til HTML5-annonser, så blir det faktisk dyrere og vil ta lengre tid. Samtidig må vi nok i en overgangsfase må akseptere at annonsene blir enklere utformet for å kunne nå tidsfrister og produksjonsbudsjett.

Det som også er veldig viktig at vi nå alle som jobber med annonser lærer seg sitt nye produkt som HTML5 annonser faktisk er. For å kunne forstå mer produktet de selger, anbefaler jeg at alle som håndterer annonser tar et grunnleggende HTML kurs på nett. Da er man bedre rustet til å håndtere de nye utfordringene som stadig dukker opp, og vet bedre hvem som evt. må håndtere det videre.

Har du selv erfaringer med produksjon av HTML5 annonser, eller har betraktninger relatert til dette? Send meg gjerne en e-post til paal@apt.no eller pling meg på Twitter. Jeg er også åpen for forespørsler om å holde foredraget fra Gulltaggen på nytt hvis man vil ha en muntlig variant.

Pål Smitt-Amundsen er innovasjonsansvarlig og utvikler i APT. 

My talk about HTML5 ads at Gulltaggen 2015

Pål - 1
Just a short post thanking Gulltaggen and ABC Startsiden for having me as a conference speaker yesterday at this inspiring conference. Giving a conference talk on a technical subject in a 2nd language is always a good challenge, resulting in a much welcome experience.

I was also happy to get many good questions and conversations on the topic of the transition from Flash to HTML5 ads, with many requesting a link to my slide deck. As soon as I get some time I will sum the whole presentation up in an article, but in the meantime I’ve put out the links to my Keynote file:

Thanks again to Gulltaggen and Annette Isachsen at ABC Startsiden for having me as a conference speaker!

PS. One of my main motivations for doing this talk is to ease this transition into HTML5 ads, which is currently causing a bit of headache for many. So if you missed my talk and want some insight on the subject – I am open to requests for doing this presentation again.

Fishes flocking fun with JavaScript

This spring I was working on a “ocean themed” site taking the user on a journey to the great depths of the North Sea. And of course, in every ocean there needs to be
fish happily swimming in flocks. So I started doing some research into flocking, and with some experience from creating particle systems, the first prototype was done in in a day.

See the Pen Fish flocking simulation by Pål Smitt-Amundsen (@gadgetgnome) on CodePen.


The basics of flocking is that one fish tries to find a buddy to follow, one that it can see in a sector relative to it’s swimming direction. Once a buddy is found, it tries to follow as best it can, limited by its max speed among other properties.

To see who a fish is following, hold the shift-button on your keyboard. Red lines will point out the leader, also green lines will display the “negative force field” that the mouse cursor is to the fishes. The are just really scared of the cursor, trying to avoid it the best they can.

Feel free to peek into the code using the link below, there are some comments that should explain the basics. I wrote the code from scratch with a JS “class” for a Fish, making it easy to instantiate a thousand of them with the “new” operator. The particle system is drawn on a canvas, drawing the fish from a bitmap with correct rotation and position from its “particle” properties.

Go ahead, visit CodePen: http://codepen.io/gadgetgnome/pen/Apnkv

Automatic brakes on bumper cars!

Late summer I was lucky enough to participate in a build project we did for our client Volkswagen. The idea was illustrating their automatic braking system by creating a similar system for bumper cars, filming people driving them unbeknownst of our modification. Take a look at the result here:

And if you are interested in how created this, check out the “behind the scenes” video with Knut explaining the basics of the setup.

The brake system was powered by pneumatics, so several large dive tanks was needed to keep the smaller bottles refilled the whole recording day. This picture was taken after, with the brake system parts all back in boxes after restoring the bumper cars to their normal brake-less setup.
Dive tanks and parts

The parts for each cars setup, hidden under the seat for a surprising effect (from L to R):

  • Small “pony bottle” diving tank
  • Pressure regulators
  • Blue Festo air tubes (awesomeness with quick-release!)
  • Computer box with battery, Raspberry PI and Arduino interfacing the ultrasonic sensor-array and sending the the data to the server via the tailor made SW.
  • Massive relay to withstand the big current drawn by the car
  • Festo solenoid electromagnetic air valve to feed air into the brake valves.

Car brake parts

The feeling of just holding one of these beautiful Festo cylinders cannot be described with words, the build quality is unbelievable. We used two in each car, each capable of lifting 178KG (1750 Newtons) at 10 bars!
By the power of Festo!

All in all I’m in awe of the design and production that Knut and Morten did, mostly just contributing to the electro mechanic part myself.

A “flappy” game prototype in JS with 1k tips

Last winter I was working on a Unity game project, discussing game concepts with 3D artist colleague Magne, namely the simplicity of “Flappy Bird”. How can it be that simple, and at the same time so addictive? We talked about having a go at it ourself, creating a spin-off or tweak to the concept. Shortly the idea of making a circular scene came up, like the old classic ‘defender’, but also inspired a little by the brilliant iPad game Osmos. Instead of the player going through ports, he/she would rather circle a planet only avoiding colliding into satellites or entering outer space. Our first goal was then to see if this was something worth spending time on – to answer that I created a prototype of the game. Try it for yourself, keep your black “spaceship” within the red “atmosphere” of the darker red planet, pressing the mouse or keyboard to add thrust clockwise.
Game screenshot

Did you like it? Was it to hard? Was it at all addictive? I knew creating a prototype of the game mechanics was the only way to answer this, as simple and quick as possible. JavaScript provides that with simple coding, great number of resources, and using a service like JSBin – a super quick start without needing anything else than a browser installed. JSBin also provides revisions, so you can demo and compare the game to older versions. For more control now however, I have moved the game to my Dropbox continuing coding with trusty editor Sublime. I also find that it’s easier to debug outside JSBin, using breakpoints and the handy debugger statement.

I started developing the game with just moving DOM-objects around, but due to performance issues on mobile I ported it to use Canvas as it is highly optimised on mobile browsers. It also meant more lean code, as I could eliminate both jQuery and CSS from all together.

A (1k) challenge arises

After being more or less happy with the game itself, my focus turned to the code. Could it be squeezed into, and be suitable as a 1k JS game? A challenge was created for myself, which really ignites an extra fun factor in coding. I first remember reading a post on creating 1k games, with tips including substituting and and shorting method and variable names. This of course creates a lot of unreadable code, so a lot of comments was desirable. Take a peak at these excerpts from the game code:

var a, //Angle to player from origo var
h, //Radius of player from origo
M=Math, //Sub Math
S=M.sin, //Sub Sin()
R=M.round, //Sub Round()
P=M.PI, //Sub PI
d=document, //Sub document
s=400, //Half the width of the game, width of planet
F = d.createElement('canvas'), //create a canvas to draw on
X=F.getContext('2d');

Shortening variable names saved a whole lot of bytes in combination with normal tools to minify JS. However I later learnt that Google Closure has this ability built in, without needing do make your own variable names unreadable. I bit of information I wish I had before obfuscating my code into byte sized ugliness.

Google Closure
As a bonus Closure also analyses your code for efficiency and checks for errors. Note that while Closure shortens and substitutes your own variable names, it does not substitute JS own functions. There are a lot of bytes to be saved substituting Math method names, as they are extensively used in games.

A note on difficulty

After the first afternoon of coding, I wanted to preview it to a number of people. I posted it on our work intranet resulting a nice portion of constructive feedback. Interesting enough, I got colleagues both complaining it was to difficult, and at the same time having others achieving three times the high score I had. Surely it was a good sign that they bothered to play it so much.

The initial version started with numerous enemy satellites to crash with, a little too difficult start for some players. To mend this, the game now starts with zero enemy satellites, adding on for every 100 points the user scores, with the maximum of seven.

So, what do you think? Post your score and feedback in the in the comments. If positive, Magne and I might progress into implementing the game in Unity and publishing on the app-stores!

Artikkel om meg i Kreativt Forum

47760-200bf-feature
Hvis lurer på hva jeg gjør på jobben – så får du et ganske utfyllende svar i denne artikkelen publisert på Kreativt Forum. Det står litt om prosjekter jeg har jobbet med, rollen min som innovasjonansvarlig og litt om undertegnede.

English: If you are wondering what I do for work – “Kreativt Forum” (Creative Forum), a web page covering the norwegian communication industry has published an article on me. It covers some projects, my role as a innovation manager and overall background. Try the Google Translated edition of it at your own risk :-)

Our talk at Making Web 2013


October 24th, Knut and I held a talk at Making Web 2013 about the project we did together at Apt. Namely how we built and developed the technical systems on “Solo – the world’s largest message in a bottle”. This was my first time speaking at a conference, and I must say it was both a challenging and fun experience. One I really would like to repeat in the near future (hint hint, conference organizers). Still, the necessary preparations and rehearsals sure tok a lot more work than I imagined. Never the less, it was the work we put in that made it possible to give the talk in a comfortable manner. Well, after a the first 5 minutes that is :-)

A video recording of our talk is available at the Making Web page. Take a look if you would like to hear about:

  • Building stuff, and integrating it’s electronics with Javascript
  • Running an unorthodox project with many suppliers
  • Creating tools for yourself in development and production
  • Using the Google Maps JavaScript API for drift prediction
  • A great story with a happy ending

Thanx to the organizers at the Making Web conference 2013 for a great experience! If you know of any other opportunities to give our talk, please get in touch. We can also modify it to be more/less about the build/electronics, web, JavasScript or just telling the story.

I’m speaking at Making Web 2013

I’m really happy to say I will be speaking with Knut Skåla at this years Making Web conference! We will be telling the story on the most amazing and challenging project I ever worked on – “Solo – The world’s largest message in a bottle”. The talk will reveal the technical solutions allowed the 8 meter bottle to report pictures and data onto the project’s webpage. The talk is named “From the Atlantic ocean to your browser“, which pretty much sums it up.

As this is the first time speaking on a conference, I’m really happy about seizing this opportunity and really hope there will be more to come. I will post a link to the talk as soon as it is published.

 

A real time strategy game with Socket.io, Backbone and Coffeescript

This article is “work in progres”, and is as much a future reference for myself as hopefully some useful information for you as a reader. One of the options for this article is turning it into a talk/presentation, I would like to hear your opinion on that!

From spring 2012 until November 2012 I worked in project team with the purpose of recruiting more students to become engineers in the energy sector. The project should both educate, inspire and ignite a curiosity about how Norway’s offshore oil industry works. With a target audience of young people looking into a higher education, we choose to make a game. A real time strategy game. The best player would be awarded a scholarship worth 50.000$, and hence the first challenge was created.

Cheating on the front end? Move it to the back end!

Creating games on the web where there are prices involved is challenging, as games run in the browser are notoriously easy to hack. Our first challenge was then to make sure that cheating would be too hard, keeping the competition aspect fair to all participants. Including those without any Javascript skills potentially being used for mischief.

As front end on the web is easy to manipulate, the back end is another story all together. There most is invisible from the outside, with wiring and logic being “eyes only” for us developers. Our solution was then to move all game logic and state to the server, with having the front end as lean as possible. However we wanted a game that would act quick and feel responsive. At the same time the server had to be able to contact the client, so posting forms and AJAX calls were out the question. With modest experience with Node.js and socket.io, we thought:
– Why not use just that technology, even though it’s a just single player game?

Game session on server, with backup

At game startup, we would create a game on the server and use websockets via socket.io to do real time communications between the client and server. Hence it would be impossible to directly manipulate any any state or logic on the client, eliminating obvious opportunities to cheat. Also the server was set up to save all state data to DB both at intervals and disconnect, making sure games were never lost. The user could just continue  whenever he/she would like to, being on the same PC or maybe on the phone riding the subway.

Start with responsive, continue with mobile first.

Today there is no way one can ignore the amount of mobile users on the web, with some of our campaigns reaching over 30% traffic from mobile devices. This was no exception, but building a complex RTS game was already a handful, so we had to think smart. As searching and producing petrolium was the objective in this game, it was obvious that we main part of the game would be based on a map. Luckily maps are per definition responsive, with bigger screens just displaying more of the map. But games cannot only be based on maps alone, other GUI elements must also exist for interaction with the user. So our designer came up with the idea that we would just use a board game metaphor, with playing cards as the base of the UI. Cards are small and fits neatly within a mobile display, they also have a natural border – making them also look good when there is more space available. Except for the intro page, and the HQ-menu we eluded the need for media queries in most of the game UI.

Game in development, stay at your post!

Most at the time when developing for the web, you want to work at a single part at the time until it’s done. When you have a game that’s progressing as you develop, that can be challenging, like working on a card that’s triggered from an event. You certainly don’t want use a lot of time searching for oil, just so that you can work on the card that tells that you found some. Luckily my colleague Anders came up with the idea of locking revisions of save games in the DB, so that every time I reloaded the game, it would start from the same exact spot! Brilliant, and a massive time-saver in the development process. We could also name save games, if we would like to start the game at those states later.

Debug screen, shortcuts to the developers delight

For all repetitive tasks as a developer, one should create tools that eliminate them. Some examples are:

  • Restarting the game from a save game, with automatic login
  • Keyboard shortcuts for saving a game and refresh the browser
  • Skipping to a specific view
  • Manipulating the model
  • Simulating data from the server
  • Simulating series clicks on UI elements to test a workflow
  • Displaying debug information

I really urge developers to use their imagination to create those little sweet tools, they are both extremely useful and lots of fun to create! As this project was built on Backbone, I just created a Backbone.View called Debugger, with references to the models so that it could listen for change events.

Interaction design crisis, not to be taken lightly!

Exploring, finding and pumping oil from a rig you have to build is not simple. There a lot of steps that has to be done before the “black gold” is ready to be sold by the barrel. Communicating and teaching the user that process was already a challenging task, making the user complete all those steps in a game, even harder. A complex concept dictated a complex interaction, with too many choices on each map tile for the user to comprehend.

This challenge really manifested itself when I just had completed all major parts of the game and was ready to try it. A bit excited I started from the beginning, creating a new company “Snake Oil” and started the game from the top.

There was just one problem, I could not understand how to play the game which UI I had created myself!

An interaction crisis was a fact, and I rallied the troops for a whole day meeting, loaded with Post-Its, whiteboards and markers. We first tried to map all steps the user had to visit before making money on oil production, and from there we looked into solutions that would help him on his way. It was a long process, but in the end we came up with a solution that in my opinion really saved the whole game and project in whole.

A stitch of the result post-its. Showing all steps for the user to take before pumping oil.

From a solution where the user had all options available at all times for a map tile, we drastically simplified the workflow by forcing the user into a “wizard” mode for each tile. So the only choice the user had, was clicking a map tile, and the next action for the tile be presented. So instead of having a massive hierarchical menu, we just sat a logic order on all steps available. When exploring a map tile, instead of the user having to select from “2D seismic”, “3D seismic”, “environmental inquiry” and “geological research”. A click on the tile would just trigger purchasing the one action after the other. This also saved us the massive design challenge of pushing abbreviations of all those choices on a menu that would fit into a mobile display.

Result and statistics

Some statistics of the game in it’s competition phase. More to come later:

  • In the most intense weeks, average time on site was 40 minutes. On our other typical campaigns, the average is closer to 4 minutes.
  • 100 000 games were played. That’s the number equal to 2% of the Norwegian population
  • 75% of the visitors was returning, they wanted to play more

In short, we were extremely pleased with the response we got from the users and in the numbers above. The users really enjoyed the game we had created, and some even begged us to keep it running after the competition ended.

The game is still playable at it’s original link, albeit only in Norwegian:
http://www.jaktenpaadypet.no/

Project team

Art Director Sebastian Rasch
Copywriter Anders Holm
Copywriter Sigurd Solberg
Consultant Ole Hustad
Project management Mona Larsen
Developer Anders Stalheim Øfsdahl
Developer Emil Jönsson
Developer Pål Smitt-Amundsen
Developer Knut Skåla
Project Music Dedmau5