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.
Hanlie Pretorius has been <<... documenting a Java system in development. I
started very enthusiastically, suggesting improvements to screen layouts,
pointing out (to the business analyst) inconsistencies in screen designs,
spelling errors (!) and so forth just to have my ideas squashed by the "we
don't have enough developers to spend on trivial things like that" excuse.>>
Geoff Hart wrote:
>If time's the
>problem, sometimes you can offer to do the fixing for them; it's often easy
>to explain to your manager that it's faster for you to fix an interface
>problem than it is to spend hours writing around the problem.
Often, too, it's far more diplomatic to assume that they understand that a
poor interface is a problem, but that they don't have time to fix it. Also,
*their* job does not stand or fall by typos and inconsistencies, but *yours*
does, because referencing their illiteracies will make *you* look
illiterate. In short, get access to the interface, and fix these problems
yourself. It's usually not a big technical problem to do so.
Years ago when I was documenting a big project, I did eventually convince
the development teams that their life as well as mine would be simpler if
they just gave the documentation team control over the field labels. (They'd
already said these were a trivial, unimportant problem.) Result: a soothing
consistency and lack of typos, plus much cheer for the documentation team as
we shared the most beautiful field labels (I especially liked the unknown
developer who invariably shortened "Analysis" to "Anal", so that Customer
Analysis invariably became CustAnal) before fixing them.
Make yourself part of the solution, not part of the problem.
Jane Carnall
Technical Writer, Digital Bridges, Scotland
Unless stated otherwise, these opinions are mine, and mine alone.
Planning to attend IPCC 01, October 24-27 in Santa Fe? Sign up by
October 3 and get a substantial discount! Program information,
online registration, and more on http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
