 |
||||||||
 |
 |
 |
 |
 |
 |
|||
|
||||||||
|
|
|
|
|
|
|||
|
|
||||||
In the beginning... (Part Deux)Publishers might not read or love books but they do love good food. In fact, as far as I can tell, the principal skill and activity of an acquisition editor is choosing restaurants. Simon Hayes of Ziff-Davis Press (Macmillan) came to MIT in September 1996 and asked some friends of mine to round up a dinner table worth of "Web geeks who might be able to write a book. Failing that, just geeks." My name apparently appeared in the second category because nobody called me until the day before. I didn't want to write a dead trees book but I figured that ordering lobster was my only chance of getting anything out of Ziff-Davis, which had been copying my images off my Web site and running them without credit or payment in its magazines (my emailed complaints about this practice were ignored). So we all met at Salamander, an expensive restaurant that somehow manages to survive the periodic bankruptcies of the tech start-ups over its head in an East Cambridge office block.Things started to go awry in the opening minutes. Salamander had run out of the lobster special; Simon & friends were from "the other Ziff-Davis." It turned out that the book and magazine divisions had parted ways a few years back. So the dinner wasn't being paid for by the people who'd stolen my images (Ziff-Davis Inc.). A few days later, Simon called to say "I've looked at your [Web Tools Review] URL and I think it is great. This is exactly the kind of stuff we need." Web Tools Review was one of the sorriest corners of my Web server. I started it basically as an FAQ for the hundreds of people who'd emailed me questions about Web publishing. But I hadn't really bothered to maintain it because thousands of people were asking me questions about photography (leading to the massive and IMHO-well-maintained photo.net). Simon said "Turn it into a book. I know you can do it. We want your voice." I told him to forget it. If I wanted to update Web Tools Review, I could do it at my own pace and stick it on my own server and reach plenty of people. If I wanted to feel warm and fuzzy, I'd be better off finishing my Ph.D. research. If I wanted to make money, I'd be better off consulting. Sorry but no thanks. "You can make $60,000." "Hmmmm... maybe I'll write an outline," I responded. After I spent a couple of days working on an outline, I realized that I had much more to say about Web publishing than I'd expected. Three years and 50 sites had taught me a lot of subtle lessons that I thought I could communicate in a coherent manner. Finally, after reading the outline I decided that I had no choice but to write the book. The on-line content at Web Tools Review was an embarrassment. So I called Simon back and said I'd write the book if I could keep the Web rights and use the material to refresh Web Tools Review. The ContractMacmillan and I wasted three months negotiating the contract. Typically writers are desperate to get money and fame and therefore the publisher is able to ram almost anything down their throats. I was busy and indifferent. My personal Web site got 500,000 hits/day. I didn't need Macmillan to reach readers. And if I wanted money, I could just invoice some of the big rich companies for whom I'd done consulting. Furthermore, though I'd written many magazine articles, this was my first dead trees book. I had no idea what constituted a fair deal.My first step was to sign up to the Studio B mailing list. Studio B is a group of agents who represent computer book authors. I would send out Macmillan's proposed contract terms to this list and ask people to comment. My second step was to peruse the O'Reilly Web site. They have done the industry a good service by making their standard contract public, with annotations. The bottom line at O'Reilly is that the author gets 10% of what O'Reilly gets. Ten percent? At this point a lot of authors think that there is something wrong. Given that books are typically sold to bookstores for about 50% of the cover price, 10% of net means the author gets only 5% of the cover price. The publishing industry soaks up 95% of the booty. How can that be fair? Five percent of retail is fair if you abandon one erroneous assumption: that the publishing industry exists to compensate authors. Magazine publishers exist to sell advertising. The writing and photography are filler. Book publishers exist to pay the salaries of people who work in book publishing. The people who work in book publishing are well aware of this. That's why hardly anybody ever quits a job in book publishing to become an author. Consider the two situations. Author: sits alone at home editing manuscripts and praying that proposals will be accepted. Employee of large publisher: hangs out in comfortable office surrounded by fun people, makes twice the salary, assumes no risk (i.e., gets paid whether or not particular book proposals are accepted). Most publishers' standard book contracts include a whole page of conditions under which the author gets half royalties or no royalties at all. Special sales, discount sales, book club sales, sales outside the US, direct sales by the publisher, copies sold by an on-line service, etc., etc., etc. ... The message is basically that the author should be grateful to be published at all. In fact, the author is lucky that the publisher isn't charging him a fee per copy printed and sold! The most upsetting contract provision is indemnification. It is axiomatic that if you publish the truth about anything that matters, you will eventually get sued. That's why newspapers have legal departments. It is an insurable predictable business risk in the publishing world. People will be unhappy with what you write and they will sue you for libel. Sometimes they might even win though they should not have. Book publishers have decided that they don't want to insure against the risk of litigation. Why should they bother when they are multi-billion dollar companies negotiating with individual authors? So they force authors to sign an indemnification clause. If the publisher gets sued because someone doesn't like what you wrote, you have to pay the publisher's legal bills and, if it comes to that, any legal judgment. What is an author supposed to do about this? You could go out and buy a business liability policy but that isn't very efficient if you're only publishing one book. What most authors do is write very bland prose that isn't going to upset anyone. Here's how the contract affects texts: Here the book publishing industry may have outsmarted itself. An author earning $12,000 from a book is not going to expose himself to liability by giving bottom-line recommendations. So people will turn to the Web and USENET when they need advice, rather than shell out $30 for a book of warmed-over homilies. Agent or no Agent?Folks on the Studio B mailing list were generally in favor of hiring an agent, delegating to him or her the contract negotiation, and giving the agent 15 percent. If I'd had a proposal and no publisher, I would have hired an agent, mostly to save myself the degrading process of selling the proposal/manuscript. However, I did not hire an agent for the following reasons:
The DecisionI signed the contract on December 19, 1996, about three months after the dinner at Salamander. Macmillan had agreed to my most important condition: that I be able to develop a free on-line edition of the book. I agreed to most of their conditions. The advance that Macmillan offered made me think that the sun would fall out of the sky before I collected the $60,000 figure we'd kicked around. However, by then I'd fallen in love with the outline and resolved to do the project with or without them.WritingIf you glance around the computer section of a bookstore, it is pretty clear that publishers contribute nothing in terms of editorial quality to computer books. If you glance at the server log of a popular Web site, it is pretty clear that publishers don't contribute much in terms of distribution either. So what function does a dead trees book publisher serve these days? Nagging.Computer books are produced in a pipelined fashion. The author is writing Chapter 9 while the development and technical editors are marking up Chapter 6 while the copy editor is correcting spelling errors in Chapter 3 while the production people are typesetting Chapter 1. This is the only way to get Netscape 4.0 Unleashed into bookstores before Netscape 6.0 hits www.netscape.com. If the author decides he isn't in the mood to write one week, the entire pipeline comes to a halt. So the publisher puts a $1000/week penalty clause in the contract and calls the author every few days to make sure that things aren't slipping. I signed a contract promising to deliver Chapters 1-4 on January 9, 1997, Chapter 11 on February 13 and the final Chapter 15 on March 6. I submitted my final chapter on March 26, 1997. Apparently being 20 days late isn't so bad because Macmillan did not enforce the penalty clause against me. If not for Macmillan's nagging, I would have written a 150-page book in three months and then finished the rest over a couple of years. Though it didn't make financial sense for me to focus on the book so much, I felt that I should because so many people were waiting for my efforts. It seems very inefficient that readers have to pay a bookstore $30 so that a computer book author can earn $1.50 in royalties. But without institutional nagging such as is provided by the publishers, I doubt that many book-length documents would be completed. Writing is depressing. Either you don't have good ideas, you have some good ideas but can't figure out how to express them, or you can figure out how to express your good ideas but not to the target audience. My worst moment during this entire project was when I read Lives of the Monster Dogs by Kirsten Bakis. Lives was such a beautiful realization of a simple idea. Life is short. How could I justify working on a tech book when I could be aspiring to if not actually creating art? After submitting the last chapter I felt drained. I wanted to sleep for two weeks and felt that no amount of money could possibly be worth getting out of bed for. Unfortunately, I'd put a host of Web projects on hold during the three months that I was writing the book. So readers, users, contributors, and consulting clients were hammering me with reminder messages and phone calls. I read a New Yorker article about Robert Hughes, TIME magazine's art critic who only managed to finish his American Visions : The Epic History of Art in America with massive doses of Prozac and psychotherapy. If it hadn't been for Alex, I'm sure that I would have become just as depressed. EditingThe editing of my book was interleaved with the writing but for the purposes of this "book behind the book" story, I'm going to pretend that it happened serially.Up at the top I said that book publishers don't read books. That's true of the people involved in buying manuscripts from authors and marketing finished products to bookstores. However, there are staffers called "development editors" and contractors called "copy editors" and "tech reviewers" who do read the prose submitted by an author. At least at Macmillan, everyone collaborates using Microsoft Word. I'd wanted to write my book in HTML using Emacs, the text editor I've been using since 1978. That way I wouldn't have to do any extra work to produce the on-line edition and I wouldn't be slowed down by leaving Emacs (the world's most productive text editor, though a bit daunting for first-time users and useless for the kind of fancy formatting that one can do with Frame, Pagemaker, or Word). Macmillan said that the contract provision to use Word was non-negotiable and now I understand why. Microsoft Word incorporates a fairly impressive revision control system. With revision control turned on, you can see what you originally wrote with a big line through it. If you put the mouse over the crossed-out text, Word tells you that "Angela Allen at Ziff Davis Press crossed this out on March 1, 1997 at 2:30 pm." Similarly, new text shows up in a different color and Word remembers who added it. Finally, it is possible to define special styles for, say, Tech Reviewer Comments. These show up in a different color and won't print in the final manuscript. [Note: Paul Takemura has written to point out that the one thing I like about Word was not in fact developed by Microsoft. He notes that in "About Microsoft Word", credit is given to "Compare Versions" by Advanced Software, Inc.] If, thanks to the genius of Bill Gates, the mechanics of collaboration were smooth, the process of collaboration was problematic. My goal was to write a book that would inspire and inform intelligent people with enough technical meat to educate an MIT-trained computer scientist but explained clearly enough to be understandable to someone with no programming or CS background. Macmillan's goal was to have a book that would sell well. It is an article of faith in the computer publishing that bigger books sell better. They take up more space on the shelf and readers with a tech problem find a bigger book comforting. Readers aren't really sure what is wrong with their computer and they only have a few minutes in the bookstore so they figure the thickest book is the most likely to contain the solution. Another important albeit implicit tenet is that readers are incredibly stupid. Combine that tenet with the observation that most computer book authors are incompetent and you get the "book with user interface." The first component of the tech book user interface can be found at the front of most books: 10 pages explaining which chapters are relevant and for whom (note that this would not be necessary if the authors were capable of writing an adequate table of contents). These 10 pages also usually introduce a whole raft of typographic conventions and icons. The second component of the user interface is icons strewn throughout a book. Instead of a blank line and "Note:" in front of a little aside, you have the big notepad icon (explained in the first 10 pages). Anything that is supposedly technical is preceded by a bolt-with-attached-nut icon. Another way to bulk up the book is with screen shots. Here's a fragment from my first chapter: "General Electric (http://www.ge.com) is a rare good example of a corporate site that takes the Web as Distribution Medium seriously.. They have brochures, yes, but also owner's manuals and installation guides for every GE product. If you moved into an apartment with a GE appliance but the previous tenants did not leave you the instructions, you can grab a PDF file from the GE site and print it."My development editor for this chapter (Angie) wanted a screen shot of the GE site. I pointed out that the user could just type "ge" into Netscape and surf around. She responded that perhaps someone would be reading the book on a bus. At some level Angie's point was valid but really there was no possible way that one screen shot of the GE Web site could convey what I'd said in that above paragraph. I argued that the the screen shot would break the flow of my writing and distract the reader. The cost of this distraction was far greater than any illustrative value it might have. Mine was apparently a novel argument. Screen shots and figures, no matter how tenuously related to the text, are never gratuitous in the eyes of computer book publishers. I successfully fought off almost all suggestions to bulk up my book, mostly because the Ziff-Davis Press team was already in accord with me and at odds with the rest of the industry. I insisted that Macmillan leave out the user interface and let the book live or die on its organization and clarity of writing. I put in only those screen shots that I thought were really helpful and mostly towards the end of the book when I'd already earned the reader's attention or lost him completely. So we'd all agreed to do an uncommercially thin book. But we started fighting again over whether or not it was safe to assume that the average tech book buyer is an illiterate moron. Publishers are terrified that someone might buy a book and be confused. Again from the first chapter: Some people like a one-truth world. If you have a huge advertising and PR budget then you can control your public image very effectively in a literate world. Ford Motor Company has enough money to remind you 2,000 times a year that "Quality is Job One;" unless you lost a friend in a Pinto gas tank explosion, you probably will eventually come to agree. Microsoft via the genius of Bill Gates invented the mouse-windows user interface, reliable operating systems, affordable computing, and the Internet; if you don't think all that is true, ask someone who has never used a computer and whose only exposure to the industry is through mass media.Even if he hadn't read the back of the book jacket and learned that I was the author of The Bill Gates Personal Wealth Clock, a native English speaker would normally have no trouble figuring out that I don't personally believe that Bill Gates invented the Internet (or anything else for that matter). Yet my development editor wanted me to stick in a sentence or two disclaiming such a belief. To couch this in commercial terms, avoiding one confused reader was worth, say, $100 to Macmillan. But to have a graceful paragraph instead of an awkward one wasn't worth a penny more. The boredom of a literate reader doesn't carry a cost. That's why computer books read like they were written for retarded 10-year-olds. Don't blame the author. The publishers make them do it. Macmillan also surprised me by their prudishness. First they rejected my title: "How to be a (small type) WEB WHORE (big type) just like me (small type)" [see below]. Then they took exception to a part of Chapter 5: Sometimes the referer URL will contain the query string. The very first time I ran a referer report on a server log was on a commercial site. I was all set to e-mail it to "the suits upstairs" when I looked a little more closely at one line of the report. We were giving away "Cosmo Hunk calendars" where each month there was a picture of Fabio or something. A WebCrawler user had grabbed this page and the referer header gave us some real insight into his interestsThis was way over the top as far as Angela was concerned. God forbid that someone should walk into the computer book section expecting to find yet another paean to the flawless products of the American software industry and come out with a book containing the phrase "hunks with big dicks." They couldn't even believe that I'd written it. Why had I included something so shocking? "It is true. And it is funny," was my reply. But I could have written something "just as true" and "just as funny". She typed in the following replacement as a placeholder: We were giving away sports car calendars where each month there was a picture of a flashy car. A WebCrawler user had grabbed this page and the referer header showed what he was looking for.Just as true? I'm not exactly a hostage to traditional journalistic ethics but I didn't understand how something made up could be "just as true." Nor did I see how the above example was anywhere close to as funny as the executives of a $3 billion publisher seeing that "hunks with big dicks" query string right at the top of their brand new HTTP referer report. I tried to persuade them with the example of my cousin who once exiled himself to Muncie, Indiana for two years where he worked for Jim Davis, the man behind the Garfield industry. It turns out that Jim Davis in person is fond of telling jokes about blacks, Jews, etc. But he knows that this kind of humor isn't commercial so he is extremely careful to avoid offending anyone in the actual Garfield strips. If he must make fun of a group, he'll choose fat people. My cousin explained that "Garfield isn't funny because it doesn't offend anyone. To be funny, most of the time, you have to run the risk of offending at least a few people. Jim isn't willing to take that risk." I argued back and forth with various Macmillan folks over "hunks with big dicks" for awhile and I thought that I'd won. At any rate, the pablum suggested by Macmillan wasn't in the "final" draft that I submitted to them. After the book came out, I started getting email from readers. They were confused by a seemingly disconnected section in Chapter 5. I opened up my copy of the book and discovered a whole half-page that I hadn't ever seen. It started off "Someone I know runs a computer answer service, and regularly scans the logs for the 'gooseggs' -- queries that didn't find any matches in the database." This was followed by a bunch of server log entries from this person's site showing users hitting a local CGI script with a variety of search strings. The first problem with this sentence is that it isn't true. I don't know anyone who runs a computer answer service. In fact, I don't even know what such a service would do. Second, I've never heard of the term "gooseggs" and certainly am in no position to introduce it to anyone else. But these paled compared to the real problem with this half-page: it has nothing to do with the topic of the chapter, i.e., how people get from public search engines such as AltaVista to one's site. I'd written about site-local full-text search engines on page 4 of the book (in Chapter 1) and had no intention of coming back to the subject. If I had wanted to return to it, I would have done so elsewhere. Naive readers were confused. Readers with a bit of Web experience thought I was a loser who couldn't figure out the difference between a Web-crawling search engine like AltaVista and his own CGI scripts talking to local site indexers such as PLS, Verity, or Excite for Web Servers. Lesson: delivering a text that won't shock anyone is more important than being correct or clear or truthful. Ziff Davis Press chose to split development editing responsibility for my book. Angie got the earlier chapters and Paula Hardin, thanks to her enthusiasm for database management systems, picked up the later chapters. Unfortunately, by the time I got Paula's suggestions the project was overdue and I was in no mood to make major changes. --- beginning of flaming digression ----Flaming Summary: Why Computer Books SuckBefore lighting the candle, let me say that I think I was working with some of the best people in the industry. Many of them agreed with my biggest gripes against computer books, which is (1) why they let me get away with writing what I did, (2) why my book doesn't have a CD-ROM in back, (3) why my book won't destabilize your desk, (4) why the interior of my book isn't filled with user interface widgets, and (5) why the cover of my book doesn't scream "this is for idiots". Do not read this as a complaint against Macmillan or Ziff-Davis Press (now Que). But working with the best people enables one to more clearly see problems that are endemic to the industry. Here then is my explanation for why the interiors of computer books are so bad.First, since publishers don't pay real money for computer books, the only people who are attracted to work as authors are the clueless and unemployed. If I actually know something about Web publishing, why should I write a book instead of consulting for $1,000/day? But if I've never typed a line of SQL in my life, that makes me the perfect candidate to write a book about databases. Yes the publisher is only going to pay me $10,000 but it works out because I get an excuse to learn a bunch of new things. Maybe I can get a job as a junior database programmer when I'm done. [Note: there are actually people who choose to make a living writing computer books. They do this by cranking out as many as 8 or 10 books each calendar year. Publishers cherish these people who become, if not famous for technical competence or quality of writing, beloved for meeting their deadlines.] Second, we must come back to the question of hugeness. If I stole a copy of PhotoShop, which lacks on-line help, and need to know what every command does, then I want the biggest possible book with as many screen shots as possible. But in other situations, size can be intimidating. My principal home computer is a Windows NT 4.0 box that I don't understand. I once tried to buy a book on NT that explained something about the philosophical underpinnings so that I'd be better prepared to use the on-line help. But all the NT books at my local Micro Center were 1200 pages long. I don't have time to read a 1200 page book. I am afraid to even let one in my house. Then I looked a little more carefully at the NT books. They are full of screen shots and user interface icons. There isn't really all that much text in them. But the text is scattered among so many "features" that it is impossible to follow. It seemed like it would be too much work to plow through one of these so I bought nothing. Flaming Example: by idiots for idiotsShortly after signing my contract with Macmillan, I came upon Creating Cool Web Databases (Sinclair & McCullough; IDG Books). I kept it around on my coffee table so that I could show it to friends and tell them that I'd finished my book. The electric blue cover, garish red "NEW", text-filled packaging, and CD-ROM all instantly screamed "by idiots for idiots". We all got a kick out of watching new people try to say something polite about the book because they thought I'd actually written it.The interior of Creating Cool Web Databases is about what you'd expect from the publishers of the "for Dummies" books and I thought that surely no worse Web/Database book would ever be brought to market. Then one day I got an Airborne package from Macmillan. Enclosed was a book that they thought exemplified the correct approach to explaining Web/DB technology: Web Database Construction Kit (Khurana & Khurana; Waite Group Press). Here was my email reply: Here's what I don't like about _Web Database Construction Kit_:1) it is entirely specific to Microsoft Access and WebSite 1.1. Reading this would get me no closer to building a site with any other tool. In 662 pages, I don't even learn SQL syntax (only how to drive Access through some proprietary forms). After reading each of 662 pages, I could not sit down at an Oracle, Informix, Sybase, DB2, or SQL Server and even see what was in a table. [Most of what is in this book wouldn't even translate very well to using another Web server program with the same operating system and Access, e.g., IIS.] On page 396, they do say "One main hurdle of using an SQL statement is that you have to construct the statement through code, which requires a good working knowledge of the SQL syntax. Fortunately, there is an easy way to bypass this hurdle: Let Microsoft Access tackle the major portion of SQL composition." How I translate this: the authors tried and failed to learn SQL; the authors think they are intelligent; an intelligent person is able to learn things quickly; ergo, SQL must be incredibly hard to learn. 2) the authors don't understand what a database is for (or they don't say it). They talk about structuring data in columns (something you can do very nicely in Excel or flat files) but not about transactions. 3) there are no IDEAS in this book, nothing that could inspire a publisher to make a better site. I wouldn't tell anyone to read this book unless he wanted to sit down and follow 662 pages of instruction to build a simple Access/WebSite site. A manager at Hearst could not read this book. The same person might get a bit lost in a few of my chapters but basically he or she could read my book and get a lot of useful (IMHO) things out of it. A young person with a tech degree, e.g., the typical programmer hired by Hearst New Media, could not read this book because it sounds like it was written by idiots for idiots (also because so little information is conveyed in so many pages). Oh no, I guess it sounds like I'm trashing this book. I don't really mean to. However, I want to be sure that we're on the same wavelength. I don't want to write like this. I want to convey information and skills that will be useful for many years with many tools. I don't want to go step by step through something with Illustra because the reader may be using Sybase. Now I'm looking at the message from Mitchell Waite in the front. I guess I SHOULD trash this book. He says he is "Creating the Highest Quality Computer Books in the Industry". He says I should send him e-mail if I want to comment (but he doesn't give his e-mail address). Oh my God, now I'm surfing his Web site. It has frames, white text on a black background (bleah). Custom link colors. I clicked on News from the menubar at the bottom of the cover page and got an image map file (the actual imagemap defining rectangles that the server was supposed to use to redirect me). The site has no provision for incorporating reader comments or doing anything with the Web that couldn't be done on paper. Book promo pages aren't linked to sources of software in electronic form. The site seems out of date. I couldn't find Web Database Construction Kit, not even after using the search engine. In short, the Khurana book embodies everything that I've been saying is bad about computer books. The Waite group Web site is an excellent example of all of the practices that I deplore in the early chapters of http://www-swiss.ai.mit.edu/wtr/dead-trees/ Philip not working for Waite and glad about it I went and revisited the Khurana book just now, feeling that perhaps I'd dissed it too hard. Couldn't I find something in its 662 pages to like? I opened it to page 16 and looked at Figure 2-3: "A map of the United States showing the state boundaries." Above the caption, surprisingly enough, a stock disk grayscale map of the US took up a third of the page. This was somehow supposed to illustrate the idea of an HTML imagemap. Below it was a list of bulleted items. Instead of a regular bullet, each item was preceded by a drawing of a satellite dish. This instantly reminded me of the icons my friend developed for a bandwidth-stealing site. Just Plain Flame: Cheerfulness Considered Harmful?As long as I'm setting down all of the things that I hate about computer books, let me add cheerfulness. Any complex software system has portions that are well-designed and do the job and portions with holes big enough to fall through. There is some kind of conspiracy among computer book authors to cover both kinds of subsystems in the same uniformly cheerful tone. This masks important distinctions among sections of a program and can be incredibly annoying.Suppose that you are up all night tearing your hair out because something has gone wrong with your RDBMS. You turn to your technical bookshelf and thumb through all the dbadmin guides. Perhaps you do find some useful information but you become enraged by the cheerful tone of the book. You are in this mess because the RDBMS vendor skimped on the design and implementation of a critical system component. This skimping may well have been documented somewhere ("the difference between a bug and a feature is documentation") but you didn't see the relevant caveats before the skimping brought down your service. Partly this is because tech books don't have sections like "design idiocies that are likely to fuck you over." When you finally do find the relevant passage, it is phrased as though the design shortcoming were perfectly reasonable. How else would you want the system to work? So you feel utterly alone. As far as you can tell from reading the vendor's official documentation and the combined products of the computer book industry, nobody else has ever had a problem with this RDBMS. You are the stupidest, unluckiest, and most incompetent person ever to walk the face of the Earth. Why do editors push authors into writing this way? Because there is a belief that computers are intimidating. They aren't friendly enough to the users so we'll make tech books cloyingly friendly to compensate. IMHO, this idea sucks. Something Nice About EditorsMuch as I love to vent my spleen, fairness demands that I acknowledge the substantial contribution my development editors made. Sometimes they took stuff that was good and said "this sucks and/or is confusing". In those cases, I mostly ignored them. But they often found stuff that was bad and said "this really sucks and/or is really confusing." On about 100 pages out of 350, there is at least a sentence or two that I owe to their hypersensitive noses. My nerd friends sometimes found minor technical errors or stuff where I'd oversimplified a bit. But they were all too nerdly to effectively simulate a non-technical reader. They filled in details without ever being aware that they were doing it. My development editors kept me from being sloppy and lazy.--- end of flaming digression ----IllustrationsI got a C in handwriting in Third Grade and that was more or less the high point of my artistic career. One of the best things that Macmillan contributed to this project was a cleverly designed and executed set of napkin drawings, Paula Hardin's idea executed by Mina Reimer. I roughed these out and FEDEXed them to Macmillan and they had Mina spend hours making drawings that looked like I roughed them out. At least half of the people who read the dead trees version comment on these drawings.Illustrators are cheap ($150-250/drawing?) but very few Web publishers ever hire them. They somehow think that they can do it themselves in Freehand, Illustrator or Canvas. Most of us can't, though. The CD-ROMAs stupid as I found the idea of printing a book about Web publishing, the idea of stuffing a CD-ROM in the back seemed to belong to a whole new category of stupidity. Macmillan initially wanted a CD-ROM, on the grounds that readers think such books have more value. I said that if we couldn't get some complete RDBMS packages for the CD-ROM then there was no point in having it (and in fact as my book came out Oracle decided to make all of its software available for download on the Web so there would not have been any point even if we could have gotten a full Oracle for the disk).I asked Macmillan to put in the standard CD-ROM pocket but fill it with a black cardboard disk, said disk to be printed with the URL for the book's virtual CD-ROM (http://philip.greenspun.com/demo.webho.com/). Macmillan said that would be more expensive than a real disk so we ended up printing the inside back cover with a nice "no CD" symbol underneath which ran my text: Would you really want to take Web publishing advice from someone who had to burn a CD-ROM to distribute his software? Come to http://philip.greenspun.com/demo.webho.com/ for electronic versions of the source code examples in this book, for live demos of the software in use, and for the packaged source code to larger systems. IMHO, this URL is better than a CD-ROM. You can't lose it. You can't scratch it. You can't leave it in your office when you need it at home. You can give it to your friends and still keep it for yourself.People laugh when they read this so I think it worked. MarketingIn the beginning, computer books were thin hardbound volumes in muted colors with minimal text on the cover. Then a marketing genius produced an incredibly thick book, in an incredibly bright color, with an enormous amount of text on the cover. Readers wandered in the bookstore knowing that they had a problem with, say, Lotus 1-2-3 macros. Attracted by the thick brightly-colored spine, the reader would pull the book from the shelf and then scan the front and back cover. Because there were so many words and software product names festooning the book, there was a good chance that the reader would spot "Lotus 1-2-3" and "macros". Thus did the book get bought without the reader carefully examining its interior and/or competing titles.Like stockpiling atomic bombs, this approach works best if you're the only one doing it. When you walk into the computer book section of a store today, you're seeing the result of a decade-long arms race. Every book is fat. Every book is bold. Every book has enough keywords on the cover that you almost need an index for the cover itself. I said to Macmillan that I spent all of Chapter 3 arguing against the Web equivalents of this approach. Could we not try to set my book apart by being tasteful? Why not make a computer book that looked like a novel? We'd do it hardcover with just the title and author name on the front. On the back, we'd have blurbs from famous Web nerds hyping the book. On the inside flaps of the dustjacket, we'd have a description of the content and a brief author bio. They chuckled at my naivete: "You might know how to power cycle a dead Web server, Greenspun, but you've got a lot to learn about marketing computer books." Macmillan initially wanted to title the book "Greenspun's Guide to Web Publishing". This is apparently prestigious for the author, i.e., to have one's name in the title. Still, I thought the title was lame and wanted the book to look like this: How to be a WEB WHORE just like me by Philip Greenspun They responded: "Bookstores won't carry it; it is offensive to women." Macmillan persuaded me finally with the argument that people who shop in the computer book section are problem-oriented. Books that are specifically about Product X sell better than books that aren't associated with a particular product. Books that are just good general background reading don't sell at all. My own experience bears this out. I very seldom go looking for a book on "database fundamentals" or "programming language theory" but I might well walk into a bookstore looking for a book about Oracle or a Perl manual.
So my book would go into the bookstores around June 1, 1997 looking just
like every other computer book ever printed: a soft cover covered in
text and a problem-oriented title.
| ||||||