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: Thoughts on reproducing what's on screen From:"Brierley, Sean" <Brierley -at- Quodata -dot- Com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 4 Oct 1999 09:10:26 -0400
Hallo again:
I received a tonne of well-considered thoughts and advice on this one.
Marginally, the consensus was that the pictures of the first page of the
report, including dummy information, is the best way to go, because the
information is more efficiently packaged that way.
To answer a couple of questions. The book in question has the precision
application of a sawed-off shotgun. The audience is anyone who comes into
contact with the software, from the neck-deep-in-geekdom techie to the
casual, use it once a month manager-in-charge. Thus, few of the readers need
to be bothered by the reports. Furthermore, the book is a difficult one to
write, since the software is based on relational databases and, at a code
level, is quite complex.
Timeframe was my big reason for balking at the task of adding a picture of
the first page of each of the 35 reports to my book. Screen captures would
be difficult to use, because the entire page of a report (US letter
portrait) does not fit on a screen. Furthermore, re-sizing the US letter
screen capture to fit in a US-letter book, with headers, footers, and
margins, would degrade the quality of the output significantly. Printing to
PS, making a PDF, and importing the PDF into FrameMaker seems the best way
to get a clear, resized image into my book. The added size of the file is
another issue. As I stated, I can use conditional text to keep the pictures
out of my online help, but I distribute the PDF and use the PDF to print
from. Someone suggested I use two PDFs, one for print and one for
distribution, but I have a large plate and am on my own, so I do not want to
undertake two PDFs for this and all my other projects, in addition to CHMs,
source files, and other docs . . ..
What, instead, I tried to do was find out, in text, what made the screen
views of reports remarkable and what info readers would glean from them.
Given my deadline, I could incorporate this now while considering the
relative merits of adding the picture of the report. What I received, to my
cynical surprise was for each report, titled : <title>, the developers
outlined the following, in writing, to show the merits of what the readers
could gain, what was important to see, etc.: "<title> does <title>." Now,
once or twice, out of 35, the second instance of title was exactly <title>.
More often, though, it was a restating of <title> with a verb thrown in.
Anyway, this is obviously to be continued, so feel free to send me
additional thoughts about including, as a graphics, the first page of each
of 35 US-letter sized reports from reproduction in a US-letter-sized book. I
am not opposed to showing, as a graphic, this first page but need to justify
adding 35+pages of graphics and 2MB to an already long book. I need reasons.
And, as one of y'all asked, er . . . no, there does not currently exist
dummy information such that all 35 reports yet produce output.