I have been reading ebooks on portable devices since I got my first Palm PDA way back in the 1990s. More recently, I have been using O’Reilly’s excellent Safari book service to read a huge number of technical books online whenever I need them.
As great as it is to be able to read books “on demand”, there are some problems with current book readers - and the formating of the ebooks themselves - that make reading them a clumsy business, nothing like the experience with a paper book.
Can we make an ebook reader that makes good use of the technology on which it is built, without causing unnecessary pain?
In this article, I describe the way that I think technical ebooks should work, and discuss some of the markup challenges this entails.
Ebook novels are generally fine, as they have a linear narrative; barring huge plot twists, there is little need to keep flicking back to previous pages. Technical books, however, can be quite unpleasant to read in electronic form. It is frequently necessary to refer back to diagrams or tables on previous pages. If an example diagram is being used for a whole chapter, by the end you can find yourself having to page back twenty or thirty pages in order to see the diagram. Sure, you can generally set up some bookmarks to allow you to flip between pages, but this is an awkwardness that you don’t want to be bothered with when reading a book. The reading experience should be as transparent as possible, so you don’t have to think about what you’re doing (just as you don’t have to think about turning pages in a paper book).
The first step is to realise that an ebook reader - whether a portable or a desktop computer - does not have to follow the paper book format slavishly. There is no need to pre-format pages so that they fit on a specified size piece of paper. Electronic page layout is fluid, and can be dynamically rearranged as the need arises when the page is rendered. (If you’ve ever tried to read PDF documentation on screen, you’ve probably encountered this cross-paradigm ugliness.)
As an extension of this point, we can also see that certain aspects of paper book layout are due to the nature of the medium. For example, diagrams are generally embedded within the text; even if the diagram is on a page of its own, it does interrupt the text merely by its presence. We don’t generally put all the diagrams and tables at the end of the book, because it would make it harder to refer to them in the appropriate context.
What we want is to keep all the diagrams, tables, equations etc. to hand that are relevant to the current displayed text. One way to manage this is to divide the reading pane into two pieces. One part is the normal text pane. The other is the ‘reference’ pane.
As you page through the book, the text pane behaves the way we are used to. The pane refreshes with each new page of text. The reference pane, however, is a dynamic ‘booklet’ of its own, consisting of all the references that are currently relevant. For example, if figures 1, 2 and 3 as well as table 2 are currently relevant, then the reference pane will consist of four pages. The page navigation will allow you to flip quickly between any of these references.
Say you page down in the text pane a couple of times, and get to a point where figure 2 is no longer relevant. Now the reference pane consists of only three pages: figures 1 and 3, and table 1. Figure 2 has dropped out. If you page up a couple of times again, then figure 2 will reappear in the reference pane pages.
So now you don’t have to manage the references yourself. You don’t have to think about anything. The book reader is handling it for you in a nice transparent way. If the text says “refer to figure 1″, and you happen to have figure 3 loaded in the reference pane, you simply page back and figure 1 will appear.
In order for the book reader to know which items to make available in the reference pane, there clearly needs to be some markup in the text. A simple HTML style markup seems the obvious solution, but we can’t use spanning tags because we won’t necessarily have a neat tree structure. In our example above, we finished with figure 2 before we finished with figure 1. In pseudo-markup with spanning tags, we’d get this
<figure:1> Dogs are hairy <figure:2> Sheep are woolly </figure:1> Monkeys are cheeky </figure:2> Whales are wet
Closing the <figure:1> tag before the <figure:2> tag is a no-no.
Instead, we need to switch the references on and off using a markup that allows us to do this whenever we choose. Something like this:
<figure:1=on/> Dogs are hairy <figure:2=on/> Sheep are woolly <figure:1=off/> Monkeys are cheeky <figure:2=off/> Whales are wet
Only self-closing tags are used here, so we don’t have any overlapping tags. The book reader software will have to keep track of which references are still ‘on’ at any point in the text.
I haven’t described here how this will actually appear on-screen, and I’ve done this deliberately. In the best spirit of “separation of concerns”, the exact presentation mechanism is an implementation decision. Having said that, I can think of a couple of ways the interface might be handled gracefully. A landscape screen could have the reference pane on the left, with the text pane on the right. Independent page navigation controls would be provided for each pane. (And the controls for the reference pane would be a lot simpler than those for the text pane.)
Another possible format is to have a portrait screen. The reference pane would appear only when there actually is some reference material. The text pane would be dynamically sized - either automatically, depending on the size of the item in the reference pane, or manually. Although the text pane would be much smaller than the amount of text that is normally visible at one time, it probably wouldn’t cause a problem. Any relevant equations or diagrams would be displayed in the reference pane without interrupting the text. So paging up and down in the text pane would not be unpleasant.
It would not be too hard to implement this scheme on a web-based book reader. A little bit of markup in the text is required, that’s all. It would be fascinating to see how much this improves the ebook experience. If it’s successful, then it could be rolled out to portable devices.
