Evolution of the Scrollbar
scrollbars.matoseb.com
scrollbars.matoseb.com
Also not shown here, the Motif scrollbars of the same era had the arrow buttons on opposite ends of the widget (like on the Macintosh), but the position indicator was dynamically sized to also indicate the percentage of the scrolled world currently visible in the viewport. This is now ordinary.
Autohiding scrollbars that stopped taking widget space when there was no amount to scroll became popular a little later. They are great when you want many views scrollable when necessary but don't want the clutter of scrollbars when not.
Some modern UX design (i.e., advertising/engagement-driven) introduced a different kind of autohiding scrollbars -- which disappear when the pointer or finger isn't in the scrollbar area, even when there is something to scroll. They are an HCI abomination. Doubly so, when the suddenly appearing scrollbar interferes with the view.
1/3 the width of Windows 10, AND it auto hides. who in gods name could have possibly thought this was a good idea? what are you helping? width is RARELY the problem with desktop real estate, its always height. so you're freeing up space that doesn't need to be freed up. I get the thinking for a mobile device, but we are talking about Windows 11, its a desktop operating system. stop designing assuming everything needs to look exactly like an iPhone. for a desktop OS, its just objectively, scientifically worse:
And she uses her computer a lot for someone of her age. Not 8+ hours like I do, but more than most people do. Keeps the boredom away.
Though all of that should be properly configurable (which it isn't) so that other users liking other styles don't suffer
thanks for your helpful comment.
That's why you can't argue that a useless element (I'm using more convenient alternatives to scroll) is useful just because it's persisted for decades
so you are free to argue that its not useful TO YOU, but you should qualify that, as you dont speak for everyone, or even a majority of users.
Would someone care to explain to me what Apple's design philosophy is, and how it makes any sense whatsoever? To me it is "Make things minimalist until they become unusable, then hide them" but surely that can't be all there is
By default if you are using a regular mouse, the scrollbar is displayed with a light-gray marker for the current position (much like the Windows 10 example to the right).
If you are using a multi-touch input device (Magic Mouse or Trackpad), the scrollbar is hidden entirely by default. This includes the space or 'track' left for it, the scrollbar just appears as a floating bar when you start scrolling.
You can change this via settings to always show track and position.
CRTs had a built-in anti-aliasing
How to make them better?
Show more than your position
- Show the content
- Highlight matches
- Show what you’ve already read
- Show things that just loaded
Do more than just scroll
- Make the handle draggable and expandable to zoom
- Bookmark your position
- Autoscrolling
- Preview scroll position on hover
What are other things you have seen or would like to see?
If overloading scrollbars with bloat was a good idea, someone would have done it already.
Nah, the software world is moving away from providing options and configurability and has been for years. I have nothing against the standard scrollbar. I have everything against people like you who think it's the optimal solution for everybody, that a single solution could ever cover all needs, and we should never have any choice in it.
> If overloading scrollbars with bloat
No, adding useful features that can be enabled/disabled by preference. Apparently that's a bad thing to you. But thanks for pushing your short-sightedness as if it's the better solution.
It's a good job I didn't say that then: I don't want it first party. If you want to _configure_ some extension or application to provide it, more power to you, but don't conflate my argument with something that I didn't say.
> No, adding useful features that can be enabled/disabled by preference. Apparently that's a bad thing to you. But thanks for pushing your short-sightedness as if it's the better solution.
Enabled by preference is fine for the most common use pattern, which is the current status quo. OSes already provide this.
You've stretched yourself to put a lot of words in my mouth. Go back and read what I said again, it will help you to avoid this level of misbehavior in the future.
> - Show the content
> - Highlight matches
KDE's editors (KWrite, Kate, KDevelop) do this. I don't think they were the first though.
This is not really possible to do in a generic scrollbar component though.
https://cdn.maxxinteractive.com/uploads/images/gallery/2020-...
There was a similar looking scrollbar with a feature I loved from IRIX. When you would drag the middle slider, it would leave a shadow underneath it. So you could easily see where it was if you wanted to go back. Haven't seen another scrollbar before or since with that little nicety.
edit: Is System 1 scrollbar is unix based?
How ironic that on iOS it’s hard to try the scroll bars cause of the carousel’s drag gesture.
Apple introduced their first external trackpad in 2010 and then introduced the hidden-by-default scrollbar with Lion in 2011. Once trackpad gestures had become good enough, scrollbars became largely redundant, as they would be with touchscreen devices. At this point they're mostly a progress indicator.
I think the Amiga bar is my favorite.
(They're also useful to quick-jump to a specific portion of a page or to scan very quickly without swiping a million times, but those aren't as important as their progress-indicator function most of the time.)
Makes me curious, was there any historical / visual / analog precedent for the scrollbar before Xerox?
I hate the modern data-driven world. I'm convinced 99,99999% of people who use data for stuff like this don't actually understand what the data means and how large of a negative impact removing the long tail is.
Also sad that the current direction is to hide them until you mouse over.
Suppose you're working on an interface to show something that's 2D, is generally 3× as wide as the viewport and 5× as as high, and the viewport is big (a computer screen, not a smartwatch). In that case two scrollbars may be the best way to let the user navigate. The user can see at a glance what part of the thing is visible within the viewport, can move the viewport by manipulating the same thing that shows the location, and the movement has a low error rate (the effect is generally close to the user's intent).
If the typical sizes are, say, 100× as wide as the viewport, then the scrollbar doesn't work as well. If the viewport is so small that the scrollbar takes up much of the space, ditto. If the viewport is a touch screen, that changes the tradeoff compared to a draggable viewport.
Namely, it's about the question, whether the scroll thumb should be flexible in size, thus representing the size of the viewport in relation to the total dimension of the document, or not. If it is, the user can obtain information about the approximate size of the entire document nearly immediately. On the other hand, if it does not, it rather emphasizes the position of the viewport in a document and allows for more precise navigation to a certain location in the given document. Moreover, this second type of scrollbar doesn't suffer from issues with very long or very short documents. (As the second option provides a bit more usability, it was quite naturally removed in the process, we know as the history of user interfaces.)
When keyboard is not supported and I can't scroll to the bottom.
When I want to scroll to find something in a binary like fashion, scroll to the middle, decide if what I want is at upper half or bottom half, etc.
Not all people have scrollwheel to begin with
Scrollwheel is broken, as many overwrite OS behaviour, and generally slow even if you specify in settings to perform larger motion per scroll action
most scrollwheels have "notches", so if you move the wheel one "notch", its rarely the exact amount you wanted to move. the middle click is also not ideal, because it starts moving the page based on the current mouse position relative to the original position. so if you accidentally move too far away from the origin, the page shoots up or down.
with a scrollbar done right, you have fine grained, manual control of the movement of the page.