Content modeling: Making future-ready content possible

Posted by Sara Wachter-Boettcher on April 23, 2012 | Comments (1)

Good news, y'all: after two months of research and writing and endless editing, I'm still excited about the future of content.

Even better, I've been talking with tons of smart internetters about the topic—and they've all got incredibly interesting things to say. What might surprise you, though, is that these interviews keep returning to the same topic: content modeling—the process of creating "micro" architectures that together form a piece of content.

If you trained as an information architect or technical writer, content modeling may seem far from futuristic to you—I mean, we've been modeling content for years, right? It's got a whole chapter in the Polar Bear Book.

So no, it's not new. It's not trendy. But with our new challenge of getting content prepared for an endless number of places, I think content modeling needs a hard second look—especially by the folks who are closest to the content itself.

Here's why. Just a few years back, content modeling was typically designed to drive contextual navigation—to create meaningful connections between information, allowing you to do things like systematically link the byline on an article to that writer's bio page, or show all articles by an author. That need hasn't gone away (and so many sites still haven't mastered this), but there's now a lot more that content modeling can give us.

Whether you're talking about personalized content, responsive design, or using an API to get your content on multiple apps, sites, and channels, your content's structure—and which sorts of structure it has—is what either limits or extends your ability to repurpose that content and make rules about where and when it should appear.

Today, I thought I'd share some of the tidbits I've gleaned from these interviews, with the hope of getting you as excited about content modeling as I am.

Whose job is content modeling?

Should content modeling be done by an IA? A content strategist? The CMS integration specialist? The database developer?

A content model is ultimately a data model—something that'll end up needing to be implemented in a relational database—but that doesn't mean it ought to start with the technical team. Instead, content models are the strongest and most useful when they map back to the content itself:

"I've always seen it as a role of the people who are most involved with the content. I know it bridges across—it bridges into information architecture, to the perspective of how we structure and retrieve content; it bridges user interface design because it's not enough to chunk up the content, we have to know what we're doing with that content... But someone has to truly understand the content, the customer, the device, the metadata."
— Ann Rockley, CEO of the Rockley Group and author of Managing Enterprise Content

What should be included in a content model?

Well, that depends on what you want the content to do now (we need content chunks A and B to flip below C for small screens), what you might want it to do in the future (content chunks A and B will be available on web-enabled toasters, but C won't make any sense there), and how much time and resources you can afford to spend on both:

"Modeling content is a never-ending battle between flexibility and complexity. The most complex model is the most flexible."
— Deane Barker, Partner at Blend Interactive

How does the CMS fit in?

When a content model is too complex or difficult to follow, it causes serious issues for those actually publishing and maintaining the content. In conversations with CMS experts and publishers alike, I've heard over and over the need for CMSes that make more sense for authors and editors—otherwise, we have no hope of them following them:

"If you make assigning a story to a section a complicated or unintuitive process, they won't do it. If you layer it in the right way, people get it. Our UX designers are involved with everything we do in the CMS."
— Patrick Cooper, Senior Product Manager for NPR Storytelling Tools

In other words:

"You give them something that's useful, then they start using it."
— Cleve Gibbon, CTO of Cognifide

Duh, right? People do better work when they're given better, more intuitive tools. Except, you see, that's not really how people think about CMSes:

"People think CMS is a soul mate—but it's more about how you treat it. Instead of finding 'the right' CMS, need to make it do what you want."
— John Eckman, Digital Strategist at ISITE Design

Experiments abound

Structure may be essential for getting content across lots of devices and channels, but there are plenty of people looking at alternate ways of building that structure.

Some are implementing CMSes where authors can edit in context, viewing a page of the website and simply clicking areas on that page to edit them. From there, the system extracts structure from the content based on the template used and the names of the editable areas.

Others are experimenting with things like markdown—a lightweight, readable way to add some structure to content that can be automatically translated into a variety of more substantial markup languages.

Thing is, no one's got the perfect answer, and there's likely never going to be a singular way to prepare content for every different situation. Solutions that don't require authors to think differently will have some limitations—but so will solutions that require lots of steps and granularity.

Here's where you come in. The more people like you—people who care about content and our users' experience with it—think about how content is organized, stored, and entered, the better our solutions will ultimately be.

Of course, you'll find much, much more on modeling content for this new world of connected devices and distributed publishing in the book, which I can't wait to share with you. In the meantime, I'd love to hear what you think: What's your role in content modeling? What do you think is important? Who should be doing it? What experiments have you tried?

Content Everywhere starts here.

Posted by Sara Wachter-Boettcher on February 14, 2012 | Comments (6)

Hello, and welcome! Chances are, you're here because you're interested in the future of content (or, you're a friend or family member I've cajoled into visiting).

Either way, I'm so glad you stopped by. It's an exciting time to work with content.

Our users are visiting our web properties on increasingly diverse and portable devices, and expecting to do more once they get there—and the websites and applications we build are starting to keep up: responsive web designs that reshape to fit varied devices; read-it-later apps that allow us to shift content for future use; fresh content driven by a focused content strategy. Yet there's still much to be done.

New devices and channels will continue to emerge, and each one requires content—content that must come from somewhere. Too often, it's from spending even more: more time, more money, more of our already stretched-too-thin resources.

There's a better way.

Instead of keeping pace with endless demands for more content, we can begin to create content that's structured, flexible, and reusable—that can travel where our users need it, reshape to fit varied displays, and keep its heart intact all the while.

Like many of you, I'm not an expert in CMS technology, markup, or APIs. I come from content—writing it, editing it, planning it—with a heavy dose of IA and UX picked up over the years. I'm writing this book because I think decisions about how to structure, store, and share content have too often been left in solely technical hands: developers, IT departments, CMS vendors.

Instead, it's time we—the writers, strategists, architects, designers, and other assorted web workers of the world—reach beyond our comfort zones and join our technical teams in making decisions that affect our content's ability to thrive.

But that doesn't mean I have all the answers. In fact, I need your help:

• Know of an organization that's future-readying its content well? I want to hear about it.
• Preparing content for a responsive design or multiple device outputs? I'd love to know how you're approaching it—and what you've learned.
• Think I'm missing something major? Tell me what I need to consider.

I'm pretty excited about this book, but I'd be even more excited to include stories of others who are grappling with these issues. So please do get in touch. I'd be delighted to hear what you think.