There are options at the system level, I find it great that most browsers follow them and sites cannot willy-nilly change them without my consent.
Too bad Google once again leads the way of being a prominent example of a bad idea with its custom scroll bars on many of its properties.
Then they went to Lion and ruined them: grey and almost invisible by design. Magical mystery popping into existence when you hover where it ought to be. Probably. I think this is when they inverted the magic mouse scroll behaviour to pretend like your iMac was an iPhone.
The backwards scrolling is way more obnoxious though, and I rage every time I use someone else's Mac or do a fresh install.
Most of the times I encounter backward scrolling on someone else's Mac, it's only there because they never realised Settings let you invert it to sane and useful!
People switching back and forth between Macs and iPhones or iPads initially found it very inconvenient/frustrating to have window scrolling on a touchpad and content scrolling on a touchscreen.
It was decided that switching the Mac to be consistent with iOS would cause momentary frustration for Mac users (it requires a few days of retraining to get used to) but would be less frustrating for most users than preserving two inconsistent behaviors into perpetuity.
The option to keep the Mac on window scrolling was included to mollify those few Mac users unwilling to spend a few days or weeks re-training themselves to a reversed gesture.
If you do have a problem, then you can switch it in System Preferences. Everyone wins.
These are UI/UX conventions. Everything is "pretend".
For example, users whose mental model of scrolling tracks the viewport will want to scroll up to move the content down. The viewport goes in the opposite direction of the content.
However such users don't seem to want the same for horizontal scrolling. Tracking the viewport left moves the content to the right and vice versa. But horizontal scrolling in macOS always tracks the content regardless of the setting in System Preferences > Trakcpad > Scroll direction: Natural.
The exception (turning it off for "inverted" scrolling or "viewport tracking") is only for vertical scrolling, not horizontal, which suggests the mental model can be adapted though users who prefer viewport tracking report they cannot adjust.
Of the few people I've bumped into who had it set to natural, and had for some considerable time, well even those were happy to learn it could be changed, and didn't want to go back. So there's probably something makes it feel odd, and stay feeling odd, for many. What I couldn't say, but not just restricted to those who spent time on other platforms too, like me. Of people whose machines I get to use from time to time at work, they're all set to unnatural too. We're nearly all iPhone users. So it's not just me being odd and rare edge case. :)
Personally, I don't want the same mental model between phone and desktop, as the metaphors are different. UI should look different, act different, suited to using each device. The Win 8 on, Lion on desire to make my laptop "feel" more like a mobile, continues to feel like a huge mistake.
I don't think this is correct.
The setting affects both vertical and horizontal scrolling.
That's the crux of the problem: the only time a website makes changes to the scrollbar is when the author thinks it makes sense.
I just disagree all of the time.
For every other regular site, and even most web apps, I always prefer native, for Windows.
Applications should respect the DE settings for UI. Browsers are the main culprits here, but only because CAD software isn't widely used. Oh, and there's MS Office, that will respect absolutely nothing. All of those are in the wrong. But everywhere the DE is powerless to enforce its style onto applications, so this is a much harder problem to fix;
If the page is long enough for infinite scrolling, I'm probably going to have a slightly error-prone recollection of the exact string of text I'm looking for. Taking search away from me makes this worse.
There's a bit of psychology that says when someone is experiencing a strong emotion, good or bad, they will associate it with a person nearby, whether they deserve it or not. This has applications from espionage to team building to crisis management.
One of the wrinkles of this is that if someone is already or almost experiencing a strong emotion and you add to it in any way, you've made yourself a target.
One of the things I tell mentees about code and test quality (especially the latter) is that in the grand scheme of things, nobody (read: a tiny fraction) is going to look at your code for fun. They're going to look at it because something bad happened, near it or in it.
Assume the person reading your code is already having a bad day. Don't make it worse. Especially if it ends up having nothing to do with you.
The infinite scroll bozos, at least in the scope of productivity tools, are making my not-great day worse. The ones that 'fix' this by hijacking CTRL-F and do their own half-assed implementation of search are just doubling down. If you're going to listen on CTRL-F, maybe force-update the entire list instead?
Yeah, stop messing with my scrollbar.
I understand the motivation for controlling the experience, but I really think designers are undervaluing consistency. It feels like the car I drive every day acts different on one road. Sure, there's a very tiny chance it's an improvement if a lot of time and thought has been invested, but in all likelihood it's just very jarring.
On a mac, to actually grab the scroller for scrubbing, you need to scroll a bit to make it visible and then manage to bring your cursor into a tiny area using the trackpad within a few seconds before the scroller disappears. If you miss, clicking activates window resizing.
UIs need to be functional first. Being pretty should never trump being functional.
I mean, if I write an app and hide a "dysfunctional prettiness [Y/n]" configuration somewhere in settings, is that a good thing?
I'd argue there are at least two better options that are trivial to implement, and surely more if one cares to do UX due diligence when trying some novel design.
With Mac they can generally influence the scrolling interface by making one of the best trackpads and magic mice standard, where scrolling is a critical part and not an afterthought, plus lots of visuals showing how to scroll with it.
You really don’t need to click and drag the scrollbar very often if at all. Especially for page scrolling which the article explained - it’s more important for overflowed objects, especially horizontal ones. And if you need to scroll there’s no guarantee that having 25px control design vs 50px (guessing) like windows would help, the click area tends to be a wide as the bar part not the control.
Wasn't your original complaint that someone decided what was "better"? Or are you complaining that they didn't take your choice? Point being that someone that decided otherwise thought they had a good reason for their decision, too. In this case, it could be argued that trackpads reduce the need for the scrollbars. (I have no idea what the real argument for such UI behavior is.)
In my experience, the backdrop in many of those cases is that UX changes get rolled out because people need to justify their jobs or they think X is prettier/popular. You don't hear nearly as much about people doing UX research as you do of people cranking out React things, and it would be extremely benevolent to assume developers do in fact do expensive, time consuming UX sessions w/ users.
If we talk specifically about scrollbars, maybe a good litmus test is this:
- if the default was no scrollbar whatsoever, would that be a problem for you?
- if the default was a read-only scrollbar (e.g. it merely reports whereabouts in the page you are, but does not respond to mouse events), would that be a problem for you?
If the answer to either of those is "no", you probably aren't actually using it. They could conceivably be configurations too, but why?
Consider this hypothetical parallel: why not hide the "Help" menu item in apps? Personally, I don't use it and it would clean up the UI, so it must be fine, right? Well, not necessarily. Because if you bother to do UX sessions w/ users, you may find that people looking to use that specific feature will have expectations about where it should be.
In 1990, everyone scrolled up or down by clicking little buttons at the ends (or at one end) of the scrollbar, or by dragging the scrollbar up and down. By 2019, these buttons are unnecessary and have been removed, and the main purpose of the scrollbar is to passively report the position in the page. Dragging it up and down still works, but few people bother.
Scrollbars are a tool and they should be functional: visible, properly sized and interactive. It helps if a scrollbar looks and functions the same on all our content, because it takes less mental strain to use.
It may be that you don't like scrollbars for your content. The obvious solution is to make your content fit so it does not require scrollbars. If you cannot manage that you will have to live with the fact that scrollbars are there as a functional tool and make sure it is kept functional.
In analogy: If I sell furniture you have to self assemble I can choose to design it to not require tools. If it does require tools I should make sure people can actually use those tools to assemble and not try to hide that tools should be used by pretending the thing to put nails in is not a hammer.
But honestly even then it’s not common for me to run into those. I’m a keyboard user, so the thing I get persnickety over is whether or not you got your focus order right, if you steal keyboard focus senselessly, or if you made a UI that only responds to mouse clicks.
When a user realizes that a scrollbar may be a useful feature, but it's somehow hard to obtain, it's too late to complain, and the Stockholm syndrome kicks in.
This complaint looks disingenuous to me. If you're using a trackpad, you already have scrolling built in and the scrollbar is there primarily for visual feedback.
The reason that scrollbars can now be invisible by default is exactly _because_ of the ubiquity of touchpads and mice with built-in scrolling.
For short scrolling, that's fine. For long documents, you're sitting there flailing.
It now widens when you move the cursor near it, so they have mitigated the issue.
No it isn't. It's fundamental to your preference. Your preference doesn't supersede others'. Don't use a website if you don't like it.
Are you a web dev?
I just disagree with users pushing their palate onto others. That's not how it should work.
No user of the site is forcing anything onto any other user of the site.
Perhaps we can have an HTTP header or something that says to the site, please don't mess with browser behaviour. Omit that and the site has got implicit permission.
That's like saying Crest should make orange toothpaste because you don't like the color. Don't buy their non-orange toothpaste.
It sorts of look like the Windows 10 scrollbars, but is 1/5th or one quarter the size of a regular scrollbar, and is hidden among the background of the page. Not what I prefer, and what I set up in my OS settings.
This is not your concern, you should spend more time looking at the ads. /s
You're already buying into the whole app and there's good reason to not like the design decisions they made. I also think many companies overvalue the need for it.
Photoshop for most of its history used the OS' UI paradigms. Only in the past decade or so has it adopted its own. I'm pretty sure it used the OS' scroll bars at least until CS5 around 2010.
This "very, very narrow" number of applications you are suggesting is exactly what I was talking about. Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
In all likelihood, I probably would. I chose my OS and one reason was those conventions. Especially on the web, developers seem to make very poor decisions on when to override things like scrolling. It's reasonable if, like you said, the UI is very complex and if I'm going to spend hours using it. In practice, they mess up conventions on a single scrolling page I'm spending 2 minutes on and it's usually a clue to avoid that site in the future.
> Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
That /has/ to be expected if you're stomping on the conventions. If you're changing the scrollbar, you're likely significantly changing the whole UI.
Scrolljacking and replacing the scrollbar are two very different things. And the problem is that there isn't a streamlined, consistent way to replace the scrollbar, so it's always a hacky mess.
The fact that this is also not the OS default (clicking usually _incrementally_ scrolls towards where you click, instead of jumping) is infuriating.
Why? Incremental scrolling works fine for pages and files of any length, whereas click-and-jump only works well for short pages.
Try to use click-and-jump with a long document, like a book, or a long header file. You move the mouse a few pixels, click and bam it's scrolled 3,000 lines. I'd much rather have to do an extra click when reading a short page than play silly games with the scrollbar on long documents.
At least there are some modern examples that get it right, like Firefox.
Plus, I find it pretty rare that I have a document that compresses the scroll bar that badly.
Well here's a recipe that, since the dawn of the GUI more than 30 years ago, has guaranteed the success of this endeavour: don't override anything that's provided by the platform.
It's extremely easy to do in a web page, it requires absolutely no coding whatsoever. You don't need to do anything, and the result looks exactly as each users expects on their platform. It also places no performance burden. And it's guaranteed to make everyone happy -- except for people who are already unhappy with their platform, which you can't really help anyway.
Can we please, please, PLEASE put an end to this endless, user-hostile masquerade?
> Minimize the real estate that a scrollbar can occupy. Windows scrollbars are obtrusive and very wide by default.
Wide and obtrusive? I'm not twenty anymore and my eyes definitely don't work as well as when I was twenty. I find them not wide at all, and definitely not obtrusive. So do many people my age or older.
You know what sucks? Thin, subtly-colored, automatically-hidden scrollbars that obscure how much is left from the current page, are hard to see when they do pop up, are hard to find and click (you don't know where the scrollbar is going to pop up when you move your mouse to the edge of the window). * Points finger at GTK and shudders *
> Respect changes to user preferences. If a user has selected non-default options for scrollbar behavior, respect those preferences when possible.
Why "when possible"? Why not all the time? If a user has gone through the trouble of configuring a non-default setting for the scrollbars, an UI element that's taken for granted to the extent that many computer users don't even know its name, does anyone honestly think it's a good idea to override these settings sometimes?
Why? What kind of information do you think you could present for the user, were it not for that pesky scrollbar?
To which I would add the adjectives outdated and brittle. It is possible, with care, to replicate almost any UX behaviour that is native to the browser or its underlying platform, but:
1. When the browser or platform changes, the "greenspunned" behaviour does not keep up, so you are either stuck with outdated behaviour, or you have to go back and update your web app to keep up.
2. Most of the high-fidelity implementations rely on a tottering jenga pile of hacks and workarounds that break in unpredictable ways when changes are made to the site's appearance (e.g. a rebranding exercise) or to the browser's underlying behaviour.
I've become very conservative about doing anything like this myself. I have extreme difficulty coming up with business justification for reïmplementing standard behaviour.
It is not my job to make scroll bars, buttons that depress when you mouse down, and especially, custom text input fields that—thanks to my meddling—don't support standard behaviour like native spell checking, copy and paste.
Now please excuse me, I've lined up a row of Geritol and Jack Daniel's ("Gerry & Jack's") shots, and it's time for a drink.
Yes, if you come from MacOS, the scrollbars seem obtrusive. When you come from Windows, the entire layout of Finder looks weird as hell as well. It's what people are used to.
For anyone who wants to disable scrollbar fuckery in Firefox, you can toggle these settings in about:config
Unobtrusive = beautiful, thin, glossy, glassy, & invisible but using it feels like lottery, or whackamole. You'll also need steady hands like a surgeon or a advanced robot to use cos its just too tiny for mouse, much less finger control. So, instead of drag-scroll, people end up tapping the scroll bar to jump around the page.
But that's not all. The user gets tired and taps the backspace button. Alas, instead of moving back, it goes to a different page because the all knowing designer messed with that too.
After a few confused back/forward presses, the user closes the tab or the browser, if the designer messed with the tab closing process.
But it's all right cos user engagement has improved!
Well, that (all that incredibly important) bounce rate won't go down by itself!
Thank you front-end designers for your continuing efforts to ruin everything good about the internet. No tech group has collectively produced so much garbage in the last decade!
Or you could just leave things at their defaults and stop messing with native chrome and UI elements. Now that you've styled it "unobtrusively" for Windows, that's one UI element that's completely inconsistent with the rest of the OS, and for what purpose? Does a usable user interface element actually need to be a tiny capsule because that's what Apple does?
This was your monthly "the web was a mistake, gopher should've won" propaganda message. You can now return to your 30MB React.js project.
Some devs value consistency across platforms so their app always looks and functions the same. But I personally think it’s best to default to the system’s UI. Sure I can make it look Mac-esque on desktop Firefox on Windows but I’d rather it look and function exactly like every other windowed application they use on the platform.
There’s also nothing inherent in using JS heavy frontends like React which encourages non-standard browser behaviour. You can still present complex interactive elements while keeping scrolling and other usability stuff like back buttons, copy/pasting, form input behaviour (not breaking LastPass and browser autocomplete for ex), not losing form data on submit after validation errors, etc. You have to go out of your way to explicitly modify default browser behaviour, usually via 3rd party libraries added on to these frameworks.
Personally I found it was far more common in the jQuery world, which is still rampant among those awful prebuilt themes people and companies always use for their websites.
This rather is a hack to make your job much more secure.
If your intent is to set an element to 100% viewport width with no scrollbar, that's trivially easy to do without jacking around with scrollbar styles.
Speaking of web scrollbars: One of the many reasons I hate modal dialogs ('lightboxes') on webpages is that they mess up scrolling behavior. Sometimes they accidentally close themselves if you hit the scrollbar, sometimes something else happens...
Interestingly in mobile web design, having a scrollable box inside a document doesn't really work that great (in fact I am typing this on HN on my phone and the fact that this text input is too small for my comment & scrollable makes it tricky to read and edit.) So this forces us to think about other ways to make boxes expandable. One solution I've used is showing eg. 40px of the box then a button to expand it in place in the page, where it can be browsed using the document scrolling behavior, instead of showing a 200px height box with its own scrollbar.)
I agree with what other users have said: please do not touch my scrollbars.
If modern UI designers were making a car they would replace the fuel gauge with just the light saying you need gas, the RPMs would be gone completely, and the speedometer would just say to hurry up or slow down.
That’s where the error is made. https://www.merriam-webster.com/dictionary/obtrusive lists two meanings for “obtrusive”, both with a negative connotation.
Especially given the sizes of today’s desktop monitors and their ability to use various grays and low key colors to draw items, there’s nothing “undesirably prominent” about permanently showing user controls.
In fact, there’s a case to be made to show more controls. That’s why we got tool bars, and why Microsoft turbo-charged it to the ribbon.
Say NO to sneaky scroll bars!
> Unobtrusive scrollbars: scrollbars that sit on top of the content. These don’t subtract screen real estate away from the container they belong to.
See, I would call "scrollbars covering content" to be obtrusive and "scrollbars outside of the content area" to be unobtrusive...
The main scroll bar in my browser should be completely off limits, and treated as part of the browser and not the page. Divs inside the page with their own scrollbars are another matter, but even then...
Why does horizontal space matter on desktop anyway?
All well and good for you but our author here is working with 40-50% whitespace anyway! Why the hell does he need to hide and minimize fundamental features to reclaim more fucking whitespace? Aaaaargh, designers are from a different species!
Because some people like to tile their screens into two halves.
I hate the "pop" you get when the scroll bar isn't there, and then suddenly there is enough content to scroll and the scroll bar shifts everything to the left. It's not easy to account for for a given page when that may or may not occur when say you show some new content and then suddenly things shift left.
It's a pain visually so I just force it to appear regardless.
I've had luck with:
Wide scrollbars are a blessing. Better to lose a couple pixels, a fraction of a percent of screen space, than have to constantly line up your cursor over a tiny, yet essential and frequently-used UI tool. I can't stand those dainty little ovals on Mac OS, it's like having to constantly slow down whatever I'm trying to do to thread a needle. It blows my mind that everyone is constantly trying to throw away effortlessly responsive function for such stupidly picky details of form, according to an arbitrary standard of pure aesthetics. Scrollbars should always remain visible and wide.
The "know-better" attitude of some web devs is terrible.
(I'm not actually condoning violence, just giving an example of how annoying you are for frustrating me)
I work mostly on the front end, and I recently ran into a bug where a scrollbar would alternate between these two behaviors depending on screen width, the page's CSS, and when the DOM was redrawn.
I'm generally interested in moving away from FE work, and I must admit that part of it is to increase the distance between me and scrollbars.
This seems to be moving in the opposite direction from how the platforms it runs on are evolving :/.
Not a touch device, but I couldn't find a file in Finder because it was off-window and the window had no scroll bars, implying I'm seeing everything.
(It started as a rant but I have tried to clean it up a bit.)
And yes, agree with the majority here: leave my scrollbars alone, if I want a Mac I can ask my boss to get one for me.
It was quite useful!
...so here's how we hijacked system-provided scrollbars to fit our needs.
So either this option isn't exposed to applications or browsers (including MS' own) aren't making use of it. Either way this is an issue that I'd like to see resolved.
Just stop, don't have internal or nested scrollbars at all. Having part of the page scroll independently of the rest is a usability nightmare anyway, especially when you consider how it interacts with zooming.
As someone who creates accessible sites for a living, this wouldn't fly.