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.
>So here are the problems (this is where you good people come in):
>1) I notice that almost all manuals for development tools are 7x9"
>perfect bound. This looks sharp, but you can't lie it flat without
>breaking the spine, and you can't flip it over. Can you tell me
>why most companies ship perfect bound manuals instead of
Because it looks snappier. The user takes second place, as usual.
The 7x9" format is used because some industry leader or other used
it -- IBM used a truly wretched 5 1/2 x 8 1/x binder format for
the IBM PC, and everyone else in the industry (except Apple)
mindlessly copied them. (Apple had already settled on a lay-flat
spiral-bound format, but IBM didn't notice, and most of us
had to live with the bulky, rings-that-snap-open-and-dump-your-
pages-on-the-floor designs given to us by the lemmmings who
follow industry-standard practices.
So my advice is to give industry-standard practice a good hard
slap in the face and figure out what you would do in a perfect
world, and make only necessary deviatoins from that ideal.
You should design documentation for the user, for yourself, or
both. 8.5x11" documentation is a convenient size to develop,
since that's the size paper comes in (in this country), so it's
easy on the writer. If the document needs complex illustrations,
the smaller pages sizes may be too small for 7x9". But it all
depends on the application.
>2) This is going to spark a turf war if Development pushes it very
>hard. Apparently Marketing is very attached to their design (tho
>I can't believe they gave any thought at all to the user when they
>dreamed this up). Any advice from turf-war veterans on how to
>say "this sucks" very sweetly and with the minimum offense?
Kicking other departments in the teeth is management's job,
as are all aspects of interdepartmental turf wars. It's your
manager's job to make Marketing acquiesce to the new design --
in advance -- and agree to use it. Otherwise, what's the point?
Marketing generally controls the distribution of documents, and
they can bury your version.
>3) The timeline for this project is 6 weeks. I've been told to allow
>for 2 weeks for printing, narrowing down the horizon to 4 weeks.
>Am I dreaming to think little old me can reorganize, redesign,
>and copy edit 170 pages (in the 81/2x11 format) in 4 weeks? I
>can't find any benchmarks for this kind of activity.
The rough rule of thumb I've always used is 25 pages per day
for technical editing, and a somewhat higher number for desktop
publishing, depending on the density of complex diagrams, large
tables, and the amount of boneheaded DTP work that has to be undone.
Worst case, you're looking at 12.5 pages per day for all work. You
have 20 working days, which would accommodate a 250 page manual.
Piece of cake. (Of course, this assumes you have good tools. I
know people who have written manuals in MacDraw or PowerPoint. I
refuse to speculate about productivity under those conditions, though
it obviously can't be very important, or they would have done
something less ridiculous.)
Of course, this will leave you only two days for a review. :-(
Robert Plamondon, High-Tech Technical Writing, Inc.
36475 Norton Creek Road * Blodgett * Oregon * 97326
robert -at- plamondon -dot- com * (541) 453-5841 * Fax: (541) 453-4139 http://www.pioneer.net/~robertp