The goal of a “responsive images” solution is to deliver images optimized for the end user’s context, rather than serving the largest potentially necessary image to everyone. Unfortunately, this hasn’t been quite so simple in practice as it is in theory.

Recently, all of the ongoing discussion around responsive images just got real: a solution is currently being discussed with the WHATWG. And we’re in the thick of it now: we’re throwing around references to picture and img set; making vague references to polyfills and hinting at “use cases” as though developers everywhere are following every missive on the topic. That’s a lot to parse through, especially if you’re only tuning in now—during the final seconds of the game.

The markup pattern that gets selected stands to have a tremendous influence on how developers build websites in the future. Not just responsive or adaptive websites, either. All websites.

What a long, strange, etc.

Let’s go over the path that led us here one more time, with feeling:

The earliest discussion of responsive images came about—predictably enough—framed in the context of responsive web design. A full-bleed image in a flexible container requires an image large enough to cover the widest possible display size. An image designed to span a container two thousand pixels wide at its largest means serving an image at least two thousand pixels wide. Scaling that image down to suit a smaller display is a trivial matter in CSS, but the requested image size remains the same—and the smaller the screen, the better the chance that bandwidth is at a premium.

It’s clear that developers’ best efforts to mitigate these wasteful requests were all doomed to fall short—and not for lack of talent or effort. Some of the greatest minds in the mobile web—and web development in general, really—had come together in an effort to solve this problem. I was also there, for some reason.

I covered early efforts in my previous ALA article, so I’ll spare everyone the gruesome details here. The bottom line is that we can’t hack our way out of this one. The problem remains clear, however, and it needs to be solved—but we can’t do it with the technologies at our disposal now. We need something new.

Those of us working on the issue formed the Responsive Images Community Group (RICG) to facilitate conversations with standards bodies and browser representatives.

“W3C has created Community Groups and Business Groups so that developers, designers, and anyone passionate about the Web has a place to have discussions and publish documents.”
—http://www.w3.org/community/

Unfortunately, we were laboring under the impression that Community Groups shared a deeper inherent connection with the standards bodies than it actually does. When the WHATWG proposed a solution last week, many of the people involved in that discussion hadn’t participated in the RICG. In fact, some key decision makers hadn’t so much as heard of it.

Proposed markup patterns

The pattern currently proposed by the WHATWG is a new set attribute on the img element. As best I can tell from the description, this markup is intended to solve two very specific issues: an equivalent to ‘min-width’ media queries in the ’600w 200h’ parts of the string, and pixel density in the ’1x’/’2x’ parts of the string.

The proposed syntax is:

<img src="face-600-200@1.jpg" alt="" set="face-600-200@1.jpg 600w 200h 1x, 

face-600-200@2.jpg 600w 200h 2x, face-icon.png 200w 200h"> 

I have some concerns around this new syntax, but I’ll get to that in a bit.

The markup pattern proposed earlier by the RICG (the community group I’m part of) aims to use the inherent flexibility of media queries to determine the most appropriate asset for a user’s browsing context. It also uses behavior already specced for use on the video element—in the way of mediaattributes—so that conditional loading of media sources follows a predictable and consistent pattern.

That markup is as follows:

<picture alt=""> <source src="mobile.jpg" /> <source src="large.jpg" media="min-width: 600px" /> 

<source src="large_1.5x-res.jpg" media="min-width: 600px, » min-device-pixel-ratio: 1.5" /> 

<img src="mobile.jpg" /> </picture> 

Via Github, this pattern has been codified in something as close to a specas I could manage, for the sake of having all the key implementation details in one place.

Polyfills

So far, two polyfills exist to bring the RICG’s proposed picture functionality to older browsers: Scott Jehl’s Picturefill and Abban Dunne’s jQuery Picture.

To my knowledge, there are currently no polyfills for the WHATWG’s newly proposed img set pattern. It’s worth noting that a polyfill for any solution relying on the img tag will likely suffer from the same issues we encountered when we tried to implement a custom ”responsive images” solution in the past.

Fortunately, both patterns provide a reliable fallback if the new functionality isn’t natively supported and no polyfill has been applied: img set using the image’s original src, and picture using the same fallback pattern proven by the video tag. When the new element is recognized, the fallback content provided within the element is ignored—for example, a Flash-based video in the case of the video tag, and an img tag in the above picture example.

Differing proposals

Participants in the WHATWG have stated on the public mailing list and via the #WHATWG IRC channel that browser representatives prefer the img set pattern, which is an important consideration during these conversations. Most members of the WHATWG are representatives of major browsers, so they understand the browser side better than anyone.

On the other hand, the web developer community has strongly advocatedfor the picture markup pattern. Many developers familiar with this subject have stated—in no uncertain terms that the img set syntax is at best unfamiliar—and at worst completely indecipherable. I can’t recall seeing this kind of unity among the community around any web standards discussion in the past—and in a conversation about markup semantics, no less!

We’re on the same team

While the WHATWG’s preferences, and the web developer community’s differing preferences, certainly should be considered as we finalize a standard solution to the problem of responsive images, our highest priority must remain providing a clear benefit to our users: the needs of the user trump convenience for web developers and browser developers alike.

For that reason (for the sake of those who use the web), it’s critical not to cast these discussions as “us vs. them.” Standards representatives, browser representatives, and developers are all partners in this endeavor. We all serve a higher goal: to make the web accessible, usable, and delightful for all. Whatever their stance on img set or picture, I’m certain everyone involved is working toward a common goal, and we all agree that a ”highest common denominator” approach is indefensible. We simply cannot serve massive, high-resolution images indiscriminately. Their potential cost to our users is too great—especially considering the tens of thousands of users in developing countries who pay for every additional kilobyte they consume, but will see no benefit to the huge file they’ve downloaded.

That said, I have some major issues with the img set syntax, at least in its present incarnation:

1. USE CASES

Use cases are a list of potential applications for the markup patterns, the problems that they stand to solve, and the benefits.

I’ve published a list of use cases for the picture element on the WHATWG wiki. It is by no means exhaustive, as picture can deliver an image source based on any combination of media queries. The most common use cases are screen size and resolution, for certain, but it could extend as far as serving a layout-appropriate image source for display on screen, but a high-resolution version for printing—all on the same page, without any additional scripting.

At present, no list of use cases has been published for img set. We’ve been working under the assumption, based on conversations on the WHATWG list and in the WHATWG IRC channel, that img set covers two uses specifically: serving high-resolution images to high-resolution screens, and functionality similar to min-width media queries in the way of the 600wstrings.

It’s vital that we have a way to take advantage of new techniques for detecting client-side capabilities as they become available to us, and thepicture element gives us a solid foundation to build upon—as media queries evolve over time, we could find ourselves with countless ways to tailor asset delivery.

We may have that same foundation in the img tag as well, but in a inevitably fragmented way.

2. MARGIN FOR ERROR

I don’t mind saying that the img set markup is inscrutable. It’s a markup pattern unlike anything seen before in either HTML or CSS. This goes well beyond author preference. An unfamiliar syntax will inevitably lead to authorship errors, in which our end users will be the losers.

As I said on the WHATWG mailing list, however, given a completely foreign and somewhat puzzling new syntax, I think it’s far more likely we’ll see the following:

 <img src="face-600-200@1.jpeg" alt="" set="face-600-200@1.jpeg 600w 1x, 

face-600-200@2.jpeg 600w 2x, face-icon.png 200w"> 

Become:

 <img src="face-600-200@1.jpeg" alt="" set="face-600-200@1.jpeg 600 1x, 

face-600-200@2.jpeg 600 2x, face-icon.png 200"> 

Or:

 <img src="face-600-200@1.jpeg" alt="" set="face-600-200@1.jpeg, 

600w 1x face-600-200@2.jpeg 600w 2x, face-icon.png 200w"> 

Regardless of how gracefully these errors should fail, I’m confident this is a “spot the differences” game very few developers will be excited to play.

I don’t claim to be any smarter than the average developer, but I am speaking as a core contributor to jQuery Mobile and from my experiences working on the responsive BostonGlobe.com site: tailoring assets for client capabilities is kind of my thing. To be perfectly honest, I still don’t understand the proposed behavior fully.

I would hate to think that we could be paving the way for countless errors just because img set is easier to implement in browsers. Implementation on the browser side takes place once; authoring will take place thousands of times. And according to the design principles of HTML5 itself, author needs must take precedence over browser maker needs. Not to mention those other HTML5 design principles: solve real problems, pave the cowpaths, support existing content, and avoid needless complexity.

Avoid needless complexity

Authors should not be burdened with additional complexity. If implemented,img set stands to introduce countless points of failure—and, at worst, something so indecipherable that authors will simply avoid it.

I’m sure no one is going to defend to the death the idea that the video andaudio tags are paragons of efficient markup, but they work. For better or worse: the precedents they’ve set are here to stay. Pave the cowpaths.This is how HTML5 handles rich media with conditional sources, and authors are already familiar with these markup patterns. The potential costs of deviation far outweigh the immediate benefit to implementors.

Any improvements to client-side asset delivery should apply universally. By introducing a completely disparate system to determine which assets should be delivered to the client, improvements may well have to be made twice to suit two systems: once to suit the familiar media attribute used by videotags, and once to suit the img tag alone. This could leave implementors maintaining two codebases that effectively serve the same purpose, while authors learn two different methods for every advancement made. That sounds like the world before web standards, not the new, rational world standards are supposed to support.

The rationale that dare not speak its name

It’s hard to imagine why there’s been such a vehement defense of the img set markup. The picture element provides a wider number of potential use cases, has two functional polyfills today (while an efficient polyfill may not even be possible with the ‘img set’ pattern), and has seen an unprecedented level of support from the developer community.

img set is the pattern preferred by implementors on the browser side, and while that is certainly a key factor, it doesn’t justify a deficient solution. My concern is that the unspoken argument against picture on the WHATWG mailing list has been that it wasn’t invented there. My fear is that the consequences of that entrenched philosophy may fall to our users. It is they who will suffer when our sites fail (or when developers, unable to understand the WHATWG’s challenging syntax, simply force all users to download huge image files).

WE THE PEOPLE WHO MAKE WEBSITES

I’ll be honest: for me, no small part of this is about ensuring that we designers and developers have a voice in the standards process. The work that the developer community has put into the picture element solution is unprecedented, and I can only hope that it marks the start of a long and mutually beneficial relationship between we authors and the standards bodies—tumultuous though that start may be.

If you feel strongly about this topic, I encourage all designers and developers to join the WHATWG mailing list and IRC channel to participate in the ongoing conversation.

We developers should—and can—be partners in the creation of new standards. Lend your voices to this discussion, and to others like it in the future. The web will be better for it.

@AnnieCushing
Annie Cushing@mattcutts Someone actually asked that? 6 days ago via TweetDeck ·  Reply ·  Retweet ·  Favorite · powered by @socialditto

@mattcutts
Matt Cutts@AnnieCushing *shrug* I can’t help what people ask.  5 days ago via web ·  Reply ·  Retweet ·  Favorite · powered by @socialditto

The first banner ad ever, on HotWired in 1994, debuted with a clickthrough rate of 78% (thanks @ottotimmons)

First it works, and then it doesn’t
After months of iterating on different marketing strategies, you finally find something that works. However, the moment you start to scale it, the effectiveness of your marketing grinds to a halt. Sound familiar?

Welcome to the Law of Shitty Clickthroughs:

Over time, all marketing strategies result in shitty clickthrough rates.

Here’s a real example – let’s compare the average clickthrough rates of banner ads when debuted on HotWired in 1994 versus Facebook in 2011:

• HotWired CTR, 1994: 78%
• Facebook CTR, 2011: 0.05%

That’s a 1500X difference. While there are many factors that influence this difference, the basic premise is sound – the clickthrough rates of banner ads, email invites, and many other marketing channels on the web have decayed every year since they were invented.

Here’s another channel, which is email open rates over time, according to eMarketer:

While this graph shows a decline, the other graph (which I don’t have handy) is that the number of emails sent out has increased up to 30+ billion per day.

All these channels are decaying over time, and what’s saving us is the new marketing channels are constantly getting unveiled, too. These new channels offer high performance, because of a lack of competition, big opportunities for novel marketing techniques, and these days, the cutting edge is about optimizing your mobile notifications, not your banner placements.

There are a few drivers for the Law of Shitty Clickthroughs, and here’s a summary of the top ones:

• Customers respond to novelty, which inevitably fades
• First-to-market never lasts
• More scale means less qualified customers

Novelty
Without a doubt, one of the key drivers of engagement for marketing is that customers respond to novelty. When HotWired showed banner ads for the first time in history, people clicked just to check out the experience. Same for being the first web product to email people invites to a website – it works for a while, until your customers get used to the effect, and start ignoring it.

One of the most important tools you have at your disposal is the creative and calls to action that you use in your marketing – this might be like “X has invited you to Y” or it might be the headline you use in your banner ads. Recently, Retargeter posted an interesting analysis on the Importance of Rotating Creatives, which showed how keeping the same ad creative led to declining CTRs over time:

Publishers often have a similar problem in consumers ignoring the advertising on their site, which drives down clickthrough rates for both of them (bad for CPMs). This problem is often described as banner blindness, and you can see it clearly here in an eye-tracking study by Jakob Nielsen:

You can see here how users, almost comically, avoid looking at any banners.

The point is, humans seek novelty yet are pattern-recognition machines. Your initial marketing strategy will work quite well as your users try it for the first time, but afterwards, they learn to filter your marketing efforts out unless they are genuinely useful (more on that later).

First-to-market never lasts
It’s bad enough that your own marketing efforts drive down channel performance, but usually once your marketing efforts are working, your competitors quickly follow. There’s a whole cottage industry of companies that provide competitive research in the area of how their competitors are advertising and give you the information needed to fast-follow their marketing efforts.

For example, with a quick query, I know how much Airbnb is spending on search marketing (turns out, millions per year) what keywords they are buying ads on, and who their competitors are. And this is just a free service! There are much more sophisticated products for every established marketing channel:

Airbnb Search Engine Marketing

• Daily ad budget: $10,638
• Keywords: 62,729
• Example ad: Find Affordable Rooms Starting From $20/Day. Browse & Book Online Now!
• Main competitors: Expedia.com, booking.com, hotels.com, Marriott.com

Any clone of their business can quickly fast-follow their marketing efforts and use the same ads in the same marketing channels. This quickly degrades the performance of the marketing channel as the novelty wears off and clickthroughs plummet.

Any product that is first to market has a limited window where they will enjoy unnaturally high marketing performance, until the competition enters, in which case everyone’s marketing efforts will degrade.

More scale means less qualified customers
Another important way to think about the available market for your product is in terms of the popular Technology Adoption Lifecycle, in which early adopters actively seek out your product, while the rest of the mainstream market needs a lot of convincing. The quant marketing way to look at this is that early adopters respond better to marketing efforts across any given metric (signup %, CTR, CPA) than the later customer segments. In the TAL framework, the early market seeks out novelty, whereas the mainstream market just cares if you solve a problem for them.

As a result, a marketing strategy focused on early adopters is bound to look better than what you get later. You can get some limited traffic from PR and targeted advertising from niche communities and media properties. However once you get past this group, the CTRs can drop substantially.

If you’re a SaaS or ecommerce company that’s road-tested your marketing strategy by acquiring limited batches of customers, the problem is that whatever assumptions and projections you make off of this base end up fundamentally skewed positive. If your model indicates that you can acquire customers at $10 and break even within 6 months, it’s not hard for a 30% increase in CAC and 30% decrease in LTV to double the time it takes to get to profitability. This could be the difference between life and death for a company.

Lesson to investors is: Beware marketing metrics done at a small scale, and beware marketing tech companies that facilitate momentary marketing opportunities without a bigger vision. These are arbitrage opportunities that will disappear over time.

How to fight the Law of Shitty Clickthroughs
I call it a Law, of course, because I really believe it’s a strong gravitational pull on all marketing on the web. You can’t avoid it, and in many ways, it’s counter productive to try.

You can always get incrementally better performance out of your marketing by taking a nomad strategy – always keep developing new creative, testing new publishers, and so on. That’s all easy, but is mostly about maintaining some base level of performance. This can push the Law of Shitty Clickthroughs to act over years rather than degrading your marketing efforts over months.

Similarly, this law provides a litmus test as to the difference between advertising and information. When you are marketing with useful information, then CTRs stay high. Advertising that’s just novelty and noise wrapped in a new marketing channel has a limited shelf life.

The real solution: Discover the next untapped marketing channel
The 10X solution to solving the Law of Shitty Clickthroughs, even momentarily, is to discovery the next untapped marketing channel. In addition to doubling down on traditional forms of online advertising like banners, search, and email, it’s important to work hard to get to the next marketing channel while it’s uncontested.

Sometimes I get asked “have you ever seen someone do XYZ to acquire customers?” Turns out, the highest vote of confidence I can give is, “No I haven’t, and that’s good – that means there’s a higher chance of it working. You should try it.”

Today, these (relatively) uncontested marketing channels are Open Graph, mobile notifications, etc. If you can make these channels work with a strong product behind it, then great. Chances are, you’ll enjoy a few months if not a few years of strong marketing performance before they too, slowly succumb.