Topic-based Content Development: the sliding paradigm sands

Ok – last time we met, I talked about why you might break your information into little pieces and why that might be something that helps you. This time, let’s look the why and how.

Go get a cup of coffee and come back. Everything goes better with a little coffee.

So how is this different?

In Frame, Word, Pagemaker, InDesign, and any other tool I can think of (not MadCap tools), you define the deliverable when you think about developing content. When someone comes in your office to tell you that a new product is under development, you say: “So, let’s see. This is an electronic phonebook that can be used enterprise-wide. That means we need a User’s Guide, and Admin Guide and online help.” You defined the deliverables as what you see is needed, which may not be at all what the user actually needs.

In topic-based content development, you would say to that person: “So, let’s see. We need to understand what things the user needs to know to use the electronic phone book.” You define the deliverables in terms of the user and what they need to know.

A brief anthropological detour

In anthropology (and linguistics, where we stole the terms and concepts from), these are “emic vs etic” approaches.

  • An emic approach is where you describe a culture/language/religion from the point of view of a native in that specific culture. So, if you are describing a symbol in the modern day Maya religion, you would use the words and concepts that are what the modern Maya would use to describe that symbol. You would explain it in context of the native. Only the natives could tell you if you got it right because they are the ones who know.
  • An etic approach is where you would use the words and concepts of (in this case) anthropology to describe a culture/language/religion. So you would use the words and concepts of anthropology or academia to describe a symbol in the religion of the modern day Maya. The natives may not understand the explanation at all or may think there are invalid connections to other symbols or rituals.

So why two approaches, you may be asking? What’s the point? Good questions. In anthropology and linguistics, these are both useful, depending on what you want to accomplish.

  • An etic approach allows you to more easily do cross-cultural comparisons on symbols or language or dig deeper into the language or symbols that the natives can. This can give real insights into humans and is useful when looking for universal human behaviors.
  • An emic approach allows you to understand what it’s like to be part of the culture and how it works. You can better understand a specific thing about a symbol or language if you understand how the native think.

Consider grammar, for example. In your native language, you just “know” when a sentence is using improper grammar. You may not be able to explain it, but you can certainly “hear” it. That’s the emic approach. You are, in effect a grammar expert. You can confirm if someone has put together a grammatical sentence in your native language – most 5 year olds can tell if it’s correct. But to understand human universals about grammar, you need to have a “meta” way to look at language and talk about it. That’s the etic approach.

Back to Tech Comm

In all of Tech Comm, the information we developed is successful only if our users say it is. A topic-based content development approach is an emic approach taken to the next level – we develop information as though we are the natives, while retaining our etic hat. We are experts in the product; now we need to figure out what the natives need to know to use the product.

You develop a body of information that’s helpful to the user, instead of a body of information that’s helpful to you or your engineers. Your engineers are lovely people, I’m sure, but…

Paradigms are all fun and games until someone loses an eye

What this content development method does is help you not generate the content that your engineers typically want. They want you to talk about the search thing they put together for the reports. They’re very proud of it. They take it home and feed it cookies and brush its hair. They put its little head on a pillow when it goes to sleep at night.

But all your users care about is that they can make a report – “Look, right here, I see a button to click for creating a report and when I click it, I see a wizard that steps me right thru creating a report. Whew, that was easy!” if you develop the information from an emic perspective, you didn’t need that 20 pages explaining how the report engine works because the user doesn’t care at all.

But if the engineers don’t tell me what’s important, how will I know?

How do we start developing emic information?

Start with a Task Analysis. A task analysis means you sit down, perhaps even with the product, and create a list of what the user needs to use this product. Don’t worry about order or anything else. For my example Electronic phone book, here’s a fast list:

  • Installing on the server
  • Installing on desktops
  • Adding to Outlook
  • Adding users to the phonebook
  • Auto-completing names
  • Addressing emails to people not in the phonebook
  • Deleting names
  • Backing up the enterprise phonebook
  • Making the phonebook available to remote users
  • Managing the licenses for your site
  • Selecting the Phonebook in Outlook
  • Selecting the phonebook in Lotus Notes

And so on. Notice how we don’t care about what list item goes in what book? That decision, the decision about what information is going to go in what deliverable and that deliverable is going to be called, is something we will address later. Right now, we focus on the user and figure out what they need to use this product. The decision about what the deliverables are going to be is an independent decision from the information development.

You know you’ve got the level of detail right when you can see that the item in the list will take 2 to 2.5 pages to deal with, not including any graphics. These tasks are the topics that you will create in Blaze/Flare.

Today you got a side of anthropology to go with that coffee

It looks like our time is up for now. Thanks for stopping by. I’ll post more in the next day or 2.

5 Responses to “Topic-based Content Development: the sliding paradigm sands”

  1. […] Burton has a nice post explaining topic-based authoring. The idea is that you write your tasks in separate little chunks, […]

  2. Dividing your material into topics like also makes it easier to identify areas where a Mimic file would be in place.

  3. I love, love, love creating content in topics and being able to mix and match for new deliverables as the need arises. Especially when the client decides that the need arises on a regular basis. New flavour of a course? Sure – deliver within a day; the biggest issue will be getting the SMEs to sign off on which topics in which order. In industries where non-techies usually write the manuals, they think it’s magic. Oh, an online orientation is needed for the other audience – a subset of the other course? Sure, we can give you that tomorrow, next week if you want some interactive software simulations to be linked to it. My client shrieks, “Tomorrow? You must be joking! I haven’t been sleeping all week because of this!” My brain has always worked that way, and technology just caught up; I figured that everyone’s brain just worked that way, too. That’s the beauty of topic-based authoring. Thanks, Flare!

  4. […] (print outputs). If you’re still locked into chapter-based authoring, you need the power that topic-based authoring gives […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: