Frequently Asked Questions
What do you mean by "content everywhere"?
The way I talk about it, "content everywhere" doesn't mean splattering your message in every corner of the Web. It's about investing in content that's flexible enough to go wherever you need it: multiple websites, apps, channels, and other experiences. Why? Because devices of all shapes, sizes, and capabilities are flooding the market, and users expect to get your content on all of them, which you can read about in Chapter 1.
Right now, most organizations can barely keep up with their large, unwieldy desktop websites, much less multiple different sets of content for all these different experiences. Content everywhere is all about learning how to prepare one set of content to go wherever it's needed—now and in the future.
What do you mean by structured content, and why is it so important?
Today, most digital content is unstructured: just words poured onto a page. To signify where one part ends and another begins, writers use formatting, like upping a font size to be a headline or putting an author's name in italics. This works fine if your content is only going to be used on a single page and viewed on a desktop monitor, but that's about it.
Structured content, on the other hand, is created in smaller modules, which can be stored and used in lots more ways. For example, you could display a headline and a copy teaser in one place, and have a user click to read the rest—something you can't do if the story is all one blob. You can give the same content different presentation rules when it's displayed on mobile, such as resizing headlines or changing which content is prioritized or emphasized—automatically. In this way, adding structure actually makes content more flexible, because it allows you to do more with it. You can learn about this in Chapter 5.
But don't I need different, simpler content for mobile?
If your content is needlessly complicated and full of fluff, then yes: Your content should be simplified for mobile—and for everywhere else, too. After all, a user with a desktop computer doesn't want to wade through filler either. But should your mobile users be offered "lite" versions of your content rather than the real deal? No.
While you might know what people do most often on their mobile devices, you can't know what they're intending to do on any specific visit. After all, people apply to college and buy cars on their phones every day—and will only do more on mobile as devices get more powerful and cheaper. Finally, I've seen firsthand how hard it can be for organizations to manage content on just one website. How much harder will it be when you're juggling updates and versions for multiple discrete experiences? There's no way you'll have the time, resources, and skills to keep up. One set of content that's clear, meaningful, and well structured is a more sustainable solution. You can read more about making this work in Chapters 9 and 10.
Who should be doing this work?
In the past, content modeling work was often just called data modeling, so it was done by database developers. That's not necessarily a bad thing, but it has its problems. Because content can be much more ambiguous and conceptual than other sorts of data, it needs attention a developer alone is unlikely to give it. If you want content to communicate a message, tell a story, or do something specific for your organization or your users, then you need someone who understands what the content means and how it means it there when you're making content modeling decisions.
Oftentimes, the ideal person to play this role is a content strategist, editor, information architect, or user experience designer. The good news is, it's not either-or. Content modeling and structuring can and should be collaborative—something that's more effective when people from multiple perspectives are involved. In Chapters 3 and 4 of this book, I aim to show those who may not have been in those conversations in the past how to get started.
I'm a content person. Do I really need to understand the technical parts?
If you typically work in a creative, editorial, marketing, or branding role, then dealing with modular content, metadata, logic, and relationships might feel foreign. How does this relate to communicating a message or telling a story? Do you need to know how to build databases and APIs?
No, probably not. But here's the thing: If you're the one who understands the content best, and who knows what readers and users want from it, then you're exactly the right person to be thinking about how it should be structured, stored, and transported—so you can keep its meaning and purpose intact. While this doesn't mean you need to become an XML expert, it does mean you should get more comfortable with the ideas presented in Chapters 6 and 7, and be able to discuss needs, options, and priorities with those who will implement technical solutions.
Is this just about mobile?
Yes and no. Getting content ready for mobile is a big challenge, and spawning all sorts of debate: Do we give mobile users just a portion of our content, allowing them to "snack"? Do we go responsive? Build an app? What does mobile mean, anyway: Is a tablet a mobile device, or something else? As these questions are raised, it becomes more and more clear that what we need is content that can go onto all the devices that exist now—and those that will exist in the future.
Smartphones may be disrupting our assumptions today, but they're just the beginning. TVs, household appliances, cars, and more are becoming Internet-enabled. Plus, there are content-shifting services like Instapaper and content-plucking sites like Pinterest to contend with, as I explore in Chapter 11. It would be easy to get overwhelmed, but the good news is this: The work you do now, to structure content for reuse and get it ready for mobile, is going to also make that content more prepared for wherever the future takes it.