This site really ballooned in scale during development, and unfortunately suffered as a result when time limits were reached. In particular, it could do with a lot more optimization.
My main responsibilities when building this were to lay out the various sections of the (enormous) home page, to animate the illustrations, and to make improvements to the Webpack-based build process.
I had some fun making the various small animations: I was given SVG illustrations and very little direction, and just animated whatever I could think of. Wagging and swishing tails, streaming water, swinging shopping bags and golf clubs, waving flags, sloshing and foaming beer and science equipment, tapping feet, nightmarishly bad parking attempts, spinning engines and coins, … Some interesting perspectiveless 3D transformations were used in some places to keep the isometric look while animating.
The most complex piece of code was that which lays out the road and animates the car in the last section (“invest here”). The idea was for the road to be routed around the various text and illustrations in this section, but since this is a responsive website this had to be done dynamically. So on page load and after a viewport resize, my code runs which checks the positions and sizes of the various elements the road needs to avoid, and plots the road’s path accordingly. It’s very flexible, and if more pieces of content were added it would happily route the road around them. The entire road is just two uses of the one defined path, with different stroke styles, and the path is just straight lines and circular arcs. At the same time as this is plotted, data is collected for the driving car animation, which includes the coordinates of the corners, the cumulative road distance at each corner, and the direction the car should be facing at each corner. A set of CSS keyframes is then output to the DOM to animate the car’s position and animation frame (the direction it’s facing), and then the car happily drives the road on a loop. The road was originally supposed to come from somewhere but there’s another casualty of running out of time.
The build process is pretty nice, and is probably one of the more complex Webpack configurations I’ve set up. There are three different configurations of the image loader just for SVGs – symbols, inline SVGs, and non-inline SVGs. On top of that there’s a configuration for the same image loader but for other images, both for responsive and non-responsive images.
Tribal mainly uses Twig for templating and so that’s what was used here.
I had a lot of trouble getting
twig.js to play nicely with Webpack, since
twig-loader seems buggy at least for this use case.
In the end after giving up on getting Twig files to run nicely through
html-loader, we had
It’s not ideal in my opinion, but it does the job.