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:Landscape vs. portrait? From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Mon, 7 Jun 1999 08:56:07 -0400
Krista Kostuch observes <<...Since we are distributing
most/all of our material in pdf format, landscape would be the
way to go because it is so much easier to view online. You
get to see an entire page on the screen, without having to
scroll.>>
Seeing an entire page on the screen is irrelevant, and has no
relation to the print orientation; in fact, portrait mode is
probably better, since it occupies only part of the screen,
thereby leaving room to see the documentation and the
application simultaneously. The truly important thing is
ensuring that users can see all the information simultaneously
for a given _chunk_; for example, a procedure could span
several pages, provided that the screenshot and the text that
explain any given step all fall on the same screen. To achieve
that end, you'll have to design your PDF specifically for the
screen. That means it won't fit on paper properly:
<<However, when it comes to printing the document, it is
printed one sided and therefore takes up much more paper.>>
Because it wasn't designed for printing. The simplest solution
is to prepare two versions of the file: one for online viewing,
and one for printing. That's not so hard to do if you're
hellbent on producing a single "one size that is suboptimal for
both online and print" file. However:
<<As we all know, there are a lot of people still out there who
want to have that hard copy. I know, I'm one of them.>>
That being the case, send them a printed manual along with
the product. Speaking for you and me--and probably most
others--we want our paper manuals, and will continue to want
them until help technology catches up with our needs. (It's
getting close.) Companies who send me nothing but a
program and a PDF earn a lot of bad kharma, and I'll start
seriously thinking about switching to a company who cares
enough about my needs to supply paper. Frankly, I'd rather
pay $10 extra to cover the cost of a professionally printed and
bound paper manual (which cost $2, plus 400% markup) than
$5-$10 to print it myself, unbound and unindexed, with my
inkjet or laser printer. Which would _you_ rather have?
Which do you think _your audience_ would rather have?
Let's put this in perspective. If your product sells for $200,
you're increasing the production cost by ca. 1%, which ain't
very much. How much is customer satisfaction worth?
<<So, what is the best way to go?>>
Unfortunately, the best way to go is to give up on single-
sourcing unless you've got the time and other resources to do
it right. Creating a one-size-fits-all PDF is inevitably the
wrong solution. If the goal is to make documentation
available online, forget about PDF: you want something like
WinHelp that ties directly into the application so users can
call up context-sensitive help, and PDF simply can't give you
that yet, at least not without custom programming. (Or can it?
Someone please set me straight if I've missed this option.)
Either avoid PDF entirely, or format the files specifically for
print and supplement it with integrated online help. Better yet,
give them a printed manual and online help.
