UPDATE: I have disabled the experimental ad described in this article because the Javascript conflicts with the theme design.
I released an eBook over the weekend. You can read about it on SEO Theory. It’s called SELECTIONS FROM THE SEO THEORY PREMIUM NEWSLETTER, VOLUME 1 and if you follow that link you will be able to read all about it. But here’s the thing.
Although I’ll need to promote the book more aggressively, after spending a lot of time working on that project I decided to experiment with an interactive advertisement on the SEO Theory blog. It runs in the left rail/margin of the site, rotating in about 60% of the time.
We use the AD INJECTION plugin to manage advertising on many of our blogs and I was able to embed code for a simple interactive ad into the AD INJECTION WIDGET. I’m selling the eBook through the e-Junkie service, which seems to have a pretty good reputation extending back several years (although finding real customer comments amid all the hyped-up affiliate “reviews” was a time-consuming task).
I point all this out because I am using the AD BLOCKER extension for Google Chrome and it seems that AD BLOCKER doesn’t filter out all of the advertising code we embed on our pages. I suspect it’s only looking for Javascript embeds (which is perfectly reasonable but misses some other types of advertising).
My browsing experience since I embedded AD BLOCKER has been a delight. Fewer Web pages hang my browser and lock up my computer, and I still see a SMALL NUMBER of ads. But now I can visit Websites like CAFE MOM without having to take a break and rebuild my car engine while the page loads. Not that I recommend CAFE MOM — I guess there is a reason why some sites use Outbrain because I never run across them in other contexts.
But I digress. This is not about advertising. This is not about blocking ads. This is about the complex relationship between all the components involved in WEB DESIGN and BROWSER MANAGEMENT.
When I look at design elements I sometimes consider whether they can or should be embedded in Javascript or iFrames. In old school HTML markup we would just slap a NOSCRIPT or a NOFRAMES tag after the important code. Unfortunately, XHTML doesn’t support NOSCRIPT and HTML 5 doesn’t support frames or NOFRAMES.
The people who define these Webs standards believe in DEPRECATING features they don’t like (and there are legitimate security issues with both Javascript and frames of any type). The iFrame specifications address some if not all of the security issues and they solve some inelegant problems (such as serving up the same text on millions of Web pages) in a rather elegant fashion. After all, it’s just one more fetch for the browser, right?
Ah…The BROWSER
Now, there’s rub if you want one. Browsers are such inconvenient things for Web designers. Earlier I was complaining about all the advertising placed on Websites; advertising and video widgets and other crap that Web designers love are such inconvenient things for people surfing the Web. Never mind the fact they pay the bills, I don’t want to wait around while CNN tries to launch 14 Javascript ads in my browser, serving me who-knows-what for content. Yes, I recently noticed that AD BLOCKER prevented CNN from starting 14 somethings on one page.
I know there are good people at CNN who all need to work and support their families, but FOURTEEN EXTERNAL DOWNLOADS for 1 page? Where do you draw the line?
Not only do Web designers have to allow for the various standards they work with (you might serve XHTML here, HTML 4.01 there, and HTML5 elsewhere); they also have to figure out if the code will work on desktops, laptops, tablets, phablets, and smart phones (and almost smart phones). And they have to figure out if that code will work well in Chrome, Internet Explorer, Safari, Opera, Firefox, and anything else pretending to be a Web browser.
Heaven forbid if the user should use a proxy server or sit behind a corporate or ISP firewall.
It’s these … Klingon Web Standards, Admiral. Web surfing has drained them.
And Now We Have Users Configuring Browsers
Browser plugins have long been the almost private domain of developers, security analysts, and Web marketers. Most users didn’t even know they existed for several years. But when I finally broke down and went looking for an advertising blocking extension not so long ago, I was astounded to find that all the leading extensions for Chrome were claiming MILLIONS OF DOWNLOADS.
That’s a lot of people who are fed up with advertising on the Web. It’s no wonder your Google AdSense click-throughs are declining. Every month fewer people can see the ads because every month more people discover ad blocking tools and install them.
I have no doubt that advertisers are already working on ways to get around the ad blocking tools; and browser plugin developers will respond to the new advertising formats to ensure that people have a good chance of seeing only what they want to see and not what advertisers want them to see.
This whole advertising arms race mirrors the search engine marketing arms race. Search engines block Web spam and marketers find new ways to spam the search engines. It will never end because there is money on the table.
And that is true of Web advertising: the arms race will never end because there is money on the table.
Which Brings Us Back to My eBook
The code that e-Junkie provides you includes inline Javascript (looking for “on-click” events). So, in order to see my ADD TO CART and VIEW CART buttons you have to be able to “see” the Javascript in your browser. But if the ad blocking software is blocking the Javascript, you don’t see the buttons.
In my case AD INJECTION’s widget is blocked in the sidebar but I still see the code on this dedicated page I created to sell the eBook. I think that means the AD BLOCKER designer has mixed in some good judgment, taking a conservative point of view about in-body Javascript. But advertising your best deals in the margin may not work for every user.
Interactive advertising widgets are cool — but only if people can see them. Maybe the AD BLOCKER extension looks for the comments that denote advertising in the sidebar but I think it’s just looking for Javascript references and figuring out how the widget block is defined. And yet, I can see the buttons on the dedicated page….
In this case I am glad that the extension is not blocking the Javascript but I can only imagine how many sidebar widgets may be accidentally blocked or misidentified by people (and extensions) who think they are seeing advertising. I once submitted a Website to the Joe Ant directory and they rejected it (they told me) because the pages were filled with ads.
There were almost no ads on the site at that time. They were looking at crowded sidebar content that was all relevant to the main body copy (mostly navigational links pointing to other parts of the site with similar content). Because huge lists of links are user-unfriendly I boxed the links and made them look “advertisey”.
All of which just goes to show that no matter how hard you try to put the user experience first, someone else will decide you DIDN’T PUT THE USER first, and they’ll screw up your hard work.
In that respect, I extend some consideration to all the people who have complained about Google algorithms downgrading their “good” Web content. I grok your frustration, friends, but at the end of the day it still comes back down to what the user does and does not want to see on the page. Advertising is user-unfriendly and users are doing their best to get away from it.
It may be a while before we figure out a generally acceptable compromise.
Read More about Search Engine Optimization
How Long Does It Take SEO To Work?
Outbound Links: Why Use Forward Links for SEO?
On-Page Optimization SEO Checklist
White Hat Link Earning Techniques
Follow Reflective Dynamics |
Click here to follow Reflective Dynamics on Twitter: @refdynamics. Click here to follow SEO Theory on Twitter: @seo_theory. Reflective Dynamics' RSS Feed (summaries only) |
Amazing article, you have explained some really basic area which must be helping for all quality designers.