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.
On 10/23/1998 12:44 AM, Ben Kovitz (apteryx -at- CHISP -dot- NET) wrote:
>An easy way to clean up bloated,
>boring manuals that no one wants to read is to go in and carve
>out the metatext. I think it's almost always a cop-out, more an
>attempt to "look busy" than to say something useful to a reader.
Well, as with many discussions on this list, I agree and disagree...
I agree that empty, filler statements are Bad Things, wherever they
appear (pop-up help, section intros, and so on).
However, my experience in training (strictly self-taught, so anybody with
formal training training -- duplicate intended -- should jump in to
correct me) is that people respond well to a structure like this:
**Creating a Customer Account**
(Here's what we're going to do:) This section describes how to set up a
customer account, including the customer's contact information,
purchasing preferences, and favorite colors. Once the account is set up,
you can use it to sell the customer many expensive prodoucts.
(Here's how to do it:) Step 1: Enter the name... etc.
(Here's what we did:) The customer account is now complete. You can now
use it here, here, or there. For more information, see these other places.
That pattern (what we're about to do, how to do it, what we just did) has
always served me well in classes as a way to reinforce the message. Of
course, I dump that structure where it doesn't apply or will be too
cumbersome, but it's a good guideline. I've also used it many times in
writing manuals and tutorials, with positive results.
So my question/point is, doesn't "metadiscourse," if used properly, serve
this "bracketing" purpose to help the message get through?
----->Mike
____________________________________________________________
Internet: stockman -at- jagunet -dot- com AOL: MStockman