The future is flexible, and we’re bending with it. From responsive web design to futurefriend.ly thinking, we’re moving quickly toward a web that’s more fluid, less fixed, and more easily accessed on a multitude of devices.
As we embrace this shift, we need to relinquish control of our content as well, setting it free from the boundaries of a traditional webpage to flow as needed through varied displays and contexts. In the words of futurefriend.ly’s Brad Frost, “get your content ready to go anywhere because it’s going to go everywhere.”
But don’t unlock the shackles just yet: our content is far from future-ready. When extracted from the carefully designed pages on which it lives today, most web content turns into undifferentiated text, its meaning lost as it spills into any container you give it.
We can do better. Rather than accept these “content blobs,” as Karen McGrane calls them, we can embrace meaningful, modular chunks that are ready to travel.
This is a content strategy problem, true. But listen up, designers, developers, and UXers: you’re not excused just yet. This job takes editorial, architectural, and technical knowledge.
This is a project for all of us.
Preparing for structure#section2
Most conversations about structured content dive headfirst into the technical bits: XML, DITA, microdata, RDF. But structure isn’t just about metadata and markup; it’s what that metadata and markup mean. Before we start throwing around fancy acronyms, we need to get closer to the content itself, creating a framework for making smart decisions about its structure. Only then can we tackle technology in meaningful, useful ways. So hang on—this part’s important.
1. Get purposeful#section3
You’re already designing sites with both user and organizational goals in mind, right? Great. Now you need to translate those goals to a smaller scale, applying them to each type of content you have—like blog posts, articles, rotating features, or product descriptions. To do this, you’ll need to be able to answer questions like:
- How does this kind of content support the overall site goals?
- Why would a user want it?
- What is the organization accomplishing by publishing it?
- What does the organization want the user to do with it?
Just as it’s critical to establish site goals before launching into design decisions, you have to know what each type of content is intended to accomplish before you can make decisions about how you need to treat it in different contexts. Otherwise, how can you ensure that content keeps doing its job as it flexes and twists to meet the needs of each device it’s displayed on?
(Now, if you realize your content isn’t accomplishing anything, or you don’t know what kinds of content you’re dealing with, you’ve got a bigger problem on your hands. Before getting friendly with the future, go cozy up to your client or boss and figure out what matters.)
2. Get micro#section4
All right, you know why the articles or recipes or limericks or whatever kinds of content you’re dealing with exist. Good, because now it’s time to get even more granular, breaking these content types down into their core elements.
The specific elements you’ll need to consider will vary greatly depending on the type of content you’re working with, so start by identifying all the content chunks you can find in a given type of information. These could be things like titles, teasers, body content, ingredient lists, reviews, pull quotes, excerpts, images, videos, captions, related articles, bylines, directions, addresses, and many more.
Take a recipe for asparagus, fingerling potato, and goat cheese pizza from the popular site Epicurious, for example.
Recipes are a pretty common type of content, so you may think you’ve got this one figured out already: title, ingredients, directions. But look again, and you’ll see a whole universe of interconnected elements contributing to this single piece of content:
- Title
- Publication Attribution
- Publication Date
- Byline
- Yield
- Teaser Description
- Image
- Ingredients
- Preparation
- Wine Pairings
- Ratings
- Reviews
- Main Ingredients
- Cuisine Type
- Dietary Considerations
- Related Recipe Collections
An information architect or content strategist sure comes in handy in determining these attributes, but everyone on the team needs to be fully engaged—because you’ll need these chunks to make major decisions about how content will respond to changes in device and display.
3. Get meaningful#section5
Understanding which content chunks exist is just the start. Now you need to understand why each one matters to the whole—and how much it matters. This allows us to make decisions about how content is organized, prioritized, and displayed for different screen sizes, contexts, or purposes.
You can begin to do this by considering:
- How does this element contribute to the content’s purpose?
- What meaning is lost if this element goes away?
- What relationships exist between this element and the others?
If this were my project, I’d do some hefty research into organizational goals, current content use patterns, and user needs well before getting here. But, for example’s sake, we’ll work with assumptions. Since Epicurious is a publisher, let’s assume it wants to increase page views to bump advertising revenue. Since it’s a recipe site, let’s assume users are there to find something suitable to cook.
This scenario could translate to a content-level goal like, “recipes should be compelling, specific, and connected—so users want to make them, can easily tell whether they meet their needs, and ultimately want to visit additional Epicurious content.”
As you hold that goal up against these content elements, some interesting questions emerge:
- Removing all those related items may seem like an easy way to reduce clutter for small screen sizes, but will that decrease the number of total pages a user visits?
- If we make sidebar content push below main content as the screen size narrows, will users be frustrated at wading through ingredients to get to the recipe’s rating?
- What would happen to users’ interest in the recipe if we removed the image?
- Does a title, if displayed elsewhere without its teaser description, tell the user enough to be meaningful?
These are difficult questions to answer. Wine pairings may be extremely compelling for the aspiring sommelier, and entirely unappealing for a teetotaler. Ingredients may be a critical first stop for someone with food allergies, but secondary to someone without.
We may never be able to anticipate each user’s personal preferences, but the more we understand the relationships between information, the more the compromises inherent in any design decision will be clear—and the better prepared we are to make tough calls.
For example, in many responsive designs, sidebars are immediately pushed beneath main content for smartphone-sized displays. But is this always the right answer? Here, ratings, reviews, and main ingredients give readers an at-a-glance means to evaluate the recipe, and pushing this information below the ingredient and preparation sections could make them all but useless.
That’s the thing about adapting content to varied layouts: each case is different. One-size-fits-all rules about how content should react are unlikely to serve your many content types—which means they won’t serve your users’ needs or your business goals either. And as more devices and technologies emerge, you’ll need to develop new rules and make new compromises as well.
Good thing is, we don’t need a crystal ball to start taking action. We can begin today simply by improving the ways our content is stored.
4. Get organized#section6
The future is sexy; content management systems are not. And yet, your CMS may well be what’s standing between your carefully considered content and its ability to travel. Think about the elements we’ve identified and the relationships and priorities that define them. Are the CMSes you’ve worked with ready for this level of content? If so, you’re in the minority. The rest of us have some work to do.
One organization that’s taken great strides to future-ready its CMS is National Public Radio. Back in 2009, NPR launched a methodology it calls Create Once, Publish Everywhere. With COPE, each story is entered into a set of discrete fields within the CMS, then made available via an API to multiple platforms, such as the NPR website, device-specific applications for iPad and iPhone, the NPR music site, and local NPR affiliate stations’ sites.
NPR’s CMS supports a variety of content elements, but only four are required: a title, short slug, longer description, and date line, says Zach Brand, the head of technology for NPR’s digital media. Additional attributes—like images, audio, or bylines—are all optional. Once in the CMS, the story is distributed via API and ultimately published using various combinations of elements determined by the needs of the platform on which it’s being published.
If we want systems that can handle this kind of modular, fast-moving content, it’s time we get cozier with our CMSes—and the people who develop, integrate, and customize them. Armed with knowledge from your in-depth analysis, you now have the tools to embrace a strategic approach to content management, which will help you to:
- Ensure those focused on CMS features and capabilities understand your content and what it’s intended to accomplish.
- Explain the types of content you’ll need and what elements they require, much like NPR has defined the attributes of its stories.
- Understand your CMS’s possibilities and limitations, and collaborate on how to deal with them.
- Ease your technical team’s burden by providing them with thoughtful, specific direction to inform the CMS’s requirements.
This groundwork will serve you well even if you’re just managing a basic website, but as you begin to share content across more devices and channels, it becomes critical. With a CMS that’s organized around modular, meaningful chunks of content, you’ll be ready to create rules for how that content should bend and shift—and have the systems in place to actually implement them.
5. Get structured#section7
There’s a reason this article didn’t begin with a primer on XML. Technology can’t help you make good decisions; it can only help you implement them. But content elements must eventually become code, so even if writing markup isn’t your job, we could all stand to get more comfortable with the tools out there to do it.
Structured content isn’t new. Technical communicators have been pushing DITA (Darwin Information Typing Architecture) for years—and there’s nothing particularly futuristic about it. Based on XML, a markup language that gives content components an inherent meaning when displayed beyond their database, DITA authors and publishes technical information in content modules—small pieces of information designed for reuse and categorized according to topic.1 Designed by IBM to manage the company’s own technical content, it’s most widely used for things like help documentation.
Many technical communicators insist DITA should be the web’s standard structuring approach, but it’s never quite caught on. It’s also not the only way to do it. HTML5 now supports semantic markup through its microdata extension, which goes beyond traditional presentational tags and allows you to mark up content with standards-compliant, semantically rich HTML.2 Of course, HTML5 itself is still a working draft, and it’s unclear whether microdata will gain widespread use, or offer enough specificity to suit our content. For example, late last year, the “time” element was removed in favor of the more generic “data.”
There’s also Schema.org, a microdata-based approach launched in 2010 by Bing, Google, and Yahoo!. Designed to create a common language across search engines, Schema.org arranges microdata into taxonomies of content types that start broadly and branch into ever-more-specific elements. Critics, however, point out that Schema.org is a closed system: the search engines tell us which structures matter, rather than allowing content owners to define them.
Many people are passionate about which of these approaches is best, and why everyone else is doing it wrong. I’m not one of them. Fact is, we may be a long way from a definitive markup method, and none of these currently supports all kinds of content, anyway. Use the one that makes the most sense for your project right now—and in fact, that could mean not even worrying about markup yet.
Giving life to structure#section8
What matters much more than markup is the work we put in to get there: the rules and relationships determined through analyzing content closely and caring for its message and purpose. After all, “semantic” connotes meaning—typically, the meaning of language. Whatever markup language you use, it’s not semantic unless it pushes meaning forward—which is why you can’t start with markup; you end with it.
This, I think, is why structured content has often been written off as too technical and utilitarian for the mainstream web crowd: because we’ve left the editorial side, the experiential side—the part that lends content life—out of these conversations.
This needs to stop. Future-ready content isn’t about becoming an XML expert or assuming microdata will solve your problems. It’s about seeing structures through the lens of meaning and storytelling, and building relationships across disciplines so that our databases reflect this richness and complexity.
We don’t have all the answers, but we do have a clear place to start: with our content itself. As we break our content down, analyze its elements, and document the relationships that turn those elements into a meaningful whole, we can begin to create and manage content in a way that endures, wherever the future leads us.
Technology will change. Standards will evolve. But the need for understanding our content—its purpose, meaning, structure, relationships, and value—will remain. When we can embrace this thinking, we will unshackle our content—confident it will live on, heart intact, as it travels into the great future unknown.
In addition to adaptation by different devices, I’m also in love with structured content’s ability to be pulled in by completely different applications. Your Epicurious example reminds me of Pepperplate, which understands the content structure of popular recipe sites and standardizes them in the app or on the site.
The amount of structure needed to not just say “this is an ingredient,” but to also say, “this is an ingredient and this is the plural of that ingredient and this is the measure of that ingredient and this is what that measure would be if the recipe is doubled” is a recipe nerd’s dream.
Also: I love this article. Go Team Future Friendly.
Thanks for not diving straight into the technology end of the pool. I think it’s important we avoid falling into the trap of seeing any technology as *the* solution rather than just _one possible_ solution. “Cory Doctorow’s Metacrap”:http://www.well.com/~doctorow/metacrap.htm is relevant here. The way ahead is to acknowledge the flaws (or limitations may be a better word) and strategize around them. I like the way you lay out the tools available and say “You can learn more about this stuff. Some people get pretty dogmatic about their preferred tool but I’m not gonna play that game.” 🙂
I am nodding my head over here. Nice work. Happy to see this argument laid out in such a clear fashion.
The only thing I might take issue with is the COPE notion. “Create Once” — love that part. Repeatability. “Publish” — like we do. But “Everywhere” gets my goat. There is an implicit green light to push everything to every available channel.
Marketers feeding ever-hungry channel-mouths would be happy to see content formatted in a way that allows (and encourages, at least a bit) publishing everywhere. Even if it is not the best idea.
As organizations create more future-ready content, they’ll need to make sure the folks with their fingers on the publish buttons know what they are dealing with. As the content becomes more sophisticated, flexible, and responsive, so too must those publishing it.
This is why I’ve wished that the acronym wasn’t COPE, but rather COPS: Create Once, Publish SELECTIVELY. (No relation to the television show of the same name, however.) It takes into account the appropriate-ness of the content for each channel and audience.
**Cue the COPS theme song**
My favorite bit:
” Technology can’t help you make good decisions; it can only help you implement them. “
@Corey—I was just looking at Pepperplate the other day. Something I didn’t want to get into here, but is really important, is how structure makes or breaks your ability to share content via an API. Data portability is cool, but if the data can’t be turned back into meaningful content out the other side of the API, what’s the point? So getting to good structure at the start is critical.
@Clinton—I agree—not every bit of content should go everywhere. But I think COPE is still a great acronym, since we use it to “cope” (get it?! har-har) with publishing across endless channels and devices. I don’t know that the message to push everything everywhere is implicit in COPE, per se, but I would concede that it could easily be interpreted that way, even though I know that’s not NPR’s approach nor intent. Ultimately, the goal is to build tools that remove the shackles on our content *and* enable us to efficiently do the things only humans can do well, like make good editorial decisions.
@Sailorgrrl05 and @Derek—I think we treat so many things like they’re a technology problem, when they’re actually problems with our people, process, and approach. Karen Mcgrane always has smart things to say about this, so please check her out if you haven’t. So glad you guys feel the same!
“Before we start throwing around fancy acronyms, we need to get closer to the content itself, creating a framework for making smart decisions about its structure.” – it’s great!
Future content will be created by experts – professionals in their field. Technology is just a tool to achieve objectives but the content is king.
Hi,
to place content at the core we decided to use an agnostic repository made of internet concepts(Webs, Pages, Images, Documents, Metadata, Links…) which help us to organize it without any look at how it will be used. Then we apply strategies to promote content to the right place.
The copy-writing phase supported by this approach and we provide simple views of the content in progress.
Our solution is a mix of process, coaching and tools.
Content is the diamond but model is the jewelbox.
I admire the attempt at not focusing on an particular technology as the solution, but it almost seems convoluted simply to rationalize the argument of this well written article. This article went to great lengths to talk in circles around some mythical CMS, but with a little research you would find all of this is ready and available in Drupal 7 along with the Schema module.
http://drupal.org/project/schemaorg
Drupal is perefectly suited for all the scenarios you posited.
@Pierre—Yes, I agree. Content models are incredibly useful and increasingly necessary. Too often, they’re done by database folks divorced from the content itself. What I’m getting at here is that people need to evaluate content on a meaningful level if they want to have models that are useful and make sense across devices. I know I didn’t talk about modeling much here, but I’m talking quite a lot about it in my book.
@rovo—Drupal is lovely, and I’d like to use it more often. I have a lot of enthusiasm for what folks in the Drupal community have been doing. But I don’t think it’s perfect, and certainly not for everything/everyone. Moreover, I think it’s important to remember that not everyone has the luxury of implementing a new CMS (or the authority to select one). Many large organizations are currently creaking along with legacy systems held together by what seems to be hot glue and hope. Many CMS decisions are made by IT without consultation from content folks. Because people’s experiences and needs vary so widely, I think it’s a lot more important that we start empowering web folks to look at their technical tools more critically, and to get into those conversations earlier and more substantively, than it is to point at a single CMS as the answer.
Thanks for the comments! Keep ’em coming.
This is probably the most complete article about content I have read. As they say: “Content is the king”.
Thanks again for your great article, Sarah. We’ve exchanged some views on Twitter on this matter. This morning (European time) I published an article on the well-known Dutch online communications blog Frankwatching.com, on ‘responsive web sites: target audience, content, context and design’.
A major issue, in my mind, that I haven’t seen mentioned either in your article(s) or in articles and disucssions by others, elsewhere, regarding responsive design and content, is whether it’s smart to publish (chunks of re-usable) content on a site, regardless of the user’s context. As in: SSDC — same sh!t, different context.
I firmly believe that, together with design and technology, content should respond to the user’s context, i.e.: I think a mobile user on the go should be offered alternate content — not simply shorter, with other bits of content disregarded, but different — than a tablet user on the couch, or a desktop user in the office.
To avoid any doubt: I don’t mean to say that content should be hidden or removed — all content should in essence be available to all users — but content should be focussed on the user’s context. As in: different context, different… you get it.
And the basis from where you decide which user should get which content in which circumstances, is found in content strategy, i.e. in target audience, needs and tasks, and context (not only device/screen size, but use case as well).
Looking forward to your reply.
Regards,
Christiaan W. Lustig a.k.a. @ChristiaanWLstg a.k.a. Lustigson
@Christiaan—In regards to context, I think that’s simply really difficult to assume. For example, you mention a mobile user being on the go and a tablet user being on the couch. How do you know that’s the case?
I tend to think that responsive websites should be used when you simply want to make sure that all people can access your content on any device—not to present different content to different contexts. You have to assume too much.
However, future-ready content isn’t just about responsive design. If you look at what NPR is doing, their model delivers different combinations and lengths of content to different users depending on the suite of NPR product they’re using: one of their smartphone apps, NPR Music, member station website, etc. But in those circumstances, the user has told NPR they want a “special” experience by visiting or downloading one of the specialized products. Going to NPRmusic.org instead of NPR.org says “I want music content,” and logically users there get a different depth of content there. Same with downloading the NPR News iPhone app, which says “I want news.” Users’ exact context is unclear, but these things give us clear direction.
But assuming what people want based on device size alone in a responsive design, and offering different content to those who have not asked for something special, seems problematic to me.
First of all, love this article and the site, just found it and I can’t get enough. Thanks for all the work your doing.
I work in information visualization, so I’m particularly critical of content and their structures. This responsive design beast, however provides some really interesting challenges (and joys!) as outlined here. The semantic groundwork of information presentation is horribly overlooked because its value isn’t seen yet, but I trust that’s coming. What I don’t get is how we’re all going about capturing these semantics. When it comes to semantics, you could argue “Context is King” as opposed to “Content”; so, call me ignorant (and I’ll fully accept that) but when smart people are advocating things like ” “I really like to watch Science fiction movies”, it seems to be ignoring the essence of semantics. By doing that, we’re assuming who I am, my preference for this genre, and what I’m even doing with it. To build truly responsive systems, ignoring the intelligence and structure of common language, seems odd. It’s like we’re trying to reengineer something that’s already been perfectly designed. Now, I’m not saying IBM’s Watson is easy, but it does point to machines attempting to cater to people vs. the other way around. If we truly are moving to this ubiquitous supercomputer of networked experience, then we need to put more focus the the relationships between info, because that’s where real meaning exist. No doubt google has been and still is (probably while I’m typing this) trying to decode this meaning. Its going to be awhile, but does seem we’re running around trying to figure out how to repackage our information in just the right way for the right experience in the right environment. But this is backwards. As people become more fluent in information seeking and profile building, they are going to have the control to say how they want to see the information in what form and to their preference. We already see this happening everywhere, and I just think it’s going to continue. We should be more concerned with how our information is going to aggregated into their chosen system vs. the one we are blessing, no? And I think those days are closer than everyone wants to admit. Moreover, i think its exciting days ahead.
Thanks if you humored my rant; I welcome any thoughts!
I am fascinated by the idea of separating the CMS from presentation, which seems to be a hurdle for most systems at this point. This makes so much sense! And yet is quite challenging. Are there content management systems that handle presentation to multiple devices / interfaces in graceful ways?
We’re working on a similar idea by including targeted, audience specific, summaries that can be attached to the meat of a story selectively. The general story is created and stored with appropriate media, metadata, and expiration date. When it’s ready to be pulled out of the story bin, the story wrapped up in an audience personalized summary, much like sharing a story on twitter or Facebook. A “hey, I think this you might find this story interesting and here’s why” attachment wrapper. The best of both worlds? Any thoughts, comments, etc.?
I think Google Glass is the first example (and just the beginning) of truly context-aware devices that need to be considered when structuring content. To your point, when LinkedIn rolled out their responsive web experience a couple years ago, they operated on assumptions that people on tablets, for example, were in different places (like a couch) than people on their phones, and therefore needed a different experience of the application. I think we all can see a certain short-sightedness in that design now, but with an onslaught environment-sensitive devices coming very soon, we can actually anticipate a user’s environmental (from where they are in their house, to how many people are around, and on and on and on) context in real ways. So it seems that one of our great challenges in the coming years will be how to best identify and address the granular real-world factors that affect information consumption.