search

graphitefriction / useful-content

Curated resources and references about content. Categories include: story arcs, bias, chunking, etc.
0 stars 0 forks source link

Future- Ready Content #26

Open WhiteShark5 opened 9 years ago

WhiteShark5 commented 9 years ago

http://alistapart.com/article/future-ready-content

WhiteShark5 commented 9 years ago

Author: Sara Wachter-Boettcher Blog Post 02/28/2012

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. 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.

GET PURPOSEFUL 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?

  1. GET MICRO 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.

  1. GET MEANINGFUL 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.

  1. GET ORGANIZED 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.

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.

  1. GET STRUCTURED 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.