Hacker News Reader

Comment by Spivak | Hacker News Reader

I mean the product manager isn’t wrong, there is no good reason we shouldn’t be able to make custom components with the behavior of “native” widgets. The fact that the dev story is “build a widget from scratch out of divs” and not “extend the fully functional component with new styling and hooks and slight behavior modifications.”

We created this problem ourselves by not having the tools to meet designer needs while doing it right. Pontificating about how they should just change their notion of right misses it completely.

View on HN

Lack of technical solutions isn't the only issue. System controls (well most of them - recent Windows and macOS seem to be regressing) have decades of refinement and battle-testing behind them and users are familiar with them. You're not replicating all of this alone regardless of how much money or years of experience you have.

Literally stepping off the shoulders of giants and wondering why you're less capable.

You and the parent are totally missing the point.

Use the system tools. But make the look of the system tools customizable.

System tool. Customizable look.

That's what should be available. But even today you can't consistently change something as simple as a scroll bar or a checkbox.

Which, even worse, are by default styled differently on different browsers.

I think the parents are _exactly_ getting the point.

Separating look&feel from functionality isn't that easy. In any kind of UX, they are bound to various degrees, depending on the use-case.

Let's take windows. The scroll bar on the start-up screens looks different to the one in explorer, looks different to the one in Chrome, which looks different to the one in IE11, which looks different to the one in IE Edge, which looks different to the one in Firefox, which looks different to the one in excel, which looks different to the one in the control panel, which looks different to the one in visual studio, which looks different to the one in Visual Studio Code.

So if they're _exactly_ getting the point, they're pretty unobservant.

There already is no consistency.

This was the entire selling point behind Windows Presentation Foundation:

https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...

Customizable look and feel means lack of consistency, and confusion as to why things look different without good reason.

This purist talk about how everyone should stick to some system standard or whatever really needs to die. It's not working. Nobody is doing it.

Everyone, literally everyone is running their own thing. Name me big company that doesn't roll their own design system.

Preaching purism really doesn't help anyone, let's just accept reality as it is, and stop chasing some utopian dreams that just won't ever materialize (and if only because it would make a lot of jobs and professions useless, overnight, and there's too much inertia for that to happen).

I’ll keep complaining about it as my parents age and struggle to use their tv apps to watch shows because every product manager needs to prove that they can reinvent the search interface.

Consistency is overrated. Context is what matters. And context often requires customized controls.

We will never live in a world where an abstract concept like a checkbox can have an 'assigned' specific visual affordance that doesn't allow for adjustments. Such thinking is stuck in the past and won't allow for new/better UI paradigms.

Consistency is a shortcut to usability; context is the long way 'round. Don't take the long way unless you're prepared to do so with care.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

My point is that by tweaking the looks of the existing thing you are breaking standards users are used to or might be causing issues you're not even aware of (bad color choices for colorblind people for example) even if the behavior/functionality of the control is unchanged.

I think this is an important concern, but not a disqualifying one. There is already a lot of variety in the space of controls, for example compare browser controls to the Office Suite to native OS, it's a big spectrum. When controls are customized correctly they become more usable within the context of the app because they are sized consistently, line up with the content grid, follow visual cues from the rest of the app, etc.

Maybe you can introduce smaller changes over a longer period of time? I dunno. Would not Windows users be stuck with that very old look if there were no changes? I mean, is this actually what you are favoring? That said, I cannot stand the trend of UI/UX on desktop being so touch-friendly, along with more padding and/or increased font sizes and less content, too.

But, once you tweak it, it is no longer the same "battle tested" thing. Even little tweaks. App developers should do themselves a favor and just stick to the standard controls that have decades, maybe centuries of tester-time working out the kinks and edge cases. A medium-size company's UX expert's "restyling tweaks" are unlikely to make the control better.

This position doesn't make sense to me. Certain customizations to the native control (which is the ask here) are already available, such as adding padding to input controls, increasing the font size, changing the width. You can even change the border color and the border radius and the background color for some controls! Some of these turn out to be necessary functional changes, and some of them -- imma say it -- are obvious and important adjustments so that your app looks consistent and everything lines up properly.

To think that there's no room for variation in the design of form controls, given the broader context of a design system for app, is just a lack of imagination. I guarantee you that the people who design the operating system form controls (which change every couple years) have all sorts of ideas, and they end putting out one possible, relatively minimal option from many good designs they considered.

Please have a look at any OOP desktop framework from like the past 3 decades. It is not a difficult concept — one is free to overload the render function, while the functionality will remain the very same, like getting focus with tab, activate to space, whatever.

It's not just appearance but also behavior. There are differences across browsers, OSes, and devices in how UI widgets work and inevitably the "custom" approach is a compromise in favor of the PM's personal workstation.

And lest it be overlooked, the appearance of those widgets themselves, is a feature. They are easily identifiable by users of that platform as being something they can interact with and expect a predictable set of outcomes.

The problem is, as always when talking about cross-platform development, is that you can have consistent widgets OR native widgets, because the native platforms have different look, feel, and interaction standards.

Would it be great if everyone on the frontend could get together and agree what the native-to-browser widgets should look like and how they might be customized? Yes. Would the three warring browser manufacturers change their platforms to make web development easier and lighter for everyone, at the cost of platform uniqueness? No.

> Would it be great if everyone on the frontend could get together and agree what the native-to-browser widgets should look like and how they might be customized? Yes.

This would not be great at all. I want widgets on web pages to look like macOS system widgets on macOS, and to look like Windows system widgets on Windows. I want designers to lose the notion that it is their system style, and respect the fact that the browser is _my_ user agent, and therefore must respect _my_ preferences.

No, it’s because it’s stupid difficult to replicate the native functionality exactly, retain accessibility traits, and if you get it perfect, then you have to deal with the fact that different browsers and devices interpret these controls totally differently.

We’re saying the same thing. The web right now today requires that you reimplement all that functionality from scratch when it should be just inheriting all the behavior from the native control in your custom thing and tweaking the styles or adding some additional functionality.

This. You should be able to subclass the DOM creation functions to specify your customized version, and have it spit out the custom tag for it.

Not a downvoter but...

> Pontificating about how they should just change their notion of right misses it completely.

The ask isn't to change their notion of right, but to understand that (yes, sadly) there is a tradeoff between "usable but ugly system components" and "pretty but janky" bespoke components, and they're making the wrong choice.

> they're making the wrong choice.

If what feels like the vast majority of them are making the same "wrong" choice, we should probably think about ways to make that choice more "right", because clearly, the current approach isn't working

This is my approach. To me the ask for custom components from designers is extremely reasonable. The fact that it’s so hard to get all the edge cases right on the web is a failing of the tooling not the ask.

At some point we have to climb out of the trenches and introspect why the most treaded path in web design is the one with the rickety bridge and spike pits when we the software engineers are the ones who lay the bricks.

It’s not a failing of the tooling. It’s a failing of designers and product to understand what a web page is and what an application is.

If youve only designed/“Ideated” for iOS or Android, you have no business designing for web. Entirely different platform with different capabilities.

Embrace reality and build simple effective products. Literally no one gives a shit about the arrows on your carousel or the border radius animation on a button. I just want to scroll and click and open new tabs.

well it's historically been because 'extend the native widget' isn't possible with css. WebComponents change that a little bit with well-scoped css, but that's still a very javascripty solution.

Of course, I’m not at all advocating that the solution is to just do it but that web really hasn’t kept up with the needs of the kinda of apps people want to build with it. It’s easy to build something that works but annoying to impossible to build something robust so we’re left with every single website being functional enough to work but broken.

I don’t think telling developers “just do it right” is a scalable solution, the platform has to make the least effort path the one that works best.

I recently came across a web site that allows one to zoom into the content (it's a mapping site). Only the designers just assumed that everyone would have either a mouse with a scroll wheel, or a touch pad. Well, I have neither. And the developers of the site suggested "oh, just install this piece of software that allows you to bind some keyboard shortcuts to simulate a scroll wheel" instead of, you know, providing two damn buttons to zoom in and out! ("But ... but ... but ... adding those two buttons would destroy the aesthetic of the site!")

Bingo

To be fair to "the system", it was developed over decades, much of it before design was even a consideration, and almost all of it from a time when modern designs would have been a pipe dream on given device resources.

Reply on news.ycombinator.com