Charles Petzold

As I've been contemplating, planning, and working on my book about the Windows Presentation Foundation, I've been struggling to come up with ways to make it more appealing to readers.

It's been very obvious to me that WPF is so huge that no single book could ever hope to cover every little detail. And really, that's not the job of a tutorial. The first rule I've set for myself in writing this book is:

Rule 1. Don't Even Try to Compete with the Docs.

By "the Docs" I mean the "Microsoft Visual Studio 2005 Documentation" program in which can be found the enormous tree of .NET namespaces, classes, etc. As any .NET programmer knows, this documentation is indispensable. Along with Visual Studio itself, the Docs program is always open whenever I'm doing .NET programming of any kind.

It wasn't always obvious to me that I can't compete with the Docs. When I was writing my first Windows Forms book Programming Microsoft Windows with C#, I tried to make the book play multiple roles. I figured people would read the book as a tutorial, and then use it for reference later on. I actually envisioned the reader having the book open on the desk while programming. To facilitate that, I included many little tables of properties and methods and enumeration members that the reader could use as reminders, and then get details from the surrounding text.

It was a noble experiment, but obviously a failure. I rarely use the book like that myself, even if I remember the precise chapter where I discussed something that I've forgotten in the interim. When I'm doing Windows Forms programming, I'm using the official Docs, even if it takes more time than rummaging through the book.

What can I say? I started working on that book 5 years ago, and that's an eternity in computer-industry time. Providing extensive documentation in the book seemed to make sense then. In retrospect, it's ridiculous.

My WPF book will not even try to compete with Microsoft's .NET documentation. That's not the role of a tutorial.