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.
<snip>
I for one would welcome a shift away from the present
practice of having each technical writer spend a
substantial part of each day consumed with simple
formatting issues. </snip>
Dude, what are you doing in that shop of yours? <incredulous wide-eyed
awe> This has never been my practice, nor the practice of any serious
tech writer I know. Especially if you're a lone tech writer, you spend
as little time as possible on formatting and virtually all your time
a)researching, b) validating, a.k.a., fact-checking, c) writing. You
develop a template, you *especially* use paragraph styles/tags to
minimize the impacts of restyling, you modify them only when needed. I'm
sure this is not only true for lone writers.
XML and repository solutions are simply not viable in many
circumstances, particularly when you have a lone writer or an immature
organization. Half the writers polled on this list started as lone
writers.
(http://www.raycomm.com/techwhirl/polls/techwhirlpollresults.php3?pollID
=100) This doesn't just happen in small companies. Many writers at large
companies do not work for a tech pubs group or have an infrastructure to
support database publishing. (Of course lone writers can do
single-sourcing if they have the tools.) Furthermore, I think it depends
on the product set. If I'm writing for a single suite of applications
where there's a lot of potential for reuse and a long product life, then
what you're talking about may be a good solution. But if you're
supporting multiple, completely separate applications that have no
relationship, your idea isn't so practical.
Just as we must approach our writing tasks with the goal of solving the
needs of the user, so must our production process and tools meet the
needs of the environment in which we're writing. It's not as simple as
saying, "XML and repositories will solve all of our document production
needs." A content repository is not going to create better writing;
better writers create better writing.
I'm curious whether you feel you've observed the distressing practices
you describe in other tech writing situations, or are these observations
derived from your own shop? And what other factors are eating into your
time? You've painted with a rather broad brush. Some more details might
produce some more insight.
Lisa
(Yes, now that you mention it, I AM a lone writer? However did you
guess?? :-) )
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr
---
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.
