Our brief to the Danish creative agency Spring/Summer was straightforward – create a landing page for Beagle that explains the product, makes people want to try it, and which wins awards. Thankfully for us, they succeeded in spectacular style. In this guest post, creative technologist Niels Lyngsø, founder and creative director Pelle Martin, and head of UX Jeppe Kruse explain how they did it.
So what’s the first thing you do when somebody asks you to do a landing page for a proposal builder app? You make a really good proposal, right? Show them how it’s done.
Well, we skipped that part, believing firmly that great work can also start with a great brief. A few hours after we met the Beagle team for the first time we were working on concept ideas. We’d been given a budget and a blank canvas to draw on and we were set to deliver something that would really sell Beagle to its primary target group – agencies.
Not so fast.
We quickly realised that the Beagle app itself wasn’t ready at this stage, so there wouldn’t be a lot to show from the actual product. I guess that’s the life of a start-up; you don’t know what you have until you actually launch. But we knew we had to make an impression and that’s where the idea of the physical metaphor came in; we would show a digital proposal coming to life through a would-be physical piece of paper, but on digital platforms. I mean, where else would you go for a landing page? It would definitely be something else.
From here we moved quite fast. We started working on storyboards, visual directions and animation styles together with the Beagle guys. Everybody drank lots of coffee at this stage, and we had inspired conversations about the stereotypical start-up landing page style that we wanted to avoid. We found inspiration in flyers and posters in the Spring/Summer conference room, but in the end we were lucky enough that the Beagle team trusted us completely, so it was just a matter of finding some new ground and breaking it.
We were also already trying out stuff in code, in fact that’s how we started. We knew we wanted to build an animation-heavy one-pager that would have both scripted and user guided animations, and we were hoping the site would be shared a lot in the digital design community and on social media (fortunately, that all happened). We figured it wasn’t that important to bring the full experience to older browsers but it would be a shame to leave mobile users behind. We focused on delivering a super smooth experience to the newest devices with a special focus on the iPad.
Much of the work we did in this initial phase was about trying out different approaches, looking for ways to keep performance high. We weren’t so concerned with bandwidth usage or code bloat at this point (that would come later), but we wanted to make sure we could throw an animation party in the browser without bogging down the user’s device. To tell the Beagle story in the right way we needed everything to move at high frame-rates, even in mobile browsers.
This is where a little thing called Pixi.js comes in. Pixi is a “2D webGL renderer with canvas fallback” that works in newer browsers. In popular terms it offloads some of the work the browser needs to do when animating stuff, which is great. But as you probably guessed already, this kind of stuff comes with a price. With Pixi.js you can’t just throw some HTML together and start animating – to get the best results we had to create almost everything from scratch with Pixi.js and render it onto the Canvas element using WebGL.
(Fun fact: There is some regular old HTML in the Beagle landing page. Look for the pre-loader, the logo and sign-up buttons in the top of the page, and the footer.)
So, what actually happens when you load up the page in a browser and start scrolling? To put it bluntly we hijack your scrolling and translate it into animations that appear to be some kind of scrolling too. I know how bad that sounds but believe me, it was for the better. We were way past the point of no return.
Side note: it was important for us to never block user input. We went to extra lengths to ensure you can always continue scrolling, or scroll backwards whenever you want, without the animations breaking.
We built our own little component that controls all of these hijacking shenanigans. It stays aware of how far you’ve progressed. It knows the size of your browser’s viewport and where you’re supposed to be in the landing page, and if any animations have been (or are supposed to be) triggered at any given time. It also knows not to waste resources by rendering stuff that’s outside your viewport. This thing is so smart, it could probably figure out what you had for breakfast.
So you make a scrolling motion and stuff gets rendered on the page. All of those animations you see in each chapter are fully custom, designed and assembled from the ground up. And hopefully, if we’ve done our job well enough, when you reach the end of the page you cannot resist signing up for Beagle.
To accomplish that level of perfection we entered into a final phase of tweaking and adjusting. This is when you do the other 90% of the work, as the saying goes. We had arrived at roughly the look and feel we wanted for the Beagle landing page, and we were set on more or less final versions of every chapter in the story, and the order they appeared in. Now, our designer, animator, and front-end developers were working together to tweak every little detail of the site – getting animation timing right, trying out different floating effects for the tear-out piece of paper, balancing copy against visual artefacts and all the stuff that was moving around, while still keeping the site running fast everywhere.
And as it turns out they pulled some pretty awesome tricks, even if we say so ourselves:
Image sizes: Scaling images is bad when animating stuff in the browser, so instead every image asset in the Beagle landing page exists in 64 different sizes. Resize your viewport and you’ll notice how they only scale to a set size after you let go. Keeps everything animating smoothly.
Screen sizes: Beagle renders natively on 4K screens. The code supports Retina HD (@3x) graphics, but we had to set the limit at Retina graphics (@2x) because the GPU of most Retina HD devices couldn’t handle native-sized graphics well enough. It’s all about those frame-rates.
Browsers: Our front-end dev Robin swooped in and created a full fallback version that even has its own effects and animations. No corporate users left behind.
Photos: To bring a bit of start-up bootstrapping philosophy into our world, we shot everything here at the Spring/Summer office last minute. Those are the real Spring/Summer people you see in the pictures.
And who knows, it might have been even better if we had started by writing a proposal. But the response has been overwhelmingly positive! So just this once I think we can say that everything worked out fine without. To date, the landing page has been awarded:
And it’s just been nominated in the Web Services and Applications category in the Lovie Awards – go vote for it!