When I am in the Split View and activating the second one the binder remains focused on the first, the original one, that was opened from the Binder.
The problem is that when moving between spit windows the binder remains unresponsive. All I’m expecting is that the Binder reflects instantly the document I’m editing in the Split View.
Is there a way to fix that?
Or I’m missing something?
That is in fact the way Scrivener is currently set up to operate. If you press Ctrl+Shift+8, it will refocus the binder onto the current item, whichever editor you’re in. It feels like a workaround, but I do it a lot.
It has to work that way. You can select different documents in the Binder that are not anywhere near each other and show them as one continuous piece of text in the Editor. The Binder is for manipulating documents and selecting what to show in the Editor. Not the other way around.
Thanks David! 
You’re welcome!
Selecting alternate documents in binder is certainly a nice thing to have. We all applaud that.
But it would be great to have a live performance when it’s precisely “the other way around.”
An argument that it should work that way seems absurd. For now, at least there is a shortcut for that, but what kind of scenario warrants current behavior? In this case, if this lack of feature is intentional then it’s simply a bad UX. 
Another example: when doing the search, binder happily shows results, you find the document going through them, then when canceling the search the binder is lost in time having the old selection on the document that was opened before the search, now you have to update the binder invoking the shortcut. It simply doesn’t make sense. The binder should be live and responsive. 
I don’t agree. The Binder doesn’t have the same function as the thumbnails in Acrobat or the sidepanel in Word. You use it to load what is shown in the editor window, but let’s say you switch the editor to outline view and did something in the outline. What would be the point of having the Binder show which item you have clicked in the outline? It’s not bad UX, it’s just different and as far as I have understood it’s quite intentional.
I posted a bunch of links to prior discussions on this topic, here, and there may be more if you want to dig around. The way the system currently works is indeed very much a part of its intentional design. I would be more interested in seeing substantiated arguments and reasoned thoughts than sweeping declaratives like “absurd” or “bad UX” (whatever that means).
Oh, and I hardly ever use Reveal in Binder. Honestly I tend to keep the binder largely collapsed down to first and second level folders. If I had everything expanded down to level 10 or whatever, showing all 2,500 items, it would be one klick tall and next to useless.
I’ll repeat what I said before, because I still think it best describes the divide between people that like the way Scrivener works and those that do not:
Dear Amber, if my examples aren’t clear then I can’t help you. But from your extensive answer I gather that you are well aware of the issue.
Look, I’m not even close to 2500 items and that’s not the current projects goal. And I never had this issue until my book advanced to the third draft, so I find myself increasingly multitasking between numerous sections making extensive edits all week long. This is where I find using the binder as a taskbar, though it’s a shame to compare these two since you have added all these wonderful features, and it’s original purpose is well documented. But why wouldn’t it reflect the current document instantly?
Scrivener is extremely beautiful piece of software, very well thought out, and it would be a shame to alter anything fundamental, but I really don’t get it why it’s such a big deal. I can’t see it destroying the binder just improving it. It’s rather simple thing. Or maybe we are talking about different stuff?
You can start by adding this feature silently, don’t activate it, just place it somewhere in the options for the rest of us, and see if it’s the end of the world.
I would tend to trust the opinion of the people who have spent 10 years making and supporting Scrivener when they say your minor feature request isn’t so minor at all. You have to worry about your point of view; they have to understand and worry about everyone else’s.
Yes I am aware of the fact that a minority of people have a hard time coming to terms with the type of model Scrivener depends upon for its left sidebar, a model that a majority of its users rather strongly prefer.
That’s a good question (incidentally answered in multiple ways in some of those threads I linked you to ahem).
Think of the binder more like the Table of Contents sidebar in a PDF reader, where if you click on a section, you are scrolled to that page in the main reading area, but then if you go and scroll the reading area a hundred pages away from that point, the ToC doesn’t scroll along with you—it may passively highlight topics as you pass through them up until the point where the reading point is beyond what can be seen in the ToC list, but that’s it.
Our mechanism will be very similar to Adobe Reader’s in that not only would the other item be passively highlighted outside of the viewing area, but the original item you came from would remain selected. This is not a mistake, this is a feature: it means you can easily jump back to where you were even after having jumped through numerous cross-references and having traversed through history. Couldn’t do that if Reveal was slaved to every navigation event. You can also at any point in time choose to make your new position within the project your current anchor point, and hit the Reveal shortcut. That is part of what it is there for.
Now expand that concept so that it encompasses the entirety of the binder as you have configured it; by that I mean both its scroll position and what you can see via disclosure of tree nodes. All of that configuration can be considered a “bookmark” to your current working model within the project. That is the kind of tool the binder is. It has very distinct purposes and cultivates certain patterns of usage that are different from sidebars that are driven by content on the right side of the application or that present a cohesive monodata system where all critical navigation elements within the interface lack persistent workspaces.
Maybe I use the two editors as navigation tools more than you do? That might be something to consider building a practice of, because the editors are definitely meant to operate as secondary (and tertiary) navigation; all in itself another reason for not slaving the binder to them, as it can remain aloof from whatever temporary digressions we make using the editors.
For example, if I want to jump around within the local context of the item I’m working on, the binder isn’t something I think to use—the editor has all of that information readily available to me, and is a more immediate and satisfactory tool for that kind of jumping around. Most often I want to go “up” in the editor so that I’m viewing an outliner/corkboard of the thing I was editing (the View/Go To/Enclosing Group command). Maybe I hit the shortcut two or three times to jump up several layers of hierarchy? Maybe then I make a non-linear jump over to a different container adjacent to the one I had been working within before. I don’t need the binder for any of that, so it really doesn’t matter if the binder is showing where I’m working while I’m doing this.
There is of course also history, which is itself a powerful localised workspace. As I navigate, it records my movements and can recurse back upon them as needed without having to look up those sections all over again in the binder. Most importantly where they are in the binder becomes unnecessary information to me because I do not need to see them in the binder to get back to them.
References in the inspector also serve as a big second level of internal navigation in many of my projects (as do hyperlinks in notes and within the text). They are a wiki-like relational web of associations between items and I frankly don’t care where any of them are in the binder when I traverse through that network as a matter of course. If I do care, then the intention there is to change my workspace to include that anchor in what I’m doing, then I hit Reveal and now that item is a part of my map of the project.
In fact in some projects (like the one I’m typing into right now) I tend to leave the binder closed anyway. That’s how much I spend my time in the editors. In these projects, the binder is a seldom used tool for quickly jumping between very large distances in the project or between major domains, and as such an occasional tool, and as such not something I would want to have changing every time I look at it. It is an important and dependable tool, something not easily replicated by the editors or any other tool in the software.
The best way I can describe it, and to synthesise the above, is that the binder is meant to have a spatial layout, meaning that I can hold in my mind an understanding of where things will be when I need to use it. If data stays where we put it within a tool, that spatial sense that we all have in our minds is augmented by the tool and we can trust it to be in sync with our mental model or map of the project. Change the layout of the map every time you touch a link or hit a back button and you, yes destroy, that concept of the tool that I am speaking of. Reveal on the other hand does not: because that is something you do, and is thus cognitively similar to when you click on a disclosure icon and expand a node. You have made the change to the map, thus modifying both your mental spatial map and the digital representation of that map in concert, not the software through secondary happenstance of a link click or whatever.
Not every disagreement that arises on the forum should come down to the addition of a checkbox! There would be no end to them and our time spent building whole alternate yet interlinked and thus increasingly overcomplicated versions of Scrivener to support them.
Sometimes you just have to accept the software was designed differently from how you intended to use it, and your choice is to either find out how it was meant to be used and work with it, or you can go on pounding on the “workaround” all day and feeling uptight about it. I do either one myself, depending on how righteous I feel I am in my disagreement with the developers of X software (cough iTunes).
By the way, there will be a compromise in the future, as I alluded to in one of the other threads I linked to. I won’t go into specifics except to say it will do a little of what you want but not everything (more like how a PDF reader works as described above)—and that it is truly as far as we intend to go with the concept.
And now we have another thread I can point people to in the future, one that will of course never be read. :mrgreen:
I couldn’t summarize the matter any better myself. This philosophical note absolutely warrants to quote Laozi: “Life is a series of natural and spontaneous changes. Don’t resist them; that only creates sorrow. Let reality be reality. Let things flow naturally forward in whatever way they like.” 8)
That said, I’m pleased to see in your last comment that you recognize this to be an area of growth and improvement.
And I would like to thank you for your patience and your time to layout your approach extensively on how you tackle the editing process in Scrivener. I’m truly intrigued with examples you have provided and I’m experimenting with them as of this moment. (Yes, using Scrivener I’m smiling again 
)
Can I suggest that someone video savvy from your team showcase the real power of Scrivener using your above described examples. The real life workflow.
Ioa, I just want to add my thanks for your thoughtful long post. I’ve used Scrivener for several years, but have never used all its features. (I fear I’ve been one of those who use the Binder more like the folder tree in Windows Explorer!) This will encourage and guide me in exploring further and getting more out of the program!
You’re both quite welcome! And that’s a good Laozi quote.
I’ve made a note of it. We are heading into a period of time where that is something we’ll be doing more of, and the concept of “advanced” navigation is something there has always been a bit of a documentation gap on—in part because it’s an orchestration of smaller features working together rather than easy to talk about and digest thing like “the corkboard” or “the binder”. It’s also a bit unusual and abstract; the fact that the editor is so much more than just a text editor or PDF viewer, that it can seamlessly transition from a binder-like entity to an editor has fairly deep implications for how we can work with it.
But anyway, speaking of future versions, I need to get back to documenting it. 
And, for those of who sit silently watching the forii for clues about the advent of V3.0 but are far too mannerly and mature to endlessly yawp, Are We There Yet, Are We There Yet? like some folks . . .
Much appreciated.
I have read this thread, and others, and I get that this is “by design.” I still don’t get why it works the way it does. That the way it works now somehow improves my efficiency.
That someone has a billion items in the binder is not a reason for it to not respond to the selection of the editor’s window.
And “shortcut” key-combinations that require three keys and looking at the keyboard are not “shortcuts.” They are interface supports.
And: given the expectations of users that it should work differently than designed says to me that the binder has not been properly described. (Yes i know it is not possible to document why and how all “features” can enhance my work habits.)
I want to know where i am and the consequences of my actions. That the binder does not reflect where i am does not make me fell better.
So, when an issue like this is complained about and the response is mostly “get used to it,” which is often the response to users complaining about what seem arbitrary changes/decisions, for this software and many others i use, i am just sad.
For me, so far, this is obviously an apple thing, of which i find many such apple things unreasonable.
“This is reality, get used to it.” Nothing in life should just be accepted when it seems to make no sense. Currently there are way too many “just get used to it” stupidities we must endure daily: apple, MS, google, cakewalk,… Changes from what was great to just plain cleverly-stupid, “look what i can do” “features” that provide no value.
Example: Most search engines now are just lousy. Used to be able to search for an exact phrase. No longer possible.
Another example of needed change: context menus need to be configurable, like the menu bar. Most of every selection on the editor’s right-click menu will never be used by me. I will pay more to be able to not have them showing.
But what do i know? Just an old guy, using computers, and supporting computer users, since 1985.