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:Dream world: "hands off the developers" From:"Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA> Date:Tue, 25 Aug 1998 09:43:54 -0600
Cynthia Fabre reported that <<it has been my experience in several
companies that the developers are "hands off" and us measly lil'
online help developers shouldn't even speak to them.>>
Unless the official policy is to quarantine the developers so they
don't infect the rest of the company <g>, then this is a policy that
it's easy to disobey without stepping on any toes. Just use Dr.
Geoff's Wonderful Cure-all Strategy number 17 (TM): get to be their
friend, or at least turn yourself into a pleasant colleague they're
willing to chat with at lunch or if you meet in the hall, then use
that relationship as a way to get your opinions heard. Once they'll
listen to you, it's usually easy to make suggestions, particularly if
you can demonstrate the value of your suggestions. I often help
colleagues draft letters, revise their resumes, etc. etc., and that
earns me serious brownie points that I can call in (without being
nasty about it) later.
I've done this several times, including with one developer who didn't
consider the deletion of 3 hours of work to represent a "bug". Long
story, but a little conversation straightened that one out quickly.
Another intractable developer made some important changes because I
persuaded his partner to make similar changes, and peer pressure (the
need for interface consistency) did the rest. I've managed to
condition another developer to routinely come see me with his
prototype interface before he even begins coding it simply because I
blew him away with an early suggestion that not only made sense from
the user perspective, but also made it easier for him to program that
function. Let's be blunt about this: you will definitely meet
developers who treat you as less than dirt, but they're far less
common than one might expect, and you can certainly change their
attitudes if you can get them to treat you with some respect.
<<To say that a field "should" not have a description is to assume
your user is smart and competent. We've all dealt with enough CSR's
at the receiving end of an 800 number to know this is not always
true!>>
This relates to the discussion of adding a "insert address here"
popup to the "address" field, right? If so, then there's always
something you can insert to make the popup useful, even if it would
seem to be obvious and unnecessary. For example, instead of "insert
address here", how about "When entering the address in this field,
put the street number first, and the office/suite number at the end
of the line." (Bad example, and not well written, but you get the
point... provide similar "affordances" to help your audience enter
consistent, correctly formatted data.)
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca
"Men are from Earth. Women are from Earth. Deal with it."--Author unknown