On discussing design intent and outlining

If users have cobbled together such a sophisticated series of hoops to jump through to get this functionality, that’s as big of a signal flare as it gets.


But holy cow, the moderator attitude is worryingly close to “no, it’s the users that are wrong,”

Different people have different needs. It has been clearly demonstrated that the feature would be useful, time saving, and directly desired by many.

It’s absolutely fine to say “not any time soon”, “low priority” ect.
The core functionality seems to be (nearly) there with the crazy Vincent comment-based workaround, and I am baffled that the opposition appears to be ideological in nature.


It’s not about “submitting to the choir of voices”, but simply recognizing that yeah, people develop different methods. Different situations call for different tools, ect.

Scrivener clearly acknowledges and caters to a varied number of writing use-cases. Very surprised to see that “conflicts with how the software was designed to be used” attitude.

Timestamps were certainly “not designed” to be combined w/ comments and searching to provide quick, single-destination jumps, but that kind of shenanigans has been done for ages, and is the very foundation of software design.

When users share their preferred methods for breaking a brick wall with their face, there’s no concept of it being “wrong” to do so. Moreover, you can’t. For every one user that gets noticed, there’s dozens of silent lurkers, and a dozen dozen doing the exact same thing w/o ever visiting a forum.

If it would be the an inefficient choice for the dev team to make a pickax for them, then so be it. Just be careful not to loose that important angle of approach.

1 Like

I can’t find any of the quoted phrases being said by anyone in this thread. I don’t feel anyone is “wrong” as you put. Perhaps the closest to that is the section that describes how Scrivener’s designed sweet spot is to use a smaller text chunking approach than one might use in a word processor? In reading that section again, I don’t see where it is overly critical of other approaches, and it even acknowledges preference and necessity for other use cases—hence the remainder of the post going on to show how you can work with longer texts more easily.

Sorry, I’m not trying to criticise your criticism, I’m just trying to understand where it is coming from. I would struggle to frame a paragraph like that as “the users are wrong”.

At any rate, I would emphasise that I was mainly sharing a variety of techniques that I use to work, as they address most of what is often desired of this capability (or another way of putting it, I’ve never felt like higher hyperlink precision would add much to how I work). Since it works well for me, I figured others might get some use out of a battle-tested approach I’ve used and refined for many years. It by no means feels like “breaking a brick wall with [my] face”. For me, it feels elegant and efficient because Scrivener has excellent tools for supporting how it works.

I would also note that the checklist in this section is the simplest way to do this, both in terms of execution and usage, as well as in how easy it is to compile without them (since inline annotations have a dedicated switch for removing them from the output that is on by default). Having the marker in the text, as annotations do, means being able to use Quick Search to extremely efficiently jump between marker points throughout the project.

As for whether date stamps are your cup of tea or not, it was meant to be a suggestion for something that is going to be relatively unique, unable to be confused with normal text and is simple to generate via a menu command. You don’t have to use that—I don’t. I use a combination of something like a date stamp with “markers of intent”, but I use these as a universal ID that integrates with multiple pieces of software and notation on my computer. So for me, this is a mechanism that goes beyond Scrivener, but is arguably most efficient within it.

I am aware of other methods in other programs of course. I’ve compared this workflow with how one would do this in Word or LibreOffice, and honestly I found it very clunky and inefficient to set up (and to later dismantle, which you have to do systematically if you don’t want them in the output), and it’s also much more limited in that links are all unidirectional rather than bidirectional. That said, I understand the notion of familiarity and feeling like if one doesn’t exactly what they used to, anything else feels clunky until one lives in it for a while—no doubt that is part of my own reaction to word processor oriented methods.

It’s absolutely fine to say “not any time soon”, “low priority” ect.

That’s pretty much what has been said, though a touch more in the realm of not having the tech available to make such a thing, so saying “low priority” would be a bit misleading.

1 Like

My cause for concern is the repeated “Conflicts with how the software was designed to be used”

That implies there’s a right, and a wrong way to use software. IMO that perspective, which I used to have, greatly limits understanding and potential.


Even way back in web 1.0, the idea of jumping to a specific piece of the page was understood as a worthwhile feature, and adding #tagID to the end of any webpage still works to this day.

Scrivener itself acknowledges there to be many character-specific pointing needs, and caters to them. Comments being the most visible example.

The very manner in which the comment window is designed seems built for the need to click and jump precisely to each one.

At some level, the use, appeal, ect of this functionality is already understood.


Hence my concern that there is some misplaced ideological component creating a blindspot here.


Those concerns aside, I can put on my developer hat to get a level deeper:

The problem is that Scrivener does not do what it claims to with child/parent text. Links cannot do what they were designed to do, because of another problem that I’ve not seen called out.

Attempting text-within-text only results in sequential documents. IMO, the UI nesting these elements is downright no-bueno. “lying” about that w/ the UI is causing problems.

To be clear, you cannot put the child text at a spot of your choosing, it’s literally just parent first, then child 1, child2, ect. Those are three siblings, and this disconnect is the root of this, and likely other problems.
In this specific case, Scrivener is not “achieving its vision” or whatever, the missing feature is why people need to hack together their workarounds.

If carving a child chunk of text out of a document does what it’s supposed to, then the linking feature becomes more functional, and could do exactly what everyone inquiring here needs it to, without using the comment system. many people here need it to, without using comment-based workarounds .

Again, if Scrivener supported actual parent-child text-within-text, this problem disappears without “compromising” any vision.

The chunk pops out as a child within the binder view, but can stay collapsed w/o clutter while offering linkability and other features of a binder item.

I won’t dive into the weeds of this thread, as Ioa has a much deeper understanding of the ins and outs of Scrivener than I do.

But the idea that a piece of software might be designed with a particular kind of workflow in mind seems to me completely obvious and uncontroversial. And so the suggestion that some ways of working will fit more seamlessly with the design of the software than others seems somewhat banal, not at all an “attack on the users” or anything of the sort.

To use a somewhat extreme example, Word is designed around single documents. So someone might import a single chunk of 50,000 words or more into a single document in Scrivener. Ok, fine. But Scrivener is simply not designed to work with 50,000 word chunks. So they would lose almost all of the functionality of the corkboard and outliner right off the bat. They would lose the abundant document-level metadata. They might see performance issues. And if that person came to the forum to complain that Scrivener doesn’t handle 50,000 word chunks well, how could the support team possibly answer, other than, “No, don’t do that. That’s not how Scrivener is designed to work?”


Would be fine.

It’s the “No, don’t do that.” I find concerning.

It is a hard prescription that implies right and wrong. Instead, IMO you give them more information to better make their own decision.
This acknowledges that I have no idea what that other person needs/wants, and understand that a brief post will never be enough information.

To be clear, that “No, don’t do that.” dogmatic thinking is becoming more common in software, but I was hoping it would not be here.


There is no reason Scrivener should not function with 50,000 word chunks. There are countless possible reasons why it might be difficult to implement, why users would inform each other of the pitfalls, but the presence of conceptual hard walls does not exist in software.

There is no sin, nothing “wrong” with someone who ignores half of Scriveners features and uses it as a Word clone. As I’m importing for a second novel revision, I myself have no character sheets, setting info, reference material, ect.
I wrote the first draft of 160,000 words in a google doc before migrating to Libre Office.
Not ideal, but in hindsight it was actually not as bad as you might think, the software held up fine.

I am already getting benefit of a number of Scrivener’s features, but I’d wager I’m ignoring more than half of them.


I’d like to address a hypothetical response to the effect of “well, it sounds like you’re using it fine, that’s different than what I was talking about. That novelist putting it all in one 50,000 word chunk is still wrong.”

That’s exactly my concern. Once a “wrong” way exists, some arbitrary line of right and wrong needs to exist somewhere, and will be invented.
Arbitrary, meaning ideological.
That “wrong” label leaks out to taint everything adjacent to that “wrong” line, and you’ve got moral thinking mucking up software development.



But yeah, here’s to hoping text-within-text is already on the radar, as it would make Scrivener a whole lot more functional.

Except that Scrivener is a terrible Word clone, and people who try to use it as one are inevitably disappointed when it can’t do things that Word can. Which leads to grumpy forum posts and grumpy emails to the support team.

We want our users to be happy, and we don’t want to be on the receiving end of angry posts from unhappy users. One of the best ways to ensure happy users is to match their expectations with what we actually deliver, and say up front, “Well, Scrivener isn’t designed to do that, and attempting to work that way is likely to make you unhappy in the long run.” (This is also why we offer a generous free trial.)


Let’s imagine for a second a world where 100 % of the dev resources went into twisting Scrivener to your proposed workflow. You’ll likely not live long enough to see the release of this version. You might as well put that energy into learning how it currently works.


This is a great reply, explaining why there is an issue, and gives a prediction based on one’s experience.

It is fundamentally different from the “don’t do that.” or “using it wrong” types.

Throws up hands.

So this whole sub-thread is about the difference between “No, don’t do that,” and “Attempting to work that way is likely to make you unhappy?”

I see your point, I guess, but it might be helpful to consider that the two responses often lead to exactly the same reaction from users. “But I’m the Customer, and this is what I want!” After responding the second way dozens of times, well, we’re human, and sometimes we just get tired.


I keep the manual open as a user lol, and am even less informed on what things look like as a developer.

All I can do is explain what I think I understand, such as the benefit of that text-within-text feature.

I get it. It’s just… This level of micromanagement can be done (by using smaller chunks of text, keywords, collections, etc.) if you’re willing to give the “Scrivener way of doing it” a chance.


I am perhaps a bit lost on the argument that states there is never a place for discussing how a program is designed to be used, and how workflows can be adopted within that optimal framework. That seems a fairly basic topic of conversation that might come up from time to time in just about any program of moderate flexibility and sophistication, particularly if there is a problem being encountered which has come about through using the program at a high level of friction, counter to its design—and particularly in a program that approaches several problems from a fairly unorthodox position.

Say for example you encounter someone on a Photoshop board that is struggling to get some elaborate macro to work which describes a process they have “always used in every other program”. You take one look at what they are doing and see they have never before encountered the concept of a layer.

Do you stand back and say: good for you, keep struggling with that one single layer. Or do you say, hey, this program is designed around the notion of layers, and here is how they can make your life so much easier. Maybe they’ll come back and say, “MS Paint has been doing things this way since the '90s, surely that means there is some merit…”.

Is one right while the other is wrong? No, of course not, I would view very few usage patterns in software in such black and white terms, but it would be folly to suggest that friction does not exist, and that all paths are equally seamless throughout any program—particularly programs with a strong idea in their design.

Inversely, we could try to apply Scrivener’s model to something like a typical Markdown editor, even one that has an efficient inter-document navigation system built into it, and see that breaking down a long text into individual files by heading structure and even deeper would run into problems of friction—because the software isn’t designed for that approach. Instead it has a bounty of tools for internal navigation within larger chunks of text.

The same is true for how most word processors are optimised and designed to be used. Trying to use LibreOffice to the degree I use Scrivener’s outline model at a file system level would be an utter nightmare: thousands upon thousands of paragraph-length .odt files. I would be using LibreOffice at a high level of friction, and if someone on a forum saw me struggling with trying to manage that mess they would hopefully rightly point out that the program is designed to work a different way, and that I’ll have a much easier time if work in 10k word chunks, and use the master document feature, or transclusion in Markdown-based tools.

Am I using it wrongly? Perhaps not, nothing is breaking, but am I working in a way that conflicts with the software’s design model? You bet!

Now this goes beyond what we interface with as users, in the visible feature set, too. A program that is designed to work with long, let’s say 50k word documents, is going to have different programming challenges in its design. It’s going to need memory management to handle having so much data in one single view, it’s going to need to use threading to fork potentially lengthy resource-intensive processes into the background while you work, such as auto-save and pagination.

In a program not designed for that, it would face different challenges, and probably would not waste development time solving programs it wouldn’t encounter. For example, a programming challenge we face with Scrivener’s design that hardly any word processor has to deal with is what happens when you click on a 2,000 outline node root outline item and tell the software to edit it as a single linear text. From there it must branch out through the file system and build a seamless editing environment from potentially up to 6,000 individual files on your disk, literal files, that are all assembled into various features within the software to provide you with this view mode. Can you imagine what would happen if you selected six thousand DOCX files and instructed Word to load all of them at once? Your swap disk would have a fun time with that.

Different challenges! Different places to put your coding effort.

Someone might put 180,000 words into a Scrivener outline node and wonder why it gets sluggish for example, why it halts and blocks input periodically (our simpler block-input auto-save system which is optimised for short packets of information into multiple files on the disk). Simply put, we’ve not spent years of development effort building efficient single-view editing environment because that’s not how it is designed to be used—but distribute that 180k over many documents, and it thrives.

This is kind of design stuff that goes into software, and intentionally working against that design will cause friction as well. Would you rather nobody told you about it?

The very manner in which the comment window is designed seems built for the need to click and jump precisely to each one.

I can see how that might seem that way to you on the surface, but it’s worth bearing in mind that this model is designed to span across “document” boundaries when working with larger texts in Scrivenings mode. Its feature set does indeed work on a single longer document, but that’s not why it has that feature set—it has that feature set so you can assemble Chapter 21 out of its 120 individual outline nodes in a linear fashion, and jump from one comment to the next, regardless of where it comes from on the disk.

It’s also worth bearing in mind that Scrivener used to have an internal bookmarking mechanism that was in fact removed from the software precisely because it was bloat. It was contradicting the design goal of having an articulated outline-based text, by having a mechanism that encouraged long unarticulated sections instead.

To be clear, you cannot put the child text at a spot of your choosing, it’s literally just parent first, then child 1, child2, ect. Those are three siblings, and this disconnect is the root of this, and likely other problems.

I may not entirely understand the concerns with this model. I do in fact come from a background of writing in outliners as opposed to document editors (which I’ve always felt out of sorts in), so what you’re describing—this linear relationship between nested nodes, to me feels entirely normal and expected. I don’t see what is wrong with that.

I think I understand what you are getting at, that you feel an outline shouldn’t represent the actual flow of the text literally, and that it should instead represent peaks that we mark out in a longer text? I would start by saying that’s not a traditional outline—that’s more like a word processor’s navigator tool, where various objects in the document becomes navigational peaks—that’s fine and good, but it’s not a model that the outline itself would work upon. Such things might arise in the feature set, for example in an org-mode outline we might use an agenda view that extracts peaks from the outline in the form of dated tasks—we can do similarly in Scrivener by pulling out outline nodes into a separate list, either dynamically as a search result or by building our own curated lists. But these kinds of supra-outline features are not part of the outline model itself, which you seem to be suggesting they should be.

That said, I think to a degree Scrivener does indeed do what you’re looking for. Let’s say for example you want all of your figures and tables to be in separate outline nodes for the sake of being able to refer to them specifically, and to create lists of them easily, and so on. Nobody would argue with the usefulness of having a list of figures. At the same time you don’t want to chop up a small subsection into three parts purely for the sake of having a discrete image object in the outline. This quandary is what I referred to above as breaking things down for purely mechanical reasons, and why that is often not desirable and ultimately can counteract the intended design by flooding what should be a concise human-friendly outline with mechanical artefacts of the document design.

So you go to the spot where you want to insert the figure in the text, you type in <$include>, select it, and hit ⌘L / Ctrl+L to link to a new document. You designate its name and location and it opens up in the second split. You drop your image into the other editor, maybe throw in a caption, and close it.

There you go: now you have a discrete outline object (which could be stored in an appendix folder with a special section type override that prints each caption instead of the image in a list of links back to the figures), that is embedded into an atomically concise text that isn’t broken apart just to accommodate that object. If you want to see that object, you click the link. It’s kind of like what you’re describing—if I understand correctly. Again, what you seem to be describing isn’t how any outline I’ve ever used works, so I may be off on that.

In this specific case, Scrivener is not “achieving its vision” or whatever, the missing feature is why people need to hack together their workarounds.

None of my working methods above are “workarounds” or “hacks”. They are logical extensions of the feature set that work efficiently within its design, and for the most part they are all doing what the design was built to make possible and efficient (funnily enough).

Perhaps you are using these words in a less technical sense than I would, however. A workaround, by definition, has a specific meaning that pertains to bugs and issues that implies a temporary bridge over a blocking problem that allows you to continue working until it is fixed.

I would close by again reiterating that the primary problem with granular hyperlinking is a lack of technology to build it in a feasible time-frame. All of the above, whether the model of the software depends this technique less than a model that must work in longer chunks of text, etc., is somewhat beside that point. Or another way of putting it, I would say that the lack of granular linking isn’t an ideological choice and that having such a feature probably would be beneficial even within its framework. We can say both things at once: that a program doesn’t need something as much as another might (like a web page), while at the same time stating it could benefit, but likely never will on account of technical limitations.


I hope to be wrong, but.

If I understand correctly, it is not possible to have a parent text item (ex: chapter), and child text item (ex: scene) nested inside.

Attempting to do so will simply put the two text items one after the other, with the (false) parent as the first, and the (false) child next in sequence.

A parent text item with a child text is fundamentally different from two siblings.


Were this possible, linked text items could be as small as desired without breaking the “after” document that at the moment must be dealt with.

If I wanted to link to key bit of dialogue, I have to break the previous single unit into three, wholly independent pieces.

Scene part 1,
important clue,
scene part 2

Actual parent child would look like,

The way it works now is a series of documents stitched together. A straight line. Trying to make scene part 1 & 2 share everything they need to (while clue does not) is already a headache I’m not bothering with.

Thus far for me, it’s been folders hold text, that’s it.
So, at smallest, chapter as folder, with unknown numbers of scene chunks inside.

If I try to have any depth with text parenting text, it add 0 functionality (as it does not seem to function that way) and only eats up time.

You are mistaken. You can nest as many levels in the outline as you want, and “text” and “folders” are not fundamentally different in that regard.

Now, by default, a new text item will be created as a “sibling,” at the same outline level as the currently selected item. But you can move it wherever you want from there.

1 Like

Of course you can do that. And once you discover how this all works (in conjuction with Scrivenings mode, the Compiler, etc.) I suspect a lot of your current frustration will just evaporate. Or… say 85 percent of it.

1 Like

I do not know how to better explain this, so I guess I must repeat.

The UI appearing to nest text, in function, actually stitches the nested child as the next sibling.

The example of putting a clue WITHIN a scene, not AFTER the scene was to illustrate this. It breaks the scene in two, which child-parent does not do.
Children nodes are bound inside a parent, sibling nodes are placed in sequence.

IE, there is a disconnect from the UI presentation and actual functionality.


In my understanding of the functionality, using a parent text item is exactly the same as putting a parent folder, and one additional text item first in line, with the (false) child being in real function a second sibling.


For something to be a text-within-text, some amount of location info is required, where within the parent does that child get inserted.

If you cannot move the child around within the parent, it’s not a child-parent.


Again, they very issue I am attempting to reveal is that UI is “lying” about this, and is the root behind many users desiring arbitrary jump links. As a developer, I get a lightbulb that changing this behavior to implement real text-in-text, despite not at all being arbitrary jump links ask for, will solve their issue and simultaneously encourage further “scrivener-like” behavior.

I am afraid you got a lot of this wrong…


I think you’re going to need a screenshot to explain this. I’ll check your trust level to make sure you can.

As far as I can tell, you cannot actually nest text within text.

It just puts them in a row. Meaning the child is just slapped on to the end, as a sibling.


Trying to pop-out a clue into its own binder item (such as for linking) is actually just cutting the one into three.

If we actually could get real child-parent, I’d start doing that in hearbeat. The degree of personal headache is due to this being unsupported. It would require tracking where within the parent to place the child, like an inline comment.

Where else would it put it?

If you want to put Section C in the middle of Section A, then split Section A in half at the desired location. (As you have done in the top half of your screenshot.)