I want to create a “scene list” from bits from various files of brainstorming, problem solving, character history, etc.
Is there a way I can “tag” certain phrases in various places such that everything with that tag will be poured into a new “scene list” file?
Have tried finding this in manual, dummies books, other forums but I get lost in the terminology.
Thanks from a newbie
~inawo
There are features that do precisely what you are looking to do, I think.
- Tagging text: there are two approaches, you can either put a mark in the text itself using an Inline Annotation (these can of course be stripped out when you compile). The advantage to using this method is that the tag is right in your text editor. Easy to spot, and easy to search for. The other method is Comments, which highlight the phrase in question, instead of sitting beside it, and the tag goes into a box in the right sidebar that you can hide. The advantages there are obvious, with the slight drawback that regular Cmd-F search won’t find the tags. It’s not a huge drawback though, because the Edit/Find/Find by Formatting… command can search by colour and text typed into the comment. This tool also works for inline annotations. You’ll find complete documentation on these features in the user manual PDF, in chapter 18, Annotations and Footnotes, including the format finder.
- Collections: these are your lists. There are two types of collections, general lists that you can add, remove and sort items within yourself, and secondly there are collections that are basically a saved project search, so that when you click on the tab that search is reloaded and run. The latter is what you want. You’ll find general documentation on Collections in §8.4, Using Collections, pg. 83, and specifically search collections in §8.4.3, Search Result Collection, pg. 87.
To find comments you’ll need to use the Text or All project search modes.
Thank you so much for this. I really appreciate the pointer to further understanding also, cutting through the chaos. I’ll try what you suggest and see if it achieves my aim.
Hello again…
I’ve read the texts to which you referred, thanks again for your thoughtful ideas. Unfortunately, I think these suggestions won’t achieve my aim. 
The challenge is this:
Whether in Binder or any kind of Collection, Scrivener works with files. If I were to go through my various brainstorming files (full of setting, character background, loose plot ideas, etc) and split around any phrase or line describing a scene bit (for example the phrase “leaps from window ledge” or “conversation with masked stranger”), I would have hundreds of one-line files. But even then, it would be the names of the files that show up in the search folder, it wouldn’t be a file of results.
Conversely, say I go into my various (not split) brainstorming files and mark every phrase that bespeaks a potential scene. Scrivener will oblige by highlighting each tagged phrase if I do a search, but what I need is a search results file (a file containing all the instances returned by the search). Not a collection, because that just gives the names of the files in which instances of my “mark” occur. That is: whether I place “scene bit” in brackets and search on the exact text [scene bit] -or- create an inline annotation out of each phrase describing a “scene bit”, I still have to crawl through every single file and copy and paste each instance into a “results file”. I want Scrivener to do that for me.
It just seems like there should be a way to do this. After all, even though Scrivener thinks in “files”, it can find and highlight text or formatting. Furthermore, it can detect footnotes and render them uniquely in a compiled/printed output, and footnotes are not files. I just need one extra step. I need Scrivener to take the notational device of choice (footnote, annotation, bracketed tag, whatever) and pour all the specific instances of it into one working file. Thereby leaving me with a file containing a list of delimited items, like:
leaps from window ledge
conversation with masked stranger
dark night eating sole
finally masters Scrivener
Perhaps I’ve overlooked a creative trick for doing this? 
Thanks so much for any help. NaNo approacheth.
- The first condition is not a problem in Scrivener, by and large. I have many projects with thousands of files. It’s designed to work with thousands of files. That doesn’t mean you should split things by sentences or paragraphs though, only if you feel there is merit in doing so. Nothing about the usage I’ve described necessitates splitting content much at all though, so I’m not sure why that cropped up.
- On the second point, a “file of results” and a list of file names are, in Scrivener, synonymous. That’s in part why the first point presents no problem in this software. Select five items in the Binder and hit Cmd–1 (or use View/Scrivenings). Now you have a “file” instead of five files, use Cmd-G in there to locate your markers. Ergo, a Collection (or even just a search result) is, in a sense, a “document” if you choose to view it that way. It can also be a Corkboard (by the way, if you missed it in the chapter you can load a Collection as a singular container in the editor by clicking on its name in the header bar of the binder).
I do get what you are describing I think. That concept was part of the original proposal for inline annotations—i.e. that there would be a way to gather their content sequentially based upon string matching or types into pseudo-documents. That particular idea never came to anything, mostly for performance reasons (footnotes, comments and annotations are formatting, so finding them requires opening each file, scanning it and closing it, which in a large project could be mean several minutes of sitting around waiting for the “result file” to load), but there is a slightly similar approach with the File/Export/Comments & Annotations… menu command—which works on lists of files, i.e. the documents containing the string you searched for (though not only exporting the comments/annotations that match the string).
So, since that is not a possibility or a route that the software will take in the future, the goal is find a system that works using its available toolset. 
Thanks so much for your swift response! 
I totally get what you’re saying about a time-consuming compilation, and why that wouldn’t have made the cut in ultimate design strategy.
I just looked up File>Export>Comments and Annotations in the manual. It says “Exports just the comments and annotations from the project into a single file. Optionally you can choose to export only the pre-selected binder items.”
Haven’t tried this yet, but it seems this might be close to a solution if I plan it correctly. Since I’ve not got so far yet as using either annotations or comments, and pulling scene tidbits is an early-stage step, I can probably do it this way. [Once I go through all the files the first time and collect a critical mass of scene bits, it’s simple to keep adding to the list as more occur. It’s just the initial round-up that is daunting.]
Not quite sure what this part means: “…can choose to export only the pre-selected binder items.” Is this saying I can also run the “export comments and annotations” on a limited set of files selected in the Binder? In any case I’m guessing it’s all or nothing with the comments and annotations, that if I export any, I export them all (vs just the annotations, for example).
Really appreciating your help. Though I didn’t state it explicitly, finding a way to work within Scrivener’s existing options is exactly what I’m after (vs redesigning the application 
). You’ve been kind to direct my attention to specific options in the sea of complex and wonderful Scrivener capabilities.
PS Just to be clear, my understanding of how to apply your suggestion would be to go through every file and highlight any potential scene bit and turn it into an annotation. Then run File>Export>Comments and Annotations for all files. The output would be a file with all the annotations I created (no comments used in said files). Voila. List of scene bits.
Have I grasped what you meant? Will probably be a newbie for awhile yet. Should other ideas occur to you on this quest, I would welcome your thoughts on them.
With the File/Export/Comments and Annotations method, it was really designed more for exporting one’s own comments to self, with the assumption that they would be self-contained and not heavily dependent upon their context (no context will be printed). So if you’re using short little codes (like I do), that may not be terribly useful. Test a few different methods before committing, if you think you’re going to use that tool.
Right, so you can run your search that only looks for the scene tags, get a file list from that, select those files in the search results sidebar and export the notes from only them (there is a checkbox in the export panel you’ll need to tick). That’s the most isolation you can do, within the content of the files themselves, all notes will be exported.
With the above caveat regarding not putting scene content itself into an annotation aside, yes. Personally that is not how I would do it, but there is certainly nothing wrong with doing it that way. I prefer a more dynamic approach inside the software rather than a static RTF file. The advantage of an exported list is its conciseness of course, you don’t have all of the scene narrative in between notes, but there are a few tools in Scrivener that can effectively “collapse” the distance between notes:
- The aforementioned tool that can search for annotations by colour and text. I generally do not use this tool in conjunction with Project Search or Collections as it doesn’t really have an advantage over the following method. But it works well if you’re just in the Binder and want to step through all annotations with “TODO” in them, for instance. This panel works like Cmd-F, once you’ve set it up you can close it and use keyboard shortcuts to jump to next/prev result.
- Project Search and Cmd-G. The latter of course is the standard Mac shortcut to find the next search result. When you use Project Search, Scrivener will pre-load the standard Cmd-F find panel in the background with your search term, meaning that Cmd-G all by itself will jump to the first matched instance in the document you clicked on in the search result list. Again, if you select all documents and view them as Scrivenings, this can be done in one instance rather than one per document. I’ll do that sometimes, other times I won’t bother with Scrivenings and just use Opt-Cmd-DownArrow (or you can click the down-arrow button in the right-hand side of the editor header bar if you prefer buttons) to jump to the next search result once I’m done with one file and am ready for the next
- Should you choose to use Comments instead of inline annotations, you get “height collapse” for free based on the design. Comments are stacked sequentially in the sidebar, regardless of how far apart they may be in the text, and they will be accumulated into one panel when using Scrivenings mode to view multiple documents. Clicking on a comment will jump you to the spot in the text it was marked under, no matter what document it came from initially.
So for me, to use a practical example, when I want to hunt through a project for TODO’s, I just click on the “Things to do” collection (that is a project search for “All / Exact Phrase” looking for “TODO //” (I use punctuation in my markings to keep search precise), load the collection into the main window as Scrivenings, and reference the “TODO” Comments in the sidebar (I use comments for this precisely for its automatic “index” in the sidebar).
One other idea I can think of, not using notes at all, is to use labels or keywords. That would require more splitting, but only to the scene level. If you’re pulling out scenes you might want to include in the draft, these might be best as individual files anyway—and simply tagging them with a keyword or something and then searching for that to get your list might be more productive. It depends on how you work though, some people don’t like to have a different section in the binder for each scene.
Thanks again for your time and thoughtful response.
Here’s where a Big Picture might help me frog-stroke through the muddle I face, trying to conceive of the use of these tools.
Am I correct in assuming that the tools
label
status
custom meta-data
keywords
are all applied to a single file? And that this is why each scene would need to be split off into a single file?
Whereas (in contrast) annotation, footnote, and comment can be tied to a string or position within the text of a single file?
Such that inserting some kind of text tag (such as “TODO //” or in my case “SCENE-BIT //”) can be used to locate something within the text? This would get me closer to listing the scene ideas if, indexed to each instance of “SCENE-BIT //” in the text, were a Comment containing a one-line summary of a scene idea. In which case I can
search on “SCENE-BIT //”
choose a list of suitable files from search results
export all the Comments (and annotations) of these files, and
have at least an RTF list of scenes derived from the undrafted brainstorming text.
As for using labels and status, I can assign ONE and only one value from each to a FILE, correct?
Using keywords, I can assign as many values as I want to a file, but whatever I apply still bottoms out at the level of a whole file, not specific text within the file.
Am I understanding the concept?
If so, when I glue everything together in a Scrivenings view, in order to step through all the instances for more context, what happens to the labels, status, custom meta-data and keywords? Are they simply not rendered until I return to individual file view?
PS Why the use of a double forward slash in your text-tag search term? Is this to distinguish from potential use of the word TODO or SCENE-BIT in the brainstorming text, that is, speaking about it somewhere in the file in contrast to using it as a tag?
TIA,
~Ina
No worries!
It sounds like you pretty much have it all figured out, but here are a few notes to confirm your understanding:
Correct, there is meta-data that we apply to a file, and that helps us identify and gather that file in the future, or view it more expressively in context with others (like colours on a corkboard can do). This is why I like to say Scrivener works better the smaller your outline components are, because that makes all of this meta-data more concise, which in turn makes using project search more useful, and the various listing and text aggregation features like Scrivenings mode.
It’s a rule of thumb, you can take it as far as you are comfortable with. Some people break things down far below the scene level, even to the paragraph level. I have a few places with that level of outline detail. The Scapple manual’s menu appendix looks like one formatted chapter in the finished PDF, but in Scrivener there is one single file for nearly every menu command in the software. I thus have a full big picture view of the Scapple menu tree while documenting it. Other times I have quite large files and don’t split them up, using text tools like annotations and comments to build an interior map of their content, where that content needs to be highlighted.
So yes, whatever balance you need between those extremes, I’d say. The text tools are meant to pick up where the document meta-data tools become too vague, and the whole thing is meant to be flexible and adaptable to the type of work you are doing in the project.
When you use Scrivenings view, the document meta-data for the item you’re currently editing is displayed in the Inspector. So for example you can jump to a “SCENE-BIT //” marking by pressing Cmd-G (assuming that is what you searched for with Project Search), and upon doing so, the text will be highlighted, updating the Inspector to showing the meta-data for that section with the scene bit. This is one of those reasons why a blend of granularity between document size and the use of text tags can make good partners. You might put involved characters into keywords, leave the pane open to that, and flip through scenes by “SCENE-BIT //” markings, looking for a character composition you like.
I use it for two things, the first you’ve already surmised, to make sure it stays a unique search string; all-caps alone could suffice, since you can search by case in project search options, but it’s a bit of a pain turning that on and off, I find it easier to just hit two slashes than messing with the menu. The second is a form of status. If I don’t want to just delete the to-do (or whatever) marking, maybe I want to keep the solution around for future reference, then I can change the marking to “TODO –” and now my search collection for “TODO //” won’t pick it up. I also just think it looks nice with the explanation to the right of the slashes.
Very helpful. Thanks for everything.
I’m sure I’ll be back…