We were honored at our last enterprise web developers’ conference to welcome Karen McGrane (@karenmcgrane) as our first keynote presenter. I have known Karen since we were both attendees of the “Content Strategy Consortium” at the 2009 Information Architecture Summit, and every encounter, every opportunity to listen to her speak, has been an inspiration to me.

Currently, Karen is giving a talk called “Adapting Ourselves to Adaptive Content,” and many of you may have heard her give it as the closing keynote at the Content Strategy Confab 2012 in Minneapolis. For any who haven’t had the pleasure yet, I’d like to review my principal revelations from that marvelous talk.

As our conference theme was vaguely articulated as “mobile,” she addressed herself to the issues of how to ensure that our content plays well, when we have no idea on what sort of device or in what context people may be encountering and consuming our content. But more important than the “how-to” aspects, my main revelation from the talk was how hard it can be for us as content designers and producers to let go of control—to confront and release the idea that our content has a “primary platform,” from which are derived all the formats for the devices and contexts we can imagine and plan for.

Abandoning the “primary platform”

I think the greatest insight I gained from Karen’s adaptive content talk is the idea that historically, all content has been designed and created for a “primary platform,” whose format is well understood. After its initial publication, it must then be reformatted to meet the design realities of any other contexts in which it is to appear.

For example, a slick sales brochure is created as a print document. In this case, the paper page is its “primary platform.” The designer kerns and justifies, styles and tweaks, until a beautiful product has emerged, ready to be handed out at tradeshows or mailed out to prospective donors.

Then someone says, “Hey, we need to get this ‘up on the web,’” and it is (implicitly or explicitly) understood that it should look as much like the printed piece as possible. The brochure is then exported as a PDF, and on some webpage, there is a link to download it.

But then, someone notices that the brochure PDF doesn’t look right on a phone…or a tablet. The display is either too small to read, or it doesn’t rotate well from portrait to landscape. It is handed back to the designers to be “fixed.”

The design team then becomes trapped in an inescapable cycle of creating multiple formats for every content piece, first for print, then for web, then for mobile devices. The need to rework the design for different contexts multiplies the time and cost of creating the content.

Some designers, feeling the pain of the rework process, recommend “designing for mobile first.” But then “mobile” becomes the “primary platform,” and the need for redesigning and reformatting content for other contexts remains.

Responsive  Design: Teaching your design to adapt to its surroundings

Ethan Marcotte has sounded the call for “Responsive Web Design,” which from the visual designer’s perspective, offers a solid approach to putting intelligence into the CSS code, so that a design “knows” what device is calling it, and it can respond with the appropriate styling and format to match. By incorporating media queries and relative measures, web designers can teach their designs to accommodate a wide range of devices and formats. This brilliant work is revolutionizing the way we make design decisions and write code.

But if “responsive design” is about teaching the design know the device, “adaptive content,” according to Karen, is about teaching the content to know itself.

γνῶθι σαυτόν: Teaching your content to “know itself”

“Designers are control freaks,” admits Jared Ponchot at Lullabot in a blog post on responsive design. News Flash: So are writers, editors, and other content producers. “Hello. I’m Stephen, and I’m a content control freak.” I can only say that self-knowledge is the first step toward wisdom.

But it’s time to admit that we’re powerless over technology and its users. We can never know enough about our users, their needs, or their devices—let alone how devices will have changed by next year—to teach our content how to adapt to them. Instead, we must build into the content solid information about its structure and meaning, so that we can allow others to make decisions about how it should look and behave.

(It’s probably more like parenting than we care to admit: Parents do their best to rear their children and help them to know themselves, but eventually they must let go and let them be their own adults. They have to stop following them around to make decisions for them. I can hear my mother saying, “But you’ll always be my content…!”)

Karen points to National Public Radio’s “content API,” which streams no design information, but only content and its structure. Because the API doesn’t know anything about devices, devices can present the content according to their native styling instructions. The NPR website has templates to style the content for the main platforms, but application developers can also write native applications to style the content for their particular target devices and contexts.As technology changes, so will the styling, but the content remains well-structured and ready for anything.

Design can only be “responsive” when content is “adaptive.”

On reflection, I think the primary message of Karen’s talk is that we’ll get the most out of “responsive” design when we learn to make our content “adaptive.” We’ve long said that structure and presentation—content and design—should be independent of one another. Well, folks, it looks like this time we have to mean it. It will require both disciplines—and facing down our control needs—to provide rich content that plays well across the dizzying array of platforms.

Time for a deep breath. Time to jump…

Every now and then, I let a retail cashier sign me up for the company marketing e-mail newsletter, mostly to see what they’re doing for e-mail marketing. OMG! I have to say that Books-a-Million (BAM!) has won an award with me today.

I decided, based on sheer volume of e-mail and the ease of ordering from Amazon, to unsubscribe from BAM’s mailing lists. You know how it’s supposed to go; there are standard practices: Click the unsubscribe link and you get a message, “You have been unsubscribed.” Easy-peasy. Not so with BAM.

Here is the footer of the last e-mail message I ever wanted to receive from BAM:

It says, "Click here, and you'll fill out a new e-mail message."

So, if I click on the link and a new message is supposed to open, that tells me that the code underneath must be:

<a href="mailto:unsubscribe@booksamillion.com">here</a>

…or something like that. No. It’s actually a link to:

http://xb1.booksamillion.com/list/unsubscribe.html?lui=etc,etc,etc...

When you click it, a new tab opens, and several minutes–minutes!–later you see:

Whose options are THESE???

…and so, I had to select “unsubscribe” from every little drop-down, for unintelligible mailing lists. It was easy, since I’d already decided I never wanted to receive anything from BAM again. And another several minutes later, the page confirmed thusly:

Oh, good. It worked...?

Now, there are too many things wrong with this scenario to list them all, so I shake my head and wonder: “Why would any developer build such a cryptic and horrible interface?–too awful to contemplate.

Books-a-Million, you have a serious problem in your e-mail marketing department. I hope you can track it down.

Postscript: Several HOURS later, I noticed that I had to click the “unsubscribe” button AGAIN to make it final. Sheesh!

First thing this morning, checking in on the Twitter streams, I saw Jeff Evans (@joffaboy) announce the article, “Google, Bing & Yahoo’s New Schema.org Creates New Standards for Web Content Markup.”

My heart began pounding as soon as I read the title. The arch-rivals of search, the biggest dogs in the yard, the great institutions of the web were collaborating to propose a solution to the problem of markup that has plagued me from the beginning: Markup doesn’t really address the substance of the web, just its most basic structure. My hopes were further raised by the mention of a “recipe” content type, which if you follow my writings, you’ll recognize as a regular example.

I retweeted in a flash: This is what I’ve been looking for!

Then, I visited schema.org, and all my hopes came crashing to Earth again. The Search Giant monsters have created a new monster.

Quick Overview

As I understand it, schema.org is proposing additions to HTML that the “Big Three” search engines are going to interpret, in order to improve the accuracy of search results. By augmenting the markup in web content, they are together settling on a standard vocabulary, so that they will all be recognizing the same language. Presumably, once they’ve built this standard language into their sorting algorithms, any content that has these augmentations will rise to the top of search results, above content that doesn’t.

In principle, that sounds good, doesn’t it?

I’d like to offer some reflections on a few practical implications of this effort.

Corporations try to head off the “free” Semantic Web

For-profit companies have been watching in dismay for twenty years the rise of the “free” WorldWide Web. Content is free. Software is free. Social Networking is free. And more and more of the web is being driven by “free” efforts, like the WorldWideWeb Consortium. Volunteerism is a huge threat to capitalism, and they know it.

Among the greatest of these free efforts is the quest for the Semantic Web, which in its simplest terms, seeks a set of standards for describing the meaning of content. Human language is always problematic—as are those who use it—because words are never just words. The meaning of words is rich, contextual, ambiguous, and worst of all, ever changing. There are a lot of really, really smart people, all over the world, almost exclusively volunteer (with some corporate support), working hard to figure this out. If you want to get a sense of the complexity of it all, talk to Rachel Lovinger (@rlovinger) at Razorfish. She’s one of the true semantic geeks, and I’ll just have to take her word on most of what she says. She’s fab.

But instead of supporting this “free” effort, the Search Giants have imposed a de facto standard for the Semantic Web, and they’re pushing it with the strength of their size and popularity. Like the Zen question of the tree in the forest:

If a search engine doesn’t support your semantic standard, will anyone find your content?

I am suspicious of their motives. I read it as an effort to bypass all the work that’s already gone into the Semantic Web.

Markup is more than basic structure and presentation

It has been a great struggle since the beginning of the web to strike the appropriate balance between the structure of content and its presentation. In other words, what content is should be distinct from how content looks. But HTML—even up to HTML5—still only addresses the most basic aspects of content, and even now, offers only tags that address the pieces of the “webpage”—like the “header” and “navigation.” There isn’t markup to describe the content’s substance.

CSS as semantic markers

Cascading Stylesheets, in a roundabout way is one approach to the problem, although it’s originally meant to control the presentation of the content. Let me give an example.

Lists are a primary content structure. We create lists for everything—ingredients, footnotes, archives, contacts, links, Q&A, references, etcetera ad nauseum—but HTML offers us only two choices: “Ordered lists” (numbered) and “Unordered lists” (bulleted).

If your website had a list of links in a sidebar and a list of staff names on a contact page, you use the same basic markup:

<ul>
    <li><a href= “http://url.for.link/1” title= “This is the first list item”>Link Text 1</a></li>
    <li><a href= “http://url.for.link/2” title= “This is the second list item”>Link Text 2</a></li>
</ul>

…and then…

<ul>
    <li>Contact Name 1</li>
    <li>Contact Name 2</li>
</ul>

Here’s the problem: The web browser has a default way of rendering these lists, and they will look exactly the same, except that the links will be underlined. If you want to distinguish them from each other, you can add CSS classes, which give you a way to style them differently.

Now, CSS gurus (the best of whom are really content strategists underneath it all) will tell you that you should NEVER use class names that describe how something looks, like “class= ‘blue_text’.” The class names should describe what they are, which is, in fact, a semantic indication:

<ul class="links”>
    […]
</ul>

…versus…

<ul class=“contacts”>
    […]
</ul>

Using these identifiers, the designer can define precisely how each component of a website should look. In a better world, however, they could also be used to identify what they are. Defining standard CSS classes and identifiers as part of XHTML would be one approach to encoding the meaning into markup.

But not Google, Bing, and Yahoo—Noooooooo.

The Search Giants, though, instead of building on CSS or any other existing approach, have introduced another “standard,” which superimposes another layer of markup on top of the feeble XHTML we already have. Here is the example from schema.org:

<div>
    <h1>Avatar</h1>
    <span>Director: James Cameron (born August 16, 1954)</span>
    <span>Science fiction</span>
    <a href="../movies/avatar-theatrical-trailer.html">Trailer</a>
</div>

Before I go any further, I have to say that this code doesn’t look like any real XHTML I’ve ever seen, and that’s a worry right from the start. Nevertheless…

Once they’ve applied their markup augmentations, again right from schema.org, it becomes:

<div itemscope itemtype="http://schema.org/Movie">
    <h1 itemprop="name">Avatar</h1>
    <div itemprop="director" itemscope itemtype="http://schema.org/Person">
    Director: <span itemprop="name">James Cameron</span> (born <span itemprop="birthDate">August 16, 1954)</span>
    </div>

    <span itemprop="genre">Science fiction</span>
    <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

There are many, many, many things wrong with this picture.

All the complexity of XML without any of its simplicity

XML is the mother of all markup. In fact, XHTML is just one markup language based on the XML standard. Using XML as the basis of your web code is an elegant—but very complex—solution to defining your content. When it’s all worked out, however, it lets you replace that gobbledygook above with something more like this:

<movie>
    <title>Avatar</title>
    <director>
        <name>James Cameron</name>
        <birthdate> August 16, 1954</birthdate>
    </director>
    <genre>Science fiction</genre>
    <trailer url= “../movies/avatar-theatrical-trailer.html” />
</movie>

Putting it simply, by augmenting XHTML with another layer of markup, the Search Giants have complicated the code immensely, making it just as complex as if they had done it in XML, but without any of the benefits of XML’s simple elegance.

Content is rarely this simple

The examples above deceive us, in any case: Yes, we can add fields to CMS templates for isolated metadata like “title” and “director,” but what about the main content itself? What about the meaning embedded in the article? Let’s say we’re writing an article about motion picture history, and we include the following sentence:

<p>James Cameron, best known for directing the sci-fi thriller,

“Avatar,” was born on August 16, 1954.</p>

All of the information in the schema.org example is present in that sentence, and if we were searching for content about James Cameron, we would have to rely on full-text searching.

If we were to use the schema.org augmentation, in order to make it all accessible to the search engines, it would get very messy, something like:

<p>

    <span itemscope itemtype ="http://schema.org/Movie">

        <span itemprop="director" itemscope itemtype="http://schema.org/Person">

        James Cameron

        </span>

    </span>,
best known for directing the

    <span itemscope itemtype ="http://schema.org/Movie">

        <span itemprop="genre">sci-fi thriller</span>,
        <span itemprop="name”>Avatar</span>

    </span>

,” was born on

    <span itemscope itemtype ="http://schema.org/Movie">

        <span itemprop="director" itemscope itemtype="http://schema.org/Person">

        <span itemprop="birthDate">August 16, 1954</span>

    </span>

    </span>.

</p>

Not for mere mortal content authors

Now we come to the main practicality of content: Content authors.

I have marked up a lot of content in my career, and I am an obsessive, precise, exacting author. On the other hand, I’ve implemented CMS templates and tried to configure the best WYSIWYG editors to be able to apply the right CSS classes within content. And I’ve worked with a lot of content owners to teach them the importance of good markup.

Here’s the hard reality: No matter how powerful the technology, no matter how carefully designed and coded the CMS templates, no matter how sophisticated the WYSIWYG editor, and no matter how much training we offer, any markup will ultimately succeed or fail on the content authors’ ability to use it.

And that brings me to my main issue with the Semantic Web.

The Semantic Web cannot rely on encoding alone

If the main difficulty of searching the web is in understanding the meaning of the content (given all the languages, people, markup skill, and so many more factors), then we can really only solve it the hard way: Intelligent reading. We cannot rely on the human beings who create content to make it speak for itself, by making sure that everything is tagged correctly. They just can’t do it.

We cannot rely on markup because XHTML is insufficient, XML is too complicated for more than data structures, and the schema.org effort is unrealistic. In the end, each method may play a limited role in addressing the findability of content, but ultimately, it will require some other kind of intelligence—intelligence in the interpreting of meaning, rather than its encoding.

I don’t know what will happen with the schema.org markup augmentations. Personally, I hope that it just sags under its own weight and disappears into the marshes from whence it came. And I heartily encourage all the folks who are working on this problem to keep at it: There’s no path to success here but the long one. Eventually, perhaps new kinds of computers will be able to understand us weird, wonderful human beings, but for now, we remain inscrutable to the mechanical, algorithmic mind.

“

Fish/Bird Tessellation by Escher

I first discovered I was a content strategy guy at the 2009 IA Summit, at which Kristina Halvorson (@halvorson), CEO of BrainTraffic, organized the “Content Strategy Consortium.” It was a natural awakening for me, as I believe it is for others, since I’ve been working with content all my life in one context or another. When content strategists talk, I find myself nodding: I recognize their stories instinctively as part of my own.

The idea of content strategy isn’t as easy to grasp for others, and that’s ok because some folks appreciate naming things and seeing them all in relation to one another. It’s a kind of wayfinding in the growing complexity of the digital age.

This conversation is ongoing, and most recently I found it in the Boxes and Arrows group on LinkedIn: Why IA Should Focus on Content

Here are a few snippets from the conversation:

Regan McClure • I completely agree. I’ve been mulling over the IA/UI/UX/CS job titles for a while (because I do all of them and can’t answer well when people ask for my job description) and I really can’t decide because they are ALL related. Inherently. Completely. Fundamentally. […]

Laura Hampton • Labelling does create an issue, agreed. When everything becomes so integrated it’s important for each area to retain its own merits but it is also essential that the overlap between them all is well communicated.

Kathrin Peek • There is also the discipline of content strategy to consider. This in and of itself is an even younger discipline than IA but ultimately evolved from it and the very need to focus on the content elements themselves. It’s a subset of UX from my perspective[…]

A year ago, Dan Brown (@brownorama), experience designer and founder of Eight Shapes, wrote a Letter to a Content Strategist on his blog, GreenOnions.com in which he said:

“But, aside from the composition of content, content strategists haven’t (to my satisfaction anyway) defined what it is they design, what’s the output of their work.”

It’s a good article, and I recommend it because he talks about what the other design disciplines need from the Content Strategist. I trust that better apologists than I have explained it to his satisfaction, but I’m going to pick up the gauntlet here anyway, perhaps better a little late than never.

Content Strategy in an Oversimplified Historical Context

I find it helpful to talk about the rise of Content Strategy as simply another thread in the spinning of the Worldwide Web. It is, of course, a gross oversimplification, but I have observed that we, as “WWWWorkers,” have always defined new disciplines to help us come to terms with each new BIG THING we’ve learned about our craft. In a continual dance among engineering and design, culture and communication, we have expanded our skills, each according to his/her own gifts. There has always been room for one more…

In the beginning…the Net

In the beginning of the Web, there was the infrastructure: Networks and protocols. It was exciting back in the early 80s that you could type some words on one computer, and they could be transmitted to another computer somewhere on the Internet. E-mail became the new telephone, and we figured out all sorts of ways to use it. We stored files on servers and used elementary browsers to list them. These were the heydays of some really powerful communication forms, like listservs, gopher sites, USENet, and IRC. With the possible exception of Gopher, these are all still going strong.

And there were links…

Then arrived the hypertext transfer protocol (http://), and we began to structure simple text documents, so that browsers could render them. Hyperlinks began to tie the Web together, and everyone was excited about publishing “personal web pages.” We learned basic HTML (or installed an MS Word add-on, so that it could save HTML), and we created websites of a few pages, all of which were lovingly hand-crafted—and painstakingly and painfully maintained!

Xtreme makeover

But webpages were ugly. They were U-G-L-Y, and there was no consistency across websites because we had no conventions beyond the obligatory “about us” page. In the 90s, we grew impatient with web pages because we couldn’t express ourselves as creatively as we could in other media, like print. So graphic artists began to apply their skills to the visual design of the Web, pushing the boundaries of markup, learning to make things more visually attractive, and establishing some standards for page parts—headers, footers, etc. In their turn, web browsers improved to render what the designers and developers created.

Pretty, but DUMB

As the Web grew, however, we learned that the more information we packed into websites, the more we tried to make them do, and the more we tried to give people a real, touchable experience, the harder and more frustrating it became for the users. We had to face up to the fact that just because websites were beautiful did not mean that people liked using them. They couldn’t find what they wanted, and they were foiled by navigation sequences that didn’t make any sense to them. Fifteen years ago, Vincent Flanders founded Websites That Suck, the original rogues gallery of bad design. (Unfortunately, he still has plenty of material to publish.)

So were born the twin disciplines of Information Architecture and Interaction Design, who along with their elder first-cousin Usability, went to work on restructuring and reinventing the web experience. They brought rigor not only to the structure of sites and consistency to interactive forms, but they recognized the importance of testing the sites on real people. Processes, methods, and tools arose to bring consistency to the disciplines themselves. These fields drew on all sorts of existing disciplines—graphic design, library and information science, engineering, and programming—so that they could stand up for themselves and point to what was important.

Dogs wagging tails

But at the turn of the 21st Century, it became unavoidably apparent that although a certain amount of design could be successful based on one’s own insight and the information itself, we still had little understanding of the people who actually were using the websites. So the discipline of User Experience arrived to embrace and extend IA, IxD, and Usability. Now, we understood that we needed to study the people on the other side of the code—their contexts, their goals, their preferences—in order to create usable sites. Personas and other models grew up to inform all the decisions that we were making.

Yes, but “content is king”

Now, in the latter half of the 00s, we have reached conclusion that we have not paid sufficient attention—have not applied sufficient rigor—to the actual substance of our websites, nor to its appropriateness to our reasons for wanting websites in the first place. And not only on our websites, but in our applications, in our marketing materials, and in our documentation.

In its broadest sense, the disciplines of content strategy (and there are quite a few) add structure, rigor, and discipline to all the questions about content: What content will help us reach the people we intend? What do they need to know from us? What information will best support our audiences and bring us long-term success?

What do we design?

We design the processes by which organizations decide what content they should publish to meet both their business needs and those of their customers; how they will create that content to ensure that it maintains the right voice, message, and perspective; how that content should be matched to delivery channels and measured for effectiveness; and finally, how that content is managed, refreshed, and retired.

Why do we need a “new discipline?”

There are indeed areas in which all these disciplines overlap, and every content strategist brings a wealth of other disciplines and experiences to bear. Stop content strategists on the street, and they will probably tell you that there is nothing “new” here. Knowing what to call something, however, and being able to draw broad lines around its parts, can help us to focus our attention on it. Erin Kissane (@kissane), in her wonderful and succinct treatise The Elements of Content Strategy, talks about content strategy as a descendent of the fields of publishing, museum curation, marketing, and information science. But these roots only make sense in the wider context of all the other disciplines out of which the Web is spun.

Our challenge and promise to one another

So in answer to Dan B., and as my contribution to the LinkedIn discussion, I say that although there is indeed overlap in our areas of interest, content strategy deals directly with the substance—the content—which the other disciplines help make usable and engaging. We worry about the business strategy the content is meant to fulfill, about how the organization is going to create and manage all that content, and about how the organization will maintain a clear and flexible control over the content’s lifecycle.

We must not allow our desire to draw distinctions for our own understanding to hamper our recognition of each others’ perspectives and contributions. In a few years, there will undoubtedly be new discoveries that lead us WWWWorkers to define new disciplines, but they will take nothing away from all the disciplines and wisdom that we exercise now.

When content management folk talk about “content modeling,” they are usually referring to the process of building templates for a CMS.  Besides the Content Management Bible by Bob Boiko, which is a great place to see how a lot of CMSes work, I found a series of excellent overviews of the discipline by Deane Barker of Blend Interactive, Inc., at Gadgetopia.

Barker says:

“Content modeling is the process of converting logical content concepts into content types, attributes, and datatypes.”

In academia, you can find inscrutably technical research on content modeling as the process of identifying the structure of documents algorithmically. (This gem from MIT scintillates! Content Modeling Using Latent Permutations, by Chen, Branavan, Barzilay, and Karger. 2009.)

But if that’s what is meant by “content modeling,” then there are essential aspects missing.

As content strategists, we face this technical view all the time, which I believe is descended from IT disciplines like “data modeling” for database design. We come on the scene talking about content purpose and process, and technologists ask us for template requirements, metadata fields, and data types. In these days of XML standards and the quest for the Holy Semantic Web, we find ourselves pushed into the thick of technical specification before we’ve had a chance to imagine what the content is supposed to be and do, let alone how it should be structured.

Returning to art

In my view, we’d be nearer the truth of “modeling” if we took our cues from other disciplines:

• When a painter undertakes a monumental work of art, she doesn’t just run in with paintbrushes blazing. She sketches from life. She does études. She makes early decisions about what works and what doesn’t.
• Murals often begin as drawings in miniature, which are enlarged to scale, then transferred to the wall.
• The sculptor “models” in clay before casting in bronze.
• The industrial designer creates digital “models” before production.
• Developers create prototypes (just “models” by another name) before turning the coders loose.

Models serve as demonstration and instruction to the producers, the assistants, and the artists themselves. They remind and guide. They provide format and boundaries to inspire greater creativity.

Content must be modeled in this creative sense, as well as in the technical sense.

Some suggestions for modeling

• Banish the “basic page” from your content types. The “webpage” is the content parallel to the “miscellaneous” category in information architecture. Far from being your standard content type, it should be your very last resort.
• Ask the simple questions. Why are we creating this content form? What are people supposed to do with it? What does that mean for the other kinds of content we produce? How can they be combined into content “super-types?”
• Do some content studies and sketches. Before you define technical requirements, spend time whipping up some real content to see how it behaves in your domain. If you already have content, gauge the consistency of its form from one piece to the next.
• Test the usability of your content. Like a user interface, you should see whether people can actually use your content in the way it was intended. Do they get from it what you hoped they would?
• Define the “rules” for each content type. You’re establishing conventions for the content creators, so they know what they’re doing, and so they can do it consistently over time.

By modeling your content in the artistic sense—by setting the forms and boundaries even before the content is “designed”—all the technical content management exigencies, like “fields” and “data types,” are set in their proper perspective. Templates are simply the mold into which your material is poured and out of which the sculpture emerges, fully formed.

Rachel Lovinger of Razorfish began a conversation recently about adopting Agile/Scrum software development practices for content strategy, and as synchronicity would have it, I am, e’en now, working on helping my team explore Scrum for our migration to Drupal. Rachel’s articulation—and subsequent posters’ agreements—of the challenges of working with CMS builders in Agile mode to craft content and system simultaneously has raised for me a few thoughts.

Waterfall Content: Must we adopt the monolith?

Traditionally, software systems have been built by the “waterfall” method. An elder child of “scientific management,” the waterfall sees development as a long, linear sequence of requirements gathering, followed by design, followed by building and coding, and wrapped up with testing before release. Without going into a complete review of the difficulties with this method, its underlying principles suppose that it is possible to foresee all the features and details of a system in advance, so that no change to the design should be required (or indeed allowed) after development has begun.

All the laborers in the process, from the “overseer” project manager to the lowliest coder, must build their part of the plan, and then hand it off to the next phase of the waterfall. Any change to the “master plan” is considered a threat to the success of the project, so a serious set of blinders must be kept in place to preserve the sense of moving forward. By the time the system is delivered, even if it conforms perfectly to the original specifications, it may not turn out to serve its users very well. The waterfall makes no allowance for learning, for creative discovery, or for unforeseen circumstances.

Now, since I’ve become acquainted with content strategy (now about two years, and still a noob!), I have got the impression that large content projects are often done in the same way: Gather requirements, design content models, build templates, create content, and deliver.

And why not? When you’re embroiled in a monolithic CMS project, if any thought has been given to content at all, the system won’t be ready for it until late, late, late in the waterfall. Content types will have been fixed in data capture templates. Layouts will have fused with information architecture. Workflows will have been encoded deep in the CMS DNA. At best, content strategy becomes a parallel cascade that will merge (eventually) with the technical cascade, as the whole project rushes to the sea.

Challenges to Content Agility

Let me draw out some of the themes from the e-mail conversation to which I referred earlier.

I can’t design content in iterative cycles without the “big picture.”

It is a natural panic when abandoning the waterfall, that if we can’t know all the requirements, all the specifications up front, then ipso facto, someone must be expecting us to work without any of them. I’ve heard this cry regularly from waterfall practitioners in my own organization: “But you have to have some idea up front of what you’re trying build!” Yes, absolutely. You have to have “some idea.” You have to have a very clear idea, a rich idea, in fact, a vivid idea of the final product. We don’t, however, need a perfectly detailed idea of it.

The starting point for the Agile/Scrum is an enormous, rich “product backlog,” which includes all the features and attributes that could possibly be included in the final product, captured as “user stories.” These user stories come directly out of strategy: business strategy, market strategy, content strategy, and technology strategy. The whole Team has access to that prioritized backlog from the beginning. Even if the Team is working on specific stories during a sprint, they can infer a general design from any important perspective from the entire backlog in order to guide their work during the sprint.

We use “agile” within the context of a larger “waterfall.”

It is tempting in a disciplined field like technology development to think that methods, like software components, can be disassembled and reconfigured in other combinations, thereby achieving the best of all possible worlds. Of course, “Agile” was first a set of principles set out in a manifesto before it collected any specific techniques. (agilemanifesto.org)

The Agile Manifesto and its extensions stand in direct opposition to the waterfall:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

These principles were articulated in this way because the latter of each pair was considered a principal impediment to the former: Process deadens individual interactions. Documentation delays completed work. Contract negotiation undermines collaboration. Rigid plans shatter in the face of change.

So in my view, the fundamental philosophies of the two approaches are direct opponents. I don’t think you can do both to any real benefit.

Specialists sit idle if they aren’t involved in the stories in this sprint.

Agile refuses to believe that work must be sequential. Each sprint is planned according to the prioritized backlog, the needed skills to fulfill the user stories, and the available resources. A fully-utilized Team should be able from the full range of stories to select enough work to keep everyone fully engaged during the sprint, and it’s the responsibility of each member to estimate his or her capacity. But at the same time, the Team doesn’t have to limit itself to the current sprint backlog.

In addition, a sprint is simply a “timebox” into which the Team plans its work. Saying that you have “potentially shippable software” by sprint’s end doesn’t mean that you don’t work on anything but the stories to be completed during the sprint. In fact, the Team must always be looking ahead to future sprints, so that if there is “prework” to do before future stories are selected, the Team needs to plan when and how that work will be done within the sprints.

Because some work is dependent on other work, someone will get left at the end with too many tasks and not enough time.

Part of the Scrum philosophy is that the whole Team is responsible for the success of the whole. It’s a team issue, rather than a methodology issue if the work is not evenly distributed, or if the Team is in danger of missing its commitments. It is also important to expect that over time the Team get a better sense of its own process and relationships. One sprint or two of someone getting left holding the bag should be enough to raise a flag to the Scrummaster: Something’s not working, and that’s not the fault of Agile/Scrum, but of the Team’s ability to select and complete an appropriate number of user stories for a given sprint.

Agile is too loose to “manage” large content projects successfully.

I have also heard it said that Agile development would work if human beings and their projects were more predictable. Also, I have heard that the larger the project the more important hierarchy and sequence becomes. These are exactly the myths of “scientific management” and its child, the “waterfall.”

• A large system can be controlled with the proper structure and oversight.
• If they work hard enough, people can be predictable.
• Error and inefficiency are the results of carelessness and poor planning.

It is counterintuitive, but true nonetheless, that waterfall approach cannot work as long as any human beings are involved. We are inherently unpredictable. We learn. We communicate ineffectively and incompletely. We make mistakes. We fail. We discover. We invent. We play.

Agile and Scrum accept the ultimate truth that no system can be controlled or predicted as long as human beings are involved. Instead, by breaking the work into short bursts, emphasizing conversation and regular inspection over the course of iterative and incremental work, and accepting change as inevitable, it becomes possible to:

• Minimize the long-term impact of inevitable mistakes.
• Take full advantage of humans’ creativity and inventiveness.
• Move forward without being paralyzed by uncertainty.

Your Platform Needs to be Agile, Too

As a final comment, as I posted to the e-mail conversation, whether you have the freedom to be Agile depends a lot on the CMS you’re using. A monolithic platform that was designed to be implemented according to the waterfall—get all the requirements together, build it, launch it, and don’t make any changes—can absolutely kill any flexibility that an Agile approach might have afforded. It’s well and good to say that your CMS developers are using Agile techniques, but if it requires tons of rework to change the content templates because you learned something later on that shifted your modeling, then you’re really still working under the waterfall.

On the other hand, a system like Drupal, can handle lots of global change as the sprints progress, so it actually supports the Agile process better. For more idea of how that works, look for presentations by Rob Purdie at The Economist.

We owe Jeff Foxworthy of debt of gratitude for this comedic formula, and I think that it serves us well in content strategy. We who work in the content of websites generally are already doing “content strategy,” because being a content strategist is really more about who you are and how you do your job, than your job title or responsibilities.

You just might be content strategist if:

• You spend a lot of time looking at websites, wondering, “What am I supposed to do with THIS??”
• Your internal customers tell you that they want you to build them their own section of the website. They provide you with wireframes and a new logo because they say they don’t want it to look like the REST of the site. For content, they provide you with 10 “webpages” of rambling business gobbledygook that could really be edited down to one bulleted list. They think you’re being difficult when you suggest that no one’s going to read it because it doesn’t say anything.
• You break down people’s monolithic documents into manageable chunks, so that people won’t have to wade through them because you know that creating content for the web isn’t just about text, text, text, and annoying pop-up ads.
• At the end of your work day, you look at your organization’s website and think, “Our users deserve better than this.”
• Your favorite websites may not be “pretty,” but you just keep going back to them again and again because you just feel so at home in what they say.
• You approach every content project with two questions in mind: “What does my audience need from this piece?” and “How does this fit in the overall strategy of the website?”
• You squeeze out a little of your day to cull outdated and neglected content from the website because no one else seems to recognize that it needs to be done.
• You have definite ideas when people complain that no one seems to be “responsible” for the content on the website.
• You read “content strategy” blogs and mail lists hungrily, yearning to contribute and feeling like there must be some initiation into this bright and shiny world…

I invite everyone in the community to add to this list. Basically, if you work in content, you’re probably a content strategist, at least in some, small way. So you can tell people when they ask you what you do, “Well, my title is [blank], but I’m a content strategist.” We do that now, anyway, until the titles catch up to our jobs.

In today’s conversation on the Content Strategy maillist, we’re once again struggling with how to show people “what content strategy looks like.” Of course we’re struggling! “Strategy” represents your whole approach—your planning, your understanding, your vision. “Strategy” is about your ideas, your insight into your audiences, and your sense of how best to reach them. “Strategy” is the lovely aroma from the oven when you’ve baked a loaf of bread—and not just any loaf, but the loaf that draws on years of experience and passion for baking.

Strategy: Just do this…

I love—LOVE—Kristina Halvorson’s book, Content Strategy for the Web. Everyone who worries about websites must buy it and read it. It gives the overall shape of the practice and offers nothing but encouragement and insightful advice the whole way through. On the other hand, I think that there will always be two responses from readers, which illuminate the nature of our struggle:

1. Yes! This is what I’ve been doing—now I understand it better, and I can do it better. Thank you!!!
2. Wait! You haven’t told me anything! How do I do that…?

Even when beautifully articulated, content strategy can come across like this:

Master Strategist (from the podium): “Content Strategy begins with understanding your goals and your audiences’ goals and preferences. Then you figure out what content will meet both sets of goals, and you plan how you’re going to create it. And oh yeah, don’t forget how you work out how you’re going to oversee and maintain it.”

Novice Strategist (blank look): “Right. Well, I’ll try that, then…”

Master (click, click, click…):  “Here…Let me show you some really good/bad websites, and we can talk about the good/bad content strategies underlying them.”

Novice (squinting at the screen): “Yes…but what does the strategy actually look like?”

Master (distributing handouts): “Ah, well let me show you these sample deliverables that document the strategies.”

Novice (passing them along): “But how did you come up with these? Are there templates?”

Master (nodding hesitantly): “Well, yes, but you have to adapt them to your own situation.”

Novice (hopefully): “Maybe if I could just see it in action. Are there case studies?”

Master (apologetically): “Yes, but not many: We’re working on pulling them together from other practitioners around the world. I included one in the handouts…”

Novice (reading): “Yes, I see…but my world isn’t really like that…”

Master (glancing helplessly back at the screen): “Well, really, all content strategy is the same: You just understand your goals and your audiences’ goals and preferences, and then you figure out what content will meet both. Then you plan how you’re going to create it, and oh yeah, then finally how you’re going to maintain it.”

Novice (in despair): “OK. I’ll try that, then…”

I mean absolutely no criticism of any content strategist who tries to explain what we do: I think this is just the way it goes when you try to explain something new to someone who’s never encountered it before. We talk with one another, and we nod in recognition: So why the blank looks and frustration when we try to tell others?

Doing and Being: Craft and Art

Content Strategy, like any field of endeavor, has two aspects: Craft and Art. In that order. For a reason. (Homage to Ian Alexander of Eat Media <g>)

Craft is about the doing of something: Skills, tools, techniques, artifacts, and expertise. The Craft is easy to watch, its results are easy to see, and its techniques are usually straightforward to demonstrate. That’s why we tend to demonstrate Craft first when people ask about the Art. We show the deliverables, give examples of good and bad, and tell stories.

Art, on the other hand, is about the being of something: Perspective, wisdom, creativity, perseverance, and experience. You can feel the power of the Art emanating from the artifact, and you can recognize the authentic wisdom in the artist, but that’s as close to it as you can get.

So when people read an excellent book on content strategy, those who have enough experience in the craft—those who have already been doing it—recognize what they already know: “Yes, of course!” And those who haven’t really started, don’t recognize it: “No, you haven’t told me anything!” The answer is dissatisfying because the more they understand what it is, the more clearly they see how complex it is and how much practice it really takes to do it well.

It is but a glimpse…

By all means, we who are doing content strategy should compile our deliverables and case studies for the benefit of those who want to learn, and we should tell our stories about what we do to anyone who will listen, but we must also acknowledge that as “artists” in our field, there is no way to convey all at once what we have spent our careers compiling.

And one more thing: We must not suggest to anyone that what we do is either easy or straightforward. Saying that only makes newcomers feel like they can never be successful. I know when experts say something is easy, they mean to be encouraging, but for the novice, it generally has the opposite effect. We just have to own up the fact: Content Strategy takes as much time to learn as any other discipline worthy of our effort. It can be learned, and there are tools to help, but it does take significant practice and support from mentors. So dive in! You can do it! It will just take a little while to find your way, and we’re all here to help!

Paul Krugman has a great editorial in the New York Times today, wherein he criticizes economists (and the Minneapolis Fed’s president in particular) for saying that unemployment is deeply rooted and therefore difficult to solve. It begins like this:

“What can be done about mass unemployment? All the wise heads agree: there are no quick or easy answers. There is work to be done, but workers aren’t ready to do it — they’re in the wrong places, or they have the wrong skills. Our problems are “structural,” and will take many years to solve.”

And then he said something that sounded a gi-normous gong for me:

“But don’t bother asking for evidence that justifies this bleak view. There isn’t any.”

I encounter this phenomenon time and time again in my efforts to advocate for the users of the websites for which I’m responsible. Content owners will come to me with all sorts of statements about who’s using their content, what they’re using it for, and why the way they (the content owners) think the content should be formatted, organized, etc. is the best way for their users.

But when I ask, “How do you know that?” They immediately perceive a roadblock to accomplishing their objectives. When I show them survey results that call their statements into question (even if the data don’t contradict the statements directly), they get angry, and tell me that they’re the content owners and that it should be done the way they want it. I’ve taken sometimes to calling some of them “data-free.”

“Common Sense” is a dangerous basis for strategy…or almost anything, for that matter. In fact, rather than  common “sense,” we ought to call it “Common Presumption.” If I were to upack the sentence, “It’s just common sense,” I would restate it as:

“This is what I believe to be true because it draws upon a reservoir of beliefs held by people who are like me, who see things in the same way as I do, and who are close to me, and so we don’t need to look any more closely at the situation.”

Why is that? Why do people not want to look more closely at the situation? Why do people not want to know the “truth” about the phenomenon they understand by “common sense?” And more importantly, why do we allow each other to get away with it?

I think part of the answer is fear: Fear of being proven wrong. Fear of having to rework an entire understanding of the universe. Fear of having to work out a whole new set of principles about how it all works. I can sympathize with those reasons. It’s exhausting (and it’s also why psychotherapy takes so much work). A little bit of information can be a fundamental threat to one’s worldview.

But on the other hand, why else are we engaged in this work? Content owners: Don’t you want to know that you’re accomplishing what you say you want to? The cynic would say, “Probably not. They just want to check off their objectives for the Balanced Scorecard.”

I don’t have any simple answers either. In the United States, we’re not really taught critical thinking anymore. Some of the skills come from science and math, it’s true: The scientific method is deliberate and at its best, is to be used precisely to counteract “common sense.” But some of the skills are part of art and literature, too: Being able to distinguish our own perspectives from others’. Being able to hold multiple perspectives simultaneously and to interpret where they do and don’t cross.

To my content owners (and yours!) I say, “Don’t believe everything you think.”–At least until you ask your users directly and gather some evidence to see whether you’re right.

I was not able to attend the several workshops on “taxonomy” at the recent WebContent2010 conference (#wcconf) in Chicago: Tough choices were made. Yet I think I got a lot out of those workshops because of the seriously faithful tweeting coming out of them, and when I said so to some new friends, they almost all said, “How? I didn’t understand any of it…overwhelming.” I replied that when you follow a tweetstream, you only see what people understand, already interpreted for you. (Which is a recommendation, really, to follow conferences you can’t attend: Done well, the tweets will give you at least the essential points.)

Amid the summary tweets of the workshops’ content, however, I saw comments such as these:

“A workshop and a session on taxonomy and I’m still confused. Is it just me? #wcconf” – @EvanKittleton

“Ouch. My head hurts. Taxonomy not an easy beast to wrestle. #wcconf” –  @cc_holland

A lot of the confusion centered on how the idea of taxonomy relates to—and differs from—other elements of Information Architecture, such as sitemaps and navigation. Are they the same thing? Is it just your metadata?

With the guidance of my best-bud colleague Becky Bristol as technical reviewer (@paintingblue) I’m going to try to “disambiguate” it, that is, to explain and clarify.

Disclaimer: I’m an explainer, not a taxonomist, so if you’d like to help with the definition, please by all means chime in.

The Roots of Taxonomy

“Taxonomy” is an ancient scientific practice. It means to find names for things. In naming things, you try to figure out how sets of things are related to one another, so that each, unique item will not only have a unique name, but also a reference to the others to which it relates.

Taxonomy creates a hierarchy of inheritance, from general down to specific and back: A giant tree, on which there is a unique place for every item, like the leaves at the ends of twigs at the ends of branches connected to a trunk and running deep into the earth.

In order to build a taxonomy in the scientific sense, you have to create a framework that tells you how to name a thing. This is the “schema.” The most famous schema was created by Carl Linnaeus, an 18^th Century Swedish botanist, to categorize and name life on Earth. It has eight, major taxonomic ranks:

Domain -> Kingdom -> Phylum (botany)/Division (zoology) -> Class -> Order -> Family -> Genus -> Species

If you’re REALLY geeky, you can lay it out in Latin:

Regio -> Regnum -> Phylum/Divisio -> Classis -> Ordo -> Familia -> Genus -> Species

There are only certain terms you can put into those fields. Imagine drop-down boxes from which you MUST choose. Let’s try it on ourselves, humans:

When the terms don’t apply at a certain point, then you get to pick a new term, which at that point, creates a new branch. If you find a new item in nature, something that hasn’t been named before, you get to name it yourself, but you will use the same set of terms down the tree as far as you can to demonstrate your new species’s relationship to all other life.

Taken altogether, this classification system becomes the official way of understanding the whole world of animals, plants, and bacteria. Taxonomy is powerful because it is universally adopted: You could try to work out a new system, but then you’d have to explain it to everyone and get buy-in for it to mean anything to anyone else but you. It is at this point that we make the transition to the Web…

Taxonomy on the Web

Now at some point, the word “taxonomy” was appropriated by information architects to talk about web content. When one discipline borrows from another’s, the meaning and use of the term can change significantly, and so “taxonomy” doesn’t mean to the web professional quite what it means to the biologist.

A website’s taxonomy describes how all the content relates to each other. Through its rigidly controlled network of meaning, there is a way to say with confidence:

“Item X and Item Y are in the same group. When you look at Item X, you may also be interested in Item Y.”

We take this kind of connection for granted these days because Amazon and other e-commerce giants have made such ubiquitous and successful use of taxonomy to sell related things, but it’s really quite difficult to establish those kinds of relationships in your content without taxonomy.

In summary to this point, then, “taxonomy” on a website is a classification system that maps all your content to other content. Taxonomy on a website creates a scaffold that holds your content together.

Not one taxonomy, but many

It gets a little more complicated from here. Whereas in a biological taxonomy, we’re dealing with only one dimension of relationship, the ultimate relationship of one species to another through its name, on a website, there can be many classification systems to govern the relationship of content along many dimensions.

Let’s take with a clothing retailer. The most basic taxonomy would divide the products into groups of “kind” to answer the question, “What article of clothing is this?”

Clothing for the upper body

• Shirts
  • Blouses
  • T-shirts
  • Polos
  • Turtlenecks
• Jackets
  • Blazer
  • Windbreaker
• Sweaters
  • Cardigan
  • Pull-over
  • Vest

Clothing for the legs

• Pants
  • Dress pants
  • Jeans
  • Shorts
• Skirts
  • Full-length
  • Wraps
  • Culottes (really a hybrid)

Accessories

• Jewelry
  • Rings
  • Earrings
  • Watches
  • Necklaces
• Belts
• Hats
• Bags

So far, so good. We have a system for identifying items by basic type. But that’s not so good for sales.

There will be, then, additional taxonomies to build up a multidimensional system that organizes products into classes: For women or men, girls or boys; for casual, work or formal contexts; for outdoor or indoor; by color; by season; by ethnic origin; and so on, and so on…

But that’s just the products. There will be other content that accompanies these products, and all that content must also be organized into categories.

• “How to” content might include tieing neckties, caring for leather, assembling an ensemble for an evening out in Paris.
• “About us” content might go through all the ways that this company works for environmental activism.
• Product information might include stories about where the materials came from, or who made them.

The taxonomy must account for all these dimensions of content description and classification, so that when you pull up the product page for that pair of shoes you’re considering, you also can see:

• What other colors are available?
• What other shoes are in its class?
• How do you care for them?
• What accessories would complete your outfit?
• How have other customers worn this item? (From their photos)
• How long it would take to get them if you clicked the button right now…?

Taxonomy implemented through metadata

All this work of understanding the interrelationship of content has a specific and practical end: Metadata.

It is beyond the scope of this article to explain the process of developing taxonomic systems and how they are then translated into metdata for your web content. It is crucial, however, to recognize that having a clear, controlled system of metadata, which is then meticulously and consistently connected to your content, is the only way to ensure that your search and coordinated applications serve up the content the user expects, in the language the user expects, in combinations that make sense to the user.

Rich, interactive experiences require taxonomy

Creating rich internet applications (RIAs) is partly about the technology to evaluate and serve up all these connections, but it is impossible without care, design, and maintenance of your content’s taxonomy.

Again, unlike our scientific counterparts, there can be no, single, universal taxonomy for web content because each content domain has its own context of purpose, vocabulary, and peculiarity.  There are commercially available taxonomic systems to get you started, but they all have to be evaluated for your specific purpose, and there will always be adaptation of the metadata.

Taxonomy, Navigation, and Sitemaps

A lot of the confusion in the workshops dealt with how a website’s taxonomy relates to the other aspects of its information architecture. As we explore these concepts, keep in mind that when done well, the taxonomy is completely invisible to the user. It just makes everything run smoothly.

Sitemaps

The sitemap reveals the website’s overall organization. Every bit of content on a website needs a primary “home.” Ultimately, when you reach a content item, you are (virtually, of course) in a particular location on the site. The information architect’s job is to choose from the infinite range of organizational possibilities to anchor the user experience, which then is the foundation for the richness that the taxonomy creates.

The sitemap probably will reflect some basic aspects of the taxonomy underlying the content, but when you consider the richness and complexity described above, any relation between the sitemap and the taxonomy will be loose.

Navigation

Navigation is more closely related to the sitemap than to the taxonomy. The main navigation provides the user an organized path around the website, intended for browsing. Like the sitemap, it may reflect some aspects of the taxonomy, but it doesn’t have to.

The taxonomy will enable, however, the local navigation options through access points to content elsewhere on the site, reached through the relatedness of content.

IAs help you put it together!

It’s the job of information architects to work all these intricacies out. The skills for designing the taxonomy and associated metadata are extensive and precise. The content strategist helps to define the content domain and the language that will best represent it, but the IA will be able to build an organizational framework that links the content domain with the technical wizardry that serves up the user experience.

In conclusion, as my best-bud Becky says, “There is no right or wrong way of [creating taxonomy]. The trick is to come up with a taxonomy that works for your users.”

I hope that this article has helped to clarify the definition of taxonomy and its application. Please offer corrections, amplifications, and clarification. It’s a matter to wide importance, and we need to get it right!

This week, @dhh from @37signals published an article on the insufficiency of the term “content” to mean…well…content. I understand. It’s like how I love the container label “resources” or “tools” to hold all sorts of items: People always seems to suggest them for labels, yet when you turn it around and ask, “So…what would you expect to find in a drawer with that label?” The only possible answer is “Resources.” So helpful.

“Content” is in many respects an unhelpful label because it’s often expanded as “everything on your website.” While it can be useful to distinguish the “stuff” on your site from the “design” of your site, or its “architecture,” “content” doesn’t tell you anything about what kind of content you envision there, nor what that content is supposed to do.

Why “content” isn’t enough

There are practical ramifications to the term’s generality. When “content owners” are talking about what they own and want to convey, they themselves are rarely able to put it into specific buckets, let alone craft the contents of those buckets to succeed for their intended audience. Recently, I was working with an HR group that wanted to “update” their content. I suggested that they “explain” the HR processes and policies, which hadn’t necessarily changed, and so didn’t need to be updated. It caused a big fright, though, because no one had ever undertaken to “explain” how it all works, and suddenly it was all at risk of being revealed and clear. They weren’t sure they wanted to go there.

So I have been considering trying to classify content, literally into “classes,” according to what those classes “do” or “intend.” These content classes differ fundamentally from content “models.” A content model is the encoding of a parcel for a content management system, comprising the metadata and components that bring it to live on the web page. Content classes are more like your content goals. For example, you have a paragraph of text on a web page (or a video, or a photo, or a chart). That content is sitting there trying with all its might to do something. What is that something? Is it a description? Is it an explanation? Is it an opinion? Is it a sales pitch? If you don’t know what that content is trying to do, how can you tell whether it has succeeded? The answer will be specific to that class.

For exmple, an “explanation” intends to make something clear to the reader, or at least to answer the reader’s question. Has the reader understood the explanation? At least we know the right question to judge its effectiveness. Another example: An “overview” intends to give the user a good sense of all the material covered in a particular area. Can the user, after having read or watched the overview, describe the general layout of the material about to be covered?

A Taxonomy of Content

I offer this first attempt to classify to engender conversation in the Content Strategy community. I’ve just brainstormed it into existence today. I want to highlight that these classes are irrespective of “medium.” A block of text, a video, or a drawing might all be intending to accomplish the same goal. So while you might think of text initially as you read these classes, try to think also of other media for doing the same thing.

As I’ll explore later on, these classes and subclasses can then be combined into compound and complex systems of content.

Exposition

Most content is just straight out “expository.” It relates some topic, it teaches something, it expands an idea, or it conveys a series of facts or ideas in prose. Some of the sub-classes of exposition might include:

• Definition
• Explanation
• Instruction
• Description
• Biography
• Story
• Demonstration
• Interpretation
• Exploration
• Comment
• Analysis
• Theory
• Framework
• Translation

Evaluation

Content often offers an evaluation of something, whether a product, a vacation, an idea, or a candidate. There are many types of evaluations on the web, from blog rants to customer reviews. These include:

• Recommendation
• Critique
• Review
• Report
• Comparison
• Opinion
• Rating
• Complaint

Summary

A summary is different from an exposition because it reduces content into a more focused, compact form. We use them all the time:

• Overview
• Introduction
• Background
• Context
• Abstract
• Conclusion
• Bullet
• Update
• Profile
• Message

Persuasion

There are many kinds of persuasive content, much of it marketing, but sometimes it’s just trying to win over people’s views or call them to action. We might think of:

• Advertisement
• Case
• Position
• Slogan
• Call
• Invitation

Announcement

Communities rely on brief bits of information that call attention to things. I call these announcements, but they also include all the practical messaging on the website:

• Warning
• Notice
• Error Message
• Alert
• Reminder

Boundary

Content that draws the line around a topic or field of endeavor indicates a boundary. Lots of web content is specifically intended to draw lines around thing, like the terms of service, or the return policy.

• Rule
• Priority
• Specification
• Standard
• Guideline
• Policy
• Protocol
• Procedure
• Terms

Inquiry

Any effort to gather information, whether practical or rhetorical, fits into the inquiry class.

• Question
• Survey
• Request

List

Web pages are full of lists, of all kinds. A list is a fundamental content class, and includes any simple collection of items:

• Gallery
• Sequence
• Inventory

Reference

Reference content simply points to other content somewhere else. Like in a paper when sources are listed at the bottom, or when one article points to another, related article. These include:

• Link
• Citation
• Source
• Date

Enrollment

Every form to sign up for something, and any shopping cart to buy something, and any commitment to receive e-mail blasts fits within the enrollment class.

• Registration
• Subscription
• Purchase
• Application

Location

Location content just helps in wayfinding. It includes signs and signals, maps, breadcrumbs, navigational links, and menus.

• Map
• Position
• Path
• Coordinates
• Directions
• Navigation

Plan

Content that makes the expected course of action clear is a plan. Conference programs, educational curricula, and menus of options might go here. I’d also include processes.

• Agenda
• Process
• Curriculum
• Menu

Identification

A lot of the content on websites serves to identify things, like product names, company logos, intended audiences, authors, article titles, list headings, and even deep in the code, the “class” assigned to html elements.

• Name (Title)
• Target
• Logo
• Icon
• Label
• Heading
• Example
• Class

Data and Visualization

When we publish data, we often include some sort of visualization. Among this class you might find:

• Schematic
• Chart
• Table
• Dataset
• Model
• Fact
• Statistic
• Illustration
• Photograph
• Organization chart

How content classes become content types

OK, so if my ideas are helpful, if you were looking to build a new kind of content for your website, you could use these classes to make sure that you ended up with a full content type. Taking the example from my previous writing about content modeling, if you were launching a cooking site, each recipe might draw upon a whole series of classes:

Recipe

• Description of the dish and its origins
• List of ingredients, and perhaps of the tools required
• Instruction in the preparation of the dish
• Demonstration of the more obscure, technical steps
• Specifications for the quality of ingredients, the times to cook, and the temperatures.
• Illustration of particular steps and the final product.
• Recommendations for serving, or for adjustments from other cooks’ commentaries
• Plan for a complete menu to accompany this dish, and perhaps a schedule for make-ahead preparations
• Ratings from other cooks who have made this dish

Just the beginning…

In conclusion, I think of this sort of taxonomic exercise as important both to combat overly-general labels and to provide some way to evaluate content effectiveness. If you find this kind of approach helpful, let’s see whether we can’t build it out into some useful framework.

A couple of weeks ago, Kristina @Halvorson raised a twitter-storm over e-zines and conferences that feature white men exclusively. In their defense, and judging from their apology, I think probably they didn’t plan to exclude women (or other perspectives). It probably somehow just sort of happened that way. They wanted to feature the best, most interesting figures they could, and those just seemed to end up white guys.

This sort of thing—that white men show up at the head firms, on the attendee lists, on the presentation line-up, on the bookshelves—happens all the time, and I believe it is, as @halvorson and others have said, an issue of diversity and inclusion. I am stepping off of the topic of content strategy for this post because I have some experience in being part of diverse community, and because I believe it absolutely essential that our community—that any community—learn what diversity and inclusion mean, why they’re important, and how to nourish them.

Something about my background

When I was in college, I studied French in Tours, France, which taught me first-hand about culture shock and the power of learning to live in someone else’s culture. I recommend this experience to every human being for gaining perspective on one’s own culture: You cannot understand yourself until you understand someone else. You can only understand being in the “majority” when you have experienced being in the “minority.”

I began facilitating “diversity workshops” back in the 90s, when I was an Employee Relations Rep in Rochester, NY. If you work for a corporation, you’ve probably been through a hundred versions of such workshops. They generally include activities and information to highlight several, important truths:

1. Diversity is not exclusively about women and African Americans, nor about Equal Employment Opportunity laws, although it does indeed address these aspects, but encompasses all the ways in which people differ from one another.
2. We all bring our biases, which are largely invisible to us, to new encounters with people who differ from us. We tend to trust and therefore favor those who are most like us and to have different expectations (often higher) of those who are least like us.
3. Diversity is not about tokenism or being politically correct. We cannot point to one person of color in a room full of white people and say, “See? We’re not all white.” Nor can we learn the “right way” to talk about things, so that the issue goes away. Diversity is about seeing lots of people of all kinds in the group, and learning to talk with them (more than about them) in terms that they choose for themselves.
4. We are all complex and multifaceted, and the goal of “diversity” is to create a working environment in which everyone can contribute her/his best work, which is known as “inclusion.”
5. Diverse teams are harder to manage, but they produce better work.
6. Stereotypes are not the same thing as generalizations. It’s all in how you use them. “Stereotypes” reduce people to a few characteristics, so that we don’t have to go any deeper to understand them, while “generalizations” identify characteristics as guides for understanding differences.

When I worked for Ernst & Young, my last project was managing the development of an online course in cross-cultural communication, which really is just another form of diversity education.

When my partner moved from Tuscaloosa to Cleveland to be with me—from the Episcopal Diocese of Alabama to the Episcopal Diocese of Ohio—we were, I believe, the first gay couple to be invited to the “new clergy weekend” at the time, and we have been open in the diocese from the beginning.

Since 2000, my partner, an Episcopal priest, has been working with St. Luke’s Episcopal Church, which ten years after our start, has grown into a vibrant and fully diverse Christian community, and its growth continues to accelerate. We attribute our diversity, and how we live into it, as one primary driver of that growth.

What we mean by “diversity” and “inclusion”

“Diversity” and “inclusion” are often spoken together, especially in business organizations. One could get the impression that they’re the same thing, but there are important distinctions. Diversity is a prerequisite for inclusion because an organization can be diverse without being at all inclusive. Diversity is hard, and inclusion harder.

Diversity: Who’s here, and who isn’t?

Diversity is about the composition of your community. A homogenous community is made up people who are all very much alike in important respects. A homogenous community is comfortable because its members can communicate with one another without a lot of misunderstanding borne of differences. Of course, no community can be completely “homogenous,” as every human being is unique, but the more homogenous the community, the harder it is for its members to have perspective on their own identity, their own biases, and their own values.

Inclusion: Who holds the power?

Even in diverse communities, it may be similar people who make the decisions, who enjoy prestige, who are chosen for leadership, or who feel most a part of the group, even when they are not the most numerous in the group. “Majority” isn’t always about quantity, but it’s always about influence. It is the “majority” culture that prevails in the seats of power, wealth, and influence, whether the people in those seats represent a majority of the population.

Inclusion is about the diversity of those who hold the power and esteem in the community. This distinction is critical and germaine to the conversation on Twitter because while a community must first tell itself the truth about its basic composition (who’s not here), it can only benefit from diversity if it can tell the truth about its inclusiveness.

Questions to assess inclusive diversity

I don’t believe that communities achieve real, inclusive diversity very often, nor that inclusive diversity just “happens” to a community. Inclusive diversity requires intention and care. Inclusive diversity requires learning to live in new ways. And inclusive diversity requires doing things that don’t seem logical, in order to get it started and let it take root.

Here are a few questions that can help us get outside our own perspective to begin the journey.

Who’s here?

A community must actively nurture diversity by learning to see “absence.” When a community is homogenous, it seems perfectly normal to recognize one another. Seeing who’s not here requires tuning into the humanity missing from your group. It’s easiest to begin with sex, color, and other outwardly visible characteristics. Are we all men? Are we all white? Are we all about the same age? Are we all straight? Do we all dress alike?

It’s important, however, to move quickly into deeper realms of difference. Do we live and work in major metropolises? Do we live in the same kinds of neighborhoods? Do we use the same slang? Do all have similar education from similar institutions?

Once we’ve built a sense of who’s not “in the room,” we can begin to explore the impact of homogeneity by assessing who holds the power.

Whose voice is heard?

Another way to assess the diversity of a community is to look at who’s authoring the books and articles that people get to read, who’s invited to present at conferences, whose names are most recognized, and who shapes the opinions throughout the community. If the people who get to hold the microphone are all alike in some way, then the community is deprived of new voices, different voices, dissenting voices, and perhaps startling voices.

Who’s making money?

I hesitate—almost—to say it, but the competitive spirit of business is probably in direct conflict with inclusion.

Capitalism generally values getting the business by beating out other people who could have it. But when a particular kind of person seems to hold the microphone, to get the business, to publish the books, and to make the innovations, one must as a matter of conscious suspect that other factors are at work in addition to those folks’ innate intelligence and their hard work.

Becoming an inclusive community requires a conscious effort to “make space” for people who are absent. That means sometimes standing aside on the platform, on the shelf, in leadership, and if we’re very committed to it, in business. Many organizations are working to make space under the banner of “supplier diversity,” signaling that they are willing to give special consideration to bids from minority-owned businesses. In order to ensure that minority-owned business get a fair shot, (and I won’t go into what constitutes a “fair shot” here), the organizations must ensure that they are somewhere in the pool of bidders.

Who leads?

But there’s more. Inclusion means working to share authority and power. Diversity in leadership is at least as important as diversity in membership, and at a certain point, it’s important for leadership to “turn over,” and for different sorts of people to lead. If you look at the agency partners, if you look at the elected government, if you look at the C-Suite, and they’re all white guys—except for the HR director, who’s a woman, and the diversity officer, who’s African American—then there is a lot of work to do. Those who hold the power to promote must not allow themselves to fall into the “we’re just hiring the best person for the job” trap. As above, if all the “best” candidates seem to look alike, then there’s something else going on.

So what? Why should we worry about any of this?

The decision to work toward diversity and inclusion in any community is hard, and the journey is fraught with change. After all, the goal of diversity and inclusion is not just to look different for its own sake, but to be changed, and no one likes that. To become a diverse and inclusive community means that we will all be changed in ways that we cannot predict or control, and certainly, no one likes that. But we must.

Diversity is safer

When you watch catastrophes of society or economy unfold, look for sameness in those at the epicenter. Homogenous groups are prone to look inward and to agree on decisions quickly. They can overlook things that lead into crisis. In diverse communities, we have to learn to accommodate different points of view and work to involve more people in decisions, which are powerful, crisis-preventing skills. Over time, we all develop broader perspectives—on ourselves, as well as on others. Diversity is safer because we learn to look more outside our own interests for the good of the community.

Diversity is richer

When the people of influence are all alike, in the end they can fall into the trap of thinking that they’ve learned all they can from others. Inclusive diversity ensures that no matter how much you learn, there’s always someone new who’s going to shake things up and make you revise your whole picture, which is great, once you get the hang of it. In a community that prizes experts, this can be especially disconcerting, and we don’t generally have the skills to say, “You know, I now have to reconsider everything I’ve ever believed about this…” But that’s the way forward. We always need new voices of widely different perspectives, so that together, we get to a greater truth.

Diversity is good

In the end, I believe that the greatest good for all of humanity can only be achieved through diversity. As we come more and more into contact with people who differ most from us, we need to have built the skills to make space for them in our own circles: listening, questioning, welcoming, and changing.

So yes, we need to consider seriously who’s on our brochures. We need to consider whose voices we’re hearing. We need to pay money to see and hear people we’ve never heard of. We need to decide to bring new perspectives into our workplaces. And we need to make space for others to stand beside us. It’s hard, but it’s the only way to the best.

It’s only recently that I’ve come to appreciate a hard truth about myself: I’m a content geek. I know I’m not the only one. If you’re reading this post, you’re probably a content geek, too. But if you’re like me, the realization that you might be fundamentally different from the normal people around you has been a long time in coming, and it’s only after years of stripping the formatting out of other people’s documents and spending more hours in “code view” than in WYSIWYG that it becomes clear: Not everyone can do what we do.

And as a content manager, I have a terrible choice to make: Do I apply my content geek powers toward crafting web content myself, or do I hand the keys of my CMS over to the content owners, who say that if only they had access, they’d create and maintain all their own content?

This is a timely question of content strategy because not only does a content strategy shape the form and substance of your web content, but it also specifies how it gets designed and produced. So who’s going to do it: The geeks or the owners? Two recent blog posts make the case very well:

Seth Gottlieb at Content Here debunks the “Myth of the Occasional CMS User,” and calls all organizations not to believe the promises:

“Often, one of the big justifications for a CMS is removing the webmaster bottleneck and delegating content entry to the people who have the information. The implicit assumption is that everyone wants to directly maintain their portion of the website but technology is standing in the way. But if you visit a CMS customer a while after implementation you are likely to find that the responsibility of adding content is still concentrated in a relatively small proportion of the employee population.”

Jeff Cram at The CMS Myth expands on Gottlieb’s post and advises that you “Stop Letting People Use Your CMS.”

“So, I’ll take it one step further than Seth. Stop letting people use your CMS unless they are an integrated part of your web and editorial team and need to be in it on a regular basis. Even then, they may not need to be in the tool.”

What is Content Craft?

Being a content geek—at least for me— means that I see the crafting of content through insect-like, multifaceted eyes:

First, there’s the substance of the content. What is it? For whom is it intended? What’s its underlying message? What are we expecting it to accomplish?

Second, there’s the fashioning of it. Have we chosen the right language, the right images, the right arrangement, the right granularity, and the right length to accomplish our goals?

So far, so good. Any good writer can do as much.

But then, there’s the structure of the content. Not in the sense of how the piece is composed, but of the technical aspects of the headings, the various kinds of paragraphs, the selection of appropriate keywords for linking to other content, and it’s position within the website.

THEN, there are the content modeling and metadata. How is this class of content the same as or different from other classes? Into which section of the site does this content go? How will it be tagged so that it comes up in the right places or at the tops of searches? Can I really build this specific set of attributes into my CMS templates?

And finally, there’s the markup. What HTML elements are we using (and NOT using)? How have we chosen identifiers and classes for the CSS code, so that it reads like Ibsen in the source view?

Content geeks can manage all these facets like playing with Legos. We have an instinctive compass that points true north: We connect the pieces across web space and keep the links consisent.

Subject Matter Experts, Not Content Experts

Once upon a time, I was all about empowering my content owners. I tried to teach them the difference between “bold” and a “heading.” I tried to teach them to use “styles” in MS Word, rather than formatting each piece on top of “normal.” I showed them how beautiful and consistent content could be when you paid attention to these simple details, how you could instantly reshape the whole piece by shifting templates. Their eyes would just glaze over, or they would simply decide that it was far too much work. Now, I’ve decided that for the really important stuff, I do it myself, and with pride.

In the end, there is a profound difference between subject matter expertise and content crafting skill. Every now and then, the two can coincide in a single human being. For the most part, however, when content owners pour their subject matter expertise into web pages, someone else ends up going through it to “clean it up,” not out of a pathological need for beautiful code, but because the whole user experience will be best served by clean, consistent, well-crafted content. And isn’t our website really there to serve the visitors?

The Bottleneck is the Real Work

When your CMS sales rep sings the praises of the system you’re evaluating, and especially how content owners’ creativity and productivity will be unleashed because they won’t need any “technical skill” to build web pages, don’t you believe the bull. Publishing web content takes technical skill and time, no matter what system or tools you use, and just as in every other professional endeavor, it is best entrusted to web content gee…er…professionals like you and I.

When I served as “information strategist” for the Episcopal Diocese of Ohio from 2000 to 2006, I was responsible for connecting over a hundred parishes, over two hundred clergy, and over twenty thousand communicants with the bishops and diocesan staff, and with one another. In the year 2000, the main diocesan communication channels included the US mail, phone calling trees, limited e-mail use from personal lists, and a diocesan newspaper that came out eight or so times per year. There was a website maintained by a volunteer, but this consisted mainly of parish listings, intended for people outside the Episcopal Church.

Now, I’m married to an Episcopal priest, so I had a particularly personal stake in how the communications went. The clergy’s main complaint was that every day, as many as ten identical, No. 10 business envelopes arrived from the diocesan offices. Because they were indistinguishable one from another, they tended to sit together in the inbox until they could turn their attention to them. Besides these envelopes, there was no easy way to find out what was going on in the life of the diocese, the practical quotidien information.

We were locked in a non-communicative tug-of-war:

• Parishes and Clergy: “Why didn’t you tell us?”
• Diocesan Staff: “We did. We sent you a memo.”
• Parishes and Clergy: “There are too many envelopes—we can’t read all that!”
• Diocesan Staff: “If you don’t read your mail, then there’s nothing more we can do.”

When I broached the subject with my colleagues on staff, they were not terribly sympathetic: “I read MY mail; why can’t they read THEIRS? They read their mail at home, don’t they?”

So when information was important, we would mail a letter, transmit a copy by fax, shoot an e-mail to let them know it was in the mail, then follow up by telephone to make sure it was received.

I call this strategy “redundancy in pursuit of certainty.” Sound familiar? Has it worked for you? It didn’t work for us, either. In fact, redundant communication produces the opposite effect: The more you “communicate,” the less people pay attention to you, and the smaller their capacity to absorb and retain information.

“Internal communications” often go this way in organizations everywhere, large and small. The technological innovation of the “corporate intranet,” introduced to eliminate precisely this struggle, hasn’t changed it very much. Why not?

The Terrible Truth About People and Information

Truth 1: People will not know a thing until they are ready to know it.

• You know how you can be walking down the same street you walk down every day and you suddenly notice a building and ask yourself, “Has this building always been here?”
• You know how you can plan a big community event for months, and you send out “save the date” postcards well in advance, then send personalized invitations, then advertise it on the local radio shows, then hang big, colorful posters all over town, and then the day before, one of your biggest donors can call you up and say, “I just found out about the [event], and now I can’t make it. Why didn’t you tell me about it sooner??”
• You know how your mother always told you “blah-blah, blah-blah-blah, blah-blah” for years and years, and then one day, you find yourself in a real fix, and you suddenly realize that this is exactly the situation she tried to tell you about all those years…
• You know how Glinda the Good Witch of the North shows up at the end of the Wizard of Oz, and announces that Dorothy’s always had the power to go home to Kansas, but she hadn’t told Dorothy that back in Munchkinland because “she wouldn’t have believed me; she had to find it out for herself?”

Yeah, that’s what I’m talking about!

Truth 2: At that terrible moment, when they’re ready to know, they will ask why you didn’t tell them and complain about “poor communication.”

Then something “clicks,” the stars move into alignment, or two people have a chance meeting where someone asks the right question, and BING! those same people are ready to “know” whatever it was. In that instant, it seems to them that everyone else around them knew this thing—why didn’t they know? How were they supposed to find out? There’s just no communication in this organization…

Truth 3: Nothing can change truths 1 and 2.

You can try any technique you want: You can send redundant e-mail blasts. You can call people up with reminders. You can post eye-catching posters and banner ads. It won’t make any difference. This point cannot be overstated: MORE communication only makes the situation WORSE. As Peter Morville pointed out in his book, Ambient Findability, the human brain hasn’t had a whole-version upgrade in at least 50,000 years (Morville, 2005, p. 45). Until we get one, we will continue to ignore what we’re not ready to know.

Mitigating the Terrible Truth: Create an Information Gathering Spot

Even though you can’t prevent the phenomenon, you can mitigate it. There are ways to improve the odds that people will “know” more often and more easily. They’re not self-evident, however, and they require measured, disciplined tactics over time. I call this strategy the “Information Gathering Spot” because it requires creating a central location in which all information is shared. I recommend it for any situation in which a large group of people–company, community, or society—needs to be in touch, and in which there is a formal body responsible for “communication,” say, Corporate Communications and an intranet.

Cultivate a single “line of sight” for your audience

Any PR person will agree that the über-goal of communication is to have everybody paying attention to you at the same time, so that when you have something important say, they’re already listening. Reaching this Nirvana doesn’t happen on its own, and it doesn’t happen all at once.

• You have to build a relationship with your audience over time, raising your credibility as a communicator, and inspiring trust as a respected source of information.
• You have to put all the information in one place, and direct their attention to it repeatedly and regularly.
• You have to be consistent, on-time, without fail. Whatever system you as the communicator put in place, you have to use it—and get everyone else to use it—in the same way, on the same schedule, for all your information. Period.

Help people be “ready to know”

Permit me a botanical metaphor: The human mind is a fertile—if overgrown—field in which grow all the things we know. The information swirling around us is like seeds, scattered on the wind. When a seed hits a clear patch of ground and sprouts, that’s when we notice something and are able to know it. Many seeds, however, get caught in the underbrush, and they don’t hit the soil immediately, if ever. Eventually, they may, and then they sprout into something we know.

In order to help people know more things, you have to clear this tangled field:

1. Accommodate the natural hierarchy of information needs

Most of what people care about knowing is basic and mundane. If you look at the web analytics for my organization’s intranet, for example, the most popular piece of content is—by far— the cafeteria’s lunch menu, followed closely by the online phone directory and the system in which you look up your paycheck.

This should come as no surprise to anyone: People need to satisfy their stomachs and their wallets before they can think about anything more “ethereal” like our “shared vision.” By providing immediate access to these “reptilian” items, your audience has more attention to pay to other, more “mammalian” things.

2. Make clear why people need to know, and what they’re supposed to do next

People cannot take in “useless” information, and “useless” is entirely in the esteem of the beholder. If it’s unclear why they need to know something, they will dismiss it even before considering it. But marking something “urgent” or “read this!” only confirms its uselessness. Your information needs to convey its own utility and next steps, and this is, of course, the skill of writing.

3. Structure and format your information to be skimmable

Ben Shneiderman, the eminent researcher in the field of information visualization, has made this “Visual Information Seeking” mantra famous: Overview first, then Zoom and Filter, then Details-on-Demand (Shneiderman, 1996). Whether it’s datasets or news items, the principle is the same:

Your users need to be able to skim at a high level (“Overview”) to get a sense of what’s there, then to focus their attention on the categories or subsets of what interest them (“Zoom and Filter”), then to grab the full detail on any single item that they are ready to know (“Details-on-Demand”).

Share responsibility for sharing and seeking

Here are the keys to making this whole strategy work. You have to:

• Transform your concept of “communication” from a one-way broadcast to an all-way information exchange.
• Lower the barriers to participation in the system. Everyone must have some access to posting information. It can be moderated and modulated, but people need to feel that if they have something to share that will be of interest to the organization, they’ll be able to get it out there.
• You have to train your organization to take responsibility for sharing what they know and seeking what they want to know. No one gets to sit back. No passive consumers. If you want people to know something, you put it out there. If you’re a member of this organization, you go see what’s there.
• You have to redefine the role of the official “communicators” in the organization from the being the single source for creating and distributing information to being the facilitator of this organic information ecosystem.
• You have to establish a new social contract for knowing: If people don’t use this sytem to make information available, they can’t expect people to know it. If people don’t use this system to find out what’s going on, they can’t complain about being in the dark. In pursuit of this contract, the “communicators” pledge to maintain an easy-to-use system to which everyone has appropriate access.

It’s as audacious a goal as you’ll undertake, but the return on investment will be huge.

Creating an Information Gathering Spot in the Episcopal Diocese of Ohio

When I began working for the Diocese of Ohio in 2000, I had built only one website of about six pages for my home parish, using MS Publisher. Because a volunteer was maintaining the diocesan website and my own experience was limited, I started fresh on a new, separate website. I invited a few members of my stakeholders for a strategic focus group, to ask them what information they really needed and how I could best provide it to them. They were great: They were practical and had reasonable expectations. They needed to know about events and deadlines, and committee meetings. (There was no central diocesan calendar of events, by the way.) They needed a place to get forms and other documentation. They needed to know about changes in the life of the diocese, particularly clergy changes. They needed all this information to be current and easily accessible in one place.

Based on their input, and on my own research into other diocese’s communication vehicles, I built a four-page website I entitled The Bulletin. If you’d like to see its humble beginnings, go to the “Wayback Machine” internet archive:

• http://web.archive.org/web/20020831050748/http://www.dohio.org/bulletin/2002/07_july_02/07_31_02/BulletBriefs.html
• http://web.archive.org/web/20021028050917/www.dohio.org/bulletin/2002/10_october_02/10_09_02/BulletBriefs.html
• http://web.archive.org/web/20011103210828/http://www.dohio.org/ExpandedCalendar.html
• http://web.archive.org/web/20011010030638/http://www.dohio.org/Downloads.html
• http://web.archive.org/web/20010303130231/http://www.dohio.org/bulletin/About.html

The main page of The Bulletin was called the “BulletBriefs,” which in simple, categorized, consistently-formatted bullets, showed news and announcements, new documents available for download, new events on the new diocesan calendar, and the next meetings of diocesan committees. Each bullet was linked to one of the other three pages: Calendar, Downloads, and Stories. I invited everyone in the diocese to send me the information they wanted other people to know, which I then entered manually into the web pages. I made this pact with them:

• If you give me five minutes every Wednesday, I will make sure you see everything that’s new this week.
• If it’s not in the Bulletin, you don’t need to know it.
• If you can’t get your information in by Wednesday, you can’t require others to know it, at least until next week.
• I will make sure that the information is consistent, skimmable, and well-organized.

Every Wednesday, I sent out an e-mail note to any who wanted it, letting them know that the Bulletin for the week was updated and ready. Whenever people asked me questions that the Bulletin could answer, I would tell them what they wanted to know, but I also let them know where they could find it out for themselves. This continual—if you’ll excuse the expression—evangelism was crucial to the strategy’s success. Over time, people offered suggestions for how to improve its usability, and so the design evolved.

Ultimately, the Bulletin became the framework upon which the entire diocesan website was built, and in response to user requests, the Bulletin turned into an automated e-newsletter informing recipients what’s new in the diocese, and linking back to the website. Although I am no longer on the staff of the Diocese of Ohio, the Bulletin still goes out every week.

Creating your own Information Gathering Spot

The principles of this community-based content strategy are almost primitive, yet they can reshape the corporate sense of what communication is and how it works:

• Everyone who has information shares.
• Everyone who wants information seeks.
• The communicator provides and maintains the place for sharing and seeking.

If you keep these simple ideas in front of everyone, in a few years, your organization will find it strange that communication could be done any other way.

Works Cited

Morville, P. (2005). Ambient Findability: What We Find Changes Who We Become. Sebastopol, CA: O’Reilly Media, Inc.

Shneiderman, B. (1996, September). The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. IEEE Visual Languages , 336-343.

Shhhhh! Look over there!

The Neverland of content strategy is full of wondrous creatures. We invoke their names in meetings. Their titles appear on project plans. We assign them tasks and responsibilities, and we expect them to deliver. Of these legendary beasts, none is more elusive than the Content Owner.

Though we never see them working, like little elves, content owners mysteriously fill our web pages with high-quality, completely relevant, irresistible content. Chanting their spell of “lorem ipsum sit amet dolor…” they spin strawcases to gold and keep every project on-time, etc., etc.

Some of their powers they claim for themselves, and some we confer upon them:

Content owners want responsibility for creating and posting content.

If only we gave them complete freedom and access to the content management system (CMS), content owners could—and would!—take full responsibility for creating and posting all their own content. There would be no more bottlenecks! They would follow the styleguide. They would keep content fresh and current. And of course, because of the CMS’s WYSIWYG editor, they wouldn’t need to learn HTML or tagging.

Content owners are content experts.

Content owners know exactly what they want and how it should appear on a web page. They know how the navigation should work and which labels will eliminate confusion. They require minimal technical support, and can be relied upon to make savvy decisions. This is because…

Content owners understand the deepest desires of their audiences.

Content owners are continually in touch with their audiences and understand their requirements intimately. They have no need of data or testing. They have no time for research: Their content is too important for research, anyway. When cornered and pressed to support their assertions, they turn nasty and threaten spells to bring down the wrath of the C-Suite.

But if you ask me…

I don’t think Content Owners really exist—certainly not in these mythical terms. It’s all superstition, fairytale, and wishful thinking about some of the hardest work in publishing: Content Strategy.

There is no easy path to successful content, and the hard work cannot be foisted off onto content owners, even if they’re real—and real good—people serving in that role. They can be invited to help in the production process, but it’s too much to expect of them that they can do it all.

Yet on the other hand, content owners need to understand that they can’t do it by themselves. Content ownership is not content dictatorship. They may indeed know the information and subject matter that eventually becomes content, but it is precisely because they own it that they are not in the best position to turn it into good content. It requires distance and collaboration with content strategists.

Content must be planned and created in the context of all the disciplines of user experience. We can’t rely on elves or fairies—or even content owners—to make it happen by magic.

Welcome to the age of transparency

President Obama has promised “transparency” as a hallmark of his administration, which now publishes documents once consigned to darkness under rubrics of “executive priviliege” and “national security.” Data.gov publishes datasets for people to analyze for themselves.  Daily legal battles are being waged to unveil monetary contributions to political campaigns. Public institutions—governmental, religious, and educational—are under scrutiny to reveal their inner workings. And on the other side of the line, privacy advocates argue that too much information is accessible, that we need better policies and procedures to protect personal information.

Just publishing information in the name of “openness,” however, does not guarantee transparency.

• Politics and public relations are notorious for obfuscation, talking a lot and saying little.
• Bureacracies are practically defined by legalese and impenetrable red tape.
• Crisis communication (a.k.a., c.y.a.) repeats only the key messages again and again.
• Credit card lenders are under attack for bewildering fine print and “hidden fees.”
• Human resources policies, crafted by the legal department, are intentionally vague to allow managers “discretion” in whether to follow them or not: What you don’t understand may or may not be held against you.

Transparency builds public trust because we trust what we understand, and distrust what we cannot discern. Your content strategy must address the issues of transparency: What information will you make available to your audience, yes, but how will you ensure that they can grasp your meaning easily and completely?

The meaning of transparency

You will remember from elementary school that there are three degrees of transparency in materials:

• “Opaque,” which allow no light to pass through them at all;
• “Translucent,” which allow some light, but no detail; and
• “Transparent,” which are perfectly clear, allowing all light to pass.

In other words, “transparent” means “see-through.”

Transparency in content doesn’t just mean “tell me,” but rather, “tell me in a way that lets me ‘see through’ what you’re saying.” Achieving transparency means helping people to grasp the fullness of what you say. It means finding the right words, in the right order, and with just the right illustration to make a situation, a policy, or a process “clear.”

Transparency in content and design

Transparent content is a lot like transparent interaction or experience design. A good interface requires no explanation. We say that it is “transparent” when it communicates itself nonverbally to the user. Users can tell intuitively where they are, where they’ve been, and where they can go next. They get regular feedback on their actions and have some preview of what their next action will produce.

Transparency in content means that users understand not only what the content says, but also why it’s saying it, and where it fits in the overall context of the rest of the content. Transparent content doesn’t make you wonder, “Why are you telling me this?” Transparent content doesn’t require indepth knowledge of the organization that produced it. Transparent content conveys itself in natural sequence in the language appropriate to the audience.

Usability testing for content transparency

When we think about testing designs for usability, we mostly imagine checking the site navigation and underlying information architecture, as well as the interactions. We test whether users can find certain information and complete their tasks.

It’s essential, however, to test your content as well. Reading comprehension, ease of visual scanning, ability to concentrate on the content without other distractions…these goals come as much from the disciplines of educational testing and instructional design as from engineering. After all, it is entirely possible to succeed in your architecture and interactions, yet still leave your users in the dark: Yes, they found where the information should be, and yes, they can made the process work, but they still have no idea what it meant or what they really did.

Testing content usability must be done in the prototyping phase, which means that your prototype must be populated with the real thing.

[Just a few] Barriers to content transparency

Dense, unstructured, unformatted text

Pages that are full of text, especially technical, poorly written text, are completely opaque. Pick almost any press release from any corporate website. Designed for the newspaper, the press release requires an absolute commitment from the reader to plow through it to see what it says. If you have to invest “quality time” with a web page to understand what it says, then it’s not transparent.

Monkeys typing randomly in hopes of Shakespeare

When the content is left to the end of the project, when no one really “owns” it, and when we use text as a “spacer” to nudge the images into the right places, then the content is meaningless and probably won’t be read, let alone understood. You must—MUST—have skilled writers and editors, expert crafters in their discipline, who are dedicated to the clarity (usability) of the written word. There is no such thing as “filler content.” Either it supports the users’ information needs, or it doesn’t. If text doesn’t contribute to user goals, then it has no place in your site.

We all know what this means!

It is common wisdom among writers to “know your audience,” yet content still shows up all over the web written from an internal, organizational, technical perspective. Worse, having done no research at all, we still feel confident that users flocking to our website already know what this content is about.

Hapless readers and users of this information can have the best intentions of plowing through the reading, yet unless they have direct experience of the organizational structure or the minds behind the content, they won’t have enough context to grasp its meaning or importance.

Whatever you do, don’t rely on passing content around to colleagues (Worse: Executives. WORST: Legal!) for feedback. Only your users are qualified to judge the transparency of your content.

Inappropriate techno-psycho-babble

On the heels of “know your audience,” however, it is imperative to strike the right balance of language. You must speak your users’ language fluently, and they must speak yours. To be transparent, content must use the appropriate vocabulary, tone, expressions, and humor for the audience. And don’t be deceived: They can always spot a non-native speaker.

Corporate speak: Losing the human voice

If you haven’t yet read The Cluetrain Manifesto by Rick Levine, Christopher Locke, Doc Searls, and David Weinberger, or visited their website (http://cluetrain.com), then it’s high time you did. In the age of content transparency, users have learned to ignore whatever has not been spoken by a true, human voice. The bland, faceless, toneless language known as “corporate speak” has no power but the power to repel. To be transparent, your content must speak directly to human users with a human voice.

Not answering your users’ questions FIRST

Users come to websites because they need to do something, find something, check something, or learn something. They come with questions already in mind or problems to solve, even if they’ve simply stumbled upon your site. The instant they arrive, new questions start forming in their minds. These questions form a Mazlow-ian hierarchy of needs, and transparent content answers these questions first. Only when users have addressed their immediate concerns can you hope to show them more content to take them further.

Self-serving organizational promotions, sales pitches, onsite advertising, pop-up surveys, and all the other barriers mentioned above only create piles of extra **** that the most committed user must dig through to find their answers.

A little bit of user research can discover the most frequent, most basic issues users bring to you, in the most natural sequence, and you can build your content strategy to address those first. Now, some of this transparency is accomplished through the information architecture of your site: Making things findable is the first leg of the race, but how you compose, arrange, and format your content will carry the baton the rest of the way.

Transparency as a content strategy goal

Setting a strategic goal for transparency involves decisions about what you reveal to your users, but also about how you will help your users “see through what you say” to what they need to know. You must discover not only what your users need to know and understand about your content, but also what they know (or believe!) already. Taking into consideration where your users are beginning, the jargon they speak, the basic questions they’re trying to answer, and their expectations of your site will all contribute to the site’s overall transparency and success.

If you manage your corporate website, which houses content from multiple departments or business lines, you probably recognize this scene: You’re summoned to a meeting with some internal web clients who own some of the content. They complain that they don’t have enough exposure on the site. They articulate the problem this way: “We get no traffic to our content!” This means that “Our peeps can’t find us!” The solution is obvious: “We need a prominent spot on the home page in the main navigation!”

You show them web analytics data: some of their pages get traffic—at least early on, just after there’s been an e-mail blast. You observe that the repeat visitor share is very low, meaning visitors come only once.

More importantly, you show them the fresh results of a user survey of their market segment (which they helped to design), showing that many in their target audience can’t remember the last time they visited your website. You mention casually that they don’t say that they have trouble finding stuff when they do visit. In the open-ended comments, the respondents talk about the information they need, but your internal clients don’t even produce that kind of information. You suggest that maybe the low traffic isn’t because of their content’s position on the website…

I’m not sure there’s ultimately any help for this situation. It’s hard to learn to put your users’ perspectives ahead of your own, especially if it means you have to rethink your whole content strategy. It underscores, however, a content strategy axiom of mine:

Be known for your content first, for your name second.

I can’t bear to hear anyone say one more time that “content is king,” but the truth is simple, if painful:

• If your content doesn’t serve anyone’s needs, then no one will use your site, no matter who you are, no matter where you are on the website.
• If they rely on your content again and again, they’ll probably get to know your name.

Here’s just one scenario:

1. I do a search for something I need.
2. I sift through a variety of links that look promising.
3. I skip the ones that seem completely wrong.
4. One link leads to something completely different from what I thought I was searching for.
5. I click it and realize that it’s exactly what I needed all along without knowing it.
6. I wonder, “Who created this fantastic thing that I never realized I needed? What else is here??”
7. I become a fervent fan of this website, and I start to tell everyone about it.

I don’t mean to oversimplify: There are many ways in which people build relationships with websites. But underlying the strength and longevity of that relationship is always the degree to which the content meets the user’s needs.

Here’s the message for that department or business line:

Even if the user recognizes your department’s name apart from the identity of the whole organization, and even if your name is emblazoned across the home page of the website, and even if the rest of the website sucks, it is the quality and usability of your content that brings people back.

As always, I would love to have your feedback. How does this perspective square with other strategy branches, “online branding,” for example?

Two years ago, I had my first experience of implementing a content management system (CMS). I will withhold all names of organizations, people, and platforms to protect the guilty, but let’s just say it’s painful even now to recall the confusion, the groping, the anger, and the desperation that my group went through. There are probably support groups out there to help us recovering CMS implementers, but in case you’re teetering on the brink of your own CMS implementation, about to go over the edge into the abyss, I want to offer some perspectives from our experience.

If you’re getting ready to implement a CMS, and you haven’t yet worked out your content strategy, then I urge you to do it now. If you don’t, you’ll find yourself saddled with a cumbersome CMS that doesn’t do what you need it to, that actually multiplies (rather than reduces) the time and resources you spend managing content, and that everyone curses and tries to circumvent.

A System Without a Strategy

I’m sure that other folks know more about how a CMS implementation is “supposed to go”—or maybe I’m simply naïf, and it’s always a crap shoot—but this is where it began for us and where we first went wrong.

Our consultants were exceedingly thorough in their project plan. They insisted on an exhaustive requirements gathering phase. They asked us, “What do you want your system to do?” We, being CMS noobs, responded, “Uh, we don’t know. What can it do?” They responded in their most solicitous tones, “Anything you want.” Round and round we went, we on our side trying to comprehend what CMS could do for us, and they on theirs trying to architect a system to fully satisfy the undefined requirements of a nonexistent content strategy.

Authoring Environment: The work areas and system branching were established before any questions of content ownership could inform them. For each of our websites, there is now one, all-encompassing authoring area, through which all our content authors tip-toe. It’s a good thing that we have fewer than 20 active content authors, and that we’re all friends.

User Permissions: Because the system was configured without a clear plan for who should be given which level access, we started simply: In order to share the one enormous authoring space described above, we’ve given most users administrator-level access. I know, I know…not cool, but it’s now so deeply configured that it’s hard to change.

Workflow: We didn’t really understand how a CMS could manage a workflow, so the system gives us one, basic workflow for everything. If you author it, you can publish it. If you want someone else to look at it, you send them e-mail. See “User Permissions” above.

Templates: Our data and presentation templates were developed starting with something called a “standard page,” meaning “no content type.” Guess how much of our site is based on that template? You’re right—a LOT. We did get wiser about content types as we went along. Some of our content types corresponded to unique publications, but we had only a rough idea of what metadata we might need even for those. Once you’ve begun populating your templates, it’s hard to make any change to their basic structure. We are stuck with some of our fundamental, uninformed decisions, and perhaps we’ll fix them next time around, when we have to migrate all the content to another system.

Platform: In our particular case, the CMS does not interact with the webserver, except to deploy files. Although we had a hard time believing that this could be the case, very late in the process, we realized that if we wanted a dynamic website in any sense, we’d be on our own to come up with a web application that would work with the CMS. A content strategy would have helped us articulate our requirements for the functioning of the website and insist on what we needed.

In the end, we have a CMS that we call our “glorified FTP server.” Our templates are ok for some things, but lots of our content is still composed in an external web editor, then either imported into the CMS or pasted into the templates because the CMS WYSIWYG editor isn’t adequate for sophisticated HTML. We have made peace with the system, but in our darker moments, we imagine all the things we could be doing with our CMS now, if only we’d known what we were doing in the first place—if only we’d had a content strategy.

CMS without CS

Designing and implementing a CMS without a clear content strategy leaves every decision to best guesses.

Content strategy scopes the content domain: For whom are you producing content? What is it supposed to do? What media will it employ? How will it produced? How will its effectiveness be measured? This is the strategic context into which your CMS is built.

Content strategy identifies content types: The whole basis for CMS templates is the content type. The content strategy not only identifies the content types that will be built into the system, but it specifies their basic structure, their metadata, their required and optional fields, their controlled field values, and their options for presentation.

Content strategy defines content presentation: CMS templates separate the content from its presentation. You create the content, then select from a range of presentation options. Without a content strategy, there’s no clear path from the visual design of the site to the visual design of all the kinds of content.

Content strategy maps the workflow: CMS generally provides customized workflows, so that content can be authored and published in a smooth, controlled process. Content strategy lays out the processes by which content is generated, published, repurposed, and retired. These processes can then be encoded into the CMS workflow.

Content strategy sets the rules for content archiving and retirement: A good CMS should have a good archiving system built into it, so that content doesn’t languish forever in outdated obscurity on your website. Content strategy guides the process for reviewing, refreshing, and ultimately retiring content into an archive.

Content strategy suggests the platform on which the content is delivered: In my limited experience, a CMS seems to require another application layer on top of it that actually drives the website. (Maybe that’s just the idiosyncratic failing of our CMS.) Without a content strategy, however, it’s not clear what that web application needs to do or how it will draw from the CMS, if it can.

Don’t Let This Happen to You

I tell you this because if you have no idea what content you’re going to create, how it will be produced, and how you need to govern that process, you’ll have no idea what to tell your CMS guys when they ask for your requirements. I hope you find my grim tale helpful. I’m a much wiser content manager now than I was before, but a content strategy would have spared me the scars.

There’s been conversation recently, especially on the Google group for Content Strategy about what it takes to be a content strategist. What’s the background? What’s the education? What’s the experience? And how do I get to be one?

I don’t think I risk too much by suggesting that no one claiming the title of content strategist started out life as a content strategist. It’s a journey of self-discovery: “Oh, so that’s what I do!”

In my opinion, the path to becoming a content strategist begins with love—the love of content.

Content strategists love content. We love both its form and its substance. We love crafting and refining it. We love running our hands around its shapes and tasting its rich and subtle flavors. We love delving into meanings and relationships. We love finding new ways to say things—and finding new things to say.

Lots of content strategists have come out of the writing disciplines—English, journalism, and such.  But the skills we use are so broad, so integrated, that one could begin practically anywhere, as long as one spent a lot of time working with content. Content strategy is more than writing, much more than text, although text understandably has a lot to do with it.

How did I become…?

My background is in languages and music, but my vocation as a content guy was evident from the beginning. Always verbal, I was  conversant with my school teachers and exercised a larger vocabulary than my peers. I just loved words.

I started editing my mom’s government grant applications as a teenager, finding clear ways to say things, reorganizing sections, and doing general redaction. I managed to get through my MBA program because although I wasn’t a number cruncher like my teammates, I wrote our research papers. My first job at Xerox was primarily to write research summaries but later grew into writing strategy presentations and doing business process modeling.

I have spent countless hours across my career reformatting documents for structure and consistency, not always because it was explicitly my job, but because it just wanted doing.

While I would never identify myself as a professional writer, writing has always been among my fundamental strengths, and has often been the gateway to new opportunities.

What about you?

So if you think you might also be a content strategist, take a look around you: Do you surround yourself with content? Do you love tinkering with how people say things? Do you pull ideas together into frameworks to make more meaning? Do you end up rewriting stuff for your colleagues, even when you don’t have to? Do you volunteer to do the writing part of the project because you know it will just go better that way?

If yes, then you’re already on the path. From here, it’s just a matter of paying attention to the content and offering your powers of organization, simplification, and clarification to those around you. They’ll be grateful because they hate it, almost as much as you love it. Becoming a content strategist begins with the love of content, and that love carries you along the paths where you learn the strategy part.

“Content types” are among the least understood, and yet most potent, aspects of user experience and web design. Most people encounter them for the first time when implementing a grand-scale content management system (CMS) because you have to define content types before building templates for each kind of content you’re going to publish. (Everything I know about content types began with Bob Boiko’s Content Management Bible, and I recommend it to anyone facing a new CMS.)

Because they associate content types so closely with CMS, some make the mistake of equating content strategy with content management. They’re not the same thing, though they are certainly related. Your content strategy specifies the content types that will then be modeled for your CMS.

I want to take some time, then, to tell you what I understand about content typology, so that you’ll be able to address content types in your strategy.

Types: The original model

In English, we almost always use the word type as a synonym for “kind” or “sort.” “What type of cake are you baking?” or “What type of car did you buy?”

More precisely, however, a type refers to the “original model” for something.

A Type is the basis, the foundation, the primary class, or the standard, upon which all instances of something are modeled, and against which all examples of that thing are compared. A Type describes the thingness of a thing, which is recognizable, no matter how much variation is evident among all the things.

For example, mammals are a particular type of animal. Since we were in primary school, we have  recognized the fundamental characteristics of that type: Mammals breath air, they bear their young live, they nurse their young, and they have fur of one kind or another. The mammalian type, however, is almost infinite in its diversity throughout the world, and there are even some examples that “violate” the type—like platypuses. Yet as a type, mammals are pretty clear, whether they walk, swim, fly, or climb.

In exactly the same way, every piece of content on your website (for that matter, every piece of content) has a primary type. Quick examples include articles, press releases, product specifications, photographs, graphic charts, customer reviews, blog posts, demonstration videos, support manuals, login splash screens, order forms, et cetera ad nauseum. In one way or another, everything on your site is content, so everything has a content type.

Content modeling: The practical craft of content typology

Content typology, or the study of content types, is the basis of the craft of content modeling. Content modeling refers to the designing the content type and its metadata or other data requirements.

Let’s take a “speech” as a working example. Imagine that you work with a political candidate’s website during an election campaign, and you decide that you’re going to make audio, video, and transcripts of that speech available. What are the basic elements of that speech? Obviously, there is the speech itself, which at the very least is text spoken to a crowd.

The speech probably has a title.

You might also want to provide a summary or abstract of the speech, so that people have some idea of what it’s about before they start listening, watching, or reading.

There are other elements that go along with the speech, such as the date it was delivered and the venue where it was delivered. It may have been delivered to a particular audience.

So far, we have a simple content type that looks like this:

Speech

• Date
• Venue
• Audience
• Title
• Abstract
• MainText

Now it starts to get fun. What other information (or “metadata”) do we need to capture to round out our speech, especially if we want to make it general enough to serve a variety of circumstances? Why don’t we add the following metadata to the type:

• Speaker (to accommodate running mates or other stumpers)
• Topics (covered in the speech)
• Pullquotes (for visual interest)
• VideoFile (url)
• AudioFile (url)

The video and audio themselves probably constitute their own content types, and so would have their own metadata associated with them, like duration, format, and filenames.

Pretty good, but there’s more we can do. The next step is to get more specific about these elements of the Speech content type:

• How long can the title be?
• Which elements are optional, and which are required?
• How many pullquotes or topics can an speech have?

And then, for the management of that content type, there would be yet more information to help keep it organized:

• CreationDate
• ModifiedDate
• Author/Owner

These are just a few examples of the elements that might be incorporated into a content type. There are many, many more you could use, depending on your specific needs. You design your content types to do what you need them to do.

Compound and combination content types

But a content model specifies not just the bits and bobs that make a content type, but it also describes how one content type relates to the others.

As a further example, imagine your favorite cooking site. Each recipe is based on a recipe content type, with ingredients, quantities, instructions, and perhaps a little blurb talking about where it came from. But there is probably also a place for you to rate the recipe and review your experience of trying it out. Your content model probably doesn’t specify that all as one, humongous content type, but rather an interrelation of the recipe with the user ratings, reviews, and pictures types. Each recipe page becomes a compound of interrelated types to make up a whole page template. Go to your favorite cooking site now, pick a recipe, and count the modules of related content types. The number of types on a single page can be staggering.

Describing how all those content types go together will be essential for communicating the content design to the interaction design, the visual design, the information architecture, the systems design, and any other part of the process of getting a site built and running.

Why worry about content types?

Content typology may seem at first an abstract, esoteric, and fussy field of study. (When carried to its ecstatic extreme, it can be, and some of us loooooooooove it like that.) But identifying and paying attention to your content types is eminently practical, for to neglect your content type design is to put your content in imminent danger of inconsistency, poor usability, and utter chaos. The benefits are manifold.

1. Content types define all requirements specifically and precisely

Designing clear content types will become crucial when you begin building templates for your CMS. If you begin loading content into your CMS and then discover that you’ve overlooked a critical part of that content, it’s hard to go back to make changes. The more specific you can be during content type design, the less confusion there will be when your template developers start working, and the fewer unpleasant discoveries you’ll make when building your webpages.

2. Content types can be styled consistently

If your content types have consistent elements, even if some are optional, then your visual design can address each element consistently, and you will have achieved the utopia of separating structure from presentation. (But that’s a post for another day…)

3. Content types provide instructions for creating the content

If those who create or prepare your content for the web know exactly what elements they have to craft, they don’t have to make it all up from scratch.

4. Content types are by definition well-formed and can be migrated

When your content is well-formed, that is, when its structure is clear and consistent, when you do eventually have to build CMS templates for that type, you’ll (ideally) be able to translate that structure into whatever form you’ll ever need, whether storing it as XML or in a database. When you change CMS or platform, you should be able to get your content out whole because anything that is well structured should be accessible to programming.

5. Content types let you mix and match content across your site

When you have sorted all your content into clear content types, you’ll be able to put them into different combinations and publish them in many places across your website. In fancy parlance, this is called “content re-use and aggregation.” 

Content modeling isn’t everybody’s favorite party game, and like any design discipline, there is a rigorous craft to doing it well. It is essential, however, for any content manager to understand content types and the care and attention they require. No matter where your content is in its lifecycle, its usability, its consistency, its effectiveness, its reuse, and its regeneration all depend on managing its underlying type.