While I agree with the previous assessment—that this is not usually something done by the author themselves during the very first draft of a text, but rather by a specialist who is looking at the completed whole, and can assess where best to guide readers—Scrivener does in fact have some automatic tools for producing one. It may be sufficient for personal projects, or as a starting point for later refinement.
For a basic test you can make use of one of Scrivener’s built-in conversion to generate an OpenOffice document. LibreOffice is a good free word processor for working with this format, in case you need one. I’ll also provide instructions for installing a third-party converter, Pandoc, which Scrivener integrates with. Using that, you can create Word DOCX files.
The main difference between this approach and a more general-purpose use of Scrivener is that the underlying conversion process is more flexible, and allows you to basically fine-tune it as you require—not everyone will want or need to do that, but the option is open to you. Case in point is this very capability, indexing. That is not a feature, but rather a process that was built using the software’s ability to build things like that.
On the surface though, it isn’t all that different from how anyone else would use Scrivener. I would say the main difference is a heavier reliance upon using styles to communicate the text’s structure, rather than pure and meaningless formatting. In most cases this won’t be a downside since using stylesheets is often advantageous for many reasons, and will often be encouraged by those you will work with on the publication and editing side of things.
Here’s a very simple demonstration—it may look lengthy, but mainly I’m going into detail here since you mention being new to everything:
- Optional: First run the Pandoc installer (or use homebrew if you prefer), and relaunch Scrivener. It should recognise the installation and add additional compile options. Again, if you’re fine testing with OpenOffice, then skip this—we’ll be using an embedded converter for that.
- To test the approach, just create a new Blank project. Disposable projects to test things out are something I like to do, but if you find this a useful starting point it can become your working project too.
- Paste some lorem ipsum into the starter document. I prefer using
Edit ▸ Paste and Match Styleto strip out all of the unwanted website formatting. - Rename the starter document to something like “Index Test”.
- At this point you need to create a couple of styles. You’ll be using these to (a) mark words that should be indexed, and (b) add invisible indexing keys into the visible text.
- Double-click on any word in the sample text, and use the Format menu to give it some kind of visual flair. This is entirely up to you. How do you want a word to look so that you can tell at a glance that it is indexed? Maybe it just uses green text.
- With the formatted word selected, click the
+button in the floating Styles panel, and create a new style with the following settings:- Name: “Index Term” (it’s important you provide the name just like that. If you want to get creative you can, but you’ll have to customise settings things later on).
- Formatting: “Save character attributes” (you don’t want the whole paragraph in the index!)
- I’d disable both the font switches, but the rest of this panel is arbitrary.
- Repeat this process for the second style, naming it “Index Key”. This will be for inserting keys into the index that aren’t otherwise printed in the output. Consider using the styles highlight feature for either of these as well, if you find a stronger visual cue is desirable.
- So at this point, since you’ve created two styles from a couple of the words in the sample text, they are already styled, meaning you have an index with two entries already. You could add a few more if you wish. Just select words or type them in and use the Styles panel to indicate them.
- When you’re ready to test output, use the
File ▸ Compile...menu command and click on the Compile for setting at the top. If you installed Pandoc, then select the “Pandoc → Microsoft Word” option. Otherwise select “MultiMarkdown → OpenOffice”. - From the left sidebar select either “MMD OpenOffice Document” or “Pandoc Word Document”.
-
Optional: You could just leave the Section Layouts alone for this simple text, but if you want to see how a table of contents could also be easily added, then assign the “Text Section with Heading” layout. Click on the
Assign Section Layoutsbutton below the preview column, and click on the indicated preview tile (there should only be one type of document in this simple text, but in more complex projects you may have multiple types in the left sidebar to assign). As you can see though, with this workflow your choices are very simple and purely structure. There are no fonts, no indent settings. - On the right hand side, select the General Options tab (gear icon), and enable Convert rich text to MultiMarkdown. Although in this simple example you won’t have any (styles don’t count)—you probably will at some point want to set some text it italics and have it come out that way.
- That’s pretty much it, click the
Compilebutton, and when saving the file you can opt to have it automatically opened in your word processor.
Now that you’re in the word processor, you’ll need to add the index listing to the document. I have no idea how to do that in Word, but in LibreOffice just put the cursor at the bottom of the file, and use the Insert ▸ Table of Contents and Index submenu to add an index. In the subsequent dialogue, select Alphabetical Index from the type of list, and the rest can be left default.
And there you go! And of course, that’s also how you would add a ToC. But if you decided to use Pandoc to get a Word file, do note you can have Scrivener insert the ToC for you (and indeed, it should by default). You just need to update fields to populate it upon loading.
You might be wondering where the formatting is coming from—it’s just stock formatting. You’d be doing that kind of stuff in the word processor, using its stylesheets to change the look centrally, rather than per word. Ideally though it’s something your publisher would be worrying about. That isn’t a kind of thing that you would be focussing on in Scrivener, and working this way encourages the use of the software as a pure writing tool.
And it is with that point that I would encourage you to stress test this workflow a bit. Do some stuff in this sample project that you would expect to want to be able do. Insert some figures, tables, lists, block quotes (styles!) and et cetera. Compile often (now that you have it all set up, it’s a quick one-two punch to update your test .docx file), and observe the results of your tests.
Earlier I mentioned that this approach can be “peeled back” and is more flexible than the general-purpose writing approach. We put the name of the conversion engine on the format in the compile menu for that reason: to let you know what technology you’re working with for document production. Markdown is a form of simplified structural writing that you may have seen in websites and forums—if you’ve ever put asterisks around a word to emphasise the phrase in a Discord chat or Reddit comment, that’s what we’re talking about. We’re using “dialects” of that which are much more capable of producing the sort of things authors need in books, but the idea is the same.
As you’ve seen, Scrivener can generate most, if not all, of the Markdown you’ll ever need, meaning you can largely ignore that fact (indeed, all Mac users who create ePub or Kindle books with Scrivener are unwittingly MultiMarkdown users!). But if you’re inclined toward writing in that method itself, rather than having the software generate 100% of it for you, then you can start by switching off the full rich text conversion option, and maybe switching on some of the finer controls, like still converting lists and tables, or hyperlinks. A lot of the features you use in Scrivener will always convert, like footnotes and images. At that point you’d probably want to open up the user manual and skim through Chapter 21, where this integration is discussed in much greater detail.
But like I say, that’s an optional path one can take—with the defining feature being that you can take it. I think it’s good to know what the technology is though, in broad strokes, so that if something does go wrong or doesn’t work quite like you thought it would, you can look to the web or this forum, for answers with the right keywords.