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: Warning re: importing by reference From:Bill Burns <BillDB -at- ILE -dot- COM> Date:Thu, 27 Aug 1998 17:06:50 -0600
It seems that most of these issues have more to do with file management than
with actual problems with importing by reference. If you manage your files
with importing by reference in mind, these issues don't exist. It would be
the same with files for an application. You take one out, the application
doesn't compile. It's a different way of working, yes. It's not inherently
any riskier than copying directly into a document. In addition, when you
have to duplicate graphics to reuse them, you simply add to your file
management woes--maybe not now, but definitely in the future, if you plan to
maintain the document over a long period of time.
> I agree, absolutely. I know most production-types swear by the
> "reference" method, but after you've had to spend about 16 hours on a
> very tight deadline trying to recreate "screen shots" for a now obsolete
> version of Windows from bits and pieces of other vintage graphics,
> you'll think twice about the so-called efficiency of the reference
> method.
>
> (in case you were wondering why we'd be printing a manual based on an
> obsolete version of Windows, it was a localization "patch" until we
> could get the next rev completed for translation)
>
I don't agree. Our localization DTP group would shoot us if we didn't import
by reference. Since they may reuse a single graphic in 30 versions of a
manual, their file management issues would be considerably more complex
(since they still have to maintain a source for the screen capture). If we
have to create screen captures of an application, it's scheduled and scoped
in advance since it, by necessity, increases production time. Given the way
software seems to change during development and localization, I wouldn't
want to manage the update process that goes along with pasting new screen
captures into 30 localized sets of files.
The only benefit I've seen mentioned for copying graphics is that you can
move the document file without having to worry about the images. In some
cases, this benefit is enough to warrant the practice. With the size of the
projects we have, this practice would be nothing but waste time and server
space.
Bill Burns
Senior Technical Writer/Technology Consultant
ILE Communications
billdb -at- ile -dot- com
