'Include in Compile' defaults?

Hi, whenever I open a new blank document, everything in my draft and research folders have ‘Include in compile’ box ticked by default. While that’s fine for the draft folder, I never want the contents of my research folder included. Is there a way to make a global setting so that items in the research folder are not included in the compile by default? It’s a bit of a pain to have to untick everything in my research folder before compiling. Thanks!

The contents of your research folder are never compiled. The only things that can be compiled are items in the draft folder or collections. The tick boxes are associated with individual items and only come into play if you move things into your draft items or collections.

Hope that helps!

Thanks for pointing that out! I just saw that the compile box was ticked and worried it would include all my research, but I hadn’t actually attempted a compile to see whether that happened. Thanks again!

You’re welcome! Glad I could help.

strictly speaking, shouldn’t the “include in compile” tickbox of the Research folder then be greyed out and unticked?

Because at the moment, it is greyed out and ticked. Which is why quartet1977’s question (and mine) arose in the first place.

Might be an easy one to change

No, for a few reasons.

  1. As already mentioned upthread, the Compile process ignores documents outside of the Draft/Manuscript folder, which makes the Include in Compile setting irrelevant for documents outside of the Draft/Manuscript folder. Why complicate the document creation process for an irrelevant setting? And what happens if one moves a doc from the outside the Draft/Manuscript folder to inside, or vice versa? Should the program automatically change the setting? Again, why complicate this process?

  2. Besides the Research folder, one might have dozens of folders outside the non-Draft/Manuscript folder. In some of those non-Draft/Manuscript folders, one might want the Include in Compile setting to be enabled. For example, I keep incremental revisions/versions of a story in non-Draft/Manuscript folders. I’ll want the setting to remain enabled, in case I ever want to print out or revert to one of those earlier versions.

  3. If having the Include in Compile setting enabled for non-Draft/Manuscript folders really bugs you, then create a document template for those types of documents, with the setting disabled by default. Create new non-Draft/Manuscript folder documents from that document template. This might sound outlandish if you’re not used to using document templates, but it’s not. I never use Scrivener’s default New Text command because I have custom templates set up for each of the various document types that I use.

These are just the reasons I can think of off the top of my head. I’m sure there are others. :nerd_face:



Hi Jim,

Thanks for your detailed and methodical response, very impressive. I do disagree of course, if only for the sake of disagreeing. :grinning:

Your reasons 1.) and 2.) are not applicable, I am afraid. The ticked box suggests that the folder is indeed included in any compile, the greying out suggests that the setting cannot be changed by the user. This is common nomenclature across the wonderful world of IT, in any number of softwares/websites etc. Therefore the confusion:
If a user is aware that no folders outside the Draft Folder are compiled, then the setting is as you say irrelevant and it does not matter whether it is ticked or not. If however a user is not aware of this (there are, I have heard, people who are new to to software) or if they are unsure, then they will be confused. Hence this thread, amongst many others. I would think. So the default setting should be, as I argued, unticked and greyed out.

Your reason 2 refers to other folders which users may or may not choose to create, wishing to include or exclude them at different points of their process, whatever the case may be. Deviation! This question is specifically about the Research Folder.

Your reason 3. is not a reason but a suggestion, one aimed at experienced users. My point would be that a software such as Scrivener should always aim to be as simple and easy to use as possible.

1 Like

Thanks for your post, @AlexLeith. We’ll have to agree to disagree about whether that default setting should be changed. :innocent:

Actually, it was aimed at inexperienced users, because experienced users would already know and likely be using that technique. :nerd_face:

I guess we must have one last disagreement. :upside_down_face:

I don’t work for L&L and had no hand in Scrivener’s design. However, after you’ve spent time with the software, you’ll see that simplicity and ease of use were clearly not L&L’s goal with Scrivener. If these had been the overarching goals, the software would be far more limited in its approach, with one clear way to accomplish each task and few customization options.

But this is not the case, because L&L’s overarching goal was flexibility. They’ve clearly designed the software to support as many use cases and writer methodologies as possible, within the container use case of “develop long form writing”. Unfortunately for new users, “maximize flexibility” and “as simple & easy to use as possible” will sometimes be in conflict.