Proactive Tech Comm

Traditionally tech comm ended when the product was released to manufacturing. We are slowly moving away from that outdated approach and towards an approach that supports the product throughout it life cycle, especially through forums and other social media.

But even when we do this, the pattern tends to be reactive. We wait for a customer to ask a question and then we answer it. But I received something in my email today that takes it one step further. It answered a question before it was asked. It was proactive tech comm. read more

Desert Island Docs

There is a long-running radio program on the BBC called Desert Island Discs that asks celebrities what recordings they would take with them if they were going to be stranded on a desert island. Today, the question does not make as much practical sense as when it was first broadcast in 1942. As long as the desert island had Wi-Fi, modern castaways would not have to make their choices before they leave, they could just listen to Pandora. (If the island has power for a record player, we can presume it also has Wi-Fi.) read more

The Place of the Book in an EPPO World

What is the role of the book in an Every Page is Page One world? The question is pertinent because I have just signed a contract with XML Press to write a book on Every Page is Page One.

Yes, I get the irony. But Every Page is Page One is not a statement about the universe. It is a statement about the Web, and about online systems that behave (or that users expect will behave) like the Web. On the Web, Every Page is Page One. The Web is, or is rapidly becoming, the dominant form of information exchange today, which means it shapes peoples habits and expectations for all media. But it is not the only form of information exchange, and it never will be. read more

Tech Comm’s Obsession with Novices has to Stop

Novice and Expert keys

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Once upon a time (sometime in the 80’s) everyone in the tech business was a novice. Novice tech writers wrote for novice users about novice products created by novice developers employed by novice entrepreneurs (most of whom, apparently, had recently dropped out of Harvard).

There were no conventions about how any of this stuff was supposed to work. No one even knew what the business model was for software, let alone what the standard conventions should be for how anything should work in software or in hardware. As the popular saying of the time went, if it isn’t documented, it isn’t a feature. read more

The Real Docs Need is Decision Support

One of the most important tools of modern business is the decision support system. Such systems can be complex and even exotic, but at its heart, a decision support system is simply a system that provides people with the information they need to make decisions.

Clicking an Add as Friend button

The question that matters to users is not usually how to press the button, but what will happen if they do press it, and whether they should press it or not. The real task problems users have are usually with decisions, not operations.
Image courtesy of Master isolated images / FreeDigitalPhotos.net

In tech comm, we don’t talk much about decision support. We talk about task support. We frame our jobs as providing the information people need to complete their tasks. Unfortunately, what we often provide by way of task support are simply procedures for operating machines. But, as I have argued before, a task is not a procedure. In many cases, the support people need to complete their tasks is not information on how to operate machines, but information to support their decision making. Its not “how do I push the button,” but “when and why should I push the button and what happens if I do.” read more

The Long Tail and Why Docs are Frustrating

It is often a matter of some perplexity to technical writers that more and more people seem to prefer searching the Web rather than looking for information in the documentation. It is perplexing because information found through a Web search is of variable quality, sometimes hard to navigate, lacking in authority, and has to be picked out of a big pile of fluff.

Why would people prefer to search the sprawling mess that is the Web when they could look in the neat, authoritative, well organized documentation set? Shouldn’t they, at least, look in the docs first before turning to the Web? read more

Why EPPO and the Web are the Right Fit for Tech Comm

While most of tech comm has moved to digital media — either to the web or to the product media — tech comm information design practices have been far slower to change. A large part of the tech comm world is still writing and delivering books, even if they deliver them as PDF or burst them into hierarchically  linked help topics. This is a carry over from the design constraints of the paper world, and we need to move away from it.

Two of the key factors determining publishing strategy are the size and the time-frame of the content. Content may be large or small, and it may be topical (of immediate short term interest) or durable (of long term interest). In the paper world, different publishing and binding models fit different quadrants: read more

Differential Content Strategy

Traditionally, the content strategy for technical communications has tended to be undifferentiated. That is, organizations would define the components of a doc set: user guide, admin guide, quick reference card, reference, etc, and would produce that same set of documents for every product and every product release from 1.0 to the very last release before the product was finally put out to pasture.

This undifferentiated strategy was based on a expectation about the role of documentation in a product — an expectation shared by both customer and vendor. But today, thanks to the Web, expectations have changed, and with frequent releases and squeezed margins, the cost of meeting the old expectation has become increasingly burdensome. As a result, more and more organizations are questioning the value of documentation, and the value of developing it in-house  as opposed to outsourcing or off-shoring it. read more