We used to be in the writing business. Then we were in the communication business. Now we are in the content business. It’s probably getting time to change the monika again. I have a candidate: “story.”
There have always been two schools of thought about the word “content”. Some love it. Some hate it.
I hate it. It is an ugly generic word chosen specifically not to mean anything specific. We can’t say “writing” because sometimes we use pictures. Etc. Etc. It is the sort of word you use when you don’t care what is in the container. (Many years ago I asked a Documentum rep what Documentum meant by content, to which he replied, “anything you can store in Documentum.”)
But the problem for “content” haters is to propose a suitably comprehensive alternative. Which is catch-22 because anything equally comprehensive will also be equally generic. The only way out of this catch is to go meta, to focus not on the artefact but what the artefact represents: story.
“Content” exists to tell stories. All the forms we use to tell stories are incidental to this. What matters is the story, and any media you can use to tell that story is merely a tool of the story business.
Now, lets see what happens when we drop “story” into some well-known “content” phrases.
From Content Strategy to Story Strategy
Content strategy has always struggled to define itself. This is no doubt due in large part to the generic nature of the word content. If content is anything that fits in a container, then content is everything. Some definitions of content strategy seem to embrace this broad definition, claiming that content strategy is about everything an organization thinks, does, knows, says, and is. Others limit it in various ways. To some it is specifically digital, or specifically Web-oriented, or specifically marketing oriented. To some its seems to be little more than a fancy word for copywriting.
What happens if we talk about “story strategy” instead. This seems clearer to me. Story strategy is about how an organization tells its story (overall) and how it tells its stories, of which it doubtless has many.
Clearly technology and media are part of that strategy, but they are not the focus. The focus is story. Clearly too, this is not a strategy for every piece of data the organization holds. It is about its stories and how they are told.
That is not going to immediately banish all arguments about scope and jurisdiction, but I think it is a step in the right direction and is an immediately more concrete way of expressing what the discipline is supposed to be about.
From Content Lifecycle to Story Lifecycle
Here is where we would start to see the change in emphasis making a real difference. Content lifecycle puts an emphasis on individual artefacts: bits of text and graphics being created, published, and retired. Story lifecycle puts the emphasis on the story to be told and how it changes over time, how it becomes of interest and ceases to be of interest.
That a story has a lifecycle that needs to be managed is an idea very familiar to the news media and to politicians. News media produce many artefacts to tell what they often call “a developing story”. Politicians often seek different ways to tell their story to different constituencies.
It should be clear that for any organization, the story, and its lifecycle, is more important than any individual item of content. For any organization, many individual content artifacts will be created, modified, and retired over the lifespan of a story, and that story will be told in different ways, in different media, for different audiences. Managing the story is far more important than managing the individual artefacts. Indeed, managing the story is, or should be, the main reason for managing the artefacts.
Thinking in terms of managing the story lifecycle also puts us back in the realm of the writerly mindset, rather than the database mindset that often informs content management design and decision making.
From Content Management to Story Management
Which brings us to content management. How different does the role of story manager sound from the role of content manager? The former is clearly an editorial role; the latter sounds more like an IT role.
How differently might a content management system look and behave if it was conceived of as a system for managing stories rather than generic blobs of “content”?
Yes, of course, we would still need systems for managing texts, graphics, videos, and any other communication artefacts. But suppose that we thought of what we were asking that system to do in terms of the stories to which the individual artefacts were merely contributory?
What do you think, is it time to move on from “content” to “story?”
Mark, great perspective here.
Is it time to move on from “content” to “story”? Yes, I think it is. As long as we stipulate that story = narrative + data, as you pointed out in a comment on my blog some months ago.
Indeed, and this speaks to the point Kate Sasnyk makes as well.
Mark,
That’s a much better story for describing what we do.
Thanks!
Story over Content is good and all – but it is fetching to short. I’ve come to use the terms “dark arts” and “black magic” lately, because it is a more holistic approach on what our business actually is.
We’re more in the business of creating illusions in the minds of others, using arts that nobody outside our business really understands, often accompanied by also using dirty tricks. We do that by using tools, knowledge and ingredients of all sorts, often borrowed from other domains – but only we do have an insight of how these bits will come together to a whole picture.
So, here I am, throwing in the terms “Strategy of Black Magic”, “Ingredient Management” and “Illusion Lifecycle Management” to the discussion.
Er, okay. Do you have an algorithm for that? Or a method, maybe?
Hi Mark,
actually I’ve got methods for parts of it and I’m trying to put them into a greater context piece by piece 🙂
Last spring I held a workshop about information development on the tekom conference using some of the more obscure techniques I’ve learned when dealing with minimal information input.
But no, nothing, that I could pull out my sleeve – yet.
What I’m trying to point out with the term “Illusion” in the story context is, that we have done a good job, when our stories provide the illusion of understanding for the audience.
A good storyteller creates images of his tale in the minds of his audience and thus creates the illusion of a consistent world and actions happening there make sense for the one that listens.
The same goes for product documentation. We strive to create the illusion for the customer, that he actually can understand how the product works. That doesn’t necessarily needs to be the case, as long as the illusion is there and the customer can get along with it.
For the time being you can ask yourself: Did you ever hear “How did you know/do/accomplish that?” in context of your work?
If you ever did, you certainly used some “magic”.
Okay, I see what you are getting at.
But it is not magic. It is storytelling.
But I get that there is something going on in storytelling that looks a lot like magic is we start with a database mindset in which we expect all terms to be fully defined.
Natural language operates by invoking stories that the reader knows. But the reader is also a participant in this. The reception of natural language involved the contextual decoding of the stories that the writer is attempting to invoke. The reader, therefore, is not a passive receiver.
The essential problem with the content management mindset may come down to this, that it tends to treat the reader as a passive receiver. It attempts to locate and deliver a data packet in response to a query. But the reality is that the reader’s engagement with the content and the subject matter is active and ongoing and cannot be captured or modeled by a query/response pattern.
Navigation is through content, not to content. That is not magic. But if you think of the world in query/response terms, it may seem like magic.
This is only part of the concept. Just wanted to stay on topic here 🙂
I’m seeing these kinds of things happen in our whole work process.
With enough experience in the field, you’re able to extract data where noone would expect it.
We’re juggling with data, transformations, media and other assets back and forth, more than most other professions out there.
We’re talking the languages of the SMEs, Psychologists, Linguists, Translators, Programmers and Mr. and Mrs. Smith out there.
We’re moving between the roles of authors, lectors, projekt managers, programmers, designers, developers, product managers, information designers and content strategists – every day (ok, exaggerating a bit).
The techniques and methods we’re using are understood by very few people outside the business and even when inside the business there are myriads of tricks and approaches that make things look like coming together magically.
Ah, the Arthur C. Clarke meaning of magic. http://www.brainyquote.com/quotes/quotes/a/arthurccl101182.html
Alex,
I have to say it, but this sounds like a cry of despair from a place where the stories you push out the door are more about hiding the problems, rather than helping the customers get to know a really great product.
Maybe you should move to a place where the product is real, not illusion? Of course there may be a happier explanation.
All my very best, Rob.
Hi Rob,
actually this is where the original idea was born and where I’ve learned some of the techniques – but I left that place long ago. Nowadays I’m confronted with other issues in other contexts and the same basic principles are still working for me.
The most important one to me is to think out of the box.
The second most important one is to actually understand the topic you’re working on.
The third one is to look at the topic from various points of view.
This leads to the ability to use “dirty tricks” on stuff that doesn’t work with common practice.
And in return this leads to those “magical” moments 🙂
Mark, thank you for a great post suggesting alternative view to what we do and how we name it! Great to find that not only I find the word content too generic 🙂
However, I also have concerns regarding the word story to describe what we do. On the one hand, it shows the user-oriented perspective of the job we do and implies that context and aim are always important. On the other hand, the word story itself has the denotation of entertainment, short news, events that might not be true, which sound quite contradictory in this context…
Thanks for the comment, Kate.
Yes, there is a tendency today to treat the word “story” as a synonym for “drama”. I suspect this may be a recent development. In Aspects of the Novel, E. M. Forster makes a distinction between “story” and “plot”. Story, he says, is simply a sequence of events; plot is a series of events plus the reason for them. I suspect if we were to make that distinction today we would exchange the two terms. Robert McKee’s book, Story, probably expresses the modern notion of what “story” is — the core of drama.
But here clearly we don’t mean drama. We mean a much broader sense of “story”. As an example, if we take the acronym “NATO”, common tech comm practice would be to expand the acronym on first use. But saying “North Atlantic Treaty Organization” barely tells the reader more than “NATO”. You don’t know what “NATO” means without a story about what the alliance is, who is a member, what commitments members make to each other, and what its ongoing operations are.
That story is not a drama, be it is a collection of related information with a narrative structure. What we call content is all material that tells stories of this sort, even if few of them are dramas.
Mark,
Great article.
I particularly appreciate this: “The former [story] is clearly an editorial role; the latter [content management] sounds more like an IT role.”
I suspect that distinction is the reason some (many) CMS and CCMS projects fail or do not deliver all of the benefits expected; people expected the system would be used by “content creators” whereas it is actually used by “story tellers” — and the stories keeps changing.
Yes, exactly, stories keep changing. And their relationships to each other keep changing. The tendency to treat content management as a storage and retrieval problem really misses this point, and thus attack what is fundamentally a secondary problem at best. Yes, storage and retrieval can be a problem for storytellers, but it is not the core problem. At best, it contributes to the core problem only by removing or reducing a distraction. If people expect more from it than that, they are likely to be disappointed.
I see the term Story in a Minimalist framework.
The Task is the center of your documentation, the part that people want to find.
We are writing Story.
And sometimes when you are telling Stories, the kids say “Why did he do that?” Then we provide some Concept material.
Or after the story, maybe they ask “How big was the axe that he used to chop down the tree? How did he carry the sword and the axe and the crown at the same time, all the way down the beanstalk?”
And the Story teller gives them some Reference material.
Hi Rob,
Actually, I would say that story is why the reductionism of the terrible troika of concept/task/reference (/2012/07/28/the-tyranny-of-the-terrible-troika-rethinking-concept-task-and-reference/) doesn’t work. It as content management view of communication, not a storyteller’s view.
I think one of the key misconceptions around findability is the idea that people are looking for a task. They are trying to complete a task, and they need information to do it. They are looking for the information they think they need to complete their task, and what information they think they need can vary greatly depending on who they are, what they do and do not know, and on where exactly they got stuck.
And they are often wrong about what information they need, because they often don’t understand what it is they don’t understand or don’t know what it is they don’t know.
We tell stories not because we know exactly what people need, but because we don’t and cannot know exactly what they need, and nor can they. We tell stories to connect things together so the people can find their place in that matrix of connections and eventually orient themselves and find a way to move forward.
This is also why narrative + hypertext is a much more powerful combination than narrative alone (or than narrative + categorization).
OK, I like that. I have been living in a DITA environment too long, I think.
If I can elaborate on your context, with respect to reference, I want to to see if I understand how that would apply in API docs, as an example.
If our Reference material contains at least some minimal info about how this thing is used, with an example, we provide a story context in which hyperlinks to related places make some sense.
In contrast, a list of “related” links on the side of the page offers nothing more than the titles to help you decide which one has the info you need.
One of the problems with “reference” as a content type is that “reference” can mean a number of different things.
In some contexts it means a data set that you look up individual data points in. Example: phone book.
In other contexts, it implies a reader behavior that is the opposite of “study”. Study is something you do in time set aside from work. Reference is something you do in the course of your work when you need information to continue working. Traditionally, a “programmers guide” was designed for study and an “API reference” was designed for reference.
But by this definition of reference, a procedure is also reference material. You look it up in the course of your work, just as you do an API reference entry.
Both a procedure and an API reference entry are stories. Specifically, they are stories in the sense that Larry referred to: narrative + data. This contrasts to a phone book, which is just data.
Look at it this way, though, and the concept/task/reference troika falls apart. To suggest that a procedure is a task and that an API reference entry is a reference ignores the fact that both are combinations of narrative+data, and both are use for reference by people as part of their work, and for the same reason.
Fundamentally, categorizing API reference entries as “reference” topics is to stumble over a simple ambiguity.
Categorizing two such similar story types, that are used in such similar ways, as two different fundamental information types just doesn’t make sense.
All useful stories contain concepts and data combined in a narrative structure. Many stories, though not all, are used to support tasks. The concept/task/reference troika severs these relationships in unnatural and destructive ways.
Regarding related links, as you say, separating them from their context in the story robs them of context and relevance. Bad practice most of the time.
Pingback: They’ll thank you when… | Leading Technical Communication