There is widespread confusion, even in the technical communication field, about the real nature and purpose of an index. This is unsettling, because an understanding of the role of the index is vital to those who create information products and also to those using the information products. Consequently, it is important for technical communicators to familiarize themselves with some basic facts about indexing and to dispel the common misconceptions about the purpose, use, and creation of an index.
- WHAT IS AN INDEX?
- MEETING USER EXPECTATIONS
- WHO SHOULD CREATE THE INDEX
- WHEN TO INDEX
- TOOLS FOR INDEXING
- INDEXING ONLINE DOCUMENTS
- HAVE YOUR INDEX EDITED!
- REFERENCES
WHAT IS AN INDEX?Repeatedly, surveys and studies suggest that readers rate the index as one of the most important features of technical documentation. The quality of an index (or its lack of quality) can have a significant impact on a customer's perception of the usability of a product. These findings may seem self-evident. Why then, given the importance of this navigation tool, is the index so often a last-minute afterthought--assuming that it is included at all? Part of the problem may be a lack of understanding about what an index really is.
We have observed usability tests in which people testing the material have stated that they are using the index to find information, when in fact they were scanning the table of contents. Other test subjects, when asked if they had considered using the index to help solve a problem, would flip confidently to the front of the document, point to the table of contents, and assert, "Yes, I did try to find the information here in the index."
Before dismissing such users as wildly atypical, consider that it is not just our users who are often unclear about the nature of an index. We have worked with experienced, award-winning technical writers who truly believe that an index is simply a table of contents that happens to be in alphabetical order and at the back of the book.
Such misconceptions are not uncommon, which suggests that maybe we, as technical communicators, need to do a better job not only in providing users with high-quality indexes, but also in helping to educate them in how to use an index effectively. The place to start, perhaps, is in making sure that we ourselves are clear on what an index is and what it does.
What an Index Is
"[An index] provides a gateway to ideas and information that is accessible to others. An index, whether it appears in the back of a book or on a CD-ROM, is a knowledge structure. Access to information is the added value the indexer brings to the material."
Nancy Mulvany, Indexing Books, p. 279An index is a tool for information retrieval, guiding you to the information you need. It is a separate written document that describes a particular information product. The items that appear in an index are based on careful analysis of the content and the needs of the users of that information product.
What an Index Is Not
An index is not simply an outline or alphabetical table of contents. An index provides ways of finding information that are distinctly different from those tools. Similarly, an index is not a concordance or list of keywords. Because an index identifies the location of information, it is not a place to emphasize points from the text or to make distinctions.
A good index can't be thrown together as an afterthought; it needs to be a formal part of the overall project plan.
Users of documentation don't read every word; they use the information to solve problems. In Indexing Books, Nancy Mulvany writes, "Information that cannot be located might as well not exist" (p. 3).
A good index makes content more accessible by grouping information that may be scattered by the arrangement of material in the document. Indexes help you get where you need to go fast. Moreover, when you get there, you'll find useful information, because a good index discriminates between substantive coverage of a topic and a mere mention in passing. Unlike a concordance, an index doesn't list every occurrence of a word, phrase, or topic; it only includes those occurrences that provide additive information about the topic (or subtopic) in question.
Another way in which an index differs from a concordance or word-search function is the use of cross-references. Because not everyone uses identical terminology for a search, an index must include cross-references to direct readers from terms not used in the index to those that are.
The needs of the user must drive the index. Sometimes it's appropriate to have more than one index (e.g., one for general topics, one for commands--both alphabetical--in a single software manual). The indexer's task is to find ways to include user expectations when designing an index, so that the index's usability extends to the navigational needs of as many different users as possible. Ideally, this may involve user analysis at the beginning of the project and usability testing at the end. Test for accuracy, adequate completeness, and proper alphabetizing. Try the index out on a sampling of real users.
A professional indexer, or at least someone trained and experienced in indexing methodology and user analysis, is the most appropriate individual to create a useful index.
Some believe that the author of a document is the person best qualified to produce the document's index. This belief is based on the argument that the writer is closest to the content and best understands the needs of that particular audience. But as we have seen, some technical writers have little value for an index, or think it is a duplicate table of contents. Others mistakenly equate an index with a concordance or with the "Find" feature in word processing software. Few have had any training in how to index. Clearly, these writers may not produce the most useful index for a document.
Hazards of Indexing Your Own Document
Though in reality many technical writers do end up indexing their own documents, there are a number of reasons why this practice may not result in the best navigation tool.
- You may be too close to the document, causing you either to omit too much or to believe that every word is worthy of an entry. The index may lack "balance," with unequal treatment given to certain content. (It is instructive to realize that Nancy Mulvany deliberately did not create the index for her own book about indexing.)
- You may not have time to do an index at the end of the project--or you may just be tired of the subject matter.
- You may not have software tools to help do the work.
- You may produce a more costly index because its creation may be inefficient, take longer, and require more editing. Although some highly experienced indexers claim to use 10 to 12 pages per hour for indexing estimates, other experts suggest an average closer to five pages per hour; your mileage may vary.
If you must index your own information product for whatever reason, it is essential to get some formal training in indexing methodology.
Our recommendation is to index at the end of the project for best efficiency and effectiveness. This of course means that time for indexing must be included in the original project schedule.
It is sometimes suggested that the writer can index a document on the fly while writing, using the imbedded indexing feature of many word processing packages. Some advantages cited for this method include saving time at the end of production and using the index tags as an editing tool to resolve usage inconsistencies and content organization problems.
The fundamental drawback of indexing while you write is that the two activities are distinctly different kinds of writing, requiring a very different focus. Even assuming that the writer possesses the necessary skills to produce a good index, the act of switching back and forth between the two modes may result in a diluted performance of both activities.
There are many software tools available to help you create an index. Before selecting a particular tool, consider some of the software issues that may affect your choice.
Tagged (Embedded) vs. Untagged Indexes
To create an untagged index (a separate document), you can use dedicated indexing software such as Cindex or Macrex (these are specialized software packages that may be rather expensive for infrequent users). Or you can use tables in a package such as Excel or Word to create sortable entries.
Alternatively, the built-in indexing functionality that exists in many word processing and page layout packages offers one way of building an index by tagging entries within the document. Because this capability is readily available in common software, it is sometimes touted as another reason for writers to do their own indexing. There are some very real advantages to doing an index with tagged entries; but many drawbacks exist as well. Before deciding to create your index this way, consider the ramifications of your choice.
Advantages of tagged indexes
- Electronic tools may be readily available in software you already use.
- Locators (page numbers) are assigned automatically.
- Indexing can start before the document is finished. (This may be a disadvantage in disguise!)
- Future revisions of text will not require reindexing the whole text; the tags will identify the proper page number when you recompile the index.
- If pagination changes at the last minute, you may be able to recover more quickly with embedded tags.
- Material that needs to appear in both printed and electronic formats may only need to be indexed once (for example, index tags done in PageMaker are easily converted to hyperlinks in a PDF file).
- Authors can create some index entries on the fly (but this makes editing essential).
- Sub-indexes for specific chapters or page ranges can be created quickly.
Disadvantages of tagged indexes
- The index tags, coded as hidden text, may be inadvertently deleted with text, which may also affect the integrity of the index structure.
- Formatting and alphabetizing options are limited.
- It may not be easy or possible to provide page ranges, especially in multi-file documents. This means that a lot of hands-on editing is needed--and if the document is later revised and the index recreated, all of that editing must be done again.
- Indexing may take longer.
- Some packages, depending on version, can't handle compound locators (a page numbered 3-1, for example).
- In some packages, the indexer cannot see any previously created index entries.
- When working in a multi-file document, depending on software, it may be unwieldy to go in and out of files to fix tags.
- Last, but definitely not least: Most embedded indexing programs create a separate file for the index itself. If you need to make changes to your index entries and you are in a hurry (which of course you will be), the temptation is very strong to edit the index file only, without fixing the tags in the text. If you do this, you will normally end up with two quite different indexes--and tags that are no longer accurate.
"Automatic Indexing" Software
Several packages now exist that claim to produce an index automatically. These can be an aid in some of the more mechanical tasks, but they are not yet the push-button panacea that their manufacturers would like to claim, and they will not produce a true index as we have previously defined it. An intelligent selection and organization of entries, based on an understanding of the content and its users, is far beyond the capabilities of the current generation of software.
Some of these packages have a degree of built-in text analysis capability, so they don't just create a concordance. They permit the user to designate word exclusions, create custom glossaries for inclusion in search, and select various levels of "depth." However, use of this type of software may lull you into thinking that the result is a sound index requiring no editing. It isn't! Someone with indexing skills still needs to work considerably with the output.
Some users claim that an index is superfluous in an electronic document, because they believe that they can find any information they need by using an online search feature. Again, the "find" feature is largely analogous to a concordance, and is a very different thing from an index. It doesn't organize the information, it doesn't distinguish important passages from random occurrences, and it provides no cross-referencing.
A sound indexing methodology is as necessary and appropriate for online information as for paper. The very size and complexity of many electronic documents, coupled with the curtailment of the reader's ability to "flip and scan," make the existence of an information retrieval tool even more critical for online access of information.
Regardless of the indexing tools used or the medium of the information product, get someone else with indexing experience to edit your index. Though often overlooked, this step in the creation of the index is critical. We have found that the accuracy and usability of any index we produce is improved enormously by the editor. Editing an index involves much more than just checking for correct page number references. An experienced index editor will clarify and refine categories, combine or add subentries, and add cross-references. Note that editing can account for over a third of the total indexing time. Ideally, the editing should be performed by someone other than the original indexer.
- Harris, Lynn A. and Jay Talbot. "Indexes: Planning for New Technologies." Intercom, March 1996: 15-16.
- Lathrop, Lori. "Considerations in Indexing Online Documents." Intercom, January 1996: 14-15, 39.
- Lathrop, Lori, Peg Mauer, and L. Pilar Wyman. "Quality and Usability in Indexes." 44th Annual STC Proceedings, 1997, pp. 264-267.
- Mulvany, Nancy C. Indexing Books. Chicago: The University of Chicago Press, 1994.
- Schimberg, Tana. "Indexing from the Desktop" (correspondence). Intercom, April 1993: 2.
- Wellisch, Hans. Indexing from A to Z. New York: H. W. Wilson, 1991.
- www.well.com/user/asi (The American Society of Indexers Web site) Includes answers to common questions.
- Wyman, L. Pilar. "Indexes Add Value Too" (correspondence). Technical Communication, vol. 42, no. 4 (4th quarter 1995): 540-541.
William L. Collins
Technical Editor
DuPont Company
Barley Mill Plaza 16/1118
Wilmington, Delaware 19880-0016
william.l.collins@usa.dupont.com
Bill Collins has 20 years of writing, editing, and training experience with the DuPont Company. He received his M.A. in English from the University of Delaware. He also presented at the 1995 and 1997 STC conferences.
Sandra M. Gallagher
DuPont Company
Nemours Building, 9424-2
Wilmington, Delaware 19898
(302) 774-0188
sandra.m.gallagher@usa.dupont.com
Sandra Gallagher has been with DuPont for 25 years, working 15 years as a technical editor. A member of STC and the American Society of Indexers (ASI), she presented at the 1996 STC conference. Sandy is also a freelance editor and indexer.
Karen J. Hamilton
DuPont Company
Barley Mill Plaza 16/1122
Wilmington, Delaware 19880-0016
(302) 892-8552
karen.j.hamilton@usa.dupont.com
Karen Hamilton has been with the DuPont Company for 18 years, working in the information design and development field for the past eight years. Karen is a member of the Philadelphia Metro chapter and has presented at three STC conferences.