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.
>"Please arrange a session ASAP for both programmers and QC
> about abbreviating, capitalizing, punctuation, and the sort."
And after that, will the programmers arrange a session for you and QC
about programming? </irony>
First, consider what audience the programmers and QC are writing for.
* If the programmers and QC are writing things and their audience is
just you (or each other), it's important that they be able to convey
necessary information *accurately* -- but they should not be required to
convey it with flawless capitalization, punctuation, and so on.
* If they're writing things for an external audience (end users, for
instance)... they shouldn't be. That's what tech writers are for. If
they're making mistakes in interface text, arrange to (1) review the
requirements document that specifies the text in the interface and then
(2) proofread the interface when it's ready.
> . . . neither the developers or the QC officers will ever listen.. and
I will
> be going through the same mistakes in interface and demo data..
You can correct those mistakes a lot more efficiently than they can. Try
to be patient with them. If you're getting the opportunity to catch the
mistakes and have them fixed, that's a good thing.
In my experience, my subject matter experts have been support people,
not programmers, but the concept is the same. I don't want them
agonizing over punctuation, capitalization, grammar, or page layout.
It's a much more efficient use of their time to have them give me a
rough document, especially since I'm going to rebuild it from start to
finish (or use it only for my own information) even if they *do*
struggle to make it grammatically perfect. If it's interface text, all I
want is a chance to review the interface early enough that we can fix
the mistakes.
Christine
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.
Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
