While I still think the business challenges are the greater obstacle, the technical challenges are interesting and beg for experimentation.  I couldn’t help from spending a few hours toying with possible solutions. Here are two demos.

Responsive HTML ad

My first idea was to build an HTML ad that could shift itself into 3 different standard IAB sizes: 728×90, 300×250, and 300×50. So I designed a mock Foursquare ad with HTML and CSS, using media queries to define break points at 500px and 728px. The two images in the ad are served as data URIs which means the ad has no external resources outside the HTML document. The file size is 36K, comfortably within standard max file sizes for ads.

This works in latest versions of Chrome, Safari, Firefox, and Opera. Maybe/Probably works in IE9. Drag your window around to see it go. You can view the standalone ad here.

Responsive HTML ad using a JavaScript interface

This one is based on the same idea but does two things differently. One, instead of the ads being built with HTML, each ad is simply a static image. And two, instead of embedding the responsive logic in media queries I’ve added a JavaScript interface, the configuration portion of which looks like this:

// Ad config
var ads = {
  leaderboard: {
    width: 728,
    height: 90,
    breakpoint: false,
    url: '728x90.png'
  },
  rectangle: {
    width: 300,
    height: 250,
    breakpoint: 728,
    url: '300x250.png'
  },
  mobile: {
    width: 300,
    height: 50,
    breakpoint: 500 ,
    url: '300x50.png'
  }       
};

This lets you define your responsive campaign with some settings and then the JavaScript does the rest. Note, this uses the window.matchMedia method, which currently is only available in Chrome, Firefox, and Safari (but Paul Irish has a polyfill that can extend support to other browsers).

This works in latest versions of Chrome, Safari, and Firefox. Drag your window around to see it go. You can view the standalone ad here.

Coda

Granted these demos are only static ads and they don’t address some of the bigger problems, like rich media and ad server implementation. But still I think the general technique around building responsive campaigns at the design/HTML/CSS/JavaScript level is not that difficult to execute. The real challenge is defining a common implementation that works for everyone involved — for advertisers, agencies, publishers, and ad servers.

Mark followed up with a great blog post that detailed many of the obstacles and offered ideas about how to move forward. I wanted to respond with a few thoughts.

Quick background on why you might care at all about my opinion on this: I’ve spent the last 5 years working daily and closely on advertising-supported sites, working in a range of areas from product design, to front-end coding, to ad ops, to content strategy, to sales strategy. I’ve debugged tangled 3rd party ad server scripts and I’ve sat on calls with advertisers to try and explain why the “fold” does not exist. Many times.

TV on the Web

Mark talks about the problem that ads are sold as fixed “slots” on a page. For example, an advertiser buys the top leaderboard slot, which has a fixed size of 728×90 and a static placement indicated clearly in the media kit (above the fold, win!). This of course poses a problem for responsive design — what happens to the leaderboard when the screen shrinks below 728px?

What he didn’t mention is that this sales model is mostly inherited from sales models for other media, and, more importantly, that most people buying and selling web have strong backgrounds in buying/selling those other media types.

Whether you’re buying a print, television, or radio ad, you’re buying something of a fixed size or duration with a specific guarantee about placement. It’s a simple, familiar model. Parties on both sides of the sale are comfortable with it. Simplicity is key.

What this means is that sales teams often end up selling other media types (print, especially) on the web instead of selling the web. The mental model is reused, some of the vocabulary overlaps (the “fold”). My point is that it’s tough to move beyond this when so much of the process is still grounded in the past.

Responsive design has a business problem (maybe)

The business case for responsive design is usually centered on a variation of the old “Write Once Publish Everywhere” pitch: instead of building and maintaining multiple sites for multiple devices, we build one site that can adapt to multiple devices. It’s a great solution to a technical problem.

The cost-saving implications are obviously attractive from a business standpoint, but the concept is actually at odds with a higher-level business goal, which is to leverage and extend brands and products into other products.

Desktop, tablet, and mobile experiences have the potential to be marketed as distinct products aimed at different media budgets. But only if the products are somewhat differentiated. Homogenizing into a single unified, adaptable experience — for all its technical and usability benefits — may be undesirable from an inventory perspective. If you’re a salesperson for a print product would you rather be able to offer a client two products or four?

That’s not to say that a responsive design couldn’t be used to produce distinct mobile and tablet offerings. Or that revenue from a combined multi-device package couldn’t offset potential revenue from separate products.

Where things stand today

Mark proposed some great ideas about responsive ad units and multi-unit packages. I’m sure we’ll see these ideas materialize in the marketplace soon but I think Mark (and @kerns) are right that it won’t happen until there’s demand.

So until the market responds to responsive design, what are our options? If your site’s revenue is dependent on advertising you most likely have few if any. Think about it. Your constraint is the width of the widest ad unit. Even if your site only has a 300×250 unit (uncommon), how do you know that you won’t need to support other units in the future?

Say your site has a 728×90 leaderboard and a 300×250 rectangle. Well, you could make a site that’s responsive from 728px (iPad portrait width) up to a 1200px+ widescreen display. Cool. But what if Sales wants to add a 970px-wide Pushdown unit to the site? Now the bottom end of your responsive spectrum is 970px. At that point, is the extra work associated with a responsive layout even worth it?

I’m not aware of any other realistic options. You can’t just hide ads when the screen gets smaller. And ad delivery logic is heavily tied to the server (i.e., it would be difficult, sometimes impossible, to request ads based on client-side properties like screen size).

…but maybe you have some other ideas?

Update 11/17/11: Mark’s article has kicked off a lot of great discussion around this topic. If you’re interested in this topic don’t miss:

• Google+ discussion thread
• André Luís’s blog post
• Nathan Ford’s blog post

Despite all the CSS fun, a lot of design still happens in the static, pixel-based world of Photoshop. Responsive designs often begin as Photoshop comps. If we want to start with a grid, we need to start with a grid in Photoshop.

When designing for recurrent conditions, it’s nice to have some sort of boilerplate or template that can kickstart the process and save you from repeating yourself. If you’re designing a desktop site, there are a few projects, like the 960 Grid System, that offer helpful grid templates for Photoshop and Illustrator.

But what if you’re designing for mobile? Or for an iPad? For email? For a widescreen monitor? Then you’re on your own. I have searched and I haven’t found any templates for graphic editors concerned with multi-device design. So I made some.

Photoshop Grids is a small collection of grid templates for various devices and common design scenarios. The templates are simply PSD files containing guides and overlays that define a columnar grid. There are templates for mobile, iPad (both orientations), email, and several desktop cases (including widescreen and IAB-300×250-friendly).

To be clear, I’m not suggesting that anyone should produce static designs for each of these experiences. Responsive design is the way to go (when possible). But depending on the project you may want to build your initial design around something other than a standard 960px desktop layout. Mobile first, tablet first, etc.

For more details or to download the templates, check out the Project Page.

If you have feedback or would like to contribute, hop over to GitHub. (Or just leave a comment below.)

To appreciate the historical significance of the work, you have to understand that in Bach’s day the notion that one could or should play keyboard music in all keys was unorthodox. It was not a matter of philosophy, but of physics — a fixed pitch keyboard instrument could only be in tune with a selection of keys at a time. In the tuning systems of the time it was simply not possible to play in tune in all 12 major keys.

While the laws of physics can be tough to bend, human perception moves fairly easily. The solution was to redefine what it meant to be “in tune”. By adjusting certain intervals so that they deviated just slightly from perfect intonation, a tuning system was produced that allowed one to play reasonably in tune in all keys. This business of compromising granular qualities for the greater good of the system is called temperament.

The name of the alternative tuning system made famous by Bach and the Well-Tempered Clavier is, unsurprisingly, “well temperament”. Today, most intonation in Western Music is based on “equal temperament”. The methods are different but the goal is the same: to make each of the keys slightly imperfect so that all of the keys can be used. It’s like utilitarianism for acoustics.

What this has to do with UI design

Probably the most exciting development in web design in the last 5 years has been the shift to designing for multiple devices. It’s no longer just about how a web site functions in two different browsers but about how it functions on various devices with completely different characteristics — different screen sizes, different use contexts, different interfaces.

Although responsive design and device-specific sites allow us to tailor designs for diverse experiences, there will be times when we have to make universal decisions, and when we do, I think the idea of well temperament can be a useful metaphor.

The application of the concept to UI design is simple. In order to serve a good experience to a range of devices we have to allow for occasional imperfections in individual interfaces.

A common example of well temperament in action is the effect that touch interfaces have had on recent desktop site designs. As a pointing device, a finger, being much larger than a mouse, requires larger touch targets. Interactive elements need to be bigger. Then other things need to be bigger to balance the interactive elements. Eventually touch design becomes associated with an aesthetic that starts to leak into standard desktop design.

(The iPad, bridging the gap between touch interfaces and desktop screen sizes, has accelerated the touch influence on desktop design. Things on the web are starting to appear chunkier… more padding, more whitespace [new Gmail, hello?].)

What we end up with is a design that might afford too much space for a mouse, but an appropriate amount of space for a finger. We allow for a slight deviation from the norm in one experience in order to better support all possible experiences.

Beware of Wolves

In the natural tuning systems that predated the popularity of well/equal temperament, the notes of the out-of-tune intervals played simultaneously produced a harsh, howling sound. Musicians had a great name for this. They called it a wolf.

Applying this idea to interface design, we can think of a wolf as a visual or interactive element designed for one experience that fails to some degree when transposed to another experience. Think of the times you’ve struggled to finger tap a small link that was made for a mouse cursor, or had to read tiny text on a mobile screen, or, using a touch device, used an interface that relied on hover states. Wolves in the UI.

Yeah, but

Again, it’s true that responsive design and device-specific experiences offer us a way around most of these problems. If we can tune the size of a button to a specific context we don’t have to accept a blunt, across-the-board treatment. But the number of devices we have to support will only increase and customizing for every possible scenario may quickly become unreasonable.

Even if we are able to provide perfect tailored design at the execution level, I still believe there’s value in thinking about tempered, universally accessible design at the conceptual level.

Also, just because we can designate design for particular experiences doesn’t mean that users will not carry expectations over from one experience to another. The boundaries may get blurred whether we like it or not.

In the end…

Bach thought that people should be able to write and play in any key they liked. He argued for it by writing beautiful music that compelled the world to agree. He designed for the system he wanted.

We want our users to have great experiences with our sites and applications on any device they choose. We want our work to be as accessible as possible.

What are you going to design?

While there’s nothing necessarily profound about either of these claims, my experience working in publishing tells me that they merit emphasis. And for editors with strong print backgrounds who are still transitioning to the web, I expect some of these concepts will be new.

(Note: Although this is mostly aimed at people working in an editor role, I think a lot of the concepts apply to the broader category of anyone responsible for producing content online. I’m using the term “editor” loosely to refer to this larger category.)

(Update 10/27/11: Originally this was going to be split over two posts but when I sat down to the write the second part it seemed better to merge them into one post. Jump to the Feedback Loops section for the new stuff.)

What your browser should look like

Throughout the day you may have dozens of different web pages open, but there’s a set of pages that I believe online editors want to have open at all times. At its base state your browser should look something like this:

Here we have tabs for:

• Content: document management (e.g., Google Documents)
• Publishing: CMS (e.g., WordPress)
• Discovery: feed reader (e.g., Google Reader)
• Reporting: site analytics (e.g., Google Analytics)
• Audience: social media (e.g., Twitter)

Of course different teams will have different tools suited for particular needs but let me try to explain why I believe each of these tabs addresses a core interest for online editors.

Documents
If you manage your documents online (with Google Documents, for instance) this is an obvious one. You probably spend a good portion of your day here, writing, editing, and volleying documents around with your team.

If instead you manage your documents offline this tab will not apply. Hopefully you have a nice, efficient offline workflow. If not, if you’re still emailing Word Docs back and forth, you may want to consider moving on up to the cloud. (For an interesting read on the subject, check out how the Bangor Daily News is using Google Documents.)

Publishing
If you publish/edit content directly to the web I’m going to assume that you more or less always have a tab open for your CMS.

Feeds
Staying up-to-the-moment with what’s happening elsewhere on the web is an important part of online publishing. This flow of information comes through various channels, and while there are numerous ways to keep up with it, I think you’ll find that the easiest solution is to use an RSS reader. (Google Reader comes highly recommended.)

Analytics
The thing I want to stress here is that if you’re an online editor, analytics should be an integral part of your daily workflow.  It’s not a daily or weekly email report, it’s not numbers that live in a spreadsheet, and it’s not the responsibility of some other department. It should be a tab (or two) that you have open at all times, just a click away.

Recognizing the importance of analytics is the first step but it only returns value if we learn how to extract meaning from the numbers and then apply that meaning to our content. To do that requires a strong understanding of analytics. We have to spend time with our analytics tools, learn what all the different terms really mean, learn how to connect the disparate dots. We have to build it into our daily workflow.

Social
There’s a mistake that I think a lot of people make when they think about social media. The mistake is to view social as a separate content channel instead of viewing it as a mode in which users experience your content. This is an important distinction. If you think of social in this way it argues for keeping social and content efforts close together. Keeping the two connected allows one to inform the other. It allows you to have feedback loops.

Why these five?

It’s likely that there are other apps and services that you use on a daily basis. Maybe something for comment moderation, or realtime analytics, or SEO keyword analysis. And maybe some or all of these fit into your daily work in a critical way.

What I’ve tried to do is define a set of tools that enable editors to meet the core requirements for publishing online. The set will be customized and augmented, but usually not subtracted from except in cases where certain tools do not apply (e.g., if you manage documents offline). In other words, these are the things that should apply to everyone and the things we can’t get by without.

I’d like to point out that the reason this collection of apps has been expressed as a set of browser tabs is to highlight their interconnectedness. Each one is a component to a larger system. It’s not enough to tweet, follow blogs, and keep an eye on pageviews; we have to connect these activities and make them meaningful to each other.

Feedback Loops

How do these applications interact with each other? For the most part in obvious ways. But I think there are some intricacies that appear in different stages.

Stage 1

This is the original model for publishing online: throw the print content up on the web and forget about it. Fortunately/hopefully, we’ve all moved past this by now.

Stage 2

In this scenario we might have content being pushed out through a social channel and general site analytics being observed, but the publishing process is still in broadcast mode. Everything is going out, nothing is coming in. We don’t have a feedback loop yet.

Stage 3

Here, by availing ourselves of analytics data and direct social feedback — sources of information not necessarily available to us in other mediums — we begin real web publishing. At this stage downstream activity works its way back up to inform what we write about. Content strategy, editorial calendars, and day-to-day publishing become responsive.

Stage 4

The difference between this and the previous stage may be a subtle one. Here, instead of responding to external forces we start using them as content sources. A discussion on Twitter may develop directly into an article (the Twitter dialogue itself may even BE the article). Facebook and Twitter might be used to survey readers. RSS feeds can provide material for curation and link posts.

Closing

While the ideas here are fairly basic I hope outlining them as I have in this post will help spread the good word. If you have any questions or comments, please leave a note below.