Why I say that is because of a concept borrowed from the financial industry called asset amplification. In the context of financial markets, asset amplification describes how changes of wealth in financial markets causes amplification because of follow-on consequences. (Thanks to the Journal of Financial Economics article by Wei Xiong explaining how this works.) Similarly, the power of copy can be amplified if it is placed into a robust technology framework. Once copy is placed inside of a framework, it becomes the content of that framework. Like coffee is the “content” of a cup, copy is the content within a technology framework. And like a super-hero with the appropriate gear, copy, with the appropriate framework, gets super-powers, too.

The super-power of content is the potential for follow-on consequences of copy because of the underlying technopower is what turns copy into content. Thinking back a few years, communications coordinators who organized events would type out the event details: event name, start and time, place, cost, and so on, and then spend hours copying and pasting the event into sites that would allow them to paste it into a provided text box or, even more time-consuming, complete a set of form fields that the coordinators had to fill out individually. Today, we use content feeds which allow events to be amplified with no manual intervention. This is done through the technopower of the underlying technology framework.

As we get away from brochureware to robust interactivity, the need for rich semantic content grows. Again, copy, multiplied by technopower, makes content which can be processed by other systems. The event example was a simple one, but there are increasing levels of complexity, from “simple” publishing to the kind of interactivity and outputs that allow for successive complex transformations of content. We are all familiar with how content gets syndicated, but what may be a surprise is how much content is manipulated and transformed within a system. Each transformation provides the potential for additional amplification, and eventually provides a much richer user experience for the content consumer.

In the end, content may be nothing without copy; however, in a post-paper world, copy is nothing without content.

Previous post: Turning Copy into Content

This list is organized arbitrarily by broad category. Hey, my blog, my rules. And what you can do, gentle reader, is add your favourite books to the comments section. More reading, more knowledge!

Planning and Design

Harnessing Complexity (Robert Axelrod and Michael Cohen)

Managing Enterprise Content (Ann Rockley)

Content Management Bible (Bob Boiko)

Document Engineering (Robert J Glushko, Tim McGrath)

Content and Complexity (Michael J Alberts, Beth Maxur, eds)

Designing e-Learning (Saul Carliner)

Information Design (Robert Jacobson, ed)

User Experience

Understanding Your Users (Catherine Courage, Kathy Baxter)

The User is Always Right (Steve Mulder and Ziv Yaar)

Paper Prototyping (Carolyn Snyder)

Why Software Sucks (David Platt)

Handbook of Usability Testing (Jerry Rubin, Dana Chisnell, Jared Spool)

Storytelling for User Experience (Whitney Quesenbery, Kevin Brooks)

Observing the User Experience (Mike Kuniavsky)

Subject to Change (Peter Merholz, Brandon Schauer)

Rocket Science Made Easy (Steve Krug)

Simple and Usable (Giles Colborne)

Do Good Design (David B Berman)

Built for Use (Karen Donoghue)

Mental Models (Indi Young)

The Inmates are Running the Asylum (Alan Cooper)

Practitioner Guides

The Web Content Strategist’s Bible (Richard Sheffield)

Elements of Content Strategy (Erin Kissane)

Letting Go of the Words (Ginny Redish)

Content Strategy for the Web (Kristina Halvorson)

Creating the Perfect Design Brief (Peter L Phillips)

Business Process Mapping (Jacka Keller)

Request for Proposal (Bud Porter-Roth)

Managing Knowledge (Wayne Applehans, Alden Globe, Greg Laugero)

Managing Your Documentation Products (JoAnn Hackos)

Techniques for Technical Communicators (Carol Barnum, Saul Carliner)

Sister Bernadette’s Barking Dog (Kitty Burns Florey)

The Accidental Taxonomist (Heather Hedden)

The Visual Display of Quantitative Information (Edward Tufte)

Envisioning Information (Edward Tufte)

Wordsmithing for Effect

Clout (Colleen Jones)

Neuro Web Design (Susan M Weinschenk, PhD)

Content Rules (CC Chapman and Ann Handley)

Get Content, Get Customers (Joe Pulizzi and Newt Barrett)

Content Nation (John Blossom)

Curation Nation (Steven Rosenbaum)

Predictably Irrational (Dan Ariely)

Delivering Happiness (Tony Hsieh)

Branded Nation (James B Twitchell)

Call to Action (Bryan and Jeffrey Eisenberg)

Intercultural Communication (James W Neuliep)

A Practical Guide to Localization (Bert Esselink)

International Technical Communication (Nancy L Hoft)

Metadata and Delivery

Audience, Relevance, and Search (James Mathewson, Frank Donatone, and Synthia Fishel)

Search Engine Visibility (Shari Thurow)

Metadata Solutions (Adrienne Tennenbaum)

Killer Web Content (Gerry McGovern)

Wiki (Alan Porter)

Introduction to DITA (Jennifer Linton, Kylene Bruski)

User Engagement

Conversation and Community (Anne Gentle)

Here Comes Everybody (Clay Shirky)

SocialCorp (Joel Postman)

Sway (Ori and Rom Brafman)

The Thank You Economy (Gary Vaynerchuk)

Radically Transparent (Andy Beal, Dr. Judy Strauss)

Crowdsourcing (Jeff Howe)

Participating in Explanatory Dialogues (Johanna D Moore)

A recent inquiry on the content strategy group asked about efficient ways of surfacing content in multiple ways. Yet avoiding content duplication isn’t as easy as it may sound. Managing content is more complex than managing data. Data moves from one point to another with little problem. The number “12″ is the number “12″ no matter where it ends up. But when the content equivalent – a dozen, December, above-average family size – context becomes critical.

This is where having a technical communication background comes in handy. Surfacing content in multiple places is a cornerstone of creating technical documentation, online help, training, and user support material, which can often come from a single content repository, and published out with variations. The “one source of truth” has long been articulated as “single-sourcing” with its corollary, “multi-channel publishing.”

The model for creating content and pushing it out to the surface is a different process, and uses different tools. It also moves responsibility for content further up the production process. The decision on how this is put into effect is a key aspect of a content strategy, and doesn’t get addressed often because of the deep divide between types of content authors.

One source of truth in a Web CMS (WCMS)

The WCMS  generally takes in content that is edited in form fields. A simple example would be changing the account settings of Facebook, and having those changes show on your home page. How this happens is programmed by the developers, and any changes to how the content is surfaced either by the writer (de)selecting a check box, or by the developer customizing the code of the WCMS. Thus, the WCMS is the gatekeeper for the content flow.

A practical example in the WCMS world

I recently worked on a project where a number of hotel resorts were described in various ways on the website. On the home page, there would be a one-line description accompanying a photo. On another page, there would be a short teaser paragraph. On yet another page, the hotel contact information would be shown.

In the background, all of the content was in a single database, per hotel. The database cells included: hotel name, city, state, country, reservations phone number, front desk phone number, one-line teaser, short teaser, property description, and at least a dozen more content blurbs. These were provided in an Excel spreadsheet to the technical team, who then programmed how the content would be surfaced, and ensure that the right images match the content as it is displayed.

Single sourcing in a Component CMS (CCMS)

In a CCMS situation, the responsibility for surfacing content is moved upstream, to the writer. The writer uses an XML authoring tool (as the industry matures, tools are starting to leverage common tools like Word to do XML publishing – it’s still in its infancy, though) to create content and determine the variations. The authoring tool creates a individual content files, which then get managed in the CCMS. In other words, the CCMS is not the gatekeeper; it becomes simply the “traffic cop” that supports the author’s work.

Once the writer has created the content and set up the dependencies for surfacing content, the CCMS does an automated generation of the content through some sort of publishing pipeline. This reads all of the XML metadata and determines what content is shown where. At this point, the content is generally pushed out to some area in the WCMS reserved for the content, and then the WCMS picks up its gatekeeping duties.

A practical example in the CCMS world

To publish a travel advisory that needs to be shown to three audiences, you would create the entire long-form advisory and tag each of the sections with an audience, as shown:

<public>Don’t go to country X, effective immediately.

<doctors> <industry_stakeholders>There is a suspected outbreak of a mystery disease. If called by the media, assure them that they will be informed as soon as developments are known.</industry_stakeholders> If someone comes into your office with the known symptoms, quarantine them and get them to a hospital as soon as possible.</doctors>

Stay tuned for details.</public>

The publishing pipeline would send out three separate messages to the appropriate output channel, presumably different places on the website, or a combination of the website and other forms of communication.

• The public would see the preamble plus the concluding statement (in blue).
• Industry stakeholders would see the public message plus the statement intended only for them (in blue + purple).
• Doctors would see the entire message.

Other critical differences in surfacing content

The first difference is in what constitutes the “single source of truth”:

• In a Web CMS, content changes are made to the database, and the content is changed everywhere it’s programmed to do so. The database is the single source of truth.
• In a CCMS, what you have is, in effect, two “single sources of truth” – one is the pre-published source; the other is the published version. The nature of publishing is that these get out of sync after version 1. Think of publishing a multi-hundred page HTML manual. Version 1 uses all new content. Then, there are updates to one section, say pages 20-30. These pages now have Version 1 content and Version 2 content, while the published content is all in the Version 2 manual.

So the second difference is how content is versioned:

• The authors will be concerned with the versions of each content file; after a while, a body of published content can be made up of a range of versions that co-exist in the same repository and get mixed-and-matched by the author to be published.
• The published content is another single source of truth. It is the aggregated “publication” that is for consumption. The consumers of this content have no idea that any given page may be made up of multiple content chunks aggregated together for a seamless reading experience.

Another difference the gatekeeping functions:

• In a WCMS, the code written by the developer provides virtually all gatekeeping functionality.
• In the CCMS, the writer is the primary gatekeeper, but there is another gatekeeping function – the publishing pipeline code. The content is generally publishing using XSLTs (an automated transformation of XML content using XML stylesheet language scripts). The code automates the output process, and changes to the output means tweaking the scripts.

The WCMS world vastly overwhelms the CCMS world in number of systems sold and implemented, though amount the content published by CCMS systems on a given site often considerably dwarfs that output by the WCMS.  The next few years will be interesting, as content management systems try to capture market share by enabling “the other type” of authoring experience for organizations that need to adopt more robust methods of creating and surfacing content in more flexible ways.

“Our IT department gave us VSS and we can’t figure out how to get components out of that. How do you do that?”

“We’re tearing our hair out with Sharepoint and versioning; what is the workaround?”

“Our website uses Documentum and it won’t do what we want. What do we do?”

“We have Interwoven and the interface is awful, so our staff won’t use it. What should we replace it with?”

Each set of circumstances was unique, yet eerily alike.  Each instance involved the acquisition of a software product which was then implemented for an operational unit, without regard to whether the software was suited to the task. The mismatch, in some cases, was painfully obvious; in other cases, the mismatch was more subtle. In many cases, certainly all the instances above, the software is popular, thriving software that has been implemented without a proper strategy. The results: generally some sort of fail.

Bad strategy or no strategy?

During the past decade, acceptance of content management has drastically increased. The idea that managing any significant volume of content requires some technology assistance has been demonstrated a multitude of times, and the adoption of a CMS (content management systems)  is no longer a novelty. Yet the instances of the tail wagging the dog – buying the software before determining the operational needs – continue to be far too familiar to ignore.

When I would encounter an audience member at a later event, I’d ask if they’d ever gotten the problem sorted out. Overwhelmingly, they would sheepishly admit that they had not. They continued to produce and publish content in ways that they acknowledged were highly inefficient and prone to operational risks <link> because they couldn’t convince their organizations of the need to make the changes that, to them, were obviously needed. So what went wrong?

Go cheap or go home. This “strategy” is when the technology group either already has some software – collaboration software, source code control software, or a Web CMS – that they insist be put to use because “we already own the software” or “the software is free.” Not only does this dooms a project to failure, but anecdotal reports show that the operational team is then blamed for the failure. The technology group refuses to take responsibility for having foisted upon them an inappropriate tool. In this case, a stalemate ensues, and everyone goes back to their previous kludgy way of work, with no movement forward, and the technologists smug in their political win.

Don’t get it, don’t care; just do it. This “strategy” is in play when a group has heavily invested in a software application, and is reluctant to investment more time or money to make it work for a different operational purpose. There is equal resistance to bringing in additional software that complements the original uber-application, and no impetus to understand why it is needed. There may have been a strategy developed for the initial implementation, but there is no acknowledgement that different operational needs will require further customization of the software. The idea is that the software should be one-size-fits-all, and if the customization has worked from one department, it should work for all departments. The department whose operational needs aren’t being met is sure to find inventive work-arounds, sometimes taking pains not to let on what is going on for fear of sanctions from the powers that be. Generally, the situation comes to light when a serious breach of protocol comes to light that can be traced back to a work-around that failed.

Connecting strategy to technology

The idea that technology can be implemented without strategy is naïve, at best. The idea that technology or strategy can be implemented without a deep understanding of the content lifecycle is a wanton mismanagement of corporate assets.

Understand your content. The entire CMS implementation is to support, with technology, the production, processing, and publishing of content. It is imperative to understand what the content needs are throughout the entire content lifecycle. Without this understanding, a technology implementation is sure to go wrong at some point because there will be a mismatch between the content requirements and the software assigned to support it.

Know your standards. For any technology to be effective, there needs to be an understanding of how the content can be leveraged. This generally involves connecting systems, whether that is as simple as providing an RSS feed or using microformats, to more robust standards such as implementing DITA <link> to make content system-agnostic or integrating content from one system into another through the magic of XSL transformations.

Understand pertinent technologies. The decision-makers who, with much eye-rolling, confess with some pride that they don’t even know how to use styles in their word processing are who allow bad software implementations to thrive. Get with the program or get someone who can, because the lack of understanding about how to leverage content through technology, more often than not, shortchanges the project or leads to disastrous results. The complexity of systems has grown exponentially over the past decade; it is imperative to understand, at least at a high level, what the various technologies can do and how that can benefit – or harm – your content and, ultimately, your brand.

The concepts I’ve articulated here are not entirely new, nor are they particularly rocket science. Consultants, software vendors, and their savvy clients have produced many case studies demonstrating successful implementations and the derived organizational value. Invariably, their successes all share a common denominator: a strong strategy.

Of course, a presentation is just that. It’s generally an hour-long session, in which a speaker has to pick and choose their facts and explanations to fit within the time frame. Sometimes large issues get glossed over in order to fit in all the great material the speaker wants to present.

CMS-savvy people – internal staff to project stakeholders to consultants and everyone in between – know that there can be inadvertent, besides deliberate, misrepresentations of what a system can do. It’s often a mismatch between a system’s features and organizational needs, and often a mismatch between cost models and budget expectations. So how do you ensure that you’re not  left holding the bag when the software vendor has left the building?

Process.

When you can explain to a vendor exactly what you need from a system – the scenarios and use cases – then you can get the vendor to demonstrate how their system will fulfill that need, how much it will cost for add-ons or customizations, how long it will take to accommodate all of this, and what impact all these will have on the maintenance after an upgrade or two. Without doing all of your homework first, you fall prey to the never-ending escalation of time, cost, and frustration as you discover the shortcomings of a misfit content management system.

Perhaps the lack of attention to content lifecycle is a reflection of the lack of attention given to the topic on the Web. In fact, a Wikipedia search on the topic of the content lifecycle sent me to the topic of Content Management, where a brief mention of content lifecycle management involves “content distributions [sic] and digital rights” – if only it were that easy. The German version of Wikipedia has an article on the content lifecycle for Web content, which seems incredibly simple (Create > Publish > Archive? Really?) and is also tied to a content management system.

But, I’m telling you, this is wrong, wrong, wrong. At the risk of sounding like David taking on Goliath, I want to spend a couple of articles talking about the content lifecycle, and clearing up some common misconceptions. I’ll discuss  content without the attachment to a CMS, proprietary software, tools, or methodologies. It’s all about the content, front and center. Defining a content lifecycle What is a content lifecycle?

Just as in the information architecture world, there’s “big IA” and “little IA”, in the content world, there is “big content management” and “little content management”. The “little content management” is about getting content to work within a content management system; “big content management” is about having a content strategy to create a repeatable system that governs the management of the content, throughout the entire lifecycle.

The content lifecycle covers four general areas: the strategic analysis, the content collection, management of the content, and publication, which includes post-publication maintenance and a loop back to analysis for the next cycle. This lifecycle is present whether the content is controlled within a content management system or not, whether it gets translated or not, whether it gets deleted  at the end of its life or revised and re-used.

The critical aspect of the lifecycle is that it begins with the analysis quadrant. The saying, “if you don’t know where you’re going, any road will take you there,” certainly applies to the lifecycle  of content that begins without a strategy. You can change how it produced, how it’s managed, which tools you use to control it, translate it or not, cut aspects out of it or not – if you have no strategy, you have no real rationale for the content you produce.

The other three quadrants are the tactical aspects of the content lifecycle.  They may not have the same allure as the strategic side (at least, not for me), but they are important, nonetheless. It’s where the rubber hits the road. Without the strategy, you may end up in an aimless wander, but without the tactical side, all you have is a good idea.

Next week: Dispelling the Top 10 Myths about the Content Lifecycle

So when it came time to changing the answering machine greeting message, I followed the instructions only to discover that there is no option to select. I tried all the little tricks to see if the option got hidden elsewhere in the menu tree, but it was definitely missing. Well, that’s fine; I will tough out the pain of contacting customer support, through the phone number in the back of the book. The phone number works in Canada – always an iffy question – so that’s encouraging, and after listening to all the preambles, I press 1 for English, enter my product number, and go through the various menus but there is no option for “menu items are missing”. It seems that all the options end up the same way, leading to an end point of “visit our website at …”.

Now, gigantic corporations all have us trained to despise having to call in; in other words: Don’t you think I’d have checked the website first if I thought I could find the answer on your website? It would have been so much easier: go to the site, choose the model number, and  But of course, the user experience was quite painful. Here is an encapsulation of the frustration points:

1. After doing a Google search for AT&T 84209 (the model number) phone, I kept getting routed to the att.com site, which was obviously US-based, and geared to telephone service subscribers.
2. I redialed the number from the instruction book and was given www.telephones.att.com as the URL. Typing in 84209 got me to a shopping area. Do I want to buy a replacement cordless battery? I must say that if I happened to know the model number of a phone I wanted to buy, I’d be in luck because the second shopping option is to buy the very phone that I’m getting annoyed over.
3. There are links to the manual and Quick Start guide, which I consulted and had the same incorrect information.
4. Filling in the Contact Us form field promises to net a response within – depending on which of the messages you believe – 72 hours (on website), 2 days (on-screen auto-reply message), or 3 days (auto-reply email) but I doubt that I’ll get a meaningful answer. It may be too late anyhow, as I’ve run about the house, disconnecting telephone bits and bobs and tossing them into a bag to return to the store.

Now, I admit that my question is not one of the top ten questions, and it might be embarrassing to put it on the automated reply options (Press 8 if the interface  doesn’t work as per instructions.) but surely someone has asked this question before, and somewhere, a content developer has tackled this discrepancy. The point is that there needs to be a strategy around content that goes beyond the basics. Now that I’ve calmed down and revisited the situation with an industry insider’s eye, the support site is lovely – beautiful colours and the navigation to the FAQs is quite simple. But when a customer is searching content, and can’t find it, then all the other niceties fall away. The laser beam focus on finding the content, which is needed to complete their task, overrides all other aspects of the user experience. Task-based analysis at its best.

So to AT&T, I would ask: if one of your questions is “Who is Charlie Johnson and why is his name displayed on my phone?” surely the question of missing menu items could be addressed, as well? This site is a classic example of focusing resources on the usability side of the support site, but not having a content strategy befitting such a site.  In this case, I did receive an email a few days later, referring me to a “real person” in another department, but by that time, my answer was, “Thanks, but too little too late. I’ve exchanged the phone for another brand.”

Seeing as how returns of electronic consumer products is a multi-billion dollar problem in North America, companies could definitely benefit from having strong content strategies, not just on their website, but across the product line, from instructions to training to their support site.

• October, New Orleans, LA: Lavacon
  A conference for techcomm managers and project managers, this year’s theme is professional and career development. If you sense a career change in your near future, or are out of a job and want to move to a field with a future, I’m presenting two sessions. One is on content strategy; the other is on managing your personal brand online.
• October, webinar: Leveraging Content Assets on a Tight Budget
  Part of Aptara Corporation’s Thought Leader webinar series, you can learn how to align technology and processes with business goals, leverage existing content assets for better user experience, and creating an optimized content supply chain
• November, Banff, AB, Canada: CANUX
  I’ll be presenting a case study at this 2-day Canadian User Experience workshop. If you attend, you’ll also get the infamous Kristina Halvorson, whose keynote my presentation follows
• December, Boston, MA: Content Management Professionals Association Summit
  The theme of the trade association summit this year is open source standards. My presentation on “open source content” is a little different aspect of content strategy.
• December, Boston, MA:  Gilbane Boston
  I’ll be moderating a panel discussion on Content Modeling and Information Architectures for Content Management, which is a critical aspect of content strategy.

If you can’t complete your professional development in the content strategy area during 2009, there will be multiple opportunities during 2010. Stay tuned!

Explaining CCM (component content management) to clients is sometimes difficult. The concept of combining content at the component level to create topics, which then get combined to create publications – or not; sometimes, topics just remain topics – is complex to understand to people who aren’t typically involved in the production or management of content.

Ironically, one group that has a hard time with the concepts of CCM are the IS/IT groups. For a while, this flummoxed me, as I thought that an understanding of the technology side would be an advantage to understanding it. Then it dawned on me that knowing the general principles of content management could actually become a barrier. Content management has become synonymous with WCM (Web Content Management), with CCM considered an obscure niche within the broader field, and WCM does not handle content at a sufficiently granular level. The final two words, “content management” are the same, but it’s the first word that makes the functional difference. It’s a little like thinking a truck is a truck, whether the prefix is “moving” or “dump”.

The difference is a little like that. For the average WCM system, content is input directly into the content management system, and managed at whatever level the content is input – generally, at the page level. A change to made to a page, and an edit udpates the entire page.

For the average CCM system, the content is created in smaller-than-page chunks, and assembled, much like a content mashup, to create a larger-sized page for output. A change is made to a component, which can be a single word, phrase, paragraph, or larger, which is then compiled, much like a software “build”, which generates a presentation version of the specified sources. The aggregated content can be pushed out to a Web page, a PDF, or a print destination.

When we think of mashups, we think of the Wikipedia definition of a mashup, which is combining data from two or more sources to create a richer information set. A common mash-up is an address with a map, that displays that includes both components as a single, integrated screen, with more meaning. A content mashup is similar – for example, when an ecommerce retailer pulls product descriptions from one data source and the prices from a financial system to mash together and display according to the requested content.

The technology that allows content to be mashed up before making it to the end display is an XML editor. The editor allows authors to determine how the components will be mashed together, whether that be through a manual mechanism such as a content map, or automated through an information retrieval system such as a taxonomy or thesaurus.

Whether understanding CCM as a mashup application is helpful for purposes of explaining to the technical parties remains to be seen. I do suspect that the analogy will strike a chord with a certain client segment, though, and that’s about all I can ask.

Janus is in the enviable position of living and working “across the pond” where talking about dysfunctions isn’t sanctioned by threats of lawsuits and exposed to the “shoot the messenger” syndrome. On this side of the pond, a CM consultant is expected to turn away, tight-lipped, and not expose irregularities to public scrutiny. When one sees, for example, a CMS contract awarded to a questionable vendor – the vendor rep who leaves the group RFP debrief, where requirements were being discussed, and courts the IT Director instead – any questioning of this manipulation of the system will work against the consultant. It’s as if ethics takes a back seat to the expediency that requires membership to the inside track.

Janus Boye is organizer of the J Boye conference series. At the Philadelphia, online professionals can share knowledge, hear great keynote speakers, and further their professional development. If I weren’t already committed to going to the STC Summit, I would definitely be there.