TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
There's no way that you can say tech writing is obsolete once the GUI is self-explanatory. And no, we don't get relegated to only APIs and repair manuals for under the hood. The one thing that's so often missing from a tech doc piece is the *meaning* of the technology. What does this field *mean*? Don't tell me, "To foo a bar choose the bar in the bar dropdown list and click foo." This is the kind of tech doc that is obsolete. Actually, in this day and age it's an embarrassment, but it's still out there, and there are still people who produce it. I want to know what FOO and BAR actually mean, how a BAR interacts with a BAZ, when and why I should FOO it, and so on.
In other words, tech doc is finally in a position to discuss the *application* of technology, not just how to grasp the knobs and dials. There's a big question here... Is *application* of technology procedural? Some people give a definite YES. Fair enough, but be careful of the Procedural Doc mantra, because it often devolves into "To foo a bar..."
I personally think the Procedural Doc mantra is a dead fish. I look at it like this... Product interfaces are more like languages than lists of procedures. That was the whole point of GUI -- instead of providing a catalog of commands, provide a collection of nouns, verbs, and modifiers... let people combine these however they like. For example, deleting a word from a document... Select (verb) a word (noun) and delete (verb). Deleting a graphic is the same "procedure", but with a different noun. Should I document a separate DELETE procedure for every type of object in a document?
For the English language we have procedural documentation... It's called "English for Non-English Speaking Tourists". To ask for a bathroom, say "Do I have to buy something to use your bathroom?" Ok, so there's a place for this kind of documentation in tech doc, but it's for rank beginners. As we become fluent with a language, we need to learn about its grammar. This is the stuff we're now free to document!
There's plenty of use for this level of documentation. I also believe we're on a "mashup" threshold. The idea of a "product" is changing. What do you think is the big deal with all that API work out there? People are making services and exposing them. The "product" is becoming a licensed client view into a collection of services. In other words, we're entering an era of combinations of combinations of technologies within a "product". That makes grammar all the more important.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help: new website, content widgets, and an output that works on any screen.
