Responsive-Ready Content

The nice folks at A List Apart published a piece from me last week called Future-Ready Content, which I wrote amid the fervor over future-friendly thinking and responsive web design last year—a fervor I both joined in and felt terrified of. Because no matter how exciting this flexible, unfixed future seemed, for months I couldn’t shake this little voice inside my head—the voice that said our content wasn’t ready.

But it can be, if we put in some work.

So today, I wanted to expand on the discussion around responsive design specifically, demonstrating why we need a foundation of content types, micro structures, and business rules if we want to keep priority, relationships, and meaning intact.

Content choreography

Paravel’s Trent Walton blogged about this concept last summer, and I’ve been thinking about it since. In the post, Walton questions whether the typical approach to narrowing screen sizes—simply plopping anything that’s in a sidebar column below the main content—makes sense:

“What happens if the first column is really tall? Is the content in column 2 less important than all of the content in 1? It probably is for something like a full-length article, but I can’t help but think that in some cases, this method throws off the hierarchy.”

What happens, indeed? Let’s take a look at Starbucks’ sparkly new responsive site to see how it pans out.

If you haven’t seen it yet, the homepage works pretty well. As the screen narrows, large rotating images shrink; thumbnails for additional features turn into simple dots; new product tiles stay above less-important information like blog posts: homepage - desktop homepage - iPad homepage - smartphone sized

But let’s say our user is interested in the Clover—a super-fancy coffee machine Starbucks bought out a few years back. She’ll find a thorough page about the Clover pretty easily under the Coffee section, and on larger screen sizes, the visual priority’s pretty clear: there’s an overview, a module to find a store with a Clover, and then deeper content about the machine and why it brews such a phenomenal cup of coffee.

Starbucks' Clover page for desktop

But look again at the smartphone-sized version, and all you’ll see is the image, headline, and 400 words of marketing copy: about the machine, the process, and even a long passage about the quality of Starbucks’ beans. Only then—far, far down the page—do you get a link to actually find out where you can get a cup of Clover coffee:

Smartphone-sized Clover page

The same thing happens when you look at Starbucks’ bean descriptions. Being a sucker for carefully sourced coffees, I flock immediately to the Starbucks Reserve section and select the Organic Ethiopia Sidamo. On the desktop, I see an image, quick facts about the product, and a call to action to buy front and center. Meyer lemon notes? Cooperatively produced? Sold. But not so on the smartphone-sized display—there, my buy button is all but lost.

So why is the Clover-equipped store finder so separated from the content at the top of the page? Why does my button to buy beans get split so far from the product information?

Why can’t Starbucks choreograph its content better? Because it seems to be missing two things:

  • Useful content types: Without content types defined by what the page is supposed to communicate and accomplish, all content is treated the same, whether the page is intended to inform, help you make a purchase, or help you find a location. The right-hand column simply swings down to the bottom, regardless of what’s in it. If you instead assigned a few content types based on the elements within the content and what it was supposed to accomplish, you could apply different rules to how each type of content shifts.
  • Micro structure: Throughout Starbucks’ site, main content is written in one big copy area, rather than with chunks of content. The sidebar is one big chunks as well. If the site used more structure within each type of content—structure that’s logical, creating units of information that have distinct meaning: a teaser, a pull quote, a lede paragraph—you could systematically break the long blurb into parts and insert an element in the middle (what Walton calls “interdigitation”), like so:

Smartphone-sized Ethiopian Sidamo page

Don’t keeping those quick facts and a link to buy near the top better keep the content flow (not to mention Starbucks’ goals of selling coffee) better intact?

Or so:

Starbucks' Clover page in smartphone size

See, now I can get the basics on the Clover with a lede paragraph, and then immediately find a location—or keep reading for a detailed look at the machine (and a bunch of marketing fluff…but that’s for another post).

This isn’t about calling Starbucks out (except maybe for making the Clover unavailable to indie coffee roasters). In fact, the company’s ahead of many simply by attempting to give good content to all their users. There’s no crime here. There’s just an opportunity to do better—if you focus on your content’s messages, priorities, and meaning first.

Mobile first?

From a design perspective, all this trouble over hierarchy and relationships might be easier if you design mobile versions of responsive sites first, using the general “mobile first” principles Luke Wroblewski recommends. After all, if the right meaning and message stay intact on the small screen, when you’re likely working with a single column, then the odds of the content making sense as you scale to larger widths seem pretty good.

This approach feels foreign to many web folks. We’ve spent a long time thinking of the desktop view as “the web” and anything else as “the other”: something different, exotic, or just plain less important. But it’s just this kind of shift in thinking that we need.

Whether designing mobile first is the best (or only) way of breaking free of the desktop mentality, I can’t say. But I do believe that however you tackle the problem, you need to be thinking more about relationships and priorities than about locations and sizes.

Structure first

Robots make poor editors. The relationships and meaning within our content make for fleeting, flickering little snowflakes, each granule packed with endless nuance yet easily mistaken as identical. But when a responsive design scales beyond the most basic of sites—beyond personal portfolios and simple blogs to thousands of pages, dozens of authors, and multiple types of information—we won’t be able to make manual decisions about each and every piece of content.

The best we’ll be able to do is rely on rules—rules grounded in clear content types, enabled by structure, and shaped by thoughtful human beings. Rules that respect our content and the readers we want to use it, learn from it, or enjoy it.

As Mark Boulton wrote the other day, we need to know enough about our content to know its structure:

You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content made from, not what your content is. An important distinction.

If you can define content types based on what they include at a semantic level—what their meaningful elements are and how they make the content tick, not just how much space they require—then you can create the databases that will support their structure (and therefore all content of that type). You can create sound rules to guide how they bend and reshape in responsive designs. You can let your content go, without fearing where it will end up.

But you’ve got to start with some structure.

35 thoughts on “Responsive-Ready Content

  1. Great post Sara!

    From a content creation standpoint, it seems like we’ve already got some of the basic building blocks in place.

    For example, a standard content template already includes areas for Primary, Secondary, and so on. It’s a pretty short leap to adapt those to fit the types we need for a responsive project (“Detail,” “Related CTA” and “Quick Facts” in this case). From there, it’s a little easier to start shuffling pieces around for various screen sizes and types.

    Obviously, there’s a LOT more to it than that. But at least it seems like some of the tools and practices we’ve created for the desktop web can make the shift to mobile with us.

    Every little bit helps, right?

    1. Definitely. Though, it seems like a surprising amount of web content still lives in some sort of “general” page template, rather than in more specific databases with modularized sections. It’s not that our tools can’t handle this, but rather that there hasn’t been enough communication between those selecting and customizing CMSes and those who are dealing with the content to make it so (and writers haven’t necessarily seen why it can help them to do things this way).

      1. YES! There must be better collaboration between the development and content authoring groups to make our CMSes work to our mutual advantage.

  2. I completely agree, Sara. I think part of the problem is that responsive design is so new and people are trying to learn how best to approach it that we fall into comfortable patterns.

    In its short life, a layout-shifting standard has emerged where the main column takes hierarchical priority and sidebars get shoved below. This is due in part to the fact that it seems logical but mostly because of the way responsive design works on it’s most basic level: columns shrink in width until they become too narrow. When that point is reached the CSS code tells the browser to move sidebars below the main column.

    There are countless new frameworks built on this method that developers and designers use to learn and build responsive sites, and in general, it works well.

    The problem is that if a site has critical information in the sidebar, that information gets moved below what could be a very long column of content. Again, this is fine as long as steps are taken to compensate for this.

    But too often smaller screens are a last resort and people forget or just don’t have the time or budget to go the extra step to maintain a prioritization scheme for multiple layouts.

    Like you pointed out, a mobile first approach can help with that.

    As a side note – one thing about the Starbucks site that almost bugs me more is that they assume everyone knows that 3 horizontal lines (top right corner on mobile) translates to “navigation” or “menu”. Iconography only works if it’s universally understood.

    1. Hey Sean! Yeah, I get that pushing the sidebar below main content is in many ways the easiest way to implement a responsive design. It’s logical and I don’t really fault people for relying on that approach. I just hope that as we continue to think about our web presences in more flexible terms and practice building responsively, we can improve upon that basic idea with more nuanced approaches.

      I worry about the shifting nav on Starbucks as well. Actually, in general, their on-click megamenu thing is a bit weird as well, and I’m not sure it’s universally understood. But I do like that they’re trying.

  3. Thanks Sara for taking the time to write this, this is something I’ve been trying to surface in my head for months and “ding” this article made sense of it. Looking at the smallest layout in Starbucks (the clover one) would it be a crime to add a “read more…” option to reduce the large chunks of copy. Mainly due to the limited width and how the text will flow make for very long pages (mad finger). There are nine ways till sunday to approach this but I agree, content priority makes the most sense.

    The desktop (or large display) version would be a lot easier to restructure via media queries, which amkes sense to start thinking about the best way to structure content on the smallest device first. Now here is one of my peeves about RWD, now this doesn’t happen on every site but I’ve seen some totally restructure content and most importantly “navigation”. What if someone on the Desktop doesn’t have their browser full width of their screen? The experience on Desktop can go from: OK I get this, to WTH just happen to my… (I think I’m on the same page as Sean).

    1. Hi Mark. Agreed on the nav. It can be trouble.

      I don’t know that I would want to add a read more button in this case. If we could interdigitate the important next steps with the lede paragraph so they’re higher up on the page, then we could let the longer content flow.

      Users know how to scroll, and if they want to read about a farm in Ethiopia, then I would bet they’d rather just scroll than click a button to do it. As long as we don’t force *everyone* to scroll through a long story just to buy the coffee, as they do now.

      Also, many pages with long content have a lot of fluff to them. As an editor, I’d suggest they cut the crap and tighten a bit before anything else 🙂

  4. Hey Sara, spot on. This is stuff is so important, it keeps me awake at night and then bothers me again in the morning.

    Agreed. We need to find those pesky content types. Slowly but surely we are building up that body of evidence to make content modelling a mandatory activity for the more involved web sites/content projects. Mobile is forcing the issue. Which is awesome. Now, for those companies that do not consider themselves publishers, but are publishing content, the journey begins.

    Nice post!

    1. Thank you, Cleve! I do love that mobile is forcing the issue more and more….and the conversations are getting interesting. Thankfully we have people like you on the technology side who get how critical meaning and relationships and messages are.


  5. Content modeling FTW! Great post, Sara.

    Pulling this off in a consistent way starts at the planning stage (just enough module types to be useful and not head-scratching) and reaches all the way down to the configuration of the CMS GUI (so content creators don’t give into the temptation to dump and run with their entries).

    A mighty and worthwhile cause, indeed…

  6. Although I have heard of “Responsive Design” I have yet to pay attention to the finer details, however I’ve need to modify a number of websites for mobile, etc and don’t wish to go through the hassle of altering the templates and stylesheets.

    It appears that the best solution is to spend some (more) time on the task of “Responsive” needs whilst doing the initial design would save time later on.

    So… what resources are available for testing these CSS along with HTML5 apart from simply adjusting the size of browser window? It appears up until now I’ve been stupid!

    1. Hi Emma, You may want to check with some authorities on CSS and HTML5…and since I focus on content, not code, that certainly isn’t me! Have you read Ethan Marcotte’s Responsive Web Design book, from A Book Apart? That would probably be a good bet. Good luck!

  7. Love your article! Agree completely. This article is exactly what who i think about Responsive Design and the bad decisions designer, but also developers make in creating a Responsive Design. They forget the content and don’t think about a content choreography like Trent Walton talked about.

    Looking forward to our interview on wednesday!

  8. Great post! I’m a designer/developer making the shift to responsive design and this issue has definitely been troubling me.

    However, the big picture is beginning to make sense, with content modeling and COPE lighting the way. I’ve discovered that the CMS of choice really matters, because content needs to become more atomized, semantic and flexible.

    I’ve sort of stumbled upon content modeling due in large part to the way my CMS of choice (ExpressionEngine) allows crafting of field types and does not assume the need for a single all encompassing ‘page content’ field. I’m also learning about the relations/associations between content fragments all because the system model/database is more subservient to the content needs.

    I agree, mobile and tablets are forcing us to focus, where content can no longer lounge in the periphery of sidebars.

    1. Hi Ian. Glad this post resonated with you! I agree that the CMS issue is critical. One thing that’s interesting is that most modern CMSes have been able, theoretically, to support semantic chunking of content for years…they just haven’t been set up that way, or the people using them don’t understand how to do it, or the CMSes are bloated and difficult to make do what you need, etc. But I really think that if more care is given to content modeling and thinking about content systems, we can a) do better with the CMS tools we have and b) demand better tools. Because the structural content work is foundational to all the other decisions and too often isn’t done, or isn’t done by someone who’s thinking about content meaning and purpose.

      1. Such tool already exists: With a content centric approach you model your micro structure and design the sitemap then export content templates to Word or Excel, compute quality report to analyse the content as soon as the team build it. Once the content ready state is reach you deploy while you start localization. This process is available for sharepoint.
        You and BrainTraffic are the opinion leaders which show the light.
        Please continue to provide us such relevant driving goals.

Leave a reply