Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
Scrollbar Blindness (svenkadak.com)
877 points by kadfak 11 months ago | hide | past | favorite | 563 comments

I loathe the fact that scrollbars are now hidden. I'm constantly looking for it to either

a) find out how big the page is b) scroll more precisely

I don't even understand why they would remove them? Who ever complained of a scroll bar?

I wonder if the designers of the systems , after becoming so bored with the status quo, begin to fetishize the sleek hidden thing that is scroll bar right now ... like when coders are writing algorithms for say, 10-15 years I bet their code gets a lot more compact and sleek looking , almost akin to tight 3 character variable leet code solutions etc.. maybe this is just the same phenomenon tearing its head in the design world , except instead of compact code blocks its compact UIs that , to a certain metric, yes , the designer has pushed further on a certain metric ex; see more of the application window cause scroll bar is hidden, but loses sight of what is lost.

> like when coders are writing algorithms for say, 10-15 years I bet their code gets a lot more compact and sleek looking , almost akin to tight 3 character variable leet code solutions

I have never seen that to be the case unless in an environment with very heavy constraints like embedded. If anything, a competent programmer 10-15 years in would skew towards more descriptive and clear variable naming as they've been burned in the past by having to maintain some of that "leet" code.

Right on. Readability is a virtue in its own right, compactness is not.

'Cute' code that leverages language features in creative and surprising ways, generally belongs on code golf competitions, not production systems. If your code is so 'clever' that only you can understand it, that means you're a bad programmer, not a good one. (That's not to say you should avoid making appropriate use of advanced language features for fear of ignorant readers, though. That's another matter.)

Ada was far ahead of the game here, explicitly prioritising readability over writeability, in its language design.

With all that said, an experienced programmer may feel less need to write comments, as their own familiarity with the problem-domain and with the language will be well developed.

> when coders are writing algorithms for say, 10-15 years I bet their code gets a lot more compact and sleek looking

If those coders are like me their code becomes more verbose, less clever, more obvious, less dependent on the quirks of the programming language I use. The reason is that it's easier for me and the other developers in the team to read and understand what it does.

On my way to here I really hated many geeky clever and brilliant pieces of code I found in projects I inherited. They made me and my customers lose days at decoding all that brilliance.

> coders are writing algorithms for say, 10-15 years I bet their code gets a lot more compact and sleek looking , almost akin to tight 3 character variable leet code solutions etc..

What are you talking about? I've been programming a long time, and clean, readable code with clear, descriptive variable names gives me a stiffy. It suggests a more meticulous mind than mine wrote it.

You know who writes the worst Gordian-knot code? Engineers from other disciplines who learned programming as a means to do other engineering calculation. Smart guys, but it's a pain keeping track of what i1, i2, i3, and i4 mean, or their 1970s FORTRAN program flow.

Actually, the worst are mathematicians. Go find some quant code.

> but loses sight of what is lost.

Literally in this case :)

Infinite scroll pages have also contributed to their demise...

Infinite scroll often make it nearly impossible to click on the site's privacy policy or terms of service in the page footer without going into dev tools. Whenever I come across that issue I wonder whether it's a feature or a bug.

Yes, they also have the problem that they (are usually implemented in such a way that they) break the back button[1] and make it so you can't easily jump to a well-defined block of the results you know you haven't seen.

I also see them frequently have a bug where they'll just keep cycling through the same first page-equivalent of results.

[1] If you click a result and then hit back, it usually just reloads the page and starts you from the beginning. I think the function of a back button changed at some point. It used to be that "back" was always instant and took you to the exact state of the page before you clicked a link. Now, there's a huge lag on all but the most minimal sites (like HN) and some reload of something gets triggered.

Not to mention the total lack of affordances for "I want to see this something from 2 years ago" in most implementations. Usually even the back end works on a "last ID" cursor system, so even savvy users can't jump back. Holding the end key for 10 minutes is not fun.

Yeah, I (perhaps because of masochism) click on links to Quora answers I see in my email digest, and it will me to the answer within an infiniscroll page. If I follow any link and click back ... the answer is gone. I have to go back to my email again and get it from there if I want to see it again.

It almost seems like, beyond a very low threshold, UX gets worse as you throw more engineers at it.

> Yeah, I (perhaps because of masochism) click on links to Quora answers I see in my email digest

Hey, it's better than clicking through the Medium digest and getting your 10th consecutive "you can use a switch statement instead of a bunch of if statements" article written by someone in week 2 of their bootcamp. :(

Update: Since I made this comment, I have gotten a "don't use if/else" article on my Medium digest... every single day.

Does this actually happen frequently?

I've tried to get to a contact link in the footer and been hindered by infinite scrolling on more than one occasion. I wouldn't say it happens a lot, but when it does it's frustrating.

I have this happened to me several times but I wouldn't say its frequent, nowadays most sites show 3-4 extra pages then show the "see more" button.

More often then I'd like–anecdotally, about once a month or so.

> I don't even understand why they would remove them? Who ever complained of a scroll bar?

IMO it's all part of this push to combine mobile and desktop UI. On mobile there is a legitimate case to be made for removing them because screen real estate is so precious. But desktop gets clobbered as an unwanted side effect.

I actually think it has more to do with the increasing size and sophistication of the touchpad in Macs. There is no need for a scroll bar when you have a touchpad you can flick (likewise for magic mice).

Yea on macOS, the scroll bar is less of a scroll bar, and more of a scroll indicator. There just isn’t any reason to click on the scroll bar if you have a trackpad.

Notably, when you connect a traditional mouse, the scroll bar automatically becomes thicker (easier to click) and always visible, as mice users do have a reason to click/drag the scroll bar. Seems like Apple had this in mind

> Yea on macOS, the scroll bar is less of a scroll bar, and more of a scroll indicator. There just isn’t any reason to click on the scroll bar if you have a trackpad.

I've seen so many web pages whose "fold line" just aligned so neatly with the end of my viewport that without the scrollbar being visible I would've just closed the page, being disappointed that it's just a meaningless hero page with no content.

Similarly, if stuff like selection boxes align just right, you simply can't see there are more options without a scrollbar. It just looks like you only have those options that are on the screen right now.

It's just plain bad UX coming from Apple.

I love pages that have CSS to make the first section precisely the size of the viewport…and then have some sort of arrow indicating that you should scroll down to see more content.

I don't know, not everybody has a macbook or a magic mouse. Plus even old, small, unprecise PC touchpads were enough to scroll a website.

To me, it looks more related to the recent fashion of "minimal" interfaces. Like material design and ultra-skinny fonts. Could also be related to the "infinite scroll" some sites have. A scroll bar doesn't make much sense for those.

Pretty much everyone on MacOS (the OS mentioned in the article) does.

But the touchpad won't help you visualize where on the page you are.

I use the larger touchpad rather than a mouse when working at my desk, and I have to say that's been a non-issue—for me anyway. A slight touch/movement on the pad and I know exactly where I am (and the device really is just great...).

That said, the issues outlined in this article are glaring, and I do notice them when I switch to PC/Linux and a mouse and back. It's definitely something easy to forget, though.

The UX is designed to make most of the obviousness fade away and make the process an extension of your natural movements. Kind of like how a good band can take cues from each other without explicitly speaking or reading off of a sheet during a performance. But that doesn't help people who aren't adept professionals, or people operating under completely different circumstances.

I've hat as programmer many times this kind of discussion, about many features. And the lesson I learned goes like this: if somebody has an issue with something, it means they have an issue with something. Telling them "I don't have the issue" does not make their issue go away. In this particular case maybe they really want to see where they are just by looking - like the commenters above just said. That's pretty natural for them, we must agree.

I'm not sure if you thought my comment was an argument or not—it wasn't.

I was adding another experience to the pile.

On a long page, it's really annoying and for some users not possible to flick scroll a long way. On desktop at least I can hit home or end. Removal of the scrollbar is arguably more user hostile on mobile than it is on desktop :/

The touchpad is related to mobile too though; trying to close the gap between computer interface and mobile touch interfaces. I don't think we'd have a touchpad if we didn't have mobile touchscreens first. And recall how Apple switched the "scroll direction" on the touchpad so you move your fingers in the same manner as you would directly on a screen to produce a given scroll direction.

Laptops had touch pads even when mobile devices had styluses.

The idea is to focus on the content and have the interface elements “fade away”. The problem is that you often need those interface elements to properly interact with the content.

They can be partially or completely re-enabled in the settings on MacOS.

Now I'm really confused, when does MacOS decide to hide scrollbars? Only when you're using a touchpad?

On auto it seems to show up as you scroll only, acting as more of a scroll indicator than an interactive element.

It depends on which pointing device you have installed.

This is the kicker, thanks. I'm using a (non-Apple) mouse and changing the settings didn't seem to have any effect.

You should still be able to make it disappear if you change it to "When scrolling".

I tried that setting before and it doesn't seem to do a thing when you have both types of devices connected.

I keep a touchpad on the left and a mouse on the right (had the extra hardware then got used to the config), plus the one on the laptop itself, and they're hidden with the "Auto" setting.


System Preferences -> General -> Show scroll bars: Always

Did that just now and Chrome is still happily hiding them...

restart Chrome

Delete Chrome, switch to Firefox.

Scroll (heh) to the very bottom of the article and it explains how.

System Prefs. > General > Show scroll bars.

> Alternatively, you can set the scrollbars to be visible at all times by setting System Preferences -> General -> Show scroll bars to Always.

Hidden scrollbars recently caused me an extra day of work. I was documenting all options in hundreds of html select boxes (dropdowns) on a legacy product being rewritten.

Many of these dropdowns were vertically scrollable, but macOS using Chrome did not display a scrollbar. I had no idea they were scrollable and missed many options in my documenta3.

I could not look at the html for it as it was minimized and not easily searchable.

Here's a tip you can try next time you have a problem like this. Maybe your task was somehow resistant to this, in which case I really do understand your pain and am not trying to paper it over, but just in case this could benefit you or folks like you:

In Chrome:

1) Right click on element you want to grab all of the contents of, and select Inspect Element. NOTE: If this element is the sort that isn't properly placed in the DOM and/or disappears when focus/mouse leaves, you can freeze the current DOM...but the right way to do that will depend on your context.

2) In Elements tab in Dev tools, the element should now be highlighted. You may need a parent or child element. But hopefully you can find it nearby and verify you have the right one with the Inspect tooling.

3) Right click on the element that has all your data in the DOM. Select Copy. Sometimes it will be enough to just Copy Element and paste it somewhere where you can start organizing the data. But for your task, it sounds like you might want to write a script for this so you can do it across multiple Elements. So, try Copy > Copy JS Path.

4) You now have access to the DOM element, even if it was created dynamically by JS and exists in the Shadow DOM. Try "paste" in the Console tab of Chrome DevTools.

5) The thing you grabbed might not be exactly the right one. Navigate down to the level you want to iterate across with the "children" attribute. Example:

    const myStuff = document
      .querySelector("#output > shadow-output")
      .shadowRoot.querySelector("div > ul > li:nth-child(2)")
6) You now have an HTMLCollection. You could be done! See if this gives you what you need:

    console.table(myStuff, ["innerHTML"])
-7) Unfortunately, HTMLCollections are only Array-like. Fortunately, it's very easy to convert.

    const stuffArr = [...myStuff]
-8) Now that you have a proper Array filled with HTML elements, you can do any kind of processing you need to grab the data you want.

    const mappedStuff = stuffArr.map(x=> { /* transform each thing */ }
Hope this helps somebody write a script to remove the tedium from a data extraction job.

> 1) Right click on element you want to grab all of the contents of, and select Inspect Element. NOTE: If this element is the sort that isn't properly placed in the DOM and/or disappears when focus/mouse leaves, you can freeze the current DOM...but the right way to do that will depend on your context.

Just to extend a touch—I use CMD+Shift+C or CTRL+Shift+C countless times in a day while debugging, or sometimes for this very reason. The shortcut is the same across browsers—at least Chrome/Edge/FF/Safari.

Instead of right clicking, it'll give you a "target" for selecting an element and highlight it before clicking.

In the console the selected element will be immediately accessible by `$0`.



> I could not look at the html for it as it was minimized and not easily searchable.

Give the Chrome dev tools a try. It "un-minifies" the html making it viewable and easily traversable.


I’ve encountered this last year when I took over a project with a dev staff solely using Chrome on macOS.

The thing was: We catered for gamers which means Chrome or Firefox on Windows was the norm. We got a lot of bug reports like “hideous scrollbars in shop item description” or “hideous scrollbars in menu” where the devs were puzzled about the bug reports.

Strongly related: viewport units (vw, vh, vmin, vmax) are fundamentally and irreconcilably broken if your document has scrollbars, because they include the size of document scrollbars, so that 100vw is equal to 100% + 17px if you have a 17px wide scrollbar there (the most likely value on Windows), so now all of a sudden you have a horizontal scrollbar too. Or your nicely calculated layout that thought that 33vw + 33vw + 33vw < 100% is now wrong and wrapping the third block on screens less than 1700px wide. There used to be a weird way of opting out of scrollbar inclusion (I think it involved `overflow: scroll` and something else on the root element, I think, but I don’t remember the exact incantation), but Firefox was the only browser that implemented it, and no one else wanted to (they said “no one wants this”—untrue, I say—“and it’s weird and inconsistent”—which was true).

We need a new set of units that excludes document scrollbars. Or a constant like env(scrollbar-width) that represents the scrollbar width so that you can subtract it yourself, which would be useful in a few other places as well (instead I’ve done the likes of `var(--scrollbar-width, 20px)` and calculate and define --scrollbar-width on the root element in JavaScript).

I dealt with this just a few days ago. A client's design was mocked in webflow and it decided to use 'static' for the header at 100vw. Which meant that on browsers that hide the scroll bar, the page jiggles left and right every time you scroll.

That was fun to fix because I had to rebuild the entire header since a ton of other webflow-generated CSS depended on that thing being static.

I need to use a MacBook as my work machine (for a little over three years now), and generally have a strong dislike of the platform. It's just similar enough to Linux to lull me into believing that I kinda know what I'm doing, but just different enough to make me feel incompetent whenever I try to actually do anything nontrivial.

    System Preferences -> General -> Show scroll bars to Always.
I stumbled across this little gem about a year ago, and has been one of the bigger quality-of-life improvements I've found on this machine.

The other being

    System Preferences -> Keyboard -> Modifier Keys
and map Caps Lock to Escape

Or Control, depending on which you're used to. Every time I try to use Windows I'm surprised that there's no easy-to-access setting for remapping Caps Lock like there is on every Linux DE and macOS.

You can really have it remapped to anything, really. Mine is remapped to F18 via hidutil to serve as a "hyper" key.

you can easily remap keys with PowerToys...


Yes! Far too many developers now only check that the page renders nicely on Chrome on their expensive macbook. While most of their users may be having a less than stellar screen and don't see the contrasts, run old hardware and a different OS+browser combo.

A couple years ago I actually had to buy a new monitor because everyone decided their login UI was ugly and needed to be ultra low contrast. I had to ctrl+a the page to find the text fields. My eyesight isn't particularly bad, just a minor astigmatism.

Same complaint with contrast aye

Yes your giga HD retina Mac displays these colours perfectly, I'm sure it looks great. On my screen however I can't read a damn thing.

Kind of an off-topic but recently I noticed capturing a gameplay video of an HDR-enabled video game with any kind of software (OBS, Twitch Studio, GeForce Experience, FRAPS, Discord) also produces terrible results. This happens even if I capture the entire monitor or just the app window. Both OpenGL and DirectX games suffer from this.

How one can tell whether what you capture/develop is what you will see without testing it on a second monitor? What is the subject I must do research on to learn more about this?

I'm not just talking about color spaces, but also how these multiple software communicate image data in a lossless way, how window modes (fullscreen, borderless, windowed) affect these flows, where HDR stands in this.

That's color management. A surprisingly fucky area from an application developer's perspective, because pretty much only DirectX 11/12 and Vulkan even have that concept -- and both DXGI and Vulkan are pretty limited [1]. Obviously, HDR and non-sRGB color spaces only work windowed in Windows, because DWM does scRGB, everywhere else your app needs to be in exclusive fullscreen. Note that Wayland on Linux doesn't support exclusive fullscreen, and since Wayland only does 8-bit sRGB, nothing on Wayland can use anything other than 8-bit sRGB. This might be fixed eventually (guess it'll take about as long as it took for GIMP).

As a general rule of thumb, if it has anything to do with colors and comes from either computer or photography people, there's a solid 99 % chance it's broken or doesn't even know what color is. If you want to know how it's done right, you gotta look at how the "moving photos" people do it.

(Note: "everything" for me means "everything that's not Apple", because I cba to care about those snowflakes)

[1] Yes, yes, OpenGL has sRGB types for framebuffers, which doesn't work on half the devices in the wild (on the other half it applies the sRGB gamma function to linear sRGB data) and isn't meaningful anyway, because we _don't_ want to use sRGB. DXGI only does Rec.709 and Rec.2020, no DCI P3, and it also treats everything that's not HDR as sRGB.

> If you want to know how it's done right, you gotta look at how the "moving photos" people do it.

So basically, all I need is a software which can do post-capture tonemapping on captured pixels before streaming the frames.

To be fair: If they would use a cheap Chromebook, then the outcome in this case wouldn’t be any different

While folks are rightfully bashing macOS’s hidden scroll bars, I would like to advertise an iOS feature that is actually pro-scroll bar. As of iOS 13, you can grab the scroll bar to scroll at hyper speed rather than repeatedly flicking the screen. Not sure if there’s a proper name for this feature but it’s explained here https://www.idownloadblog.com/2019/08/05/scroll-faster-iphon...

We used to call that "using the scroll bar".

iOS devices were not nearly performant enough to allow that until recently ;)

Not sure if you're being serious or not... I mean I thought these iPhones were faster than PCs. I've been able to scroll since I had my first 486.

I'm being serious. The first iPhones were years behind comparable desktop hardware of the time. It's only recently that iPhones have caught up and surpassed them.

> you can grab the scroll bar to scroll at hyper speed

I think it's called using a scrollbar. :) That's typically how they work.

To spare readers the content marketing piece: tap and hold to grab it.

That wasn't how they worked on nearly any modern multi-touch capacitive touchscreen device.

Android scrollbars have worked that way for quite a while iirc. Not sure about windows phone but I don't see why MS would change that behavior.

I've taken to using a fling motion on my Android devices since grabbing the position indicator in a scrollbar is comparatively inconvenient... but performance is fine.

Are you saying that you had to repeatedly flick the screen before iOS 13 ?

This "feature" has been available on every Windows, Linux and Android device I have ever used.

Increasingly many sites are opting for overlay scrollbars that are exceedingly difficult to actually use. It's almost as if they don't want you to use the scrollbar yet provide one for compliance. They are often very thin (just a few pixels) and coloured dark gray upon black background and won't expand to a bigger size until you successfully squint and hunt it down and precisely position the pointer over it.

That's because the "designers" don't give a shit about the users' actual needs. They just want the thing to be pretty. They'll also fuck with it every once in a while, making random pointless changes, just to keep the look "fresh". Way too many artistes can easily sneak onto your UX staff.

Also watch out for people from marketing and the like who put pressure on the UX people to do that sort of thing. People who don't actually know how to make anything work, and don't have to actually use it to get work done, tend to be obsessed with how it looks.

A few casual users who don't actually need to get anything done will usually support this kind of time-wasting idiocy, and the offenders will point to their feedback for validation. Unfortunately people who write reviews are often in that category, since they rarely make practical use of what they're reviewing.

...and thanks to some apps doing away with window borders completely, as well as everything becoming some drab grey colour, many times I've mistakenly clicked in and activated a different window while trying to manipulate a nearly-invisible "automatically expanding" scrollbar.

Contrast is issue I've found to be annoying, as though UI designers don't really want you to spot it easily and to show the information it conveys. On the windows side I think it's after winxp that they moved away from having color to greys, and then later to solid blocks

> If you are a front-end developer that uses macOS, I kindly ask you to dedicate a little more attention to how the websites you create behave on platforms other than your own.

I'd take that one step farther - no matter what platform you code on, test your UX on all the others.

I'm looking at you, all sites that only work on Chrome and break in subtle ways on Firefox or Safari.

The worst are sites which get broken every other year (each time they are redesigned/rewritten) whereas they provide nothing more, feature-wise, than what they provided 15 years ago. And yet it forces you to update your browser to one that provides the latest compatibility with the latest Chrome "feature".

The true spirit of Internet Explorer lives on.

> Alternatively, you can set the scrollbars to be visible at all times by setting System Preferences -> General -> Show scroll bars to Always.

One of the best things I think I've done for quality purposes is require all developers, QA team members, and project managers have scrollbars turned on at all times. It's sent the number of sites with hidden overflow in production down to near-zero for us. Someone, somewhere down the line will end up seeing that your page is 300px wider than the viewport before it hits production. And because that usually indicates other problems (often related to accessibility), it usually has a domino effect of discovering other issues that need to be fixed.

It has definitely made a marked improvement to the quality of our work, and I recommend everyone require their teams using Macs to require scrollbars be set to "Always"

If you read between the lines, you should understand that the root cause of issue is the macOS developer monoculture.

All you need is one Windows or Linux-based developer in your team to catch those kind of issues. But so many dev teams are macOS-only those days, whereas, apart from US and 2-3 other rich countries, 80%+ or even more of actual desktop users are Windows-based.

(There are many other problems with macOS monoculture, for example, the spread of ultrathin fonts that look nice and crisp on retina macbook but result in very low contrast rendering on Windows).

US-based devs: outside of your country (that is, >95% of humanity), most people do not have a Mac, an iPhone, nor use MM/DD/YYYY dates and 12-hour clock.

> outside of your country ... most people do not have a Mac,

I think you mean outside of the Bay Area. For PCs/Desktop Apple has like 12% market share in the US. 7% globally.

People in this bubble overestimate the popularity of anything Apple.

I once had a discussion with a coworker at a major company known for its app, where I was complaining about an Android bug and he genuinely asked "does anybody even use Android?" And I responded, "only the majority of users in every country around the world including the US. It's even 50/50 on our app!" Afterward, I found the internal numbers for employee use of the app was 96/4 in favor of iOS, and this included employees outside of tech and outside the US!

He, like so many others, was totally oblivious living in the Bay Area tech bubble.

Users or customers? Is it possible more revenue was coming from iOS users?

If you design your site/app in the Applethink-bubble, then maybe you're missing out on quite a lot of market share if the majority of people with devices find your Applethink site/app difficult to use.

Make stupid design choices, win less customers.

Is it a surprise that iOS users are more engaged with your product when it's tailor-made for them while Android users are getting a sub-par experience?

IOS has much higher penetration when it comes to app installs. I’ve seen this both at a fintexh/challenger bank and multiple e-commerce companies. At the e-commerce company I am currently at, 80% of our traffic is IOS. IOS users are also higher value.

iOS has the majority market share in the US (~60% nationwide).

You’re completely right that this doesn’t hold true for other countries, and that ignoring Android is not the play, though.

This seems to be getting downvotes, so here’s my source: https://gs.statcounter.com/vendor-market-share/mobile/united...

This is a single aspect of something i call the bay-area-bubble.

other aspects include to assume everyone have free wifi everywhere or unlimited latest-G data on their phone, last model Macs and phones, disposable income for 57 $9.99 monthly subscriptions, and live on food delivery.

Soon to include: everyone have a room fully set up for VR, with the latest headset du jour.

Developers, not general computer market share.

I think the macOS monoculture is going to go away in the next few years because on one side macOS is becoming more and more developer hostile with each release and on the other side WSL (and WSL2) is improving the Windows developer experience a lot.

I use Windows as my daily driver OS now for both native/web/mobile/devops work and I expect to see more and more developers making that same switch in the coming years.

For folks considering the switch, I highly recommend considering linux as well. I've used both macOS and ubuntu as a development environment, and bug wise they are on par, but linux really excels at having a true "native" development environment. Docker without a weird VM, true bash, etc.

Just a minor nitpick, macOS has true bash. It just doesn't have the GNU coreutils, instead it uses the BSD-based equivalents.

And yeah, they suck a lot[1], but there's a way to fix if you use Homebrew: https://stackoverflow.com/a/57973942/8280773

[1] Performance-wise and also when you take into account that most shell scripts/tutorials on the internet are written with a GNU userland in mind.

As I remember it, this is the whole reason OS X became the de facto standard for developers in the first place, consumer-grade windowing and device drivers coupled with a familiar development environment.

zsh has replaced bash as the default shell, btw.

macOS has a 12+ year old bash. Also, even with Homebrew patching up Apple's neglect, coreutils behaves differently under a Darwin kernel than Linux. A repeat source of aggravation for myself is the behavior of 'ps'.

that's not due to the kernel, that's because it's bsd ps instead of gnu ps. sed is the one that gives me the most irritation, there's basically no way to write useful cross-OS sed scripts.

To suggest that “bug wise“ it is the same between Mac and Linux is a bit of a stretch. I work in a team where the developers are mostly split between Mac and Ubuntu. Guess which ones often have problems joining zoom meetings or attaching their machines to a projector for a presentation? There are a lot of things that you generally don’t have to worry about much if you’re using a Mac. I’m not gonna say that one of these is better than the other, but to suggest they have equivalency wrt common scenarios is a bit strange.

Also, Mac is a certified UNIX environment, it is native.

I think the corollary is "consider Ubuntu, but still don't skimp on hardware". Buy a proper laptop that ships with Ubuntu, buy a proper connector cable if you need one, etc.

I don't think paying more for hardware significantly changes the problem that was brought up.

I think what he is saying is, don't buy a cheap-ass Dell that runs Windows 10S, then expect to be development powerhouse where all the hardware works properly. He is suggesting buying a developer-oriented laptop that is designed and supported to be running Linux. You'll have less weird hardware quirks that way.

You can buy a $1000 laptop and still run into issues where your computer won't connect to a projector or a major application refuses to support your platform.

Yep, that's exactly what I meant - and peripherals too. I'm sure a big reason Apple products don't have problems video calling or connecting to projectors is high-end hardware, and I don't think the difference between MacOS and Ubuntu on comparable hardware is anywhere near as striking as their reputations would have you believe.

I really, highly doubt that. Autodetecting and using proper settings for a newly-discovered display device (projector) is fundamentally a software consideration, not hardware: the hardware into which you connect the display is capable of talking to it (maybe not at ideal resolution depending on specs, but whatever), but the OS needs to discover, detect, and configure the new connection properly.

The same is true for Zoom: things like accelerated video streaming are universally supported on laptop GPUs, but software support is spotty for some apps/OSes. Things like screen sharing are 100% software-side.

While I'd love to use a Linux workstation (and often do), it's simply not there yet in those areas. That has nothing to do with "high-end hardware" and everything to do with less robust software support than many alternatives--including MacOS.

I guess you could make the case that because MacOS has to support fewer kinds of hardware, they can spend more time on making software support robust, but I'm neither convinced of that argument nor convinced that's what you meant by your post.

You'd think that, but once I replaced my €5 AliExpress connector cable by a proper one, suddenly I haven't had any issues with projectors any more.

Likewise, if you use an underpowered laptop, or one for which Ubuntu doesn't have proper drivers, you're going to have a hard time using Zoom.

I'm not saying that you'll never have issues (which I'm sure holds for MacOS as well), or even that you might not have slightly more issues than on MacOS (see your last paragraph), but things are definitely not as bad as comments online would have you believe, because many of those can be ascribed to issues like I mentioned above.

> Guess which ones often have problems joining zoom meetings

As a linux user, I'd like to say that I've seen that happen just as often with OSX users on my team. I think that's just Zoom's shitty app. But I do agree about peripheral hardware issues plaguing Linux. Bluetooth headphones are still such a hassle on Ubuntu 20.04.

I think it's crazy to seriously consider using an OS where something as basic as Bluetooth is a hassle.

Bluetooth has never not been a hassle in my experience - and that goes for Android, Windows, Linux, OS X, iOS. There’s always something with the device or driver.

This goes especially for audio.

I’m going to guess that Apple peripherals + Apple OS on Apple hardware is actually hassle-free but then what’s the point of a standard.

Bluetooth in general isn't a hassle. Bluetooth audio is a little bit of a hassle in the sense that there's a workaround that you have to do.

This is definitely the largest drawback of Linux in general - support for peripherals and common communication/presentation software is really lacking. If I had a dollar for every time I had to muck around to get my headphones to work on Ubuntu, I wouldn't be posting here.

> support for peripherals and common communication/presentation software is really lacking

Well if peripherals vendor and "common communication/presentation software" didn't test on Linux, whose drawback is it now? That being said, I have used the following without any trouble on Linux: Slack, Discord, Teamviewer, Zoom, BBB and BlueJeans. Vendors don't put enough investment into testing for Linux due to comparatively low usage numbers - but that doesn't mean that it is a "drawback" of the OS.

As for hardware, as Vinnl explains above the way to go is buy certified hardware. Ubuntu and Red Hat folks certify a bunch of Dell and Lenovo laptops to work with Linux. I use Ubuntu on a Dell XPS 13 and I don't need to do ANY extra setup. Things just work (TM) - including my Sennheiser and Jabra headphones.

Seems like a trade-off based on my experiences. On Macs you'll get a less bugs in proprietary, user-oriented apps (like Zoom). On Linux you'll get a less bugs on free software apps, developer tooling and server side apps. Though I think it mostly comes down to where you spend most of your time and what you are working on.

To equate lack of peripheral support to "bugs" is hilarious.

I feel like GIMP and Inkscape have finally caught up to the Adobe offerings. It was my reason for not switching for so long. But over the past year I did and I just-- wow. GIMP in particular is just really good now.

I think WSL2 is wonderful, I use it on my primary development machine. Docker doesn't have as many pain points as it used to, and I generally find that I can get around the OS without too much issue, and the new Windows Terminal App helps a ton (its no iTerm2, but its better than anything else I can find)

I still miss macOS, so much, because

- Mac Software I was accustomed to using (and it was lot) is no longer available to me (don't discount this problem when suggesting switching)

- I had to customize Windows 10 a lot, (many hours of work) to emulate native features of macOS I personally can't live without (including remapping keys, which turns out not to be trivial on Windows)

- I miss the general UI polish of macOS. Windows is...ugly in a lot of places.

- I miss Finder, and I've tried so many file explorer alternatives and nothing comes close

- Windows 10 can't seem to ever remember my screen layout for my applications. I had to resort to an application to do this for me. Drives me nuts

- macOS has way better HiDPI support (I have 3 4K monitors)

It ain't trivial, is what I'm saying.

Don't get me started on Linux, I loved Pop OS conceptually, but the support for basic things, like natural scrolling, was completely lacking, and I had to resort to all kinds of hacks to get a desktop semi functional. Not to mention, a lot of Linux 'add on' packages are abandonware and would break constantly when updating to new versions, and for basic things, like dealing with scroll direction, I had to edit files in a terminal, which I just found annoying. It just wasn't a polished out of the box experience. Don't get me started with it not recognizing adapters properly and issues with GPUs. macOS is alot of things, but they take 'just works' more seriously than any other operating system I've ever used.

Honestly, I find it incredibly odd that companies that have more manpower than Apple (you'd be shocked how little manpower they devote to some things) can't manage to pull off the polish of macOS UI

WSL2 has no built-in background services. That's a huge issue for me. And I don't have 100% confidence in it. It has many little bugs on each builds.

Why do you miss Finder? Search feature? Preview.app? Opposite to you, I never like it.

If you didn't buy into Finder and other built-in apps on macOS, it can be easier to see less value, that is true, but effectually I feel like that dismisses perfectly reasonable expectations a macOS user has about using a platform. Frankly, Apple hasn't given as much love to macOS over the last 5-6 years in particular as they do their other platforms (in some ways, justifiable, otherwise, its frustrating) however, even with their basically trickle of updates to the desktop platform in that time, no other desktop platform could even match them on baseline functionality and user experience. Even though I'm certain Microsoft has more people working on Windows 10 than Apple has working on macOS. Even Ubuntu with its open source contributors likely dwarfs Apple's resources on this, yet nobody comes close to matching the user experience to me.

As for software, I miss Finder because I felt the interface was intuitive and I really liked the features Finder like tags, smart folders, and the way you could custom it with extensions and settings. I like the built in software, like Preview in particular.

I have yet to have anyone show me an OS that comes close to matching macOS out of the box. Even conceding customizations, they're just so lacking in comparison, to someone who 'clicked' with macOS.

Granted, not everyone likes macOS, and thats fine, but to come at it from a place that its so easy to migrate to another platform, ignores so many things about macOS that make it great to a macOS user.

My job requires Windows 10, thats how I ended up on the platform. I learned to get around and replicate as much of the features as I could, but so many are just fundamentally missing and even if I wanted to pay for the functionality (and for so much of it I would), the software doesn't even exist.

As always, it's all about the tooling. For better or worse, more is moving to web/electron, but for teams using Sketch, good luck trying to open Sketch file on Windows.

After getting a Windows gaming PC, I've been spending more and more of my time, developing and otherwise, on PC. I prefer it because it's where I have my large (low DPI :( ) monitor, but Windows is still full of so many papercuts in general usage (I miss being able to drag a file into a Open File dialog so much) that I still greatly prefer using macOS.

Windows has some niceties to try and make the transition better - The Windows Terminal app is pheonomial, and Powershell tries to map rm to whatever the Powershell command is - rm -rf doesnt work as expected though. I honestly don't find myself using WSL all that much - I only use it when I can't figure out how to make ping go forever in Powershell.

Didn't Microsoft make an effort to bring Linux into Windows a few years back? Is that no longer a thing?

That's WSL. It's still there, and it's super easy to use (new Terminal tab > Ubuntu), but I just find I don't have much of a need for it. I do web development with Node, which runs fine under windows. https://imgur.com/a/n19qb8M

Linux on laptops is getting much better too. Is a great alternative now for developers.

So long as you don't need HiDPI, multi-gpu or good touch-pad support.

High density hasn't been an issue for me lately on Ubuntu, I rarely use a touchpad, so I can't comment on that. GPU support is absolutely garbage on Mac OS in comparison, both from a compatability and performance perspective.

For you, but it's an issue.

Anyone who has used any Linux knows HiDPI or mixed DPI monitors are a massive issue on Linux. Even when you get your xrandr configured perfectly fine, disconnecting is a hassle. And that's completely ignoring apps, QT, GTK, etc all handle DPI differently. So you need a different config with DPI setting on each.

One of the best I've used is PopOS with the HiDPI daemon enabled. But even that has issues.

Even Windows can't deal properly with having a 4k laptop screen and a 2k monitor attached. Have to deal with weird text scaling issues and other weird scaling issues.

But MacOS can and does it beautifully.

My new Lenovo laptop touchpad works perfectly well (much better than my old XPS13). Running Pop_OS 20.04.

HiDPI is pretty good on a KDE desktop nowadays

Or good battery life

Especially now that hardware makers are making developer edition devices with Linux-supported hardware (and Ubuntu/RHEL pre-installed)

Agreed. I grew up in the 90s using Windows. Bought my first MBP in 2009 and within a few years was using Macs almost entirely. Started using a Windows machine as my primary earlier this year for a new job and now I rarely touch my MBP. Took a little time to get used to Windows again, but I'm quite content. Windows 10 is excellent, and so is the ThinkPad T480s I'm using.

Nah, Windows is still Windows, no matter how much Linux they try to bolt on. Let me know when they've got proxy icons.

The most obnoxious I've seen of US-centrism shining through is a registration page - forgot where - where you could select country (optional) and US state (required, no "none")

It could just be the market they were interested in.

All you need is a round of testing for cross-browser compatibility. It's a pretty much solved problem by now, doesn't take that much time and can be automated. There is nothing stopping every developer from doing it - besides the usual pressure to deliver features in place of proper engineering.

> All you need is a round of testing for cross-browser compatibility. It's a pretty much solved problem by now, doesn't take that much time and can be automated.

Please show me a solved automated test for the issue in the post.

There are several online cross-platform browser testing services. You don't even need a non-mac yourself. If the company is large enough to alwayus test locally, most modern testers will use VMs or some sort of containerization for repeatable determinism. This is absolutely a solved problem.

Online isn't real-life. You can test in a VM, but it will never be the same as testing on actual hardware.

Even my craptastic company gives me a bunch of devices to test on. And I very deliberately specify very low-end versions of the machines so that I can test against worst-case-scenarios. It's a bonus that sub-optimal hardware is cheap as chips.

My favorite testing device is a $20 burner phone I picked up in the supermarket checkout aisle. If the web site works on that piece of poo, it'll work on anything.

Right now I'm waiting for UPS to deliver an old iPad from Alaska that the IT department bought for me off of fleaBay, just so that I can test on sub-optimal actual hardware.

> Online isn't real-life. You can test in a VM, but it will never be the same as testing on actual hardware.

Testing platforms like SauceLabs, Browserstack etc run on real hardware, even for mobile.

Testing with your own devices is of course better, but a lot more work. Which one you choose doesn't really matter, the point is just that you don't _need_ to have all those resources to do basic compatibility testing, so no excuses.

> Online isn't real-life. You can test in a VM, but it will never be the same as testing on actual hardware.

Ths context is that testing is a solved problem. You are taking specific factual examples I wrote and attempting to debunk them with a general statement that is in agreement with what I wrote. Testing scrollbards can absolutely be tested inside a VM. Pretending that native hardware is needed to cover 99% of the use-cases for scrollbars is kind of silly.

> Even my craptastic company gives me a bunch of devices to test on. And I very deliberately specify very low-end versions of the machines so that I can test against worst-case-scenarios. It's a bonus that sub-optimal hardware is cheap as chips.

You've made my point. This is a solved problem.

> Ths context is that testing is a solved problem.

The only problem that is solved is running multiple browsers in VMs in a cloud. Everything else is anyone's guess.

To come up with an automated test for the problem in the OP you have to be a) aware of the problem and b) have a way to test that scrollbars do/don't appear. Good luck with that.

> The only problem that is solved is running multiple browsers in VMs in a cloud. Everything else is anyone's guess.

That false hyperbole. Just because you do not know something, that doesn't mean that nobody else does.

> To come up with an automated test for the problem in the OP you have to be a) aware of the problem and b) have a way to test that scrollbars do/don't appear. Good luck with that.

No luck is needed, just tests. You may not realize, but test frameworks already exist for testing the screen for the presence of UI elements. That is how dialog boxes are clicked in tests. This is literally solved.

> Just because you do not know something, that doesn't mean that nobody else does.

For the third time you've failed to show how to test for the problem described in OP. It tells me that you don't know

> test frameworks already exist for testing the screen for the presence of UI elements

Which ones test for the presence/absence of scrollbars?

Honestly, it seems like you are playing a game. Did you perform a search of tools that can test ui? There are lots of them. I find it hard to believe that you think there aren't any. That's like saying that compilers don't compile C code anymore, because you only compile C++.

I see our testers doing this all the time - but I don't know what libraries they use. I know the testers at our shop do it with an house built framework as well as with commercial ones. On our company's security team, various people have scripted UI exploits using selenium or appium. I just asked one of the people familiar with those two tools I mentioned, and she said it would take her a few minutes.

These are commodity tools. There is nothing special with any of them.

> Honestly, it seems like you are playing a game. Did you perform a search of tools that can test ui? There are lots of them.

It would'be been so easy to just answer the question I asked. Instead, it's now a thread of non-answers and thinly veiled ad-hominem attacks.

The rest of your long answer is once again working hard on avoiding the answer.

> I find it hard to believe that you think there aren't any.

I didn't say there weren't any. I asked, "which ones let you test the problem in OP".

> I see our testers doing this all the time - but I don't know what libraries they use

Ah, my assumption that you don't know what you're talking about is proven correct.

> On our company's security team, various people have scripted UI exploits using selenium or appium

Question: scrollbars.

"Answers": tools click on buttons, scripting security exploits, I don't know what libraries testers are using.

Ignorance is bliss, isn't it?

> and she said it would take her a few minutes.

Given your answers in this thread, I seriously doubt your ability to ask a proper question to "the people familiar with the tools". Especially given the fact that you don't know what libraries testers use and that you, apparently, don't do any testing yourself.

See, frontend testing is very far from being "a solved problem". Especially for quirks as described in OP. But you wouldn't know because you, well, don't know.

> These are commodity tools. There is nothing special with any of them.

Indeed they are. Indeed there is nothing special. And this still doesn't answer the question.

Except that I did answer as to specific toolkits - with two answers for two separate kits.

You used a lot of words to make it seem otherwise. As you yourself wrote, "Ignorance is bliss, isn't it?"

> Except that I did answer as to specific toolkits - with two answers for two separate kits

You din't, really. On the third attempt you said "I see our testers doing this all the time - but I don't know what libraries they use" and "various people have scripted UI exploits using selenium or appium. I just asked one of the people familiar with those two tools"

This shows that you started this entire argument with very bad faith. You berated me for not knowing something while you yourself:

- don't do frontend testing using frontend testing tools

- you don't know what tools your testers use

- you assume some capability of some tools only because "you talked to people familiar with them" which further shows that you yourself are not familiar with them.

On the other hand, unlike you, I know what I'm talking about. Granted, I haven't used these tools extensively, but I did use them, and I'm well aware of their limitations.

All you have is, well, empty words.

You're still at it???

> You din't, really. On the third attempt you said "I see our testers doing this all the time - but I don't know what libraries they use" and "various people have scripted UI exploits using selenium or appium. I just asked one of the people familiar with those two tools"

Because I see this sort of test being done almost daily... I work in security and not specifically in testing. I mentioned what frameworks are used in a security context. You are beating a dead horse, focusing on what doesn't matter. I suggest you get off hacker news, go educate yourself, and stop pontificating.

When I said that I "just asked" I meant that I just now asked, not that just asking was all I have ever done. You're being foolish, projecting in every comment that you know more than everyone else.

PS. Please quote properly. I wrote that the security team uses selenium and appium not whatever it is that you are pretending I wrote.

A person who doesn't do testing himself, doesn't know which libraries testers use, and has to ask other people how to solve the problem in OP (because he himself doesn't know) is telling me to stop pontificating and go educate myself.

Good luck with your holier than though attitude, and god help your security.

Yikes, you guys. Please don't do flamewars on HN and especially not tit-for-tat spats like this one.


What is wrong with you? I never said any of that. You keep cherry picking half-statements and then taking them out of context.

I did not need to ask other people how to solve a problem. That is a silly interpretation of what I wrote. You are willfully pretending ignorance of how to read and have a conversation.

Pontificate: "express one's opinions in a way considered annoyingly pompous and dogmatic." Yes, you really do need to stop pontificating.

I hope you find happiness.

Yikes, you guys. Please don't do flamewars on HN and especially not tit-for-tat spats like this one.


Gotcha! Thanks.

This is a non-answer to my question.

No. It was an answer. The correct answer is that there are many ways to test for this. Just look for one.

If you knew the answer, you would've already answered this. Instead, you keep giving non-answers until you admit that you don't test yourself, and that other people use some libraries, you don't know which.

I did - with two specific answers. Then I went and asked a security tester and told you the results of that question.

You can keep using all the words and comments that you want, but the simple truth is that this is a solved problem, I gave you two solutions, and yet you keep using ad hominem attacks.

As you yourself wrote, "Ignorance is bliss". Those are your words, not mine.

Another thing I keep bumping into is designers assuming a nice 16:10 display, and wondering why when the final product is opened up on a 1366x768 shitbox barely any actual content is visible.

… designers assuming they have my whole screen.

It goes beyond that - it affects every part of life, it's why enforcing diversity in your team is a bonus

A good set of examples is here


I wouldn't be surprised if 80% of US desktops were Windows. Their users are probably also less tech literate than the Mac users.

Funny. I wonder when this (perception?) shift occurred. 15 years ago, it was distinctly the perception that Mac users were the tech-illiterate ones. Have all the tech-illiterate users abandoned Apple, or have they just been drowned out by the bay area macOS dev culture?

In my experience in a graphics lab, the perception was that Macs (thought they often wrote that in all caps) “couldn’t do anything.” Specifically, having a one button mouse made them unusable. I never had trouble being productive and greatly enjoyed the old Macs, but I think it was just a different way of looking at computers.

Now that macOS is every bit as complicated as windows, it’s often Microsoft’s OS that can’t do something. WSL helps some of that, but there are usability shortcuts that Windows doesn’t have. Windows is also insultingly condescending with its verbiage (“Getting Windows Ready” or “Working on Updates”). Maybe aiming low in their explanations is their one-button-mouse moment.

I don’t think the users were ever all tech-illiterate on either platform. Only perceptions have changed.

More like 95%

Macs are 12% of new sales, but tend to have a longer lifespan than average, so 85% seems reasonable, but 95% does not.

Scroll bars have always been a compromise. Today, I have a 4K monitor connected to a 2K laptop with a USB-C port for yet another big monitor or more. I can span a window across 3 big monitors, and still the horizontal scroll bar appears because of the platform agnostic attitude of "good enough."

Up until Android and iOS mostly phones and tablets, we had a monoculture Intel and Windows. Windows is still almost 90% of actual laptop/desktop users. [1]

I am an ex-Mac developer. I do not have a modern Mac, I do not have an iPhone, and I set the date/time format to pretty much whatever I want on Linux, Windows, and 15 year old Mac OS X. And, I just have to deal with broken date/time interfaces on the web. For far too long, I would go along with the Intel / Windows developer monoculture of "good enough" software, and comments like Mac? Linux? What's that?

[1] https://www.netmarketshare.com/operating-system-market-share...

Our company offered me a choice between a Mac and a PC, but also said that the former is heavily recommended so I picked that option. I didn't want to be the guy who constantly cries for help because stuff is just not designed and never tested on windows.

Don't forget the constant peer pressure and lame jokes from your coworkers! Oh and if you're a Mac newbie, be prepared to figure it out for yourself. Not that people are unhelpful but that they genuinely don't know any other workflows beyond their cloistered little OS with a barely-usable kernel.

It's hard enough already to not get ridiculed for using JS on the backend from the Java devs :)

Took me a week or so to get used to Mac. I can't care less about what OS I'm using, they all excel and suck in different ways.

Perhaps they aren't particularly font of you calling their OS unusable.

See also resent thread about Zappo where there was lots of talk about customer service. I think a solution would be that designers and engineers should have as part of their job to sit in customer service to support their products. Preferably for weeks on end to learn from their customers. Otherwise they will continue to produce bad solutions.


> US-based devs: outside of your country (that is, >95% of humanity), most people do not have a Mac, an iPhone, nor use MM/DD/YYYY dates and 12-hour clock.

This is an unsubstantiated claim, why bring up and bundle the entire United States to support your claim? I was with you until this.

It should be trivial for you to confirm that Apple is not selling enough iPhones and Macs to any more than a small portion of smartphones and desktop computers. Are you claiming that this is impossible to know?

In my current company, my manager, when I complained that my remote PC machine was a bit buggy with Docker, ordered me top-of-the-line MacBook, delivered in 2 hours.

I don't even live in US. But this culture certainly exists here too.

the date format and the 12 hour clock drives me nuts

Lots of countries use a 12 hour clock, that’s a strange claim to make.

Judging from this [1], even more countries don't use it.

[1] https://travel.stackexchange.com/questions/34950/which-large...

This source is not very trustworthy. No one usually uses 24-hour format in a few places not noted here, such as Holland, a decent-sized European country that many people have heard of. But they are not shaded in this chart. So I wonder how many others are also not shaded.

In many European countries, the 12-hour format is used in speech, but not in writing. You'd say "Let's meet at seven", but you'd write "Let's meet at 19:00". The context being software, I'd say it's a pretty solid claim to say most countries use a 24-hour clock.

From a UX standpoint there's a big advantage to monoculture: the user learns a thing once and applies the idiom everywhere. For most users, diversity of options means having to learn every option. They'd rather have one good thing -- or even one good-enough thing.

The world does have a variety of options, so users need to live with the fact that they're going to have to discover things, and designers are going to have to live with the hassle of designing for users with a variety of experiences. That makes the best possible UX worse than it would otherwise be. It's a necessary evil, but it's not surprising that a lot of developers try to wish it away, especially when they can get away with that, at least initially.

The problem is that the UI testing monoculture is on Safari. Safari has 20% market share according to StatCounter (9% desktop market share).

Most users use Chrome on desktop and mobile.

My understanding is that the monoculture being discussed is macOS rather than Safari. I would be surprised if most developers tested UI primarily on Safari considering, like you said, most people are Chrome users.

Anecdotally, most engineers I know use Chrome on a MacBook. The only people I know who use Safari are my parents.

That monoculture means you can't change anything because it breaks the learned idioms. And there is no best possible UX. UX is mostly subjective measured.

Being incompetent and not knowing how overflow in CSS works is definetly something anyone should be able to change.

I've been guilty of this. Normally I like to blame CSS for all of my personal failures, but I think the definition of "overflow" is intuitive enough. I was hesitant to turn on visible scrollbars system-wide because I thought it might be ugly. I did and it's not, so I second the author's suggestion to do that.

I think part of the problem is that this "feature" masks the need to properly understand scroll behavior (at least if you only use platforms that auto-hide scrollbars).

Recently, we were doing a bug safari for a new product feature that was about to launch. I noticed that an element had a scrollbar when it shouldn't, and filed a bug. One of the developers picked it up, and first said "not a bug. I don't see it on my computer." I showed him the bug on my machine, and he looked at it for a few minutes before saying "I don't know how to fix it." I pointed out that the overflow-x was set to "scroll" in the CSS for that component, and he could just set it to "auto" to fix the behavior (since the scrollbar should never show up in normal usage of that feature). It turns out that he didn't even know "auto" existed.

Hidden features extends to many things.

On NTFS you can hide an arbitrarily large file in the "Alternate datastream" of any file. Explorer doesn't show you alternate datastreams and certainly doesn't show you they are possible.

You can use VLC to play a bluray from what appears to be a 1kb text file in Explorer.

If you have that on a USB stick, the properties of the USB stick will reflect the capacity loss of the bluray image. But Explorer won't show you why or which file has it...


Hidden scrollbars are just terrible UX all round for so many reasons:

- Discoverability: You don't even know if a container is scrollable at all until you try.

- Orientation: You don't know where you are in a document until you scroll to make the bar appear, and then you have to notice it before it disappears

- Usability: It's much harder to target the scroll thumb to drag it. To find it you need to again scroll first, then notice it, then target it with the mouse, all under time pressure before it disappears.

If you're on MacOS, do yourself (and your users) a favor and set them to always show.

"introduced an enhanced scrollbar behavior that made scrollbars hidden by default"

That's not enhanced at all, it's horrible, and scrollbars should be more contrastful and bigger again

But that’s silly when the preferred method of scrolling is a mouse wheel or a swipe nether actually require the scollbar as a touch/click target.

The actual useful UI left is “does this thing scroll”, “where on the page am I”, and “the grab and flick” gesture on touch to scroll faster.

In hindsight I think the mistake was having scrollbars be part of the document flow instead of hovering invisibly over the content until they’re needed.

The scrollbar does still provide valuable context over what scrolls, how big the scroll area is and how far you have scrolled. The second two you can solve by just scrolling a little to see the popup scroll indicator but discoverability is huge and I often am confused by this when I am using macOS.

scrollbar gives visual information and allows me to scroll to whereever I want at the speed I want, scrollwheel only goes at fixed speed

I'm talking about desktop computers here by the way, althrough grabbing a scrollbar and going to wherever I want at any speed would be awesome on a phone too.

I mean such programs as Konsole, Firefox, and others, in Linux desktop. Scrollbars got thinner and with super low contrast there too

I use an old IBM laptop with only a pointing stick (the red nipple in the middle of the keyboard).

I don't mind having to move my mouse to the scrollbar and drag it to scroll documents or webpages (when I can't use the keyboard for that already).

This was fine until a few years ago when scrollbars starting to hide or become super thin. I should not have to concentrate to be able to target scrollbars with my cursor.

If you're working on UX/UI design, please remember that not everyone has or uses a scrollwheel on their mice.

While on the subject of people creating user-hostile experiences, try disabling "Allow pages to choose their own fonts, instead of your selections above" in Firefox. Now instead of a different set of fonts for every single website because of some misguided form-over-content design wankery I can read things with one less distraction.

I actually tried that, and it has its own downsides. Sometimes pages get icons by drawing from characters in higher codepoints, and so the icons will get randomly replaced with Greek letters and random symbols.

Hiding scrollbars is one of the worse ux antipatterns.. it makes it difficult to see IF there is more content and which part can be scrolled (if any)

A lot of developers I worked with only using their MacBook & iPhone to do tests. Many sites do not fully responsive also. For example, the github.com only support 1280px width and above. Below that, padding & buttons rendered incorrectly.

And I think this is a trend in the open-source that developers reject Windows patches, or never really try to fix the bugs.

Now a lot of tools are only designed for MacOS first. Linux is extra because it's easy to migrate. For example, Facebook Watchman. It's about 5 years but still unstable for Windows I think.

And many web tools, even Android development, I found it's no errors in MacOS but have to fix the config or do extra yourself to get it to work properly.

> In 2011, Apple released Mac OS X Lion which introduced an enhanced scrollbar behavior that made scrollbars hidden by default.

I don't think hiding scrollbars can really be termed an enhancement; 'mistake' at best or 'user-hostile behavior' at worst seem more appropriate.

The original Macintosh GUI succeeded so well because it made it so easy to see what was possible. It laid an awful lot of stuff out right there on the screen in front of the user, and what was hidden was easy to get at. They spent a ton of time testing an improving usability. Modern macOS, OTOH, just doesn't feel right anymore; I suspect it is designed to look good, not to be usable.

I like how this page also has four levels of scrollbars, and the title has two. It's an interesting sort of border effect.

I noticed this a few years ago on a project I was working on, and ever since I've always enabled scroll bars on my work laptops.

More recently, a few weeks ago we had a bug in our app that was caused by an India time zone. Our company is fully U.S.-based so nobody noticed. Since then I've kept my computer in the India time zone so that time zone issues are readily apparent. I've already caught another one since then.

There's a more general principle here of "user empathy": configuring your environment so that you're in the same boat as your users.

I have noticed this too. This page itself immediately distressed me with its deliberate overdone use of `overflow: scroll`, so much so that I honestly almost left it without reading, which seems a little weird when I reflect on it, but… ugh, multiple useless scrollbars. I think this must be what people mean when they describe something “triggering” them.

I think there are two parts to the problem: ① a popular developer platform using overlay scrollbars; and ② the fact that `overflow: scroll` sounds like what people want, when it’s actually not (as you say, they wanted `overflow: auto`). If I could rewrite the history of just this one property, I’d rename `scroll` to `always-show-scrollbar` or `show-scrollbar-even-if-insufficient-content-to-scroll` or similar. Or maybe split `overflow` in two and use `scrollbar-show: always;`.

Hmm. I wonder if we could convince browser makers to kill off `overflow: scroll`, making it equivalent to `overflow: auto` due to rampant abuse (there’s precedent for this sort of thing), and replace it with a new, more clearly-named property `scrollbar-show: always`. (And `scrollbar-{x,y,inline,block}-show` to go with it.) Maybe `always` wouldn’t be quite the right keyword, given that it wouldn’t be affecting the behaviour of platforms with overlay scrollbars. But this actually sounds both reasonable and feasible to me, given that `overflow: scroll` is subject to rampant abuse due to misunderstanding and was basically only a tiny quality of life thing for certain corner cases in layouts anyway.

Wow, that's pretty bad. I'm guessing the front end developers of those sites just do everything on a Mac and never check how the site looks on Windows or Linux.

Even worse, they tend just do it just on Mac and only in Chrome.

The reason `overflow: scroll` is a better default is the need to account for every screen size or possible dynamic content. If overflow is set to `hidden` or worse `visible` your UI is going to break on some screen sizes. So basically you need to decide if you want extra scroll bars for some screens, or broken UI when a user shrinks the browser. It's very time consuming to get everything right on every screen size on every browser on every OS.

`overflow: scroll` shows the scrollbars always, and should just about never be used. >99.99% of the time, you want `overflow: auto` instead, which only shows scrollbars if they will do anything.

Designers don’t get it. What do they teach in design schools these days? Genuine question. I hope stuff like this is brought up? How do you even become a UI designer?

I took a "designing the user experience" class in as part of my computer science curriculum (not in the design or art school).

It was much more rigorous than other design content I watch (e.g. skillshare, youtube), which are usually based on how something looks (emotion) and not the actual efficiency or usefulness of the design.

In the industry we really should distinguish between UI Architects and Aesthetic Designers.

On many Mobile Apps I also found that the scroll bar is just a small dot and it only appears when I do scroll a bit, so it's very difficult to see how much is left to read. This is particularly annoying because I have to scroll down to estimate how much is left and then scroll up back to where I was.

I have on idea what school of thought has brought forth the no-UI UI but I absolutely think they are idiots.

I like how the title of the article has a hidden scroll bar (reading on iPhone).

the whole page too; it starts with:

  <body style="overflow: scroll;">
    <div style="overflow: scroll;">
      <div style="overflow: scroll;">
        <div style="overflow: scroll;">

Indeed. I just set scrollbars to always show on my Macbook per the author's suggestion and there are 4 scrollbars on their page!

Makes me wonder if I'm missing the point of the fairly simple post?

That's clearly intentional to make the point. Made me appreciate the article more.

Ah! It's only on that post, not the rest of the site. Clever.

Ooo those hidden/slim scrollbars are annoying. It's as bad as an auto-hiding taskbar.

When I first saw it the first thing I did was to find a way to get rid of it. In Windows it's: Settings > Ease of Access > "Automatically hide scroll bars in Windows" > Off

Great read, and nice examples to show how important the issue is (at least, relative to web design).

This just reminds me of how lovely it would be to have complete interoperability between every browser, every OS, mobile or desktop... And how unlikely it is to happen in the near future.

I'm on MacOS and have `Show school bars: Always` set, but I still wish the scroll bars were slightly wider.

They're undoing much of what Ive did to MacOS, it's time to include making scroll bars as big and useful as they used to be!

Great article! Short read and proves his point excellently by calling out big sites that are making the mistake he points out. The Snapchat example is the best, looks terrible on my Windows machine on Firefox.

Help Scout have this discoverability problem with dropdown menus - there's no scroll bar when the content overflows, so I had no idea there were more options until a colleague pointed it out.

I felt absolutely ridiculous and ashamed after that. So, I make a point of designing all my software with visible scroll bars and other visible features that a user could reasonably expect to find without having to hunt or guess.

Sure, it doesn't look as "pretty" but it's so much more useable.

Whenever I looked for website templates to purchase, I always hated those that had a jQuery library to "restore" the scrollbar.

I misunderstood the intent and I thought that they were just replacing the scrollbar to style it, which as a side effect broke the behavior with a mouse in Windows/Linux, but it took me long to understand that it was because Mac OS removed them by default and it was not just designers being obsessed about styling the scrollbars...

I recall a point by Jobs et al. wherein the original case for GUI drop-down menus was motivated by a clear desire for discoverability, versus the arcane keyboard shortcuts of the IBM applications of the time.

That stuck with me for a long time, and I remembered it when MacOS and iOS first began departing from that philosophy with their modern looks. I would say Jony Ive contributed a lot to this transition from user-friendliness to design-led, form-over-function.

I would very much want a way to toggle scroll bars on and of within the browser, eg a Toolbar button that I can add through an extension.

The fact that I can only toggle it at an OS level is pretty bad. I love the invisible scroll bars and I would prefer to have them in all apps I use myself, but I do respect the platforms and users who have visible ones, but I shouldn’t have to choose between my own user experience and testing for their user experience

This trend is sickening. Windows 10 has a nearly 1 second delay when mousing over the Start Menu scroll bar. Why wouldn't I want a scroll bar there? It is the primary thing I seek when I click Start.

In the Gmail Admin interface for users, the scrollbar vanishes unless I have my browser nearly maximized. Do the designers live in a world where their browser is always nearly full screen?

You'd think huge companies would notice and care about these things.

On smaller screens I’m kinda ok with scroll bars appearing only when scrolled, but what’s with no scroll bars at all on some websites? That irks me like nothing else. I can’t even figure out how long the page is and whether I can finish reading it quickly or need to save it for a later time. What do the designers gain from such user hostile designs? And how are people paying for such designs without any oversight or reviews?!

I also have this issue with the disappearing window borders.

I remember on IRIX they were so bold, a real tool to be used. Same on Windows up to and including Windows 7. Now it's like you have a 2 pixel wide invisible border, hard to click, which may be the shadow of the window, or at the edge in the window; it's hard, specially when working over VNC. Nothing is gained by freeing up those 10 horizontal and vertical pixels.

> If you are a front-end developer that uses macOS, I kindly ask you to dedicate a little more attention to how the websites you create behave on platforms other than your own.

I think this is a lost cause. A lot of macOS people are "zealots" and they feel that anyone who uses anything else is simply "wrong." I've long dealt with designers like this and realized I can't win.

Even Google has this problem[0].

[0]: https://i.imgur.com/kusIhDh.png

And discoverability is the no 1 problem of the command line interface, that's why a lot of people don't like the command line so much.

It would be a lot nicer if, while typing a command, a list of options came up, along with a short explanation and example, and by clicking the option the full documentation for it would come up.

But that cannot happpen, console apps have no connection to a UI.

What is the reason for this developer monoculture?

This is only a problem for the web because web developers are using broken OSX to develop.

The amount of hidden-ness/clevery fuckery in OSX is maddening. I would implore every one to complain to Apple to fix their broken OS.

The web is fine, the garbage developers are putting out is because of the broken dumpster fire of OSX.

All valid criticisms. The hidden scroll bar is also really hard to use. It removes the ability to jump to a position by clicking. It's hard to see sometimes too.

You'll notice that Apple loves to champion usability (HIG etc) ... except when it flies in the face of their minimalist aesthetic.

this is my most hated Apple "UI modernization." Its not just a problem with website, apps, even Apple apps don't deal with it well. I always turn on scroll bars all the time (I do a lot of work with very long documents or files, and just scrolling with the scroll wheels doesn't cut it for these), and every time I do a VNC connection using the built in screen sharing app, the scroll bars are placed in the remote screen area, rather than outside it. So every time I connect to a remote screen, the first thing I have to do is enlarge the window so I can see everything.

Oy. Not fun to see Render on the list. We just fixed the horizontal scrollbar!

Note that in some instances `scroll` instead of `auto` is warranted. When a scrollbar is placed because of `auto`, its contents are laid out differently than `scroll`, and might cut out some content.

I fell victim to this while implementing my personal website. An easy fix to be sure, and one that I think is worth it for the hidden scroll bars (which I prefer), but kind of annoying.

This problem is so endemic for so many years now, I wonder why the browser devtools have options to turn off caching but not option to turn on the scroll bar during dev mode.

I really like the dichotomy presented in the argument that I should change my settings so scrollbars are always visible because they're ugly and not needed.

As someone who has scroll bars always turned on, I actually added a step in our CI that forbids `overflow: scroll`. auto is fine, scroll is never OK.

Woah, Thanks for bringing it up. These are the things that remind web developers to test the cross-browser compatibility, chrome is not the universe.

The microsecond of time which is the quantum between seeing the scroll element, moving focus and it going away again before you can grab it ....

Another example missing from the list: twitter.com. The navigation (when logged in) has an unnecessary vertical scrollbar.

and then there is the new firefox for android which decided to just remove the scroll bar entirely in its new tab list. so if you have lets say the now usual amount of open tabs, you don't have any idea where or how far along in the list you are. i wonder what the reasoning behind that was?

Let's not forget horizontal scrollbars that cover the last line of a code you want to copy....

It was a happy day when I discovered you could disable auto hiding of scrollbars in OSX.

I like to hide my scrollbars by putting it into another div with an overflow hidden

I dont like the very thin scroll bar in JetBrain IDEs.

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact