The Design and Construction of eBooks, by Steve Thomas

Design Principles

In progressing from an exploration to a real collection, I was aware of the need to set some standards and design principles.

The first was the choice of format. Obviously, the choice was HTML (and now XHTML), but there were alternatives available, and used for ebook collections at other sites: plain text, as used by Project Gutenberg; Adobe’s PDF (Portable Document Format); TeX, well established for technical papers; and SGML, a super-set of HTML. All of these formats have their advantages — for example, plain text is a clear winner in terms of accessibility. But HTML wins overall in being accessible and offering a great deal of flexibility in formatting, particularly when coupled with CSS (Cascading Style Sheets).

But a few more design principles were also required, and these are:

In summary, I wanted to maximise the readability and usability of the ebooks, to make them “just like a real book”.


The most important things to get right are legibility and readability. Legibility is straightforward: it refers to how easily one can recognise the glyphs that are used to form individual characters, so we need only to choose a typeface or font that is legible.

As an extreme example, compare

The quick brown fox jumped over the lazy dogs


The quick brown fox jumped over the lazy dogs

The first is Georgia, and the second Unifraktur Maguntia. To the extent that we find most legible that with which we are most familiar, the first is much to be preferred.

When I began the project, and until recently, choice of font was also constrained by the likely availability of different fonts on different platforms (operating systems). For example, Palatino is an attractive font, but it’s not generally provided on Windows, so it would be pointless choosing that font for our books. It was essential to choose a font that all or at least most users would have on their systems. Which led me to choose Georgia for the serif font, and Verdana for the sans-serif font. Happily, these are both attractive, highly legible fonts, both on the screen and when printed.

Recently, so-called Web fonts have become available and supported in all the major browsers. The fraktur font above is a web font, freely available from Google. Web fonts are used by including a little code in the header of the web page, plus some style sheet magic, making them available to all users without the user needing to do anything. The result of this is that we now have a much greater choice of fonts available to us when creating ebooks, as long as they are read through a browser. When transferring an ebook to an ereader (Kindle, iPad, etc.) any custom fonts are likely to be stripped out, and the text reduced to the ereader’s default.


Readability concerns how easily we recognise whole words, sentences, paragraphs, etc. Subjectively, we are looking for harmony and balance between the micro and macro elements of the book. After 500+ years of printing and publishing, we have some pretty clear ideas of what works and what should be avoided. Some key considerations here are: size, measure, leading, alignment, white space, and style.

  1. Size matters. Too small, and reading becomes uncomfortable, or the text illegible. Too large in comparison to the surrounding text, and it becomes a distraction.

    A crucial factor with size is the eye-sight of the reader. I can comfortably read 12pt text (with my reading glasses), but I know nothing about other potential readers. The only way to accommodate all readers, is to allow the reader to determine their own base font size, using their browser or ereader settings.

    The important thing then becomes the size relationship between different elements of the book: assuming the paragraph is 1em, then every other element (heading, footnote, etc.) is a proportion of that. So a heading size may be defined as 1.3em (or 130%), a footnote as 0.8em, and so on. By defining our sizes in terms of proportions rather than fixed point sizes, the ebook becomes scaleable: the reader can enlarge or reduce the text as they please, without losing the subtleties of proportion.

    An em is a unit of measurement equal to the currently specified point size. Historically, the unit was derived from the width of the capital “M” in the given typeface, but this no longer applies.

  2. Measure refers to the length of lines, and it has long been established that lines that are too long make reading more difficult. The eye has to scan rapidly from the end of one line to the start of the next, and the longer the line the longer it takes for the eye to do that, and the more likely it is that the eye will return to the wrong line.

    There is no hard and fast rule about measure, but a line length of between 45 and 75 characters is considered ideal, noting that in a proportional font, the characters have different widths. I have set a maximum width of 33em for body text. After much experimentation, this seems to be about right, and produces a similar result to many printed works.

  3. Leading refers to the spacing between lines (actually the height of the line from the baseline to the baseline of the line above). Without leading, text will appear cramped. Too much and the eyes will have to work too hard to scan the text. Here, leading is set at 140%.

  4. Alignment refers to how the lines are positioned relative to the margins: left, right, centered or justified.

    I have chosen to justify paragraph text, that is to have the spacing of each line adjusted so that all lines are aligned at both the left and right margins. There is no general agreement about how this affects readability. Some argue that the extra spacing that’s inserted to achieve this can be a distraction for the eye, therefore reducing comprehension. This can be true in extreme cases, but in my opinion the benefit or more readily identified blocks of text is worth the cost.

  5. Style refers here not to the style of the writer (humorous, serious, boring, etc.) but to the use of italic, bold and small caps, all useful in directing the reader’s attention to some distinguishing aspect of this portion of text which differs from the text around it.

  6. White space, above all else, is crucial to readability. Just as a sentence would be hard to decipher without the space between words, so to vertical space between elements of the page, margins, and indentation all assist the reader in discriminating between paragraphs, table elements, sections and so forth.

Usability issues

Attempting to replicate the print world on a computer screen presents a few challenges, as well as imposing a few constraints.

The Screen

The first problem is the width of the screen. Print books are generally taller than they are wide, while computer screens are generally the opposite (landscape). If the text was not to be spread across the entire width of the window, it had to be constrained. Initially, I used a table with a defined width, but this crude method was quickly superceded by the use of CSS, as noted above (Measure).

The second problem arises from the solution to the first. Having constrained the width of the page, the user is left with a lot of blank space on either side. On my screen, the page takes up about one third of the screen, leaving two thirds blank. By default, this blank space is white, which can create a significant problem of glare for the user, and screen glare is the main reason for users objecting to reading on the screen: it leads quickly to tired eyes or worse. The solution to this problem is to dim down the glare. Initially, I did this by changing the background color to gray, but later replaced the gray with a more interesting but still unobtrusive pattern.

But the glare problem persisted with the page being black text on a white background. Many people still find the white background to be too bright. So I’ve recently changed the style sheet to use an off-white background which reduces the glare. [The color is actually slightly yellow, to mimic old paper.]


Other usability issues are less easy or impossible to resolve:

The Page

The print world has been splitting a text into pages since the invention of the Codex. There’s nothing inherently superior about pages, they are only an artefact of the printing process: a printing press can only print so much at a time, and the reader finds it easier to hold a book with smaller pages. Similarly, books tend to present two pages of text at a time, left and right. Again this is simply an outcome of printing and binding a book made up of separate pages.

In the world of the web browser, there’s no simple way to mimic this page structure. A web “page” is a complete document, and the user can scroll the page up and down to view different parts. While it is possible to mimic the printed page in the browser, and even provide a two-page view, this cannot be done without sacrificing some other features. The text has to be split into separate pages, each of which must fit on the screen. The only way to ensure that they fit is to define precisely the size of the text, which then prevents the user from adjusting the font size if they wish.

People often tell me that they prefer turning pages to scrolling. But this is surely only a question of familiarity. Examined dispassionately, pages have a number of problems, not least of which is that they break the flow of the narrative or argument simply because we’ve reached the end of the page. How many times have I turned a page, only to turn back to remind myself of how the sentence began? And how many times, reading a novel, has my eye been tempted to stray across to the right hand page to see what’s coming, ruining the surprise the author had in store for me?

Overall, there’s no particular advantage of paging over scrolling, or vice versa. They’re just two solutions to the problem of presenting a work, each suited to a particular medium.


Another usability issue, often mentioned by opponents of ebooks, is the lack of page numbering. As above, this is more about familiarity than utility, since page numbers are irrelevant when there are no pages.

But there is one use case where this complaint has some merit, and that is with referencing. In the print realm, it is common to quote some text and then give a citation which includes the page number of the book. Without the page number, it would be tedious to have to locate the passage if one had to read through an entire chapter to find it. Of course, with a web page, you can simply search for the text on the page and the browser will find it for you, faster than you can turn to the cited page number in a book. But still, people prefer what they already know.

It is possible to add reference points to a work, so that the reader can both cite and locate a particular passage. But doing so has two costs: first, it adds to the overall size of the file; second, it takes more time for the editor (me) to do. So in the case of this collection at least, you will generally not find page numbers or reference points, other than those provided by the table of contents.


A final usability question concerns printing. In spite of the extensive effort I have gone to in order to make the work readable on the screen, there will always be people who want to print it. Well, it’s not my task to tell other people what they can and cannot do, so I have gone to some lengths also to make sure (again using CSS) that a work will look good in print as well as on the screen. The result will not, of course, look quite as polished as a regular published edition. Printing from a browser lacks some of the refinements of print publishing software, such as hyphenation and management of widows and orphans. But the result will do for general purposes.


I made a conscious design decision that the books would be new editions, rather than trying to replicate existing print editions. There were two reasons for this:

  1. The plain text files I started with typically made no reference to which print edition was used. [Where they did, I have retained that information in the title verso and/or the metadata.]

  2. The task of exact replication of a print edition lies somewhere between hard and impossible, for any but the simplest works. It’s true that most novels have a simple structure involving not much more than division into chapters. But if there any embellishments, such as illustrations, ornaments, special typography, and footnotes and endnotes, then trying to replicate the look and feel of a print edition becomes an exercise in rapidly dimishing returns. It’s rarely worth the effort, and the result is rarely satisfactory.*

    * For an extreme example, see Tennyson’s Lady Clare, in which the text and images are each wrapped around the other in intimate embrace. It is possible with a great deal of fiddling with positions to achieve a result similar to the original — at least until the reader decides to change the font or font size, at which point it all falls apart.

    I have already discussed above the usability issues with pagination. Trying to replicate this in an ebook is actually counter-productive, because (as with paper) it breaks the flow of the text artificially. The printer has no choice but to do this, but on the web our page is of infinite size, so breaking up the text is unnecessary.

So you should consider* the books in this collection to be distinct, new editions, designed and crafted for the web, rather than being facsimiles of existing paper editions†. Hence the pains I have taken with the title page and verso.

* Most people seem to have trouble with this concept. I once had a discussion with the Open Library people about adding catalogue records for my books to their collection. Things were going well, and I sent them a sample of records, whereupon they asked, “and which edition is this, there’s no mention in the catalogue record?” I carefully explained my position that these were new editions, after which they went quiet and I haven’t heard from them since!

† There are a few works that attempt to reproduce some aspects of a print edition. See for example The Happy Prince, by Oscar Wilde, where the placement of the illustrations was of some importance, and therefore worth the extra effort.

Semantic Structure

The markup (HTML) applied to a book is important for managing the presentation, but it is also important in defining the semantic structure of the work. This means that the structural elements applied, rather than simply dividing components of the work, actually have a meaning that can be identified by some agent (a text analysis program for example). This requires not just identification of chapters and headings (the gross components) but also the fine details. So for example, if a piece of text is a telegram, it is identified as such. A researcher would love for this to be as detailed as possible, but in practice I have tended to limit myself to identifying structures for presentation purposes.

In some cases this semantic structure derives directly from the HTML tag used. E.g. in this code fragment:

<cite>Lewis Carroll</cite>

the cite tag indicates that the content of the tag is a citation, in this case the author Lewis Carroll.

Notice that this says nothing about the appearance of a citation (how it should be presented). It only says “this is a citation”. Any presentation we might want will be applied by our style sheet.

Commonly used semantic HTML tags are em and strong for emphasis, address, code, div and most commonly p.

The p tag is semantic because it says “this is a paragraph”, and div is semantic because it says “this is a distinct part of the text” (which may be a chapter, a letter or a quotation). On its own, a div tag is not terribly instructive, but by adding a class attribute* we can refine the meaning to make it as useful as required, for example:

<div class="telegram">

can be used to specify that the enclosed block represents a telegram.

So, the design rules I have adopted for structure are these:

  1. minimal subset of HTML, using only semantic tags (p, div, span, em.);

  2. use of class names to define structural elements;

* Note that there are no generally agreed class names for the different parts of a book, but I believe I have chosen names that make sense and are commonly used in the print world.

Last updated Tuesday, January 26, 2016 at 23:27