Behind the scenes of the rich, dynamic user experience you've seen on our new story pages is a brand-spanking-new technology platform. We built it from the ground up to be flexible and innovative and awesome. We're pumped about what we've been able to build. Even more pumped about what we'll pull off next.
Here, we're going to dive into the technology behind just one of the things in our basket of new and awesome: ServeView. That is, ads that only download and display when you're only actually going to see them.
For technical people (that's me!), our platform allows selecting the right tool for the job: leveraging Microsoft's ASP.NET MVC framework to pull off intensive composition and rendering logic on our servers; while handling user-interface behavior in the browser, implemented primarily in JavaScript, with a keen eye toward web standards and cross-browser compatibility. A focus on sharing detailed data between these server- and client-side layers allows our code to make complex decisions about layout, ads and features, all dynamically wrapped together in an experience delivered to your browser.
And the importance of that technical foundation was impossible to ignore when the concept of ServeView ads came up in our design and brainstorming process. It was clear that making it happen was going to be a challenge. Multiple ad networks and platforms. Complex page layout requirements. Failover. Performance. We had more than a few dots to connect.
Pulling it off
One way to think about an ad on the page is as a unit – a bucket already sitting within the page, containing everything it needs to display the creative it's assigned. This corresponds to a common approach: rendering an inline script block that invokes a call to an ad provider, based on parameters including the type and size of the ad creative to be shown – shown right there, where you put all the code, immediately when the page loads, and regardless of whether the ad is actually on the screen. Well, it turns out treating an ad as a unit isn't flexible enough for us.
We decided to think about an ad, not as a unit, but as three distinct parts:
- The placeholder that marks where we intend to display the ad
- Per ad provider or network, the code that allows us to request and display the ad creative
- The specific parameters, or metadata that indicate options like the ad's size, type, whatever the corresponding ad provider needs to identify the specific ad
Our code corresponds to the concept. We include ad placeholders within the structure of our markup templates, which expose class names linking them to a type of ad, its context and size. JavaScript wrappers, per ad network and platform, provide a façade to disparate methods to request and display ads, enabling us to treat all ads across all types in virtually the same way.
When the page loads, code (we love jQuery, by the way) sweeps the ad placeholder in the page, matching each to its corresponding metadata, but without making requests for the associated creative. Instead we attach event handlers to prime these, now matched, ad placeholder, for use. Then, as users scroll and interact with features, we check the browser's viewable area for those primed ad placements. The first time each placeholder comes within view, its event handler applies, which makes the associated ad call, via the ad network façade, which downloads and displays the creative within the placeholder markup.