Cross-linking among Scrivener projects in Binder

Some history: last November I did my first NaNoWriMo project, and since then I’ve been pondering how to make something viable out of all those words. I’ve decided that what was originally conceived as a single book will in fact be much better as two or more. So, in order to prepare for next November’s rewrite, I will be splitting the old Scrivener project into probably three new ones. However, these three projects will be tightly linked, with overlapping reference materials and characters, places, and other concepts.

The idea is that perhaps it would be possible to drag Scrivener project A into the Binder of Scrivener project B and vice-versa. This would specifically not import all those files, but rather just add a special kind of alias. This alias would allow read-only access to the pieces of the other Scrivener projects by following their Binder hierarchy. The pieces of the other projects would be displayed normally (perhaps there could be something like a distinctive background). If you dragged a Scrivening or group of Scrivenings from an external project into the current project’s Binder, they would be copied in; the same with research documents. Since these are aliases, the system would have all of the normal vulnerabilities to problems resulting from changing locations in the file system or moving to another compute (I don’t think there would necessarily be sandbox-related problems, since they are all Scrivener documents).

I think that this kind of thing could have utility far beyond my situation. For example, a Scrivener project containing reference materials, notes, and bits of text in a certain domain could be linked into every subsequent project involving that domain. If a linked-to project itself contained such links, then they could be followed recursively, resulting in an arbitrarily complex network of linked projects. (I suppose you’d have to block project searches from recursing beyond a certain depth to prevent endless loops.)

Well one simple answer to your problem is to just keep everything in one project. :slight_smile: This is a perfectly legitimate way to use the software, and those working with series of books, articles, tv episodes or anything that would benefit not only from shared research but the ability to easily look up bits of text from other closely related passages in other books. Although Scrivener’s basic mode of operation kind of assumes a one-project-one-book approach, it can definitely be tuned to work with multiple books. You can store each book in the Draft folder as separate book folders at the top level (we even have custom “book” icons so you can colour-code these folders), and then in your Contents compile option pane, select the book you are currently working on from the drop-down menu at the top of the contents list. This will not only set up compile to use that as the “whole work”, but other tools in the software will (or with optional features allow you to) narrow their scope to your selection, such as Project Statistics and targets.

Beyond that, you can reference individual items from one project into another by dragging them from the binder of the source project into any References inspector pane in another project. Additionally, right-clicking on a Binder item and copying a document link to it creates a special URL that can be used in any hyperlink, too (even in other programs, PDFs, web pages, etc.). Given that there is no penalty for having many multiple projects open at once, this means you can double-click on a reference in one project and be immediately presented that information from the other project. If you change your link behaviour settings in the Navigation preference panel, you can even make it so that loading a folder link remotely will cause it to open in the main editor in the other project as a corkboard.

I regularly work with multiple projects, many of which have overlapping domains of information, and I’ve never really felt hampered by the software. I don’t see what adding a read-only project browser to the Binder would add to the equation, when you can just punch a keystroke or double-click a link and be right in the project itself with full power.

Yes, I think I get what you’re saying. It took me a while because at first I thought you meant to add all of your Scrivener projects to a single all-encompassing one, as in dragging or otherwise directly importing them. Of course, you can’t do that, first because Scrivener won’t let you drag in other Scrivener packages, and second because then you’d have all that overhead in there, which would be useful if the added projects could also be standalone projects, but useless if all the documents are just mushed together into one big Ur-project.

I personally feel that the atomicity of Scrivener projects is an enormous plus and I think you’d give up a lot to mush all or many of them together into one. Also, you will probably have some pieces that really shouldn’t be further modified (i.e., they’ve been published, submitted, sent to a co-author, whatever), and so I see isolating them from the active document(s) as a plus, and write-protecting them as an even bigger plus.

However, I will consider the approach you suggested for my current project, since there will only ever be maybe three to four chunks, and at least for the foreseeable future, all will be “active”. One advantage of this is that it is close to the current state of the project.

Thanks,
Greg

P.S. This actually reminds me of an exchange we once had above how Perl is different from awk, sed, grep, and the various shell scripting languages: it just sort of mushes everything into a single container instead of keeping certain kinds of functionality separate in standalone programs. I think some people like to keep each type of food separate on their plate, and others just like to mush it all together.

Ah, no I wouldn’t recommend dumping everything you ever do or will do into one project. While there is plenty of merit for putting closely related works into one project, there are limits to the concept. The format is designed to accommodate huge amounts of information—I’ve encountered people with hundreds of gigabytes of research data in their project. It can hold its own—but I am also a staunch proponent of backing up frequently when it comes to your works in progress, and it’s difficult to back up a project like that on a daily (or even more often) basis when it is huge like that. Even that aside, like you say, things would get very muddy. One unified list of Keywords or Labels is perfect for a trilogy, but what a mess that would be if you had to accommodate everything.

I do definitely agree with you that the atomic nature of the project concept being a boon (as well as it being a file based approach rather than some hidden database). There are some programs out there that take the universal dumping ground approach—and I’ve never been a fan of that. I personally have hundreds of Scrivener projects, I even make little ones for long letters to friends or short articles. But, like I say, if three projects are really going to be heavily dependant upon shared research and background material, and if the thought of being able to search for “Charles” and pulling up all of Charles’ POV scenes across an entire trilogy excites you, then you can see why I advocate the concept (and you can, by the way, constrain your search for “Charles” to one book if you wish to, as well).

To a degree that kind of division can be done as well, I earlier mentioned keeping all three books in the Draft folder, but you can just as easily swap the finished ones out of that draft folder, leaving it dedicated to what is currently being worked upon. There are distinct advantages to that, such as the aforementioned ability to narrow your “Charles” search down to one book. The Project Search feature has an option to only scan through Draft. Swapping whole books in an out of this folder is cake. Just select the master folder for it and hit Ctrl-Cmd-LeftArrow to promote it to the top level of the Binder. RightArrow to bring it back in.

The read-only project idea is interesting in theory, don’t get me wrong. The practice is something else though. Given that the software is designed from the ground-up to be a writing program, it works heavily around the concept that everything text is editable. There would be some awkward things about having read-only text items. You mentioned project search, that is one of them, but consider that you can also select 15 text files and form a Scrivenings session out of them, editing them as though they were one file. One read-only chunk in the middle of that would break the fluidity of that concept—never mind being a nightmare to code for (for example right now you can hit Cmd-A to select all text and change the font). There are other feature requests we’ve declined on that basis as well, such as locking files, or linking directly to text documents on the disk in a read-only capacity (which it would have to do, since the format uses some non-standard syntax to support feature RTF itself does not, like multiple footnote & comment streams and images linked to the disk). With read-only items the concept would be even more awkward since grouped views allow batch actions, and group views can contain items from anywhere in the Binder.

P.S. Don’t get me started on Perl. :wink: