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: What Defines "Entry-Level"? From:Hope Cascio <hope -dot- d -dot- cascio -at- US -dot- ARTHURANDERSEN -dot- COM> Date:Tue, 21 Apr 1998 16:14:04 -0400
This reminded me of a project I've recently completed. I'm in a department
full of pretty "pie in the sky" thinkers who do practical things, while at
the same time, they chafe at the bit of reality. I'm absolutely no
exception, either. I chug along, developing Help, when what I really want
is to explore web-based knowledge transfer and other exciting new
technology. Recently, I was asked to explore options for single sourcing
hardcopy, Help, and (possibly, in the future) HTML-based Help. I had a
great ol' time for a couple weeks, looking at everything from SGML to
RoboHTML to FrameMaker and back again, and finally proposed (drumroll) that
we use what we already have on hand and know how to use. Once I had that
off our collective minds, I dove into the particulars... finding out if the
method tried and reliable, or buggy as all get out, and writing a
methodology. Looks like it'll work just fine, too.
Our department had a wonderful meeting one afternoon, making all sorts of
proposals for improving our documentation delivery. And almost every one
was shot down by budgeting restraints. Maybe our session was catharctic,
maybe it got our idea hamsters running, but I do think that all of those
creative juices are being channeled into what the folks who hold the purse
would call practical, and we're making a better product because of it--
creative, within the restraints of our reality.
Thanks for listening to my own diatribe!
Eric Ray (ejray -at- RAYCOMM -dot- COM) wrote:
(Note that this also applies, particularly at higher
levels in companies, to everything you do at work.
Teleconferenced into a staff meeting this morning
and listened as the manager running the meeting
asked for plans to resolve a logistics/communications
problem. Then I listened as people who really should
have known better suggested
good/fun/interesting/impractical solutions to a very
real and immediate problem. If you need to get
release notes to your customers this week about something
urgent, you think practical (email, fax, ASCII, or
HTML) and NOT impractical (Multimedia presentation,
Winhelp/Wizard, or full doc set revision and mailing).)
Comments on this diatribe would be welcome.