For the last few years, I have been trying to read a book: The Expedition of Humphry Clinker, and I keep failing. It is available on Project Gutenberg, so I never bought it. The problem is that I hate every ebook reader I use. After spending years complaining about the mediocrity of standard digital books, I have decided to put my code where my mouth is and start building them. Humphry Clinker is the first. Go try it. To me, it is the best reading experience for this book I’ve had yet (more on that later).

I will say little about the design, I believe it speaks for itself. The text of the novel is dominant, everything else serves your access to the content. When you switch to Explore Mode, two things change:

First, the table of contents at the bottom of each chapter becomes color coded by character:

Second, a similarly color-coded visualization of the table of contents appears at the right of the page (as well as the top of the Table of Contents page):

For those of us that have not read the book yet, this feels like peeking ahead. That’s the point. It gives a broader view of the structure of the book, you can see how the first two letters (chapters) foreshadow the bulk of the story. When we are reading a story for the first time, everything else should be out of the way. But when we have finished, are analyzing, or reading our favorite parts again, extra information can help clarify and deepen understanding.

Why the web?

So far ebooks have been a step back from print in almost every way: they often cost the same, require special tools to read, are harder to share, have inferior typography (the first person to create a lightweight TeX rendering engine will have my permanent adoration). Notes are like typing on index cards and sticking it in the pages rather than writing in the margins. Browsing across chapters requires memorizing digital page numbers that can change depending on window and text size.

By building the book as a web app, it is immediately interoperable with any device with a web browser. (Though I haven’t fully finished and tested it on mobile or tablets…anyone want to buy me an iPad for testing?) There is no need to own a specific device or download any app. It just works.

Interoperability isn’t the only reason to build the book as a website. My goal is to make the text as accessible as possible, so readers can interact with the text however they’d like. Social reading has much to gain from being on the Internet. Social networks based around books such as Goodreads and apps such as Readmill are letting us create beautiful communities around the books we read. Quoting and sharing passages from a book is far easier out of Readmill than most ebook readers, but social reading still has a long way to go. Many ebook readers don’t allow any way to easily share passages and annotations. To read books with Readmill, you must use an iPad and your books in certain ebook formats.

With metadata, we can programmatically offer new ways to analyze and interact with our books. And social reading can be deeply rewarding and fruitful, digital does that very well so we can make sharing of text from our books easier. This does not mean the ebook readers should be social networks, but we should make our books so people can explore, interact with, and share their discoveries. This prototype lacks some of the features I want in a book: There is no way to make notes or highlight the text. Nor is there an easy way to annotate the text with outside references and material, nor is there a way to sync across devices. This was partially intentional, I wanted to release this prototype early, and keep it simple. Adding notes would drastically increase complexity and slow the release (especially since I am actually a mediocre programmer). However, I have tried to include tools to help people share, analyze, and reuse the texts in more powerful ways through the API.

The API

[Permalink]

Just as user interfaces enable access to information by users, APIs enable access to information by programmers¹.

By building our books with an API, we let readers build their own tools to explore and remix the book however they wish. While the data in the API is still incomplete (specifically character and location data), we can already build interesting things from it. For instance, the table of contents visualizations in Explore mode use the chapters API. Readers do not have to be slave to our design decisions and can build their own tools to read, parse, and annotate the text as they wish. To make connections between our texts and others. When we make it easy for our readers to share our ideas they are more likely to be shared and read, and isn’t that the point?

Books are varied, so to are their layouts

Not all books are linear, yet we largely force linearity upon them. Digital mediums can free us from physical constraints of the printed page, yet so far the only way we’ve been freed is physical mass. Side-by-side translations are impossible in most ebook readers. Each book is different, and attempts to shoe-horn them all into the same format and layout are hacks².

My goal with Humphry Clinker is not to create the best digital book reading experience, but merely to create the best experience for this book. Other books would not benefit from the same the visualized table of contents. Footnote-heavy books would require more emphasis on annotations. Books set in other worlds would not benefit from geographic location data, or require their own maps. A child’s picture book requires special attention to the graphics, poetry sometimes requires specialized layouts. The goal is to build the best book for the content. That has always been the goal. We just temporarily forgot it in our rush to digitize everything.

Coming up

Humphry Clinker is the first prototype digital book I plan to republish out of A Yellow Raven. And I’ve already chosen the next book: Ludwig Wittgenstein’s Tractatus, with side-by-side translations, like it was intended. For now, I am concentrating on books that are already in the public domain or are open access.

I will be releasing the code for the Humphry Clinker server on Github over the weekend so anyone can download, run, and extend their own version of the book. I will also soon be releasing a framework ensemble based on what I have built here that anyone could, with a little bit of XSLT knowledge, publish their own digital books, with an API. I think will be especially powerful for academics who want to publish their research and data publicly more versatile forms than just files that require statistics software to use.

A call for help and a request for intrepid academics

I am not brilliant at code. While I can XSLT my way through a giant pile of XML, my php and javascript skills are mediocre at best. Also, I haven’t read this book before (I built this ebook so I could read it without tearing my eyes out). Many may notice that the API includes more data than the web interface provides, such as character and location data. I would love help filling stuff in from literature and 18^th-century English history dorks.

I want to see more academics publish their work openly and online. So I am looking for academics who want help publishing their research and data with an open API. Let me know what other public domain books you would like to see republished this way. Tweet or email with your ideas, suggestions, and thoughts. In the meantime, enjoy the story, I’m on chapter 20.