Tag: css

The Problem is Not Ad-Block it’s Ads

I’ve seen a fair bit of discussion again recently against ad blockers. Even some new services to help advertisers avoid the blocks.

Scale: Intrusiveness of Ads
Scale: Intrusiveness of Ads

It may surprise tech nerds that people outside our field have no idea that ads help fund the free content we consume online. The vast majority of Facebook and YouTube users never stop to consider who pays the hosting fees for those heaps of family photos and cat videos. To these users, ads are just another unpredictable barrier to their stuff. This is especially true when ads are the pop-up, pop-under or pop-between-paragraph type of affair. They disrupt your session and demand your attention. I understand the need for ads to get seen but it’s a bad experience. It doesn’t take a huge leap from there to understand why ad-blockers are so appealing. They easily remove these annoyances at source. Pages load fast, text stops jumping up and down the page, the web works like it did in the good ole’ days. That advert for a new car you were researching stops following you around the web. It’s a massive win for users.

But here’s the thing. Small indie publishers are way down on the annoying ads scale. It’s predominantly large news sites, or blog networks that have the worst of these ads. Squeezing every last penny from their page-views, they poison the web for everyone.

Compare this ad on Marco.org:

Marco Ad

With the ads on engadget:

Engadget Ads

The discreet and relevant advertising on Marco’s site doesn’t alienate users & offends nobody. The Deck has taken this approach, and nobody would ever bother to block deck ads. Why would they? They are relevant to the sites they appear on, and don’t interrupt the experience for anyone. I assume they have a lower CTR than other ad-networks, but they respect the readers and don’t dance all over the page for attention. I expect the quality of leads from these ads is far better than AdSense for example.

Here’s the problem. Ad-block doesn’t just get rid of the awful flash ads that clutter news sites but also blocks unobtrusive ads like the deck. See the example below of the Marco & engadget pages below when using adblock. The engadget page is much improved showing the articles you came for right at the top! On the other hand, Marco’s site is hardly changed at all.

Engadget No Ads

Marco No Ad

Users will happily run ad-block and get their internets back, but the small sites lose out. They never hosted up video ads for cars or holidays, but they lose their small revenue stream thanks to the ham-fisted & heavy handed big networks. You can’t put the blame on users here. They have a tough enough time navigating the evils of the web. Blocking ads just reduces their hassle a little bit.

Update 22-6-2015

On Friday after I posted this article I later saw that John Gruber had basically said the same thing as me in one succinct paragraph. Smart guy.

Twenty Fourteen Single Post Page Secondary Menu Disappears

After ironing out some issues with my Twenty Fourteen Child Theme, I found another one. This one is not really a bug, as it is quite deliberate, but it was still a problem for my needs. When viewing a single post page, the secondary menu in the left sidebar is not visible. The menu is visible on other pages, and on the overall blog page. Again, I’m not sure why this was chosen behaviour, but there is a float left and negative margin that pushes the menu off the edge of the screen.

On line 3596 I changed the following:

#secondary {
 background-color: transparent;
 border: 0;
 clear: none;
 float: left;
 margin: 0 0 0 -100%;
 min-height: 100vh;
 width: 122px;
 }

To:

#secondary {
 background-color: transparent;
 border: 0;
 clear: none;
 position:absolute;
 min-height: 100vh;
 width: 122px;
 }

So far, this seems to have reinstated the menu, but I’ve yet to test this much yet. There is a chance it may cause trouble under certain conditions. I will see if it causes issues on a full-width page, and check the other media queries for knock-on issues.

Twentyfourteen Sidebar Bug

After updating to WordPress 3.8 I was keen to give the new Twenty Fourteen theme a try. I’ve been using a modified twenty eleven theme forever so thought a change would do me good! Within an hour I had changed the default green accent colour to match our company blue, made sure our contact-form plugins still worked, and got everything looking perfect on my testing site. My pointer hovered over the Publish button, but I decided to give it a quick check on the iPad. Just in case.

It looked great. The responsive layout was beautifully readable, and everything looked fresh and new. There was a slight, but game-stopping problem though.

The Content Sidebar Became Unclickable!

Some of the media queries that control the responsive layout had clashed and caused widgets within the content-sidebar to become unclickable at certain viewport sizes. In my case this was the contact form we have on every page, so losing the ability to fill the form is pretty bad news! I checked on the desktop version of Safari and found the same problem if I reduced the window to approximate iPad size. I couldn’t replicate the problem in Firefox at all.

For reference I was able to find the culprit. Two lines of CSS.

On line 3186 I changed width:100%; to width:66.66666666%;

On line 3192 I changed margin-right: 33.33333333%; to width:100%;

This fixed the unclickable problem, but caused a bit of overlap elsewhere with another media query so:

On line 3578 I changed:

margin-left: -29.04761904%;
width: 29.04761904%;

to:

margin-left: -25%;
width: 25%;

Remember that changing the live-version of the theme is a bad idea, as the changes can get overwritten by theme updates. I changed it in my child-theme instead.

I’m pretty sure this breaks a bunch of conventions that were used in the development of the theme (I hated changing the specific -29.04761904% to a generic -25%) , but it works for now, and that’s what matters. I couldn’t find the correct place to post theme-related bugs to WordPress, so have posted it here for posterity. I will probably have a look at fixing this more cleanly soon, as I suspect there is a quicker fix that I’m not seeing. Especially as this doesn’t seem a problem on Firefox. z-index maybe?