Building like it's 1984: Scrollbars in web applications

I would like to venture the unpopular opinion that platform-native scrollbars are not a problem.

With native scrollbars, it meant that different browsers/OSes would display Height differently, and that using a different scrolling device would drastically change how Height renders.

I'm old enough to remember when we called this a desirable feature, when consistency was measured across the user's experience instead of across the product's presentation.

Windows and macOS with scroll wheel have the biggest scrollbar footprint, they actively reduce the displayable content, even when not being used.

Scrollbars are passively used; you can glance over to know where you are in a document. They even recognize this use later in the article!

It is kinda interesting to think about how scrollbars can be adapted for infinite or unknown length content though. I keep thinking about a two-level scroll, coarse and fine. Think of the coarse scroll as being like pagination or timeline selection, then the fine adjustment is your normal scrollbar inside that view.

So for something like a chat with an extremely long history, you might have the timeline selector be like "current time back to last time i logged in plus 30 more messages" by default and let people also be like "start at 10am and show me the next 500 messages", and you scroll inside them. Then, when you get to the end of the scrolllable area, you have previous/next page buttons to adjust, with some level of overlap it still lets you scroll by.

I need to stop talking about this and actually implement it some day. I'm not sure it really belongs as a bar right next to the scroll bar or what though.

When designing user interface for invisible scrollbars, we need to pay attention to the invisible track to avoid overlap between the scrollbar and the content. [from a couple paragraphs later] Invisible scrollbars sometimes make it difficult to discover overflowed content. [from much later] Avoid layout thrashing when rendering or measuring scrollbars. An easy way to do so is to use fastdom.

I agree you shouldn't overlap scrollbars and content nor thrash layout, and their solution is a step in the right direction.... but next step is to not make the scrollbar disappear at all! Give it a dedicated space and make it always visible. No more overlap, no more relayout, and you keep the passive display of article position and length. And it is less work to implement! Everybody wins!

Their scrollbars have a larger track which is used to indicate to the user where errors, or search results occur in a file.

I think this is a legitimate improvement on the scrollbar concept, I kinda like it and wouldn't mind seeing it exposed by standard apis (I plan to work it into my gui toolkit but haven't found the time yet). A lot of browser's search functions also show hits in the scrollbar kinda like this. I'd like to take it a step further and let users put arbitrary marks on the bar so they can save their position and jump around. Make that part of the standard native scrollbar and all apps can benefit without having to do work! It'd be great.

I think all scrollbars should offer some kind of user-defined marking, jumping, and numeric input somehow for when you need more precise control than the normal bar provides. I sometimes use vim's mark/jump capability (the m key and the ' key) but it is so easy to forget what I marked as A or B. If the scrollbar actually had a little indicator at it, that'd help a lot. Could maybe even put a note on it expandable on demand, you know, like those sticky tabs you can put in a paper binder.

I wish the people who did custom scrollbars thought about user cases at least as much as they do about their designer's brands. It seems like an area you could innovate while building on the lessons of the past.

edit: oh another thing, i think scrollbars should be right on the edge. so if the window is maximized, you can target the scrollbar from the edge of the screen. why? Fitts' law - make the target bigger for easier grabbing! This is easier to do native since that's who would be responsible for window borders. But on the other hand a window border even one pixel wide might be usable by the OS thanks to the same concept. still that's a platform decision that can be supported.

I dislike invisible scroll bars more than I dislike visual clutter, so I have scroll bars turned on wherever possible. It's not always obvious to me that there's more content off-screen, but the scroll bar tells me this at a glance.