I can’t reproduce the problem following these steps, but I think some steps may be missing (for instance, it’s not possible to switch to scrivenings mode when the focus is in a child document as in these instructions).
Something else to check is whether you have Include enclosing folder text in scrivenings mode disabled, in the Behaviors: Folders & Files preference pane. In such a state the enclosing group will have no representative text in the editor from which to inspect.
This highlights a fundamental concept: the inspector does not inspect the binder selection. It might seem to, if circumstances allow it (and often it will appear to), but it solely uses the editor as a source for inspection. If the editor does not contain the group “within it”, then it cannot be inspected at that level; you need to click one level up in the binder so that the group can be seen within the editor. With Corkboard and Outliner there is an implicit “within it”, in that the very background of these views are considered the group. Deselect all of the cards or rows in these views, and now you are inspecting the group that contains them. There is no way to “deselect” text editors however, the cursor has to be somewhere.
Thank you, checking this box resumed a common-sense behaviour, however:
There is a flaw in the concept here. If the application is communicating one thing to the user but doing another, then then is a failure of design. Here, fundamental rules of design should dictate that when the user selects an item in the Binder, the user’s selection should be reflected in the application behaviour.
The Binder selection even uses the macOS default colour for a selection, however, for comparison, open Finder, select a file and open the Inspector with ⌥⌘I. Upon selecting another file, the information in the Inspector will change, reflecting the new user selection. Scrivener’s behaviour runs counter to this fundamental mechanic of macOS.
It may make sense to those who make Scrivener to do otherwise, but it is incorrect and thus causes user confusion, annoyance, and bug reports like this one.
I’d encourage this to be addressed in a future release.
Sorry I spoke too soon. The problematic behaviour is not resolved with this preference checked. Following the steps listed above will still result in the Inspector showing information for the child document, rather than the selected folder. With the cited preference enabled, the user still needs to:
select the enclosing folder in the Binder
select the child document in the Binder
select the enclosing folder again in the Binder
Only then will the Inspector show the information for the selected folder, rather than the child document. Considering that the application state in step 1 and step 3 is the same, it seems impossible that the Inspector should be showing different information, but this is the problematic case.
The user does not expect the cursor to dictate their selection; this runs counter to all macOS GUI mechanics. Rather, mouse clicks and the selection highlight colour is how applications communicate selection to the user. But even if this were not the case, the cursor disappears when focus is moved to the Binder.
It’s not a flaw. The Binder is used to select what is shown in the Editor and the Editor decides what is shown in the Inspector, but it doesn’t go the other way. Only from left to right. And remember that the Editor can be split and what is shown in either part is decided by the Binder.
It communicated correctly, as I understand it from your description, because you became aware of the fact that you were inspecting a child item instead of the group. Now, if the inspector had told you it was inspecting the group but was in fact changing the metadata for a child item—that would be a bad problem and a clear case of miscommunication.
And indeed it is. Where you are differing is in assuming that what follows from that action should, without exception, percolate across the entire surface of the UI, rather than to its immediate right, and then stopping. It is the latter that happens, and then the user’s selection within that middle column is reflected in the application behaviour by informing the scope of the element to its immediate right: the inspector. It is a very simple (and common) left to right approach—which might in some cases indeed percolate all the way across, if the middle column’s implicit selection is identical to the thing we clicked on in the binder (as is the case when clicking on a single PDF file).
But there are many cases where that may not be what happens. With Navigate ▸ Binder Selection Affects ▸ None, or by locking the editor view, or even splitting the editor, never mind locking the inspector focus to one split or another—you can override these assumptions!
As I said before, the notion that the binder and inspector are coupled together is something that might be superficially assumed in the software’s most basic and default usage, but it is capable of doing things that would make that simplistic coupling inconvenient, or even downright confusing. It must be premised upon a more flexible model—and not one that I would say is terribly unusual given the integrated right-hand sidebar design.
And on that matter of defaults, it is worth being mindful of the fact that you had already disabled a default setting, and were thus using the software in an more advanced state. By default one does indeed get the folder inspected in Scrivenings when they click on it. We cannot promise that every combination of Scrivener’s many settings will always produce perfectly obvious outcomes—becomes sometimes the outcome that is not obvious is precisely what one wants, if they are expecting it.
I suppose we could change it to bright red, to denote Scrivener isn’t Finder, but I don’t think that is what you mean. You’re already in a different design context though, at the point described above. The Finder inspector is decoupled from the integrated browsing environment within the window itself, and presents itself as a floating panel. It is indeed conventional for floating panels such as these to track all interior clicks in real-time. You would do better to look at how an analogous integrated right-hand sidebar component in Finder works: the Preview pane. Note how that completely disregards sidebar actions and is wholly dependent upon the activity within the area that is analogous to Scrivener’s editor?
That said I don’t know how useful Finder is as a comparison. Perhaps something a little closer to Scrivener in both its design ethic and intended usage, like Ulysses, would be worthwhile. Last I checked their UI works in a strict left to right fashion as ours does, with an inspector that only regards the selection and cursor state outside of the leftmost sidebar view.
I’m confused here by this: if the state is indeed the same in step 1 and step 3, and the state you desire is that seen in state 3, then one needn’t go beyond step 1 at all, correct?
With the default settings, the first document in the Scrivenings stack will be the group you clicked on, and as a new Scrivenings session, that is where the cursor will be positioned, meaning you will be inspecting the group.
Sure, if you go and click on a child document all by itself, then you’ll be inspecting the child document, because now the cursor is in the child document in the editor. But now try this: click the Back button in the editor header bar. The inspector doesn’t stick to the child item you clicked on in the binder. It is now inspector what you are working on directly. As you would put it: it is reflecting your selection in the application behaviour. (Also, note that if you had moved your cursor into a subdocument within the session, when you return it, rather than clicking on the group again in the binder, you will be returned to right where you left off.)
Well, I would strongly disagree with that assertion (nor do I entirely understand it to be fair—oftentimes the selection is inextricable with the cursor, in the sense that commands that operate on the cursor will operate on a selection and vice versa). If you select a heading in Pages you will expect the inspector to operate off of (a) the text that is selected and (b) the applicable context around that text if necessary. When you move the cursor I am sure will expect such things as the Style information to change, too.
Once you get past this learning bump and find yourself writing within a thirty-section Scrivenings session, you may come to appreciate the fact that you can jump over to the inspector and jot down some quick notes regarding the section you are currently working on within the larger session—the section that the cursor is active within. That is the design goal here—to operate in support of what we are doing within the editor, not some thing we clicked on two hours ago in a sidebar that may even be hidden at this point.
It has been this way for over ten years and there are strong reasons for it to be the way it is. Rather than upheaving countless thousands of user’s experiences and expectations with what you feel should be correct, the simplest and most globally efficient response is for you to change to how it works; to find its inner logic and tap into how best to make use of it.
Keeping in mind that I don’t buy the assertion that we’re being really weird here, or violating fundamental design rules—even with that said, not everythings needs to, or should, be conventional, and sometimes even rules are well broken—even if it does mean acclimiation may be necessary. If the end goal of design, maximum power and efficiency, is best achievable through acclimation, then it is a worthy cost. I do not understand any argument that tries to say otherwise, that software should all melt toward an expected middle that never shocks, never demands we figure out why it works the way it does, and never challenges us to adopt a premise it might be offering that nothing else does.
I became aware of the mistake, which is unfortunately not the same as clear communication.
There are two very fundamental issues here that strike to the heart of L&L.
The first issue is that I can tell you have not tried to reproduce the reported problem before launching into a 1,200-word “I’m right, you’re wrong” essay. As stated above, I did re-enable the default preference, and the problem persists. For total clarity, the steps to reproduce:
create a new blank project
add sample text to first text document’s synopsis, e.g. “Foo”
Documents > Convert > to Folder
Project > New Text (as child of previous folder)
add sample text to child text document’s synopsis, e.g. “Bar”
select enclosing folder in Binder
View > Scrivenings
position cursor in child text document
select enclosing folder in Binder
The Inspector will show synopsis with “Bar” rather than the folder selected. This is contrary to your statement above that by default the user gets the folder inspected when they click on it.
The second issue surrounds the notion of user expectation. I have worked with many developers on software projects of different sizes. Regardless of how many developers on a project, how many years it has been actively developed, or how many users it has, code always has mistakes. But the single biggest mistake developers make — the mistake that renders all others meaningless — is the mistake of blindness to their own mistakes. Being intimately familiar with their own project, their perspective becomes so clouded with the reasons for pursuing an idea and the energy put into the code, that it blocks out the reality of the validity of the idea itself. This mistake gets worse over time as developers put increased energy into both working on the code for the idea and fortifying their reasons for why the idea is valid, and so it becomes increasingly difficult to walk it back and see reality for what it is. Forest for the trees. I’ve had people argue with me that “0” should actually mean “1” because it works better for their code.
UX mistakes should be easy to spot: when software behaviour differs from user expectation, the reality is that you have a UX mistake. However, when this kind of reality-rejecting culture takes hold of a development team, it is almost impossible for anything but superficial mistakes to be fixed or even acknowledged. They will put immense effort into protecting the integrity of the bubble within which their ideas are still valid — a 1,200-word essay blaming the user is a lot of effort but doesn’t make the mistake go away.
Scrivener is not a complex piece of software; it is TextEdit wrapped in a bunch of bells and whistles. This being the case, the user’s primary expectation is that those bells and whistles work properly. You’re not making high art here — you’re making a tool — it’s not supposed to “challenge” us.
The folder is already selected in the Binder when you click on it the second time and the Inspector reacts on what you did in the Editor, i.e. position the cursor in the child. From left to right…
You have to change the selection in the Binder to get a new reaction. If you click on the child and then on the folder the content of the Editor will change and thus also the Inspector.
From left to right… which makes sense when you start using the software in a more advanced way. It’s for this exact reason that moving through a scrivening in the Editor doesn’t change the Binder, only the Inspector.
Thank you for your feedback! This is just a note to let you know that your valuable suggestion has been filed in our system. We appreciate your support. We also thank you for the additional detail you have provided to your report. Someone may be in touch with you if we require any further information.