Last year, at DrupalCon Chicago, the organizing team gave an update from the stage about the number of devices and attendees: the ratio between unique IP-address requesting devices to attendees was over 2:1 and approaching 3:1. The organizers asked, rhetorically: “Just how many devices do you guys need?”

Clay Shirky, who’s keynote began right after the update, delivered the answer (paraphrasing):

As every geek knows, the correct answer to that question is ALL OF THEM.

This year’s DrupalCon, in Denver, fulfills that prophecy, and not just in the sense that the device:attendee ratio may break 3 and head towards 4. It’s also the dominant theme of the whole show: Collaborative Publishing to Every Device.

Robert Douglass and Jeffrey McGuire’s opening session shortened the official tagline to this version for the tl;dr; crowd

The “collaborative publishing” bit should sound familiar to anyone who knows Drupal – the platform has from the beginning been focused on enabling communities in which large numbers of people create or interact with content: social plumbing. The “to every device” bit reflects the rise of Responsive Design: moving beyond the assumption that what we’re building are web applications which will be consumed on a desktop or laptop. Instead the responsive design philosophy assumes that nothing is known in advance about the device on which the site/application will be consumed, and makes and effort to respond appropriately to the device making the request, based on that device’s capabilities.

This means responding to different screen sizes (as well as pixel-density ratios) but also sensing the presence or absence of touch capability, and making an effort to not even send to the device images larger than the device can display. Working this way also forces a renewed sense of prioritization, as you start to eliminate, condense, linearize, and otherwise respond to the changing device capabilities. It’s no longer a question of what’s either on the “page” or off it, but a discussion about what remains, what rises to the top, what gets shuffled to auxiliary pages, and what just plain disappears on some devices. (Register for Connective DX’s upcoming webinar on “Building Future Friendly Experiences” for more on responsive design strategies and the role of mobile).

How Will Responsive Design Impact Content Management Systems?

For the most part, the discussion here at DrupalCon has been about the publishing part of responsive design: how from a technical implementation point of view you make your site’s theme responsive, or to what degree. I think, however, that there’s a danger here of putting the technology cart before the strategy horse (pardon the strained metaphor). It will be far easier to pull together HTML 5 Boilerplate, Modernizr, response.js, and an approach for adaptive images than it will be for most organizations to understand and internalize the content strategy decisions necessary to determine how various sites’ designs should adapt.



Should your content management system do something fundamental to support responsive design, or just stay out of the way and allow presentation templates to be responsive without specific action by content authors?

Should content authors be able to see (and potentially change) how a given page or content item will adapt, in order to create the ideal content presentation?

It’s clear that the momentum is toward responsive designs which leverage mobile-first style thinking and progressive enhancement. But we’re still only focusing on the publishing part of the problem.

How should the wire frames most design agencies still develop change to reflect responsive design? Where will you capture, from a business perspective, what features are accessible from which renderings?

How will you ensure your responsive design doesn’t inadvertently obscure functionality users find more important than you expect?

How will you regression test for responsive design as new features and templates are introduced? How many devices will you need to have in your testing lab (remember mind Clay Shirky’s answer above)?

Should the CMS platform’s preview mode emulate various devices, presenting a handful of common renderings for a given page content item?

Should the CMS simply offer a unique preview url (tokenized or otherwise made highly un-guessable) and put on the content author the task of viewing that URL on many devices?

Looking forward to seeing the conversation develop, especially as we try to connect the “Responsive Design” conversation with the “Web Experience Management” conversation. Can sites get smarter about personalization and content targeting at the same time as they get smarter about responding to different devices, and still result in an “easy to use” editorial experience?