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: Documenting Windows Functions From:Daniel P Read <danielread -at- JUNO -dot- COM> Date:Mon, 16 Dec 1996 10:12:32 EST
>>The product is targeted for a specialized, professional market, and it
is expected
>>that users will already be comfortable with Windows software. This
>>being the case, should I document the standard Windows editing
>>functions, or is it reasonable to assume that they will be
>>understood?
I don't know what the "official" line on this would be, but my feeling is
that a cursory explanation of the Windows editing functions would be in
order. If this were a programming language or some other type of
development tool, I would say that you would not need to worry about
documenting these, but anything less, I would say do it. Part of my
reasoning here is that the Windows editing functions are relatively
simple concepts and explaining them would not add much fat to your
documentation. If you're doing a Winhelp file, I would put the
explanations outside of the normal flow of the help file so that users
who need to know how they work can get to the instructions, but your
average user (who you say is already Windows-savvy) won't be bothered by
them.
But this brings up the question of where to draw the line. Do you go as
far as explaining the basic concepts of clicking with a mouse and sizing
windows? I think not in this case. This is where the instinct of the
individual writer (and his familiarity with his audience) must take over.
Take care,
Daniel Read
danielread -at- juno -dot- com