Set up dependencies between documents

I would like a simple mechanism to track dependencies between documents.

I can already use metadata to set up groups of documents that express a particular theme or character arc, but what I don’t have is an easy way to configure set-ups/pay-off or other “this before that” scenarios and have Scrivener show me if rewrites are violating those.

Basically, I’d like to be able to introduce the gun on the fireplace early in the novel, and link that to the point later in the novel where it is used to shoot someone, and make sure that I never carelessly move the scene with the gun after the scene with the shooting without Scrivener warning me about a dependency violation.

You can use keywords to tag the items that are part of the ‘gun’ arc, and set up a date-type custom metadata field (or use Aeon Timeline) to indicate in which order the ‘gun’ documents should appear.

Katherine

Would Scrivener warn me if the dates (or other metadata field I used) were in the wrong order, though?

No.

Katherine

Hmm, thinking about this a bit from the point of view of establishing a system using existing features: one thing that would work for sequencing errors like this is to subvert the intended usage of the <$linkID> placeholder, which generates a background <$n> type counter for each binder item. Hence if both the linkID for the Cause and Effect items are printed somewhere, we can see at a glance if there is a sequencing problem if Cause is greater than Effect:


Note the first placeholder is linked to the other scene, pullings its linkID into this scene.

To take the concept one step further, one could gather these little contingencies into a folder in the binder as stand-alone notes on narrative flow. Where relevant (perhaps in both the Gun is place and Gun is used scenes) one could then use the <$include> placeholder to print the warning in both places. In that case you would want to hyperlink both linkIDs to create static references to these scenes.

The advantage there is less I would say in terms of keeping the output uniform between dependent scenes, and more about having a central repository of such dependencies on hand. And keep in mind that if you write the note from the dependency “card”, and link to both scenes from it, then each scene will get a backlink Bookmark to the depencing. Not only will the include placeholder let you know something is up, but you can view what’s up right in the inspector.

Of course this isn’t logic. The message will display even if “Gun is placed: 3 → Gun is used: 5”, but if these notes are easy to spot and turn on as needed for proofing, then it could help a lot in keeping things lined up neatly after a big shuffle.

Actual logic would probably mean Scrivener needing to dip into Tinderbox-ey waters, with if/then/else placeholder constructs and so forth. Maybe some day, but I wouldn’t cross my fingers over that one. :wink:

Now on the other hand, a technologically inclined individual might devise a simple logical markup system (or better yet, reuse a language that already exists) and attach a post-processing script to the compile settings to in effect achieve this, allowing for red flags to pop up only when needed, etc. I could for example have a “Warning” Style that I can type little instructions into like so:

red_flag("There is no gun!") if (<$linkID> > <$linkID>)

Then have the style prefix/suffix insert markers that the post-processing script looks for and executes the contents of as code, with naturally some definition of the red_flag method somewhere else in the script, to handle the presentation of the warning itself.

3 Likes

I was hoping for some sort of constraint system that worked real-time in the Binder before compilation, but I’ll have to give these ideas a look later. Thanks for the brainstorming.

I don’t think this is the sort of thing that would really fit what Scrivener does, since Scrivener is essentially a sequence of documents with no logic dictated inside Scrivener itself. It would also be quite limited, since it would depend on chronological ordering, which isn’t how everything is written, so would be of little use for a book using a different narrative order. It’s possible that we see the gun go off before we see it on the mantelpiece, for instance, if we see the murder and then jump back in time.

All the best,
Keith

If I use custom metadata today, I can show that various arbitrary documents are related (by having the same metadata value). I can see that relationship in the outliner, as long as it is an unordered relationship. Adding a way to set a dependency simply would expand on the ability to define relationships between documents and say, “this is the order these should be in” so I don’t inadvertently violate my content-dependent constraint. (If I’ve decided that’s the wrong order, well, that’s simple, I choose to remove the dependency.) I don’t think we any logic involved other than “does this document come before the other in Binder order” to implement such a feature, do we? It wouldn’t even need to tie into any specific metadata – literally just be “Document A must come before Document B in the Binder”.

If I can set an arbitrary dependency between two documents, without any semantic ties to the content or metadata, then I’m free to set that ordering however I want for my work:

Chekov sees the gun on the table in Act I; the gun is used for the murder after that scene.
Barry Allen sees his mother killed by the Reverse Flash in episode 1; he finds out the identity of the Reverse Flash in episode 18.
The Enterprise blows up in Chapter 1. In Chapter 20, we find out the Enterprise is caught in a time loop.

It would be a nice little feature that would ease certain use cases and allow us to avoid having to maintain data across Scrivener and some other app.

To be honest, I think this would be a bit of a weird addition - Scrivener throwing up a warning because you drag a document to a different position. And of course, it would mean that every document movement would need to search through a bunch of metadata dependencies. But ultimately, I’m afraid that I just don’t like the idea, sorry. :slight_smile:

That’s not to say that I don’t like the underlying idea of mapping relationships between ideas, but, for me, that would have to be part of a much bigger system of somehow planning out a book and its concepts - an unformed idea that I play with occasionally but which never goes anywhere, and which is much bigger than something like this anyhow.

Thanks for the suggestion anyway!

All the best,
Keith

I have some thoughts on this. Happy to share offline at some point if you ever revisit the idea. For now, the one thing I’d say is that I personally don’t think that what you’re describing is “a bigger system”, but actually a much simpler one that feels bigger because it involves wide angle views and broad strokes on to which you can subsequently hang specific points of detail.

Going back to @devinganger’s original suggestion:

tl;dr; Avoid using book structure on a draft.

This appears to be an example of trying to impose structure too early. Or rather, imposing book structure onto a story while still drafting.

In my case, while I’m drafting, I don’t care about the order of the scenes as they will appear in the final book. So, if the gun’s first appearance occurs – in Scrivener parlance – lower down in the Binder than its use – since that it the order used when compiling – it’s of no concern. It’s only of concern when I prepare the text for submission, which is a separate process, and where these kind of potential problems can be checked.

1 Like

To what extent is it possible, or desirable, to mechanize the act of writing a book?

Now, it may be that I’m biased because my own process is highly chaotic. But it seems to me that this request is an attempt to automate something that really shouldn’t be automated. Maybe the “gun is loaded” scene really does need to come after the “gun is used” scene. Maybe everything in the scene except the act of loading the gun should come later, and the real answer is to write two scenes. (I recently came across a situation like this in my WIP.) These kinds of questions can be addressed by way of a “gun” keyword to surface the relevant scenes, but it seems to me that more automation than that would take time to set up that might be better spent actually reading and editing the work.

2 Likes

I suspect this could be an actually helpful use case for (offline) “AI”. Spotting inconsistencies, without having to micromanage everything manually. But that’s not something Scrivener would have to care about, just feeding the compiled output to such a tool would do.

With the current state of AI, I doubt it. AI can certainly surface all the “gun” references, but it doesn’t have the ability to understand “gun state,” much less to figure out an appropriate sequence. Especially since statements in the text are going to be things like “Chekhov opened the cylinder and dropped the bullets in one by one,” or “Chekhov flipped open the cylinder, confirmed it was empty, then flipped it closed again.” Not “Chekhov checked the gun,” “Chekhov loaded the gun,” “Chekhov fired the gun.”

2 Likes

Well, I guess that eliminates the one possible upside. Maybe it is completely useless after all.

1 Like

My original request all those years ago was less about trying to mechanize writing and more about what I thought would be a simple, useful extension to metadata to help writers apply just-in-time structure/constraints as needed, so that a quick glance through the Binder would help flag additional status. Basically the equivalent of Excel’s conditional formatting feature.

3 Likes

I’m always happy to hear the suggestion - we will one day be thinking about Scrivener 4 of course! I’m still not sure this fits into Scrivener, though, even though this thread is so old that I don’t remember writing any of the above. :slight_smile:

1 Like

For what it’s worth, I agree. I think it could be awkwardly shoehorned in to Scrivener, but I must admit I’d leapt to the assumption that – like Scapple – you were talking about a smaller standalone app that plays nicely with Scrivener, rather than an expansion of functionality.