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.
Some suck. Hard.
What’s a DOM maven to do when every include and their brother calls
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
addLoadEvent. All that’s left is smoke and ashes. Too bad. We needed some kind of event listener.
And then sweet serendipity struck.
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.