Last year, I spoke at New Adventures about A New Canon: three rules by which we can create modern websites. At the start of that talk, I spoke about responsive design. Not Responsive Web Design, as such, but the practice of responsive design more generally.

To summarise: responsive design is a design approach whereby a design system has three components: a sensor (a thing that senses stuff, whatever that may be); a design system (that takes the sensed data and applies system rules and logic); and then an actuator that actually does stuff that the design system tells it. A simple example of a responsive design system is your central heating in your house or apartment. A thermostat senses the temperature. Normally, this thermostat also has a bunch of programs in there (a design system) that tell the boiler (the actuator) to turn the heating on or off.

An understanding of this, and how it relates to web design –- and specifically at this time of responsive-adaptive-mobile-contentfirst-progressive time –- is useful for us. Why? Because responsive design is an emergent practice outside of the web –- notably in architecture, but also in environmental design and engineeering. And when things are so confused right now, semantics matter.

Responsive Content is not a thing

Recently, I’ve been hearing rumblings of content being talked about as responsive or adaptive – mostly in the mobile context. ‘If I’m near a thing, maybe the content on a website changes to tell me that’. That’s great! Of course, that would be useful. But it’s not the content that is adapting there. The content isn’t doing anything. It’s just static. The content is being controlled by a responsive design system. Let’s break it down:

  1. Sensor: In this case, it would be location. Something on your device is letting the web site or app know where you are.
  2. Design system: The logic in the code that takes the sensed location data and does stuff with it. This could be a CMS or some other type of publishing system.
  3. The Actuator: The code that tells the system to swap out the content for something that is of more value for you. This could be a bunch of technologies from server-side changes, or client-side.

Nowhere in that system is the content doing anything intelligent. It’s just existing in different forms and being pulled in based on the Design System’s rules. And that’s the thing.

Dumb(ish) content

For great responsive design systems, we need good output. The output that we’re lacking at the moment are the fragments of content that Karen McGrane talks about. Content that travels around with a set of rules or meta data that will allow responsive design systems to make good use of them. But this does not make this content responsive. On its own, it’s pretty dumb: just floating around with additional information attached to it, until some smart design system grabs it and displays in the right context.

I’ve been working with a news network for about eighteen months now on doing just this. And it is incredibly difficult to even come close to making it work. Why? Well, in a high pressured newsroom, it turns out that people don’t generally have the time to re-write the same story umpteen different times for different contexts and outputs. Let alone add the meta data differences to each one. And that’s just a process problem. What about the tech? What about the design?

I guess this is a post about being careful about tacking on trendy adjectives to a process that organisations have been trying to do – and generally failing – for a long time. We need to be careful about the services we sell to our clients and the industry in general.