Book as API


Get the short URL

Last week, Hugh McGuire and I spent some time at O’Reilly’s Tools Of Change conference talking about the future of the book. It was a lot of fun, and I think we managed to offend, terrify, and inspire at the same time. Hugh is the person behind Pressbooks, so he has a lot to say about the subject. I was mainly there for comic relief.

My basic thesis was that just as we didn’t know the killer feature of a camera was an Internet connection, so we don’t know the killer feature of a book is an Application Programming Interface.

I wrote up my speakers’ notes beforehand, and they’re included below. Here are the slides from the event.

A book has always been a hack.

Years ago, when I first started blogging regularly for GigaOm, I would write long, meandering, narrative pieces. Carolyn Pritchard, their ruthlessly efficient editor, called me out after one particularly long submission and said, “Alistair, the only good thing in this is the third paragraph. I want you to delete everything else, expand that, and submit it.”

She may have been more gentle in her actual words, but it didn’t feel that way. I licked my wounds, rewrote it, and sure enough, the post thrived.

Months later, after I’d been writing for a while, I said to Carolyn, “I think I understand the difference between journalism and storytelling. In a mystery novel, the last line of the book is ‘the butler did it.’ In a blog post, that’s the first line—and the rest of the post explains why.” I’d finally learned that content and narrative were distinct.

Content, structure, format

When you peel back the onion of a book, you realize that it’s really three things: the content; the structure; and the format. The content may be whatever you like: fiction or nonfiction; objective or subjective. The structure may vary widely—even in the era of only physical books, we have chronological order, alphabetical order, and other ways of accessing the content. But for centuries, the format was ink on wood pulp.

Because the format was fixed, the content and structure were locked in at the moment of printing—what Mathew Ingram has called the “false epiphany” of publishing. This has been terrible for two big reasons.

First, content is ever-changing. There’s always an update, a comment, a thread to follow, a typo to fix. Even a time-worn Homerian epic has new criticism, new insight, new illustrations, or a new Hollywood remake that’s somehow associated with it.

And second, the structure needs to adapt to how we’re using the content. The first time I read a book, I may want to view it as a narrative, revealed in the order the author intended it. The next time, I may want to view it as a timeline. Or from the eyes of different characters. Or as a glossary of terms. Or as waypoints on a map. Form, quite literally, should follow function.

Consider the following diagram, which looks at two dimensions of published content: fiction and nonfiction, subjective and objective. Depending on these four quadrants, audiences want to consume content differently.

Looking at books in two dimensions

Looking at books in two dimensions

But we can’t possibly build all forms of interaction for all content for all readers. That way madness lies.

SaaS beats the Gold Master

Software developers used to talk about a Gold Master. This was the final release, and anything you got wrong in it cast what Ben Einstein, co-founder of Bolt, a hardware startup incubator based in Boston, calls the Long Shadow. It represents the things you have to live with if you make a mistake in the final release. For hardware, this might be things like battery life, hardware power, or component failures. For software, it’s things like security vulnerabilities, or a broken update process, or lack of support for particular platforms.

Remember when we named software by year or version? That was fun.

Look at the changes that software has undergone in the past two decades. Once, software was installed on desktops, where it grew slowly moldy until someone updated it. That ended with the rise of Software as a Service. What version is Google Docs at? Freshbooks? You don’t know, because they’re publishing now. And now. And now.

Software-as-a-Service thrives largely because it’s far easier to administer and maintain a central application than it is to manage millions of installations.

Unfortunately, economies of scale still apply. A company like Salesforce has thousands of requests for new features, which it can’t possibly satisfy. It did something smart: it created an ecosystem that let others extend the platform. Salesforce’s App Exchange has tens of thousands of third-party tools that can extend the company’s CRM. Users get extra features; Salesforce doesn’t get distracted by niche demands.

Data, data everywhere

As a species, we’ve migrated from atoms to bits. Whatever the medium, we consume it digitally. The move to e-books is only part of a much bigger sea change, as we colonize a new world online.

What’s the most popular camera in the world? I’m not sure, but I’m willing to bet it’s actually a telephone. Flickr thinks so. Meanwhile, Kodak is out of business. We didn’t know that the killer feature for cameras was an Internet connection. But of course, it is: pictures are for sharing. Hindsight is easy.

Similarly, we didn’t know that hyperlinks were a natural part of books. It should have been obvious, because we’ve been stuffing books with footnotes since, well, the second book came along. There has never been a time in human history when we’ve created as much writing as today, because everyone is a publisher. We just have the wrong lenses: as Jeff Jarvis explains, traditional publishers “see content as a scarcity we produce and control. Facebook and Google … see content as an abundant resource to learn from, value and exploit.”

We’ve tried to wall our books off from the surrounding world by erecting castle walls around them. But that’s not how to add to the usefulness of a publication; increasingly, there’s more stuff about the book outside the book than there is within.

I’m asking you to grant me the following assumptions:

  • That a book is actually a convenient bundling of content, structure, and format.
  • That the format content takes needs to adapt to how it’s being used.
  • That the content of a book shifts constantly, and that the “publication date” is a false epiphany.
  • That the rising tide of Big Data means books that aren’t linked to the world are hermits, outcasts, shut-ins. 

If you’ll grant me these four assumptions—and many of you won’t, and I look forward to beers and/or angry 140-character ripostes as a result—then you have to agree that the future of a book is its interfaces: Specifically, the one between a book’s structure and its content.

This interface frees the content from false epiphany of publication: it can be updated constantly. It’ll have its own lifestream, beginning when the content was just a gleam in the author’s eye and continuing on every time someone updates a Wikipedia entry or writes some fan fiction. It plugs the book into the Big Data our quantified society is constantly generating.

This interface also frees others to build new interfaces the original producer didn’t have the time or ability to create. Just as third-party software helps SaaS companies tailor to niche markets and discover unexpected new ways of using them, so new structures allow us to understand content in ways we didn’t before.

The killer feature of the book is its API. Those that ignore this are Kodak; those that pay attention to it are Android.