Re: Too Many Errors! (long rant)

[Jim Grey <jimgrey -at- IQUEST -dot- NET>]

Michael Collier and Glenda Jeffrey found a poorly proofread book about SGML:
>: I recently purchased a book on SGML that shall go unnamed. A cursory
>: thumb-through revealed a poorly placed graphic, sentences without periods at
>: the end, and typos a spell checker could easily catch.
<snip>
>: My question to you is what is it about modern electronic publishing methods
>: that proliferate these kinds of errors?
>I've found the same kinds of problems in one other (expensive) SGML
>book -- but I also have two other SGML books (one cheap, the other
>extremely expensive) that were obviously proofread very carefully. I
>don't think the problem is electronic publishing -- I think it's just
>that the people who worked on that particular book were not very
>careful.

I'm an editor in the computer book publishing biz.  Let me tell you why
books as poorly edited and/or proofread as the SGML book you mentioned are
out there.

My job is a cross between project manager and editor.  Not only do I edit
the text, but I make sure all of the project milestones are met on time.
Recently, I finished a project that produced a comprehensive
tutorial/reference book on a common application about to be released in a
new version.  The book was scheduled for release near the release date of
the software.  The book was written by two very nice gentlemen with great
credentials as users and developers of this application -- who, it turned
out, couldn't organize their thoughts and couldn't clearly express a
concept.  When the project was turned over to me, the authors had already
written 1/3 of the text.  I rejected it all.  It would have taken more time
to edit it into shape than to write it over again.  I recommended to my
management that we release the authors from their contract, and find someone
else to write the book.  The response:  "This is a strategically critical
book. We've promised it to the sales force; they're already pitching it.
Moreover, because most books on new apps sell their best in the first month
or two after the app's release, we have to do what we can to make *this*
manuscript into a book.  This book cannot be delayed, and finding a new
author would certainly delay it."

The authors rewrote the rejected chapters with lots of direction from me and
a copy editor.  The resubmitted text was marginally improved.  The copy
editor ripped the text apart and sutured it back together as best she could,
but her best efforts left the text full of holes.  The technical reviewer
found many factual errors in the text.  With a scant few days to go before
the text was due in Production for layout, I sent the text (eight hundred
pages) back to the authors for another pass.  The authors rushed to fix the
problems, and I rushed to smooth their fixes into the rest of the text.
Because of this, I submitted some of the text to Production late, which
caused the layout and proofreading cycle to be compressed.  Because
Production's time was cut short, they didn't do their usual quality work.
Part of my job is to read proof pages (after the proofreaders read them).
Because Production was squeezed, I didn't have the time I needed to read the
pages thoroughly.  I speed-read them, looking for obvious faults.  I found
several, which were corrected.  The book shipped to the printer, and it
ought to be on the shelf at Barnes & Noble right about now.

It's hard telling what slipped through the cracks.  I'm afraid to look.

>: With oversights such as those, how can I be sure that, for example, in the
>: sample DTD included, there are no misplaced exclamation points, pipes, end
>: brackets or hyphens? Or that such errors do not occur in examples elsewhere
>: in the book?

Bingo.  When the time is taken to choose the right author, to carefully edit
the manuscript, to carefully check the author's facts, and to carefully read
the proof pages, the book becomes solid.  Readers may not know why, but they
feel they can *trust* the book -- because you can bounce a quarter off it.

Conversely, when Time To Market is king, you're far more likely to get poor
quality.

>I had the same reaction. And in fact, I have found mistakes in one or
>two examples! I truly believe that poor proofreading has a significant
>effect on the reader's impression of the book. It's like coming to
>an interview with your tie or blouse on backward.

Proofreading is part of the equation.  I know of some subpar proofreaders
who (somehow) keep getting work.  Most of the proofreaders I've worked with,
however, do the best job they can do in the time they are given.  It's far
more common for a competent proofreader to rush through a project because
it's late, than for a bad proofreader to work on a project.

Peace,
jim grey
--
jim grey          |beebeebumbleandthestingersmottthehoopleraycharlessingers
jimgrey -at- iquest -dot- net|lonniemackandtwangin'eddiehere'smyringwe'regoingsteadyta