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.
>So, for those writers who hold sway in GUI issues, how does your company
>include you? How is the corporate structure set up to solicit and act on
>your input?
Some companies are more willing than others to include tech writers in
GUI design, but if you learn to use the defect-tracking softwarte your
development team uses, you're halfway home. See, programmers work on
a schedule and have specific goals, so ambushing them in the hallway
and asking them to fix a GUI thing really doesn't work -- they don't
have time, it's not on their task list, they forget... Enter your
suggestion as a bug and everyone from the product manager on down
knows what's going on. Defects, such as "does not conform to platform
conventions" and "grammatical error" will usually get fixed before
the software is delivered. Suggestions for product enhancement,
however, will be lower on the overall priority list and may not get
fixed until "next rev".
>What does your company do in the way of freezing the GUI before
>release, or don't they?
Here again, some companies are better than others, but you need what
you need and that includes a stable interface to document. When you
create your doc plan for the project, use interface freeze as a
dependency for your finalization tasks, promising the manuals x days
after GUI freeze. Every time the GUI changes, the clock starts ticking
all over again.
Procedures. Learn to use 'em to your advantage. ;-)
