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 love this list. Tim Altom transforms the fonts thread:
>We often encounter clients who want us to use an inappropriate tool, for
>example. Clients often insist that they want us to use Word, even though
>Word's long-document characteristics are so primitive that it will double
>our time, cost and trouble. And then they often balk when we try to push
>Word to its limits to accomodate the needs of the long documents. There are
>sometimes internal style conventions that work fine for memos, but make long
>documents unreadable.
>If a client wants you to do something that's absurd, do you walk, or do you
>do it the client's way, knowing that your eventual user will be unable to
>use the thing you've so lovingly crafted? To whom do we owe our final
>allegiance? And to whom do we owe responsibility?
In a flash, the thread becomes a debate over the comparative usability of
Frame and Word:
>Dennis Hays says:
>Very few accelerator keys? Boy, have you got this one wrong. There are many
>(and some even quite mnemonic) and, what's even better, it's the same key
>combination for Unix and Windows--I know, I use it on both platforms daily.
>No, you have it wrong!
>As just one example, look on the Paragraph Designer window. How many of the
objects have
>hotkeys? I'll tell you -- zero!
I'll answer this one first. I've worked very intensively with Frame on all
three platforms for eight years. It's true that the hotkeys are not notated
on the menus and windows. However, the lion's share of the commands and
functions have keyboard shortcuts. Take a wild guess where the info on
accelerator-key combinations is hidden. Yes, folks, that's right...in the
*documentation*. Intuitivity is great, but I can't honestly say I've *ever*
learned how to max out an application without taking the time to RTFM--and I
mean _word for word_, every bit of it. During my first couple of years
working with Frame, I shared "Glanbrok"'s feelings about it. The
functionality was terrific but the productivity was lousy. Then I
discovered the information about accelerator keys--and my productivity
nearly tripled.
Word-vs.-Frame-wars aside, I've had quite a bit of experience with the type
of client Tim describes. I do intranet web site-/content-development
consulting for large corporate clients. There are a lot of tools out there,
and recently a client was pressuring me to recommend their new "standard"
Web publishing tool (InterNotes) for a large and complex site. I felt it
was the wrong tool for complicated reasons that I won't explain here. I was
able to dissuade them from this course. How? Instead of saying yea or nay
to management, I first met with the owners of the site itself and gathered
information about the audience and the material being published. Then I
started asking management endless questions about why they wanted to use
InterNotes and why they thought it was right for this particular site. I
was easily able to rebut each reason using the information I'd gathered on
the goals of the site and the needs of its users. By the time this dialogue
ended, I'd come up with 12 unassailable reasons why InterNotes was not the
right tool. Needless to say, this worked and management was dissuaded.
Essentially, if a client wants me to use an inappropriate tool for a
particular project, I try to gather and present enough concrete data to
convince them otherwise. This doesn't always work, of course. In those
cases, I don't walk--but I do make it known *repeatedly* throughout the
entire course of the project that my sole priority is for the information to
reach its audience...and that if this goal is not achieved for tools-related
reasons, the user has been cheated. And after I've done the best job I
possibly can with the inappropriate tool, I put it behind me, collect the
check, and put my feet up...and wait for the phone call where they tell me
that the users are complaining and I was right, then ask me to redo the work
*my way*. (BTW, this happens around 80% of the time!) Even better, this
provides me with even more ammunition for handling this particular problem
the next time around. There's nothing quite like empirical proof of how
much money can be lost by using the wrong tool--the original cost of work
that I later had to completely redo *and* rebill proves quite convincing to
reluctant clients.
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-
