Intentional Design Inc. » single-sourcing

Surfacing content: ways to keep content in sync

rahelab — Sat, 20 Nov 2010 02:00:04 +0000

One important aspect of publishing content on a website is keeping all content in sync. The content manager’s nightmare is having the same content in multiple places on a website that requires an update. Tracking where the content lives can be nightmarish, particularly when versions can fall out of sync, making subsequent updates more laborious. Having “one source of truth” is the holy grail of content developers.

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:

Don’t go to country X, effective immediately.

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. If someone comes into your office with the known symptoms, quarantine them and get them to a hospital as soon as possible.

Stay tuned for details.

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.

Component content management as content mashup

rahelab — Fri, 11 Sep 2009 15:37:29 +0000

Component content management as topic mashup

Explaining CCM (component content management) to clients is sometimes difficult. The concept of combining content at the component level, to create publications, 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.

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.

Redefining content strategy

rahelab — Thu, 11 Jun 2009 16:02:10 +0000

The definition of content strategy, according to Wikipedia, is “a repeatable system that defines the entire editorial content development process for a website development project.” This definition, not surprisingly, is taken from the The Web Content Strategist’s Bible, by Richard Sheffield. While there is no explicit connection of Web copy to marketing copy, the implication is that Web sites are marketing sites.

I would argue that, depsite the perception that websites consist of marketing content, for many sites, the marketing content is only the top layer – the icing on the cake, and what supports that top layer is a substantial amount of technical content – the cake itself.

Layers of content on a website

That technical content is often far more valuable to the corporate or product brand than the persuasive content. In doing user research for one client in particular, a manufacturer of power generators and inverters, I saw how guys used their site. Consistently, they would bypass all of the marketing material and go right for the specs. (Of course, before the site revamp, a lot of the specs were missing or buried in a PDF in some obscure area of the site, but that’s a whole other story.) They knew what inverters did, and what to look for, and went directly to find what was, to them, the important piece of information.

In effect, the technical specifications were the marketing material; if the inverter had the right oomph to it, that’s what the users wanted to know. And had the content been wrong, had the inverter been used with some disastrous results, then the ensuing fall-out would have become a marketing problem. The artificial siloing of content between organizational departments – marketing, techdocs, training, support, engineering – is reminiscent of the discussions we had about information arhcitecture, some 8-10 years ago. The difference is that for many organizations, these larger silos have become de facto standards in which they bucket their information for consumers. They assume that when a content consumer arrives on their site, they want to see a certain type of content. They try to funnel the user through their site navigation or constrain the path to the cash register. But if you look at the way consumers actually use a site, you can see that they will not be constrained. In this case study, Jakob Neilsen reveals that consumers will breeze past the feel-good content and head right for the techincal information, product reviews, and other information pertinent to their decision-making process.

The content that was sought out by the consumer, in this example, is probably produced by a department that publishes to multiple channels, not just the Web. Their content strategy likely has to take into account single-sourcing for print as well as Web, and other channels such as training materials (possibly print, e-learning, and a Web output), manuals, product data sheets, and other end products. The Web is but a slice of a greater strategy. When we talk about content strategy, then, my contention is that the type of content we include in the definition needs to broaden beyond Web content, as does the recognition that the content, even if just for the Web, includes not only persuasive content, but instructive/informative, user-generated, and even entertainment content.

Protecting your corporate content assets means easy interchange

rahelab — Wed, 11 Mar 2009 16:57:42 +0000

To get the most out of your content, you need to be able to re-use it in appropriate places, rather than recreate content for each new situation. It follows, then, that re-using content requires that content be in a format that lends itself to re-use.

If you’re the type of person who likes to write, think, edit, and then publish , tink about the pain of re-using content from an article created in a word processing program to a blog entry. You had to go through and check things like apostrophes, quotation marks, and dashes to make sure you didn’t end up with question marks in the middle of your carefully-crafted prose. That can be called “dumb work” – silly rote tasks that don’t add any value at all.

Now, multiply that dumb work by millions when content gets locked into a proprietary system. You may have a million-dollar content management installation, but what happens when you want to use your content elsewhere, or when you need to migrate content between your behemoth system and specialty systems, such as a component content management system?

Unless there is a vested interest by, say, a competitor in providing some sort of import wizard from a specific proprietary format into their own format, your content is now held hostage by the vendor’s system. This used to be considered good business sense, as it locked you into their system for long periods of time. In today’s world, however, it’s considered a pretty bad move on everyone’s part. The recognition that content is a valuable corporate asset whose value increases with its potential for re-use has changed the game.

Re-use is a concept that is often discussed at too low of a level within the corporate sphere. There are several kinds of re-use:

Single-sourcing. This isn’t a particularly sexy type of re-use, but is the industrial workhorse of re-use that is the backbone of any product or service provider that produces technical content (user, installation, maintenance, and quick-start guides, training material, knowledge bases, and so on). The ROI on standards-based, re-usable content becomes critical, particularly in cases where translation are involved.
Integration. Content among departments, divisions, or partner companies may need to be mashed together to create a cohesive whole. Saving troublesome conversion steps toward a common format is a huge time-saver, and eliminates the worries that the conversion process has eliminated or corrupted critical content that affects the quality and integrity of the end result.
Convergence. This re-use case is bringing together content from various types of sources, such as mixing single-sourced content with user-generated content in a knoweldge base. The need to “round-trip” content relies on being able to get content in and out of systems easily and quickly, with as much automation and as little human intervention as possible.
Syndication. Content flies (or should fly) outside of the organization, in the form of news releases, event announcements, and so on. If content doesn’t conform to the standards-based formats – microformats is the most common example – then the value of automating syndiations is lost, with a default position of cutting and pasting into multiple sites.

Having content that can “play nice” with other systems is a key component of a good content strategy. Because large-scale content projects are dependent on the technologies that manage the content, it’s critical to look at how the system treats the content, and how open the content is for re-use in strategic ways.