The Content Wrangler published a “state of the profession” rant about writers who have jumped on the bandwagon of content strategy without going the work the understand the nuances of content production on large projects. Read Know Your Stuff’ or Stop Pretending To Be Professionals.

I was part of a panel discussion at the Gilbane Boston conference, and instead of doing yet-another-panel, my co-presenters and I decided to stage our presentation in the form of a three-act play. Watch One Project, Three Strategies: : What Teams Need to Know About Design, Development and Content Strategies for Content-driven Initiatives. (54 minutes, and the sound quality is iffy but if that doesn’t bother you, you’ll enjoy it)

The Content Marketing Institute published an article about how the goals and production of public sector content is similar to that of the private sector. Read How to Climb the Engagement Pyramid with Public Sector Content.

Data Conversion Labs published an article explore some of the ups and downs of making online books that are both usable and attractive. Read e-publishing.

Rachel and Rahel talk with Scott Abel

The web is simply one channel in a multi-channel publishing environment.

You can’t really talk about being a web content strategist, unless that means you handle only web content that is not also destined for mobile phones, PDAs and other small-screen devices, or even (gasp!) print. And if you don’t, who takes care of the content models, delivery design, topics maps, localization, customization, standards, publishing pipelines, transformation guidelines, metadata, and all that other stuff that needs to be considered?

When we develop content strategies, we are asked to analyze content and make recommendations about the various aspects of how content will be handled during the content lifecycle. One of those decisions points may be how the content should be, is likely to be, and will be consumed by its readers.  It could be output to the Web, but it’s more likely to get output to the Web as simply one of the channels in a multichannel publishing environment.

I contend that no one can do it all, but that the way to slice the content pie isn’t by output channel. Meanwhile, did this ring a bell for anyone else? Discuss…

The issue with “Content strategy for the Web” is that for me, the Web a single output format.  What happens when I put the some content out on the Web, and send it to Training to incorporate into their training materials, and share it with the Customer Support group, so they can incorporate it into the knowledge base for service reps, and send it out to a PDF so it can be printed as a manual? My mandate is obviously bigger than “the Web,” but more importantly, the framing shouldn’t be by output channel.

While the term “content strategy for the Web” doesn’t say this explicitly, there are several implicit connotations: the content is marketing content, and the Web is where content consumers go to read it. The differences between content for the [marketing] Web and [marketing] print material has to do with length, look, keywords, search engine optimization, and so on.

Ann Rockley gave her earlier book, Managing Enterprise Content, the subtitle of “a unified content strategy” but the concept of “unified” is not well understood by our audiences. Unifying what and what:  Web and not-Web? Marketing and technical? When the questions I get asked start with “what do you mean by the word content?” the whole idea of unification becomes a hurdle that sometimes my audiences never get to. The type of content strategy I provide isn’t the normal definition of enterprise-wide. It doesn’t include email and ediscovery, or records management for HR, or ERP data, or any of the stuff that information-management gurus look at as enterprise content management.

Yet we know that the power to name what we do can define expectations – not to mention make search terms so much more effective! So what do we do? In an effort to frame our focus, I looked at our activities, deliverables, and scope of content, and realized that there are a couple of basic common denominators:

• The content is on the critical path. We’re not talking about email or HR records. We’re talking critical-path product content. The content is related to the product being sold or service being provided. This means product content that gets used in multiple contexts: technical documentation, training, and customer support, and marketing, as well as content that gets turned into product content, such as engineering specifications, product-related user-generated content, and content used in a social media context.
• The content either supports pre-sales purchasing decisions, or it supports the post-sales relationship between you and your customers. The content may not always be customer-facing, but it is used to build the customer relationship. Why both of these stages are important is because the pre-sales stage is like dating; and the post-sales stage is like marriage. Consumers, and perhaps more importantly, industry analysts, look to see what the relationship will be like once you’re hitched, and they do that during the dating stage. So the content we’re concerned with is, essentially, relationship content.

Joe Gollner calls it “content in the context of forming persistent business relationships.” I like this definition because it defines the content by its function rather than by its output mechanism. However, someone might posit that email exchanges between staff and customers also serve the purpose of forming or maintain persistent business relationships.

I then (re)turned to Karen Donoghue’s book, Built for Use: Driving Profitability Through the User Experience, wherein she makes it clear that every successful transaction that a user has with a website has the effect of taking a step closer to a trust relationship; every unsuccessful transaction send the user a step (or two or ten steps) away from that relationship, and in some cases, irreparably damages the relationship.

Given that part of my mantra is cross-silo consistency – your content should be consistent on your site, in your print documents, in your PDFs, on your product packaging, in your service agreements, in the software interface, and wherever else it appears, AND throughout the entire lifecycle of the content – then the logical conclusion I draw is to connect my type of content strategy to the user experience. User experience helps form and retain persistent business relationships; content is a critical component of a user experience.

Then, do I call this user relationship content? I can just see the look on the face of an executive as he mutters something under his breath to the effect that his company doesn’t have a dating site. As a good content strategist, I realize the importance of crafting content to be effective for my audience. So who is my audience: the practitioners who want a technically accurate description of the craft, or the decisions-makers who are potential clients for my services?

In this case, I have to admit that I’m leaning toward a client audience, and hence the designation of content strategies for the product life cycle. Product life cycle is a term that resonates with product managers, program managers, and other mid-level to executive-level management, and all the content related to the product lifecycle – soup to nuts, so to speak, of the content lifecycle – is what is at stake in my type of content strategy. When I use this phrase to describe this to potential project sponsors, will they understand it? Will we do our field of practice justice by calling my work product life cycle content strategies? Let the debate begin!

Part of a content strategy is ensuring that visitors can actually find what they’re looking for on a website. The way people talk, and thus search, can be vastly different from the carefully-crafted phrases of the marketing department. Perhaps you need to also include industry terms, as a way of helping potential industry visitors reach your site, and to frame your offering – your product or service – within a larger context. Or perhaps part of your mission is to educate and inform, not just sell. In that case, you need to include the terms that explain the concepts. But as brilliant as that may make your organization look, it won’t necessarily invite dialogue. That is done by creating conversational content.

An example that comes to mind is a client of mine, a small company that develops a CCMS. They understand the need to  but continues to struggle with the terminology. Their system has great multi-channel publishing capabilities, but that’s a industry term. Who searches for “multi-channel publishing”? Typical adopters are more likely to search for “single-sourcing” or “CMS for technical documentation” or “content re-use” and some combination of their outputs (technical documentation, online help, training materials, and content for a customer support site or knowledge base).

So their challenge has become to figure out what Gerry McGovern, in an article on CMS Wire, calls carewords, and ensure that readers can find your site using those terms.This seems obvious enough, but this critical aspect is often overlooked, when creating site content That’s where doing a reality check comes in. Whether you do user testing, scan the search logs, or use sophisticated analytics tools, the task of opening the conversation begins with finding the right conversation starter that will get visitors to site, in the first place.

HAPPY BIRTHDAY, RAHEL!
It may not be the coolest thing to send gift certificates as birthday presents, but:
1) There aren’t many same-day delivery gift options.
2) All online gift-selection guides are too narrow minded and in a dire need of some faceted taxonomy: a woman our age can only be a domestic diva, country clubber, or super grandma, and a geek can only be a young dude; there’s no way to find something for a geek grandma.
3) I hope you’ll enjoy browsing the product catalogue.

Most consumers wouldn’t articulate the problem as clearly as my taxonomy guru colleague. I’ve had this frustration for years, starting with becoming a grandmother at age 40, and finding myself represented in the media by 80-year-old white-haired, hunch-backed women in rocking chairs, their knees covered with shawls. Well, it’s more than a decade later, and I’m in the gym three times a week, working out with my personal trainer, and watching my media alter ego get a little younger and a little more active, but mostly, I’m supposed to be verging on arthritic or incontinent and see lots of medical professionals to fix me up when I’m not in discomfort on the golf course. On the other hand, at least I’m now being shown on a golf course instead of in a rocking chair!

In all fairness, there are a few posts for geek grannies – there’s even a link to a spoof video of a gangsta granny (again, hunch-backed and white hair). I was thinking more along the lines of Goldie Hawn or Kathy Bates.

Given that I’m working on a couple of design projects for fitness-related, health-related sites, these observations hit closer to home than usual. I suspect there needs to be more middle-aged women in advertising, design, and related fields, as our perspectives can show how different the landscape looks from this side of 50.

However well that has served you in the past, using this structure might be doing your group a disservice when you have a lot of content to manage. This holds true when you move to a content management system, where you have lots of content “chunks” or “objects” that get combined and recombined as an aggregate of topics for the output in a “book” format.

How context affects findability
There are lots of ways to think about your content, and to be sure that you’ll be able to store the content in an appropriate place, find it when you need it, and manage its lifecycle, you need to understand the requirements from a business, content, and technology point of view. When content gets stored in a traditional file structure, you run the risk that content gets forgotten because of its creation context.

Using the example above, let’s imagine a typical department scenario. Imagine your company has a product line of, say, office chairs. The traditional file structure would be:
Office Chairs
> Swivel Magic Chair > Assembly Instructions
> Swivel Magic Task Chair > Assembly Instructions
> Swivel Chair with Lumbar Support > Assembly Instructions
> Swivel Magic Executive Chair > Assembly Instructions

Let’s assume that a new writer is assigned the task of creating assembly instructions for the new type of chair (executive chair with armrests). The writer must look through all the versions of all the chair types to see if any assembly instructions for the armrests exist. If there are many sets of assembly instructions over a number of years, finding existing instructions could be hit or miss.

In a content management system, there is no need to store the content in such a linear way. The content chunks get stored in a way that can be mixed-and-matched, and changed with conditional text processing that gets applied at some point during the system. In the case of a product line such as chairs, where one could assume that lots of the content is common, a more efficient way of structuring the taxonomy could be to group the common elements in a way that requires writers to sort through a known number of content types. An alternative structure could be:

Office Chairs
> Swivel bases
> Swivel bases > Castor type A
> Swivel bases > Castor type B

> Chair frames
> Chair frames > Steel
> Chair frames > Wood

> Armrests

> Upholstery
> Upholstery > Leather
> Upholstery > Wool
> Upholstery > Microfiber

Under this model, any writer beginning to write assembly instructions would look under each Level 1 section, and would choose a topic from each appropriate area. Because any writer can see all the available topics, there is no guesswork about whether content exists elsewhere, and where. In a content management system, there are likely search options to locate content that isn’t categorized appropriately, but for a successful search, the writer has to determine what the search terms will be. If a previous writer used a slightly different term, or a now-defunct term that was in vogue during a certain marketing era within the company, the search may be unsuccessful, and a writer could spend valuable time rewriting content that already exists. On a one-off basis, this may not seem like a big deal, but in an environment with lots of content or many writers, the content repository can get “littered” pretty quickly with duplicate content. And as the collective memory fades, it will become unclear which version is the right version, the official version, or the signed-off version.

The example used here is obviously a simple one, and certainly will not apply to all situations. In cases where complex content relationships exist, you may need a formal taxonomy that allows terms to be referenced in specific ways, that allows content to appear to be filed under multiple categories, or that drives navigation. These strategies are best left to a taxonomist whose training lets them easily see content relationships that the untrained eye struggles to detect. What should not be hard to see, however, is that how you structure your content, right from the beginning, will affect your content “discoverability” for a long time forward, and is a decision that should be based on the business and content requirements within your organization.

Don’t look for component content management systems (used to manage and aggregate chunks of content to create larger information products, such as help systems or technical documentation) to be shown in this metropolis, though – seems those systems must live in an off-the-map suburb, unlike the “Europolis” and similarly cleverly-named areas of town. Maybe, on a future map, we can anticipate an inset to this specific subset of content technologies?

Actually, moving away from written instructions seems to be a popular way to go. However, there is a serious downside to graphic instructions, however, that hasn’t been addressed yet, and that is content findability. Graphic instructions can’t be located by text search, so unless the artist or video director attaches the appropriate keywords, one may not even realize that the instructions even exist on the Web.

For example, I own a bicycle alternative called a Trikke, a self-propelled cambering vehicle, and while its manual gave me the basics of how to assemble and use it, there were a certain number of incongruities between the marketing hype and the instructions, particularly around safety. (Are you truly supposed to avoid puddles and ride on flat, dry pavement, or can you really do half-pipes?  But I digress.) The Trikke site has a limited amount of installation and training instructions. On the Web, there are some intstructional videos on the Trikke site, and links to more videos in the Trikke Talk forums. Some enthusiasts have their own sites with instructional videos, which may or may not come up during a search (such as Nicky’s Seeds in the UK). And YouTube yields its share of videos, but I wouldn’t have discovered certain riding techniques had I not been intrigued by a Trikke video called Trikke – Newbie Day 2, which had to do with Trikkes and weight loss.

This leads me to wonder how organizations will cope with the consumer-driven demand for instructions in graphic and video format. Will this trigger a resurgence of the importance of taxonomies, or will organizations opt for taxonomies enhanced by a user-generated folksonomy? The next few years will be an interesting time as the industry discovers and defines its best practices.