Sequence of Collections

I’ve just updated to Windows Scrivener 3.1.4.

The *Add to Collection" command lists the collections in reverse order from their list in the binder sidebar.

Search Menus also does this.

And Go to Collection

This may have been the case prior to the update, but I’m fairly sure I would have noticed.

My assumption is that this is a bug and that the intent is for all Collection lists to be sequenced same as in the binder sidebar.


It has always been this way (I think!), and it is in fact intentional. The ordering is for ergonomic reasons: the items considered most “important”, in the sense of what you use most frequently, would be placed toward the bottom of the collection list in the binder sidebar—thus placing them closest to where your mouse is most likely to be before switching. Likewise the top of the menu requires the least distance to move to activate.

Sorry @AmberV, there’s some communication wires crossed here, because I’m not understanding the logic behind this implementation.

The collections list in the binder is limited to 7 items, therefore the collections at the bottom of the list are truncated and inaccessible without scrolling the binder.

For example, there are additional collections in this project, but they are invisible without scrolling:

Why would a user want to put the most “important” collections at the bottom of the binder list where they won’t be visible?

If you listed collections in the “Add to” commands in binder sequence, then we could simply place the “important” collections at the top of the binder list. They would be visible and accessible in the binder, and they would also be at the top of the list in the “Add to” command, right where the cursor is. A win/win for both working with collections in the binder and with “Add to”. I see only benefit here and no cost.

But by listing collections in the “Add to” commands in reverse order from the binder sequence, you’re forcing us to choose between a binder sequence optimized for working in the binder or for working in the “Add to” commands. I see only cost here and no benefit.

Why would you do that? It doesn’t make any sense to me. You guys seem to invariably come up with elegant designs within the limitation of the framework, so I’m assuming the challenge here is on my side. What am I missing?


Ah, yeah that’s true, the intent behind the design is somewhat rather hobbled by the fact that this was never fixed… You should be able to resize that to be as tall as you want, and the anchored scroll position should be at the bottom, not the top. Hence it would be the binder and search results always in view, along with whatever other collections you feel are most important just above them. It’s the lower frequency stuff that would be scroll off toward the top, and found down at the bottom of the access and assignment menus.

1 Like

The missing pieces! Now it all makes perfect sense. :nerd_face: Thank you for clarifying.

I think it’s fair to say, without the other pieces of the design being implemented, that the current reversed collections sequencing in “Add to” is needlessly burdensome.

Would you consider modifying the “Add to” command to list collections in binder sequence, and then implement the reversed sequence whenever the rest of the solution is ready to be rolled out?


I’m sure the problem has less to do with complexity and more to do with just being forgotten. I don’t think it makes sense to spend what would probably be as much time undoing the menu order, just to not do the work that needs to be done, and then reversing the menu order again once it is done.

Why not just fix it?

If the devs know what they need to do and all the problems are solvable and implementing the total solution is simply pending in the queue–sure, implementing the whole thing makes sense.

But if the devs don’t have all the elements of the complete solution worked out–particularly if there are areas of Scrivener where QT will not comply with the design goal and therefore implementing the total solution has proved to be troublesome and/or impossible–then making what is possible more usable would be my request.


Yeah, of course there will be things like that—either very difficult or near impossible—that you have to design around. But as I said above, it is very unlikely this has anything to do with anything like that.

We’re talking about a max-height limit on a split view being increased (like how you can drag the synopsis divider almost all the way down into Notes) and a scroll position adjustment (kind of like how when you open a text editor it can be scrolled to a certain spot). Neither of those things are novel features like Scrivenings mode using one editor instead of many.

So given how basic both of those adjustments are, it’s most likely the value in doing so was never recognised or understood when it got initially filed.

Thanks again @AmberV, I appreciate the explanation.