You can’t get more deadpan than the brilliant observational comedian Steven Wright, who is imagining the ultimate ad to sell strings. Strings are as commonplace as cellphones these days. In addition to the plain old strings Wright describes, you can have:
- stringed instruments
- pearls on a string
- a string of islands
- drawstrings
- a string of ideas
- string beans
You can pull strings, be strung out, string a person along, be second string, string lights, and keep someone on a string. When it comes to describing this particular object, there’s simply no strings attached.
The Mother of All Stings
Leave it to theoretical physicists to make something as simple as a string the foundation of one of the most complex and fascinating scientific theories ever imagined: string theory.
String theory proposes that everything in the universe is made up of tiny, vibrating strings of energy. The way the strings vibrate determines the type of particle formed. In this theory, strings make up quarks, which in turn comprise electrons, protons and neutrons, which make up atoms and finally molecules.
If string theory could ever be proven, it would literally be the answer to the universe. That’s because string theory is a unified theory, a theory that unites the study of the very, very small (quantum mechanics) with the very, very large (general relativity). It would explain how all matter behaves, from the components of atoms, all the way up to planets and galaxies. That’s why a unified theory is also called a theory of everything.
My, What Small Strings You Have
The problem is that it may be impossible to prove string theory. The strings would have to be unimaginably small: a string would be to a hydrogen atom what a small tree is to the solar system. If strings exist, their tiny size would make them unable to be detected directly. Also, for the math in string theory to work, the strings have to exist in eleven dimensions. (I have enough trouble with multiple text conditions.)
What’s really fascinating, though, is the idea that by determining the basic building blocks of the universe, we can solve the mystery of the universe. Now, if we could identify the basic buildings blocks of technical communication, it could be a unified theory for our profession.
I Object
Initially, it would be tempting to identify the basic tech comm objects as the actual language or visual constructs used when communicating, for example:
- letters, numbers and symbols or
- words and pictures or
- nouns, verbs and objects or
- overviews and tasks
While it’s true these elements are all used to assemble documentation, realizing this doesn’t bring us any closer to exactly what technical communication is or does. In fact, taking things to their logical conclusion, all communication is made up of ink or pixels, but this doesn’t explain anything.
We need to ask: what is the true purpose of technical communication, and what does it actually mean to achieve this purpose?
Tech Writing On Purpose
The purpose of technical communication is to give users the information they need to understand concepts and complete tasks. That is, all technical communication is made up of two basic components:
- conceptual explanations or overviews
- procedural explanations or procedures
These are the two types of technical communication to be unified, just as string theory attempts to unify the small and large. We need to identify the common elements in each type, and then see if they can be synergized.
Let’s start with overviews. To have a user understand a concept, we need to explain that concept to them, and wherever possible, show a real-world example. (An example would be appropriate here.) For example, to explain what character formatting is, you could show examples of bold, italic and underlined text.
For procedures, we need to tell users what the procedure does, any prerequisites, why a user would (or would not) perform the task, and what the end result is.
Elementary, My Dear Reader
So what are the elements in a procedure? In a procedure, a user performs an action on an object, with some specific result. We could therefore list the elements as:
[user] [action] [object] [result]
So, for example, when a user updates a file:
- the action is the process of updating the file
- the object is the file
- the result is an updated file
Let’s keep this mind for now and look at overviews. In a conceptual overview, a user reads an explanation of a concept and then, we hope, comes to understand that concept. We could therefore list the elements of a conceptual overview as:
[user] [concept] [understanding]
For example, a user reads an explanation of a database, and then comes to an understanding of what a database is and why they would use or create one.
All Together Now
Bring these two list of elements together, we get:
Procedures: [user] [action] [object] [result]
Overviews: [user] [concept] [understanding]
We can remove [user] from both lists. The user is the receiver of the document, but is not actually part of the document.
We now have:
Procedures: [action] [object] [result]
Concepts: [concept] [understanding]
[action] can be replaced with the more general . When you define an action or step, you are really creating an explanation for that step.
[understanding] can also be replaced with . The user understands, but the document explains.
We now have:
Procedures: [object] [result]
Concepts: [concept]
[result] could be more generically referred to as [state]. That is, in a procedure, an object moves from one state to another: a field is completed, a record is updated, a document is printed, and so on.
[concept] can also be generally referred to as an [object]. Although concepts can cover tangible items such as files, fields, and records, they can also apply to actions such as printing, saving, and copying. The action becomes of the object of the explanation. So whether you are describing a thing or non-thing, that item becomes the very object you are trying to explain.
We now have:
Procedures: [object] [state]
Concepts: [object]
At this point, it would be tempting just to simply remove [state], thereby making both lists of elements identical, and solve this puzzle. However, [state] is such an important aspect of documentation we cannot eliminate it. Instead, let’s see if there’s a way to add [state] to concepts.
State of Grace
What happens when a user understands a concept? The user moves from being in a state of ignorance to a state of awareness. However, we’ve already said that the user is not actually part of the documentation, only the object is. From the object’s point of view, it moves from being in an unknown state to a known state. That is what an effective conceptual overview must do.
We can therefore add [state] to concepts and derive the solution:
Procedures: [object] [state]
Concepts: [object] [state]
That is, all documentation consists of these three basic elements in various forms:
[explanations] [objects] [states]
Does this have any practical application? Well, it can serve as a high-level checklist of whether a topic has been effectively written.
Specifically, if a topic does not clearly:
- identify and define an object
- offer a clear explanation of the concept or task
- indicate the change in state of the object (for a task) or actually change the state of the object from unknown to known (for an overview)
then the topic has failed.
Andrew Brooke 
I admire your reasoning and your conclusion.
Your facility with logic makes me suspect that you may have had exposure to a Jesuit educational institution or textbooks. I attended parochial schools taught by nuns, but used Jesuit-written texbooks.
Today's texbooks are big on whitespace, pictures, size and weight, low on content, especially anything controversial, and very low on reasoning and logic. Minimalist documentation in the worst sense.
Thanks for your comments Margaret!
Your suspicions are fairly accurate. I have and continue to study not Jesuit but Jewish philosophical and meta-physical texts.
My main focus is on Kabbalah, another area with its own “theory of everything”.