Case Study: How we built the scenes on Google Santa Tracker
The christmas spirit has arrived early this year at 14islands!
We got approached to help on a very exciting project from Google called Santa Tracker.
Google Santa Tracker is a christmas calendar that consists of 24 interactive scenes. From elves having a good time and doing some work to mini-games to keep you entertained - Google Santa Tracker is a massive christmas environment with lots of fun.
One scene is unlocked per day, from December 1 until December 24th. We had the pleasure to collaborate on 9 scenes for this project.
Thus we would like to share our experience on the process from design, coding to debugging and testing in various devices.
The whole experience was directed by our friend and multi talented designer Haraldur Thorleifsson.
The design features colourful flat elements and details, like iconic animals and nature. The elves are shown in different colour outfits and you can always see them posing in different perspectives.
Everything is vector based and got delivered to us in Illustrator files. That gave us the freedom to slice and scale them how we see fit. Good approach to keep things responsive and resolution independent.
Building this design was loads of fun. It was not uncommon to laugh about the scene because it was so captivating.
Say, an elf animation moving too fast because you are experimenting with the animation? "Haha - look at that elf!". And so on.
Bringing the design to life
Looking at this project design we could see straight away that we should give SVGs a try.
The elements were not too complex and the SVG's potential was staring right at us. Some reasons that pushed us to stick to SVG on almost all of the graphics we took care of:
A SVG file size if compared to a PNG is smaller.
A compressed SVG file size gets even smaller than an optimised PNG.
We love markup. Glancing through a SVG markup and it's quite straight forward to understand what's happening, making it easy to tweak where necessary without opening jumbo Illustrator.
No extra requests. Put this bad boy inline with the HTML and you're gold.
It's crisp. Hello, retina! Long time no see.
First image is a SVG and it weights: 4KB (uncompressed)
Second image is a PNG and it weights : 10KB (uncompressed)
With Illustrator opened and SVG in mind, we would spend some time on each scene thinking on what would be the best way to tackle them.
Our process of working on Illustrator was something like this:
Study and strategise the scene. How many layers should be separated, grouped, etc.
Copy the object that you want to export and paste it in a new document.
Fix the "artboard" dimensions in Illustrator based on the graphic.
Make sure the export settings are optimal for web (see screenshot below).
Compress it if possible and make sure it still looks good. Here you have to be careful, compressing might remove some things you need.
It's important that we compress the SVGs to keep the size small and optimal. Performance matters!
A quick search on compressing SVGs I came across svgo by chance.
That was our tool of choice for compressing SVGs to keep them optimal and we can recommend it. There's a grunt plugin for it, even.
Separating different elements
Given some time studying the scene we could then conclude on which elements needed to be separated in many graphics and which elements could stay all together in one.
It was important to divide the scene properly in different layers to get some nice effects. That way you can have some elements staying on top of others, acting as a "mask" for some animations.
Check out the airport scene, for example. The elves just re-appear fully clothed. For this effect to happen properly, we needed the "closet" to be in a separate layer being on "top" of the "conveyor". So the elves can show up behind it.
Animating with CSS3 keyframes
We have our scenes in place responding well. Now how will we animate them?
There are a few different ways to animate an SVG.
1. You could use the SMIL spec to animate some SVG elements
SMIL stands for "Synchronized Multimedia Integration Language" and it's basically markup that let's you specify attributes that should change for a given duration. The SMIL syntax can be used in combination with SVG.
Pretty much like animating elements with XML. It's a very interesting approach, introduced initially by Mozilla.
The problem is that Internet Explorer doesn't support it and likely never will. So this option was out.
2. You can use Javascript to update the built-in attributes of an SVG.
SVG has some very interesting attributes that you could update on the fly by using Javascript. Radius, x, y, stroke, etc.
There is a article from polygon showing a nice use of stroke-dasharray and stroke-dashoffset for a cool effect.
3. You can animate the SVG just like any other element by using CSS3 keyframes
Being a responsive project, we wanted everything to perform the best possible way.
We thought that CSS3 keyframes was a good performance bet - considering we animate only the "safer" properties as much as possible.
Also for the fact that we wanted to keep things simple with Javascript and that our animation could be easily solved with CSS3 transforms - this became our choice.
We won't go deep on how CSS3 keyframes work because there's plenty of material out there.
But one typical and interesting task that we would need to do is how to synchronise some animations together.
CSS3 keyframes and the animation-delay
With Javascript out of question, one way to make the animations synch is to use "delays".
You want animation B to only play when animation A is completed. So you add some delay to B that equals the duration of A.
The CSS3 animation spec has a property called "animation-delay" for this.
To be honest, it would make more sense to me if this property would be named "animation-initial-delay" because the delay only happens once.
Specifying a delay of 5 seconds on animation B, means it would run 5 seconds after the page loads. As soon as the animation comes to the second iteration, the delay won't be applied.
Sometimes that is enough depending on what you need to build. A very good example of animation delay usage is the digital clock that you can find in the Command Centre:
See the Pen yJnLi by Marco Barbosa (@marcobarbosa) on CodePen
Here each digit gets a delay before fading-in/out to "offset" it from the other digits animations. That way the seconds play before the minutes that play before the hours.
But what if you want this delay to happen in every animation cycle instead of just once?
Adding empty frames as delay gaps
The idea is to increase the duration of an animation just to be able to have "delay gaps".
Total duration = duration + some delay gaps
See the keyframe there at 50% and then next is 54%? That's a 4% difference between them, right? That's our desired duration: 20 (total duration) * 0.4 (that's 4%) = 8 seconds.
So our animation is 8 seconds long but we use the other 12 seconds to do nothing - acting as a delay.
That way in another animation, also with a 20 seconds duration, we would do something at 54% to match.
This way you can synch a lot of animations together by adding larger durations and making sure the keyframes are similar.
One scene that shows a very nice synchronisation is Call from santa:
Make sure the animations that you want to synchronise have the same duration, delay and preferably are linear (or have the same easing). That will make things a lot easier.
iPhone4S happened to be a very good test device for this project. That is because CSS3 keyframes performance in both Samsung Galaxy S3 and iPhone5 were a breeze.
Chuck in some animations and things will "just" work. Pretty powerful devices.
iPhone4S, however, would crash if you're pushing too much.
Because of that, iPhone4S quickly became our reference test candidate for the scenes: if you have something crashing on iPhone4S then it's really too much going on.
The worse part about testing and debugging was Android browser.
Android browser has some weird behaviours to when it comes to animations. Debugging was even more difficult because you'd nee to toggle things on/off to find out what's going on.
Fortunately, for that, there is Weinre.
Just to give you some examples of Android browser issues that we found on the way:
Android doesn't like animation shorthands
Iteration count is not properly supported
direction reverse doesn't work properly
negative delay doesn't work properly (or at all in some cases)
This will be improved very soon though since Chrome is now the default browser on Android versions starting from phone 4.3.
Building these scenes was a true joy. From putting SVGs together in the browser, to spicing things up with some animations and debugging.
A few points to sum things up:
CSS3 animations are good until a certain point. With more complexity they get pretty limited.
Javascript still has a very strong spot when it comes to animations. Simply because of control and flexibility. Animation order, delays..the more complexity you need the harder it gets to handle it with CSS3 keyframes.
Be careful with Android browser. Test as early as you can to just be safe.
Responsive Web Design can also be interactive.
Looking for a cutting edge project? We love those! Get in touch!
