The present (hyperlinking)
At the moment there are two typical approaches to hyperlinking indexes inside ebooks, the first is to mark each "page" as a it corresponds with the printed book (or PDF) and then link to these page markers from the index. The alternative is to link to specific paragraphs or even words.How the hashtag would work
An index built with JSON, and controlled with JavaScript and RegEx, could be built in a number of ways. This is because we could do a number of things. The first of which would be to have the indexer compile a list of words and then for these words to be searched for across the entire book when tapped, and for an in-place list of extracts returned.Spot the difference
This first method is little different from the reader typing a word in the search box, the difference being that the words are known to exist in the book and so the reader doesn't have to guess at them.Refining the search
The disadvantage of the first method is that the time taken to search a whole book might be too long and the reader might already know that they are interested in results from one chapter but not another.The reader could narrow the search based on chapter themselves, but I would suggest that the second method would be for the indexer to identify chapters in which the terms are held so that the search takes less time. Once again removing the user's hit and miss fumbling and providing quick access to content.
Note: Although I describe the user interaction here as "hit and miss fumbling", there is nothing to stop the addition of reader refinement to narrow (or expand) exploration of the indexed terms at any point.
How far is too far?
This narrowing could be reduced to a paragraph level and even a page level, but the advantage of such searches not reaching this level (unless necessary) would be that the indexing and proofing time can be reduced, along with the necessity of marking out pages.Allowing for fuzzy interpretation
Indexers sometimes label a concept, let's say fishing, and point to a page where the precise word isn't present but it is the topic being discussed. In these instances we need to add an invisible piece of notation to the text that our search can find.Is this really possible?
The whole process, to my mind, is much easier if the book is built entirely in JSON as outlined in A list of rules for a JSON book - a manifesto of sorts but as always there are ways and means of adaptation. In the earlier blogpost I give an example of a JSON index (see point 10), which is a very traditional echo of a book index and the type currently being used by ebooks where they have one. As discussed in this post that needn't be the actual case, but it is a starting point.What else?
An index such as this isn't just useful for inside a packaged ebook, the same thing could be used on the web and in any app that makes use of the content. The JSON format would make the process easy to implement and control.
This sounds like a good start.
ReplyDeleteBut what about additional levels of analysis? A good index is more than just a concordance, or one level of #headings. Can you give us multiple levels of tags?
Thank you for the comment, yes multiple levels of tags would be as simple as using sub-entries, like any regular index. It requires a bit of technical understanding but I outlined an index written in JSON in this previous post (see point 10) and when you look past the curly braces and square brackets what you actually have is something that looks incredibly similar to the book index we know today.
DeleteCool! with links instead of page numbers, 'live' indexing is here, it looks.
Delete--Thanks.
All the pieces of the puzzle exist to make this a reality on the web and in iBooks. They just need to be put together and turned into a compelling reader experience that can be trialled on full-length books.
Delete