============
Index format
============
Here's an example of an index entry with both general page references and three subentries:
Carroll, Lewis, 40-50, 66
Alice's Adventures in Wonderland, 5, 24, 334
childhood, 12-17
Through the Looking-Glass, 23, 103, 334In print, an index is page-based: it cites each page or page-range that contains one or more occurrences of an indexed term (or discussion of the topic to which the term refers even if the term itself doesn't appear). When I'm researching something in a book, I'll typically go to the index to look up the term, and then -- saving my place in the index with a finger so I can flip back & forth for multiple lookups -- to each of the target pages to eyeball-search for the topic. This model works, not perfectly but well enough, because a paper page is a relatively short chunk of text to scan.
For the web I need to use a different model. First of all, I'm thinking that paper pages won't translate to HTML pages. Hard pagination every N lines doesn't work well in HTML unless the font-size is fixed, and I want to leave the text resizable to be accessible. When the reader resizes the text, hard page-breaks that fall in mid-sentence cause pages to end awkwardly in mid-line, while paginating only on paragraph breaks creates pages of uneven lengths making for ugly printout. Therefore I'm tempted to paginate the book only at the end of each chapter. This might require the reader to scroll down through each chapter which can tire the eyes, but it lends itself well to printing.
Without normal paper-style pages, how does an index work?
- Lacking page numbers, one could use the standard index format but refer to chapter numbers instead. However, a chapter seems too large and not specific enough a location.
- Readers can search for specific instances of a term using their browser controls, however that doesn't work when a term might appear in a variety of forms ("Lewis Carroll" | "Lewis" | "Carroll" | "Carroll, L." | "her son" | "Dear L.," | etc.).
- One could refer instead to the paragraph that contains the indexed term. A paragraph is just right, but brings up the problem of how to number paragraphs in a cosmetically acceptable and non-intrusive way.
- In hypertext, displayable location numbers can be considered irrelevant. The linking between words in text and index entries is subtextual (href=""), providing other visible/audible cues to the reader: words in text can be styled typically to indicate that they're hyperlinks and index entries can provide some other hyperlinked symbol to represent each instance: a graphic symbol or an instance number:
Carroll, Lewis, LINK, LINK
Alice's Adventures in Wonderland, LINK, LINK, LINK
childhood <--(itself a link)
Through the Looking-Glass, LINK, LINK
or:
Carroll, Lewis, 1-7, 8
Alice's Adventures in Wonderland, 9, 13, 17
childhood, 10-12
Through the Looking-Glass, 14, 15, 16In this latter model, does a range of instance numbers work for the reader in the same way as a range of page numbers?
===================== Index user interface: ===================== The user interface for an index could be implemented in a variety of ways:
- Place text and index on separate pages, and merely hyperlink between them, using local #anchors to position the selected text in the viewport. The anchor for a word in text could be located at the term itself, so it appears on the first line of the viewport, or at the beginning of the current paragraph.
- When a word in text is clicked, bring up the index entries for that term in a pop-up window. This is an unhappy solution with respect to accessibility & advertising-suppression preferences.
- When a word in text is clicked, bring up a faux window (an absolutely-positioned div) overlaying the text that contains the index entries for that term -- similar to the context-menu one might invoke by right-clicking on a link. This requires javascript, so a robust fall-back system should work in the absence of client-side scripting.
- Keep an empty sidebar for display of index entries, footnotes, etc. when linked text is clicked. Ditto above re JavaScript.
- Enable the user to highlight (and de-highlight) all instances of an indexed term in the text -- similar to Google PDF-to-HTML result pages. If all instances of each term are assigned a unique class name in the markup, toggling such highlighting would be easy using CSS & a touch of javascript.
==========
End-notes:
==========
A problem related to indexing, but simpler, is that of end-notes or footnotes. Typically in print a footnote appears at the bottom of the current page, whereas end-notes are clustered at the end of a chapter or the book.
TEXT:
That year Carroll wrote Through the Looking-Glass.[5]END-NOTE:
[5] The full title of the book was Through the Looking-Glass and What Alice Found There.
Hyperlinking between the end-note reference in the text and the end-note itself is simple. Any of the user interface solutions mentioned above can be applied:
- Hyperlink between the page of text and the page of end-notes.
- Cause the end-note to appear in a "window" or a sidebar when its reference is clicked.
Client-side scripting, if applied, would need to gracefully degrade to server-side scripting if disabled, and shouldn't interfere with the functionality of the book with non-visual user-agents.
Comments?
Paul
****************************************************** The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
