Switch among multiple manuscripts in same Scrivener project file?

Oh, I know that. I’ve often done it myself, for example when moving from one draft to the next one. What I haven’t done is to have multiple closely related manuscripts going on at the same time, perhaps switching from one to the other several times in a single day. This would be especially be true if the section types and output styles varied among the different current manuscripts. So, I know it’s possible. I was just thinking it would be nifty if there were a way to do it easily, naturally, and quickly (this would also minimize the result of leaving out a step while doing a complicated, multi-step switchover for the umpteenth time).

All you need to do is to use level 1 folders and have the compiler compile “current selection”.
Work a book as if it was the whole project, select the book’s master level 1 folder and compile. (?)

Else, why would you need styles variations, if the books are related enough for you to want them sharing a single (uselessly huge - just my opinion) project?

There is even a way to make the compiler treat part of a project as if it’d be the whole thing.

As I said, I don’t really have anything against, but it’s definitively not a path I’d feel compelled to integrate to my workflow.

Hi there @gshenaut,

I must confess, I do not at all understand what problem(s)/challenge(s) your proposed feature change is attempting to solve, or what new advantage(s) it’s bringing to the table. I may be mistaken, but It sounds like the other commenters are in the same boat, and I suspect the same will be true for L&L support.

It’s entirely up to you, but if you feel strongly about your proposal, I recommend you provide a specific example of how it would work and the specific operational pain points that it would solve. That is, what exactly is it that you would be able to do more easily, naturally, and quickly, and what complicated, multi-step switchover would become less error prone?

Best,
Jim

1 Like

There can only be one Draft folder, but you can create as many subdivisions as you like within it. You can then Compile whatever combination of subdivisions you like, using the Compile Format most appropriate to the intended destination.

While many of Scrivener’s users are writing books, many are writing short stories, essays, poetry, scripts, and other short forms instead (or in addition). It’s not at all clear what problem you are attempting to solve, or what your solution offers that the status quo does not.

Could you clarify what you perceive to be involved, please? It seems to me that if you wanted different section types for the shorter form, you would only need to assign those once, and then assigning those types to a given set of Section Layouts would also only need to be done once.

Another approach is to make use of the default subdocument section type feature, which can be applied to groups, and impacts everything below that point in a cascading fashion. In other words you can have a main group in the Draft folder for the novella, and set it’s default Section Type to “Chapter” for example. Now everything you put into that group will be a chapter by default. If you want more structure, you can set sub-groups to have their own defaults. So in short you can have an area of the Draft that completely follows its own rules, ignoring the Project Settings.

To play with this idea, right-click on the group that should be different, and from the Section Types submenu in the contextual menu you will see the Default Subdocument Type section that I’m referring to.

Overall I would say Scrivener has a lot of support for multiple works in one project, and it doesn’t require multiple Draft folders to accomplish that. There will always be a line where it makes more sense to split a project off though. While you can do a lot with overriding section types, and having different compile formats with different style treatments, have statistics track only the work you’re focused on, binder hoisting to isolate the list to one section of it, and all that stuff, I would say main factor would be metadata, depending on how much you use it. Keywords and labels for example could get very cluttered if you use them to specifically refer to things that are only applicable to one work. For closely related works there may often be enough overlap that it is fine though—same characters, same locations, etc.

For cases where it gets unwieldy though, it is good to know that separate projects can still work closely together. And here is a recent discussion on tips for multiple works in one project.

2 Likes

Reading that gave me a headache. I would just simplify it by duplicating the whole project and deleting everything in the draft folder except the novella, and keep the research folder.

1 Like

Personally, at this point I’d also make the research and bible and whatnot a third project of its own, and simply link to it.
This way if you edit it, you edit it for all related projects.

Plus, you don’t end up with bloated backups that backup stuff (other books) that don’t have to be.

3 Likes

Maybe this will get you started.

multiple books in one project

2 Likes

How would that work? Please explain.

You copy this link from the target project to the other project(s).
Clicking that link then loads this target project in another instance of Scrivener.

What does that do? (extra character to make 20)

Clicking it loads this other project in a new instance of Scrivener.

So say you have three books in a series + a bible.
You make 4 projects — 3 books + 1 bible.
You paste the link to the bible in all of the three books’ project.
Clicking the bible link opens the Bible project on the side.
So: editing the bible edits it for all three books.

You may rename the link however you want afterwards:

You can even simply drag the scrivx file to the editor… (So the above would be more useful in the case where you’d want to link to a specific document inside another project, instead of linking to a project as you last left it.)
…or drop it straight in the bookmarks:

1 Like

Thanks everyone. There are some good ideas here. I’m going to play around with compile groups, which I’ve never needed to do before. I think I can figure out how to define section types appropriately.

Cheers,
Greg

2 Likes

Thank you. I will have to try it out soon.

1 Like

I have a couple of “satellites” projects set up like that.
Not necessarily in the context of a book series plus a common research folder and/or bible, but rather that I have a project where I take notes on the craft of writing (notes to myself about stuff I realize as I go), one project is just blurbs, as in “I just write anything and everything that shoots through my head”, one other project is concepts/ideas for (maybe) future stories, etc etc. (And, of course, my current custom template, as I am constantly upgrading it.)
All these “satellites” projects are already linked to in my custom project template. So all of my “real” projects already have those links set by default upon creation.

So what happens if you type into one of them?

They are projects of their own.
So, nothing other than what you’d expect, working on a project.

The idea, here – in the context of a book series + a bible –, is that the bible is not duplicated but rather shared across multiple projects.
There is only one.
So, whatever you do to it, you do to it and that’s that.
Whenever it is called upon (no matter out of which “main” project), those changes will reflect, as there exists no other version.

I’ve set up exactly the same types of satellite projects + custom template as you, minus the built-in links between them. I’ve designated these satellite projects as Favorites, so Scrivener maintains the links under File > Favorite Projects.

Best,
Jim

1 Like

Just as good.
I use links like I do because it has become an habit to access most of my custom stuff out of the inspector. (I have developed a reflex to “tilt” right (toward the inspector) for everything of the sort.)
Using links, I handle that in the bookmarks panel.
Otherwise yes, using the favorite list is just as good. (Most probably intended as such, too.)

1 Like