Article
April 1, 2025
0 comment
by Stephen

Format: Pulling the Index Together

Over the last few weeks, I’ve been exploring the components of an array—main headings and subheadings, locators, and cross-references. It’s time to now look at how these are all held together.

Formatting the index, by which I mean either run-in or indented format, along with punctuation, has to do with the visual structure of the index. It is what the reader sees on the page. An index is not written like conventional prose, with complete sentences, capitalization, and closing punctuation. Headings and subheadings are instead single words or short phrases which nonetheless need to be strung together in a coherent way that indicates relationships and is easy to search.

There are two ways that indexes are typically formatted: run-in and indented. Run-in format is more space efficient and common in scholarly books, where indexes tend to be dense and space can be at a premium. Indented format is easier to scan, while also being more spread out, taking up more space.

When I write an index, the software I use, Cindex, allows me to easily switch back and forth between run-in and indented format. I find this a huge advantage because I prefer to index in indented format, which is, I suppose, my implicit acknowledgment that indented format is easier to work with. Once I have finished editing the index, one of my last steps, if the press requires run-in format, is to switch the format and export.

The difference between run-in and indented looks like this:

Run-in format

coffee: café culture and, 35, 64-66, 132; comparison to tea, 52-55; fair trade, 22, 32, 58, 89-90;

geopolitics and, 43, 78; industrialization, 33-34, 88, 91-93; roasting, 43, 53, 67; varieties, 29,

45-47. See also caffeine; tea

Indented format

coffee

café culture and, 35, 64-66, 132

fair trade, 22, 32, 58, 89-90

geopolitics and, 43, 78

industrialization, 33-34, 88, 91-93

roasting, 43, 53, 67

tea, comparison to, 52-55

varieties, 29, 45-47 

See also caffeine; tea

As you can see, in run-in format the main heading, subheadings, and cross-references are strung together, one after the other. The main heading is separated from the subheadings by a  colon, and subheadings are separated from each other by semicolons, with a period between the final subheading and the cross-references. This format allows the array to utilize the full length of the line; once the line is full, the array runs down onto the next line. Subsequent lines are indented to differentiate between arrays. This is what makes run-in format more space efficient, though having all of the lines run together does mean that the reader needs to scan more carefully. 

In indented format, in contrast, each element of the array has its own line. The main heading is at the top with all subheadings following below. The subheadings are indented to differentiate between the heading and subheadings, and to differentiate between arrays. The cross-references, in this example, are placed at the very end, also indented. Because each line is indented, less punctuation is needed—no colons, semicolons, or periods. With the subheadings stacked on top of each other, the subheadings are easier to scan, though also taking up more lines.

For both run-in and indented formats, commas are used to separate headings and subheadings from locators, and locators from each other. 

In my experience, some publishers, including scholarly, see the value of indented format and are committed to making sure that there is enough space. Indented format also works well for an index that doesn’t have many subheadings, as the space difference between run-in and indented will then be negligible. Otherwise, if the index contains a lot of subheadings and space is an issue, use run-in format to squeeze in as many lines as possible. Sometimes, if I know the publisher is open to either and I’m not sure how the index will fit, I’ll submit the index is both formats for the publisher to try and decide.

A few more points:

  • Capitalization should follow the text, and generally is only for proper nouns. I believe it used to be a convention to always capitalize headings and subheadings, as in a sentence, but that convention seems to have passed. The exception are the See and See also of cross-references, which are capitalized since they typically follow a period. 
  • Adjust how subheadings are phrased, depending on the format. In run-in format, because subheadings run together, I try to ensure that the subheadings read naturally, without inversion or extra punctuation to chop up the phrase. While I still try to lead with the key term, there is already so much punctuation that I don’t want to make the array even more complicated. In indented format, in contrast, because the stacked subheadings are easier to scan, always lead with the key term. This may require inverting the phrase. For example, see the subheadings “comparison to tea/tea, comparison to” in the examples above. This difference also affects how the subheadings are sorted—another detail to pay attention to. The goal, as always, is to make the subheadings both easy to read and easy to find. 
  • If you use dedicated indexing software, like Cindex, you don’t need to pay too much attention to formatting. The software does it for you. You do need to make sure, though, that you have chosen the correct settings. Having the software handle the formatting is a huge timesaver and frees up cognitive space to focus on analyzing the text and writing the entries. When I first started indexing, I typed everything out in a Word document and needed to manually create the format. That was an excellent way to intimately learn how format works, and I’m also thankful I don’t need to do that anymore. 

The format is how the index appears on the page. It helps to pull all of the entries and arrays together in a way that is easy to read and search. Run-in and indented formats are both common and both have their pros and cons. While indexing software typically handles the formatting automatically, as the indexer, be aware of the options and of how the format affects how entries are written and how the index fits the reserved space. How the index appears on the page is also important, alongside the contents of the index, and you may find yourself called upon to advise the client on the best format for their particular index.

Article
March 18, 2025
0 comment
by Stephen

Signposts within the Index

Welcome back to the mini-series on the basic elements of an index! I previously discussed entries and arrays, main headings and subheadings, and locators. Today I am writing about cross-references.

Cross-references are a type of locator, but instead of directing readers to the text, cross-references redirect readers to a location within the index. Riffing off the metaphor of an index as a map, I like to think of cross-references as signposts within the index that ensure readers find the arrays they want.

Cross-references come in two types, See and See also. See references tell the reader, “Good effort, but the information you want is actually over there,” while See also references indicate, “if you liked this, maybe you will also like that.”

How to Use

  • Cross-references should always point to new information, which is to say, new locators that the reader hasn’t seen yet. If the array the cross-reference is pointing towards has identical locators, then it is a double-post, which is also good, but renders a cross-reference unnecessary. 
  • Speaking of double-posts, cross-references and double-posts are kind of like cousins, complementary tools for making information accessible within the index. Double-posts are when identical information is placed in two or more locations in the index, such as both a main heading and subheading, to accommodate readers searching either way. They work best for shorter strings of locators that are easily duplicated. The downside to double-posts is that they can take up space, especially if subheadings are involved. In that case, a cross-reference is the quicker and more space efficient option. 
  • Cross-references are usually from broader topics to more specific topics. For example, “computers. See also Apple; Microsoft.” The logic is that readers less clear on what they are looking for will likely begin with the broader term, whereas if they already have the specific in mind, they will skip the broader term and go straight to the specific. For those readers uncertain, the cross-reference prompts them that there is more to the topic that they may be interested in. Can cross-references also go in the opposite direction, from specific to broad? Yes, sometimes. I don’t want to create a hard-and-fast rule, but I usually find broad-to-specific to be more meaningful. Think carefully about which direction readers are likely to desire.
  • Building upon broad-to-specific, cross-references can also be used if a subheading needs to be hived off to create its own array. Say “Apple” is originally a subheading under “computers,” but as the index is created it accumulates a dozen locators, which you decide should be broken down into subheadings. Instead of using sub-subheadings under “computers,” turn “Apple” into its own array and use a cross-reference to redirect readers. 
  • Cross-references can also be reciprocal. Say the book contains two or more related, but not quite identical, concepts. Cross-references are a good way to link these arrays, keeping in mind that readers should find something new in each. 
  • Cross-references can link synonymous terms. Say the book uses the terms “film industry” and “movie industry,” and you decide to make “film industry” the preferred term in the index. A cross-reference should be used to redirect readers who search for “movie industry.” A cross-reference from “Hollywood” may also be a good idea, if the book is specifically about the American film industry.
  • Cross-references can also be generic. There may be a category of arrays that you want to point readers towards and there are too many to list. For example, in a work of US history that covers multiple presidencies, the following may be useful: “United States of America. See also specific presidents.” The assumption here is that readers will know the names of specific presidents, or will remember which are discussed in the book, and will be able to search accordingly. 

Formatting and Placement

Where to place the cross-reference is an interesting question. The cross-reference is usually placed at the end of the array, after the other locators and subheadings, if any. But cross-references can also be placed at the beginning, immediately after the main heading.

For example,

computers: economic advantages; history of; rare earth minerals and; semiconductors. See also Apple; Microsoft; TMSC

and 

computers. See also Apple; Microsoft; TMSC: economic advantages; history of; rare earth minerals and; semiconductors

Both approaches have their advantages. Placing cross-references at the end allows the reader to first peruse the array to see if they can find what they want. If not, the cross-references are ready to offer other suggestions. Placing cross-references at the beginning allows readers to quickly see if they actually want to be elsewhere, before they dig into the subheadings. Placing cross-references at the end is more common, and I think is what most readers and publishers expect. However, for reference documents, especially, and for indexes with very long arrays, placing the cross-references at the beginning can be helpful for an audience that wants to search quickly. 

Cross-references can also direct readers to specific subheadings. I rarely do this, but that may have to do with the types of books I tend to index. If you need to, the cross-reference can be phrased as either “statistics. See under economics” or “statistics. See also economics—statistics.”

Cross-references can also be attached to specific subheadings, instead of being gathered in a group at the beginning or end of the array. I didn’t use to do this, but the recent NISO indexing standard (ANSI/NISO Z39.4-2021) recommends doing so, which prompted me to give this more thought and to adjust my practice. There are two questions that guide where I place the cross-reference: 1) How specific is the cross-reference? Is it more connected to the main heading or to the subheading? 2) How long is the array? If short, I think readers will easily see the cross-references at the end. If long, then attaching the cross-reference to the subheading, if relevant, allows the reader to be redirected sooner. 

In terms of formatting, See and See also are typically upper case and in italics. The exception is if the heading being directed to is also in italics. For example, “Austen, Jane. See Northanger Abbey; Persuasion; Pride and Prejudice.” Multiple cross-references are separated by semicolons. Cross-references are preceded by a period, but, if placed at the end of an array, no closing punctuation is needed. Cross-references attached to subheadings are in lower case and may be placed in parentheses to better differentiate from the surrounding subheadings. For example, “literature: authorship, 34, 53, 122; figurative language, 45, 53 (see also metaphor; similes); poetry, 56-60, 132, 154; translation (see translation)“ 

Some indexes are thick with cross-references, an interlocking web redirecting readers. This may be due to the book using a lot of synonyms, or similar but different terms, or concepts for which the indexable term is not obvious. Other indexes contain just a handful of cross-references. Either way, the goal is to ensure that readers find the information they desire.

Article
March 4, 2025
0 comment
by Stephen

Cognitive Load and Indexing Oxford UP Titles

My original plan for today was to write about indexing Oxford University Press (OUP) titles, of which I recently indexed two. I will still reflect on OUP, but as I was writing this, I realized that my main issue with OUP’s system is its impact on cognitive load. So partway through I’m going to take a little detour to discuss the cognitive impacts of indexing.

The OUP System

Oxford University Press is unique among publishers, so far as I know, in that it uses a paragraph ID system for indexing. Each paragraph is assigned a unique ID, for example C2P34, which stands for chapter 2, paragraph 34. Each section is also assigned an ID (for example, C3S2), as is each figure (C4F5). In the index, these are used as locators instead of page numbers. When the proofs are finalized, OUP converts these IDs into the appropriate page numbers and ranges.

For me, this system is sort of halfway between traditional back-of-the-book indexing and embedded indexing. I can use the paragraph IDs with my preferred software, Cindex, and I don’t need to fiddle around with embedding tags into the proofs or manuscript. The paragraph IDs also allow the press to output the index for both print and ebook versions. 

Are paragraph IDs the best of both worlds? Depends who you ask, perhaps. I suspect some indexers already comfortable with embedding would prefer that OUP fully make that transition, and maybe embedded is better than this hybrid approach. I don’t write embedded indexes, so I can’t compare. Personally, I appreciate being able to use Cindex, though the IDs are not as easy to use as page numbers.

I found it an interesting experience indexing two OUP titles back-to-back. Despite freelancing for about twelve years, I have very little experience with OUP. I haven’t avoided them, per se, but neither have I actively sought out their books. I simply haven’t received many queries, at least until these last few months, when I probably received as many queries as I have in the previous twelve years. So it’s been a crash course for me, figuring out how best to handle the paragraph IDs.

OUP’s indexing instructions are comprehensive, explaining how they want the paragraph IDs used and formatted. So I won’t discuss all of that in detail. Instead, I want to discuss some of the challenges I had, along with some strategies that helped me through.

Impacts on Cognitive Load

The most significant challenge I had with the paragraph IDs was its impact on cognitive load.

Cognitive load is “the amount of information our working memory can process at any given time.” Working memory is the “small amount of information that can be held in mind and used in the execution of cognitive tasks.” These are the pieces of information that you are actively trying to keep in mind while performing a task. 

Cognitive load and working memory are relevant concepts for indexing. When writing an index, I am identifying information in the text, deciding if it is indexable, determining how the information relates to other pieces of information, and then adding the entry to the index. All of that is happening within my working memory. Add in that I may read the entire paragraph before I make a decision, or I may read a few paragraphs ahead, and my working memory is suddenly bursting with potential entries waiting for me to decide whether or not—and how—to add to the index.

This is why I pick up entries as I see them. At most, I’ll read ahead a few pages before going back to add the entries I’ve identified. I am aware that if I read too far ahead, I begin to forget the specific details that I previously noticed. So I want to capture those entries right away and make space in my working memory for new information. If you are someone who prefers to mark up the text and type the entries later, underlining terms and making notes in the margins fulfills the same function. You are making notes about your decisions to refer back to later, to make room in your working memory.

When using page numbers for locators, I’ve gained a sense for the limits of my working memory and for when the cognitive load becomes too great. What I did not anticipate from indexing OUP titles is how much more the paragraph IDs added to my cognitive load. 

The paragraph IDs added to my cognitive load in a few ways:

  • Paragraph IDs are longer and more complicated than page numbers. An ID which contains both numbers and letters is more to scan, remember, and type, compared to a digits-only page number. 
  • There are far more paragraphs than pages. A typical book may have 200 pages and maybe 600 paragraphs, assuming three paragraphs per page. That is a significant increase in the number of unique locators to track and ensure accuracy.
  • Ranges are more common and lengthier. A range can occur on the same page, as in C1P34-C1P35. Or the page span 84-88 may be represented, in paragraphs, as C3P43-C3P56. Because ranges are so prevalent, I found myself constantly scanning ahead, even on the same page, to see if I needed to add a range. For ranges that spanned a few pages, I found myself more focused on identifying the correct paragraph IDs than I was on the contents of the paragraphs. Perhaps I haven’t acclimatized yet to paragraph IDs, but determining a range that spans 14 paragraphs somehow felt like more work than a range that spans 5 pages, even though both ranges are for the same amount of text.
  • Navigating the PDF proofs is more difficult with paragraph IDs, especially when I’m editing the index and want to refer back to the text to double-check an entry. The locator does not tell me the page, and so I can’t use my usual keystroke shortcut to jump from page to page in the PDF reader. Instead, I need to use the search function. As I mentioned above, typing the ID is more work, as it contains both letters and numbers. Searching for the ID also means that I can’t use the search function to simultaneously search for whichever name or term I want to check, which also makes searching the PDF more cumbersome.
  • Indexing endnotes is more tedious and time consuming. In OUP’s system, the note number is appended to the paragraph ID where the note originally appears. As in, C1P45 n.27. This means going back to the chapter and searching to find the in-text note number so I know which paragraph ID to use, while trying to remember what the note was about in the first place.

Tips for Handling Paragraph IDs

So I’m not a huge fan of OUP’s paragraph IDs. They are more work, though is it really so much more work? Yes and no.

A single paragraph ID is not that big of a deal. It maybe adds a few seconds extra to the work. The problem is that the book contains hundreds of paragraph ID. The index likely contains at least a thousand locators. All of these add up, to the point where I, at least, start noticing that the work is taking longer and that I’m mentally juggling more than usual.

I am still able to use Cindex, my preferred software, and my indexing process mostly remains the same. But I did have to reset my expectations for how long the work would take, and I made a couple of adjustments to how I worked.

  • Take a deep breath and accept that the work will take a little longer. For me, this was especially true when editing the index, due to how awkward it was to navigate the PDF proofs.
  • Multiple passes. When drafting, I found it helpful to make multiple passes, going over the same paragraphs or section a couple of times. One pass would be to determine the broader discussions and where ranges needed to begin and end. Occasionally, if relevant, I used a section ID for the entire section rather than fiddling with a range. Another pass would be to pick up smaller details, like names, that didn’t need a range. This isn’t a new strategy for me, as I often do this when the text is particularly dense or confusing and I want to have a better understanding of the text before I begin typing up entries. But due to how focused I was on ranges and ensuring accuracy with the paragraph IDs, I used this strategy a lot more to make sure I was picking up both the content and the locators. There was too much to focus on in one pass.
  • Duplicate the endnotes. It was time consuming and frustrating to flip back and forth between the endnotes and the chapter, trying to find the paragraph where the note is found while also trying to remember what the note is about. Much easier to create a duplicate PDF of the endnotes (printing the notes would also work), so that I can see and compare the notes and chapter is parallel. 
  • Search for partial IDs. When searching the PDF for paragraph IDs, I found it usually worked just as well to omit the initial C. So, to search for 3P34 instead of C3P34. A small detail, but I felt like it was a tiny bit quicker. 
  • Charge a little extra. For the extra time and work, I did charge more for these indexes. I was also upfront with my clients about this. I think it is fair to be compensated for extra work. 

Will I index an OUP title again? Yes. I’m actually in discussions with another potential client.

Will I go out of my way to find OUP titles to index? No.

I do appreciate that OUP wants to include the index in ebooks. And the paragraph IDs are a good approach, in theory. I just wish that the IDs weren’t so awkward to use, and that there aren’t so many of them. Indexing is already cognitively taxing, and adding to that load isn’t helpful. But with some forewarning and tweaks to my approach, indexing OUP titles is very doable.

Article
February 18, 2025
0 comment
by Stephen

Pointing Readers in the Right Direction

Welcome back to this mini-series on the basic elements of an index.

I’m currently looking at what makes up an entry, which I described as “what this thing is + where to find it.” In my previous post I discussed main headings and subheadings, which form the first part of that equation. Today, I’m writing about the second part, “where to find it,” also known as locators.

Locators are the portion of the entry which tells readers where to find information about the main heading and subheading. They are like directions for the reader to follow. To be effective, locators need to be clear, specific, and accurate. 

There are three points that I want to make about locators.

The first is that a locator can be anything. Page numbers are usually the default locator, especially when indexing books, but other forms of locators can also be used, such as paragraph or policy numbers. The only criteria is that the locator is appropriate for the material being indexed.

My second point is that the locator needs to be clear and specific. Readers should understand how the locator relates to the text, and should be able to easily use the locator to find the desired information.

To give a few examples, page numbers are often augmented when referring to figures and tables or to footnotes and endnotes. For figures and tables, the page number may be placed in italics or bold, or have a fig. or t appended. For notes, the note number is usually appended to the page number, as in 253n43 or 265nn14-15. These allow the reader to more quickly pinpoint the information on the page.

For a cumulative index for a journal or multivolume series, the locator should probably include a volume or issue number alongside the page number, as in VII.343. For a policy document that I update every couple of years, I use unique policy numbers instead of page numbers, as in 20.2.1.2. These policy numbers both direct readers to the specific policy more quickly (especially if there are ten or more policies listed per page), and makes updating the index a whole lot easier as I don’t need to worry about the pagination shifting as policies are added, removed, and revised. 

When augmenting page numbers or using something different for a locator, it may be helpful to explain your choice in a headnote so readers understand how to interpret the locator. Page numbers, being the default, don’t need to be explained.

To give a few examples of locators:

conduction, 83, 84fig. 

convection, 85, 84t, 234n43

safety protocols, 2.1.13.4, 3.3.1.12, 3.4.3.6

thermodynamics, VI.343, IX.23

The last point I want to make is that the number of locators in an array should be reasonable for readers to search. As a general rule of thumb, no more than 6-10 undifferentiated locators. Larger arrays, with more than ten locators, should have subheadings to sort the references and make it easier for the reader to identify the relevant aspects of the subject. The concern is that searching through a long string of undifferentiated locators is time-consuming and may discourage the reader from finding what they need. Better to set the reader up for success by presenting locators in smaller chunks.

 

When writing an entry, the main heading and, possibly, subheadings, tell readers what the subject is, while the locator tells readers where to find information about that subject. Locators can be anything, and should be clear and specific. The number of locators should also be reasonable for readers to search. Do this, and you are setting your reader up for success.

Article
February 4, 2025
0 comment
by Stephen

Telling Readers What This Thing Is

In my last post I wrote about entries and arrays, which I described as the building blocks of an index. I defined an entry as “what this thing is + where to find it.” Today I’m going to expand on “what this thing is,” also known as main headings and subheadings.

The fundamental purpose of an index is to guide readers to the relevant information that the reader is searching for. To do that, the index needs to be clearly written, which begins with the first words that the reader sees. 

Main Headings

The main heading, also known simply as the heading, kicks off the entry. This is the first word or phrase that you see in an entry and array. It is typically a noun, and should be clear and concise. If a longer phrase is needed, the main heading should lead with the most important element. The main heading should also match how the term is used in the text, such as using the same spelling and capitalization. 

The heading should be reflective of both the text and the audience. Is the book discussing cars more generally or electric vehicles specifically? Or both? Will readers be reading this book to learn about the auto industry, new innovations, or specific brands and models? Or all of the above? To give another example, biblical characters such as Matthew, Silas, and Timothy probably don’t need a gloss clarifying their identity in a work of biblical studies to clarify their identities, but these names may be more unfamiliar to readers if they appear in other disciplines. 

Another consideration is whether or not to pluralize main headings. Should it be dog or dogs? Cantaloupe or cantaloupes? To start, be mindful of differences in nuance. Freedom is somewhat different from freedoms, for example. Otherwise, I tend to follow common usage. If a term is commonly pluralized, then I go ahead and make it plural in the index, which I think reads more naturally. 

To give a few examples of main headings:

Acts (biblical book)

Cleveland, Grover

electric vehicles

heat transfer

London (ON)

trade wars, retaliatory

Subheadings

For short arrays containing a handful of locators, a main heading is usually sufficient to specify what this thing is. But more specificity is often needed for topics with extensive discussion (usually when there are more than 6-10 locators) or if there are different aspects that readers would appreciate differentiated.

The subheading is placed after the main heading. Its purpose is to further clarify what this thing is. Because subheadings often differentiate references from one another, there are usually multiple subheadings per array.

Since the subheading is appended, there is more flexibility in how it can be phrased. Depending on the context, the subheading can be either a short word or phrase, or it can be longer and more descriptive.  In all cases, the relationship between the main heading and subheading should be clear. If possible, I try to also lead with the key word, which both affects how the subheadings are alphabetically sorted and, I think, makes it easier for readers to find the subheading as they scan the array. 

For example,

Acts (biblical book): authorship; within biblical canon; commentaries on; Paul within

Cleveland, Grover: first presidency; free-silver issue; legislative achievements; private life between presidential terms; second presidency

heat transfer: conduction; convection

Effective headings and subheadings connect readers to the text. Main headings are the point at which readers encounter the index, and readers should not need to guess what this thing is. The same is true for subheadings, if the reader decides to read further into the array. 

Tell the reader what they need to know. Be specific and concise. Do this, and your index will be well on its way to being excellent.

Article
January 21, 2025
0 comment
by Stephen

The Building Blocks of an Index

An index is a document that is scanned to find information. It usually spans several pages. But if you had to break an index down into its smallest part, what would that be?

An index is not like most books or documents in that it does not contain a narrative. It cannot be reduced to plot points or the components of an argument. An index doesn’t even contain proper sentences. Instead, an index is a compilation of references. Broken down, the smallest unit within an index is an entry. 

An entry has two components. Basically, “what this thing is + where to find it.” Using indexing terminology, this is “main heading + locator.” Or, to add another level of specificity, “main heading + subheading + locator.” From the entry, the reader can identify what they are looking at and where to find it in the text. For example,

Foxconn, 45

semiconductors: geopolitics of, 67

The second building block is an array. I like to think of an array as containing everything that an index—and by extension the book or document—has to say about a particular subject. If you want to learn about Foxconn, you search for the Foxconn array. Want to learn about semiconductors, you search for the semiconductors array.

If there is only one mention, then a single entry can serve as a single array. But more often, there are multiple discusses throughout the book, which lead to the creation of multiple entries. Combined together, the entries create an array.

Foxconn, 45, 49, 51-52

semiconductors: fabrication techniques, 54-57; geopolitics of, 67; history of, 23-25; properties of, 34, 44

Why are entries and arrays so important? No one writes an index composed of a single entry.

But every index begins with an entry, and as the index is written, the entries and arrays accumulate. It is through knitting the entries and arrays together than an index emerges.

Step one to writing an index is to write clear, concise, and specific entries, so that “what this thing is” is clear to the reader. Step two is to combine entries into arrays which are clearly organized and easy to scan. Step three is to sort and organize the arrays—creating the structure of the index—so that the index as a whole is easy to navigate. 

Each of these elements—the entry and the array—fit together, like interlocking pieces, to create a coherent whole.

A Note about Terminology 

I’ve noticed that not every indexer, including books about indexing, distinguishes between entries and arrays. I’m guilty myself of using the terms interchangeably, though I try to be clear when I’m writing.

But while terminology varies, I do think that the distinction is important. Because an index is composed of hundreds or thousands of pieces of information, it helps to know what these pieces are and how they interact with each other. An index is also easier to edit and organize if these building blocks are clearly written and well thought out.

As you index, how are these building blocks fitting together? How can you be more mindful of each piece of information and how it interacts with the entries and arrays around it? Does it make a difference to think about indexing as building up from the smallest unit to the larger whole?

Article
January 7, 2025
0 comment
by Stephen

Goodbye 2024, Hello 2025

Happy New Year! How is this first full week of 2025 shaping up for you?

I am having a slow start. I enjoyed unplugging from email and work for two weeks. I’m also recovering from a cold.

December was crazy busy, wrapping up nine indexes, which included a children’s book, one project which was simply names and biblical references, and two scholarly books that I began in November. So not quite as much work as nine indexes may sound, but still more than I bargained for. That was due to a couple of projects slipping and arriving when I did not expect and also, if I’m honest with myself, I did accept too much for December and didn’t leave enough margin for complications. 2024 was an odd year and I was trying to make up some missed income, but I should have been more disciplined and said no to a couple of projects.

2024 in Review

2024 was all about buying a house and moving. That dominated everything else in my life, including indexing. I’m thankful for this house. It still feels a bit surreal that I have a permanent place to live. I have always lived in anticipation of needing to move again within the next 1-4 years, and so a part of me is waiting to move again, another part is reassuring myself that I can stay where I am, and a third part doesn’t know how to compute living in a place for longer than four years. One day at a time, I guess.

Moving, settling, and learning the maintenance rhythms for this particular house has also taken time. There were a few months over the summer when I was indexing part-time at best. That impacted the number of projects I was able to complete, along with my income, so I am especially thankful for Elim, my wife, who is earning more than me. 

Looking at the numbers for 2024:

  • 44 indexing projects (down from 52 in 2023)
  • 25 trade books, 18 scholarly books, plus an index for a policy document that I update every couple of years
  • Worked with 12 publishers (30 indexes), 12 authors (1 index each), 1 professional association and 1 policy institute (1 indexes each)
  • 34 projects were from clients within Canada, 8 projects from clients in the US, and 2 projects from clients in Australia.

Overall, my numbers are fairly similar to 2023, despite fewer projects. My ratio of trade to scholarly books is similar, as is projects from publishers vs. authors, and where projects are coming from. I am very thankful for the publishers I work with and who continue to send me work year after year. Having these positive relationships and not needing to actively market as much definitely makes my life easier. 

One interesting point: one publisher sent me 11 books to index in 2024, which is 25% of my total projects. All of the other publishers sent me between 1-3 projects each. While I always enjoy working with that one publisher and I hope to continue to do so, I think this speaks to the value of working with a wide range of publishers, especially if they are fairly small companies. One or two publishers are not enough to fill my schedule, but 10+ combined keeps me fairly busy.

Indexing Highlights

Do you ever notice that certain topics can appear in waves, with two or three books in a row on a similar subject? I find that often happens to me and I wonder why. Very serendipitous. 

In the past few months I indexed two trade books on the Empress of Asia and the Empress of Ireland. These were both ocean liners owned by Canadian Pacific Steamships. The Empress of Ireland collided with another ship and sank in 1914 in the St. Lawrence River, causing the death of 1,012 people, Canada’s worst maritime disaster. The Empress of Asia had a longer career, serving in both WWI and WWII, before being sunk by the Japanese near Singapore. Reflecting their different trajectories, Beneath Dark Waters: The Legacy of the Empress of Ireland Shipwreck, by Eve Lazarus (Arsenal Pulp Press, 2025) is tightly focused on the collision and aftermath, while Oceans of Fate: Peace and Peril Aboard the Steamship Empress of Asia, by Dan Black (Dundurn Press, 2025) follows the Asia over its 30 year lifespan. Both focus on the lives of the passengers and crew, which is what brings these harrowing stories to life. I recommend both if you enjoy maritime history. 

Taking the prize for the most unexpected subject matter is Dialectics of the Big Bang and the Absolute Existence of the Multiverse, by Gregory Phipps (University of Alberta Press, 2024). Did you know that the first second after the Big Bang can be divided into six epochs? Difficult to study empirically, and so Phipps uses Hegelian dialectics to unpack what may have happened. A fascinating read, and also very challenging to index. Philosophy is not my strong suit. Thankfully the author seemed happy with the result. 

Whither 2025?

For 2025, my keyword is margin. I want time to write, to work on the house, to spend time with Elim, and for exercise and rest. This means managing my indexing schedule so that I’m not constantly chasing deadlines and needing to work long hours. I still have an income target, which is a decent amount but also about 10% less than what my target has been in the past. And I’m okay with that. The pace of work hasn’t felt healthy or sustainable, and I don’t like feeling like there are areas of my life I am missing out on.

So here’s to finding a better balance in 2025.

Article
November 20, 2024
0 comment
by Stephen

Making the Index Invisible

So the 18th edition of the Chicago Manual of Style dropped in September. I have to admit I have not bought a copy. While I think their recommendations are solid, I find I don’t use it very much, since I only index and not edit. But I do know some editors who are very excited about the new edition, and there has been chatter among indexers as well on the changes to the chapter on indexing.

The main change in regards to indexing is 15.66, which states:

Chicago now prefers the word-by-word system of alphabetization over the letter-by-letter system (but will accept either in a well-prepared index).

 

I think this change makes sense.

I personally most notice the difference in sorting when indexing Asian studies books, where I tend to see a lot of surnames like Chen, Kim, and Liu. Being so short, these names often get mixed up with other headings when sorted letter-by-letter, whereas I think the index is easier to scan if all of the surnames are sorted together. I’ve also received instructions from a scholarly press to sort the index letter-by-letter except for the names, which the press wants force-sorted word-by-word. Which begs the question: why not sort the entire index word-by-word?

For example, here is a comparison of letter-by-letter compared to word-by-word.

Letter-by-letter sorting
Liang Ji
Liang Qichao
Libailiu (Saturday)
Li Boyuan
Li Chen
Life Weekly
Lin Meijing
Li Shirui
List, Friedrich
Liu Denghan
Liu Jiang
Liu, Jianmei
Liu, Lydia
Liushou nüshi (Those Left Behind; film)
Liuxuesheng (overseas Chinese students)
Liu Yiqing
Li Yuanhong
 
Word-by-word sorting
Li Boyuan
Li Chen
Li Shirui
Li Yuanhong
Liang Ji
Liang Qichao
Libailiu (Saturday)
Life Weekly
Lin Meijing
List, Friedrich
Liu Denghan
Liu Jiang
Liu, Jianmei
Liu, Lydia
Liu Yiqing
Liushou nüshi (Those Left Behind; film)
Liuxuesheng (overseas Chinese students)
 

The word-by-word sorting, for me, is a lot easier to scan and parse when like surnames are grouped together, and when names are sorted together above other terms. It makes me confident that I am seeing all of the names present, rather than being concerned that I am missing a name that is buried below.

Also note that the Liu names are sorted according to the clarified 15.85, which states:

When the same family name is inverted for one person but not for another (e.g., “Li Jinghan” and “Li, Lillian”), the names may be listed together and alphabetized by first names regardless of the comma.

 

This also makes a lot of sense and has been my practice for a long time. By ignoring the comma, the second portion of the name is treated equally for all names, whereas if the comma is taken into account, all the names with commas sort to the top and may cause some names to appear out of order. For example,

Liu, Jianmei, 48
Liu, Lydia, 91
Liu Denghan, 148n6
Liu Jiang, 105
Liu Yiqing, 27, 144n13
 

For another interesting comparison, as a colleague pointed out, try looking for the sorting differences in the indexes between the 17th and 18th editions of the CMOS. And if you’d like to see a full list of the changes to the indexing chapter in CMOS 18,see here.

So will I now unilaterally switch to word-by-word sorting for all of my clients who request that the index follows CMOS? I don’t think so, unless I think that the index will really benefit. I think it is better if I first ask my clients if they want to change, so we are both on the same page and I am not springing a surprise on them. And, to be honest, for most indexes I don’t think that the difference between word-by-word and letter-by-letter sorting will be that noticeable.

This brings me to my larger point, which is that the mechanics of a well written index should be invisible to the user. I doubt that any reader will browse the index and think, “I wonder what the alphabetical sort is?” That is not the reader’s concern. What the reader cares about is quickly finding information.

To facilitate finding information, every aspect of the index needs to work together. This includes the sorting, the structure, term selection, phrasing, and cross-references. When it works, the reader shouldn’t notice how the index works because the reader is too busy digging into the book. When the index does not work—that is the point when the reader is pulled out of the index and is frustrated at their inability to access the information they want. The reader may not be able to articulate whythe index is not working, but something about the contents and mechanics of the index is wrong.

Bringing this back to sorting, for many indexes the difference will be negligible between letter-by-letter and word-by-word sorting. As CMOS states, they will accept either in a well-prepared index. For other books, like for me with Asian studies titles, the difference will be more pronounced.

When indexing, pay attention to when the difference matters. Make decisions based on what will make the user experience the most seamless. Pay attention to how the different elements of the index fit together. Striving to make the index invisible may be an odd way to think about indexing, but to be invisible means that the index works, which is what we ultimately want for our readers.

Article
November 5, 2024
0 comment
by Stephen

Paying Attention to Terminology

I am writing today about some decisions that I needed to make on a recent index. In the grand scheme of the index, these decisions only affected a few entries. I am tempted to brush these off as not very important and not worth discussing. Yet much of indexing is about paying attention to the details without getting lost in the details. And I think this is a unique situation that illustrates an important point about term selection. At least, it made me sit up and think carefully as I was working.

A good index encapsulates two different goals, which can sometimes seem like they are in opposition to each other. The index needs to be both a reflection of what the author has written and be an attempt to clearly communicate with the reader. Lose one of these aspects, and the index ceases to function.

Term selection is key to achieving both of these goals. The terms used in the index need to both match the text and how the reader is likely to search. Ideally the author and the reader are in alignment, but sometimes the author uses different language than what the reader might expect. In those situations, the index may need to bridge the gap.

I recently ran into this issue when writing the index for Saint Paul the Pharisee: Jewish Apostle to All Nations, by Father Stephen De Young (Ancient Faith Publishing, 2024).

If you are familiar with Christianity, the title may be a hint that the author is taking a different tact with terminology. While Paul was a pharisee prior to his conversion, he is now more commonly known as the Apostle Paul, or Paul the Apostle. Yet here Fr. Stephen is emphasizing Paul’s Jewishness.

In the book’s Introduction, Fr. Stephen addresses this question of terminology:

Throughout this book, I have deliberately eschewed certain language. This language is certainly acceptable and has become the usual language of the Church. However, familiar terminology can sometimes be misleading. By using the word Messiah instead of Christ, community instead of church, or Torah instead of law, I hope to unsettle commonly held notions and help the reader reassess Paul in his historical context, rather than project the experience of present-day Christians into the past.

 

This shift in terminology also extends to names, which is where I noticed the biggest difference in regards to the index.

In addition to “Paul the Pharisee,” Fr. Stephen also frequently refers to Paul by his former name, Saul of Tarsus. Jesus is referred to as “Jesus of Nazareth,” rather than Jesus Christ. A figure such as the Apostle John, also known as John the Evangelist, John the Theologian, or John the Divine, is here referred to as John, the son of Zebedee. None of these names are incorrect, but they are names that are less commonly used. They support the author’s focus on Paul and the early Church’s Jewish context and alerts readers that the author is taking a different approach.

From an indexing standpoint, do I follow Fr. Stephen’s lead? By using these names, I would provide continuity with the text and reinforce the point that Fr. Stephen is trying to make. But will readers still recognize these names in the index, outside of the context of the text? I am not helping anyone if I include names and terms that readers are unlikely to recognize.

In the end, I decided to lean into the author’s terminology. Christians form the primary audience for this book and, I assume, are familiar enough with with these Biblical figures, even if these are not the names typically used.

Paul I simply indexed as “Paul.” As the subject of the book, I decided a gloss was unnecessary. I also included a See cross-reference from Saul of Tarsus, for any readers looking under Saul and to keep all discussions of Saul/Paul in a single array.

I indexed Jesus as “Jesus of Nazareth,” with a subheading for “as Messiah,” to reflect how the author discusses Jesus. I indexed the other Biblical figures as is (“Peter,” “Silas,” “Timothy,’ etc…) except for when a gloss or tag was needed to disambiguate (for example, “James, brother of the Lord’ and “James, son of Zebedee”). This is again following the author’s approach and trusting that readers will recognize these names.

I did, however, include glosses for several of the provinces and cities discussed, such as “Achaia (province)” and “Perge (city),” especially the less well-known places (I didn’t include glosses for cities like Athens and Rome). This may not have been necessary, but I personally like knowing where things are and what things are, so as a reader I would have appreciated the differentiation.

As I wrote at the beginning, these names form a small proportion of the overall index. Was it really worth spending time considering how best to balance the author’s approach versus reader expectations? There are plenty of other discussions in the book, such as discussions about Paul’s missionary journeys, the history of the early Church, and theological issues that Paul addresses in his epistles, that I also wanted to get right.

And yet names matter and terminology matters. The index would have presented a different message if I had used more conventional names for these figures and the index would have appeared disjointed from the text. Writing a good index is often about paying attention to the details so that the entire index works together as a whole and in conjunction with both the text and readers. The trick is to see both the details and the whole. It can be easy to lose sight of the big picture.

For this book, while the author opted to shift the terminology to make a point, I decided that most readers would still be able to follow along in the index. I didn’t need to include much in the way of signposts and clarifications. But for other books, extensive use of cross-references and glosses may be necessary. While reflecting the text and the author’s intentions, the index also needs to be responsive to readers. Thankfully, we have tools to bridge that gap.

The first step, though, is paying attention to the language used by the author. The next step is considering the audience. Do the two match? From here you can select terms and write an index that is clear and recognizable to all.

Article
October 22, 2024
0 comment
by Stephen

When Potential Clients Ghost Me

Fall has definitely arrived here in Edmonton. Leaves are turning a beautiful golden yellow and the temperature at night is starting to dip below freezing. This year this also seems to be the season for an uptick in queries to index academic books, most of them ready for indexing in December. I’m not sure why this is the case. I find queries can ebb and flow throughout the year, though I don’t think publishing seasons are as important for academic publishing as it is for trade. In any case, I’ve been responding to a lot of emails.

I’ve also noticed a number of authors who seem to be ghosting me. I respond to their queries, sent them an estimate, and never hear from them again.

This is actually good, from my perspective. It means I don’t have to say no and that time slot is kept open for someone who does want to work with me. I am receiving more offers than I can accept, so while I do appreciate a response to inform me that the author is choosing to work with someone else, I don’t mind when potential clients filter themselves out.

I assume some authors simply forget to respond because they are busy. I’ve certainly done that. But why are potential clients choosing not to hire me? Am I doing something wrong in how I present myself, or am I actually doing something right? While I don’t know for sure, I have a few guesses based on the interactions I do have. I think there are two main reasons why I get ghosted, plus four additional reasons why I may not get the job. 

  • I’m too expensive. Especially for authors paying out of pocket. I am sympathetic to authors on a budget. I know that indexing can be expensive and that I am not the cheapest indexer around. I also don’t want to be the cheapest. I believe that the quality of my work and my years of experience is worth something. I am also mindful that I am freelancing in order to earn a sustainable income. So yes, I suspect that I am too expensive for some authors, and I’m okay with that. I see my pricing as a filter, because I know while some potential clients will find my quotes too high, others will find my quotes acceptable.
  • The client doesn’t value or understand what indexing entails. This is also related to price, though not because the client is unable to pay. I sometimes get the sense, from what the potential client writes in their query or the questions they ask, that they see indexing as data entry. They don’t consider all of the analysis, skill, and time that goes into interpreting the text, selecting terms, and structuring the index and arrays. So my quote seems outrageously high for what, to them, seems like a simple and menial task. It is frustrating when potential clients don’t value or understand what it is I do, but I also don’t want to waste my time writing a terrible index to make a low price worthwhile. If the client and I can’t agree on the value of the index, then we are better off going our separate ways.

Those are the two main reasons why I think I get ghosted. But projects can also fall through for other ordinary and legitimate reasons. Here are four common ones I see.

  • Another indexer responds first. Some authors contact multiple indexers and seem to choose the first indexer who replies. While this is incentive to reply quickly, I also find email incredibly distracting, so I’m okay losing out on the occasional project if it means I can carve out uninterrupted time to work.
  • Going with a firmer yes. Some authors don’t have firm dates yet for the index when they contact me. This makes it difficult for me to give a firm yes, especially if my schedule is filling up and I’m concerned about overbooking. Whereas another indexer may have a freer schedule or more flexibility. Which I understand and no hard feelings from me. 
  • An embedded index is needed. I don’t write embedded indexes, so once I realize what they need (which the author doesn’t always realize themselves), I need to reply and decline.
  • My schedule is full. Sometimes I simply don’t have room and I need to say no. 

It still stings when I get rejected or ghosted by a potential client. There is a hit of validation when schedules align and the client decides to accept my quote. But I also recognize that I am in a privileged position. As someone running a one-person business, there is a limit to how many indexes I can write per month. The question becomes: how can I filter the offers and queries to find the best clients and projects to work with?

Part of the answer is pricing, as I already discussed. I am looking for clients with larger budgets.  Marketing—the information I put out about myself—is also important. Can I find projects and clients which align with my own interests? Cultivating long-term relationships with certain publishers and editors is also important to me, as I enjoy their books and they have provided a lot of work over the years.

If you are an experienced indexer and feel like you are drowning in work and queries, then maybe it is time to raise your prices. Some clients may leave, and that’s okay because you can’t serve everyone. Saying no to a potential client, or having a potential client say no to you, can sometimes be the best outcome because it leaves room for a better client and project to come along. Who do you most want to work with? Focus on attracting and serving those clients. 

If you are a newer indexer, what I am writing today may seem irrelevant. I remember being a new indexer with an empty schedule waiting for anyone to get in touch with any project. But as your experience and reputation grows, your schedule should begin filling up too and you will hopefully reach the point where you will need to turn down work. It helps to be prepared for that day, even if you just make a note at the back of your mind that that day is coming. Again, who do you want to work with? How can you adjust your pricing? A no to one project means a yes to something else.