I really like the upgrade.
Any possibility we’ll ever get inline tags? I would like this so that I can go right to the specific sentence in a long document.
I am using Dynalist now, which is great, but I’d rather have all my notes in Scrivener.
If we can get this, I would ask for two things with it:
Thanks,
Ray
Glad to hear you like the update!
I use a text tagging system within the annotations themselves which are a combination of an identifier string and some status symbols. An example could be:
SCI// Here is the content of my concern regarding scientific implausibility with the source text.
SCI/- Here is the content of a note which is no longer relevant; I’ve fixed the problem in the text but wish to keep the marker for some reason.
Given the punctuation pattern, I can search for these either one-by-one using the Edit/Find/Find by Formatting... tool, or the main project search (and can then save them as Saved Search Collections for rapid use in the future). Since I mark something as “done” by changing the punctuation mark, a search for “SCI//” looking for all current science problems in the book will only find those notes which are still marked as not having been addressed.
This is something I’ve written about in the past, describing my methods in the hopes they will be of use to others:
Tips for gathering markers into lists either as one-offs or automatically. Note the discussion here goes on at length, and I provide quite a lot of additional usage advice for making this system work fluidly.
Here is an older discussion that offers a less elegant technique using older mechanisms in the software.
Method for tagging text and easily gathering all tagged text into a list.
And here is a listing of older discussions that have been had on this topic in the past, along with other solutions.
Thanks so much. I’ll try this. --Ray
So this has been suggested before…
I just spent a whole day going over each of my chapters with a fine-toothed comb to find every bit of throwaway information on some characters and copying that into a resources document.
And then I noticed I already had inconsistencies and spent another hour finding all places I needed to change.
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.
Hi @HenryLoenwind,
Yes, that would be a wonderful feature, which I would definitely make use of.
It’s also one of the most requested features, and I’ve seen no responses from the L&L team that they’re interested in or able to implement it. What they have responded with though are a number of workarounds that aren’t quite as good, but may be of use to you. For example, see this post or this one. Perhaps you’ll find something helpful in one of their suggestions.
Best,
Jim
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.
@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.
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.
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.
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.
Glad to be of help!
That sounds like a good idea to me. Symbols can be useful for this, and very clear to the eye. We have no shortage of them these days, with Unicode fonts and Emoji.
What I use, incidentally, is a very abbreviated date and time stamp format: two-digit year, three-digit day of year, and three-digit fraction of the day (where .500 is noon and .999 is 23:59). This results in an ID t
hat looks like this: 22321-853, which is very compact, useful in its own right, and bound to be unique given I’m not a machine generating dozens of edits per second.
Maybe tagging comments or annotations would be easier for them to program. IDK, but yes, this would be a great feature. The type of writing I do almost demands it.
On those occasions when tagging might be useful I turn to corpus linguistics software especially those programs that include Part Of Speech (POS) tagging. Currently I am using LancsBox produced by the specialist corpus group at Lancaster University not least because it accepts a myriad of input formats — thanks to a Java library — and applies POS tagging — thanks to a different Java library. One of the formats that LancsBox accepts is our good friend RTF.
However, much as I sing the praises of corpus linguistic software there are times when even in that environment tagging becomes more intrusive than useful. That said I am at the moment compiling my own corpus which is currently planned to have eight tagging schemes applied to it! POS using the same toolkit as LancsBox, a simplified POS which reduces the specificity of the POS tags to broarder classes so transitive and intratransive verbs are tagged as VERB with specific instances ot comma period semicolon etc reducded to a generic PUNCTUATION, semantic tags which apportion the lexemes in the collected texts to semantic groups— this using another tool from Lancs which they have recently made opensource, and lemmatisation which collects declensions into the headword. These are all pretty standard stuff for corpus software. But I plan to go further by including Named Entity tagging with a subdivision of personal names, then speech (utterance) markup, and finally syntactical tagging. Like the semantic tagger all the tools I am using are opensource as is the web crawler (as all the texts I want are out on the web somewhere), boilerplate redactor and deduplicator.
There is no way I would want any of that stuff being added to Scrivener itself. It is all too niche. Ah that reminds me of something else I would love to tag my corpus with “foreign/scientific phrases” especially Linnian taxonomy.
Hi, I see that this request was created over 10 years ago and I wonder if something changed. As you can imagine I’d also love to have that tagging arbitrary text feature in the Scrivener. It would indeed help immensely with the organization and keeping track of various topics, characters, plot points, you name it.
Yes, keywords help just a bit but to be honest, not nearly as much as tagging would do and keywords are cumbersome to use for that purpose.
I’m asking especially as from coding perspective, such functionality at least on the surface look more like low hanging fruit rather than a hard brainer, so I’m curious if we will see it eventually?
Nothing’s changed. @AmberV’s Aug 2022 post upthread remains the most useful compendium that I’m aware of for all the various tips & techniques using Scriv’s current architecture.
Best,
Jim
To be honest it’s sounds to me like presenting a workarounds, that still doesn’t rally work or is working far from optimal, without any explanation why can’t we simply get the dedicated tagging mechanism?
Yes, using styles as tags works only partially in a sense that we can “label” arbitrary text and then find their occurrences, however:
In context of tagging functionality, if I understand that correctly above can pertain to the usage of keywords, and tagging documents that way. If so, then I’d say it’s coupling two separate ideas and it just doesn’t work as:
Also I’d like to put emphasis that I’m not writing that only to complain for sport but I’d like to genuinely understand why such, rather simple and yet powerful functionality is systematically avoided to be implemented, despite many, many request throughout the years?
Because Scrivener’s text engine doesn’t support it. 
See this also.
I don’t know the Scrivener’s internal architecture nor capabilities / limitations of it’s text engine, but isn’t the wishlist a place when we can put our requests precisely because the functionality we would love to have is not supported (yet)? Scrivener’s text engine or any other dependency-component is still just a piece of software that can be modified and adjusted to accommodate and support new features.
Is it so that adding tagging mechanism requires so extensive redesign, that it is not worth the effort or something else?
No one is against you expressing your desire to see specific features/functions be implemented.
You only received neutral replies.
Have you seen the way I go about it, in the thread @JimRac pointed to? I am happy with it – it does what I need it to do. (It is, yes, again a workaround ; but it works.)
In this thread, my example is built for a “source” and “destination” for the tags/linking. That I don’t myself use. Rather that I make a list, in a table – dedicated document in the project bookmarks – with the tags themselves and a topic/description next to it.
Hi @Qbisiek
It certainly is. Has anybody in this thread implied otherwise?
I am not an L&L representative, nor do I have any particular insight into the internals of Scrivener’s software, aside from being an ex-developer myself and hanging around here for a decade or so. So take my opinion for what it’s worth. FYI, I would love this functionality too.
The text engine is one of the foundational software processes supporting Scrivener. Assumptions about the text engine’s capabilities (or lack thereof) thread throughout the software code. While modifying the text engine can certainly be done, my guess is that changing it to add this functionality is a significant, non-trivial effort, otherwise they would have done it already.
It’s the kind of thing L&L would have had to consciously design into the text engine when they were initially designing V3. I’m pretty sure at that time they consciously decided to leave it out, perhaps so they could leverage more of the old V1 text engine. Just me guessing.
If we ever see anything like this in an L&L product, it would probably be in a completely new built-up from the ground version. Perhaps Scrivener V4?
Best,
Jim
Thank you guys for your input, appreciate it. It seems that workarounds is all we can count on for now then. Anyway, still I would really appreciate a comment from the L&L team.