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.
I tried to pare this down to a less lengthy response but Diane has so
many provocative
Diane Haugen wrote:
> At 11:32 AM -0700 6/19/07, Ned Bedinger wrote:
>
>> After thinking about why I prefer editing on paper and what a survey
>> might reveal, I believe that the variable 'occupation' (editor or
>> writer) ought to also be gathered in any survey of editing
>> preference, as it could be confounding.
>
>
> I wound up at Carnegie Mellon because I became interested in the
> interface between writers and editors.
I'll read your comments as informed opinion, then. Ordinarily, I don't
think many tech writers get to work with editors, but I do think the
editor's role needs to be filled in tech writing, even for developmental
and substantive editing of tech writing, because it gives us a dedicated
resource with a fresh objective eye toward good documentation. I can't
count on that from other busy team members, so an editor would be a good
fit.
> I was a writer who started
> editing,
As an editor who started writing, I think it only fair to warn you that
tech writers are rather chauvanistic about our vocation. I've seen this
from both sides, and I know that many tech writers don't want to work
with editors because editors tend to value prescriptive rules of writing
over audience-driven communication styles.
> and I realized that a lot of what is called editing is
> really creating knowledge by recasting the author's thoughts (I was
> doing technical editing).
Yes, and as a tech writer who spends a lot of time grappling with the
language and the subject matter, I welcome the prospect of an editor who
comprehends the subject matter and is prepared to improve my work, To
me, this would be like having a carpenter knock on my door and ask if I
need any work done. Hell yes, I'd say, look the place over and give me
some ideas of what you can do.
>
> The levels of edit do not adequately describe substantive editing,
> and in fact, sort of push them off to the side as heroic efforts
> beyond what editors normally deal with. Personally, I think editors
> do often have to deal with substantive editing when the writer of the
> document does not know the difference between the two.
I'm OK with the idea of an editor/contributor, but I think that a
contributor needs to deal with the whole enchilada--SME interviews, dev
team meetings, good knowledge of project. I'm pretty sure I've never
seen an editor go to such lengths (i.e., to the source) to get the
information needed to write, so maybe the implicit writing work of
substantive editing is the writer-editor frontier, where job
descriptions control who does what.
>
> Yes, I agree that there needs to be some sort of mental construct
> which differentiates a writer from an editor, but I don't think we're
> quite there yet. In a sense, the whole issue of online editing as
> opposed to paper editing sort of detracts from this underlying basic
> difference between a writer and an editor.
Because it points up the wrong differences between editors and writers?
Elaborate on your point, please.
> There's been a lot of
> research on collaborative writing, but I believe (at least up to the
> time I kept up with it) the research tends to concentrate on
> collaboration between writers, not collaboration between writers and
> editors.
I don't have a good idea of how writer/editor collaboration would work.
Would it be like this?
>
> When I have worked with software that tracks changes, I have found
> the comments can take over the document and coherence is lost for
> anyone working on the online file.
Point taken
> When I edit and design a book, I
> am producing printer-ready drafts for the writer, so putting comments
> in the online text file isn't an option.
So own the final draft--you're making changes the author won't see
before the document is printed? Wow, how nice that would be. As tech
writer I dream of handing my work off to someone, but work means I have
100% responsibility for everything from preliminary outlines to
distribution of the published doc.
> I do the sentence level
> changes online and keep a log of comments in a separate file, open as
> I edit, and reference the suggested changes by page. For me, it's
> easy to simply switch from file to file when both files are open on
> my screen, but for others this may seem really cludgy.
No, it doesn't seem cludgy (or kluge-y). The edit log should, in the
recently aired theory of on-screen editing, be cast as an inefficient
use of time and effort. But I think the log creates an accessible,
easily reviewed record of changes. I do a similar log or list BEFORE I
open the doc to make changes online. This is effective when collecting
and comparing the requested changes submitted to me in a technical
review cycle. Once I have changed the document, I then circulate the
revised doc and change log to the reviewers, so that everyone can see
the summarized changes from all reviewers. The log promotes better team
communications, and I feel like this practice instills confidence in the
reviewers, many of whom view tech writers in the way that many tech
writers view editors. Anyway, I commend your diligence.
>
> In the final analysis, as Geoff Hart suggests, as close as we may be
> able to get to some sort of generality is to learn to tweak whatever
> program we are using to accommodate our working styles and the
> constraints of the job.
Now that you mention it, I guess anything can be tweaked. Is this
portentious for the writer-editor collaboration you mentioned earlier?
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
