Seeing a folder's Document Notes


I have been outlining my NaNoWriMo novel last month, making extensive use of the Document Notes, something I’ve never used before. I have a folder for each chapter, with documents for every scene.

Here’s my problem: when I click a folder in the Binder, the Inspector doesn’t change to show the folder. Instead, it shows the content of the last document I saw within that folder, and I can’t access my notes easily. First I thought they had disappeared, but they are there if I see the whole project as an outline or corkboard. The only time the Inspector doesn’t change is when I click a non-empty folder on the binder.

This is really driving me crazy. This behavior makes me mistake one Document notes for another ones.

What am I missing? Is there a preference somewhere I need to activate?

Added for clarification: I discovered that this only happens when I’ve seen a document within the folder in this session. If I haven’t, then the Inspector changes as expected.

There is no way to preferentially disable Scrivener’s persistence features. What you can do however, to view a container’s Inspector information, is click on the background of the Corkboard, or Cmd-click on the selected item to deselect it (if the background can’t be reached, which is more often a problem with Outliner).

Or you can just view the container’s container, rather than the container. Consider if you wish to view the inspector details for a number of scenes in a chapter. You would click on that chapter folder and view the scene index cards on the corkboard, clicking between them to see their notes. If you wish to see the notes for the chapters then you should be clicking on the thing that contains the chapters (probably the Draft folder).

Thanks a lot. Cmd+click did the trick.

That works as expected.

What was really unexpected was clicking on the Binder on a closed folder and seeing some random (to me) document in the inspector instead of the folder. Now that I understand that selected documents remain selected until you deselect them, my life will be easier.

Thanks again :smiley:

What is your current View->Binder Affects-> setting?

If I have my right editor locked, and have Binder Affects->Right editor only (i have a left-right split), the inspector doesn’t change when I click on a folder… or anything else… But if I just have “current editor”, and the editor is not locked, then it changes.

Probably not relevant to you, but I thought I’d throw it out there in case you were experiencing some related glitch.

Yup, it’s designed that way on purpose. Basically any action that views a collection of things will remember the selection within that collection when returning to it. Where it probably would make a whole lot more sense is in the History function. If you are viewing a corkboard and have a card selected, and working in its notes, and want to switch to one of its references briefly, you click the References button and double click on the icon of a supporting document. You quickly check up some facts, then hit Cmd-[ to go back to where you were—you would want the original item you were working on already selected, not the corkboard it incidentally belongs to.

That’s the design premise behind it anyway.

Right. Working for me as expected when using the Binder Affects->Right Editor, but with the right editor locked. Maybe my example will lead Elmago to find some setting that’s accidentally interfering just for document notes.

But for me, everything is working as the OP wants it to if I have Binder Affects->Current editor, and that editor is not locked. No matter what I click on, folder or document, I get the synopsis & document notes for that object. I never have to select the container of the folder to see the folder’s document notes… so I was thinking maybe there’s a bug related to the Binder Affects setting.

(Edited for clarity)

Hmm, it actually shouldn’t be doing what you are describing. If you follow this sequence:

  1. Create a folder with three cards in it, “A” “B” and “C”

  2. Create a “D” as a sibling to the folder

  3. Click on the folder, view as Corkboard, open Inspector and click “B”.
    You should be seeing the meta-data for “B” in the inspector.

  4. Now click on “D”. You should be seeing the meta-data for “D”.

  5. Click back on the folder. Inspector should still be showing meta-data for “B”, not the folder, and the “B” card should be ghost-selected in the corkboard.

Instead you get the folder’s meta-data in the inspector every time?

Ah, I see what’s going on. I’ve been selecting everything in the binder, not clicking on the items on the cork board. If I bounce around between folders and their documents, the inspector shows whatever I select in the binder, but if I click on a note card, then click on it’s containing folder in the binder, then it behaves as you describe.

Weird. I take it this is a design decision to behave this way? Because I would prefer it to always show the metadata of what I select in the binder, no matter what I’ve selected in the editor previously… But I can see how that would confuse people if you leave the ghost selection of the card on the cork board. Hmmm…

Well I think the main reason for the design decision is what I highlighted above. According to Scrivener, any way that you get to a thing is pretty much an identical action internally. Clicking on a container in the binder is the same as going back in history and having that container come up, which is the same as using the Go To menu, or a Scrivener Link, or a reference… you get the idea. In many of those cases you would want the last thing you were doing in that container to be the way you left it, and if that means selected items then that is part of the “state” you left it in. Besides, it’s pretty easy to get out of that state if you do want the container’s details by just clicking anywhere not-a-card—or as you point out, just forming your navigation habits to avoid that behaviour altogether.

In short, I think it is one of those 50/50 problems. If the interface is changed to work the way you describe it, then those who prefer and expect it to work this way might feel it now no longer works right. So you just swap one group with another on who gets the default behaviour and that doesn’t really solve anything. I think it’s better to just learn navigation habits that suit the way you wish to work—like always intentionally clicking on the thing you want to look at, rather than clicking on a container and then drilling down through a group view.