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.
> -----Original Message-----
> From: lyndsey -dot- amott -at- docsymmetry -dot- com
> Jason Willebeek-LeMair writes:
>
> > Problems with content create enormous problems with
> customers and support.
> > Problems with design cause only internal headaches.
> >
> > Fixing design errors is a fairly mundane, brainless task.
> I could get an
> > intern, teach them the DTP application and template, and
> let them loose.
> > Or, I can stay a couple of extra hours and do it myself.
>
> I agree that fixing design errors is a mundane, brainless
> task and that is
> exactly why I don't want to do it. I feel the same about housework.
Right. But, the point is, they much easier to fix than content errors.
>
> >
> > However, fixing erroneous information because the writer
> did not understand
> > the material can be quite a headache. And if those types of
> errors get
> > out to the customer, you end up with credibility issues,
> additional support
> > costs, and possibly lost business. Even if there is a
> thorough review to
> > catch those errors in the beginning, rewriting takes longer
> than arrowing
> > through a document and applying styles.
>
> Inaccurate, unclear documentation goes out to customers all
> the time. The
> problem is usually caused by the writer's inability to write
> clearly, not by
> his lack of technical knowledge, which is easily overcome.
Not so. I have seen many fine writers send out poor documentation.
It is because they do not grasp what they are writing about.
>
> And, if you are in a rather
> > fast release cycle, having someone who can produce
> creditable documentation
> > without spending an enormous amount of time doing research
> >is a bonus.
>
> You seem to assume that a person who does not have experience in the
> technology will not be able to figure it out and write about
> it.
Not at all. If you reread it, I said that it is a bonus not a
necessity.
>I am a
> freelancer who has worked at many different companies. When I
> start a new
> contract I am not only in a state of complete ignorance about
> the company's
> product, but I am also just about overwhelmed by all the
> acronyms. Even
> having experience in a particular technology does not help
> much. Knowing
> about switching, for example, does not help me understand wireless
> intelligent networks, which does not help me understand
> synchronous optical
> networks, which does not help me understand mobile IP. When I
> think back to
> my first technical writing job, in which I had no techwriting
> experience and
> no technical knowledge yet still managed to write accurate and
> easy-to-understand documentation, I have to say that the most
> useful-for-my-career knowledge I got from it was document design, not
> technical knowledge.
I have no doubt that you learn very fast. You can't make it as
a contractor if you don't. That is great. I learn very fast too,
actually. But, if I have to hire someone to document an optical
switch, I would favor someone with experience with switch and
optical networks. Well, that is an oversimplification. It would
depend upon the project timeline, the current talent on the team,
my needs, and whether I wanted to grow someone into the team or
get a quick win. But you get the idea.
>
> You also seem to assume that good document design is about
> paragraph styles.
> I have to conclude that you don't know much about doc design! :-)
Well, you would be wrong. But no hard feelings. You have not been
properly introduced to the wonderessness that is me! 8-) (PLEASE
NOTE THE SMILEY--I AM NOT _that_ EGOTISTICAL).
I personally feel that design issues are easier to fix. Yes,
there is more to design than paragraph styles. It ranges from
organization to layout to what is included to what is not included.
Of course, I am biases. All my stuff is in XML and is rather
easy to rearrange, tweak, and fiddle. What I hate is finding
content that is wrong, which leads to other content that is wrong,
which leads to me spending the weekend correcting a document.
Besides, as a freelancer I bet you make a bunch of money from
fixing other people's content problems. So, of course you
would prefer to see those types of problems. ;-)
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
