Binder/Outliner-like Tree view for Compile-Draft

It would be quite nice to be able to make selections using a tree-view rather than a flat list. There might be very simple useful rules for how a given selection on a parent affects its descendants.


At the moment, there is no impact. Export selection does not work in a cascading method, so as to allow the ability to sort sections of the book into non-exporting containers (just to mention one example). I feel the flat list helps reinforce this concept that, going forward, hierarchy will mean very little and everything will be produced in a linear fashion into a single document.

Doesn’t part of the tree structure represent the structure of the book? If it is useful when browsing, drafting, editing … I’m not sure why it would be less useful when configuring for “compile”?

It provides a flat list of exactly what is getting compiled… I’m not sure how it would be useful or meaningful to have this as as a hierarchical list, which would be more difficult to view in the more cramped space of the Compile Draft sheet, and as, like Amber says, upon exporting there really is no hierarchy - everything gets flattened out into one long continuous text. At any rates, this isn’t going to change - the Compile Draft sheet has undergone big changes and improvements for the next update, but the flat list remains.
Thanks and all the best,

You can most certainly use the Binder to visualise the structure of your book, yes, but that doesn’t mean that it actually does during compile.

There are two subtle exceptions to this. One is that a fluid sort of hierarchy is expressed when using the font overrides. These will grant different styled fonts to the titles of “container” style documents. But given the bounty of options surrounding whether or not these titles are even a part of the book at all, it is another example of where Scrivener can definitely support this notion of Outliner=Book, but doesn’t require it.

The second exception is MutiMarkdown which definitely does use binder depth to derive header depth. But again, while this is a possible usage, it is also possible to disable header generation for individual documents (or all of them) and handle the book structure independently.

This sort of flexibility allows the Binder to transcend typical structure and make itself useful to the author as more than a simple representation of a book. Whether or not all authors decide they want or need that is up to them. Putting hierarchy into the compiler would be, I think, a bit deceptive in that in the end this order isn’t used for anything other than a few subtle things mentioned above. It is just a big flat file, and while Binder structure can impact the textual marking within that flat file, it may not uniformly do so, or at all.

Ah yes, thank you both, Keith and Amber.

Sorry to revisit this. I have a large (and growing) document structure in the binder. Multiple levels. Starting to use all of Scrivener goodness around this. Seeing it as a single huge flat list in Compile-Draft is very disconcerting.

Can the list at least show some indentation to reflect the tree structure? I understand that propagating compile-draft selections and other properties up/down the tree is a bigger job, but how about just the visualization?

Sorry, no, this isn’t going to change as already stated, at least not in any 1.x release.
All the best,

Sophie, there is one thing you might not be aware of that I don’t think has been mentioned yet.

In the Compile Draft dialogue, in the first tab (“Content”), there’s a box above the list of documents that says “Choose folder…” If you click on that, it presents you with a hierarchical menu of your Draft folder, enabling you to “drill down” to a particular folder. When you select one, Scrivener will then present and compile only that folder (plus its children).

It doesn’t aid you when trying to export the entire document, but if part of your difficulty comes from only wanting to export a section or two, the ability to compile only a single folder (plus its children) may be a big help. I use it all the time.

Thank you, Antony, that was a much more helpful reply than my previous one. :blush: Sophie - the thing is that I really don’t see any advantage of having a tree structure in the Compile Draft area, where you could collapse items and therefore not necessarily see everything that was going to be printed. As Amber has so well pointed out, the flat list indicates that everything is indeed about to get flattened into one long document. The structure itself is only really meaning during the writing process, as Scrivener is not - and was never intended to be - a structural document creator (in the sense of LaTeX or XML, for instance), but rather instead it is intended as an aid to structuring a large body of work.

All the best,

Yes the Contents will sometimes help, thanks.

btw, in my last post I was not looking for a collapsible tree widget, or fancy hierarchical selection behaviors, or anything like that. Just a few spaces to indent elements appropriately, so I can visually scan it the same way I scan the Binder. Perhaps that does not fit your vision of the binder, I am sure you know best.

Cheers - Sophie

It’s not that I “know best”, of course, it’s just that, being the developer, I get to make the decisions so that it works the way I prefer. :slight_smile:

Sorry to revisit this again; I understand the UI’s unlikely to change.

The frustration I have is that I have a lot of flexibility in how I organize my document normally: labels and status settings in addition to hierarchy. When I go to Compile Draft, I lose all that flexibility and just have the hierarchy. I often want to make a draft of, for example, just the sections which are incomplete. I’ve already labeled them that way, so it’d be intuitive (for me) to go to Compile Draft and choose to compile all the sections marked as “Unfinished” or labeled “Needs Polish” or whatever.

The “Include in Draft” metadata shows up in the inspector, so I can theoretically do this from the editor, but the inspector won’t let me change a bunch of pages at once, so it’s no better than checking or unchecking boxes in the Compile Draft box.

I’d actually vote to get rid of the “Include in Draft” metadata and just use labels or status instead. Then you’d just compile a draft based on label/status criteria. It’d simplify the Compile Dialog and the inspectors, and give more flexibility as well.

Knowing that’s a big ask, my second-best option would be getting labels into the Compile Draft dialog. I think replacing the “Include All” and “Include None” buttons with a drop-down with the options “All”, “None”, and “By Label >”, with the last giving a submenu of labels, would work pretty well.

Again: sorry to drag this out, but I think the Compile Draft workflow is really important.


Hi Hugo,

You can batch assign “Include in Draft” by option-clicking on its checkbox column in the outliner.

More importantly, you’ll be able to do what you want in 2.0. Although the Draft folder will remain the mainstay of Compile Draft, there will also be a way to use Compile Draft to compile the results of a search (so you could compile the results of a search on documents that are included in the draft AND have a particular label assigned, or the result of a search on documents that have a particular status assigned in or out of the draft folder etc) or arbitrary documents. I don’t really want to go into details just yet, but basically you will be able to do exactly what you want.

All the best,

While waiting for 2.0, my solution to this problem is to use the search functions to find the documents I want, Edit Scrivenings to mush them into one unit, and then print that combined document. I don’t get the formatting power of Compile Draft, but for intermediate versions I don’t care.


Keith, that sounds great. I just realized the thread was from last September, not this one, so sorry for really dredging up an old one. Looking forward to 2.0!