Responsive Content: Re-architecting the Basic Page, Render API, etc.

conference: Drupalcon London 2011, London

Chocolate + Peanut Butter = Peanut butter cups, Ponies + Unicorns = Ponycorns

Until recently mobile development meant site builders had to build parallel solutions, either a mobile app or a mobile-only website.

But the past year has seen a fundamental shift in how we think about web sites. Responsive Design means that the front-end of a website can adapt to the varying screen sizes of devices from small cell phones to large 30" LCDs. Using media queries, JavaScript and smart CSS choices means front-end developers can continue to use a single HTML source for all screen sizes.

But this is not enough.

Leading mobile development leaders like Stephanie and Bryan Rieger, Jason Grigsby and Steve Souders know there are competing requirements for our new mobile world:

  • “One Web” means serving all devices using a single URL.
  • Performance is even more critical than normal, so serving images, CSS and other assets that aren't used by the client is a huge waste.
  • There are no such thing as a “mobile friendly CMS”.

Drupal handles structured data very well. But what about the “Basic Page” content type? Its usually a dumping ground for unstructured data, content that doesn't conform to a standard model that easily fits the concept of a “field”. Brochure-ware sites are actually really good examples of unstructured data.

To truly reach the One Web ideal, we need all our content to be responsive. Literally let the site builder change the way the content displays depending on the context. Which means we need Drupal to understand the semantic structure of our content, even when its all in one textarea.

We should be able to drop an image into a textarea and still know its an image and give it all the features it would have if it was a field.

How do we make Drupal understand the semantics of our content so that our content can be responsive?

Slides