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.
>
> Amen, John. Amen.
>
> On Tue, Jun 29, 2010 at 5:04 PM, John Posada
> <jposada99 -at- gmail -dot- com> wrote:
> >> Wouldn't it be something if you could buy software that required
> >>little to no training, and caused little to no loss of productivity?
> >
> > You can.
> >
> > Hire experienced technical writers that don't require a learning
> > curve. What you are paying for with new software is not the
> CERTAINTY
> > of needing training...what you are paying for is that your EXISTING
> > writers cannot pick it up as soon as they pick it up.
> THAT'S the cost
> > of getting writers on the cheap.
> >
> > Bring in writers at a little higher money, with experience, and even
> > if the writer never saw the particular application, you will get
> > production in a very short time, maybw within hours.
>
HOWEVER... a writer who's never seen the particular tool
before will necessarily bring to it the approaches and
experience s/he's had with other tools.
So, there they are, 7 hours after arriving at your
company, dutifully cranking out their first page or
two of Help, as they did it with Doc2Help.
But they're using (say) Flare now, with no previous
experience and a [n apparently] frantic deadline to
provide some evidence of motion. (Gotta justify having
displaced [former?] in-house writer[s].) So they start.
Weeks later, it becomes apparent that there are some
problems due to having used pliers as though they
were a wrench. Considerable backtracking and fixing
is necessary on dozens of pages. Stuff that the writer
didn't understand about the Flare design philosophy
has been bolluxed and must be rectified before the
single-source stuff will work properly.
Finding this out, and then finding out how to fix it,
and then fixing it... turns out to take about as long
as giving the displaced in-house writers a three-day
training or access to (and time for) the Flare Webinars.
Plus, of course, the disgruntled or dismissed in-house
writer takes away her/his headful of years of experience
and history with your products.
- Kevin (playing devil's advocate)
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Gain access to everything you need to create and publish information
through multiple channels. Your choice of authoring (and import)
formats with virtually any output. Try Doc-To-Help free for 30-days. http://www.doctohelp.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-