Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

First of all, the OS does not style widgets, the browser does. And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. So either you create versions of your app which match each browser individually, or you re-style the scrollbars to look the same as the rest of the app.

Thirdly, there is an obvious counter to your arguments that shows that one-size-fits-all design is not actually what users always want: games. You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.

And we can extend this observation further out: if your app is self-contained enough, and you have a distinctive enough style that your users like, then you should re-style everything away from the OS style to your specific unique look.

Should every app do this? Absolutely not. But is there no case outside gaming where an app should? Of course not.



> And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels.

Yes, and? No matter what it is, it's what the users of said platform are used to. Is there really a benefit to forcing users to re-learn such a critical component?

> You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.

1. Not everything is a game.

2. Depending on the game, system look&feel can be perfectly fine: SimCity 2000, Aurora, the Rule the Waves series, and probably loads of other simulation games all use it, because their art style doesn't require to re-invent the wheel poorly.

3. Games whose art style do need custom look&feel will most likely be using a fullscreen canvas/WebG(L|PU) widget anyway and will be able to use it regardless of CSS support of the feature.


My point was that a general "no app shall customize scrollbar look and feel" is wrong, as there are certain kinds of apps that do benefit from custom look and feel. Sure, not all games, but also games are not so entirely different from other kinds of apps.

Also, I thought the specific points about CSS and how to achieve custom styling if desired are irrelevant. The arguments I was replying to were about UX, not about details of how that is implemented.


> My point was that a general "no app shall customize scrollbar look and feel" is wrong, as there are certain kinds of apps that do benefit from custom look and feel. Sure, not all games, but also games are not so entirely different from other kinds of apps.

But the point is, that your website is not an app. At most it is a web app, and therefore governed by the browser and the user's preferences and choices for the browser.

A website (or website that is a "web app") should fundamentally be a different degree of commitment than installing an application into the user's system. There is a reason for browser sandboxes and for the browser to have its configuration. The browser itself is the actual app and the user should be in control of that, to govern a at least partially unified UX throughout the websites the user visits.


I don't see why there should be any distinction between apps and web apps in terms of UX constraints, and I don't think one has ever existed even since the invention of the Web. After all, Flash is older than JS and much of what people loved on the earlier Web was in fact made with Flash. Similarly, many famous Geocities sites were heavily customized to illustrate their creators' preference.

The web is much more than productivity focused software, and limiting it to some specific notion of dull uniformity in the names of consistency is honestly sad.

If I want to create a site to represent a detailed exploration and appreciation of the Voynich manuscript, why should I not try to style similarly to the original manuscript? Why should utility trump aesthetics for nay document on the web?


The real problem, in my opinion, is that too many websites do this sort of thing. Is there a place for it? Sure. But it should be something that is rarely done.

But I'm only talking about websites, not web apps. I don't use web apps, so have no opinion on them.


A website should fundamentally be a different degree of commitment than installing an application into the user's system

I agree with that, but this is opinion and not fact. There's a lot of money invested in blurring/obviating this distinction, exactly because installing a real app has more hurdles (both for the developer and for the user).


It's very hard to actually write good UX from scratch, particularly stuff like scrollbars that require all sorts of relative resizing, drag listeners, velocity methods, second and tertiary controls (keyboards, drag-selection of text) and often need to handle those things after a variety of user interactions without redrawing their content or slowing anything down by constantly remeasuring the rest of the UI.

Because it's difficult, it's often done poorly, which leads to people thinking it should never be done at all.

To your point about games, I find most custom-written scrollboxes in games to be pretty terrible, but we all kind of appreciate them just for their uniqueness, because as UX items they're generally not something you interact with that much. (Unless you're playing Crusader Kings, in which case ... )

I remember being disgusted and offended by Apple's app developer rules two decades ago, which included dictates such as never implementing your own UX elements like scrollbars. We're still debating whether they were wrong. As long as there are bad ways to build UX elements, some people will do them, and this will serve as proof for a few big companies that it should never be done.


You don't have to write good UX from scratch to get non-OS scrollbars, there are CSS rules that let you style scrollbars while keeping most system scrollbar features and accessibility.

No comment on whether or not that's a good idea, though.


I think in games reimplementing controls is done because of game engines having their own gaming-specific widgets or parts, which are not using the system's widgets themselves. Game creators will make use of the things available in the game engines.


Well like e.g. when I had to write UI elements into first iterations of Star Citizen, those were all in a 2D vector/sprite layer over the 3D world that had to be completely custom coded. Even the shape of the UI was pretty much completely open to interpretation. I have mad respect for people who write their own UI elements and "widgets" into games, given the restrictions that are often involved. Some do it better than others, but therein lies the art of observing and stealing from the best.


> First of all, the OS does not style widgets, the browser does.

This goes beyond scrollbars. There are hundreds (thousands?) of libraries or entire frameworks to build consistent dropdowns. Even more to create date-pickers and to replace alert dialogs, add modals, and whatnot.

This shows that the browsers don't do a good job offering nice and neat UX on them. Same for scrollbars. Browsers offer native dropdowns (that more-or-less match your OS - depending on browser and OS), datepickers (that at least match your locale) and even native alert dialogs. And many are ugly as hell, have a terrible UX or integrate very poorly. IMO fair points. And often even reasons to replace the native widgets with tons of JS, CSS and dom manipulation. Edit: though I don't think this is the case for scrollbars, I think browsers do a good enough job there.

The one reason that I very much disagree with, it cross-browser or cross-platform consistency. No-one cares that widgets on your website or -app are the same on chrome/windows, icebeaver/weirdlinux and safari/OSX. Because no-one other than the webdeveloper and -designer will ever use them on all those platforms and expect everything to look the same on all these platforms.


> And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. So either you create versions of your app which match each browser individually, or you re-style the scrollbars to look the same as the rest of the app.

Find me a user that sez "This experience sucks...that's the native scrollbar" and I'll give you $100. If you give me $1 for every user who is fine with the native experience they are most comfortable with. If you give me $1000 for every time a custom scrollbar isn't accessible.

Fwiw, I've never visited a site with a custom scrollbar that didn't have other UI / UX issues. The fancy scrollbar didn't makeup for those.

p.s. Gaming is a different aesthetic, a different audience, etc. It's not what should be the user-centric internet.


> p.s. Gaming is a different aesthetic, a different audience, etc. It's not what should be the user-centric internet.

I don't think that games are an entirely different world from web apps. There is some amount of gradation between pure document-like pages at one extreme and games at the other, and a whole spectrum in between (say, an app like Google Earth probably doesn't need regular scroll bars to implement most of its scrolling behavior, while not being a game).

Also, I think users are quite observant of color clashes, and will notice if you have system-styled scroll bars in the middle of a web page that is styled in a specific way. I don't even understand how this is a controversial opinion - especially when we have things like dark mode that was available in numerous apps long before any OS or browser supported it natively - thus requiring the app to re-style all controls.


The technology is not the audience / culture.


The difference is that games are a deliberate exercise in non-productivity. You are generally not trying to 'get something done' in a game except what the game itself is asking you to do.

When using a webpage, you generally are trying to 'get something done'.

Besides, games implementing their own widgets can be terrible for accessibility.


The majority of game menus are there to help you get something done. With some exceptions, games are not played inside their menus, and have the same kinds of UX concerns as any regular app.

The main difference between games and many other apps is that games are trying to sell you a fantasy, and look and feel are much more important to keeping you in the right mindset than in some other apps. But there are other apps and even web pages with similar goals which don't quite qualify as games.


>You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.

Oh yes I do.

https://store.steampowered.com/app/2008100


MacOS and iOS scrollbars are the same in every app and browser. They are styled by the OS, even in iOS games.


Perhaps, but MacOS and iOS are not the only OSs out there. Also, full screen iOS games have full control of the screen and I/O, and can choose to draw anything they want and implement any interaction they want, they don't have to rely on the system to draw widgets for them.


The "But games don't standardize the UI" is actually a worse argument than it appears on the surface. Since every game is re-inventing the wheel, they're all making inferior wheels. UX/accessibility is so far behind OS/web in full screen games that I'm impressed that disabled people can even play most games at all. It's not uncommon to boot up a brand new game in 2023 that has the menu design and UX consideration of a late 90s website.


I don't think most games would become compatible with a screen reader if their inventory system had a better scroll bar. You are right that game UIs tend to be well behind some common OS elements in terms of accessibility, and even low hanging fruit are sometimes missing, but it is also the case that many (most?) games are fundamentally incompatible with many disabilities and as such improvements in certain specific UX areas are low value. Doesn't excuse the fact that they should do better where it's possible, though.


I believe the point is that if you're unhappy with the default scrollbar, you should get rid of it altogether rather than torture it into doing something it's not meant to do.

Having done e.g. an endless scroll application, the scrollbar was unfit for our use, no matter what we did. The right solution was to remove scrollbar and implement our own scrolling mechanism.


Which is straight up what jmbwell was complaining about, as it breaks their workflow such as tapping on the top to scroll to the beginning and everything else they mentioned.


There is no beginning in the thing I was talking about. Which is why removing the scrollbar and breaking people's expectations in a way they can see/understand was better than trying to repurpose the scrollbar.


I appreciate this is off topic and not a solution but on iOS you can tap the hole on top of your screen to scroll to the top on any application.


Yes, that's one of the features that break with endless scroll bars, which was what this whole discussion was about.


It works for every single app that has endless scroll bars on my entire history of using iOS. Try it on Reddit for example.


It breaks more often than it doesn’t. Yes, the page “scrolls”, but it scrolls only a few pixels, while the internal “custom” scrolling implementation doesn’t respond to the event and does not scroll to top, resulting in a terrible UX.


When you scroll on reddit, there is a beginning and no end.

Some applications have neither a beginning nor an end, so scrolling to the beginning makes no sense. At best, you could make "scroll to the beginning" get back to the start of your navigation, but then your scrollbar wouldn't let you go further.

(also if you have both horizontal and vertical scrolling, you're still left with no horizontal options)


The GP was specifically complaining about apps not respecting their scrollbar choices. They said that apps should defer all scrolling UX to the OS, as that is what the user chose.


You're right, I misread that. Thanks.




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

Search: