E-Publishing with Readerworks: Helping Students Ditch Their Bookbags

Go to previous version

If one thing was abundantly clear to me when I made my annual pilgrimage to Fall Comdex [What does this stand for?] this year, it was the accelerating importance of handheld devices. There appears to be a literal explosion of device styles, peripherals, and applications for these units. IBM (2000) describes the market for handheld devices best:

The demand for anywhere, anytime access is pushing Internet access away from the PC and into a variety of mobile devices. Devices such as the telephone, home appliance, automobile or PDA will supplant the desktop for information access as customers are no longer content with waiting to get to a PC for information retrieval.

Since I seem to have such a problem with eye strain after staring at a computer screen all day, I was skeptical about using a handheld device for my primary information management tool. So I stopped by the Microsoft Solutions Pavilion and explored the latest release of the Microsoft Reader with Clear Type technology, recommended as the text-viewing application of choice for units using Microsoft's Windows CE or Pocket PC operating systems. (Note: There is no version of Reader for devices using the Palm OS like the 3Com Palm Pilot or the Handspring Visor). The software was demonstrated to me on an HP Jornada Pocket PC, and I found the text quite readable. I was also shown a new free plug-in for Microsoft Word 2000 (also available in a Pocket PC version) that allows me to save any word document as an "e-book" in Reader format.  

From a user's perspective, the Reader software not only provides a near-paper reading experience, but also it lets users annotate, search, bookmark, highlight, and index quotations. When used with the freely provided Encarta dictionary, a reader can also easily look up a definition simply by right-clicking and selecting "Lookup" from the pop-up menu [Should this be replaced with "drop-down"?]. 

From an author's perspective, the format produces a compiled file that cannot be reverse-engineered easily and protects such content objects as images from appropriation by a simple right-click like a Web page [I'm not sure what this means--this sentence's wording is a little confusing. It might help to break it down into two sentences that contain a little more explanation.]. As I considered the potential for publishing electronic text books, normally very expensive because of the limited market and typically small press runs, I became more excited about the software's authoring potential than I was initially about its use as an application. [I suggest "the software's authoring potential than its applications." Does this distort the meaning?]  

Naturally, when I returned home I wanted to try it out for myself. Although I don't currently have a Pocket PC, I downloaded the free Reader software, the free Encarta Dictionary file, and the free plug-in for Word 2000 to my full-sized Windows PC. I had no problem converting a simple text-based Word document to an e-book using the Word toolbar plug-in. But I wondered how commercial e-books displayed a custom cover image and title page and how successful a conversion of more sophisticated work with images would be.

I noticed that the Reader Guidebook refers to commercial publishing software produced by Readerworks, so I visited its Web site. I discovered that the company's commercial product not only allows specification of cover images, but also it allows library thumbnails and specially sized graphics for Pocket PC reader displays. The software also incorporates a Table of Contents Wizard which automatically creates links to sections in a document with heading sizes of at least 3. Additionally, it accommodates specification of a book's bibliographic information, including author, publisher, time period covered by content, illustrator, translator, etc., that allows readers to easily locate the e-book in a collection or e-library.

I also noticed that the company offers a free copy of its commercial Publisher version to educators who state in their application for the product that they intend to use it to produce educational materials. I applied for this version and was approved within minutes, so I downloaded it and began to explore its functionality.

I discovered that Readerworks can build an e-book from either a list of text or html files (one can specify which one by browsing under the "Source Files" object). I also quickly learned that all files for a particular e-book project need to be stored in the same folder. For example, if I were creating an e-book about Julius Caesar, I would create a folder called "Caesar," put all text and image files associated with the e-book into it, and save the Readerworks project file into that folder as well.

Readerworks also specifies the image sizes needed for the different cover pages and image file formats, .jpg, .gif, or .png. Individual Image files can be included in a source file list and placed automatically on a separate page. 

Since we are still constrained by bandwidth speed at this time, I downloaded Microsoft's Source Materials and Conversions handbook and Layout Guide (both available in Word or Reader format) for more specific guidelines as to image size and maximum number of images recommended for an e-book. These reference documents are written with the assumption that users are hand-coding HTML documents for conversion to Reader format. Since most of this work is done automatically by the Readerworks Publisher software, I didn't study the guides too closely. However, I did notice some important considerations for all users, even ones depending on the Readerworks software to perform the conversion:

• Even though the conversion references suggest creating a separate file for each chapter, the Reader software's search function can search within only one file at a time. With this in mind, I suggest that the body of the work be composed as a single document with embedded images and appropriately sized subheads (at least Heading size 3) to provide sequential links in the Table of Contents. 

 

 

• Since Reader automatically sizes content for a wide range of display sizes, images may be distorted if they are radically resized. Therefore, users should size images for small displays. By experimentation, I found that headshots of a person are usually quite adequate at a size of only 2 inches high. This would not suffer resizing even on Jornada's 2.9 inches by 2.1 inches display. Additionally, consider cropping more complex images to avoid loss of detail, e.g.,:

• Captions are also problematic. The Readerworks software does not presently have a caption attribute feature (so I suggested it to them). This means that captions must be included in the images themselves (another reason to avoid resizing wherever possible). The layout guide suggests font sizes of no less than 10 point. Since a detailed caption for a very small image can easily exceed the depth of the image, a figure designation with a short title may work best. Then the author may elaborate on the caption in a separate illustrations list at the end of the book. A single 10 point line of text could be added to a 2" image by adding only about 20 pixels to the depth:

 

 

• At this time, the guides recommend that an e-book should contain no more than 10 large images or 20 small images (although small is not specifically defined) because of the download time required with the current average modem speeds.
• The current version of Reader cannot interpret dynamic data of any kind, so avoid animated .gifs, java applets, or scripts. Transparent .gifs do not render properly as cover images either, so they should be avoided. At this point, think of the early days of Web page design; think text and images only.
• The current version of Reader does not render tables and graphs adequately either. If it's necessary to include a detailed table, consider creating it in Word, saving it as an Adobe Acrobat .pdf document, and then using the graphics tool in Acrobat or Acrobat Reader to "harvest" the image. This is accomplished by opening the .pdf document with Acrobat, selecting the table with the graphic selection tool, copying the selected portion to a workstation’s clipboard, and then pasting the clipboard contents into a new image document (Photoshop, Paint, etc.). I found that this method produces a much crisper image than using even a high-resolution scanner to scan the same table or graph from a hard copy.