Hacker News new | past | comments | ask | show | jobs | submit login

The core problem, as I see it, is of someone else deciding that "unobtrusive" scrollbars are better.

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.




On a Mac, this is configurable. The article talks about this, and about respecting user configuration when possible.


> configurable

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.


Are you sure it’s dysfunctional?

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.


I'd argue there are at least two better options...

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.)


I'm talking in generalities. The status quo used to be "scrollbars are visible things". If you're going to change the status quo, it behooves avoiding a dark pattern (like e.g. privacy settings turned off by default). The two better options for UX changes (generally) are to leave it alone, or to create a configuration that defaults to the old way of doing things. You probably heard again and again of some random company doing some major redesign with good intentions and ending up pissing off users.

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.


People changed their interaction after mice and trackpads started to universally include a built-in scroll wheel / scroll gesture.

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.


I did not know this, but I am apparently one of those few people who use a scrollbar to point to a location where I need to be. Either in source code, manuals, even on some vendors web pages I know the tech specs and the link to the datasheet is 2/3 of the page so I drag or click the scrollbar. In documents, or on webpage I have a mental image of where the scrollbar was when I read it, like page numbers in a book and I use it a lot. And no this is not substituted by scrolling with a mouse wheel or heaven forbid a track-pad. If I know I need to find something at 'M' I do not want to go through all the stacks starting at 'A'. Just saying we have been organizing content for a lot longer than the UX people telling us what we do not need.

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.


I have almost forgotten that it’s even an option to click and drag! On my trackpad I use two-finger scroll, and my scroll-shell mouse can handle horizontal scroll just fine.

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.


It's configurable operating-system wide, and the system default is to hide the scrollbar, which is terrible.


Being pretty helps the first impression in an Apple store, and for first few days.

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.


> 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

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.


Scrolling yes, but not scrubbing. The latter is a feature that people use for navigating very large pages (e.g. I may remember the rough location of some section of some programming language spec that I'm looking to consult, but the spec is 500 pages long)


> 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.

For short scrolling, that's fine. For long documents, you're sitting there flailing.


You can say it's disingenuous, but I used to hit that issue fairly regularly. I've seen that complaint more than once, so I assume a large subset of users did as well. Habits built over years won't vanish just because you add a track pad.

It now widens when you move the cursor near it, so they have mitigated the issue.


[flagged]


The opposite is true as well - it's the web developers website. If you don't like how they style the scrollbars...don't use it.


Sure, it's the dev's website. But the browser is my user agent, not your developer agent. It is fundamental to the purpose of a web browser that it should prioritize the wishes of the end user over those of the server.


> It is fundamental to the purpose of a web browser that it should prioritize the wishes of the end user over those of the server.

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.


This is exactly what's going to happen. If the site's owner for some reason looked for my business — well, the developer's priorities were different, tough luck!


Interesting point (upvoted too).

Are you a web dev?


No, and I generally agree with the sentiment that poor UX is bad for the user.

I just disagree with users pushing their palate onto others. That's not how it should work.


Ooh, that's a bit much. The website dev is pushing their side.

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.


The website dev is generally the one paying for and providing the website... Why is it you expect the provider to bend to the whims of the user? The user doesn't need to use the website.

That's like saying Crest should make orange toothpaste because you don't like the color. Don't buy their non-orange toothpaste.




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

Search: