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.
Subject:Re: Documentation is not as important anymore? From:Pam Tatge <pamt -at- STEINBECK -dot- SC -dot- TI -dot- COM> Date:Mon, 2 May 1994 11:55:18 CDT
I appreciated Anatole's post about this article. It rings true with
other things I've heard and read lately.
It's becoming increasingly common for companies to require payment for
support, as Chuck Banks noted, although it can cost thousands of dollars
per year, rather than hundreds. Some companies are also switching their
hotlines over to 900 numbers. (We haven't done that, but our hotlines
aren't 800 numbers, either--the customers call on their own dimes.)
As a customer, I love products that are so intuitive that I don't need
to crack open the book. And when that's not possible, I love it when the
documentation is incorporated into the product. But, I don't think these
concepts apply well to the documentation that our group writes. (Yeah, I
know I started two sentences in a row with conjunctions--Beth, don't
give my number to Sister Marie Cecelia!)
The products that we write about sort-of-are and sort-of-aren't "other
than computers". We write about microprocessors, microcontrollers, and
related software-support products (assemblers, linkers, compilers, and
debugging tools). This is definitely "computer", but it's a different
perspective on "computer" than is usually discussed on this list. Our
audience is different, too, but I don't think they're any more inclined
to read than any other type of audience. (The SMEs that some of you
work with are my customers, probably.)
Except for putting power and ground in the expected positions, I don't
really know how we'd make a microprocessor intuitive. :) Except for the
debugging tools, our software doesn't have a user interface. We have to
search really hard for opportunities to make our information more
accessible. We drool over some of the projects that you other writers
discuss on this list--and we have to be careful that we here don't go
down some new path just because it's fun for us. We are finally working
on our first online project, and everything associated with it is a
big IF: If our customers don't read stuff on paper, will they read
stuff on a screen? If the documentation is online but the product isn't,
will customers read the documentation? Etcetera... (If you think we
should have asked those questions BEFORE going online, you're right. We
*did*--but we didn't get to ask customers--then. That's another story.)
Anyway, usually we have this big captive audience that *must* read our
documentation. They're not an end-user audience--in order to use our
products, they need a fairly specialized education. Although I
personally think that much of our documentation is abysmal, our
customers consistently rate it as better than our competitors'. (I keep
arguing that we don't know if our documentation meets our customers'
needs, or just their expectations.)
Almost every time I've been up to our DSP hotline room, I've seen an
engineer reading to a customer over the phone. This apparently happens
a lot...a customer calls, the answer is in the book, they pay someone on
our hotline to read aloud to them. You might think that the customers
would demand better indexes. They don't, but our hotline people do! I
think that customers sometimes just want help from another human being,
rather than from a book (in any form).
I guess what we really need is to include the documentation in the
chip's microcode, plug it into the port at the nape of the customer's
neck, and download the information into the customer's brain...and then
erase their memory of the hotline number. (There's way too much
involuntary Star Trek in my life.)
*** Pam Tatge, Member Group Technical Staff
*** Texas Instruments Semiconductor Group, Houston
*** pamt -at- steinbeck -dot- sc -dot- ti -dot- com