Content development no image

Published on January 6th, 2013 | by rahelab

5

Content Re-use and Narrative Flow

Just when I get to the point where I think  I’ve published everything I have to say about content strategy, I read something like the post by Deane Barker (@gadgetopia on Twitter) entitled Content Reuse and The Problem of Narrative Flow and I’m keen to jump in and participate.

Don’t get me wrong. I like Deane. I respect Deane. In fact, I was tremendously pleased when he called me for an opinion – a developer wanting perspective from a content strategist? I was happy to chat. Overall, we have similar takes on content re-use, but I do have to take issue with a couple of points that Deane makes.( This is not trash-talk; it’s considered and respectful debate.)

Deane claims that content re-use gets taken to an extreme, where the investment that companies make far outweighs the benefits derived from the content, that very little content is suited for content re-use, and that content re-use basically dehumanizes content to the point of sounding like it was written by a robot.

My first response is that there is a lot of content of that can benefit from a good re-use strategy, and there is far too little investment in content that it makes sense to re-use. However, narrative isn’t one of the genres meant for any kinds of re-use. This we’ve known since John Carroll wrote The Nurnberg Funnel (a reference to the Nuremberg Funnel) in 1990. Some genres weren’t meant for content re-use. News releases, for example, are an example of single-use content. You’ll never announce the same news twice, so building in re-use would be a waste of time. Well, except for the boiler plate that describes the company. Oh yes, and the contact blurb at the end of each news release. So there is some logical re-use, but that is a rather simple case that can easily be done through a Web CMS. I wrote an article about this in 2010.

Surfacing content: ways to keep content in sync

However, what we do know if which genres lend themselves to re-use.  If we think of how object-oriented code benefits developers, we can similarly extrapolate how systemic re-use of content can benefit writers, as I discussed in an article in 2006.

How understanding genre helps us understand structured content

A very real example of content re-use at its worst (and then at its best) is illustrated through the following example. A couple of years ago, my Blackberry was stolen when I left it behind at a grocery counter, and I found myself looking for a replacement. I still had two years left on my contract, so I looked at two different models available from my provider. Opening two different web pages gave me the following result:

All I knew was that I wanted an equivalent or better phone, and one that worked in Europe.  A long phone call later to the support centre resulted in me making these notes:

Now,  in the old computer papers, this was a common technique for vendors to mix up the descriptions to make it harder to make an apples-to-apples features comparison. But here, there was no reason to mix things up. I was a customer handcuffed to my provider for another two years. And a support call was sure to eat into their profit margin far more than a self-serve choice, so what was behind this confusing presentation? Picture two writers, sitting in their respective cubicles, probably in different work groups, making up their own feature lists when they could have drawn on a single feature set that allowed a user to make and process a choice without intervention.

A bit of a detour: I presented this as part of a keynote presentation at a marketing conference,  and at the lunch afterwards, happened to sit next to a marketing manager (or possibly director – I wasn’t really paying attention to titles) where we discussed this in more depth. I was delighted to go back to the site a couple of months later to find that they had made a commitment to improving their user experience.

To create this experience, they had to seriously step up their content game. The product names, features, prices, and images had to be separated, standardized, structured, and tagged in order to be presented reliably as users checked various combinations of choices.

To do this,  the content developer has to be serious about understanding how to author, structure, and tag content. Their job isn’t to create narrative text. (In fact, perky marketing copy can get very irritating very quickly, as I discovered when I was researching laptops. I couldn’t leave the page that described how  an interface would make my experience more intuitive and exciting (WTF?) and takes my computing experience to the next level (yeah, right, whatever.) I jumped right to the specifications page and started comparing processor type and speed, hard drive capacity and speed, RAM size, screen size, and so on.)

One of the other points that I dispute is that relatively little content works in a re-use situation. The benefits of having consistent, structured content is demonstrated with great clarity by my co-author, Noz Urbina, in our book Content Strategy: Connecting the dots between business, brand, and benefits, which I’ve summarized here.

In this real-life situation, consider a single chunk of content that gets used in 4 product lines, with 4 products per product line. That makes 16 uses. Then, each product has 6 deliverables per product where that content chunk is used. That makes 96 uses. Then, the content is produced in 4 delivery formats. That makes 384 uses. Then, translate that content into 12 target languages. That makes 4,608 uses. And finally, re-use that content for 4 audience demographics. That’s a whopping 18,432 uses. Do you really want authors to create this content 18,432 times? Or even 384 times? Or should they create a single content object and then reference it multiple times? This is not an isolated instance, either, though if your world is “marketing content on websites,” the masses of content outside of the marketing realm may be shocking.

One of my own clients had an extensive line of products, and the re-use factor was over 80% – in other words, once you chose one content object of type A, one of type B, one of type C, one of type D, most of the content was assembled for a product. There was only a small bit of custom text that needed to be written for each product. The website was, in effect, a veneer of marketing content compared to the masses of product content tucked away in the extranet for customer use.

It’s not a simple task, by any means, to get content managed at in just the right way. One of the big names in managing content at the component level that Deane didn’t mention is Joe Gollner. He recently wrote an article explaining why.

http://www.gollner.ca/2013/01/content-technologies.html

The final point that Deane makes is that readers expect narrative flow within content boundaries, and that the likely net result of content re-use is choppy, stilted text. Do I agree? Well, yes and no. The reason isn’t even because of technology. It’s the responsibility of the content developers to understand the implications of the content they’re writing, and to develop the skill and discipline to ensure that content can be re-used in multiple contexts. It may be hard to believe that in 2013, there are still writers who blithely confess they don’t know what a Word stylesheet is and don’t see why they should care. The majority of writers don’t know about content structure; in conversations about structure and discipline in authoring, I’ve watched them roll their eyes with disdain and declare that all of that three-letter acronym stuff (XML) is boring, and they have no desire to know about that stuff.

That leaves structured content to the content developers who have, by choice or by circumstance, embraced structured content and developed the skill and discipline needed to make content work. When these writers create re-usable content, the reader likely doesn’t even realize it – because the narrative disruption is noticed only when it doesn’t work.

So Deane, to answer your closing question – how much of a gain in efficiency is worth the effort – when done right: it can be worth a lot, a very, very lot.


Share this post:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • del.icio.us
  • StumbleUpon
  • email
  • Facebook
  • LinkedIn
  • TwitThis

Tags: , , , ,


About the Author



5 Responses to Content Re-use and Narrative Flow

  1. Excellent. As you say, Rahel, “Some genres weren’t meant for content re-use.” It’s unfair to lay a judgment against content re-use because it can be done wrong.

    In cases where content should stay the same in multiple places–for example, in user guides for various models of a product where the functionality is mostly identical–companies pay a high price for allowing that should-have-been-identical content to stray from one guide to the next.

    – They pay in terms of maintaining that divergent content through its life cycle.

    – They pay in terms of translating that divergent content more than once.

    – They pay in terms of risking the introduction of errors. “Oops, we forgot to make that edit in user guide #12″ doesn’t hold up in court.

  2. Mark Baker says:

    Rahel, I think we should make a distinction here. For purposes of making it I will use the terms “database publishing” and “content reuse”, but without the intent to define them for any purpose other than making this distinction.

    The example you site of 18,432 uses of a piece of content sound very much like a database publishing example. That is, the piece of content is question is created as part of row in a product database. The 18,432 places that this content eventually ends up in are the result of running 18,432 queries against that database. The content is created not as part of creating one of the 18,432 uses of the content, but as part of the process of populating the original database. The content is created to satisfy the requirements of the database record type, independent of its use in any of the 18,432 different “reports” in which it ends up being published.

    Content reuse, as commonly practiced, does not work this way. In content reuse, someone writes a document, dividing it into chunks as they go. Someone else then comes along, writing a different document, searches the CMS for a reusable piece, and includes it in their document. For the same chunk of content to actually end up in 18,432 different places in such a system is virtually unimaginable. Some of the 18,432 different authors will not find it and create their own version, which will then be found and reused by some of the other 18,432 authors.

    Database publishing systems work reliably, and have done so since long before tech writers started using these techniques. Content reuse is hard, expensive, and more often than not ends up creating a complete dog’s breakfast.

    If we focused on database publishing as an approach, rather than on ad hoc content reuse, we would get a lot further with much less aggravation. And the issue of narrative flow would seldom arise, because the kind of material that is suitable for the database publishing approach clearly is not inherently narrative in structure.

  3. Scott Abel says:

    Great points, Rahel. And, good feedback, Mark.

    Spot on.

    Scott

  4. Pingback: What I've been reading lately (week 2), by Samuel Ericson

  5. Deane says:

    I absolutely agree with everything you wrote here, Rahel. In specific situations, with content that lends itself well, content re-use is a worthwhile endevour.

    But I don’t feel like any of the example you provided were pure narrative. They were all highly-structured content in which the chunks were all surrounded by their own content boundary, thus making them absolute prime candidates for re-use.

    In these situations, re-use is a no-brainer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Back to Top ↑