Re: Has WebWorks fallen off the map?

["Chuck Martin" <cm -at- writeforyou -dot- com>]

If you find candidates who write well, who organize information well, who
understand the technology (or who can learn it quickly), who have experience
in developing API (including understanding user needs), then why is tool
knowledge so imperative? Tools can be learned, many of them easily. (Sadly,
for just as many, learning how to overcome their deficiencies is more
difficult than learning the tools themselves.) And experienced technical
communicators can often adapt quickly to tools they are not used to or have
not used before.

For a recent contract, they wanted docs developed with Framemaker (for a
PDF), plus HTML-based output for a web application. I hadn't used FM in a
number of years, yet I swung right into it, even designing a (relatively
simple) template. I had only a couple of stumbling blocks, and this
community helped me ove them quickly.

I had never used WWP before, yet I was able to understand its options (with
a bit of assistance from a couple of its Help topics) and put out a very
nicely formatted HTML-based Help system within an hour or two of installing
the product.

For my current gig, they are using RoboHelp (2000), which I also haven't
used for a numbe of years. (I've been doing a lot of HTML hand coding for
Help systems that were developed in-house.) I picked that back up
too--including all its frustrations. I inherited a Help system that was
written by a merketing person, someone who generated very nice-looking
output. But the writing itself was horrible. I'm removing large blocks of
redundant material and rewriting most of the rest.

I'd value good writing skills a lot more than expertise in any particular
tool.

A lot of times, the tech writer's "tool of choice" is whatever their company
is using--and so many companies deploy MS Office. Especially at small
companies, it can be hard to justify spending hundreds of dollars for
vertical market tools where we're "just" writers.

As a side note, at the first gig, the client wanted the Help to look and
work liek salesforce.com, so I looked at the source files and saw it was
built with WWP. But I also convinced them that it should "look" like their
own app.

Chuck Martin

P.S. If you don't mind my indulging my curiosity, as I might have your ear,
I'm wondering why I was never contacted by salesforce.com when I applied for
a TW job there some months back (for end user stuff, where I have oodles of
experience, not yoru current API opening). I even dropped a portfolio of
good writing samples at the main office. My former recruiter told me once
that salesforce.com eats peiople up and spits them out, but I not only take
that as a challenge, the company and its (doc) needs then looked very
interesting.

"Carolyn Dismuke" <cdismuke -at- salesforce -dot- com> wrote in message
news:210211 -at- techwr-l -dot-  -dot-  -dot- 

We've been interviewing technical writers for an API contract. But of the
few applicants that have API experience, NONE have WebWorks experience. They
all have Robo, HTML, and many years in tech writing. You'd think in this
economy it would be easy.

I thought FrameMaker was the tech writer's tool of choice and WebWorks
(although not without its faults) went with it. Is WebWorks too much work?
What are people using instead? How do most FrameMaker shops get their docs
in online format?