Not shown here, the Open Look scrollbars, defined in the 1980s, had the arrow buttons attached to the position indicator. It was probably best that died, but it was distinctive.
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:
Seriously, this. We upgraded my nearly 93 year old Grandma to Windows 11 from Windows 10 and this was the most disruptive change for her. At least she quickly learned how to use a scroll wheel.
If there is a screen to the right you cant even push the pointer against the edge of the screen. I imagine at least some people must be using the scroll wheel to scroll 1000 pages down. Spending quality time with the interface.
Removing a useless UI element is a positive regardless of real estate constraints (and I wish it didn't flash over mouse scroll either as it usually does)
Though all of that should be properly configurable (which it isn't) so that other users liking other styles don't suffer
No, something doesn't need to be good to be useful or popular or persist, that presupposes a degree of pervasive thoughtfulness and rationality that simply do not exist in reality.
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
No linux scrollbars, no mobile scrollbars, no interesting application specific scrollbars? There are a lot Kore interesting designs for scrollbars out there, there are like 3 main layouts in this presentation wity what amount to fashionable skins of their time.
I like how the Mac OS X Lion scrollbar removes most of the functionality, and had me wondering for a second "how do I use this?"
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
The website incorrectly represents it. Since Lion, how the macOS scrollbar/position looks depends on your input device.
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.
Windows 95 scrollbar looks the best of all of them IMO. it looks like it was professionally designed, compared with Windows 10 scrollbar, which looks like it was designed by an 8th grader.
Yeah, 95 looks really good. So does OS 8. Can’t believe how pixelated OS X looks in retrospect. That didn’t age super well, but it looked pretty at the time.
Windows 10 has at least two styles. One where the arrow is a triangle and the other it's a chevron (as in the example). System 8 (and Next) were odd in the up and down arrows were on top of each other. That works for the initial scroll or if there is only one scroll movement, if there are more than one in a given direction, it becomes annoying (if you're using a mouse on the arrows to move the bar).
Like everything else, it should be configurable. SublimeText provides a version that shows a minified view of the document I have open. That's incredibly useful. If you don't need/want that, you can change it to a standard scrollbar. I'm not sure why or when we collectively decided the best solution for everybody is some mediocre middleground that can't be adjusted to your needs.
> when we decided decades of widely ccepted and intuitive access to those same functions is a "mediocre middle ground".
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.
> 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.
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.
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.
This doesn't correctly simulate how mouse clicks affect Mac scroll bars. Clicking in the track outside the elevator box should move a page at a time. Maybe it's not intended to accurately simulate interaction, only appearance.
This is very interesting when you consider the device timelines.
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.
Even before trackpads were good enough, scroll wheels were a thing (and I still prefer them). Your dismissive "mostly a progress indicator" is burying the lede: yes, I've seen scrollbars as primarily progress indicators for more than a decade now, and I'm still irritated when they're not there!
(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.)
> Between 1981 and 1982, the Xerox Star moved the scrollbar to the right to get it out of the way and reduce visual clutter. Scroll arrows pointed inwards in the direction the content would move based on user studies, and + and – buttons allowed for scrolling by pages. The thumb was a fixed size diamond, independent of how much of document is visible. Clicking in the thumb elevator region would jump to that part of document.[7]
That's interesting. Maybe just a product of what I expect from the UIs nowadays, but the arrows seem very counter-intuitive, and the + and - buttons lead me to believe it is going to zoom in and out from the document, not scroll by pages.
This doesn't accurately reflect how some of these scrollbars work. The Amiga and Windows 3.x ones, for example, should scroll a full page page up and down when you click above or below the scrollbar. It doesn't jump to 10% when you click 10% from the top.
On most of my devices, there is no scrollbar, or it's not visible until I actually scroll... and it's fine. So it's not so much evolution of the scrollbar than disappearance of the scrollbar.
When did Apple introduce overlay scrollbars on Mac? Does anyone know? I ask because it seems that Windows and Linux are moving in that direction as well.
IIRC (tho I could be making this up), scrollbars became overlay because most mice have a scroll wheel and most trackpads have gesture scrolling support. These are faster than a scroll bar, because you don't need to move your mouse to the side of the screen to use them.
I also infrequently need to jump to certain parts of a page compared to how often I use mouse scrolling or other options. But when I do want to jump to certain parts of a page, I want that scrollbar. Just because "the data" shows it's clicked infrequently doesn't mean it's not important.
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.
I worked with this a while ago. It's a navigation/organisation tool for GUIs. GUIs have many such tools, and each of them is unnecessary in the sense that you can use others. But each of them is also better than the others in some cases.
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.
There's also a notable ideological split, a schism, in this amazing instrument combining both the aspects of a positional indicator and a navigational device in a single widget that we call a scrollbar.
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.)
FWIW, I've seen issues with that type too. Specifically, I once watched a user trying to scroll across a very large model. When the scrollbar moved by just one pixel, the model moved by more than half a screenful. It was painful.
a scrollbar when done right is the most natural form of moving down a page.
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.
I'm not sure why you'd call it the most ‘natural’ form. Scroll bars don't appear in nature. Of all the ways to scroll content, direct manipulation (dragging your finger directly on the document on the screen) is most like the way we move real things around in nature.
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.