Inspector Panes Layout and Size Control

Apologies if this specific request has been made and discussed, but I did search the boards for awhile looking for either a way to do what I want to do or an existing request, and I found some related ideas, but nothing covering exactly what I’m wishing for. So with that said, I have two related requests for user control over the inspector panel specifically and the layout of the program generally.

I find it frustrating that the synopsis pane in the inspector can’t be directly resized. In general, I find the way the synopsis feature is implemented to be very helpful to me — because of the size of index cards and the synopsis panel in the inspector, the program pushes me to write brief overviews of different sections of my work and my notes… and this, naturally, forces me to think in a more organized way. This is great. But Scrivener runs on a wide variety of different display sizes, and as it stands, the synopsis pane seems much more appropriate for a laptop than for my 27" iMac, and it’s so small that even truly digested, compact and efficient synopses generally spill out of the viewable area of the synopsis pane.

By the same token, the taller the monitor, the more space is allocated to the bottom pane, whether it’s displaying document notes or references or keywords or custom meta-data.

Different people, however, and even different projects created by given individuals, are going to have a different amounts of information allocated to synopses, document notes, document references, keywords, and custom meta-data.

So my first request is this: please allow us to vertically resize the synopsis pane at the top of the inspector and thus its multipurpose bottom pane too. (Presumably the best way to do this would be to let us click and drag at both the bottom of the synopsis pane and the top of the bottom pane, but of course either action would have the same effect.) I realize that letting us put more than one of those bottom-pane options in the inspector at once is technically infeasible and not an option (that much I did find from searching) but either way, this would be a tremendously useful feature in my opinion, and I’m willing to bet a lot of other people would agree. Nor do I believe it conflicts in any way with the concept, design or mission of the program, though of course as the developer you’re the ultimate arbiter of that question.

My second request is somewhat related, and I did find some discussion of the general issue, but nothing covering the precise problem and solution I’m talking about.

I’d really like some mechanism by which dragging the right side of the program’s window only resizes the inspector. I spend much of my time working in vertical split view, and I set my two editors to be exactly the width I want them to be for easiest reading and editing, but then often enough I need to resize the inspector to get some more room for the synopsis pane, and then presto, my nice, tidy, matching, comfortable editor layout is messed up and I didn’t actually get any more room for the inspector. Instead, I first have to drag the right side of the inspector to the right, then show rulers for the editors, then drag the right side of the right editor back to the left until it’s the proper size, and then hide the rulers again — and when I’m dragging the right side of the inspector, I’m really just guessing about how far I need to drag it, because I’m not seeing the text reflow in the synopsis inspector pane, the ultimate purpose of my actions, so often it takes a few iterations of the whole sequence to get things just right.

I realize that this specific task flow is probably not exactly a universal one, but I do think there’d be a lot of value in having the option to resize any panel without affecting the size of other panels but by resizing the whole program window instead. Perhaps holding the option key while dragging would work. Thus, holding option while dragging the right edge of the binder would resize the binder and thus the whole program window without affecting the sizes of the editor or editors and the inspector if it’s visible. And option-dragging the right edge of the left editor would resize it and the program window but nothing else, and so on.

Together, I think these two tweaks would remove some modest user experience frustrations and make arranging our layouts much easier and also more useful, so I really hope you’ll consider them.

Will it not serve your purpose to scroll down in synopsis pane, rather than re-size it?

This would also, I think, answer part of the second problem.

ps

No, not at all. Or maybe a little, but only very minimally. I already know I can do that, but it doesn’t address layout control, which is frustrating in the ways I described, or optimal utilization of different display sizes and optimal displays of different distributions of information. At least for me, the synopsis is a glance-at-it-and-take-in-its-information field — an aid to processing an overview of the material at hand. Having to go in and scroll down through an individual synopsis, at least if it’s a reasonably short one, really undercuts that utility. And it seems particularly unnecessary given that people using larger displays have plenty more space than is actually being made available to use, at least for that particular part of the interface.

Besides, there’s already a very limited form of resizing available for the bottom pane — if you hide the synopsis, if you either don’t need it at the moment or if you just don’t use it in the first place, the bottom pane expands to take up the freed space. It would just make the program more flexible (and thus somewhat more useful in more use cases) to offer greater flexibility in that respect.

Why not – as you have a 27" screen – include an extra-wide synopsis pane in your initial set-up?

ps

I have, up to a point, though I still think the sizing controls I’m asking for would be both very convenient and very useful and probably not difficult or confusing to implement, but I typically also have project notes open on the right side as a sort of scratchpad for things with no immediately obvious place and for other notes which I want to keep visible much or all of the time. Sometimes I put a list of things I want to get done before calling it a day, sometimes structural stuff I’m kind of working out as I go and which isn’t yet figured out enough to work into the structure of the binder and the work yet… various things. I find it useful.

But like I said, I think the option-drag sizing idea I offered (or some other mechanism to do the same thing) would be really useful. If you don’t think you’d use it, cool, but I don’t see why you seem to think it’s inherently a bad idea. (If I’m understanding your general thrust correctly.)

I don’t think it’s inherently a bad idea; I think it’s inherently a needless frill. You write

What you appear to be saying is that you want a lot of space available in the Inspector (the panel on the right side). Why not then leave it permanently at a wide setting? Is there some need you have not mentioned to return it to a narrow setting?

ps

As a random reader, it seems there’s a bit of information left out of this dialogue.

p_benjamin, have you looked into from the menu-bar, which is what I think PJS is referring to without being so specific? You can set your Scrivener window layout as you like it, with a wide inspector, then save it with a suitable name. You can then save other named layouts, with a narrow inspector, or left-right split, or no inspector, or whatever takes your fancy or needs.

The “Manage Layouts” pane is accessible with a built-in shortcut, or, as the menu lists the layouts you have saved, you can use System Preferences to assign shortcuts to your wide-inspector and whatever others you need to change to and from quickly.

That way, you can have your wide inspector with more room for your synopses, without Keith having to re-program the inspector pane … a topic memory tells me has come up before on the forum with reasons given as to why it is the way it is … but old age means my memory may be playing tricks.

:slight_smile:

Mark

Mark is right, of course. My bad. Long-time users tend to forget that features familiar to them can be confusing or even unknown to the new user.

As Mark says, set up the screen as you choose. (It may be easier to create a wide inspector first, then split the editor area.) Then click on Window > Layouts > Manage Layouts. A small screen will show the layout. Click on the + (lower left) and give it a name.

ps

The synopsis in the inspector is designed to keep its 5x3 aspect ratio, so when you widen the inspector, the index card gets taller - on a 27" screen (which I use myself), if you widen the inspector to its widest, the index card has plenty of room for a lot of text:

This is certainly an artificial constraint, but one of the reasons it is there is technical. Scrivener has to accommodate all screens, so the inspector has to be able to fit all of its controls on an 11" screen as well as a 27" one, and the index card at its tallest (when the inspector is widest) is the tallest it can go without the other controls disappearing off the screen on a small monitor. There is also the other aspect you bring up - the index cards are intended to encourage users to write short synopses in there, as they are not intended for long notes; that is what the notes area is meant for. I’m not entirely against allowing more flexibility in the sizing of the synopsis pane, but at the moment there are certain technical challenges involved - split views (which is what would be required for resizing) are notoriously awkward in OS X (Scrivener uses them extensively, and has an incredibly amount of code for such seemingly simple resizing controls), and could cause problems in the inspector.

I have therefore put this on my list of considerations for 3.0, given that it would involve some serious redesigns and recoding to the inspector, but it does come up occasionally. No promises, but it is something I will re-evaluate when we come to looking at features and refinements for 3.0.

Regarding your second request, this comes back to the awkwardness of split views, unfortunately. A split view is two panes with a divider between them. When you have the binder, two editors and the inspector visible, you have one split view containing the binder and another split view, and the split view inside that containing a split view and the inspector, and the split view inside that containing the two editors. Because of the fragility of split views on OS X (everything broke on Lion and I had to recode a lot of this, because of some supposedly minor changes to the way split views worked), changing the behaviour here isn’t as simple as it might seem. Add to that the fact that the inspector will have a maximum width after which the editors would need to start resizing anyway, and it gets even more complicated. Not that I think this is necessarily a bad idea, just a lot more complicated and involved from a technical perspective than it would appear from an end-user perspective. I’ll therefore look at this when I come to look at the editor for 3.0, too.

Thanks and all the best,
Keith

I may have skimmed a bit too much, so my apologies if I completely missed the point, but… There’s a check-box and a couple of other nearby settings to make the editors be a specific width, no matter how you manipulate the size of the binder or inspector. Sorry I don’t have my mac with me, but I think this should be fairly easy to find in the program settings. The saved Layouts feature might even allow you to set up these fixed-width editors for different monitor sizes if you need to move from your desktop display to a laptop screen.

Ahhh… somehow that had escaped me.

FWIW, though, I don’t think maintaining the index card ratio in the inspector makes much sense as an artificial constraint.

In the corkboard view, the corkboard-and-index-cards metaphor works, IMO, for two reasons. First, it effectively communicates the nature and purpose of the interface elements by ably using a familiar metaphor. And second, it fits really well with the constraints of the interface — there’s a rectangular area with constituent elements in it, so making those constituent elements rectangular maximizes the efficient utilization of space. In the inspector, though, we’re not actually able to move cards around (nor would we want to) so maintaining the shape of a card is, if anything, giving us the wrong information about what we can do with the “card”. (Though admittedly I didn’t even notice that card shape in the first place, since I assumed its context in the inspector obviated that element of the metaphor.) I think preserving the lines and color theme of the index card is enough to tell the user to expect a synopsis there; more extensive skeumorphism is, I feel, counterproductive in the inspector.

Also, both to clarify to you if I haven’t made myself adequately clear and to answer other posters’ strange suggestion that I just make the inspector wider in order to expand the space used by the synopsis pane within it, that just winds up wasting more screen real estate on those projects or in those instances when I’m not using the bottom pane for anything — i.e. when I have no keywords or custom meta-data or what have you, or when I just don’t need to see them. I can’t imagine I’m unique in sometimes not needing to see anything there, but the wider I make the inspector, the more space that pane takes up and the less space is available for other things, like the binder, the editor panes, the project notes window I often have up on the right side of my screen, a quick reference panel, and anything else I might want visible.

Of course at other times and when working on other projects, that bottom pane is great and much needed. But the kind of flexibility I’m talking about would be really useful and very much appreciated.

As to the technical issue, I hadn’t realized that split views were quite so problematic. I hope Apple improves the situation or you find some way to compensate for the problem in the v3 release, whenever that comes.

And regarding those with small screens like laptop users, certainly you need to serve them just like all your customers, but it seems to me that if you just have the synopsis pane default to a small size, it’s up to individual users to resize (or collapse) elements as they want, just as they can select their own preferred font(s) and sizes for a variety of different interface elements in order to make the program work best for their needs and with their gear.

Anyway, thanks very much for the clear and comprehensive reply, and thanks much more yet for the awesome work making Scrivener such a terrific tool!

Seriously??

I have this LITTLE ITTY BITTY Tiny little index card that I use A LOT and put a lot of information into. And then I have this GREAT BIG EXPANSE the size of Oklahoma right below it that I don’t use AT ALL

Would you add the vertical splitter PLEASE?

Good morning!

@jwhitten, you’re responding to an eight-year-old thread which had technical comments that applied to Mac Scrivener of that time, here. In Mac Scrivener 3.x.x, the synopsis pane can easily be resized vertically, and the notes pane collapsed, so that the synopsis takes up almost the entire Inspector sidebar. Although I’m not set up to test it :wink: , as Windows Scrivener 3 is intended to match Mac Scrivener 3, I infer this functionality is already in the Windows Beta. I can understand if you don’t want to switch to the Beta for production work, but you might check out whether this change has been implemented yet in the Beta. Happy writing!

I haven’t read through all of the posts, but can confirm that the Win v3 beta Inspector has a vertical splitter, so I can resize Synopsis vs Notes panes, or even collapse the Notes pane entirely.


Best,
Jim

I have read the additional reply and understand that it is coming in version 3.

Hopefully that is coming VERY soon!! :wink:
I’m looking forward to using it.

I am anxiously looking forward to the release of Scrivener 3 for windows. :slight_smile: