Charles Petzold

There is a book I've been intending to read that's about 700 pages long, has the reputation of being hard, and was written over 250 years ago, all of which combine to make the book very intimidating. But the book is divided into approximately 90 chapters, and I thought if I spent maybe 30 to 60 minutes a day reading just one chapter, I could finish the book in three months (and become very, very smart in the process).

This plan didn't actually work (other priorities intervened) but it was a good idea, and it will work sometime in the future. But it got me thinking about chapter length.

My two Windows Forms books have chapters that average about 50 pages. To someone intending to read the book from beginning to end, or someone interested in a particular topic, the 50-page chapters could be intimidating. Perhaps I could make my new book more "user friendly" (to resurrect an antique term) with a different structure.

My third rule for writing my Windows Presentation Foundation book is:

Rule 3. Write Shorter Chapters

How short? For awhile I toyed with the idea of the book consisting of 100 chapters of 10 pages each. The round numbers appealed to me. Each chapter would focus on a particular topic, for example, the DockPanel, or routed events. But, of course, the book wouldn't be just a collection of little articles like the typical overviews found in the Microsoft documentation. The consecutive chapters would provide—as in any worthwhile tutorial—a progressive narrative thread through the material.

The chapters would be short enough to allow a reader to dive into the middle of the book for reference and at least read a whole chapter. And, perhaps, because each chapter connects with the one before it and the one after it, the incentive might be there to read the chapters consecutively. And that's about all an author could possibly hope for.

As I actually started writing chapters, it became apparent that 10 pages was just too short. The chapters are really turning out to be about 20 pages.

Of course, even that's a lot. You just can't list 50 chapters in a Table of Contents and hope the reader can make sense of it. The chapters must be grouped into Part I, Part II, and so forth. For a couple months now, I've been carrying around a 4×6 card on which I've listed the following six parts:

I. Controls & Layout
II. XAML
III. Data Binding
IV. Styling & Customization
V. Graphics & Animation
VI. Documents

The first part is entirely C# code, and will probably be the longest part in the book. It looks like it's coming in at 15 chapters and about 300 pages. I would like to email this chapter to my editor at the end of this month. Let's just hope there's nothing coming up in the next 12 days to distract me.