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.
Subject:Re[2]: Documenting A Moving Target From:Kristina Ricks <kristina_ricks -at- MAIL -dot- MEDICALOGIC -dot- COM> Date:Wed, 21 Feb 1996 11:58:58 PST
Interesting thread... generally part of the deal (in my experience) in
software writing.
One thing I found helped in my previous job was that I got the job of
writing error messages. This accomplished several things:
* The programmers were glad to pass it off to someone else... many of
them dreaded the task of writing these messages.
* I got my hands somewhat into the UI... at least as far as the
language of the messages goes.
* I had a view into what was changing where in the interface. I had to
sit down with the programmers and they would explain the situation,
the error condition, and why/where/how the error would take place.
From these conversations, I could usually see what else was changing,
and how that would affect all the documents.
* It meant that all messages had to be "externalized" (referenced in a
separate message file, not imbedded in the code), which is usually a
requirement if the product will ever be translated into another
language.
I'm currently lobbying to get this job in my new workplace. If all
works well, I'll be the designated error message person, and
communicate the UI changes I discover to the rest of the documentation
staff.
