I’ve moved these posts to a more recent thread, which contains more constructive tips and links to extensive conversations on how to better mark text for later recollection.
It is worth noting that since a lot of these discussions have taken place over a long period of time, and features have been gradually added to the software in that duration, some methods such as the inline annotation and text code method mentioned above, could be as easily implemented using the style system, which when you get down to it, is really just a text-level tagging system. Which to use is more a matter of preference than clear objective advantages. Both are roughly capable of the same things, they just do things different ways. I prefer clear markings in the text because I like how accessible that is to searching, and how long-term future proofed it is (it even works in a plain-text file). Others might find it too cluttered though, and prefer how styles can embed the marking into the name of the style—where the style itself may even be invisible to the eye in the editor.
It really would be nice if I could just select some text and tag it for a character/place/etc., then have a view that shows all those snippets for a tag and allows me to jump there.
In looking at what these tools provide, we pretty much do get this result. Yes, there is no aggregator that only shows small, web search like results with a little context, but we can easily access marked text, and for those approaches that use something searchable, we can build lists from the outline where matches are found.
As with many things in Scrivener, this is one of those areas where the software really only starts to shine once you start breaking the outline down far enough to truly represent the internal structure of the text. Those with massive multi-topic sections will require more scrolling and searching than those that have those eighteen topics broken down into individual nodes.
In essence, the need for aggregating snippets drops considerably the more pin-point accurate your search results are. For how I break things down, I rarely even need to scroll because there isn’t enough text in the editor to scroll. A search result is right in my face, and a Scrivenings session of search results is bound to have less bloat around the stuff I’m interested in. Even where it does, the style navigation and format finding tools can make quick work of jumping from one point to the next.
Keeping Track of Edits
@HenryLoenwind : And then I noticed I already had inconsistencies and spent another hour finding all places I needed to change.
So on this specifically, the following is a technique is something I use whenever I do an extensive review or edit. This approach will build a track record of everything that was associated with the editing pass, storing it in a persistent fashion that can be useful for years to come.
Almost everyone is familiar with the “ticket” concept, as applied to a conversation that is created to address an issue. With customer support, it happens when opening a case for a problem. In software development, tickets are opened when bugs or problems are identified, and closed when addressed. The ticketing concept is a natural when considering revisions to a large work.
Scrivener is designed to be a platform for building workflows out of its feature set. So when we think of ways in which one could get a feel for overall editing status in the outline, there is no simple answer. It has no singular feature for that, but rather dozens of features that can be combined into thousands of different approaches, unique to each individual and even project.
The basic ingredients
One way in which you can track revisions in major projects that see a lot of iterative changes is to make use of several different features to create a simple ticketing system:
-
The outline: I create a new folder in the binder (outside of the Draft of course) for each major revision, which for this purpose, describes a collection of tickets, or individual changes that need to be made. Within that, a new “ticket” or card on a corkboard for things I want to change. This folder thus also becomes my todo list, I can add to it as I think of things to change, and come back to them later.
-
When I am ready to “open” a ticket, I pin it to the editor with the Copyholder feature, and set its Status flag to “Doing” from “Todo”.
-
As I start going through the Draft, identifying things that need work, I can jot them down in the copyholder, and make notes on the sorts of things I should watch out for that might be hard to find—casual cross-references and the like.
-
Whenever I identify an item that needs to be edited, I click into the copyholder and open the Bookmarks inspector tab. I then drag the item I need to edit into the ticket’s Document Bookmarks list. The easiest way to do this is to drag the icon from the main editor header bar into the Bookmarks list in the inspector.
That gives me (a) a list of every section of text I changed for the purposes of this edit, and (b) if I click back to the section itself, I get a back-link pointing to the ticket, in the draft section’s Bookmark list.
-
When I’m done, I “close” the ticket by setting its status to Done, and changing its custom icon to the ticked checkbox.
Since Bookmark lists show custom icons, I can see at a glance which tickets are still active for this section, if any. This is very useful, as sometimes one edit will cross-feed with another. It might spark a memory of something I should do about another ticket entirely, and if it’s right there in the Bookmarks list I can click on it, and add that thought to the preview area below it, then get back to what I’m working on presently.
Thus each revision note, or ticket, has a full list of items modified on account of it, and from each subsection in the Draft I will find list of every major edit that has changed their content in a significant way over time. I could for example see four different tickets that impacted it over the years, their full notes in the Bookmark preview area—and when I click through to load it in the main editor, can view its Bookmark list, meaning branching access to the full edit list.
Bringing together elements with minimal effort
I would put special emphasis on the notion of using a binding keyword of some sort to identify the edit. What you use is up to you (I use a very abbreviated date+time code), but if you put that into the title of the revision “ticket” and into the snapshot titles related to it, or any other inline annotations or comments that are made in relation to that edit, then all of these individual pieces come together, and are easy to retrieve whenever you need them. The Snapshots Manager can be used to find all snapshots throughout the project that reference this ID, and project search will of course also pull up mentions of the ID elsewhere.
The concept here is to minimise how much work we have to do in order to build effective todo lists and future-proof documentation of our past efforts. Instead of manually writing lists down somewhere, we depend upon search results. Instead of having a list of IDs we have to maintain, the revision folder in the binder contains that list in an easy to read format (Mine looks like “[ID] Plain-English description of the revision purpose”). Instead of having to think about this stuff in advance before we take snapshots, we can react to things we realise or remember as we edit. The simple act of pasting an inline annotation with the ID in it into a document turns it into a TODO item for that revision. The simple act of bookmarking it to the ticket records its relevance to the ticket. The simple act of removing the annotation later on marks that section “done” without having to mess with metadata or other tracking systems.
We do have to do things, but we’re doing very little, the least amount necessary, considering the overall benefits and process we get out of it.
And most importantly, we have that “ticket” binder item, which like all binder items, can be host to many other binder items nested beneath it. There is no limit to the amount of notation we can make about what we’re doing. If you are obsessive about documenting your process, you have the full project window interface to do it within; all of the tools in the Inspector to further mark up and categorise our notes-on-notes.
The benefits of using the binder to talk about the binder
It may sound like a bit of overhead at first, but it’s really not much work once I got into the habit of doing it, and it means I have a deep network of revision level markings, snapshots, inline annotations, and a wiki-like tree of references binding together all of the text impacted by each major edit.
This approach has been enormously valuable to me, for if a similar edit is required a year or two later I don’t have to go back and repeat all of the hard work in digging up multiple references to a concept throughout the draft. I can just pull up this old revision checklist’s list of impacted draft sections and go from there.
We think of things like keywords and metadata as a way of binding items together, but when considering an approach like the above, the very binder outline itself can be used to bind other outline items together in a way that is richer and more amenable to human-centric approach than a raw search result can match. Metadata can be great if all we need is a way of collecting “X” items together (such as our keywords to-do list idea above). But if “X” is something we need to articulate, understand, and perhaps handcraft a list of associations to, then storing a list of “Revision Notes”, or tickets, in your binder somewhere can be just the thing you need.
As with the Snapshot Manager, the Reveal in Binder command works with bookmark lists. A list of bookmarks is not only a record and cross-reference, but you can think of it as being a kind of saved selection. From there we can compile a slice of the draft out that has been revised for a particular purpose, by using the “Current Selection” compile group setting, for targeted proofing sessions.
That’s just one idea for how one could get a little more serious about tracking edits in Scrivener. It’s a method I like, because I find those particular tools work well together for me, and I rarely need more detail than what I can get when you combine all of that.