Re:terminology question (and a bit of a rant)

Subject: Re:terminology question (and a bit of a rant)
From: "Anameier, Christine A - Eagan, MN" <CANAMEIE -at- email -dot- usps -dot- gov>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 3 Sep 2002 14:41:00 -0400


> </rant>
> Right. So what this has prompted me to do is start a
> style guide for online help.

Hi Rosemary,

Sounds like a frustrating situation all right. For what it's worth, your
terminology sounds fine. I think "screen" is a vestige from pre-Windows days
and I avoid using it. Sounds to me like your instincts on terminology and style
are right on target.

I don't think a style guide is the answer to your problem, though. If you hand
IT a style guide, you're implicitly giving them permission to (re)write
documentation, which is *your* job.

I think if I were you I'd take a "let's clarify IT's role in the documentation
process" approach.

(1) Set good precedents through diplomacy. Find ways to establish, gently, that
you are the writing expert. If a stylistic issue alarms them, they can trust you
to do the right thing. They don't need to waste their time parsing your grammar.
This is a tricky, delicate thing--you want the message to be "relax, I'll take
care of the grammar," not "you can't write your way out of a wet paper bag!"
Maybe they'll balk. People who take the time to rewrite your stuff in passive
voice with loads of extra words are usually pretty dogged about what they want,
or else they wouldn't bother. In that case...

(2) Accommodate them with compromises that you can live with. Sometimes they
make changes to fix a perceived problem and they bash around breaking things in
the process. You'll never know what they're REALLY trying to do unless you grill
them. Once you find out, you may be able to offer a different solution that
everybody's happy with. (If the perceived problem is just "but it sounds so...
informal!" then you get to discuss why stiff, dense, verbose writing can be
counterproductive in user docs.) Failing that...

(3) Go the organizational route: an SOP or written policy or a memo from your
manager to theirs. Maybe you can get some kind of policy instituted that
designates IT people as SMEs and technical reviewers who are NOT to edit for
anything except technical accuracy, in which case they would provide info and
you would make the edits. Tread carefully. They'll probably resent it unless you
can convince them you're doing them a favor (and presumably you tried that
without success in option #1 above).

YMMV... a lot depends on the personalities you're dealing with, as well as the
organizational culture. Good luck.

Christine


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l

Absolutely FREE! FrameMaker/Win 6 & 7 Express Customization (v3):
Quick-access buttons & keys to common functions, char tag/font drop-down
lists, charset browser, QRef guides & much more: http://www.microtype.com/2

---
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.



Previous by Author: Documenting field descriptions in printed documentation
Next by Author: RE: terminology question (and a bit of a rant)
Previous by Thread: Re: terminology question (and a bit of a rant)
Next by Thread: RE: terminology question (and a bit of a rant)


What this post helpful? Share it with friends and colleagues:


Sponsored Ads