You’ve written a few magazine or MSDN articles, and now you feel ready to write a book. It’s got to be different to write a whole long book, but the more you think about it, the less obvious it seems. The difference between writing a series of related articles and books is huge; it isn’t solely a matter of the number of pages you need to produce. If you bought a book for $80, a thousand or so pages on your favorite techie topic, how happy would you be if you found that no subject was covered more deeply than 10 or 15 pages? I suppose initially, you’d be excited by the diversity of coverage. But after a while, you’d start feeling like you never did more than skim the surface of anything. Is a skimming worth $80? The purpose of a magazine article is to give readers an overview of a large topic or to spotlight a narrow aspect of a larger topic. A series of related articles is interesting, but you never get deeper than the overview; if you do delve deeper briefly, it’s mostly out of context of the greater product. The purpose of a book and its chapters is to take a large subject and examine all its aspects, whether they be large and compelling, or small and nearly insignificant. After reading your book, readers should feel pretty confident about their understanding, and perhaps ability to use, the product you’ve described. To start thinking about writing a book, create an outline. Yup, you’ve read that I want you to do that for articles too. But it’s not optional for books, no matter how brilliant you are. The scope of a book is much larger than that of an article, and you really have to create a map to end up in the right place. The publisher will require an outline as a tentative table of contents anyway, so create an outline of at least the major subjects. You don’t have to go deeper than naming the topics yet. You may find that you’re eager to outline the details. If you get bogged down in the details now, you could be in real trouble defining all the topics for a whole book. Try to think in terms of building something fairly robust throughout the course of the book (once you’re past the initial introductions), and you’ll find that you’ve covered a lot of interesting tangents. But resist the temptation to outline details until you’ve got the whole book outlined. Using this surface-level outline, make a very general stab at guessing how many pages it will take to cover the material in each chapter. Total your page estimates and see if it fits into your idea of a suitable book length (you could check out a few published books on your topic and see if your estimation is typical). You should also make sure that each chapter is about the same length. If you have a really long chapter, consider breaking it up; if you have a really short one, consider combining it with another topic. Once you’ve got an outline for the whole book, you can develop a few of the earlier chapters into their own outlines, just as if you were going to start writing them immediately. Try to make a later chapter hearken back to one you’ve already outlined. Look for themes. This time, you are looking to see if your topics are in the right places. Say, for instance, that you’re describing security in Chapter 6. To set that up, you need to have talked in previous chapters about users, groups, normalization, network connections, server issues, software licensing, coding techniques, sharing work and templates, Internet connections, administrator functions, and any number of other relevant elements. Or perhaps the product you’re describing is meant to be used on a stand-alone computer, and the security issues have to do with multiple users, inadvertent changes, or protecting users from inappropriate websites, rogue IMers, or hackers. Either way, you can see how many topics need to be covered before you cover security, unless your plan is to cover all that stuff in the security chapter itself. You might find yourself with a monstrously large chapter on your hands if you try to pack it all into one place. This is your chance to look at that and try to create balance. If you know that the security chapter is going to be of greater interest to your readers than most of your other coverage, head (in your coverage) toward that all important chapter from the beginning. Make sure there are references to security-relevant objects and methods, programming and development tools, user set-up forms, and so forth. Point to the chapter with overt coverage like this: “(see Chapter 6 for more on X)”. Make good notes along the way, so those early promises are kept when you actually get to writing the security chapter. If the security chapter is just another aspect of building your application and exploring a product, don’t point to it much. If there’s another topic that you think will be the main focal point of the book, try the same experiment. It’s great if you have two—or even three—subjects that you think will be major draws. Now that you’ve thought in some detail about your outline and where the larger focus of the book will be, you can really start playing with organization. Know that hardly anyone reads books on technology sequentially from page one through to the end. Most people skip around to the bits that are relevant to their purposes. So you can organize your chapters in a way that makes the most sense to your idea of a good reading order, and then be sure to include lots of references to coverage elsewhere in the book as you write. If you’re building a single application throughout the book, or several related applications, your options are limited, as you need to be chronological to some degree. But you can still play with what needs to be covered first compared to what you want to covered first. Now think back on those magazine articles. Plainly, there’s a lot less involved in the planning! I’ll write more on writing a book from the perspective of magazine articles soon.