Author – Speaker – Consultant

Content First?: Semantics, Structure, and Why We Should Care

Content first!

Exclamation point and all, it’s a rallying cry that’s been bandied about the internet for a few years now—first by those early pioneers of content work, but lately echoed more and more by smart design-and-dev world folks like Jeremy Keith and Luke Wroblewski.

Total win, right? Seriously, high five, you guys. They finally care about the content! Exclamation points all ‘round! But then, last week, I happened upon a post from James Callan questioning the usefulness of this oft-uttered phrase:

“Content vs. web-design-elements-that-aren’t-content is not a chicken and the egg argument. It’s not about evolution. It’s about genetics. Which came first, your mother’s genes or your father’s genes? Silly question. You need them both in order to be you.”

I can’t help but agree. I, too, have heard lots of newly minted content folks recently take up the phrase to claim that all content should be there, finished, before a single design decision is made.

That’s not just silly; it’s unrealistic—and unhelpful.

The rallying cry has served its purpose, but this is content strategy’s belle époque. As the discipline gains ground, the way we talk about it needs to advance as well—moving from broad calls to arms to specific, more nuanced sets of ideals and corresponding practices.

Getting practical

If “content first” doesn’t cut it, what does?

Let’s talk first about website content. In my work, this usually means websites for state government, higher ed, or good-sized corporations—sites with large amounts of content and generally inconsistent editorial oversight and management. I’ve found it helpful to place content like this into three broad categories, each with its own spot on the timeline: user interface copy, page-level content, or database-driven content.

These categories work for me for two reasons: first, they require different processes and different tasks, and second, they help me break the large, amorphous c-word into chunks that are manageable, yet still universal enough to apply to every project.

User interface copy

Fact: Scary error messages don't good user experiences make.

Some might say UI copy isn’t content at all, but rather part of the design. Others would say that all the things that make meaning on a website are content, including all those tricky bits of text.

Inline help, error notifications, labels, button text, and the like are critical to overall user experience. Someone better be figuring them out—someone with user-focused writing skills (which is why I rarely suggest leaving this to a client).

Anyway, I like to work the most important pieces—like signups and shopping carts and calls to action—out early, during collaborative wireframing sessions with design and development folks. At this stage, it needn’t be perfect. But I find it useful to document what needs to be communicated and about how much space you’ll need to do it. To get started, check out Amy Thibodeau’s Contentini post on the topic.

Because UI copy is often omnipresent, or at least omni-accessible, I like to make sure it’s polished and incorporated into designs before they’re cut—so developers can easily build out templates with a realistic, complete UI.

Database-driven content

If your work is anything like mine, you may be finding that more and more content is handled via database queries. This is great for lots of reasons, particularly because you can use that content as more than just a page, creating things like modules, teasers, and contextually relevant sidebars based on its database attributes.

For this kind of content, which often includes items like articles, blog posts, event listing, recipes, authors, and other sets of like data, I’m much less concerned with what each piece of content specifically says, and much more concerned with what it’s like, in an archetypal sense. This is where content modeling (something Jonathan Kahn explains well in A List Apart and R. Stephen Gracey covers at length) comes into play.

When we model content, we define not just its backend attributes (like “date” or “title”), but how those attributes will look on the front end—and how you’ll use them to relate one piece of content to another. That’s why I tackle content modeling in conjunction with sitemapping—so I can meld the macro structures of navigation and hierarchy with the more micro structures within a single piece of content. (Interestingly, this also helps avoid the age-old problems with page stacks.)

I dropped this little chart during a client meeting and BAM! The whole room finally understood why disconnected content was their problem.

Content modeling also adds depth to a traditional sitemap, which tends to look linear—A is a subpage of B, which is a subpage of C—as opposed to relational, where you may want to show not just that events are accessible from the “Events Calendar” area, but that events are related to cities based on their “City” attribute (see my non-contextualized, somewhat opaque example at right).

A well-defined, vetted content model makes sure everyone knows what size and shape each content type will take—without needing all of the actual content in hand at once (though it’s helpful to have a few representative samples to show your designers).

Collecting, editing, categorizing, and organizing that content is still no small task, but when planned well, this can easily be done by clients—freeing us up to keep the project moving toward real wireframing and design, and being more efficient with their project budget.

Page-level content

Yet, the web still has pages. Understanding content needs at the page level may be the most difficult for a content strategist in a consultant role, because the content here is neither built into the design to support functionality nor archetypal and easy to categorize. Instead, it can be (and often is) anything and everything: about-us blurbs, introductions and overviews, department-specific information, the works.

I like to customize content templates to the client and project. This one's fruitier than most, but they're all pretty tasty.

So if page-level information is the mystery meat of content, how can you know what you’re getting—and plan around it? It’s all about defining purpose. For these pesky creatures, I generally revert to something akin to content templates—pedantic, painstaking guides to what each page needs to do and how much space it ought to do it in. There are lots of formats for these documents, but I’ve shown a simple one at right.

I like my page templates to make their client-facing debut somewhere just after wireframes are finished, giving us ample time for discussions about length, format, and substance (this is also a great time to talk to clients about the things page-level content is exceptionally bad at, like managing content that has an expiration date or that needs to be used in multiple places).

With some templates and a reassuring pep talk, you can wave goodbye to page-level content for quite some time—sending it off to clients or subject matter experts and feeling confident it’ll come back in one piece, at least close to publication-ready.

Getting philosophical

While I’ve been successfully using these three content macro-types for a while now, I won’t pretend they’ll necessarily work for you. But I do think it’s critical we stop thinking about content as one undifferentiated thing, and start being more analytical (and anatomical, in a sense) about its structure and function.

In this way, I like to think of my content types as a series of Urtexts—stripped-down, elemental concepts that get at that piece of content’s core, enduring nature—which reminds me of something I saw Mark Boulton tweet a few weeks back:

“Content should be *always*. Not just first.”

This is particularly true when we move beyond website content. And boy have we. Today’s content doesn’t always stay where you created or envisioned it. Whether we’re talking mobile experiences or read-it-later apps or even just social sharing, content is moving quickly from place to place and device to device, its context and form changing constantly.

As Cameron Koczon put it in A List Apart, content is becoming orbital:

“Most online content today is stuck… Sites are the gravitational center and we, the users, orbit them… Our transformed relationship with content is one in which individual users are the gravitational center and content floats in orbit around them.”

This future may feel a long way off: something to aspire toward, but not something our clients yet understand or our projects can handle. But if we want to get there, we need to start making our content semantically rich, clearly marked up, and carefully attributed now. And, just as critical, we need to change the way we talk about it.

How we conceptualize and discuss content today will either bring us closer to this future, or keep us from it. Semantics matter. Specifics matter. If we start talking about content in a way that gives it a form and shape, we’ll have content that’s more than “first.” We’ll have content that endures.

22 thoughts on “Content First?: Semantics, Structure, and Why We Should Care”

Great journey into the content process. The concrete distinctions within types of content, times and ways to produce them, are what give clients and practitioners their a-ha moments about why it all matters. Breaking down the process keeps us from getting overwhelmed by the volume of pages and words we’re all generating. Thanks for the thoughtful and thought-provoking post.

Hi Rebecca! Glad it resonated with you. You know, you’re right about making content more manageable by breaking it down into types and structures – something I didn’t really talk about much. I was thinking a lot about how you can do more with the content when you break it down, and didn’t even really think too much about the benefits to our sanity during the process. Thanks for the comment!

Hi Allan. Not sure I understand what you mean…we are talking, primarily, about content that is captured in a CMS. Or are you talking about Gather? In that case, I think the tool is useful when you have a lot of people providing content, and different hands on the editing process. While some CMSes sell their editorial workflow capabilities, I’ve yet to see one that actually makes content collaboration, gathering, and mass editing very workable.