The Humanities E-Book (HEB) project took 20 books (as scanned page images + uncorrected OCR) and converted them to an in-house XML format. They compared the workflow impact, costs and user experience of the final XML product versus that of the page-image ebooks.

Many of their findings consorted with my own experience in this area:

1. The quality of the OCRed text was worse than expected: good enough for search, but not always suitable for reading.  However, the cost of double-keying the text from scratch was prohibitive.
2. The encoding vendor, while skilled and diligent, nevertheless produced output that would require a trained editor to correct properly.  HEB spent 4-8 hours hand-correcting each book in the sample set.
3. The average cost for conversion to XML was approximately 3X greater than for scans + OCR only.  This did not include in-house correction and review.

User survey results

After the 20 sample books were made available to their community, users were polled for their reactions.  I feel these are worth mentioning at length.

69% of readers preferred the XML-encoded books (presented as HTML in a browser).

Reasons for preferring the XML scans included:

1. Readability (despite the fact that not all books were completely proofed)
2. Usability (e.g. cut and paste, ability to use screen readers)
3. Layout (the HTML presentation had few distracting elements on the pages, and more content was available per web page than in the page-based scans)

Interestingly, of those readers who preferred the image scans, one of the primary reasons cited was the more book-like paginated layout. I’m very conscious of this tension: many Bookworm users complain about the chapter-at-a-time, scrolling layout of the pages, while others absolutely hate arbitrary emulation of the printed work. It seems to be a strong personal preference that runs in one direction or the other.

Ebook interface considerations

Although not directly related to the study at hand, I found some of the publisher-imposed constraints on their user interface illustrative. I feel these would be best be avoided when designing an ebook reading site:

Foremost among user requests was a desire for better printing options. Printing of HEB titles has always been restricted to fair-use provisions, and for this reason there had neverbeen any immediate way of printing out pages without prior browser adjustment to
accommodate frames—the intention being to discourage printing out long sections of copyrighted text at once.

The ability to print text at length is critical for any serious work.  I’m always unhappy when a site prevents me from doing an ordinary task like printing or downloading.  I hope that publishers reconsider these types of restrictions.

Similarly, revenue models should not constrain the ways in which licensed users can access content:

XML titles normally suppress all higher-level “container” sections, so that users always access only the smallest available text chunk in each overarching section. [...]

…for this set of titles, we would simply make all section levels accessible.  This would affect the process of tallying hits for these titles—something needed in order to calculate royalties  for publishers and usage statistics for libraries—as users could now potentially read an entire book by accessing only a small number of chapter-level sections (which in turn would generate fewer hits than reading the page-image version).

As a reader, I should absolutely be able to read content — especially XML-based content — in as fluid a manner as possible.  Generating accurate accounting is a programming problem, and not one that should drive decisions about the reading interface.

Thanks to everyone who attended and especially to those who asked so many excellent questions.

To expand the project in useful ways I’d like to be able to add:

1. Other content types besides novels, especially reference
2. Content from other document formats, such as DocBook
3. Native, highly-tagged TEI documents

Wikipedia and its cohorts are by far the largest source of public domain data on the web now, but they aren’t encoded in XML. Publishers are unlikely to use wiki formatting to mark up their content and thus developing a workflow to convert from wiki to TEI doesn’t seem productive.

XML data welcome!