The Devil You Must Live With
Let’s be honest. As designers most of us would prefer it if ads just went away. It’s okay, you can admit it. They’re the unwanted stepchildren of the web design world and we all know it.
But for those of us that work on sites that depend at least in part on advertising for a chunk of their revenue, sites like BusinessWeek, ads are a sober reality. Get used to it. Ads put food on the table and staff in your chairs. It may not be all sunshine and lollipops sometimes, but it behooves you to learn how to design with them in mind.
As we’ve been updating our design I’ve made a point of thinking of our ads like real estate. No one wants to buy a timeshare in the ghetto.
Keeping that metaphor in mind and discussing it openly we were able to do the unthinkable with the new homepage and story page designs—remove ad positions. By axing cluttered ads not only were we able to trade up to larger sizes (more dollars), we also increased the overall value of our “neighborhood”. Not cramming an ad into every crevice of whitespace gives you the opportunity to lay each one out appropriately and ensure it hews to the visual rhythm of the site. Just like your content elements. Advertisers notice their ads aren’t locked in mortal combat with each other, competing for the user’s attention, and they appreciate it. People feel a lot better about forking over their bucks for property in the good part of town.
Just as important, being able to discuss ads internally using these kinds of terms kept us from falling into the classic “us-versus-them” trap. (You know the one I’m talking about. It goes something like this: “All you suits do is screw up the site!” “You artsy types don’t know how to run a business!” And so on.) We were all just folks in a room trying to figure out how to improve our community.
Then there’s the small matter of implementation. Basically, ads make their way onto the site through good old-fashioned JavaScript calls scattered throughout the markup. The actual content pulled in by these calls is created by a variety of third parties and their sundry partners. And partners of partners. And partners of partners of partners. You get the idea. All this makes for a pretty wide variety of code quality. Another fact of life that there’s just no getting around. Some ads are just dandy, and some are… well…
Some suck. Hard.
What’s a DOM maven to do when every include and their brother calls window.onload?
First off, Simon Willison’s excellent addLoadEvent is out the window. Because the ad calls happen late in the markup, after our own DOM scripts have been called in the head, any ad that stakes a claim to window.onload obliterates addLoadEvent. All that’s left is smoke and ashes. Too bad. We needed some kind of event listener.
And then sweet serendipity struck.
Just as I was getting ready to hunker down for a long night of pounding out a listener from scratch the fifth edition of David Flanagan’s seminal JavaScript: The Definitive Guide dropped.
If you’re still knocking around with a trusty dog-eared fourth edition do yourself a favor and pick up the refresh. It’s worth it. Besides smartly consolidating the different client-side reference sections it adds a handy helping of new goodness. Example? A robust onload event listener. Standing there in the bookstore I pretty much randomly flipped to Flanagan’s runOnLoad (page 434, example 17-7) and there was the answer winking up at me. Thank you, Mr. Flanagan. So far its handled everything we’ve thrown at it on BusinessWeek.com without complaint.
As of late there’s been some fresh discussion about cracking the window.onload nut in new ways. It’s clear this is anything but a done deal and that’s a Good Thing. The upshot? Even when you’re serving up all manner of thorny, unpredictable ads and partner content you can still be hip to Web Standards and the DOM. Even the biggest, craziest commercial sites no longer have any excuse.
You can have your design, ads and DOM, and eat them too.