Etter en del frustrasjon med manglende kunnskap og mangelfullt underlag fra mediebyråer – har jeg skrevet et innlegg i Kampanje som setter fokus på saken. Det er nå viktig at mediebransjen, og særlig mediebyråene setter inn et ekstra gir for kjapt å tilegne seg nødvendig kunnskap om HTML5 annonser.
I den noe lett kaotiske og teknisk utfordrende HTML5 annonse-verden har det nå kommet et lyspunkt – IAB har nemlig laget et utkast for “HTML5 guidelines” som går for en anbefaling på 200kB (!). Av teknologiske årsaker er nemlig mye vanskeligere å få et kreativt konsept innenfor kB-begresningene med HTML5 enn det var med Flash. Så nå er det lov å håpe at vi på sikt kan få litt mer kreativt spillerom her også i Norge.
Om dette blir standarden eller ikke, så hadde det uansett vært en stor fordel om vi kunne innført brukt “CDN hosting” av det vi mener er det det aller beste animasjonsbiblioteket, nemlig Tween-serien fra Greensock. Biblioteket gjør det mulig å lage rikere løsninger, enklere, kjappere samt at det i stor grad garanterer best mulig ytelse med tanke på CPU-bruk. Fordelen med at vi kan hente biblioteket fra ett sentralt CDN vil også være at brukere kun trenger å laste biblioteket én gang, for så å automatisk “cache” det de neste gangene annonser blir vist i samme nettleser.
For at dette skal fungere må det aksepteres av alle norske nettsteder som vi lager annonser for, samt med de annonsesystemene de bruker. Samtidig må vi bli enig om én CDN-link vi kan bruke på tvers av alle nettsteder og systemer. Dette er den eneste måten vi kan få en løsning som er optimal både for sluttbruker og oss i produksjonsleddet.
Les mer opp HTML5-annonser og Greensock sin oppfordring her:
Hvis du ønsker en mer generell innføring i konsekvensene er av overgangen til HTML annonser er, så har jeg skrevet en innføring på min blogg.
PS. For dere som produserer HTML5 annonser, følg med på Greensock sitt forum
Despite that an increasing amount of my time is spent on giving talks, research and otherwise evangelising about technology – I still love to code. This is a good example on just that, being able to tinker with a visually rewarding task like creating this 3D-animation of trees. The animation is made possible with a newer web technology called Web GL that allows advanced live 3D in your browser.
The library Three.js allows a simple interface to creating the 3D content. Visit CodePen to peek at the code : http://codepen.io/gadgetgnome/pen/gpoMGg
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?
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.
Oppdatering sommer ’15 – Vil Chrome blokkere Flash-annonser?
Neste versjon av Google Chrome, den største nettleseren på desktop, vil pause “ikke-essensielt” Flash-innhold. Annonsene vil da ikke bli korrekt vist uten at bruker aktiverer de med et klikk – noe som er svært lite sannsynlig. Medier vil nå snart sette sperrefrist-datoer for når de ikke vil ta i mot Flash-annonser lengre, overgangen til HTML5 annonser er da straks et faktum.
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.
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.
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.
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.
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!
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
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
- Running an unorthodox project with many suppliers
- Creating tools for yourself in development and production
- 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 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.
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!
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.
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:
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