CHAPTER 2

Building a Way Forward

Future-ready, adaptable, flexible content requires a new framework, but take heart: You needn’t start from scratch. Much of today’s work has its origins in disciplines you likely already know a thing or two about. In this chapter, we’ll explore those origins, creating a solid foundation upon which to build. We’ll then take a look at how one organization is already putting the pieces together and creating a more flexible path for its content to travel.

With a look to the past and a bit of inspiration, you’ll have your own starting point—a place from which you can roll up your sleeves and get to work.

Tracing Our Lineage

This isn’t the first time folks have talked about reusable content, meaningful messages, structured information, and designing systems that work harder. Instead, you can find the roots of today’s movement in four key—and often overlapping—digital areas: content strategy, technical communications, information architecture, and content management.

Content Strategy

If you work online, you work with content. Whether writing or filming it, coding or organizing it, labeling it or designing its typography, this work is all about creating a digital space where content can exist and thrive—and where it’s findable, accessible, understandable, useful, and meaningful. Yet for years, that content was marginalized and ignored with the same refrains:

“The site’s all done. Now the client just needs to add content!”

“Let’s just launch now and fix it later.”

“It doesn’t matter what it says. Just throw in some lorem ipsum.”

These approaches resulted in little more than headaches and expensive delays, and as a result, websites often became a mess of disconnected, outdated, and useless content—content no one was responsible for, much less passionate about.

Enter content strategy: a discipline dedicated to reducing the pain of dealing with content that’s gone wrong and determining viable plans for making it go right—for both users and organizations.

As Erin Kissane writes in The Elements of Content Strategy, content strategy sits somewhere between user experience, business analysis, marketing, publishing, and technical communications, and is an umbrella term for all work that:

• Helps companies understand and produce the kind of content their target audiences really need.
• Allows organizations to develop realistic, sustainable, and measurable publishing plans that keep their content on track in the long term.
• Cuts costs by reducing redundant or extraneous publishing efforts, while increasing the effectiveness of existing assets.
• Aligns communication across channels so that web content, print collateral, social media conversations, and internal knowledge management are working toward the same goals (in channel-appropriate ways).
• Prevents web projects from being derailed by the often major delays caused by underestimating the time and effort required to produce great content.¹

Content strategy has caught on, and organizations far and wide have begun spending more time understanding their assets, articulating their goals, creating user-centered content, and improving the editorial quality of the things they produce.

But as digital spaces change, the approach to dealing with content must adapt as well. While message platforms and editorial guidelines will help, we also need to apply this passion for great content at a more systematic level. That’s where today’s work begins.

Technical Communications

Systematic approaches are nothing new to folks in technical communications. Since at least the 1990s, technical writers and editors—those historically responsible for things like specification documents, instructions, and help guides—have been embracing ways of making content more structured and interconnected to meet the demands of publishing across large, distributed companies.

These pioneers developed ways to separate content’s structure from its presentation, create repositories of content ready for reuse, and mark content up in a way that would allow it to travel between systems, resulting in

approaches like DITA (Darwin Information Type Architecture), an XML-based language for authoring and publishing information in modules categorized according to topic.

Originally designed by IBM’s technical communicators to help organize their own help documentation, DITA is perhaps best suited for marking up technical content, such as manuals for complex systems like military aircraft or computer hardware—use cases that don’t always feel relevant to the wider world of digital professionals.

Moreover, this form of structured content can feel cold and clinical, especially to those from the editorial or marketing side of content, so it hasn’t really caught on outside of very large enterprises managing vast amounts of technical data across distributed users.

It’s hard to get people excited about XML, to be sure, especially when the rest of the team is talking about marketing campaigns and flashing design comps around. But, as we’ll discuss more in Chapter 6, “Understanding Markup,” the need to structure content and set it free now affects us all, working on all kinds of projects. And that means structure and markup need a fresh look, this time through the lens of meaning, form, and message—so content can go mobile, cross-channel, everywhere...all without losing its form and shape.

Information Architecture

Systems, structures, and the shape of information—sound familiar? It should. Much of this new approach to content comes straight from good old information architecture, which Louis Rosenfeld and Peter Morville cemented as a critical interactive discipline in the late 1990s, and from which your own skills may well hail.

Often referred to as “the structural design of shared information environments,”² IA solidified as a practice to help solve several challenges parallel to those we face today. As the amount of information produced increased, information environments got more and more complex to support it. But they also became unwieldy, unusable, and impossible to manage. Information architects sought new ways of organizing and structuring all that data to facilitate users’ access to and interaction with it.

As a discipline, IA defines spatial relationships and organizational systems, and seeks to establish hierarchies, taxonomies, vocabularies, and schema—resulting in documentation like sitemaps, wireframes, content types, and user flows, and allowing us to design things like navigation and search systems.

The discipline of IA was also critical in establishing the use of content models—“‘micro’ information architectures made up of small chunks of interconnected data,” as Morville and Rosenfeld called them, which we’ll use at length in Chapter 3, “Breaking Content Down,” and Chapter 4, “Creating Content Models.”

A few years ago, content models were primarily used to support deep linking and related items within a single site—like connecting shoppers looking at a shirt with a listing for the matching pants. But today’s challenge requires us to take our content models further, using them to guide and shape how content flexes to fit the demands of a cross-channel, multi-device universe.

As content continues to get easier to produce, more interrelated, and less fixed to its original place of publication, we must focus more energy than ever on defining these micro information systems, establishing architectures that tackle the messier world of our content’s meaning—something we’ll do throughout this book.

As we do this, we’ll need to create experiences that are not just hierarchical or linear, but flexible, modular, relational, and semantic. Which means if you already have IA skills, you’re needed now more than ever.

Content Management

Ask any organization’s website manager or communications specialist about her CMS and you’re likely to get a sigh, a four-letter word, or—perhaps worst of all—a shrug of the shoulders and a look of resignation.

Content management systems don’t have the best reputation, but there’s still plenty we can learn from them—and plenty we can do to improve them. Because, in actuality, the problems with mobile and the problems with our CMSs are actually the same, as leading mobile and content strategy advocate Karen McGrane says:

If we’re going to succeed in publishing content onto a million different new devices and formats and platforms, we need interfaces that will help guide content creators on how to write and structure their content for reuse.³

Designed to streamline routine website updates and create a publishing platform less-technical staff can understand, CMSs do make some things easier for organizations. But they also cause their own set of problems. Editors and writers find them hard to use. Those WYSIWYG editors let well-meaning contributors turn perfectly good text into pink, bolded nightmares. Sites are typically arranged in strict hierarchies, not relationships—resulting in endless disconnected pages, not modules or systems that can be related and remixed.

Perhaps worst of all, content management systems are often unfriendly to their end users: the authors publishing in them. And they’re not sold or implemented in a way to help the authors get tasks done efficiently and effectively.

Today, however, folks are starting to address this problem by focusing on “author experience,” which is the flipside to user experience. Just as basic UX principles tell us to help users achieve tasks without frustration or confusion, author experience design focuses on the tasks and goals that CMS users need to meet—and seeks to make it efficient, intuitive, and even pleasurable for them to do so.

Put this way, it seems so obvious: of course the people creating and managing content are users, too. But in reality, today’s CMSs often seem to challenge users as much as they help. And as we all know, a frustrated user will abandon the process, avoid the system, or end up with errors.

Poor author experience can be just as detrimental. When CMS authors are frustrated or confused, they make errors or simply don’t bother to complete tasks fully—choosing, for example, to leave fields blank rather than navigate a painful series of drop-down menus. As a result, content creation takes longer than it ought, yet still winds up inaccurate and inflexible...and your workforce becomes frustrated and either unable or unwilling to care about your users.

As we’ll discuss in detail in Chapter 4, we now have the chance to stop creating such lose-lose situations and start incorporating content creators and strategists—those who know the content best—into the CMS selection, customization, and implementation process. When we do, we can develop CMSs that are both user-friendly and ready for the structure, rules, and relationships needed for content to travel across devices and channels.

Putting the Pieces Together

Whew. So you have a foundation and some skills to help along the way. But it’s always easier to get started with an example to guide you. Before you dig into your own content, let’s look at how one organization has stopped the endless cycle of more content for more places and started designing systems that let its content go further.

National Public Radio, the United States’ public- and donor-funded multimedia organization, has become the poster child for major media getting more flexible with content, seeing its overall page views increase by 80 percent in 2010 alone and attributing the bulk of that increase to its mobile efforts. But it wasn’t always this way.

Back in 2007, when Zach Brand joined NPR to head up its technology efforts for digital media, he started talking with the organization’s member stations—all those affiliate radio stations that carry NPR programming in their local markets—and seeing what their experiences and challenges were. By and large, they told him their websites were the problem—or more specifically, their sites’ content.

While NPR is known for radio programming that features detailed storytelling, in-depth interviews, and investigative reporting, none of that content was reaching its member stations’ sites. Instead, NPR was providing just short news briefs. Though informational and newsworthy, these stories lacked the depth and emotional connection NPR fans had come to expect—and that NPR held as the core of its content strategy.

This need to provide member stations with rich, satisfying content was at the heart of NPR’s decision to build a system for more flexible content—content that would support their strategic goals, anywhere it went.

First, the team revisited its information architecture, defining the types of content NPR produces and building a structure that supported them. Then it revisited the CMS, improving its interfaces for all that newly restructured content, as well as helping reporters and editors understand how all this would enable them to produce better stories. Finally, NPR built an API—an application programming interface, which we’ll discuss more in Chapter 7, “Making Sense of Content APIs,”—which opened its content up for use by other websites, making that content more reusable and reconfigurable.

With its API in place, NPR quickly began seeing more opportunities for its content—this time, looking inward. Rather than focusing on how others are using NPR content, the organization is now enhancing how it uses its own content, putting its API to work for multiple platforms and products, like NPR Music, the NPR News iPhone app, and NPR’s listings in iTunes.

It calls this approach, quite aptly, COPE: Create Once, Publish Everywhere. The concept is simple: create one set of content affiliated with each story, enter it into a CMS with structured attributes, and allow that same content—made available via the NPR API—to be accessed by both member stations and NPR’s own suite of products.⁴ Just a few of these outputs are shown in Figure 2.1.

FIGURE 2.1
NPR’s COPE model gets content onto multiple NPR websites and mobile products, as well as to its member stations.

As you’ll see more of in Chapter 3, this approach has had a number of benefits for NPR and its member stations, including better content in more places, less duplication of editorial efforts, higher consistency, more control over quality, and easier story updates.

That doesn’t mean it’s perfect. For example, it’s primarily been a one-way system so far. While it’s great for sending its own content out across platforms, as of this writing, NPR is just starting to toy with ways to receive content from external sources—so NPR’s member stations can’t easily send their features back up the chain to the national office.

Imperfect as it is, COPE is helping NPR...well, cope with a rapidly changing publishing landscape. It puts the organization squarely ahead of most others when it comes to mobile, and in some ways, that’s no surprise. After all, at NPR, content is the product, and every member of the organization understands its importance, including techy types like Zach Brand. With a large content-producing staff and plenty of editors, setting an editorial vision and publishing workflow isn’t new there. Plus, NPR has been sharing content with member stations since the 1970s, so while its delivery method may have shifted from satellite to API, it’s been packaging stories for broader consumption for four decades.

Progress, Not Perfection

Not a major media outlet whose product is content? That’s OK. Rather than relying on technologists to start looking at content more closely, it’s up to you to take the first step, even if you can’t tackle all your content challenges at once.

Whatever your background—content strategist or manager, technical communicator, information architect, writer, editor, or any other role that gets into the thick of the content—it’s up to you to break out of your professional comfort zone, glean some skills from all the disciplines we’ve talked about here, and collaborate on a better way forward.

By breaking content down into components and understanding how a piece of content comes to mean what it does, you can begin to make more informed decisions about how you build, organize, and use it—decisions that will allow you to bring a new content framework to technical teams and ultimately create experiences with the longevity to serve users and organizations far beyond a single page.

Part II of this book, “The Elements of Content,” is where we’ll do just that. In Chapter 3, “Breaking Content Down,” you’ll learn how to analyze a piece of content, breaking it down into its building blocks and documenting the micro structures within that make it whole.

In Chapter 4, “Creating Content Models,” you’ll take that intimate knowledge of your content and use it to create rich, useful content models—models that support your content’s meaning and make your databases and content management systems smarter. We’ll also talk about how to better collaborate with the technical teams typically tasked with this process, as well as how to implement content models in a way that respects writers’ and editors’ skill sets, time, and priorities.

With smarter attributes and more reusable content “chunks” planned, Chapter 5, “Designing Content Systems,” will show you how to think through the logic and business rules and conditions that will define how your content is used, combined, and displayed across experiences.

In Chapter 6, “Understanding Markup,” you’ll see how content can be prepared for transport with an overview of some current and emerging markup technologies used to keep structures intact as content travels. Finally, we’ll complete our methodology in Chapter 7, “Making Sense of Content APIs,” by discussing content-focused APIs and their role in getting content everywhere it needs to go.

Part III of this book, “Putting Structured Content to Work,” will explore how you can put smart, structured content to work, and the benefits you’ll reap when you do. It starts with Chapter 8, “Findable Content,” which explores using structure to improve navigation, related and contextual systems, site search, and SEO.

In Chapter 9, “Adaptable Content,” we’ll explore how your understanding of content types, as well as their inherent relationships and priorities, can help you make decisions about how that content should flex for different displays, such as in a responsive or adaptive website.

Chapter 10, “Reusable Content,” will show you how to put content modeling to work to repurpose content in a variety of ways, looking at examples of centralized content stores, personalized content, and more from technical communications, government, and major retailers.

As your content travels, unfixed from a single site, you must learn to let it go. In Chapter 11, “Transportable Content,” we’ll do this by discussing how content is shifting away from sites and into users’ control. We’ll also see how structure can give you a better foundation for saving and sharing, and possibly help you retain authorship information and data about content circulation in the future.

Part IV of this book, “Enduring Content”—which includes Chapter 12, “Content and Change,” and Chapter 13, “Towards a New (Information) Architecture”—will leave you with a mindset that will help you prepare both your content and your organization for a more flexible, less fixed future.

There’s no time to waste. Let’s go.