Binders and collections and organising files

I have read the manual section on binders and collections but I have to admit I am still unclear on how to relate the different elements. I am a writer, a journalist and a speaker and I have created three binders to represent three different areas of work and I want to relate the documents, corkboards, research etc to those divisions but I am not sure how to do it. I am not sure what the brown object I have created entitled PREACH represents.

In my mind I would have three main binders, then collections within those binders, and projects, then documents at lower levels – but I don’t think Scrivener’s hierarchy works like this. Can you help me to understand it – and be able to move my content to the right places? TIA

–Ian Greig

Not exactly a reply but here is the screenshot I made earlier but the board doesn’t accept .tiff

Okay, I think a tip that will help you out is that collections are not actually binders. There can only ever be one binder in a project. Collections are portals for viewing select portions of the binder in useful ways as you see fit. You might have twenty articles that are scattered amongst various categories in the binder, but you wish to view them all together in one spot. You don’t want to actually move these items and collect them in one spot in the binder, because their original placement is important for their context (perhaps they are meant to compile together into a longer piece and need to be in that spot). This is where Collections step in. You can gather these disparate pieces from all over the binder and show them together as one list.

So when you create a bunch of empty Collections, as you have done, and then start adding items directly to them, Scrivener doesn’t immediately know where to put them. Collections are themselves an abstract sorting mechanism that exists by design completely divorced from the ordering in the binder—but since all newly created items must appear in the binder somewhere, that being the fundamental resources management tool in Scrivener, the software creates a “COLLECTION NAME (Unsorted)” folder in the binder for you, and starts adding these items to it as you create them. The idea being, once you’re done brainstorming or whatever in the collection, you would move back to the binder and sort these items out to where they should go in the master outline. Or you could just leave them there, nothing to prohibit against that.

So really, I think what you want here are folders in the binder, rather than collections.

The actual hierarchy goes like this: Projects are the master container class in Scrivener. They are individual packages on your computer, stores like normal files in your user folder. A general rule of thumb is that you create a project for each real world project you embark on, though there are many exceptions to that rule. As a journalist you might very well want to store many related articles in a single project—all being too short to have their own projects and be separated from one another’s research material. To take it to a larger example, serial novelists like to use a single project for multiple books so that they can use the same universe info for them all.

Theory aside: the project is the largest category of division in Scrivener. It is a hard wall where nothing inside of the project can “communicate” with things in other projects. You can’t share keywords between them, or link items between two projects. They are meant to be discrete. What you do inside of them is up to you.

Next “down” in the hierarchy is the Binder. This is the master list for each project. Every single resource in the project (with the exception of the contents of the project notepad) will be listed in the binder somewhere. It is impossible to have a file in the project that is not listed somewhere in the binder. You can have many folders within it, but each binder has one “draft” folder which is the primary focus of the project. That is where the production happens. Whatever you intend to produce with this project should be going into the draft. If a project has multiple productions (like a series of articles), then they would all go into the draft—probably each into their own top-level folder.

Everything outside of the draft is presumably in support of the draft. That might not always be the case, but that is the general rule of thumb and how the software is designed. There are no compile facilities (production tools) for stuff outside of the draft. They can be individually exported as files, but that’s it. The research folder is the exemplar of support material organisation. It cannot be deleted, to reduce confusion, but it doesn’t necessarily have to be the only sorting folder at the top level. You can have dozens of top-level folders—or you can just put everything into research to keep the top-level simple. That’s totally up to you.

So the binder is the master project list.

Below that level of organisation, I would say the container is the next; most common container is the folder. You have folders in the binder—and in Scrivener the folder is a tricky beast because it is an outliner, not a file manager. Files can be sorted into files just as easily into folders. So you will see the documentation refer to organisation as being “container” based. A container is a folder, a container is also a file with sub-documents.

Collections are strange because they are in every sense lateral to the binder. They do not represent an level of organisation above or beneath it, but rather beside it. Nothing you do in a collection will adjust the contents of the binder (save for creating new orphan files within a collection, as you’ve witnessed). No amount of moving items into or out of, or rearranging them inside the collection will impact the binder. Nothing you do in the binder will change the collection contents or order (short of deleting a resource). Adding an item to a collection does not move or copy it—it creates a link, or alias, to it. Thus you can have one item in twenty different collections.

They are a more advanced feature, in part due to this abstraction, but mastering them can bring your organisation and workflow to new levels. They are not necessary, however, for much of anything. They are a special purpose tool.

Outside of your own personal organisation, collections have two special purposes which elevate their importance a great deal. They can become surrogate “drafts”. When you compile, you can select a collection to compile instead of the draft folder or a container within it. Their second role in compilation is filtering, which is an even more advanced concept. Say you have some items in the draft you don’t want to compile—you can throw them into a “Do not compile” collection, and then set a filter in the compiler to strip any items found in that collection out of the list. Again, here we are getting into some of the really super-powerful aspects of Scrivener, and it is safe to just set this aside as academic information for now. Just now that collections can become a power tool to solve some tricky problems down the road if you need it.

So in summary: Projects → Binder → Containers (Folders) → Files. Then meta to all of that, Collections, which ignore all boundaries within the project and likewise impact nothing.

1 Like

Many thanks to AmberV for such a detailed, helpful reply.

Just one further clarification: what exactly is the brown icon (in the image as “PREACH”? I don’t remember how I made iot and can’t work out where it comes in the hierarchy! Thanks again.


The brown book folder is what I was referring to in the second paragraph above. Those will appear automagically whenever you create items directly inside of a collection. Since collections represent “no space” in the binder, Scrivener cannot guess as to where you wanted the actual new file to appear in the binder outline—so it creates an ad hoc folder for that collection and stashes the file(s) in it. It gives it a “book” icon; brown variant. Feel free to move those items out of there and into a more appropriate place.

Got that, thanks. Some very good explanation here that I feel could helpfully be added to the manual. Thanks again for taking the trouble.


Yeah, I’ll take a look at it. It’s difficult because a lot of the above is a synthesis of features and the documentation is by necessity more thorough with each feature, so multiple features and philosophies like what a project is, how the binder works, and what collections do, by necessity end up getting scattered all throughout the introduction due the weight of words required to fully describe them. It’s valuable insight though, but perhaps a better topic for an in-depth tutorial. In the coming months we hope to put together some of these as Scrivener projects; kind of like the main tutorial in the Help menu—but focussing on a particular aspect of the program that is tricky. There are some things tricky to explain with a 10 or 15 minute video; and some people learn better by reading and following along in a practice project, anyway.

Thanks for the feedback!

Indeed a very useful post that could easily fit as introduction of some sort, or must-read, into the manual. Really, the semantics of projects as implied with Scrivener is signficantly different from what people tend to understand with it. At least that much different that it has a significant impact on how one could best organize oners work into separate projects, or one single project all the same.

If I understand correctly, since there’s only one single binder there is also a one-to-one correspondence between binders and projects, i.e a project can only hold one binder that on its turn can contain several (hundreds) of containers, the latter being a recursive entity.

I wanted to ask whether it was possible, now or in the future, to share cards between projects. I now understand that that probably is never going to happen since your vision would suggest that if there is a need for sharing, than those two projects should have been the same project in the first place. Which refers back to my initial comment that Scrivener’s semantics of project significantly impacts the organisation of ones work.
As a conclusion, this implies that my PhD-work (papers, research, thesis) all will be one single project since everything somehow relates to one another and you never know on beforehand what will be reused.

Somehow this doesn’t feel totally alright me. But maybe that’s just what makes us human: the unwillingness to change and take someones word for it that it will make a difference 8)

Yes, that’s a way of putting it, just like there is one Inspector sidebar on the right side, and one editor (that can be split once). But I don’t think of the Binder as a data model, or a “super-container”, I think of it as an interface component—a way of manipulating the project’s data, much like the Corkboard is a way of viewing and modifying items being represented as index cards, rather than saying that there are only one to two Corkboards per project. The Binder is a tool.

I wouldn’t say never. Keith has never been opposed to the idea, it’s just that there are some technical issues with implementing it, with rather far-reaching implications on how data is stored—and so with that obstruction on top of the already valid point made where projects can best be seen as the largest tent available rather than the smallest one, it’s been somewhat of a very low priority thing to even look at.

Yes, I believe this is how most who have used Scrivener for their PhD have used it. I’d say a good many also use a separate database for the bulk research, so as to keep the project tidy and easy to back up—also to take advantage of more focussed database-oriented features which Scrivener lacks in.

As for the user manual describing this better, actually my paragraph above was shorter and less descriptive than the one in the user manual:

On the other hand, such a large project could easily become unwieldy.

I’m a journalist, and spend a lot of time writing about a few fairly technical sub-fields. I keep all research materials in DevonThink Pro, and create a separate Scrivener project for each major project. (So a book-length work might be one project, a set of related articles another, and so forth.) I’ll either drag items into Scrivener as needed, or just work with Scrivener and DTP open side-by-side.

I’ve got nearly 5 million words, spread across 3 DTP databases. I love Scrivener, but it just isn’t designed for data management on that scale.


Though I continue to regard Scrivener for Windows to be one of the best software programs for writers, there is no place where it fails more remarkably than the difficulty once you have established a hierarchy than the binder.
Unless someone knows a solution, the only way I have found of creating, say, a new chapter, and creating new (subordinate) sections underneath that chapter in the case that I section belongs to a previous chapter is by moving all sections in that chapter to the left so that they are ordinate with (at the same level as the chapters.
After this, you can move the section into that chapter and then move the sections (including the section you have moved from one chapter to the other) to the right and subordinate place.
This from my point of view–unless someone more experienced than I has discovered a way–is a software inadequacy that begs for a fix in an update.
Does this work differently for users of Macs?

The expected behavior is that you can freely drag any document or folder from any location in the Binder to any other location. So once you’ve created the new chapter, you should be able to just drag (or use the Move menu) the existing document into it.

(Subject to the limitation that the Draft folder can only contain text files.)