Any chance of making the bits you grab to change binder/inspector widths more than ONE PIXEL wide? 
It should be more than one pixel wide, more like four or so. The actual grabber is invisible, and thicker than the aesthetic line you see. But, I’m not around a Windows machine at the moment to verify, so maybe I’m wrong about that.
This is SO weird - I just checked again, and it’s TWELVE pixels wide. But the other day I repeatedly tested it and it was definitely one. Either my computer’s playing up, or - the only thing to have changed since - it’s because I’ve registered my copy of Scrivener. That would be mad. Hey-ho… I’ll crawl back under my rock
But before I do… the “invisible” handle is a bit daft, IMHO. It apparently increases available space for things, but actually doesn’t. Why not just have a visible bar and have done with it? As it stands, one could legitimately click IN the inspector but fail to focus it. Worse still, one can click on the vertical scroll bar in the binder and find oneself adjusting the width. An example of form over function. :-/ Also, it’s inconsistent with the more standard way the split screen is done in the main working area of the screen.
You’re preaching to the choir.
It’s a design trend, we do adopt those if they aren’t ridiculous, like removing all application menus or monochrome buttons for everything. So this invisible dragger interface concept will probably come and go and those of us that prefer thicker spacers between UI elements may once again have our day.
As for its purpose, that’s all it is, entirely visual. As you point out, there is no logical basis for it because the space saving is mostly illusory and competes with close elements near it. The point isn’t to save space, but to make everything look “cleaner”—and that is subjective and always changing.
I hear ya
It’s not just subjective fashions though… this is about putting your mouse pointer on a scroll bar and then finding it does something else. Basic (not to mention objective) interface design issue. Affordance fail, lol.
I’m a big believer in “If it ain’t broke, don’t fix it” - and this seems more broke than a conventional design.
The disillusioned few can sometimes make a much louder noise than a quietly contented majority.
I’ve no idea where the balance of opinion lies (and don’t really think it matters, to be honest), but on the off chance that that it wasn’t clear… there are some of us that prefer it as is.
In case it wasn’t clear? The “think-it’s-wrong-and-THESE are the reasons” outnumber the “I-like-it-cos-I-just-DO” on this thread 2 to 1. Go figure.
Hey, I was just making sure it wasn’t 2-0! 
And “cos it looks good” is a good enough reason in my book (not everything has to be pure function). I have to look at the sliders a lot more often than I have to move them.
Here’s the problem I see: They don’t work the way a windows user would expect. You expect to click in a scroll bar and have it scroll, not resize the window. Also, a particular style of dividing line tells a windows user “this is resizable.” That would be worth the few extra pixels.
If you had a great reason for designing a car with the accelerator pedal on the left of the brake pedal, it would still be a problem.
But you have done a much better job at porting to windows that many other developers.
Yep - especially as those pixels aren’t being used for anything else - the resize handles are there and are taking up screen real estate - just invisible.
Seems to me that a global toggle setting for this would be a good way forward. It would give everyone what they like. At the moment, as the thickness/existence is inconsistent across Scrivener, no one is getting the setting they prefer…?
I don’t know… I’m pretty sure that these days if you see any line between panels in software it’s pretty clear that you can hover over it to see if it’s resizable. After all, you guys all found it; you’re not complaining about having spent a few months swearing that it wasn’t resizable before someone happened to mention in casual conversation that it was. You’re also not talking about making a change that would make it easier to resize, and the handle is already the size you want it to be… you just can’t see it.
I’d personally rather have a thicker handle that I would have yet another preference I have to tick, but considering that the only change you are asking for is (therefore) a cosmetic one, perhaps you could acknowledge that the purely cosmetic arguments on the other side are equally valid?
It seems to me that we are already in the best possible compromise position: it has the clean looks of a small handle, but has the easy functionality of a large handle.
My only problem with the resize area is that it’s too large vertically. Often, I try and scroll through a document only to resize the inspector panel instead. I’d prefer a small resize handle that is only a quarter inch high or so, right in the middle of the separator line between panels. It can be only a few pixels wide, and then there’s a definite spot to click if you want to resize, and anywhere else on the scroll bar will just scroll the document.
Not to belabor it, but I just noticed that I went to scroll up, and resized the window instead.
I hadn’t realized it, but that has been happening now and then. I thought my aim was bad, but now realize it’s not my fault.
Hmm… yeah, if we must have invisible resize handles, they should at least fall in the dead space rather than over another control.
I’m honestly clueless as to what you are referring to. There hasn’t been a standard look for splitters since, arguably, XP. In MS Office 2010 for example, just about every splitter looks different from every other splitter, even in the same program! There are even some splitters in Office that look and act exactly like ours do, all the way down to overriding the adjacent scrollbar along a sliver of pixels.
What you’re saying may have been right back in 1998, when everything looked like warm grey 3d buttons, but that’s basically what I said above—design trends have been to minimise the visual density of everything, including stuff like UI zone resizing. It’s been going that way for a long time now.
And to reiterate, since there seems to be a pile-on of people saying it’s crazy to save three pixels over something like this: this is not about saving three pixels! This is about keeping up with design trends so that we aren’t the only car on the block with faux wood panelling on the sides. 8)
Thanks! But that might not be fair, because we didn’t port it at all. Scrivener for Windows was written from the ground up for Windows (and Linux). There isn’t a single line of code from the Mac, and nearly every design element within it has been researched and emulated from the Windows platform (mostly from Microsoft). We’ve seen how badly ports can go, in either direction, and didn’t want to be one of those companies that just took the easy way out, even though that means years more work.
Er, and that makes it ok? It’s disappointing to see that being trendy is rated more important than basic interface affordance. As our parents might’ve said when we were kids: “So, if Microsoft Office jumped off the roof, would you?”
A slider should slide. End of.
Well then I suggest we all tell our parents that they are resorting to a straw man logical fallacy, creating a distorted extrapolation that has no bearing at the point under discussion so that they have something easier to attack than the reality.
I really like the single-pixel dividers with some buffer room around them. They make the interface cleaner and I have never had a problem with them in any application I’ve used. The point isn’t that Scrivener is doing it just to be trendy, it’s that I prefer them and that they are in common use across many applications, so we aren’t doing anything unusual or contrary to standard - or good - UI design (on either platform). They are not any less usable than the other kind of split divider, so this really comes down to an aesthetic preference. Obviously users are free to like or dislike this trend in modern UI design, but it’s an aesthetic choice we have made to adopt this new standard and one that is hardly left-field. I think that pretty much concludes L&L’s stance on this topic.
Have a good weekend all!
I’m relieved to see it’s not just me. I’m constantly re-sizing the inspector when all I want to do is scroll. Happens often enough to be really irritating.
Again today I was wondering why, when I was just trying to scroll up, the text in the editor was changing. Then I realized that when I clicked and moved the elevator in the scroll bar, I was not scrolling, I was resizing, and because I wasn’t moving exactly up and down, but a little to one side, some of the line breaks changed.
This is such a no-brainer error, that I had to mention it again.
Note that the problem isn’t the width of the resize area. The problem is that you think the mouse cursor is in the scroll bar, because it doesn’t change to this:
There is a three-pixel-wide area in which the cursor is wrong.
So you act accordingly, but the program does resizes instead of scrolls.