By Eric Meyer, Author and Simon St.Laurent, Editor
O’Reilly is taking a new approach to publishing one of its classics, CSS: The Definitive Guide. The Fourth Edition will arrive in bookstores sometime soon, but long before then you’ll be able to buy sections of the book on more tightly-focused topics. The first three just came out:
We expect that this will work better for readers, the author, and the publisher, but the reasons are all different even though they interlock.
Some readers tell us (O’Reilly) that they want the latest and greatest and don’t worry as much about quality. Some readers tell us that they want every “i” dotted and every “t” crossed. Serialization lets us achieve both of those goals. The content comes out much faster, but it’s already been copyedited, reviewed, and illustrated. There may be updates to come if the content changes or errata (inevitably) turns up, but O’Reilly has polished each piece before its release. It may not yet be perfect, but it should be comparable to our usual finished books.
CSS: The Definitive Guide is large and getting larger as CSS grows. The writing process will take a long time, and in the traditional model content written at the beginning might wait a year or more to see customers. This new approach gets content out, and makes it much easier to fix things when content goes out of date.
With serialization, readers get much faster access to the most recent information, and customers who buy the ebooks will also get updates if the pieces they buy change. They can also buy the pieces secure in the knowledge that if they want to buy the whole thing later, O’Reilly will make sure they don’t lose their early investment: we’ll make sure that the price paid for the pieces becomes a discount on the larger work for readers who want the whole thing eventually.
You can also pick which pieces you want. Some people want huge definitive books. Others want just the pieces that fit their particular focus. If you only need three pieces of CSS: The Definitive Guide, you’l be able to buy just those three pieces.
For the author
As an author, there are a number of immediate benefits to this approach, most of which are also reader benefits. The biggest advantages are two facets of the same thing, really: accuracy and agility.
As chapters are published, readers will catch those inevitable errors that creep into any human endeavor. As errata reports come in, corrections can be made and free updates pushed out to all readers. This means everyone benefits from the errata process, not just those who purchase the next edition (assuming there is one): those who already have the chapter ebooks and those who purchase the whole book, once it’s completed. What the latter readers will have is a book that has been almost entirely reviewed for errors. It’s crowdsourced technical review!
Obviously, this does not mean an author can or should slap together half-baked material and push it out for the readers to fix. That’s never a good idea. But we’re all human, and mistakes creep in. As an example, just as one of our first chapters was preparing for production, I (Eric Meyer) caught a glaring error that I had made and nobody had caught. It should have been screamingly obvious at every point, and my catching it before publication was honestly luck.
Let’s say I hadn’t, though. Likely several readers would have noticed and reported it right away. After the ritual head-desk pounding, we would have fixed the error and pushed a new version out to the world. Existing owners of the text would get the updated version at no extra charge, and future readers would get an already-improved text. It’s a win for everyone.
The other aspect, agility, is particularly important when writing about topics that are in flux. Instead of waiting (and waiting … and waiting …) for a language version to be frozen or some other arbitrary breakpoint, authors can write about the state of things in the moment and make corrections to deal with unexpected changes. If a method or value name or some other thing changes, updates can be made quickly — and, again, those changes will become part of the finished book. Those who buy The Whole Tome will have a text that’s as reasonably up-to-date as possible.
This also allows authors as well as publishers to have books out at the right time. Let’s say that you’re writing a book about the (sadly) hypothetical TeaScript 3.2. Instead of waiting for the language to hit its milestone before writing the book, you can write alongside the development of the language, updating the chapters as changes are made and errors are reported. When TeaScript finalizes, most if not all of the book will already be written. Publication can happen with weeks or even days of the language’s debut, making it far more timely and relevant.
Last but probably not least, if the chapters do at all well, then the revenue stream starts much earlier. Rather than a series of lump-sum milestone advances, payments come in as chapters are published and purchased. In effect, early chapters help bootstrap the rest of the writing — assuming, of course, that revenue comes in! We live in hope.
This model introduces challenges, of course. First is knowing when you have to go back and update content, though you hope readers will help in that effort. More interesting is how to deal with inter-chapter references. If you know you’re only producing a single book, it’s easy to reference a concept that will be explained in a later chapter, or to refer back to a concept explained in an earlier chapter. With standalone chapters, that’s much more difficult to do.
You can view such references as suggestive-sell techniques, of course. (“Hey, if you want to know more about this concept, buy something else from me! Did you want fries with that?”) Ideally, however, this will push the author to keep explanations and concepts simple and self-contained enough to stand on their own.
This isn’t always possible, obviously; in my own book, it’s almost impossible to avoid cross-references in the early stages because selectors and specificity are so interdependent and yet so different. We solved that by bundling the chapters on selectors and specificity into a single ebook. As other cases are encountered, we’ll figure out what to do. It’s entirely possible that some cases will end up with a reference to another ebook, whereas others will force a reworking of the text to eliminate the interdependency. We’ll see!
Color is another area that can be challenging. It’s simple enough to produce color figures, but some devices (such as E Ink readers) can’t display color, and paper printings may or may not be able to afford color. This requires the author and publisher to work together to figure out their color strategy. Author in color and let the chips fall where they may? Author in color and only convert to grayscale for certain channels while keeping color in others? Author in color and convert to grayscale in production? Author in grayscale and avoid the whole mess? The answers, as ever, will vary by circumstance.
For CSS:TDG4e, we’ve chosen to author in color and convert to grayscale only when needed. The hope is that by the time the entire book is done and ready to be printed, color printing will have become cheap enough to do for the whole book, or at least for the pages where it’s needed. If not, we can look to see what content needs to be adjusted for printing in grayscale, or if other approaches (such as referencing a URL that shows an example as intended) make more sense.
For the Publisher
O’Reilly sees many of the same advantages the author does — reaching an audience faster with easily updated content brings earlier revenue as well as improves our odds of keeping our readers happy. Ebooks make color and search easy and offer the promise of future features.
Internally, the shift to a serial fits well with O’Reilly’s growing emphasis on shorter and more focused pieces, solving more specific problems rather than trying to cover everything every audience might want to know about a given technology. We don’t have to give up on the general approach, since the pieces will combine nicely into a final book, but we can get a much clearer picture along the way of which components readers really want.
(We also have an early release model where readers get access to a book in development, but that model still assumes that they are buying a complete book, and doesn’t offer the option of pieces. Serialization makes reader preferences much more visible.)
There are some costs to this fragmentation, including slightly more work in metadata management, fulfillment, and marketing, all of which have costs. We haven’t yet figured out things like whether we’ll be able to keep the same copyeditor on a project over an extended set of pieces, so there may be more variation in the final product than before. I worry a bit about reader annoyance because print versions won’t update, of course, but hopefully telling this story should help.