Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Friday November 01, 2002
10:10 PM

Book sizes at O'Reilly

[ #8734 ]
It seems like O'Reilly has finally succumbed to the trend for thick books. The latest offering, Paul DuBois' MySQL Cookbook weighs in at 1022 pages. The first think O'Reilly book I remember was the 2nd edition of Programming Python (1256 pages), shortly followed by the 3rd edition of Programming Perl.

I'm not complaining. There's a lot to say about each of these topics. Part of me wishes we could go back to the days when a major technical work would be released in a series of volumes with copious cross references. (The X and UNIX manuals come to mind.) It helped to just know you wanted to pick up Programming Perl, Volume 3: Regular Expressions, open to some page or another, next to Programming Perl, Volume 2: Builtin Functions open as always to the page on localtime.

Sadly, those days are gone and unlikely to return. The major multi-volume reference works that I remember were produced by the technical writing department at companies like AT&T, Sun, DEC and the like. (Yes, O'Reilly belongs in that list, but I'm not sure who actually wrote the X manuals.)

Then again, O'Reilly is living in an industry where competitors are using all sorts of dirty tricks to get books with wide spines to the market: thick paper, wide margins, large type, and long stretches of text (or code) that say nothing. At least O'Reilly is delivering the same kind of material the old multi-volume libraries used to deliver, while their competitors play games.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • And then you get people like me who won't buy the fat books because they're too damned heavy. I'm not buying camel3 for that reason. Ditto ESA. And a few others. At least Camel3 can be easily split into volumes.

    Mmm. Safari.
    --
      ---ict / Spoon
    • And then you get people like me who won't buy the fat books because they're too damned heavy. I'm not buying camel3 for that reason. Ditto ESA. And a few others.
      But would you buy PPerl3 if it were sold as a three-volume set, so that you can keep one volume at a time with you in your backpack?
      • Absolutely. Although I'm not sure I actually want a copy anyway =)

        Even a two volume set of Camel3 would be fine (not having a paper copy handy I'm not sure exactly where it can split well =) ).
        --
          ---ict / Spoon
  • I wanted O'Reilly to print my book on paper-towel paper!! But they wouldn't.
  • Looking at several recent books, Perl & XML, Learning Cocoa, Perl & LWP, and Mac OS X for Unix Geeks are reasonably small. Dynamic HTML is huge, though. I think you're noticing that cookbooks and definitive guides are big. Normal books tend to stay in the 250-400 page range.

    • Dynamic HTML [oreilly.com] is a scary 1418 pages. I almost put my back out picking it up. It's also so big, bulky, and overwhelming that I haven't read a single page.
    • Yes. O'Reilly titles aren't uniformly huge. While some of the denser titles are thick, there are a few that are just barely 200 pages. (The first edition of the Polar Bear [oreilly.com] book was around 200 pages; the 2nd edition is just under 500 pages.)

      I've always found that the optimal length for a technical book to hover around 300 pages (of reasonable thickness). That also supports what I said about taking a 1400 page tome and chunking it into 4-5 topical volumes...

      Just another $0.02

  • "It seems like O'Reilly has finally succumbed to the trend for thick books ... O'Reilly is living in an industry where competitors are using all sorts of dirty tricks to get books with wide spines to the market"

    Translation: I just bought a thick O'Reilly book. We've always done thick and thin books. The editorial motto is "write as much as needs to be said, no more and no less". If there's 1200 pages in a MySQL Cookbook, it's because we couldn't fit it into 1199, not because the first draft stopped at

    • I'm no O'Reilly historian, but I believe the first O'Reilly books were a series on the X-Windows System. An office where I once worked had the complete set. Each book was fairly thick. Each book covered one subject as completely as possible, spilling over into multiple volumes where necessary.
      • O'Reilly and associates started their publishing business based on the sales from those X manuals.

        As gnat pointed out, the problem with multi-volume sets is that some volumes sell more than others. I believe that it's a lot easier to find volumes 3 and 3M (Motif) than many of the other volumes. I think they were the biggest sellers in the series. I don't know how often I've seen the full set (with the Motif volumes included), but in my experience it's a rare site to see.

        • I was agreeing with Gnat. Some of those X manuals were quite thick.

          I think O'Reilly has not changed it's policies with regard to manual thickness. They make them thick enough to cover the subject as completely as possible.

    • You're right that those days aren't likely to return. The prevailing wisdom is that if you release two volumes, sales of Volume 2 will be lower than Volume 1.

      Also, I vaguely suspect that two volumes would cost a little more. Of course, this is hardly a matter with O'Reilly books. The benefits I got from my three O'Reillys (Debian, Linux in a nutshelf and the Camel) far outweight the money I paid for them.

      Anyway, there is nothing at all wring with thick books! I wish the Camel had 5000 pages instead of j
    • I just got my copy of the new Mason book, and was wondering, what happened to the RepKover? Surely the Mason book is slender enough that it could have used one, no?

      --David

      • Two things: (1) it was expensive, and we've had to pinch the pennies where we can; and (2) we had complaints about pages falling out and other miserableness. As far as I know, we're sticking with perfect binding.

        --Nat

    • It's a pity I packed it into boxes already but I do have a copy of the original "Make" book by Andy and Tim which, if I recall correctly, was ~200 pages, roughly 6x8" in size and had punches for a 3-ring binder. Is anyone at ORA still planning on doing a little timeline style history of the books over the last 15 years? But, one must admit, compared to ORA books ca. 1994 when the Sendmail book was leviathan, they have increased in page count which could mean there is more to write about or the topics have t
      • It's our 25th anniversary next year. Expect a lot of cool things, including a shindig at OSCON. I imagine a timeline history will be part of this.

        --Nat

    • Translation: I just bought a thick O'Reilly book.

      Not exactly.

      A while ago, I was approached to write a book about SOAP. I'm not exactly interested in the topic, but I've a fair share of presentations about it, and written an article or two about it. The publisher who approached me out of the blue started the conversation by talking about the process of writing a book for them: make sure that it's at least 300 pages at a bare minimum, because the book won't sell unless the spine is at least 4 inches

      • Unfortunately the dirty tricks don't just apply to technical books. Having bought many second-hand sci-fi books from the 60s/70s, which neatly fitted into your pocket, the same books are now being republished at least a third bigger in all dimensions, mainly due to the type being twice the size and with bigger gaps between the lines.

        While ORA and others do produce good quality books in my opinion, there are some (one based not too far away from where I'm currently sitting) that do feel they have to resort

      • As a co-author of an upcoming O'Reilly Cookbook -- PHP Cookbook -- I can assure you that there was no pressure from the O'Reilly staff for our book to be any length other than what we felt was the correct one.

        In fact, we cut material from the book towards the end because we didn't think it was of the same quality as the rest.

        Also, the Cookbook format lends itself to longer books because of the Question / Solution / Discussion division. We could make it more compact, but it'd be harder to skim and it'd t

        • I can assure you that there was no pressure from the O'Reilly staff for our book to be any length other than what we felt was the correct one.

          I never said that there was any pressure to fill pages, or water down the quality of a title to fill a length requirement.

          Also, the Cookbook format lends itself to longer books because of the Question / Solution / Discussion division.

          This is exactly my point. The cookbook format at O'Reilly is about 5 years old. At the time, the Perl Cookbook was one of O

        • Hi Adam! :-)

          Yes, you're right--the interior design was changed to fit more on a page. Headings take less space, we can get more columns of code in our examples, and we get more words per page overall than before. All contribute to a lower page count.

          --Nat

      • the book won't sell unless the spine is at least 4 inches thick

        Ho ho. The one piece of feedback we consistently hear about our books is that people like small ones. We editors love small books. They're quicker to do, easier to edit, and faster to get through production. The 1200+ page monstrosities are clusterfucks for everyone. Some books need those 1200 pages, though--good luck writing The Definitive Sendmail Book in 250 pages.

        it looks like O'Reilly needs to compete more effectively with other l

        • One extra paragraph of italic at no extra cost!

          Bah. I was distracted by the arrival of "Computer Science & Perl Programming". Whee!

          --Nat