This summer I read Ethan Marcotte’s Responsive Web Design—the latest from A Book Apart—with fervor. I’d been hearing bits and pieces about this newfangled approach for a while, but I was anxious to understand it better…and, of course, to figure out if and how content should play a role.
While most of the book was outside my direct skill set (I’ll take my ridiculous tiny sticker now, Erin Kissane), I can assure you of two things:
- This shit is fascinating.
- It will also require a tremendous shift for people who care about content (read: you).
So let’s get to work, shall we?
But first, some background
Responsive design, as Ethan explains it, uses flexible grids and media queries to create experiences that reshape to best work within the display constraints of a user’s device, whether that’s a smartphone, tablet, laptop, mega-monitor or whatever other device tech nerds are lining up to buy next.
Not sure what this means, precisely? That’s cool. My grasp of the code behind the design is tenuous at best, but that’s not the point. Responsive is about asking a device what it is, and responding in a way that, in theory, makes the site experience more useful and pleasurable for that user.
Its roots can be found in places like Luke Wroblewski’s “mobile first” approach, the grid layouts popularized by folks like Mark Boulton and Khoi Vinh, and ideas about progressive enhancement (none of which I will tackle here, given my lack of expertise and the plethora of better sources). But in sum, these approaches all point toward a single goal: building web products that deliver the best possible user experience possible, regardless of device.
Great, but I’m a content strategist. Last time I coded shit more complicated than switching from WYSIWYG to HTML in a content management system, I was customizing the fonts on my MySpace page (ain’t too proud to admit it, either). So why do I find all this so damn fascinating? Because thinking responsively isn’t just about learning a new way to design or code; it’s about embracing a new way of thinking about the things we make, as Zeldman pointed out recently:
It may be an even bigger idea than we initially realized—an idea too big to be limited to a single, technical approach to the problem of multiple, disparate viewing environments…The purpose behind “responsive design”—the concept of what it strives to achieve—should be separated from the specific techniques used to achieve it.
Flexible grids and media queries may be the technical bits Ethan and other designers testing these waters are using to make responsive design possible today. But they’re just a means to an end—an end that content folks should and must be actively working toward, because it helps us, too.
My mobile discontent
So how can responsive design improve content? Let’s start by removing the need to make tough, and potentially bad, choices about what stays and what goes when a site is viewed on a smaller-resolution device.
I’ve long accepted the need for mobile redirects—those pesky m.someaddress.com URLs and the like—you get sent to instead of the “real thing” on many sites. After all, we can’t redesign a big corporate site to be mobile-friendly overnight, and we can’t always make complex functions work well on small screen sizes. But as a content strategist, they always made me wonder: what information am I missing? What does the full site have that I don’t get? How can I get the hell out of here and read the thing I came here to read?
Mobile versions of sites aren’t wrong, per se. But they often force us to make decisions about content based on assumption, rather than knowledge. Assumptions like “mobile users are on the go,” something countless couch-lounging couples ending a debate via Wikipedia would heartily disagree with.
Responsive design moves us a step closer to solving this problem by placing fewer artificial limits on a user’s access to information and functionality—ensuring the content he came for is available and usable, wherever he is.
Similarly, many websites look like shit (yes, that’s the technical term) when displayed at very small or very large sizes. Perhaps even worse, they often read like shit. Put everything up on a big screen and line lengths become unwieldy and hard to follow. Trim them down to skinny little smartphone size and you’re zooming and squinting to see anything at all.
In contrast, responsive design considers the device size in how it lays out text, attempting to keep line lengths readable and approachable, font weighting appropriate for its purpose (headline, subhead, etc.), and overall allowing content to be displayed in a way that aids meaning.
A job for content strategy
It’d be easy to leave this trend to designers and developers. But content strategists and others who care about content still have a big job to do in making responsive design possible. After all, it’s rather hard to know how each element associated with a piece of content should respond to changes in display unless you know what that piece of content is intended to do.
Understanding content structure is relatively easy on a blog, where you are primarily dealing with one type of content—blog posts, which tend to be well defined already: headline, maybe a teaser, date line, author, body copy, tags, related items.
But let’s say you want to make a huge corporate site responsive. Or a university. Or a big publisher, like Ethan’s been working on for the Boston Globe. This ain’t the Bot Blog anymore; it’s a big mess of content types and relationships and structures. A designer left alone can’t possibly know how all of these pieces should respond to device capabilities while retaining relevance and context.
How do we make smart decisions about things like relative font sizing for different content elements? What content elements can be moved around—pushed below, moved above, etc.—to suit different device needs? These are questions content strategists can start to answer. But if we want to answer them well, we better start taking a hard look at how we structure information, as Stephen Hay’s recent presentation “Structured Content First” explains:
The device landscape is constantly changing. Capabilities are constantly changing. Properly structured content is portable to future platforms.
Preparing for tomorrow
The future! Spaceships! Robots! Structures! It’s exciting stuff, and maybe a bit overwhelming, too. But don’t let that stop you from getting started. Because whether Ethan’s approach is The Way, a way, or just a stop along the way, we can be sure that content has to be ready for a future that’s less fixed, more shifting, more capable of change. We have to make content that endures—that lives through those shifts, not loses its meaning.
You may still be cleaning up after the content horrors of the past: auditing old sites, filling gaps, creating style guides, editing. And don’t stop that work, by any means. But while you’re in there, digging through the ROT, you can start preparing your content for the future now.
Karen McGrane touched on this the other day in a Content Talks podcast, just as I was about to finish this post off—and just in time to throw a wrench into this topic with her super-smart take:
This is not about having something that looks like Microsoft Word. This is about you creating content that might appear formatted in different ways, structured in different ways, on lots of different platforms. You have to be able to start thinking in systems… Mobile is going to be a really helpful wedge there, because you just see the panic on people’s faces where they’re like, what do you mean, I have to support the iPhone and Android and Blackberry and the tablet…and is this ever going to get better?
No, it’s going to get worse; there’s going to be even more platforms and even more competing standards. The only way we’re ever going to be able to support all those things if we have a reusable content store that is flexible and intelligent and nimble.
Intelligent and nimble, but not new
As Karen alludes to during the podcast, structured, smart content isn’t new—it’s something folks interested in setting content free, like Rachel Lovinger, have been talking about for a long time, particularly in Razorfish’s Nimble Report, put out last year:
When elements of content and data are well defined in a content management system, they can be marked up with tags that provide more meaning than HTML. Instead of “dumb” tags like <h2>, that just define the way the information should be displayed, these tags give meaning and importance to the information contained within… It might even deconstruct a long-form political scandal into segments for different services—the tweet tease, the short form for mobile phones, the slide show for a tablet device, and so on.
It even goes back earlier—to folks like Ann Rockley, who’s been talking about this subject under the label “intelligent content” for years. But while these sentiments may not be new, I think the difficulties posed by the emergence of mobile—and the possibilities brought to us by responsive design—will finally bring them to the forefront and force us all to deal with them. And soon.
Wait, THIS is my job now, too?
Yes. By using our understanding of content at the micro level—the understanding gleaned from countless time spent auditing and editing—we are primed to take an active role in developing content structures: creating stronger database attributes and metadata schema, more “atomized” content, better tagging and relationship-making systems, and the like. This, in turn, will set the stage for future-proofing and freeing our content, breaking it down into clearly defined and semantically rich pieces that can be remixed and transported more easily, wherever they need to go.
If this sounds more like information architecture than content strategy, you’re not wrong, exactly. IAs need to be all up on this, too. But I’d argue these decisions are best made when someone intimately familiar with the content on a message and meaning level is in the room as well.
Margot Bloomstein, whose work focuses more on this brand side of CS, said it to me well just last night:
We need to understand context *and* communication goals so as to determine the rules by which to filter. Content that is deemed supporting and tertiary under one message architecture might be considered the primary point of interest under another message architecture…I think we have to start at the point of communication goals and the message architecture, before we start developing rules and attaching semantic attributes.
This doesn’t mean the IA/UX crowd isn’t critical to solving these problems. But, if you’re the one wallowing in real content all day, it does mean you’re a necessary piece as well—even if you’re more comfortable talking message than metadata.
Content strategy, this is your party, too. Time to répondez, s’il vous plait.