I have wanted to write about the role of story in technical communication for a long time. It is certainly a subject that comes up again and again, but without any clear message emerging. I have long felt that yes, story is fundamental to technical communication, but I could never quite pin down how.
It is well understood that story is fundamental to human beings. We are a species who tells stories, who understands ourselves and our roles in the world in terms of stories. The marketing business has long recognized the centrality of stories to what they do, and the importance of story in creating an emotional connection to the reader. A Harley Davidson executive is supposed to have once said:
What we sell is the ability for a 43-year-old accountant to dress in black leather, ride through small towns and have people be afraid of him.
That’s a story.
But what has that to do with technical communication? Presumably the Harley Davidson repair manual was not written to evoke this same emotion. If good tech comm generates emotion, presumably it is the satisfaction of a job well done. Perhaps it is the confidence to tackle a job in the first place, if we count such confidence as an emotion.
But this presumes that story is always about emotion. More specifically, these days, it seems to presume that all stories are a telling of the hero’s journey, the theory of storytelling that has dominated Hollywood since Star Wars.
Imagining the user as a questing hero in search of a pearl of wisdom in order to make their phone work just seems silly. And it violates the principles of simplicity and directness that are fundamental to technical communication. Anyone who has encountered tech docs that attempt to be “fun” knows the result is almost always an excruciating waste of time.
But my recent post on taxonomy led me down a path to appreciating the role of story in all communication, including tech comm. When you try to pin down what individual words mean, you quickly discover that they don’t convey anything very specific until you use them to tell a story.
The word “store” by itself has a number of associations, but it does not really mean anything concrete until you put it in a story:
Dave went to the store to buy milk because the baby was hungry.
Words can have multiple associations, multiple denotations, but it is only when juxtaposed to other words in a story that a single denotation emerges.
In other words, story is not a special form of communication; it is all of communication. We communicate by telling stories. The hero’s journey is not an archetype of all stories, just the archetype of one type of story.
By themselves, the words “run,” “see,” and “spot,” can each denote a number of objects. Put them together into a story, “See Spot run.” and you have something that creates an image of a running dog.
At least, you do if you belong to a culture in which “Spot” is a common name for a dog. If not, maybe the image you got was of a spot of wet paint dripping, or maybe something else, or maybe nothing. If your early education included the Dick and Jane books, from which that line is taken, you also see two small children, a boy and a girl, to whom the dog belongs.
The word “dog”, however, is not in the story itself. The image of a dog that the story produces in your mind is a result of you knowing that Spot is a common dog name. That too is a story. The story “See Spot run” depends on you knowing the story “Spot is a common dog name.”
That is how stories work, by invoking your knowledge of other stories. It is a wonderfully efficient system. If we had to explain everything all the time, we would never get anything said. By appealing to stories you already know, though, we can be much more compact.
Here is a paragraph from a recent opinion piece.
Algorithms make mistakes all the time. Just think about auto-correction on your iPhone, the recommendations on Netflix, or the coupons automatically printed at Kmart’s checkout. Just this past week, a fraud detection algorithm incorrectly blocked my ATM card while I was traveling in Germany, despite having called in a travel notification before the trip.
In this one brief paragraph there are reference to a half dozen other stories at least, and if you really analyse it down, probably many more. Autocorrect often makes amusing mistakes. Netflix recommendations are often silly. Kmart’s coupons are usually for things I don’t want. None of these things are said explicitly. The appeal to these shared stories is enough.
Is there anything other than stories? There is data. There is also a theory that distinguishes between data, information, knowledge, and wisdom. But while this sounds compelling as a set of words, it turns out that people have great difficulty defining what each of the terms means, particularly knowledge and wisdom.
I’m going to suggest something much simpler. There is data and there are stories. Data is simply data. Facts. (I defy you to come up with a definition that is not circular.) Stories seem to have two essential properties: they are world building, and they are transitive. That is, they build a picture of the world in the reader’s head, and they then create a change in that picture.
Information, knowledge, and wisdom, it seems to me, all come down to the stories you have in your head. Perhaps the progression to wisdom is a matter of having stories that link to other stories in useful ways that make better sense of the world, that provide a more secure foundation for decision making and action. But I would submit that they are still just stories.
As communicators, then, we are storytellers. Not hero’s-journey storytellers, but still storytellers, because there really isn’t anything else. If we are doing anything more than recording data, we are telling stories.
And the way we tell stories is by stringing words together in ways that evoke stories that the reader already knows. If the reader does not know one of the stories that you invoke, they have to go learn that story before they can move on.
Figuring out what story they have to go learn, however, is not always easy. We usually evoke the sub-stories of our stories by implication. We do so because it is efficient, and because it his how our minds work, how we form language and understand it. But if I do not know what is implied — if the word that does the implying is a word that, like most words, has many denotations, and if the apt denotation is one that you recognize only by context, it is very difficult for an uninitiated reader to find the end of the thread.
This, I suspect, is at the root of the problem know as “the curse of knowledge“. It can be described, per Wikipedia, as “a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties.” But what the better-informed party knows, that the lesser-informed party does not know, is stories.
And the reason, I would suggest, that overcoming this bias is so difficult, is that we integrate these stories so tightly into our language, that the invocation and recognition of them becomes essentially unconscious. (Just as language would be appallingly inefficient if we had to explicitly tell all these stories, it would be appallingly inefficient if we had to think them all through in order to speak or write, and explicitly recognize them in order to understand.)
And this is why communication on a broad scale is fundamentally difficult, why people often require multiple sources of information combined with practical experience, to grasp what may seem to us elementary concepts: we have so internalized the stories on which these concepts depend that we have forgotten how to tell them, and that we need to tell them. And for many concepts there are so many stories — stories on stories — to be learned, that there is no shortcut to understanding.
This is why readers don’t read in a straight line. This is why every page should be page one — because every page tells a story, and people need stories in an order and sequence that are unique to them, and that is uncovered only as they learn, for each story they discover depends on other stories they must learn.
It is also why stories should link richly — because it helps the reader to find the stories they need, not just because it is faster than searching, but because links — good links — resolve the ambiguity of implied references to stories.
And it is why we need a disciplined and systematic approach to linking, because that helps overcome the author’s curse of knowledge about what stories they are implying, and even when they are implying them.
*Edited 2015-07-29 to amend a passage that was needlessly and thoughtlessly derisive.
Very well said, Mark. You bring out, to a degree I hadn’t considered before, the vital role of context in storytelling. I can infer a story from “see Spot run” because my context includes the Dick and Jane books. Other readers might infer a totally different story, or no story at all.
It’s hard, therefore, to rely on stories to lead our readers to the knowledge they need. Hard, but absolutely necessary. So I believe you’re right: each topic needs to establish its context and provide links for readers who need help seeing that context.
Aside: Before I wrote this comment, I wanted to make sure I was accurately citing your views on context. So I decided to search your website. And I was very surprised to discover, given your views on how readers find information, that the site doesn’t have a search box. (P.S. With a little old-fashioned navigating, I found the article I was looking for. It’s titled “Subject First; Context Afterward.”)
Thanks for the comment, Larry.
I dropped the search box a year ago as part of a decluttering that I talked about in this post: /2014/07/07/tech-writers-must-learn-to-stage-content-better/. To date, you are the first person who has complained.
You are not the first person who has missed it though. The other would be me. And when I miss it, it is for exactly the same reason: to find a specific post on this site that I remember and want to cite. Like the one I just cited. :-/
This may be the one role that site search is good for: looking up specific articles on a site that you remember — as opposed to searching for information. So maybe I will put the site search back.
I won’t touch knowledge or wisdom… But I’ll try to define information in relation to data — information is the compression of data such that the data can be reconstructed by the receiver of the information. The most elegant example I know is the story of Johannes Kepler.
Kepler worked as assistant to Tycho Brahe — Brahe had the best astronomical observatory of the time (in Europe, anyway). Brahe was collecting data about the motion of heavenly bodies. He never let anybody at the data, not even Kepler.
Fortunately Brahe died, and Kepler got a-hold of the data. From that data, Kepler derived his laws of motion:
* A planet orbits in an ellipse
* A planet moves faster as it gets closer to the ellipse focus
* The orbital period and radius make the same ratio for all orbiting bodies
Brahe gathered data, Kepler created information… Brahe could give you a catalog of all the observed positions of a planet. With very few variables and three laws, Kepler could reconstruct the full data set for any orbiting body.
Now, I did use a story to describe this example. But I wonder… Would you say there’s a story in Kepler’s information?
Thanks for the comment, cud,
I would definitely say that Kepler created a story. At least by the criteria I described in the post: world building and transitive. Kepler told a story that explained how planets move.
This is an interesting case, too, because it illustrates a class of story with an interesting property: it enables prediction. We tell all sorts of stories like this, stories that enable us to predict what will happen in the future. We depend on such stories to plan and prepare for what is to come.
Today we tend to be quite literal in how we tell such stories. This does not make them any less stories. But there are myths and tales that do not really fit the model of modern entertainment (the hero’s journey) because they are not that sort of story — they are predictive stories told in figurative or analogical ways.
This is pretty much where I would have hoped you would go with that question. The only thing I would change is this — more than calling the story predictive, I’d call it productive. Kepler’s story enables others to create their own stories.
Sure, anybody can create a story any time he likes. But with technical communication the issue is to create stories within the bounds of the technical domain. Kepler enables story creation within specific bounds… Our recent trip past Pluto is one example. The value we add as tech writers is to produce information that enables people to pick up and run with a technology — to create their own stories within that domain.
I like the idea of a productive story. I suppose all stories — or at least all good stories — are productive in the sense that they enable us to tell other stories. But a story that provides the confidence to act is productive outside of the realm of language, and that is precisely the business we are in as technical communicators.
This is one of the reason that it is so hard to produce good metrics for tech comm: the only measure of its value is in the actions that its readers take. It is valuable because it is productive, and hard to measure for the same reason.
So, Kepler was a technical writer, and his technical writing enabled a bunch of NASA engineers to send a spacecraft to Pluto. I somehow doubt that showed up on his annual performance review, though.
Mark, I simply dig this post. My background is in linguistics, and I was nodding all the way through.
As small children, we all perform a congnitive miracle. We deduce stories from scratch. That is, we hear language
(“data”) all around us, and with astonishing rapidity, distill the data into stories that inform us of our world.
The first stories we form are elemental, and we form them without any reliance on or access to, other stories.
(Though one can well argue that this feat is evidence that we arrive in the world pre-programmed to a great extent.)
Having done this once, we can never really do it again–build stories independently of any other stories.
I had a feeling where you were going from the start and by the time you got there, I was completely warmed up to it.
In tech pubs we must somehow figure out which stories to rely on when telling a new story. It’s easy enough when
we’re writing fiction; we can assume that most readers out of childhood will have had certain common life
experiences. But we can never assume common technological experiences and that’s the rub. It makes perfect sense that beneath all the discussion about hyperlinking, content chunking, modular writing, etc., what we are really trying to do is figure out what stories to tell and how to make them accessible to those who need them.
Thanks for a great post!
Leigh
Thanks for the comment, Leigh.
I agree with your conclusion wholeheartedly. I have increasingly come to feel that we have focussed on publishing efficiency to such an extent that we have somehow, at least tacitly, come to believe that we should be able to make information finding as efficient as a database query. But making data finding efficient and making story finding efficient are very different things. There are severe limits to the latter, just based on how we create, understand and share stories. Carroll’s paradox of sensemaking is very relevant here. Optimizing story finding is very much something that happens in the content, not just the metadata.
“…threads…should link richly…” In my writing, I try to bring together the right words and related links to build a tapestry, weaving together interrelated ideas in a cohesive way.
Hey Mark;
You’re somehow on my karmic weft now.
I was just emailing a guy that writes stories about technological innovations and how businesses might put them to use. (no, not marcomm…). He helps entrepreneurs bring their stories closer to the marketplace.
There has also been an interesting (if sometimes testy) discussion about the difference between information and data on LinkedIn. Essentially, it comes down to accepting the orthodox approach which you correctly identified as something important-sounding, or trying to see things more completely in terms of a progression of energy.
Finally, my wife was reading Deepak Chopra’s “Seven Secrets of Success” on our vacation and came across a line that read: “In the beginning, everything was energy and information…”
It seems like the Kepler story is missing a piece and it is one that could begin to address some of the issues you and other posters are raising. What Brahe was recording was the information he could see in the movement of the planets. He, like many others, felt that if he could only record enough information is a very rigorous way he would begin to see new information that would make predictions possible.
The point is, without first technically enhancing the original information as data, neither he – nor Kepler – would have been able to prove that the raw information (again, recorded as data) was in fact part of a much larger and ever more informative pattern.
What I see when I read this is a flow of production like this:
INFORMATION -> data -> information, where the INFORMATION is some primordial information that always was, always will be.
For me that can’t work — here’s my problem. To start, data and information are psychological constructs — they only exist in a mind. Example: The markings and audio disk on Voyager are neither data nor information as long as no “mind” perceives them. Another example — if a tree falls in the forest… I won’t argue whether it makes a sound, but if nobody ever perceives that the tree has fallen, there is neither data nor information. It just is.
Observation is a requirement for data. In fact, observation is often used as a synonym for data — “Here are the results of my observation…” “Let me share my observation…” Data, in the Brahe/Kepler story is the the collected record of observations.
You might argue for a mystical observer — God or a living universe, etc. It might exist. But it can’t really help technical writers produce information, at least not in any scientific way. The existence of “information” on a mystical scale doesn’t really “inform” me as a technical writer, and it didn’t inform Brahe or Kepler. Until Brahe tracked the positions of Mercury in the sky, he had no data or information about the positions of Mercury in the sky. The fact that Mercury most probably demonstrated Kepler’s laws for eons doesn’t mean that humans were informed by that fact until Kepler put it together.
Ok, so why do I care? I really think a good understanding of data vs information, and the ways in which people can produce transformations are key to the value that a technical writer can add. I’ll give my favorite example of lousy writing — The Foo button foos a bar. To foo a bar, click Foo.
Scintillating. And correctly task-oriented. And content-free.
Hmmm… Come to think of it, this is turning into the perfect Tech Writer interview question — “What’s the difference between data and information?”
“The markings and audio disk on Voyager are neither data nor information as long as no “mind” perceives them.”
Hmmmm. So by the same token, a muffin is not food unless you eat is. Which kind of raises the question, how do you find food, since muffins are not food until you are already eating them?
More directly, it implies that the books on my shelf and the sectors on my hard drive that are not currently reflected on my monitor contain no data or information. Which in turn suggests that the data is spontaneously generated as I access a sector or turn a page.
This really puts paid to the whole idea that we can record or transmit data and information, since they don’t exist in the absence of a mind. Indeed, we can’t even talk to each other, since that involves the transmission of sound waves, which are not mind and therefore cannot contain data/information.
Clearly these propositions are absurd. But how do we get into this position of absurdity? I submit it is by misunderstanding what words are and where meaning lies.
If a tree falls in the forest, it creates vibrations in the air. When a human being’s ear detects those vibrations, we call them sound. Presumably we are not questioning the existence of the vibrations. The way in which we experience those vibrations as pleasurable or informative is indeed somewhat mysterious. Does that mean that “sound” is that je ne sais quoi of human experience, not the vibrations, and that therefore the je ne sais quoi is sound and the vibrations are not?
Clearly not, at least as we commonly use language. Because if “sound” is the je ne sais quoi and vibrations in the air are not, then we cannot record sound, and we talk about recording sound all the time. Also, speakers cannot produce sound (only vibrations) but we talk about speakers producing sound all the time, and would regard it as silly (though true) to talk about them producing vibrations.
So what is going on here? Quite simply, people operating in different domains — philosophy, neurology, sound recording, etc, are using the word “sound” to tell different stories. The word “sound” contributes it connotations to the meaning of those stories in different ways, each determined by how it is juxtaposed to other words, and how it is situated in the domain of discourse.
So why is “when a tree falls in a forest, does it make a sound” such a conundrum? Simply because we don’t know what domain of discourse it belongs to. The problem is not that we don’t know what the word “sound” means, nor that we don’t know in some general sense what sound “is”, but simply that we don’t know what story is being told, and therefore can’t resolve the multiple connotation of “sound” in a satisfactory way. It is not a philosophical problem, it is a piece of linguistic sleight of hand.
“The fact that Mercury most probably demonstrated Kepler’s laws for eons doesn’t mean that humans were informed by that fact until Kepler put it together.”
Indeed, until that motion was perceived and that story was told, people did not know that story. People create and tell stories to explain the things they observe about the world. Stories, not words, are how we communicate.
“I really think a good understanding of data vs information, and the ways in which people can produce transformations are key to the value that a technical writer can add.”
I agree with you on fooing the bar. But I don’t see this as a confusion between data and information. “The Foo button foos a bar. To foo a bar, click Foo.” is a story. It is not content free. It is simply content that tells a story that the user can almost certainly perceive for themselves. Interfaces tell stories too — that is one of their functions — so fooing the bar is simply repeating a story the user has already been told (and probably knew anyway).
Which is why the proper role of tech comm is not to tell the story the interface is already telling, but to tell the stories that the interface itself cannot tell, which is how to connect the user’s business problem with the capabilities of the machine.
That is, of course, in a culture in which people understand the language of interfaces. In a culture in which they don’t (say, every culture in the world pre 1990) then the job of the documentation was to explain the stories on which the interface was relying to tell the story it was telling. This is what tech comm was mostly doing in the 90s, and apparently a fair chunk of tech comm has not get the message that those days are over.
Ok, I knew I was in trouble over the Voyager thing when I hit SEND. Yes, the markings on Voyager are stored information. My point is, so what? If a mind never finds them, they might as well not be. Without mind, there is no data or information. It took a mind to store that information and it will take a mind to unpack it. And that’s precisely what Voyager is looking for, I might add.
I stand by my tree example. If the tree falls and nobody observes it, we simply have no data… by definition. Data IS observation, and observation requires mind. Data can be stored for other minds to get at it. That doesn’t mean data can exist without mind — it took a mind to make the observation and record it. If all the minds in the universe were to die, then all the stored data in the universe would have no potential to inform. For practical purposes it would not be stored data anymore.
There are differences between event, data, and information. It’s meaningful to understand those differences. Now, you can have a machine that “instruments” events… it records mechanical response to events with no human intervention. It’s still not data until a mind observes it. Before a mind observes it, it’s an event. Just like a fossil is an event until it’s perceived by a mind.
And ok, the statement “to foo a bar, click foo” does have “content”. I was just trying to be funny by calling it content free (sheesh). But it adds no value. The data that is recorded in a button labeled FOO is equal to the data in that statement. So why state it? Human minds are able to record data, and they’re able to produce information. As technical writers, that’s our job — to produce information.
“You can have a machine that “instruments” events… it records mechanical response to events with no human intervention. It’s still not data until a mind observes it.”
Okay, but that is not how the term is commonly used. We commonly say that our instruments record data and that we later access the data. In that domain of discourse, the word “data” very clearly means the pattern of bits recorded in the machine, regardless of whether a mind has examined that data or not.
It is very common these days that data is recorded in massive amounts that no mind could ever process. It is processed by algorithms which produce some form of analysis. No mind ever sees the “data”, yet “data” is very clearly the term that we use.
So, the distinction you are making between event and data is not made in that domain.
Now this is not necessarily a contradiction of your point. My purpose in this essay was to point out that different words point to different stories in different domains of discourse. In the domain of instrumentation, the word data points to the mechanical recording of signals, not to the moment that those signals are observed by a mind. That is what it means in that domain, and to tell people who work in that domain that they are using it wrong would be silly.
But you may not be using the term in that domain of discourse. Even though you are talking about instruments recording signals, you may not be actually speaking in that domain, merely referring to it to make a point in the domain you are speaking in. In the domain you are speaking in, the distinction between an instrument recording a signal and a mind receiving that signal may be vital, and data may be the common and current word in that domain for the mind receiving that signal.
Or again, you could be making a new point, opening up a previously unexplored domain, or attempting to make a new distinction within an existing domain, and therefore proposing a change in vocabulary to support that distinction. (I do this in this blog with regard to the word “topic” — talking about Every Page is Page One topics is an attempt to inject a distinction I find important and not commonly made into the discourse of my domain.)
In either of these cases, though, my question would be, what is the domain of discourse, what is the value of this distinction in that domain, and why is “data” the right term in that domain? Just as the question of whether a tree falling in a forest making is sound is a problem only because we do not know what domain of discourse it belongs to, we may be a cross purposes here only because I haven’t grasped what domain of discourse your proposition belongs to.
Thanks for the comment, John
I’m not sure that I can discern the line between “data” and “information” in your comment, but it brings to mind a passage from Zen and the Art of Motorcycle Maintenance to the effect that no one knows where hypotheses come from.
You can rigorously compile data as much as you like, but it is not until you form a hypothesis and test it that you are doing science. But where do the hypotheses come from? They do not spring from that data spontaneously, as maggots were once thought to spring from rotting flesh. They occur when an observer, such as Kepler, sees a story in the data.
Leigh talks about how children bootstrap their stock of stories, which forms the basis for their understanding and use of language. The gift of seeing a story in a set of data must be something like that. Perhaps your existing set of stories prepares the mind to see an analogous story in the data, but still, there remains the gift of seeing a new story in the data.
There is something very fundamental about this drama which speaks to us just as the hero’s journey speaks to us. It is reenacted every week in every forensic show on TV (are there any other kinds of show on TV?) A miscellany of clues is assembled. Our hero sees a story in them. The team tests the story and finds a flaw. A new piece of evidence is found. Our hero sees a new story in it, and at 55 minutes to the hour the villain is caught. (This is every episode of Castle ever.)
G.K. Chesterton had a short story called The Honour of Israel Gow that explores how we can see utterly convincing stories in a collection of data which turn out to be completely wrong. The story is not there in the data announcing itself to us. We are creating the story to fit the data, which is why we must then test each hypothesis rigorously.
So the new information that makes predictions possible is not more data, it is a story that fits the facts and that predicts future data based on the logic of the story.
Interpretation of data is a whole ‘nother topic, so I won’t touch the Chesterton aspect.
Barry Devlin said that data is digitally enhanced information. If we extend that concept to technology, my understanding is that data is technically enhanced information.
To make a more complete, and I believe more useful, model when we put natural information in the driver’s seat, and assign data the role of storage of natural information at the same time it is the source of new insights, things begin to make way more sense.
For example: Is it easier to study the patterns of the universe when the information is standing still (as data) or in their natural, dynamic phase?
Another way to look at it: If the information about the movement of the planets was not recorded, what are the odds that Kepler’s insights would have come to fruition?
I have to presume Devlin was making a local definition for a particular purpose. I have not idea what his definition would mean in the general case, and it would certainly run contrary to common usage. Data does not have to be digital at all.
It seems pretty clear that Kepler’s insights depended on recording the data. But we should note that recording the data was not new, and nor was making up stories with predictive power — the Ptolemaic theory of epicycles did that, and was compatible with current stories about the perfection of the heavens, and the perfection of circles.
The problem with epicycles was that as more precise data accumulated, the epicycle story was shown to be not quite accurate in its predictions. So, the data was driving the need for a new story, but to get there Kepler needed not only to come up with a new story to explain the data, but to overcome the whole stack of stories about the nature of the cosmos on which the epicycle story was built (a Greek, not Christian story, BTW). https://en.wikipedia.org/wiki/Deferent_and_epicycle
Mark – You’re kind of making my points for me…
I think Barry would agree that digital is a bit limiting but he was telling his own story, For me the inclusion of any technology that ‘slows information down’ is sufficient to turn it into data.
Putting information ‘in front of’ data does indeed run contrary to common usage, but it also opens up a very tidy way of explaining, for example, how to incorporate all of the ‘understandings’ of the words “information” and “data”, something I believe your story-telling metaphor is also aiming at.
I’ve worked with a lot of technical writers and it is relatively easy to point out that what they are trying to do is bridge a user’s understanding of reality with what one or more application developers, for example, have done with it. When they become aware of the difference between the flow of information a user has access to and the relatively static interpretation delivered by code and its data structures, the bridges become easier to build.
Coincidentally, this (previously unresolved difference between information flow and structure) is what typically puts the DITA wonks and practitioners in a tizzy. But that is for yet another day.
Well, I’m glad if I am helping you make your point, but I’m afraid I still can’t figure out what it is.
The problem may lie here: storytelling is not a metaphor. I am not saying communication is like storytelling. I am saying it is storytelling.
You say, “how to incorporate all of the ‘understandings’ of the words “information” and “data””, but I can’t imagine why you would want to do that. Words have different connotations and denotations that are used to tell different stories. There is not necessarily any connection between those denotations other than that the same word invokes them, or else the connections are merely analogical (If I “milk” you for information, for instance.) Trying to incorporate all of them is pointless.
The worry about the relationship between information and data seems rooted in a tacit view what words are somehow real things that can be understood in their own right and that understanding words somehow conveys reliable information about the real world. This is not so. We use a very small group of words to talk about a very big and complex universe. There are not nearly enough words to assign one to every phenomena and every movement in that universe. So we use stories — juxtaposing our small collection of words in new ways to express new ideas, mostly by invoking other stories. The methods is brilliantly economical and flexible, but also lamentably prone to misunderstanding when people do not know all the same stories. But it is all we have.
There is no relationship between “data” and “information” as abstract terms. There are specific relationships between certain data points and certain stories, and the way people understand certain stories, and the terms “data” and “information” may be locally useful in telling stories about those relationships. But those stories are not universal, and so the relationship between “data” and “information” is not universal, and it is a category error to think that this is a problem that needs solving.
But yes, on the DITA wonks, information flow, and structure, I agree. Or at least, I agree with the story that these words produce in my head — I’m not certain if it is the story that you intended. Readers follow the relationships between stories, some of which are inherent in the story and some of which arise because of the reader’s background and circumstances. (It an author is telling stories about the real world, it is not reasonable to expect them to know all the stories that could be told about the real world objects they are talking about. Readers will connect your stories in ways you cannot anticipate and may not even understand.)
Categorizing stories does not express these relationships. Categories and taxonomies are a poor way, at best, for readers to follow these relationships. Search, linking, and social media provide superior navigation, but even they cannot anticipate all story relationships which may come to matter to a reader.
Stories cannot be reduced to data, if only because data only makes sense in terms of the story behind it (which is why a database has to have a data dictionary to be meaningful.)
Let’s say for simplicity’s sake that we are talking about technical writing and not broader “reality”. Yours is a techcomm world, correct?
There is information (signals and symbols if you will) out ‘things in the real world’ that a client wants to capture and manipulate in an application. Let’s limit our domain to socks: things people wear between their feet and their shoes.
The client documents his requirements and asks a developer to build him an app that will make it easier to find the socks he wants to wear, independent of location.
The developer builds a slick, graphics-based application using faceted classification and refiners.
Here’s how I see the task of the tech-comm person documenting the app. There are three related domains and they all treat information / data differently:
The user in the real world has socks in the real world and has experience with how they are stored and (via his requirements) how he would like to find them.
The application developer (who does not wear socks) has a pretty good idea about how to make the ‘sock finding experience’ better.
3, The technical communicator who, as a go-between (who does wear socks) is responsible for cataloguing all of the visible components of the app; the expected behaviour of the app and how the user should optimally interface with it.
A few ground rules: His feet are real; his socks are real; the drawer(s) in which he stores his socks is/are also real, and he can locate real socks there.
There is very little ambiguity in this application: The user understands that, per his requirements. he will be able to search for socks via the following criteria: colour, material, purpose, shape and pattern. Currently, using a rudimentary filing system, he can ‘navigate’ to the location of most of his socks but, since he has 2,200 pairs of socks, he wants to improve his chances of success.
The information this person has in his head is about to be codified on two levels:
~ The developer is going to create a technically enhanced rendition of reality in the form of an application that holds a visual navigation field (the UI); a data-store and methods for going back and forth between the two.
~ The technical writer is also going to create a technically enhanced rendition of reality, in the form of content, that essentially answers three questions about what the developer has delivered:
What is this thing? (in the interface)
What does this thing in the interface do for me? (in the code)
How do I perform a task in the interface?
The user already has information about his socks. The application captures that information as data and gives the user a method for accessing that data. Once outside the application the data becomes information again so the user can make a real choice in the real world. The story told by the technical communicator is a means to an end: connect the digital reality to the real one and vice versa.
BTW: If the occupation of the person using the application is a ‘sock analyst’ they could likely take all of the original information, now stored as data, and do some clever analysis (i.e. turn the data into information again) about sock picks, sock favourites and stochastic patterns in the Argyll market.
Sorry, John, but this just strikes me as word games.
Yes, programmers call their subject matter “data” and writers call their subject matter “information”. That does not mean that it changes into something different as it passes from one domain to another, it just means that people in different domains use different names for the same thing.
The reason they use different names for the same things is that they tell different stories about that thing and are interested in it in different ways. This is fundamentally were the whole taxonomic enterprise breaks down. It can’t accept that data and information are just words the people in different domain use to describe data/information on the location of socks. Either there is one thing and it must have one name, or there are two names and therefore there must be two things.
That is not how language works. Language is stories, and words don’t mean anything except in the context of the particular story in which they occur.
And as far as this goes:
“The technical communicator who, as a go-between (who does wear socks) is responsible for cataloguing all of the visible components of the app; the expected behaviour of the app and how the user should optimally interface with it.”
No, the technical communicator’s responsibility is to help the user make a connection between their business problem and the capabilities of the app. Cataloguing all of its visible components is almost never a useful way to do that.
“…words don’t mean anything except in the context of the particular story in which they occur.”
Sorry we are so far apart here, Mark.
Declaration of meaning is a big part of all three domains. The fact that story-tellers ‘cheat’ and assume that context will successfully declare the meaning of a single word is unimportant.
As for your last comment, it’s interesting that you chose to focus on the catalogue. I agree that by itself an inventory of UI components is not very useful, but if a technical writer is going to refer to one of them, in a task for example, or a user wants to know: “What’s This” then a catalogue comes in kind of handy.
Users, with their business problems and application developers with their programmatic solutions use two different dialects to manipulate concepts. I would have thought that the job of connecting them would fall to a technical writer, but I’ve been wrong before.
Indeed, I am sorry too that we seem to be so far apart.
“Declaration of meaning is a big part of all three domains. The fact that story-tellers ‘cheat’ and assume that context will successfully declare the meaning of a single word is unimportant.”
It is neither a cheat nor an assumption. It is how language works.
When you define a word, you do so by telling a story and associating that word with that story. But there are far more stories in the world than there are words, so every word has multiple stories attached to it. Sometimes the differences between those stories are subtle — so subtle, in fact, that you can’t tell the difference in conversation. You can only tell that the stories are different when you see them result in different actions.
Even the stories you tell to define words in a taxonomy depend on the sub-stories that the words you use evoke in the minds of those who study the taxonomy, and those will differ from person to person. People within a domain share far more stories in common, and have had their interpretation of stories refined and unified by shared experience.
Between domains, no such similarity exists. You can’t bridge between domains with shared taxonomies, therefore, because people in different domains will understand the underlying stories in different ways. More profoundly, people in different domains will generally find the definitions and distinctions made in the taxonomy of one domain inappropriate to the stories they need to tell to get their work done in their domain.
In short, you can only define words unambiguously for people who already use them in exactly the same way. You can unite disparate terms, but only if the two terms are already being used in exactly the same way. (In practice, this is almost never the case, though the differences are often not obvious until later.)
Precision in communication does not come through shared definitions but through shared experience and shared stories. This is where the limits of taxonomy lie. They can map terminology to share experience and shared stories where they already exist. They cannot create shared meaning where share experience and shared stories don’t exist. The only thing that can bridge that gap is sharing experience and sharing stories.
“Users, with their business problems and application developers with their programmatic solutions use two different dialects to manipulate concepts. I would have thought that the job of connecting them would fall to a technical writer, but I’ve been wrong before.”
The fallacy of here is the idea that they need to be connected at all. Users do not need to be connected to the application developers. They need to use application to solve business problems. You don’t need to be connected to automotive engineers to drive your car to the mall, and you don’t need to be connected to software engineers to check your timeline on facebook. I saw a survey recently that claimed that most people don’t know what a browser is — even though they use one every day. Good tech builds interfaces that hide what goes on behind the scenes. Indeed, our whole technology stack, which is now far too complex for any one person to understand, depends entirely on this principle.
The role of tech comm is not to explain the developers to the users. Their role is to connect the user’s business problem to the features of the machine.
Well put. I surrender.
Oh Dear. I hoped we might get closer to understanding the stories we were trying to tell each other. But perhaps this is not the ripe moment for crossing that gap. Another time, perhaps.
A couple of characters didn’t make the post…
“…(signals and symbols if you will) about ‘things in the real world…”
and the first two numbers before point #3
Mark, one thing came to my mind this morning still thinking about your blog post: Remember how programmers call their descriptions of “what a user does or needs to do” in agile software development? User stories! (http://en.wikipedia.org/wiki/User_story) So the story term has long found its way into technical communication. While software developers are using stories to get an idea of what has to be coded beforehand, our job as technical writers is to de-code and re-write the stories that are now manifested in the applications after development has been done.