Note: This file has moved to notablog.

Writing or Dialogue? In a mailing list discussion Elna Tymes wrote: > It is my belief that what we call technical writing today will > become a relic as we move toward other forms of communication, > probably involving networks and possibly involving more direct > information transfer. At all points along that way, however, there > will be a real need for the 'translators' which technical writers > are - translating technical concepts into material that mere mortals > can come to understand. This raises an interesting thought which I've thunk in the past (and revisited just yesterday, which is why I'm posting this message). Hearkening back to the Railroad companies which went bankrupt because they didn't realize they were in the freight transportation business, not in the railroad business, what we do as technical writers is essentially take a body of information and make it accessible to others by a) writing it in english and b) putting it in structured form. As such, one fundamental part of our job is learning about new topics; yet another is questioning our own assumptions and trying to think from our users' point of view; finally the last is building an informational struture (usually static and printed, more and more these days interactive and electronic). Leave aside the first two parts, I've often wondered, lately, about profoundly new ways of building an informational structure to convey knowledge. Perhaps the future, in some ways, is going back to the past, building storytellers instead of books. In a certain sense, a technical document is designed to be used non-linearly. To a certain extent you could consider this a dialogue. What other forms might the dialogue take? I'll never lose my love of the english language, and passive/static information will always play a role in technical communication, but nor will I allow my love of writing to blind me to better ways to inform and educate people. The idea that's been kicking around in my head lately has been about oral culture vs. printed culture, and what will be the next generation? (not fiction). Technical books are usually designed so you don't have to read them from front to back. The technical writer expects that the reader will have opened the box, tossed the book in a corner, installed the software and ignored the book until he got stuck. When he does get stuck, he won't start reading from page one until he figures it out. He'll *maybe* skim the first chapter to get a guess at where he'll find the part he's stuck on, then flip to that section, skim it, read it if it seems to apply, check the index if that doesn't work. When he gets to something that seems to have something to do with his problem, he'll read. The writer expected this and tried to design the book so each part stands on its own, but includes references back and forward to sections that deal with related topics. The reader may or may not follow these references, depending on how much he thinks he knows, or how much they seem to have to do with what he's stuck on. He may stumble over a term or concept, then check the index or table of contents for it. In relationship to the book as a whole, the reader is really more interacting with the book than reading. The process of creating the book is much more about designing the structure about it. Writing the words is still a bit part of it, but it's arguable which is most important. The whole process is much more like a dialogue than like reading a novel. What other forms might the dialogue take? Might we, in a sense, return to the oral culture, building a "document" that is in essence a storyteller? Today the cool thing to do in technical writing circles is interactive help systems. These have existed for decades. In form, the web is basically a fairly simple version of an interactive help system, that then got a bunch of bells and whistles glommed on (when some business types decided the web could be as big as TV; online help makes a ton of sense from a business perspective, too, much cheaper and faster to manufacture and ship than books). Most every interactive help system isn't worth a damn, however. Why? Partially because of simple physical aspects; a book at least has some linearity that our minds can latch onto, by virtue of how it's built, one page after another. Interactive help systems don't. The screen you're reading off of is about 25% to 50% more tiring to read off of than paper. The help system has to share the screen with the software. Most of the time the help system is written after the book, often by simply cutting up the book into chunks and putting links to go from one chunk to another. In theory the interactive help system has the advantage that, unlike the book, it can actually *do* things. It's truly interactive. But the fact of the matter is that the text itself is still static; it's chunks, paragraph sized or page sized, but not in itself dynamic and changing to adapt to the situation. Maybe the future is in another direction. Before we had books, we had oral culture, where all information was transmitted in a dialogue from one person to another. The experience of reading the printed word is inherently and fundamentally different than the experience of a dialogue. The printed word is not time-bound; you can see and hold more of it in your mind at once than you can the spoken word, and you can effortlessly rewind and fast-forward at least a little bit. It's also almost always more carefully composed and yet at the same time more structurally complex than the spoken word. The spoken word is most often strings of somewhat connected phrases. The printed word has far more power to lead; but the dialogue has far more power to explore. Technology to understand language - not merely to recognize a spoken word but, once having turned the sound into letters and words, to truly understand it and manipulate it - is called "Natural Language Parsing" technology. Natural as in spoken naturally, not as a set of command keywords. Parsing is the technical term for what you do when you sort out the sounds in your head and come up with meaning. Natural Language Parsing technology to date is fairly impressive; although it can't carry on a conversation with a random human. The main stumbling block is context - keep track of what you're talking about and how that alters the meaning of what you say. Even humans lose track of this quite often, and unstructured conversation meanders and hops from one context to another so quickly that it's no surprise a computer can't figure it out. But we're talking about writing, not about building a fake conversationalist. If we limit the context, the technology starts to look a lot more feasible. Imagine a "book" - electronic, of course - that is able to converse with you about a limited topic. This might be a far more powerful way to convey technical information - about any domain, not just computers and software. In an even more limited range, I've programmed some fairly simple, abbreviated interactive help systems for online chat systems. Not truly natural-language parsers, but more on the lines of responding to a narrow list of predictably phrased requests for help. I've done it, and I know that I personally have only barely scratched the surface of the technology. What might be achieved with more sophisticated technology? What would it be like I wonder, as a writer, to spend my days building a storyteller instead of a book? From another tack, consider an Expert System. Expert Systems were all the rage back in the eighties. An expert system is essentially a way to take all of the many judgements and decisions required for a particular task and write them down, and automate them. They now have fairly impressive medical expert systems that can, for example, diagnose a patient pretty accurately by asking questions. "Pretty accurately", huh? Not exactly the phrase you want to hear from your doctor. What they found when they started trying to actually replace people with expert systems is that they weren't really as effective as a real expert was, at complex tasks. People are much more powerful expert systems than anything we've come up with so far. What the expert system was good for, however, was to train a beginner. By using the expert system, the beginner essentially got to apprentice to a mediocre-but-competent expert. People could learn the fundamentals much more quickly, in something more like a one-on-one teacher-student environment, then surpass the expert system. Where am I going with this? I don't know yet. So far I only have enough to start wondering, and asking questions.