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: issues in communication From:Scott Miller <smiller -at- CORP -dot- PORTAL -dot- COM> Date:Fri, 31 Oct 1997 09:27:27 -0800
Issues and some things that can help:
1. Getting information from developers.
- Batch your questions. Instead of asking one question every hour,
save them up and ask them 20 questions every week or so.
- Know how each developer wants to deal with questions. Ask them if
they can be interrupted, or if they like to schedule appointments.
- For major issues, bring them up in team meetings.
2. Getting docs reviewed.
- Schedule a review meeting, so reviewers have to be prepared.
- Make the review draft extremely readable. For online help, print
the help from the help viewer, not from the doc, so the reviewers don't
have to deal with all the ugly hyperlinks, bitmap references, etc.
- Limit the focus of the draft. Don't bother reviewing the
absolutely obvious information, if there is any. Call out areas that you
know are questionable.
3. Getting context-sensitive help hooked up.
- Be extremely clear about which topic gets hooked up where. If
necessary, create a document with a screenshot of each dialog box, and
the help topic that applies to it. At the very least, create a
spreadsheet with the contexts, the topics, their ID numbers, and ID
- Log context-sensitive help bugs often and early. Be responsible
for the troubleshooting.
smiller -at- portal -dot- com
>I'm a graduate student in tech. comm. conducting research on the
>communication problems tech writers often face when dealing with product
>developers, project managers, and so on. I'm currently trying to get
>information about how these problems typically manifest themselves, how
>we might prevent them from arising, and how we might alleviate them once
>they do arise. Of particular interest to me is hearing about solutions
>people have come up with when faced with such problems.