an index adds significant value to a book.
even an e-book, where — some will try to say — the “search” capability is a suitable replacement. it’s not, not really, for reasons we’ll discuss later.
an index is a good thing. it makes a better book.
the problem is that a professional indexer charges anywhere from $50 to $200 per hour, and a book can take anywhere from 20 to 150 hours to index, so an index might run you from $1,000 to $30,000.
clearly this is a hefty sum, so it becomes a matter of a delicate counterbalancing of the costs and benefits.
fortunately, you now have the computer to help you.
so even if you decide to hire a professional indexer, perhaps you can give them a substantial head-start, using an indexing app, and thus decrease your cost.
and, if the indexing tool is good enough, perhaps you can even forego a need for that professional.
although i should quickly add that, if you need an index for your book, you probably also have a requirement for the expertise a professional brings.
on the other hand, if the index is just a little “bonus” for your readers, and not something they’ll “expect”, you can probably get away with an amateur-built index, provided that your indexing tool is sufficiently adequate.
so let’s examine some of the things such a tool will need.
***
and, to guide us in that, let’s reflect first on the special requirements of an index in the age of electronic-books.
we think of an index as pointers to locations in a book, where certain people, places, or “things” are discussed.
but, in doing so, we skip over the most important part. because an index is, first and foremost, a list of those people, places, and things. it is a summary of the book.
the index is an x-ray revealing the contents of the book.
thus the first reason why “search” can’t replace an index: the readers do not know what they should search for!
how can we search for the names of the people in the book unless we have an idea what people the book talks about?
and how do we search for concepts if we don’t have a list? or we don’t know the jargon the author used for concepts?
a professional indexer will know the full panoply of terms that are commonly used to describe a particular concept, and will generate the suite of “see also” entries required.
an index tells us the people, places, and topics in the book.
this is the stuff which a quick perusal of the index gives us.
and yes, an index then points us to the relevant locations. which is terrifically useful.
but, even more, it points us to the most relevant ones.
whereas a simple search summons every single instance of a term, including ones where it’s mentioned in passing (this being the second reason why “search” is insufficient), an index points us to the most meaty of all the locations, and disregards relatively trivial ones, making us efficient.
finally, when the discussion of a certain concept overflows one page, and continues to another one (or two or three), the index tells us that too, so we know we need to go on. searching for a keyword won’t inform us of that situation.
***
but we can’t moan too much about the search capability. for all of its shortcomings, it still has a cost-benefit ratio which is superb, considering that it costs us nothing.
indeed, leveraging the search capability is probably the first functionality we want to build into an indexing app.
***
further, shortcomings exist in the other direction, too. the paper-book index is an admirable thing, to be sure, but it runs into some “issues” when applied to e-books.
in digitizing paper-books, for instance, information on the page-breaks and page-numbers is often discarded. (the thinking is that “pages do not exist in e-books”.) but this is very unfortunate, since if they are retained, page-numbers can be used as anchors for index-links. an e-index can be generated quite easily where the page-numbers in the e-index link to those anchors.
for instance, you have an anchor located at page 87; so when the index has an entry that points to page 87, you simply link that entry-page-number to the anchor. note this work doesn’t even need to be done manually, which would be too tiresome; it can easily be scripted.
this procedure is prone to glitches, however, because there’s no guarantee that the anchor for page 87 will be presented on the same screen as the text to which the index-entry was originally pointed. with font-size changes and different-sized screens, that text might now be on the following screen, or even way after it. so these after-the-paper-fact digitized links are “approximate”. the links can be made more accurate, of course, but that is manual work, and there is often no budget.
***
in a born-digital e-book, however, we can make links accurate from the get-go. but first we need to decide just how accurate we want them to be, because that can be an issue that impacts the cost of this process.
one question is whether we link to a “point” location — the most typical type of link in the digital sphere — or a “range”, taking into account that an index-entry might often point to a range of pages, such as 88–92. if we decide on a range, how can we accomplish that?
yet another complication is that, if we link to a point, the typical behavior is to position it at the very top of the screen, which fails to give any preceding context.
i think that an index-entry should link to the top of the paragraph containing its pertinent text-content. this is generally specific enough that it’s meaningful, and yet still broad enough to give sufficient context.
for the e-book ecosystem which i have programmed, i auto-code a link for each paragraph, which i believe is a good compromise for the issues discussed so far.
so, since every paragraph has a link-anchor anyway, i would just use the existing anchor for index entries.
and when an entry applies to consecutive paragraphs, that can be noted too. so i think this is a good solution.
at the same time, in addition, this gives us a hint on how we can actually make an e-index better than a print-book index, because — for instance — we can highlight the exact specific text-range for an entry.
(the term “highlight” calls to mind a bright backcolor, but it could be a much less obtrusive gray underline.)
so the link would jump to the start of the paragraph, and then the exact text therein would be highlighted.
so rather than the hand-wave aspect of a print index, which points to a page saying “it’s somewhere there”, the e-index jumps to the paragraph to give context, and then highlights the text so you can see it exactly.
***
and this introduces another idea whereby an e-index might be even more informative than a p-book index.
i would suggest a person could have the highlighting be displayed while they’re actually reading the book, with the index-entry being shown in the right margin.
the person could do this for specific terms, or for all.
in this way, an index would serve as “an active guide” to the book while you are in the process of reading it.
***
so, given all these thoughts, on the old and the new, how should we design a tool to help build an index?
first, i think our tool should get all words in the book, discard common (and thus fairly meaningless) ones (especially words like “and” and “the”, for instance), and show a draft list of the people, places, and things contained within, so we can prune that appropriately.
for instance, here’s a list of terms that might be suggested for this article:
after that pruning, the tool should create a “first draft” of the index, doing a simple search of each paragraph.
it’d then step us through the book paragraph-by-paragraph, allowing us add more-sophisticated items to the index—anything from “anarchy ants” to “zesty zebras”, you-name-it—marking the exact text to be highlighted for each one. the index, and its links, would then be auto-coded.
***
as far as i know, this is how most indexing apps work, and probably how most indexers did the job manually (using lots of “index” cards), back before computers.
this paragraph-by-parapraph mode seems very easy to code, so almost any programmer could manage it.
***
i am also sure most indexers, and index-app coders, will tell me that i’m just scratching the surface here, and that creating a “pro” index is more complicated; but my intention is to service self-published authors who, despite their small budgets, still wanna provide the best possible e-books to readers and fans. and an index adds significant value. thank you for reading!
