Arbitrary insertion anchors in document stacks

Scrivener Wish List
1

I love document stacks; I often write each novel scene as a separate text file, group scenes into logical sub-chapter document stacks, and then cluster those as chapter document stacks. I’m super happy with how this works.

But sometimes scenes don’t naturally follow in contiguous, linear progression. Sometimes one scene might live inside another scene (like a parenthetical within a sentence), causing a more complicated structure. I can solve this problem by having three text files something like “scene A part 1”, “scene B”, and “scene A part 2”, but really I’d much rather be able to make “scene B” a child of “scene A”, and then specify where in “scene A” “scene B” should be inserted.

I’d be happy with some kind of “reveal code” ([insert scene B here], #insert, etc.) or markup tag or a custom graphical element that I could insert into one text file to instruct the Compile operation to include the other specified text file.

Fantastic product. I use it every day.

Thanks for reading.

2

I don’t think I’ve really wrapped my head around this request. I understand that the writing may not be linear, but at the end of the day the reading will be. So at some point, if scene B is supposed to be inserted into the middle of scene A…that’s a real insertion that’s going to break up the scene exactly as you’re doing now by splitting A into two documents on either side of B. Yes?

So is the problem that you want to keep A intact until the moment of compilation so that you can read it to check the flow without B in the middle? If so, you can still break it up as you do and select the two scene A documents to view together in a Scrivenings session. If you change the divider from a line to the subtle crop marks (Scrivener>Preferences:Editor), you can read the two documents together about as seamlessly as if they hadn’t been divided at all.

Another option might be to use a Scrivener link and/or an inspector comment to indicate in scene A where scene B should be inserted, but not do the actual breaking up until you go to compile.

Obviously neither does what you want, if this is just a request for a convenience feature causing compile to do the work of inserting your documents instead of you splitting them up. I just don’t really understand why you wouldn’t want that insertion to happen until compile; personally I’d want to be able to read B in context of scene A during some phase of drafting and revision, so I’d want this break up to happen right there in the binder and editor. Obviously we just write differently, so I’m not critiquing, but I thought I’d offer the above in case it was helpful. (Also because I’m procrastinating on my own writing. :wink:)

3

While including insertion directives would be cool, I think it might be overkill for what Scrivener’s ultimate aim is: producing a linear document. That’s what it does. It takes a bunch of pieces and produces a linear text, which is as MM points out, how everyone is going to be reading it anyway (unless you are writing something like recipe book which is meant to be random access).

What you desire, from what I can tell, is a way to visualise non-linear scenes in a linear fashion, without the clutter of other plot-lines in the way. While Scrivener doesn’t have injection code to do this, it is still perfectly possible using its non-linear collection facilities. What you could do is break up this into three parts as you suggest, and supply them each with their own plot-line label colour. So blue-red-blue, or what have you. If each of your sub-plots (timelines, or whatever the narrative fracture may be) has their own distinctive colour, you can more easily see the flow of your book at an overview. Say red is flashbacks, you can at a glance see the frequency of flashbacks based on the appearance of red cards in the outline.

Now to couple that with management tools, you can search for these labels and save them into a Collection tab, making it easy to quickly gather threads of your book into discrete linear lists, completely divorced from their sandwiching content in the actual narrative. This is quite useful for making sure the flow is consistent from section to section, even if the physical position of the scenes are scattered all about. If the flow within these threads are themselves non-linear, you could employ custom meta-data to track order, add that column to your outliner, and then sort it.

Keep in mind you can always view scenes as one chunk of text just by selecting all three of them and using scrivenings mode to view them. So splitting things up even if it is all one cohesive theme with an interjection in the middle, shouldn’t harm the editing and writing process. This works in conjunction with collections as well. If you want to read the scenes without all of the flashback injections, just create a collection for the base plot-line and view that as a scrivenings session. Or just Cmd-click on everything around the red scene right in the binder.

On the topic of meta-data, this is one thing you could do to achieve injection like you want, but it’s a bit silly. You’d put the injected sequence into a custom meta-data field and then insert the token for that field in your draft. By example:

  1. Create a new custom meta-data field called “Flashback” and set it to line wrap
  2. Select the scene you want to add a flashback to and open the custom meta-data panel by revealing the Inspector and pressing Cmd-7. Type the flashback sequence into this field
  3. Now in the main text where you want to insert the flashback, type in [b]<$custom:Flashback>[/b]

Of course, this is pretty limited. You can only have one per scene (unless you make additional columns); it’s highly restrictive, typing in that small field; and it’s plain-text, so no italics or anything else.

4

Thanks, MimeticMouton and AmberV, for taking the time to reply. Your comments and suggestions are very much on target, and I’ve already started to use some of them.

I think I misrepresented my suggestion in my initial post; my goal isn’t to have the inserted text displayed only upon Compile…I’d ideally like it to be displayed just as with any other text documents, but with an easily translatable insertion anchor. What I meant is that the insertion anchor, as metadata, shouldn’t be displayed on Compile, but should rather be replaced with the inserted text. The anchor would obviously need to be displayed in Scrivenings so it could be relocated/edited.

The simplest case I can see for insertion anchors is—to use AmberV’s example—the insertion of a flashback into a larger scene. If all the flashbacks in the entire work need to maintain continuity if read contiguously, it makes sense to separate them out as separate text files so they can be proofed as a set using keyword selection or collections, etc. Anchors would become useful if one then wanted to move the flashback around in the container scene in order to find the best location for the flashback to occur. With the “before”, “flashback”, “after” three-document solution, the same operation requires text to be cut and pasted from the “before” and “after” documents to accommodate changes in location of the inserted flashback. Not a terrible scenario by any stretch, but it would be convenient for the software to manage the text shuffling.

When it really comes down to it, this is more an issue of logical and structural elegance in the text than anything else. Having the container scene be broken into two halves when it’s a single logical atom (with or without an inserted flashback) is what I’m trying to avoid.

A few quick comments regarding the various suggestions offered:

  • Scrivener links are really close to what I’m looking for. If inserted links could be traversed/expanded upon Compile/View Scrivenings, my suggestion would be satisfied.
  • Inspector comments actually kind of work, inasmuch as they’re displayed at Compile, but they’re clearly (and appropriately) second-tier text, whereas I want the included text to be displayed without any qualification.
  • AmberV’s suggestion regarding custom metadata is exactly what I’m looking for, except that I’d like to be able to insert a regular text document instead of custom metadata that’s hard to edit and maintain.

For the record, I’ve now set up Collections as per AmberV’s suggestion, and that gets me a lot of what I want. Cut and paste gives me the rest.

About a year ago I moved from Windows to OSX as my primary operating system, and at that time I purchased pretty much every writing product I could find, and once I started using Scrivener, I haven’t touched any of the others.

Thanks again for your time.

5

I just thought of a simpler way to describe what I’m trying to accomplish with this request:

Right now, Scrivener uses implicit insertion anchors: a parent document inserts all child documents in (Binder) order, at the end of the parent text, and this behaviour cascades depth-first throughout the document tree. I’d like to be able to override that behaviour by specifying explicit insertion anchors in the parent document. All other behaviour would remain as-is.

6

My apologies for the succession of posts; my ideas on this topic clearly aren’t coming out all at once.

With regards to Scrivener’s current policy of inserting all child text at the tail of the parent: this forgoes some of the potential advantages of allowing a document tree of arbitrary depth, because it means that any parent/child relationship is exactly equivalent to a structure with an empty parent and one additional child, where the first, additional child contains all the text previously in the parent (and where the parent doesn’t actually contain any text at all). Any tree is then trivially flattened into a single layer with strict (parent-to-child, depth-first) end-to-start ordering of sequential documents. The display characteristics of a parent text document doesn’t depend at all on its children, as the flattened hierarchy demonstrates.

As MimeticMouton points out, any text delivered with conventional publishing will in the end be linear at time of reading, but in my mind, there’s still some significant benefits to be had by taking advantage of tree structures at time of writing. In particular, it allows documents to represent complete logical units without consideration for child ideas and texts, if desired.

Thus explicit (and arbitrary) insertion anchors take advantage of document tree hierarchies by allowing the parent/child relationship to capture semantic atoms in individual text documents, while at the same time offering a final text structure that isn’t necessarily an end-to-start ordering of files. As with this scheme the final display characteristics of a parent is dependent on its children (which will be inserted in arbitrary locations in the parent text), the tree structure is justified. Note that an absence of explicit anchors could default to current behaviour, so that nothing changes for folks who don’t want to take advantage of this potential feature.

Clearly this isn’t a request you receive all the time. I’m rather laughing at myself right now at having put so much thought into this, when it obviously isn’t necessary to deliver a fantastic product. I hope you have (had) a great weekend.

7

I did understand your original request. The last one, of embedding the text into a meta-data field so you can use a token to place it later on, disregarded that of course—but I totally understand where you are going with this thought, and have worked with outlines that either support the notion or depend upon it heavily. LEO is probably the best example of an injection based outliner—it’s kind of like Scrivener for programmers. It takes your source code and turns it into an outline so you can visualise your project’s code method by method as tree nodes. It can be very injection based, with meta-nodes that simply list inclusion nodes, or common header nodes and etc, but the base nodes are always visible in the outline, even if they are only meant to ever be included indirectly by other nodes. It’s a great system, and you’ll never hear me saying it isn’t.

My primary point in the first paragraph is that I’m not sure it is the best system for Scrivener. For code, this makes sense not because it lets you place tree-section G in the middle of tree-node-Y, but because the duplication of key texts is a common task. Injection is incredibly useful when you have “Header-plain Header-code Code Footer” structures. A lot of that is going to be the same in every single file, so why not declare it once and inject it a thousand times instead of pasting it a thousand times? But a book is nothing like that, and a book is what Scrivener is all about.

So that leaves one-time injection, and that is less useful for reasons which you actually went into later on: Scrivener’s outline is powerful because it lets you actually fathom and manipulate the structure of your book just as easily as the text of your book. If you start obscuring the structure into the text, that relationship between the two degrades. There are very few advantages to injection over smaller nodes, in a one-time scenario—especially when there is nothing about the software that punishes you for small nodes.

Consider your own example: you have a scene with a smaller sub-scene (flashback, whatever) in it. The Scrivener method would have you split that into three pieces. What I would do, to logically contain it, is create an empty scene file and then put these three components into it—that way they are set apart from the other scenes around them and it is clear they are meant to be one scene. It presents one single target to click on if you want to view that scene from a macro point of view (using Scrivenings), in the same way you would view any scene around it that is contained in one file. It can effectively be treated as one file until you disclose the group and examine its parts. That’s a big concept in Scrivener and it should be used liberally when necessary. This is, in effect, what you want: a way to hide the fact that scene 48 has a flashback in it, because in a list of scenes in that chapter, unless you disclose the scene container, it will just be another scene in the list—but if you need to know where the flashback is, this method makes it easy to find it and view it with all of Scrivener’s modelling capabilities! That’s something an injection code couldn’t provide.

You might not always need that full power, but it’s there if you do—you don’t have to prepare for it or anticipate it. If you work in small nodes, then you are already set up for powerful derivative cross-analysis. If you’ve peppered a bunch of injection codes and then later realise you’d really like to view a collection of all the flashbacks to make sure the continuity is correct—well you can’t—then you’d be back here for another request support asking to allow collections of injection markers. :slight_smile:

What if you decided you want to take that sub-scene and append it to the larger chunk of text it came from. You’ve read through the proof, and this section feels to jerky with the small sub-scene in it. So in Scrivener you just grab the red label file and drop it in front of the red label scene it corresponds to. You’re done—the original scene is now a seamless whole. You could merge them together if you want—but you don’t have to—I don’t. I keep spits forever because I like to see where I’ve fractured the book before. As you can see, making this edit with injection codes would actually involve a couple moves, not just one.

I think you get what I’m driving at here. The outline is much, much more than just Composition 101 stuff. It’s a macro-image of your book’s skeleton in a way that an external pre-thought outline can never be. It’s an amazingly accurate topology, if used liberally in this fashion. It could just be an artifice—a “Chapter 10” text file that is 8,000 words long and nearly as unwieldy as it was in Word, but it needn’t be if one wants.

Injection would cripple this because suddenly structure would be a property of the text, which is a thing you cannot see in a stack of index cards or an outliner tree. You are back to the word processor problem that most of us fled from.

You raise a point on how it is easier to move an injection point than a node through text itself. On the surface this seems true. If you want to move the flashback three paragraphs up, you can’t just move the flashback node up. However on second examination it’s actually no more difficult in Scrivener than in a free-flowing text example. Just click on the entire scene as a node, and in Scrivenings edit the position of your flashback node by moving text around it; an opposing gesture to moving the injection mode around the text, but ultimately no different. Since you can edit the textual topology of a list of nodes just as easily as you would edit text within a single node, many of the limitations and obstructions in the node system vanish. Or to put it another way, other outlining solutions have developed injection code as a simple substitute for what Scrivener is doing. The ability to edit the textual topology in an amongst the outline topology, or working completely upside down from an outliner point of view, means you can treat your text (with a few exceptions) as “simply” as you would in a word processor, without losing the benefit of a solid outline methodology.

I think this is a slightly askew way of looking at things. It is not as though the parent implicitly includes its children. In fact you can exclude the parent from compilation entirely, and its children will still be included. Compile ignores and uses depth in different places, and this can make things confusing, but you could think of it this way:

  • When it comes to constructing the text of the book, it approaches your outline as a flat, linear list from A to Z. If an item is excluded, it skips to the next with complete disregard for the relationship between the items before and after the current item.
  • When it comes to “formatting” the text, it pays avid attention to depth, context, and node type. Full control of this is in the Formatting pane, where you can describe rules for document type and depth.

Where I’m not sure I follow your argument is when you state that this above treatment of an outline makes it difficult or impossible to construct an outline tree of arbitrary depth. I would say the complete opposite. The fact that the tree is treated as flat no matter how deep it goes in fact enables the tree to transcend mere book structure and become a true author’s tool. That you can break down a scene into sub-pieces and have that break-down be completely invisible when compiling means the outline is no longer just for the reader’s indirect benefit via the delivery of strict depth-based titling. So I might not be understanding what you are driving at here.

Now, you do have a point in that injection allows non-linear “cloud publishing”. I suppose that term has been thoroughly soiled by the buzzword brigades these days. I don’t mean using the Internet to publish: I mean publishing a thought cloud rather than a linear “this is the book” construct. Yeah, Scrivener’s not really set up for this wiki-like approach, and I submit that altering it to do so would cripple some of its utterly unique powers—for a technique that most people would never use. Honestly, many people never get past the “list of chapter files in the Draft folder” technique. Yeah, they are missing a huge amount of Scrivener’s potential, but cracking a book down into a thousand pieces instead of 20 pieces is a huge cognitive leap that may not even be necessary (and certainly isn’t superior) for most people, many of whom started out on a typewriter which is about as linear as you can get.

8

Thanks, AmberV, for taking the time to read my suggestion so attentively, and for preparing such considered responses. I think we both understand each other’s position now, so while our opinions are clearly divergent in a few places, I think I have only a few comments to make that aren’t merely reiterations of points already covered:

It seems you’re against the idea of injection points (previously “insertion anchors”) because they couple structure and content, and I’m all for them for exactly the same reason. I agree this coupling might appear abstruse to some users, but note that using injection points needn’t degrade independent operations on structure—such as the dragging of files around in the binder and changing their hierarchical arrangement—in any way; in such cases, the current behavior could be essentially unchanged, with injection points defaulting to “append/concatenate” as they do now with parent/child nodes.

I like your suggestion to move the text around the injection point instead of the injection point itself. The case where this fails (and the case I encounter most often) is when the injected scene is moved to a different encapsulating scene, which then requires splitting up a scene into two files where it was once (and is more elegantly and logically) one. For me this remains the greatest limitation with the current system: a single, logically-atomic scene may need to be split to accommodate the injection of another scene. And more: a scene that once had an injected scene—but now doesn’t—needs to be joined back together. (It could be left as is, as you suggest, as an historical record of prior topologies, but that’s an approach that isn’t scalable; a text that’s suffered many drafts could get untenably fragmented.)

For me, the Scrivener hierarchical levels are used to manage “inside” relationships. Chapters are “inside” the draft, and scenes are “inside” chapters. The concept of injection well represents the idea of one scene being “inside” another; it is for this reason that I’m a fan of using the parent/child relationship to capture this structure, rather splitting scenes in a flat hierarchy.

The most convincing argument against injection points, to my mind, is contained in your comment that they aren’t easily represented with card stacks. I’ll admit I don’t use card stacks much, because they’re obviously intrinsically linear, exactly unlike hierarchies (unless those hierarchies are bound by rules for trivial flattening), but I know a lot of people use them. That’s unquestionably an issue.

You’ve clearly thought about this a lot, and your arguments for why this feature doesn’t fit into the Scrivener landscape seem to me to be very defensible. But the fact remains that at least one of your customers, if offered this feature, would absolutely use it.