Indexing is governed by a lot of rules and conventions. Every indexer, including myself, tend to have their favorite strategies and style preferences. These are important for shaping and refining the index. But is that all there is?

I’ve recently challenged myself to take a big step back. While conventions and strategies are important, and I’ve discussed many here, I also sometimes feel like I am getting lost among the weeds. What is the underlying why for these conventions, and why do they work in certain situations and not others? I also sometimes notice myself and others holding onto strategies as if they are immutable rules, even when they are no longer working.

The problem is that no single strategy will work all the time. Inevitably something about the text and index will be different and will require a different solution. Being too committed to any particular approach can lead to blindspots.

So, attempting to strip away all the various ways that an index can be pieced together, what are some fundamental principles? Can a larger framework be pulled together? Is there a way to contextualize all of those rules and conventions?

This is my current attempt.

1. Every index is going to be different. This may seem self-evident, but I think there can be the misconception, especially by those less familiar with indexing, that writing an index is about following a certain template. This is indexing as a mechanical process. In the AI age, perhaps indexing as an algorithmic process. For example, this can manifest as assuming that writing an index consists of matching page numbers to keywords, and that identifying appropriate keywords always follows a certain pattern. This can also manifest as committing to a specific convention or strategy no matter what, because that is the way that an index is supposed to be or because that is what is expected. What this misconception misses is that every text, and hence every index, is going to be different. Guidelines, conventions, and preferences need to be tailored to the subject matter, the audience, client preferences, and space constraints.
2. Be attentive to the big picture. Every index is about something, in the same way that every book is about something. The index should reflect all that the book is about. The big picture also includes the larger context of how the index will be used, who will use the index, and any constraints on length or style. These factors all shape the index. Lose sight of the big picture, and the index will likely either not fully reflect the book and/or not meet the needs of its users. Instead of thinking of the index as a collection of headings and subheadings, an excellent index is more than the sum of its parts, revealing something of the essence of the book. 
3. Index at multiple levels. Details matter, from the big picture on down. Entries and arrays for the different layers of information contained within the book reflects how the book is written, provides structure, and serve the various ways that readers may search. 
4. Always refer back to the larger context. The best way to ensure relevance and clarity is to be clear about why this heading or subheading matters in the larger context of the book and index. If you, as the indexer, doesn’t know, the index user probably won’t know either.
5. Understand the tools of the trade. Indexing conventions, guidelines, strategies, and preferences are tools for shaping the index. Know the differences between tools, and when they are applicable and when they are not. Be able to explain and justify the choice of tools. If certain conventions or strategies are not working in an index, then change or adapt. 
6. Remain creative and reflective. The process of writing an index is dynamic. Circling back around to the first principle above, every index will be different. While go-to strategies and styles can be a good starting point, it is important to keep sight of the big picture and to continually adjust as needed. Writing an index is ultimately a creative endeavor, requiring careful problem-solving to create the best index for that particular text and constraints. 

I still surprise myself when an index turns out to be more difficult than I expect. There is almost always something different.

To give an example, I’ve indexed several hiking guides for a long-time client. I consider these to be easy books to index. I have a system all figured out, for the types of entries I want to pick up and how to structure and style those entries. And yet the last hiking guide I received included significantly more Indigenous place names than previous volumes. I applaud the author and publisher for making an effort to identify, include, and educate readers on local Indigenous place names, and I want to support that effort in the index. The problem was that the space available for the index remained about the same. As I realized partway through, there was no way the index, with the addition of all those new place names, was going to fit. I needed to stop, reprioritize what to include, and rethink what I choose for main entry points.

I believe if we, as indexers, can approach each index as a fresh start, assuming upfront that something about the text and index will be different and will require creative problem-solving, and be able to keep the big picture in mind throughout the indexing process, then all of the other details will sort themselves out.

Recently, I’ve been thinking about how subheadings can sometimes be repeated and reused throughout an index. This can be valuable to readers, to signal that the same discussion reappears in different contexts or that different people are involved in the same project. This can also ease the cognitive burden of indexing and save time for the indexer. Subheadings do not need to be reinvented for every array.

As a caveat, repeating and reusing subheadings is not going to work for every index. As with any indexing strategy or technique, the first step is to determine if it is applicable. That said, I find this is a helpful strategy to keep on hand.

Repeating and Reusing Subheadings

Subheadings can be repeated and reused in two senses.

The first is to keep in mind or have written down a set of default subheadings that you can draw upon. These subheadings match common discussions or types of material, and so when those discussions come up when indexing, the subheading is readily at hand to plug in.

Some of mine include the following. Depending on the types of books you index, your list may be different.

about

background

education

establishment

introduction

marriage and family

scholarship on

The second scenario for repeating subheadings is project-specific. I find this most often happens for books with significant, overlapping elements. The overlap means that a subheading is likely needed to indicate that relationship. If overlap is extensive, subheadings are likely be reused.

To give an example, earlier this year I indexed Citizens, Scholars, and Friends: Women in the Canadian Association for Adult Education (1935-1965), by Leona M. English (University of Toronto Press, 2026). The book is about the people in the CAAE, especially women, in the context of a number of significant endeavors undertaken by the CAAE. One of those is the journal Food for Thought. I used the subheading “Food for Thought and” under nineteen different people.

To give another example, a few years ago I indexed Decolonizing Independence: Statecraft in Nigeria’s First Republic and Israeli Interventions, by Lynn Schler (Michigan State University Press, 2022). That book discussed overlapping regions, political parties, and politicians. I decided to repeat subheadings across those arrays to give a sense of those interconnections. For example, for the party Action Group and it’s leader, Obafemi Awolowo, the subheadings “Israeli relations and” and “joint corporations and” are repeated, as both the party and leader are involved.

Tailoring Subheadings

When repeating and reusing subheadings, one option is to copy and paste, which is essentially double-posting. That is what I did in the two examples above. But in other cases, while there is overlap that lends itself to reuse, the overlap is not exact. The subheading may need to be tailored.

Going back to the Decolonizing Independence example, the locators for “Israeli relations and” don’t quite match between Action Group and Obafemi Awolowo. Yes, both dealt with Israel and often together, but there are a few places where only one or the other is discussed. So while the subheading can be repeated, locators may vary somewhat.

How the subheading is phrased may also need to be adjusted. Again, looking at Action Group and Awolowo, I used the subheadings, “Action Group (AG): leadership crisis and tensions between Akintola and Awolowo” and “Awolowo, Obafemi: Action Group leadership crisis and conflict with Akintola.” Both subheadings refer to the same incident—a leadership crisis within Action Group and tensions with Akintola—and both use the same key terms, but the terms are rearranged to fit their respective main headings. This still counts as reuse, albeit modified.

Double-Posting vs. Asymmetric

Another consideration when repeating subheadings is, do the subheadings need to be double-posted or can the reuse be asymmetric? By asymmetric, I mean that the subheadings are not mirrored in the overlapping arrays.

In the Decolonizing Independence example, the subheadings are essentially double-posted. While taking into account that the locators and phrasing are sometimes tailored, many of the same subheadings can be found under two or more arrays. This reflects that many of the actors are involved in the same projects and events.

In contrast, many of the repeated subheadings in the CAAE are asymmetric. While the subheading “Food for Thought and” appears under nineteen different people, the array for Food for Thought does not contain a reciprocal list of nineteen people. This has to do with the story that each array is telling. Part of the story, for each person, is the projects they were involved in. For Food for Thought, in contrast, the story is about its establishment, growth, and end; key editors; and key topics and contemporary issues that the journal addressed. While I included subheadings for the key editors, a list of everyone involved would add clutter rather than being helpful.

Connecting to the Larger Story

Taking a step back, the single most important point about subheadings I feel like I keep repeating is the need to connect to the larger context. What is this subheading about? How does it connect to the main heading? Why is it relevant?

The same is true when repeating and reusing subheadings, with the addition that repeating subheadings also reflect broad overlaps within the text. These are relationships that can and should be highlighted at different points. When considering whether subheadings should be double-posted or asymmetric, again, how do these arrays overlap? What is the nature of the relationship? What is the larger story to be told?

To better see if there are overlapping elements and relationships, consider sketching a mind map, as I discussed last month. Take a step back from the index to see the major components and how they relate. The overlap could be specific actors, as in Decolonizing Independence, or the overlap could be more in terms of elements, such as people and projects in the CAAE example.  

It may take some practice to think about books in terms of overlapping elements and to be able to see and formulate repeatable and reusable subheadings. I think it is a strategy worth developing. It can remove some of the guesswork out of subheadings while serving readers by indicating multiple entry points from different angles. 

PS. I discuss the Decolonizing Independence example more extensively in my book, Book Indexing: A Step-by-Step Guide, in the chapter on index structure. Check that out if you want to read more.

Counterintuitively, I enjoy indexing because it is difficult. Sure, there are plenty of days I complain about a chapter being too obtuse or I’m anxious because an index is taking longer to edit than I anticipated. But if writing an index were easy, I’d lose interest and want to do something else.

I’ve been thinking of this in the context of a recent article by Rebecca Solnit, published in The Guardian. Solnit writes about the lies that Big Tech tells us, including about AI, and what we can do to resist.  One of the lies that really resonated with me is that our work is too difficult. Why should we have to do hard things ourselves? Better to give it to AI to do on our behalf. 

What Solnit points out, as does Oliver Burkeman in his book Four Thousand Weeks (which I also highly recommend), is that it is often the friction in our work and daily interactions that makes life meaningful. By friction, they don’t mean conflict, but rather things like needing to interact with a human barista to order a coffee as opposed to ordering through an app or screen. For me, tasks with good friction would also include mowing the lawn or shoveling snow, which, while involving time and effort on my part, are also opportunities to be physically active outdoors in the fresh air away from my computer screen. Or, the friction involved in writing an index. For me, at least, it is the intellectual labor of problem-solving and learning interesting things, along with feeling like I am part of a larger team working together to produce the finished book, that makes indexing a meaningful and worthwhile endeavor. 

Of course, no one wants their life to be all friction. What is a pleasurable challenge for one person may be someone else’s mind-numbing drudgery. For me, while I probably could design a new website for myself, it is not my top interest or skillset and I’m happy to hire someone else. I also see this with authors and publishers who hire me to write an index. Could they write the index themselves? Probably, given enough time and maybe some coaching. But they already have enough difficult things to do and hiring an indexer is easier. 

So the value of work, for our satisfaction and well-being, lies partly in its difficulty and our ability to overcome that difficulty, yet we don’t want everything in our lives to be difficult. Doesn’t this swing back around to the value of AI or other Big Tech tools? Why hire a web designer or an indexer when you can instead hire an AI tool to do the work for significantly cheaper and faster?

I think this speaks to another lie that Solnit identifies, which is the scarcity of people. It is too hard to find someone qualified and available. They probably don’t exist anyway. Better to use AI, which is always available.

I think this lie is quite insidious and perhaps a self-fulfilling prophecy. If we, as a society and industry, don’t nurture human talent, is it any wonder that it may disappear? But that human talent does exist. And the friction of interacting with other people, to delegate and work together, makes the work more meaningful. It cuts through the isolation of being siloed alone with my computer and whatever apps Big Tech sells me.

I am concerned about the new AI indexing tools which are being developed. There is the concern of whether those tools will ever develop to the point of being legitimate competition to the quality of human-written indexes. There is the concern of whether some publishers, in their push to industrialize publishing and squeeze out all the profit for themselves, will use AI anyway, despite quality issues, simply because it is cheaper and faster. Those are excellent concerns and worth paying attention to.

But what feels even more existential to me is the question, do I even want to work with AI indexing tools? Even if I could leverage such tools to work five or ten times faster, indexing ten or fifteen books per month instead of three to five, would I still enjoy the work? Would writing an index still be a satisfying intellectual puzzle? Or would I be delegating most of that intellectual labor to the machine, and churning out indexes too quickly to meaningfully absorb and process what I am reading and piecing together?

I think the answer is no, I would not enjoy that kind of work.

I have to admit I am starting to think about how I may exit indexing if the industry changes too much and human-written indexes are no longer valued. What else could I possibly do where I can continue to problem-solve, be creative, and still feel like I am part of a community of people?

Thankfully, I don’t think I need to make a decision yet. The silver-lining, perhaps, is that the publishing industry is vast and segmented. Even if some segments turn to AI tools—and I’m pretty sure some will, the same segments that are already heavily invested in contracting to offshore companies and industrializing the production process as much as possible—I’m hopeful that not all segments will. Some publishers are still committed to creating quality books and to working with human freelancers. 

I don’t want to be completely against AI. It sounds like there are some areas in which it is genuinely useful. And I don’t want to alarm you too much, especially if you are new to indexing. I want to believe there is still a future for human indexers, and that the work will continue to be challenging and meaningful in all the right ways.

I think it is also important to try to be aware of new developments and to think through all implications, beyond the hype and lies that Big Tech wants us to focus on. 

If AI tools are adopted by indexers and in the publishing industry, they need to be accurate and reliable, obviously. But more than that, they need to support human work and human workers. Replacing indexers (and editors, designers, etc…) does not make for a healthy work environment, nor, I would suggest, for books that are written and produced with humans in mind. For an industry and world in which humans can thrive, people need to be kept at the forefront. 

With a full schedule also comes scheduling challenges. Part of this is on my end, if I underestimate how long an index will take to write or if something else comes up that sets me back. Running late on one project can snowball into the next, and before I know it I’m running behind for the next few weeks trying to catch up.

On the other end are clients with delayed, shifting, or vague schedules. Sometimes this works to my advantage. I’ve had two projects originally slated to begin in September which I am thankful are now delayed. Sometimes this works against me. It seems like almost every project I’ve been offered for November and December have come with the qualifiers “maybe” or “probably.” Should I expect three or four proofs to all arrive at once or for the indexes to all be due in the same week? Or will they be nicely staggered? I don’t know. 

All of this busyness and uncertainty has prompted me to think more intentionally about how I book and schedule projects. While I do keep a fairly full schedule, I don’t enjoy being too busy and feeling overwhelmed. 

I’m being more intentional in the following ways:

• Checking in with clients a month before proofs are due. Sometimes, even two or three months in advance, if the original schedule was tentative and I’m trying to see if I have space for another project. In the past, I would check in with some clients, but not all. My new policy is to check in with all clients. It is not that I don’t trust my clients, but rather an acknowledgment that even my best clients are often busy and may forget to send an update. More importantly, I need to be responsible for my schedule. Being proactive about checking in is giving me a greater sense of confidence in my schedule, and, so far, has helped to identify a couple of delays earlier than I would have otherwise heard. 
• Being open with the client if I am not a hundred percent confident about the schedule. This may mean telling them that I can’t fully commit until they give me firm dates. This may also mean being honest that I have a number of other potentially overlapping projects at that time and that I don’t fully know what my schedule will look like. Being open like this accomplishes two things. One, it gives the client an out if the client prefers an indexer with a lighter schedule and a firmer yes. Which has happened and I don’t blame the client for going elsewhere. Two, it gives me an out if my schedule becomes too full. When I accept a project, I fully intend to do my best to honor my commitment, but if my schedule turns out to be truly too full, I don’t want to be stuck juggling too much.
• Develop my subcontracting capacity. I’ve begun telling potential clients, especially if I’m uncertain about the schedule, that I may want to bring on a subcontractor. This gives me another option without having to give up the project entirely. I don’t want to spring this on the client at the last minute, and so I am bringing this up early in case the client is not comfortable. In terms of developing subcontracting capacity, I am creating resources for subcontractors, including my own style guide, and providing a lot of feedback so that the subcontractor and I can learn to be on the same page.

I am already seeing benefits from this more proactive approach. By being more open, I am not making unrealistic promises and I’m presenting different options for delivering the index on time. I’m able to learn sooner if there is flexibility with the schedule. I feel more confident that I have the support in place to deal with unexpected shifts without too much additional stress. 

Subcontracting on a more regular basis, like I am trying to develop, as opposed to maybe a couple of times a year, is a change for me and still a work in progress. I’ll have a better sense in a few months how it is going. But I’m pleased so far and am feeling hopeful. 

I have long thought of myself as a small, one-person business. Managing a host of subcontractors and producing hundreds of indexes per year does not appear to me. And yet I do feel my limits as a single person. Perhaps what I want is to remain a small business while also having good support, a buffer against the uncertainty and the shifting and overlapping schedules. I think scheduling will always be a challenge, but it can be anticipated and managed. That is what I am trying to become better at.

I’ve written before about AI, here in 2023 and again in 2024. I’ve been thinking for a few months about writing on this topic again. Perhaps this will turn into an annual AI reflection, as the technology progresses and as society and publishing adapt.

Indexers are no exception to talking about AI. I think it has been on the agenda at just about every indexing conference in the last year or so, in Canada, the UK, and the US. Which is good. We need to be aware of what is happening and what our options and response are.

Elizabeth Bartmess, in the US, and Tanya Izzard, in the UK, have both been particularly active, and perhaps the most visible, researching and testing AI’s indexing capabilities. My thanks to them for all of their work. By AI, Elizabeth and Tanya specifically mean large language models (LLMs) such as ChatGPT and Claude, which is what most people think of when they hear the word AI.

For a quick reference of recent articles and resources, here’s a little round-up:

• Tanya Izzard has published two recent articles on AI. The article published in The Indexer is behind a paywall, while the article published in Catalogue & Index is open source and freely available. 
• The Digital Publications Indexing Special Interest Group (DPI-SIG) has released a statement on AI in indexing, prompted by Elizabeth Bartmess’s presentation at the ISC/SCI conference in Vancouver. The DPI-SIG has also created template versions of the statement for individual indexers to use.
• The American Society for Indexing (ASI) has released a white paper, by Elizabeth Bartmess and Michele R. Combs, on LLM-generated book indexes.

Bottom line: current LLMs do not write good indexes. 

AI-Powered Indexing Software

Indexing software utilizing AI is also now on the market. I expected this would happen and I have mixed feelings about it finally happening. There are currently two programs available that I am aware of. 

IndexStudio appeared first, earlier this summer. It is created by Peter Tanham and claims to create a full draft while also providing tools to edit the resulting index. I tried its free trial, which did not allow me to use the editing tools, but if the sample index it allowed me to see is any indication, it does not do a thorough job, showing many of the same problems found elsewhere by Elizabeth and Tanya. A few other indexers have tested IndexStudio more thoroughly, and have also found it to be significantly lacking. 

I also don’t trust the claims that Peter Tanham makes about IndexStudio. The testimonials on the website are obviously fake, as a google search fails to find any of the quoted indexers, authors, and scholars. The website also clearly sees Cindex as a direct competitor. It is hard to not get the impression that IndexStudio is intended to disrupt the indexing profession, as in replace professional indexers. Yet Peter left a comment on my blog claiming that IndexStudio is actually created for self-published authors and is not intended to replace professionals. I agree hiring a professional indexer is often expensive for many authors, which is a problem. But offering a poor quality alternative does not strike me as a good solution, and disingenuous marketing and messaging makes me suspicious.

AI-indexing, created by Ben Vagle, launched a couple of weeks ago. Ben also wrote an article explaining the program. This seems designed to be more of an assistant to professional indexers, rather than claiming to create an entire index by itself. The instructions explicitly state that the output will need further editing. The output can also be exported to Cindex, which is promising as Cindex does make editing a lot easier. I have thought that if AI was ever used in indexing, it would work best in an assisting role, so this program might be a step in the right direction. That said, I have been too busy this month to try this out, so I can’t comment yet on whether AI-indexing lives up to its claims.

AI and the Nature of Indexing Work

Much of the discussion around AI and indexing has focused on whether or not LLMs can actually write an index. Which is a very important question. I have no interest in using a tool that fails to deliver what I need. What I have not seen so much, beyond a fear that AI may replace indexers, is a discussion on how AI may change the nature of indexing.

I write indexes in part because I enjoy the creative and intellectual challenge of analyzing a book and piecing together an index that will serve readers. To write an index is to solve problems, trying to find the perfect balance between the contents of the book, the needs of the audience, and the space available on the page. It is difficult work, and rewarding because it is difficult. 

Is AI going to take away that sense of challenge and creativity?

A common fallacy about indexing I’ve noticed in non-indexers is the belief that writing an index is simply a matter of identifying and picking up terms. Before AI, this manifested as creating a list of keywords and using the search function to search PDF proofs for all relevant hits. When I first learned to index, in-house, my supervising editor sometimes used this method, seeing it as a way to get started on the index—creating the word list—before the proofs were ready.

But an index is more than just a list of key terms. Yes, there is an element of searching for terms, and some books lend themselves to keyword searches more than others. But an index also requires paying attention to the implicit content, which is often also indexable, as well as how the book is organized and structured. An indexer considers the audience and shapes the index accordingly. An indexer also shapes the index to fit the pages available, which can lead to drastically different indexes depending on how limited the space is.

All of these decisions, beyond identifying keywords, are uniquely suited to humans. It is a question of priorities, trade-offs, and knowing how to manipulate the index in response to the particular context of each book and audience. My concern with AI tools is that 1) the tool makers are operating under that fallacy, focusing on keyword search, and not making room or providing tools for these other aspects of indexing, and 2) that AI tools, by allowing the user to be more hands-off, will enable users—whether authors, publishers, or even indexers—to fall into that fallacy and to assume that whatever the AI produces is good enough. 

How can we keep indexing human centered, both the creation of indexes and their usability?

My other fear with AI tools is that instead of me being in control, problem-solving and making decisions, that I will become an assistant to the AI. By letting the AI create the first draft, I am ceding that initial decision-making about what is relevant and how the index should be structured. Instead of my approach guiding the way, I’m editing what the AI wants to do.

I wonder what is lost in that.

For the index, I fear a loss of value and usefulness. I don’t think an algorithm can properly discern what an audience needs or wants, or how to prioritize and juggle competing demands if space is tight. Not that I or any other human indexer will always get it right either, but I like to think that a human, coming at this from a human perspective, will usually do a better job. If I am simply editing what the AI decides, I am concerned that whatever errors are present, even subtle errors, will be reinforced rather than corrected. 

For myself, I fear a loss of creativity and meaning. For better or worse, and as difficult as it can be, I thrive on problem-solving and bringing order to chaos. This is part of what makes me human. If I surrender these aspects of my work to AI, I don’t think I’d want to index anymore, to be honest. I’d find some other line of work that allows me to be creative and to problem-solve. Maybe it is egotistical of me to say that I need to be in control, but I feel like there is something lost in my humanity if I give responsibility for the index to the AI and my role is simply to clean up what the AI produces.

Considering all of this, I’ve also been asking myself the question, is there a difference between using an AI tool and hiring a subcontractor? What is the difference, really, if in both cases I am delegating a portion of the index while retaining the final say? I have to admit I am struggling with the answer. I want to believe that a human subcontractor is inherently better, with their human perspective, which gives them the ability to look beyond a keyword search and the capacity to learn and incorporate feedback. Trust is also an important factor, in that I can build trust with a human subcontractor as we work together and they learn what I am looking for, whereas I have very little trust in an AI’s ability to learn and deliver. Corrections to an index are often very specific, not index-wide, like I assume an algorithm would try to impose. Perhaps it depends on what I am asking the subcontractor or AI tool to do, as sometimes all I want is a simple list of all names or scripture references, for example, and other times I do want the subcontractor to take on a larger role shaping the index.

At this point, the question of AI tools versus subcontractors is still theoretical. I don’t trust AI tools enough and I value what humans bring to the job. But if AI-powered indexing tools progress, this is a question that will need to be answered. Both by indexers who do use subcontractors and by all indexers on if and how to adjust how they work.

This question of subcontractors also ties back to my concern about who is assisting who when using AI. Subcontracting does involve giving up some control over the work, but I feel like the lines are still clearer with subcontractors. I can be clear about what I ask the subcontractor to do, in my review of the subcontractor’s work, and in what I retain for myself. With AI, the lines seem blurred. AI is so fast and at least gives the illusion of power and accuracy that it can be easy to trust the output, to the point where it is no longer really my index anymore. For an AI tool to be effective and for me to feel good about signing off on the index, it clearly needs to be a tool under my control, with me understanding the text, audience, and any other constraints, and making decisions accordingly. 

Ethics and Legalities

The last consideration, which is also important to keep in mind, are the ethical and legal dimensions of using AI tools for client work. At least one of my publisher clients has explicitly forbid all AI tools while working on their books. I think that policy is subject to change, as tools evolve and as privacy issues and concerns may be resolved or allayed, but for the time being I think AI in publishing remains a fraught subject and I want to respect my clients’ policies. If I ever find an AI-powered tool that I want to use, I would need to first discuss that with the client before using it with their books. 

What do you think about AI and indexing? Or about AI in general? Have you found any instances in which an AI tool is actually useful? Feel free to respond and let me know. I am curious.

As I’ve tried to explain above, I have questions and concerns about AI, not only about whether AI tools can produce quality work, but also about how it may change the nature of indexing work and how it may affect what makes us human. The claims of AI are very different compared to software such as Cindex. Cindex is powerful in its own right, but it still requires me to manually create all of the index entries and decide how the entries are structured together. Cindex is clearly a tool under my control. AI has the potential to blur that distinction. What is the effect on me if my role transforms into feeding the machine? I am concerned about the unintended consequences, both for indexers and the indexes we write, and wish I had more answers. Time will tell, I suppose.

Tree planting, if you are unfamiliar, is seasonal work in which crews of mostly young people replant forests after the loggers have gone through, and sometimes also after forest fires. (I have the sense that tree planting, as I experienced it, is a distinctly Canadian job, though I could be wrong.) My Dad, two uncles, and an aunt all planted while in university, and so once I was university-bound, it felt natural and somewhat like a rite of passage for me to also go planting. In the interior of British Columbia, where I planted and where my Dad’s family is from, the planting season typically runs from the beginning of May to the end of July, which fits well with the university calendar. Planting can also be an excellent way to earn a lot of money quickly—I earned enough to cover tuition and living expenses for the year—provided you work hard, are willing to tolerate rough living and working conditions, and, most importantly, can learn how to plant fast. 

Tree planting is piece work, with the price, at least twenty years ago, averaging 9 to 11 cents per tree, sometimes a little more or less. Given how grueling the work is, spending all day outdoors on a clearcut, miles down a logging road in the middle of nowhere, while living in a tent in a camp with 60-80 other tree planters, it only feels worthwhile if you can earn more than a job in-town. My goal was to earn at least $200 per day, which meant planting at least 2000 trees per day.

The thing with planting and speed, though, is that it takes time to learn proper technique. To some extent the rookie year is a write-off, with the real money made when you return.

The procedure for planting a tree is as follows:

• Load up planting bags with 300 to 400 seedlings, a mix of pine and spruce. The bags are attached to a belt, strapped around the waist, one bag on each side with a third bouncing in the back. (I didn’t like how the weight felt in the back, so I loaded trees on my right and left sides, with my back pouch reserved for my water bottle.)
• Find the line on your piece of land assigned by the foreman. 
• Take three to five steps, scanning the ground for a good planting spot. Look for a high spot, well drained, ideally with creamy soil or red rot. Next to a stump is usually a good option.
• While stepping forward, reach into your bag with your tree hand and pull out a seedling by the root plug. 
• Also while stepping forward, raise shovel, with your other hand, and, when ready, throw it into the ground blade-first. (We would throw the shovel—precisely aimed—and release at the last moment to minimize impact on our hand and wrist.)
• In one fluid motion, open the whole using a curved stroke; insert the seedling, making sure that the root plug and tree are standing straight; and close the hole, either with a fist or a gentle kick. 
• Take three to five steps and repeat. 
• Oh, and well doing all of that, also occasionally rip off and drop pieces of flagging tape so you can see where you previously planted.

Easy, right?

Ideally, it takes ten seconds or less to plant a tree. Which is fast. You need to be in constant motion. Stopping to take a break or meandering across the block costs you money. But speed is only part of the equation.

The secret to planting quickly is to have no wasted movement. The eyes, hands, and feet all need to work in sync. While the eyes are looking ahead for where to plant next—while also watching out for branches, logs, and stumps, which are simultaneously tripping hazards, obstacles to maneuver around, and potential clues for where to plant—the hands and arms are already in motion, one hand selecting and preparing a seedling, all by feel, while the other arm is swinging and throwing the shovel. Bend over and both hands need to work together to open the hole, insert the tree, and close the hole.

It is tempting to move fast before the technique is locked in. After all, speed is money and we all wanted money. But my foreman, Hank, insisted that us rookies first learned proper technique. Yes, this meant that we would be slower in the short term. But an extra stroke or two with the shovel, multiplied 1500 or 2000 times over the course of a day, adds up. Fumbling for a tree, 1500 or 2000 times a day, adds up. Learn to plant efficiently and correctly, and more trees will get into the ground with less effort. 

(Not only was wasted movement costly in terms of time, but poor technique could also lead to poorly planted trees. If the checkers found too many problems—j-roots, too shallow, too deep, leaning, too close together, too widely spaced, poor locations—you were sent back to replant, which meant planting the same tree twice but only paid once.)

Hank also taught speed, once he was satisfied with your technique. Hank would either plant alongside me or walk in front, pointing out good planting spots. These sessions were usually short, maybe 10 or 20 minutes, but they left me scrambling to keep up and they gave me a taste for the pace I needed to aim for. Until Hank pushed me, I had no idea my body could move that fast over a chewed up cut block while carrying 400 seedlings. 

That first summer, I hit the 2000 tree mark only three or four times. By the time summer plant rolled around, in July, my technique was getting pretty good, but the terrain and planting conditions got more difficult and I was burning out. My second season, though, I hit 2000 trees within my first few days back and consistently pounded in 2000+ trees every day for the rest of the summer. I was officially a vet, no longer a rookie.

(To put this in perspective, consistently planting 2000 trees per day is a good benchmark for separating vets from rookies, though the real highballers in camp would consistently plant 3000+ trees per day. I never did crack that milestone, and I retired from planting after two summers to focus on less lucrative but more relevant summer employment, which eventually led to me learning how to index.)

Bringing this back to indexing, I still think in terms of technique first, speed second. Or, better yet, as an iterative cycle. Start with technique, add in speed, then go back to technique to see if anything can be adjusted in light of the new speed, and on and on. 

There are definitely ways to become more efficient and fast while indexing, including utilizing software, keyboard shortcuts, and creating macros, but while having their place, a macro, for example, can’t fix a poor understanding of index structure. Or, rapidly picking up and then deleting irrelevant entries is probably going to take more time than accurately assessing from the start what is indexable. 

If you want to be a quick indexer, start with learning and internalizing indexing fundamentals and best practices. Learn how to make better decisions and cleaner drafts. It may feel like slowing down in order to think through decisions, but these are decisions that will hopefully set you up for a strong finish. And yes, also add in macros and other shortcuts, and experiment with your process, but keep coming back to technique. What makes for a good index? How can you refine your process to support writing a good index? Start with quality, and speed, to some extent, will take care of itself.

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.

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?

A few months ago I started tracking my time when I index. I had previously done so, but not effectively and I eventually gave up. This time, I’ve created a new system and a new spreadsheet that is much easier to use, and I am a lot happier with the results.

One of my insights so far is that I spend about an equal amount of time drafting and editing. I have to admit that this surprised me. I knew that editing took up a fair amount of time, but I didn’t realize that the time spent is often about 50/50. For some indexes, I actually spend a little more time editing, making the time split closer to 45/55 or even 40/60.

Reflecting further on my process, I tend to spread drafting the index over 3-6 days, depending on the length of the book. Whereas I tend to edit within 2-3 days. When drafting, I am learning what the book is about. When editing, I am fully immersed in the index and I treat it more like a sprint. It probably also helps that by the time I get to editing, the deadline is looming.

I’m realizing that I also tend to draft quickly. I do try to write a fairly clean draft, taking into account context, clarity, and relevance, as I previously discussed. I believe in trying to set myself up for an easier edit. But I also know that this is not my final draft and that some things won’t become clear until I’ve read the whole book, and so I also try to keep moving.

Editing an index, for me, is both seeing the index as a whole and going through the index line by line. I like to give myself space between drafting and editing, which usually means sleeping on the draft and beginning to edit the next day. This helps to give me some distance so I can more clearly see the whole index with fresh eyes.

I usually begin by skimming the index, making note of the larger arrays for the metatopic and supermain discussions. This reminds me of the structure I am aiming for, and is a chance to consider if I want to make any major changes. I then start at the top of the index and work my way down, line by line. I know some indexers edit using multiple passes, each pass looking at a different element. I think I would go utterly cross-eyed and unable to make sense of the index if I tried multiple passes. Instead, my goal is to fully edit the array in front of me before I move on to the next. This may mean jumping around the index to also edit related arrays, and sometimes I will go back to re-edit an array if I change my approach, but generally speaking, I systematically move through the index.

With each array, I am first of all looking for clarity. Does the main heading and any subheadings make sense? If there are subheadings, I look to see if any can be combined or reworded, or if subheadings need to be added for unruly locators. I consider if anything needs to be double posted, and check to make sure that is done properly. I consider and check cross-references. I investigate any notes I may have left for myself. I also spot-check a few locators to make sure I understood the text properly. I may also run a quick search of the PDF to see if I missed any references. I don’t check every locator, which I think would be very time-consuming—to a certain extent, I need to trust that my drafting process was thorough and accurate—but these spot checks do provide peace of mind and I do sometimes find errors.

Reviewing arrays with no subheadings is usually quick, unless I’ve left a note for myself or I decide to spot check. Arrays with subheadings take more time. If an arrays has 20+ subheadings, I may spend as much as twenty or more minutes making sure that the array is in order. I often find the larger the book, the larger the index, the more subheadings there will be, and the longer editing will take.

Considering my process, I do wonder if I can shave off time. I could spot check a little less, especially for simple arrays with no subheadings, trusting that I picked up what was necessary. I can also pay more attention, when drafting, to larger arrays, so that editing them isn’t so onerous. I could also explore using more macros and patterns for batching tasks such as double-posting or removing subheadings. What I like about my process, though, is that it is thorough and I can clearly see what is completed and what is still to come. Editing line by line helps to keep my thoughts in order.

Other Approaches to Editing

My approach to editing is not the only approach, of course. I’ve mentioned making multiple passes. I also know of indexers who do a quick edit at the end of each day, while drafting, so that the draft is cleaner. I’ve also heard indexers who say that they do such a thorough job drafting that the editing process only takes them a couple of hours. I don’t know how that works for them. I seem to need a lengthier editing process for the index to gel and come together. And that’s okay. We are all different. What matters is that you find a process that works for you.

I find it interesting to hear how others index, even if it is not something I would do myself. I hope this glimpse into my process gives you something to think about.

But…in indexing there is always a but. Occasionally, a project comes along that proves the exception. 

This happened with a recent index I wrote, for To See What He Saw: J.E.H. MacDonald and the O’Hara Years, 1924-1932, by Stanley Munn and Patricia Cucman (Figure 1 Publishing, 2024). J.E.H. MacDonald was a Canadian painter and a member of the Group of Seven. He fell in love with the landscape around Lake O’Hara, in the Rocky Mountains, and spent several summers there painting. This book takes an interesting approach to MacDonald. Over the course of almost twenty years, the authors sought to identify the exact locations where MacDonald painted. The bulk of the book is composed of a brief discussion of each of the O’Hara paintings, alongside a photograph of what the scene looks like today. The rest of the book is composed of an introduction, an overview of each of MacDonald’s eight trips, and excerpts from MacDonald’s diaries and other writings. The result is a beautifully illustrated coffee-table book. 

The instructions from the press were to only index the paintings, people, and places. While narrow in scope, there isn’t too much else discussed, and these are what readers are most likely to want to find, so I thought the instructions reasonable. Figure 1 Publishing is also very good at providing clear specifications for how long the index can be. For this book, the specs were 55-60 characters per line, for 675 lines total. 

I quickly realized that the book mentions a lot of paintings and places. The book discusses 226 paintings, almost all of them by MacDonald. With each painting taking up at least a line, some of them more, the paintings alone fill up about a third of the index. The rest of the index is mostly places—mountains, lakes, creeks, trails, huts—in and around Lake O’Hara that MacDonald either painted or visited. In comparison, only a few people are mentioned.

I also realized that the book contains a lot of repetition. For example, the same mountain may appear in a couple dozen different paintings. That mountain is mentioned again in the overviews of MacDonald’s trips, and then again in MacDonald’s diaries. This kind of repetition makes sense given how the book describes the same events and paintings from different angles, but it does mean that the mentions add up. Arrays with especially long strings of locators include Cathedral Mountain (49 page references), Hungabee Mountain (39 references), Odaray Bench (34 references), Lake McArthur (32 references), and Lake Oesa (27 references).

Normally, I would add subheadings to these arrays. Asking readers to look up each page reference is a big ask. But for this index, I left those strings, for paintings and places, intact. 

Not using subheadings was a conscious decision, and one I didn’t make lightly. My initial instinct was to find subheadings. But as I indexed and considered the entries, I also realized that subheadings would not be so useful in this particular index. Wanting a second opinion and to avoid surprising the press with a departure from my usual approach, I also queried the editor I was working with and got their approval.

I decided to not use subheadings for two reasons. One, I realized that too many subheadings would quickly make the index too long. Unfortunately, space constraints can sometimes mean putting aside the index that you want to write for the index that fits. In these situations, I need to be strategic about picking and choosing the subheadings that will have the biggest impact, while also being okay with other arrays not having subheadings. 

More importantly, though, for this book, I couldn’t think of subheadings that I was satisfied with. For subheadings to be effective, they need to clearly articulate additional information that readers can use to narrow their search. But what if there are no clear distinctions between locators? In that case, I think the long strings of locators should be left alone. It is not helpful to introduce artificial distinctions or to get so granular that context is lost. 

As I mentioned, this book contains a lot of repetition. Places either appear in MacDonald’s paintings, are places that MacDonald visited, or both. This doesn’t provide much to hang a wide range of subheadings. 

I briefly considered listings all of the paintings that each mountain or other feature appears in, along with a subheading for MacDonald’s presence at. For example, 

Cathedral Mountain: MacDonald at; in painting 1; in painting 2; in painting 3; in painting 4; in painting 5; etc…

But this approach presents a few problems. Some arrays would have been enormous, with a dozen or two subheadings for each of the paintings. Besides the space issue, I’m not convinced that listing each painting would have been meaningful to readers. Would readers remember the titles of individual paintings? In many cases, multiple paintings shared the same title. Thankfully, the authors give each painting a unique alphanumeric code, which I included in the index to differentiate. For example, “Lake O’Hara (25-1.3(S))” and “Lake O’Hara (30-3.1).” But I imagine it would still be difficult remembering which is which. Alternatively, I could have created a subheading for “in paintings,” but that would have still resulted in a long string of locators, as would the subheading “MacDonald at.” “MacDonald at” also isn’t very useful since readers can presumably assume that MacDonald was there, as that is the focus of the book. 

Given the space constraint and that either way—with a couple of generic subheadings or without subheadings—the arrays would have long strings of locators, I decided it was best to keep the arrays simple and to forego subheadings. This does mean that readers will need to search through each locator, though readers should also quickly notice the repetition, and it is all there for the dedicated searcher. 

This isn’t to say that I avoided subheadings entirely. I did use them in a few places, mostly for people, though even with people I found it difficult to avoid longer strings of locators. Many of these references are brief mentions and again reflect the repetition throughout the book. For example, here are two arrays for MacDonald’s friend, George Link, and wife, Joan.

Link, George K.K.
     about, 234, 343n83
     Lake O’Hara Trails Club and, 340n25
     MacDonald and, 82, 91, 104, 107, 113, 114, 143, 215, 224, 233, 234, 239, 243, 249, 252, 253, 254, 256, 258, 264, 294, 301, 307, 308, 310
     photographs, 246, 260

MacDonald, Joan
     encouragement from to travel west, 13, 202, 205
     letters to, 93, 96, 115, 120, 121, 122, 131, 167, 175, 200, 203, 204, 205–6, 211–12, 229, 230–31, 236, 240, 256, 265
     Links and, 341n47
     MacDonald’s departure west and, 250
     mentions in MacDonald’s diary, 304, 308
     O’Hara trip with MacDonald, 36, 123, 191, 217, 221, 222, 223–24, 259
     photo album, 224

While I highly encourage you to include subheadings and to make sure that subheadings are clear, specific, and meaningful, I think it is also worthwhile considering the exceptions to the rule. I hope that my approach to the index for To See What He Saw, about J.E.H. MacDonald’s paintings in and around Lake O’Hara, is helpful for considering when subheadings may not be useful. If there is a lot of repetition in the text, if it is difficult to find meaningful distinctions, and if there is a hard space constraint, then it is okay to have long strings of undifferentiated locators. It is not ideal, but it may still be the best solution for that particular text and index.