A funny thing happened while Inkling was trying to redefine the eBook: we found that we also had to redefine publishing. If it takes a tremendous amount of energy, money, and time to produce a single next generation eBook, no one will do it. Is it possible to create tools and processes that can scale publishing these kinds of eBooks? Can we rethink eBook publishing itself?

The Inkling Habitat team, the browser-based publishing software I've been building the last three years, has explored many different avenues towards scaling next generation eBook production. We've explored everything from treating books as software to deeply building distributed collaboration into the authoring and proofing process itself. The Inkling Habitat team has explored some radical directions; some have panned out, others have not. I'm going to explore some of the things we've done in this space over a few blog posts here.

One of Inkling's challenges has been converting the huge back catalog of existing books into high-quality next generation eBooks marked up in HTML5. This includes textbooks, cook books, etc. Sometimes we've worked with vendors such as Aptara and Innodata to aid this process.

The process of converting these books into high-quality HTML5 eBooks has roughly followed the following steps:

First, a domain expert in education or the material in question designs a content architecture appropriate to restructuring this material once it becomes digital. Then, this architecture is turned into a small number of content specifications that basically provide examples and detail on how to convert the different parts of the traditional book into its digital equivalent. For example, this might include specifications on turning sidebars in a physical book into independent Inkling reader cards; how to break up the pieces of a chapter into independent Inkling cards; standard ways of dealing with figures in the new digital book; etc.

These specifications are then used as documentation and examples for core conversion, which means the entire bulk of the traditional book is converted into high-quality HTML5. Think of content architecture and content specifications as the blueprints, while core conversion is the actual construction of a building according to those blueprints.

Next, once the bulk of the traditional book material is transformed into HTML5, enhancements can be produced. This might include interactive quizzes, images that allow you to test yourself, video, audio, widgets, or more.

Finally, proofing happens to ensure that all of the content was core converted correctly and that the architecture and specifications were followed.

All of these steps are incredibly non-trivial for the deep body of content that is out there. For example, this Concise Textbook of Clinical Psychiatry on Inkling has fifty-three chapters! Come up with a bad process that is too expensive and you go out of business; come up with a process that has low quality and you've produced eBooks that are no better then PDFs or ten dollar text files.

The history of Inkling and Inkling Habitat has been hitting bottlenecks at each of these steps and trying to come up with answers to move beyond these bottlenecks. For example, the first bottleneck we hit was proofing, and our answer was to treat books as software. There have been many other bottlenecks and interesting answers to these bottlenecks.

Next week I'll explore one of these bottlenecks, the content specification step, and one of the answers we threw at it, involving radically smart templates.

Subscribe to my RSS feed and follow me on Twitter to stay up to date on new posts.

Please note that this is my personal blog — the views expressed on these pages are mine alone and not those of my employer.