left-right scrolling in binder

Dear KB and the Scrivener team,

Once again: thanks very much for Scrivener; I would not be getting through graduate school without it!

I could not find this suggestion in the wish list, although someone may already have suggested it.

I have lots of folders/subfolders etc, but, in order to save space, dont like to make the binder subwindow very large. This means it is impossible to see all the different subfolders etc without hoisting the binder.

Would it be possible to allow left-right scrolling in the binder window? This would allow the user the see all the various levels of files and folders without resizing the width of the binder window.

(The attachment clearly shows the issue.)

Thanks and regards,

David

Screen Shot 2016-04-22 at 09.07.09.pdf (43.8 KB)

It would be unorthodox to have the left sidebar view scrolling horizontally like that—they are traditionally meant to be more of a high level index where you use the rest of the window to dig in deeper. A good example of that is an e-mail client, where you have high level folders and accounts listed on the left, and when you click on something it loads the contents of that thing into a whole separate navigation interface, and the things you click on inside that pane get loaded in yet another pane (the e-mail message itself in this case). How I work in projects with a lot of hierarchy is to turn the project window into something more like that. There are three simple ingredients:

  • First, split the editor so that you can have a navigation pane and a content pane.
  • Use the View/Binder Affects/ sub-menu to select one of these panes as a dedicated target for all binder clicks. Instead of loading things in whichever split you have open, clicks will only ever impact the pane you select.
  • Now click on a folder in the binder so it loads in the editor and change the view mode to Corkboard or Outliner. In the footer bar of this split, click the button with an arrow coming out of a box. That will cause anything you click on in this pane to automatically load in the other pane.

Putting the bulk of hierarchical navigation into the main editor means much more space to see what you are doing, and to be able to work with multiple levels of hierarchy more easily. As you can see, not all of the ingredients are necessary. For example you could leave off the third, leaving opening documents into the content pane a deliberate action (Shift-Cmd-O opens the selected document(s) from one pane into the other).

How does this work in practice, particularly if you like to use two panes for content already? In my experience it doesn’t really get in the way at all. The per-split History feature is very powerful—you can go off on a tangent in one split, then right-click on the “back” button and jump straight back to where you were. You can even flip forward and backward in history while typing in the other split with Opt-Cmd-[ and ]—I use that capability to jump between my chosen research files and the last navigation tree I was using—I think of history a bit like a session of tabs without the tabs. It is also easy to lock a split so that all of this auto-load “wiring” we set up doesn’t get in the way. Finally, the project window can be saved into configurations like this and hot-swapped with the Window/Layouts sub-menu. You can use a 3-pane style window for high level organisation work, but once you’re ready to do a 30-minute writing session, switch the whole UI over to a configuration more conducive to that process.