Research Binder Sub-Folder Relocation


An appealing feature would be for one to be able to move any Research sub-folders and files to the associated text document. This would break up the amount of reserach documentation and put it where it is relevant.

In the screenshot below I have been able to move the folder, in pink, called “Phineas’ Will” from the “Research” folder to the document called “Phineas Discusses His Will.”
Interestingly, the URLs are only typed into the document, so the document is an .rtf document. To access the URL, one uses the “right-click”->Open URL command.

However, the pink file in the “Research” sub-folder called “Diamonds Dames and Double Crosses,” which is full of imported URLs acquired by the “right-click”->Add->Web Page command sequence cannot be moved to any related text documents. These documents, an example of which is the one called “Web Page” can be clicked on directly to show the URL.

Is there a reason why there is a difference in moving these two different kinds of files (contained in the folders) from “Research” into the main text file area? For continuity’s sake as well as to add robustness to the feature set in the program, I think it would be an improvement to an excellent program if you could allow movement of all types of files permitted in “Research” to the main text area.

My guess is that you are trying to move that folder somewhere into the “Draft” folder. One of the main features of Scrivener - and one of the first things explained in the tutorial and Help file - is that the Draft folder can contain text files only. This is, obviously, because the Draft folder is what gets compiled into your final manuscript. Web pages, media files, images and so forth can be stored anywhere except in the Draft folder. (After all, how would you compile a QuickTime file or web page into your manuscript pages?)

So, you first folder, “Phineas’ Will” could be moved into the Draft folder because it contains only text. Your second folder, “Diamonds…”, could not be moved into the Draft folder because it contains media files (a web page). In other words, the limitation is not in where you can drag from but rather in where you are trying to drag to.

Thank you for your fast reply.

I understand what you are saying and was aware that the tutorial addressed that. For what it is worth, my desire to move non-text files into the draft area is to associate those files with their relative draft counterparts only while writing because the amount of research files can get so large that searching for a specific file would end up taking more time the more the research area grows, especially when using a small laptop. Once the particular draft file is finished, I would move the non-text files back into the research area or else delete them.

My question was why was there a difference between moving non-text files and text files into the draft area? If there is some programming limitation, well, ok. If it is a software design decision, that is your choice, but I wanted to weigh in with the view that I thought it would be a plus if I could see non-text files in the draft area. Since I color code the folders which hold those non-text files I would have no concern that I might inadvertently include the non-text files in my manuscript, even if that was possible.

Does this help clarify my question?

Part of it is certainly a design decision, and one that makes sense when you consider what the draft folder is for: something for the final version of your product; and something that can be compiled to create the final version. As such, it doesn’t really make sense to put documents in there that you do not wish to be compiled into the final manuscript (or which cannot be compiled into the final manuscript). It makes more sense to disallow the files, than to have stuff in the draft folder that must be removed before compiling the manuscript.

Whether there are other design decisions or technical influences, I am not sure, but the design decision makes sense to me.

That being said, I understand what you are saying about your workflow. I would suggest two possibilities for you to get what you want without needing to change the software.

  1. Create folders in your research folder that directly mirror the contents of the draft folder. Then you know the documents for a document you are writing can be found in the same location in the research folder.

  2. If you already have lots of other research, you could create a new top-level folder for this purpose. You could then either use it as I outlined above, or use that as a substitute for your draft folder while you are composing, and only copy the final version of a document into the draft folder when you are done. This gives you the desired workflow and arrangement, and will just require an extra step of duplicating the text documents into the draft folder before you compile.

I hope those ideas help.


It is more than a design decision, it is a fundamental feature. The Draft folder is crucial to Scrivener. Just because one user says they will move non-text stuff out of the Draft folder before compiling doesn’t mean that the Draft folder should allow non-text items - relying on users to move non-text items out before compiling. That way madness lies… Because it wouldn’t prevent users from having non-text items in the Draft folder when they go to compile, which is essential. The Draft folder is for text-only items, so that they can be compiled into a long text document. The Draft folder is the one folder that is like that because it is the one folder that is fundamentally special as it holds your draft. All other folders are for research materials that can be of any type… This is such an essential part of Scrivener that it will never change. I hope that makes sense… This is typed after half a bottle of wine so forgive any repetitiveness. :slight_smile:

Matt, I was already using your #1 suggestion, but #2 solves the problem. Very clever, Matt, thanks. It has the added virtue in that “Edit Scrivenings” won’t work in that circumstance, so even there users are prevented from compiling a draft with non-text material in their drafts. A happy solution for all.

Keith, I understand your approach even without half a bottle. No worries.

Best regards to all,


Just a quick thought that came to my mind – what if there was a (context) menu item Mirror Draft Folder Structure In Research Folder? With the option to mirror only folders or even files, which would become a folder in the research folder?

This would mirror the whole structure, but maybe the possibility of generating a research counterpart to a single item or a number of them would be helpful too.

And I don’t mean creating it manually like Mark suggested (a method we probably all use) but in a way that Scrivener knows that a draft item has a related research folder and indicates them in the outliner with, say, a little down-arrow before the draft folder item. A Scrivener link inside of the outliner, so to speak.

And clicking the arrow would … just highlight the related research folder in the outliner? Open it in the active screen? Or in the non-active screen, and if there was just one screen open would it automatically switch to split-screen?

If I understand correctly you are talking about clones or aliases… Unfortunately because of the way the internal structure is set up, there is no real way of doing this. The underlying code of the binder (and thus outliner too) expects each item to be unique - it just can’t cope with aliases etc. It’s the sort of thing that would need a fundamental rewrite (and thus would be a 2.0 sort of feature).
All the best,