Yep, you heard it right: multiple windows. As in more than one window on the same document at the same time.
I have so much research material in my Scrivener document that split screens, while very useful, aren’t enough. But another window open on the second monitor? A dream come true.
It’s a feature added recently to FileMaker Pro. It’s made a huge difference.
I’m not sure what platform you are using, but if you’re on Mac, that’s what the QuickReference feature is for (and if not it’s a feature on the to-do list for implementation). From the binder, select the research item you wish to view and hit the spacebar, select it directly through the View/QuickReference/ sub-menu, drag it to the “QuickRef” toolbar item, or use Documents/Open/as QuickReference.
Beyond multiple document windows, there are no plans for the project window multiplying.
Nice, I was just going to ask the same question. I am a HIGHLY visually organized person. I spend most of my time writing on a rotated to vertical, 24" monitor. I am thinking of upgrading to two vertically rotated 27" monitors - three if I build a new mac with better internals than this iMac.
Using the Quick Reference feature seems to be the answer - with only one missing feature, apparently as it has no zoom control. 
With my tired eyes I hide the binder and go to 200% for most of my writing. I just did not want to give up all the vertical space I was already using to edit the same document in two places at the same time. But it should be said that I am EXTREMELY grateful to the Scrivener team that this is possible at all. Don’t ever change babe. 
Thanks.
Hmm, have you set up a default text zoom in the Editor preference pane (top right)? That should impact QR panels as well (ones you’ve opened already within the session will use the older value). Otherwise, you can zoom, we just didn’t have space for the control. The View/Zoom/ sub-menu still works, as well as the associated keyboard shortcuts.
(User credentials: I user Scrivener frequently for musical theater scripts.)
I find multiple window panes to be too fiddly for practical use. I’d love interface tabs, each of which could reveal an arbitrary interface configuration (I forget Scrivener’s term for this), or, better yet, the ability to open multiple interface windows on the same project.
My use case is a laptop Mac with multiple desktops (Spaces in macOS parlance) between which I can effortlessly switch with a four-finger swipe on the trackpad. This is so fast it feels instantaneous. Often, instead of opening two Safari window tabs, I’ll open two browser windows and put one on each desktop. Swiping between them involves no clicks or pointer motion, and is ergonomically as close to perfect as I can imagine.
I’d love to be able to do this with Scrivener. I find that I now use Scrivener just for script writing, and have started to put meta-project notes in Bear.app (in a separate desktop/Space), because it’s so much faster and easier. This is a shame as it relinquishes one of Scrivener’s strengths, which is to be a repository for project metadata of all kinds.
If I search the wish list forum here for multiple windows, I get a number of redundant threads, which means the conversation about this is sadly spread across many different places to look. If you don’t find the above discussion useful, that I’ve merged this into, I’d suggest poking through a few others, where will find that although we have heard this request—there are no plans for adding multiple window capabilities.
It has less to do with design matters, who could argue against the notion in principle, but technical limitations. To put it into perspective, on Windows it took a major effort to get the split view feature working, where two completely separate views could simultaneously safely edit the same file. That wasn’t a problem on the Mac, but there the window model itself is deeply tied into the data model. You either use that model as given, or invent your own. The latter is a major effort few would be willing to undertake for a window as complex as Scrivener’s.
Perfectly reasonable from a developer’s POV, just as from a user’s POV it’s reasonable to want ergonomically optimal tools and not care about cross-platform parallelism.
In any case a two-app solution isn’t a hardship, even if it’s a little inelegant.
I am not sure if this is intended toward this answer specifically. If so, both platforms would find it equally difficult, for different reasons, I perhaps did not make that clear. I was covering the challenges that would be faced by either.
On the whole we do try to keep things roughly balanced—getting way out of balance leads to trouble. One need only look around here in the past to see evidence of that. But if it makes sense to do some particular thing the other platform cannot, we do it. For example, on the Mac the window manager itself supports merging multiple document windows into a tabbed interface, and Scrivener supports that. There is no such thing on Windows, so we don’t support it there. There are opposing examples as well, such as how the Windows version can be themed all the way down to the buttons and tooltip colours, while Mac software is far less conducive to that approach and its themes are limited to what colour choices you have in Preferences.
But, having for example the ability to filter index cards on the corkboard by label on one platform and not another? That kind of design level disparity we do our best to avoid.
Your prior examples all suggested that multiple windowing was too hard to maintain across multiple operating systems, rather than difficult to implement on any one operating system. Are you saying that multiple windowing is too effort-intensive to justify implementing on (say) just MacOS alone?
I did a short non-scientific survey and found that Apple’s own native productivity suite doesn’t allow for this feature either. On the other hand, most or all modern web browsers offer this functionality. Ulysses (Mac only) seems to offer multiple windows, and the opening message in the thread refers to that feature in FileMaker Pro (presumably also Mac only). So it doesn’t seem beyond the pale.
To be fair, you could also do this with two Scrivener projects (in two different windows on different screens).
True! But here is where Scrivener’s complexity would work against it. There would be more steps involved and more interface elements to deal with. Plus Bear’s dynamic creation of folder-like hierarchies based on tags is super quick and efficient.
I personally am now leaning towards simpler specialized tools, even at the expense of consolidation. I sometimes write scratch versions of scenes in Bear, then move them over to Scriver for the final formatted version. It’s just easier for my workflow. And as said, having Scrivener on one desktop (“Space” in Mac-eese) and my project notes on another and being able to four-finger swipe on the trackpad to switch between them is absolutely the best.
I’m not driven by any kind of ideology here. I’m just following the path of least resistance. Your mileage may vary.
It was poorly worded, if that is how it came across.
Probably most so, in fact. I would suspect if anything it would be a bit easier in the Windows version, but I wouldn’t wish to speculate—these things are often spiral into dramatically more complicated problems than you might think, unless the framework or data model has a native way of doing it.
On the Mac, this question was answered in another thread.
None of these examples you list are like Scrivener, though.
Most browsers are not Mac software, outside of a thin interaction layer that acts as a container to the real software (same goes for Electron-ware, like Visual Studio Code and Obsidian)—or that which we would consider the functional part dealing with data inside the window border frame itself—I would tentatively even say the same of Safari, which does have more native Mac UI, but is still fundamentally using a rendering kit in a window. That aside, there is very little beyond superficial overlap between a system that can load data from a remote server and display it in a read-only fashion in a window more than once, and a system that is interactive with your disk storage on a single read/write access point.
The other two examples are not document editors like Scrivener is. Database-based software is inherently capable of overcoming the file system issues mentioned prior, as databases are designed from the ground up to host thousands of concurrent clients all making changes at once—like how this forum works. It’s a popular model to use, for many reasons, but it isn’t without its own downsides as well.
In short, if we don’t allow you to open the same project twice from two different systems (say using file sharing or a local file server) without dire warnings of catastrophic data loss and such—how is that fundamentally different from two or more different instances of the software operating on the same data, simultaneously unless you are using a system or framework built for that capacity from the start?
There are different systems that make this more or less possible without huge performance costs or an imposition on the user, but we aren’t using that technology. One way of doing that is having a plural windowing model all routing through the same singular data document-based model. Mac doesn’t do that out of the box.
It is possible to overcome the natural limitations of the file system issue with a traditional file system and plural document + window model (i.e. multiple agents interacting with one data source without any interaction between each other), but it is a comparably expensive to do so, as it requires all instances to be polling the disk for changes to the files it has open. Now, in a program like Sublime Text where one might have at most a dozen files open at once, that’s can be an acceptable use of resources—and in a program like that you can optimise the process by polling on window activation too, rather than constantly, and alerting the user if conflicting edits have been found and asking how they would like to proceed. I have one program that opts for the active polling route, and even with one document open, it is sitting in the background chewing up a constant 5% CPU, no matter what.
But in Scrivener, where hundreds of files might be actively open? Neither semi-active polling and conflict resolution nor active polling are feasible.
We might as well spend our time on making the project window better. I think it would be a lot more interesting to discuss why you find the existing navigation and splitting mechanisms in the window inadequate, and what you feel we could do better. That is something more within our power—most of the above is the kind of stuff that would take one programmer many years to change.
A lot of thought has been put into making the one window super efficient, but it is one of those things that comes with a level of adaptation and discovery, perhaps it already does things you haven’t come across yet? I will say, for myself anyway, that I work across many dozens of items, cross-referenced between many pieces of research, all with splits, copyholders, bookmarks, keyboard shortcuts and history—and I’ve honestly never really felt like I needed another project window. More active text views? Absolutely—but I’ve got that with QR windows already—and those give me inspectors too, which can solve problems that are hard to get around otherwise with one single inspector.
Then I don’t understand what two Scrivener windows would improve in this situation? 
Unless one of them also becomes more like Bear…
This is hypothetical, because I’m imagining an interface feature that doesn’t exist. But I’d like to think that I could pop up the second Scrivener window (derived from the first) with relative ease, more easily than opening two separate separate Scrivener projects as you suggest.
Plus, the “open most recent file edited upon Scrivener launch” feature would always open the One True Project file, rather than have a 50% chance of opening the notes-only file, depending on what I most recently opened.
A hypothetical Multi-Window Scrivener would lack some things I’ve come to appreciate about Bear, but I’d be willing to give those up for the consolidation convenience. Whereas I prefer my current two-app workflow to any other current possibility.
There might be a way, through scripting and automation perhaps, to make the two-separate-Scrivener-file approach be as ergonomically convenient as my homebrew Scrivener-and-Bear combo. But I don’t think I’d gain enough in return.
Amber, I think you’ve made a good argument that multi-windowing is technically difficult. I have enough background in software to follow what you’re saying at a high level, even if I can’t evaluate the details.
But I’m not in your position (software developer working on a thing, trying to make it as good as it can be); I’m in my position (creative person looking for optimal workflow, with a choice of things). So ultimately, the why-not doesn’t matter.
I will however as you suggest re-comb through Scrivener’s UI features and see if I can find some related functionality that will save me from the two-app solution.
I will pip in and say that the ability to access inspectors via quick reference windows is definitely awesome. One thing that I am always wanting, which isn’t quite resolved however is the ability to fully collapse the editor so that I can only see the inspector items in the quick reference window. When working on two monitors I often want either the project notes or bookmarks floating on my other monitor (not dissimilar to the floating inspector pane you get when using composition mode).
At the moment, however, you can’t fully collapse the editor in QR panels - this means that if I have the same document open both in a QR windows and the main editor you can see both windows updating as I type. I find this really distracting when all I want is to be able to glance at my document on the second monitor from time to time. The ability to collapse/hide the editor on the QR would resolve this problem and basically give you the option of having a floating inspector as needed.
My workaround for the moment is to move my document notes to a separate project bookmark, but considering I very rarely want project notes, but use document specific notes all the time, this is less than ideal.
I’m not quite understanding the issue with QR panes for this kind of use case. You can give a QR pane a Bookmark sidebar, which can function as a mini-Binder, and all the document-specific metadata is available, so what’s missing?
If you quit Scrivener with both projects open (instead of closing each project while Scrivener is still running), then both should be opened upon launching Scrivener later.
Also, you can link to another project’s binder items. Right-click on a binder item in your notes project and select “Copy Document Link”, then paste into an external bookmark in the main project. Clicking on that link in the main project will open the notes project to that document. So you don’t even need to turn on the “Reopen projects that were open on quit” feature; just open the main project, and when you need the notes from the other project, just click on one of the links to the relevant document.
Edit to add: In case it’s not obvious, the links can also be placed in any rich-text area in a Scrivener project, such as the main text of your documents, or in the document notes, for instance.
Thanks Rdale. Those are handy features and might together make an argument for the two-Scrivener-project-at-once approach.
Here’s another write-up on more closely integrating multiple projects together.