3D coding fun in the browser

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.

See the Pen Canopy Flight by Pål Smitt-Amundsen (@gadgetgnome) on CodePen.

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

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.