Reference vs. Learning: pick ONE

Reference vs. Learning: pick ONE


The biggest problem with many tech books (and tech training) is indecision. When the author can't decide between creating a reference or learning book, they often try to do both. That rarely works. So the second most important question to answer when you start to write a tech book (or a book proposal), instructional manual, or training course is what's my goal?

And the most important question is, "what's the reader's goal?"

When a non-fiction book (especially a tech book) doesn't sell, or a training course isn't successful, it's often because the reader was on one end of the graph while the writer/course developer was on the other. Or because the author/teacher believed that giving information was the way to communicate knowledge and understanding.

The difference between facts and information is straightforward: information organizes facts into a meaningful pattern. Without information, data and facts can be arbitrary and useless. There's a crucial place for reference information, and information architecture is art + science. (Two info architect bloggers are Louis Rosenfield and Jesse James Garrett, both who've written books.) Turning facts and data into meaningful information is--for a lot of books, websites, and manuals--often the destination. The thing the users want.

The big problems happen when the user wants and needs knowledge and understanding but gets only information. If information is a meaningful, useful organization of fact and data, understanding is about knowing how--and more importantly why--to apply that information to do something creative.

Look at the tech books on your shelf. Chances are, more than a few of them exemplify what Prentice-Hall editor Greg Doench refers to as one of the seven deadly sins of computer book authors: greed. He calls it greed because he reckons it's the author's way of trying to capture the largest possible market for the book. He spots this most often in book proposals by first-time authors, he claims, when they make statements like "this book is for everyone from beginners to advanced users" and "after they learn from it, they'll use it again and again as a reference."

I don't think it's actually greed, of course. Often the authors don't have enough user data on what readers do want, so they're trying to be safe and do both. Or they're trying to make a book that simply is more helpful because it does offer both information and understanding. It's so tempting to try to offer something to readers where they need buy only one book that both teaches and is a reference-- it sounds so user-friendly. But it's nearly impossible to do well.

Our advice to our authors is: "You MUST choose one, and you must commit body and soul and keyboard to doing that one single thing--either reference (data and information) or learning (knowledge and understanding), while letting go of the other. Accept that you can't meet both goals, and that most of your readers don't have both goals, and figure out the best way to satisfy that one goal."

How do you decide which to choose from? Only your users can tell you. There is an interesting trend that might help, though--early adopters tend to need the least amount of hand-holding, and not only can but want to jump in armed only with a reference and a few tips. You just point them in the right direction, give them the information, and they're running. It's these early adopters that will help define the kinds of user stories that those of who write about more mature technologies will use to teach for knowledge and understanding.

Tim O'Reilly has been giving a talk on What Book Sales Tell Us About the State of the Tech Industry, and O'Reilly's extensive data crunching (for all publishers, not just O'Reilly Media) has consistently found that when a technology is fairly new, the bestselling books on the topic tend to be more advanced, less step-by-step learning. But as the technology evolves, the balance shifts and the bestsellers are the beginning books while the advanced books start to drop off. This isn't completely intuitive unless you think about who the early adopters are. So for example, the bestselling Java book today is a beginner book, and the best selling C++ books are also focused more on beginners, where a few years ago, the bestselling Java books were advanced reference books, not "learning experiences."

This table shows a few of the key differences between Reference and Learning, and explains why we (my co-authors and I) believe so strongly in picking only one side of the table.



Actively trying to do both means you'll probably do both mediocre at best, and today there's not enough tech book business (down to 1/10th of what it was in the bubble) to support anything but the books that know and meet their goal. Obviously there are places on the venn diagram that overlap; I can't conceive of a learning book that does not offer facts and information, and a great reference book does provide learning by using an information architecture that makes the knowledge and understanding explicit. Some of the best reference books organize the data in a way that offers not just meaning but a revelation... a higher pattern I wouldn't otherwise have seen without that organization. And those higher level patterns and revelations are memorable, just as a well-crafted learning experience.

The other big thing I'm not addressing here is that there are a lot of subgenres in each of those categories. It's not just a matter of a straight dictionary-style reference book vs. a fist-time-beginner learning book. You have tutorials, cookbooks, hacks, hands-on expert walk-throughs, nutshell books, and "missing manuals". Many of these have at least some element of each side of the learning vs. refererence table. But the point isn't about avoiding the other side of the table--it's about having only one thing as your ultimate goal, and then putting in only what supports that goal. It's about choosing NOT to include things if those things are there simply to try to satisfy both sides of the table (i.e. to be "greedy").

Footnote: when I mention the "greed" thing, it's from a great talk Greg gave at JavaOne on how to make a bestselling computer book. His slides aren't online anywhere, but he's given me permission to reproduce some of it on this blog, so I'll be putting that up soon. It's especially helpful to those who want to propose a book to a tech publisher (today's tip: do NOT put "this book is for both beginning and advanced users" in your proposal) ; )