This is how chrome does it to. The first time you scroll a little you see how long the page is. You don't need to keep seeing something that doesn't change.
The funny thing is, if scroll bars never existed and someone tried to add them they would be considered terrible UI.
You need to hit a tiny target with your mouse, that gets smaller and smaller in proportion to the size of the document. Missing the scroll bar, and hitting the gutter moves you to a random page with no simple way to get back.
On small documents a small mouse movement scrolls by a small amount, but on a large document a small mouse movement can scroll way too fast.
On some systems clicking the gutter is "page down". On others it is "move to this relative point in the document".
With a mouse wheel or track pad the scroll speed is consistent no matter the size of the document, and the user can scroll faster or slower very easily. And you have a huge target - the entire document. There is no chance of paging when you mean to scroll. Scrollbars are obsolete.
Scrollbars aren't meant to be clicked ever since the invention of the mouse wheel. Their primary job is to tell you that you can scroll, because there's more content. If you hide the scrollbar until you scroll, then users often won't scroll, because they won't know there is more to see.
The secondary job of the scrollbar is to tell you where you are in relation to the content, and how much of it there is, relative to what you see on your screen. Both of these roles are best fulfilled when the indicator is persistently visible.
You could make scrollbars transparent to clicks and they'd do 90% of their job already. The ability to click on them to quickly jump to a desired location is a useful bonus, even if not frequently used these days. What matters is that they're visible.
>If you hide the scrollbar until you scroll, then users often won't scroll, because they won't know there is more to see.
Do you have evidence for this, even if it's anecdotal? To be honest a statement like that sounds like a hypothesis and a reasonable hypothesis, but I am not joking when I say when we did user testing, it was absolutely never the case that someone actually didn't scroll because they didn't see a scroll bar. Now we didn't test specifically for that but I'd be surprised if a controlled experiment testing that hypothesis concluded that people will actually just never bother to scroll unless they explicitly see a scrollbar.
Scrolling is actually a very natural thing that people do without the need to visibly see a scrollbar. Using a dedicated scroll button or gesture is a very cheap and consequence free action to perform. I'd be very surprised if you have data that contradicts this and indicates that an actual human being would simply not scroll because the only visual cue/indicator that people use is a scrollbar, rather than the multitude of context specific information available to indicate whether more content is available.
I only have anecdotes to support this, but unless I'm a really weird outlier, I'd say it's indicative:
- Almost every discussion on Apple and scrollbars I see on-line has someone telling a story of how they didn't realize some app was scrollable, because its visual grid happened to align perfectly with viewport size of their iPhone/iPad;
- I got caught myself by this a few times on PC, where the design of the page looked complete, scollbars were hidden, and I didn't realize I could scroll down;
- I've been the person to tell some confused non-technical people that they could scroll down to see more, because the layout of a webpage did not make this obvious, and without a scrollbar visible, they were just puzzled why there's so little information on the screen.
Plural of anecdote is not data, so I'm open to the possibility I may have just had peculiar luck, but I think it's fair to assign a low prior to that.
> that an actual human being would simply not scroll because the only visual cue/indicator that people use is a scrollbar, rather than the multitude of context specific information available to indicate whether more content is available
What these cases had in common was that there was insufficient context-specific information available to make it apparent the content is scrollable (and - anecdotally, again - in my experience, non-tech-savvy people don't have the nervous tick of just randomly scrolling on the wheel, to check if it does something). Sometimes, the only such contextual information was the feeling you got after reading everything on the page, that something is missing. But if your users have to reach that point to figure out they can try scrolling, the UI failed at its job, and wasted them a minute of their lives.
The worst offender I've seen is the share button on the iphone. You can scroll down to select more sharing options, but the first row of options aligns perfectly with the bottom of the screen. I've seen at least two people have no idea there are more options.
Is that how it works on macOS? If so, it's plainly broken.
On Windows, and in every Linux GUI framework I can think of, clicking anywhere above or below the scroll thumb scrolls exactly one screen page up or down, for the very reason you've described. To navigate to an arbitrary spot, you're supposed to drag the thumb.
On GNU/Linux systems, at least, you middle-click to say 'go to this place'.
I love my scrollbars, and I want them always visible. I don't use the mouse often, and I certainly don't want to have to use the mouse just to see context.
Chrome implemented even worse nasties on GNU/Linux with scrollbars though, including forcing a snapback to original position if you drag the scrollbar but happen to move the mouse a few pixels too far left or right of the scrollbar [1]. Apparently that's how Microsoft Windows users do things. So now we have to as well.
Windows does it, but "too far" is actually closer to 500 pixels, not "a few". You'll certainly never run into it in normal use. I actually find it useful because I can refer to two places in the same document without losing my scroll position (I don't think that's its intended purpose, but it works).
macOS can be set to either behave the way you're describing when you click above or below the scroll thumb, or to navigate to that point in the document when you do that (e.g., click 80% of the way down the scrollbar and jump to the 80% point in the document).
The funny thing is, if scroll bars never existed and someone tried to add them they would be considered terrible UI.
You need to hit a tiny target with your mouse, that gets smaller and smaller in proportion to the size of the document. Missing the scroll bar, and hitting the gutter moves you to a random page with no simple way to get back.
On small documents a small mouse movement scrolls by a small amount, but on a large document a small mouse movement can scroll way too fast.
On some systems clicking the gutter is "page down". On others it is "move to this relative point in the document".
With a mouse wheel or track pad the scroll speed is consistent no matter the size of the document, and the user can scroll faster or slower very easily. And you have a huge target - the entire document. There is no chance of paging when you mean to scroll. Scrollbars are obsolete.