Hacker News Reader

> The color picker is neat, but extremely nonstandard

When I press the button on my iPhone it brings up the actual system native color picker. It’s the same control that appears in dozens of apps because it’s provided by the OS.

I much prefer that over some bespoke thing.

You do, but companies don't. A major advantage of a browser app over a native app is having one system that behaves relatively consistently across all platforms. This isn't just cosmetic: providing customer support for a web app that has exactly one expected set of behaviors is far easier than asking your support agents to keep track of the constellation of different features users might have access to depending on their platform.

The color picker control is the antithesis of this consistency: not only does it look different across platforms (making it harder for CS to walk customers through something over the phone), it provides different features depending on the platform. Some users will be able to pick an arbitrary hex code, some will be able to pick colors off the page, and still others will be given a tiny set of fixed choices.

HN's audience might prefer that because they know the platforms they use extremely well, but the average caller to a customer support desk doesn't know their own device that well. If we instead write a bespoke control, you (being technical) will be able to figure it out, and the people who call in to customer support for help will all be seeing essentially the same thing.

EDIT: And note that when I say "companies don't", I'm not even just talking about the SaaS vendor. Oftentimes the customer is also a business that has an internal support desk that prefers consistency.

And that is why I hate web apps. What even is the point of various OSes offering different UX to choose from if the apps completely disregard it and offer their own thing that is 1) different from what the OS does and, 2) usually worse.

Yeah. People will hate me for using it as an example, but there is such a huge difference between native apps and the gunk we’re fed now. I can vividly remember the first time I used a Mac-assed app on a Mac, and it was remarkable. Like, it felt good. But now those are going the way of the dinosaur. (Yes, I know, Apple is to blame for that in part by their iOS-ification of the Mac. That’s not what my comment is about.)

Really? I am trying to put my customer/mum hat on and but is this really true. How many OS would you need to really support? 4 or 5? On top of that docs/knowledge would be more standardised. Google/peers/family would help people more.

> Google/peers/family would help people more.

Tell me you've never worked in tech support without telling me you've never worked in tech support.

My experience in a tech support center for a software company is that, for the kind of person who calls in to customer support, them having made a Google search first is not something that should ever be assumed. And usually whole offices were chronic customer support users or none of them were—peer support, when present, is already sufficient, and in the offices where everyone is clueless having a system-native color picker isn't going to fix it.

> On top of that docs/knowledge would be more standardised.

If everyone started using the native widgets at once, then maybe external docs would be more helpful, but until that happens your software-specific documentation becomes much harder.

How do you take screenshots of the color picking flow for your documentation? If you just pick a browser to screenshot then you will get calls from people using a different browser who are confused that it looks different for them. If you screenshot every supported browser then your documentation becomes much more expensive to create and maintain.

I hear the know it all customer is the worst.

I once had a problem with my laptop, which was a problem with the drive. I pulled it out and duplicated the problem on a different laptop, so I needed to get a replacement. I kept mum and went through all the steps I was instructed to (reboot with this or that key held down, etc) until finally support said “well sorry, we’ll have send you a box for you to send back the laptop”. It would have been useless and annoying to the person on the other end of the phone to dry to skip all that. Like doctors, they must deal with a lot of people who studied at the university of Google and think they know it all.

I have a few times sent in bug reports on software I had previously worked on myself. Again, just file it like any other bug. Usually the bug just gets fixed (or not) but I did once get mail from a former colleague who said he was assigned my bug and how the hell was I? Sadly he also told me, “we aren’t going to fix it.” :-/

Of course most of the time I don't know any more than the next schlub. Otherwise I wouldn't have called.

I'm at a point where I just treat the front-line CS person like a fellow engineer and tell them exactly what's wrong, and why I know that.

I've actually had pretty good success with this strategy, though it really depends on the company. Framework laptops and system76 for example were both phenomenal with this approach. The first reply I got from them was either an engineer or someone who talked to one, or someone very experienced in CS who would be a good candidate for engineering.

Worst case if the CS person has no idea what I'm talking about, then we start from scratch but at least they know I'm not a dumbass they can BS :-)

Most of them have to walk through a decision tree in response to their computer and don’t know about the domain anyway, so I don’t want to waste their time.

In my experience this is, unfortunately, true. I see it from both sides and would prefer the native implementations myself, but I've never worked with a customer who agrees.

I start by saying, your customer who uses an iPhone is never going to use an Android, and vice versa, so there is no need to keep them consistent and identical looks and design wise. You should use the native items as much as possible because a random user is more likely to understand the common system version than they will understand your bespoke version. Use the native share icon, don't use the iOS share icon on Android, etc.

Also iOS tends to be way more consistent than android, windows, etc, so there could be a case for iOS native and 'company consistent' for everything else, especially if you're in the USA. iOS people pay more and it could be worth it to have two branches for customer support if it leads to total better conversions and thus more profits. Your business's core competency is not making UI toolkits, it's selling whatever your making. Leverage the literal billions of dollars apple and google invest into the core UX toolkits.

What could possibly go wrong with a standard color picker though? Show some grid, spectrum and sliders, remember the last 10 choices, return a hex code back. Done.

This is something humanity can solve once and for all then be done with it.

Implementing your own will have bugs and generate a lot more support. The dialog I get on my iPhone is magnitudes better than any other home baked pickers I’ve seen.

Date pickers on the other hand I agree are more complicated to standardize, due to frequent need of overlaying extra data, like price, together with the dates.

> that prefers consistency

So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved.

Because as a customer there’s nothing that makes me happier than when I contact customer service and they say “our website is made for Windows so you’ll need to use the exact same OS as us”

That part of the parent comment was about corporate setting.

> Oftentimes the customer is also a business that has an internal support desk

Maybe I misunderstood something, but if it's a business with internal support desk, surely if they want consistency they want it everywhere, including the work machines (BYOD aside) they provision?

I know at least my company, employees who aren't devs or designers get a Windows laptop, unless they're considered a frequent traveler (i.e. sales role) in which case they get a MacBook Air. Designers get a MBP. Developers can choose between Linux and Mac, or Windows if you can justify it (we have some hardware engineers who actually need certain Windows-only software). We also have some new acquisition every few months and those companies get to keep their previous computers for a couple years before they have to get on the company approved device list.

> So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved.

How would that work if the app had to work on both desktop and mobile?

And, how easy would it be to make sure all users were using the same model and make of mobile device?

The picker that opens in Firefox on Android is quite terrible, fwiw. Chrome on android has a good one.

Compatability is only better if you make the assumption that all your users need to be using javascript. I much prefer using the web without javascript, it impacts my laptops battery life by hours. Some sites, are not compatible with this and render a blank page or complain to me that they require javascript to render some text in windows. Meanwhile Amazon has a javascript free clone of their ecommerce site, showing that such herculean feats are possible without reaching for javascript.

I think that is a pretty good assumption to make. The vast majority of websites are being made for the average person to use, and the average person is using one of the big browsers with more or less standard settings.

You could write a website that doesn’t use JavaScript, is meant to be accessed primarily through curl, etc but if it’s a business project then you’re going to end up with a product that your users (average people) will view as more janky than otherwise, and you’ll spend more time and money on it too, for the benefit of 0.01% of the population who would be slightly inconvenienced if you didn’t.

> you’ll spend more time and money on it too, for the benefit of 0.01% of the population who would be slightly inconvenienced if you didn’t.

The Unreasonable Effectiveness of Simple HTML:

https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...

> Compatability is only better if you make the assumption that all your users need to be using javascript

Are any companies foolish enough to assume otherwise? I understand there is a minuscule number of users who don't want to run JS in their browsers, but aside form Amazon and their near-unlimited resources, who is catering to that small number of users?

Battery life is the silent victim. Maybe browsers should name and shame websites that are heavy.

I would love to know how many milliwatts a page is using? Any way to find out?

I try to push for making websites without JavaScript but nobody wants to because it requires some forethought. TIL Amazon has a functional no-JS version, amazing!

Sites should work without javascript, but I think it's fine to demand a somewhat up to date browser in that case.

For features that have been very widespread for enough time, it's okay to have a javascript polyfill as the only fallback, in general.

The <dialog> element actually has deep support at this point, and the polyfill for the few percent of your users on 2021-era Firefox or Safari is totally fine. I highly recommend the element if you're making modals; the accessibility gains are fabulous.

> but because customer support will find it harder to help people.

This is a big one. At a past job we actively discussed this and instead decided to use JS over things like datalist due to it potentially increasing the CS burden. Datalist specifically was tried, but the inconsistent results meant it had to go.

We eventually ceased support for all browsers but Chrome as well due to the inconsistencies.

Nope. Javascript means that if it fails then it completely fails and the content is not there at all. While the HTML examples may not look correct in older browsers, the actual content will be there. With JS it's just nothing. Nothing at all. It completely breaks accessibility. With HTML my screenreader can at least still read it. JS generated content prevents this.

No amount of polyfill or other JS can save JS when JS cannot JS. It's terrible for accessibility unless it "works" to start and in that case your point is moot.

None of what you said is an inherent problem with JS.

The company I work for has JS app that is resilient against the missing-content problem you refer to. It is also more accessible than any other web app I've ever seen in my life. There's nothing about JS that breaks screen readers: you just... generate the right HTML with the right attributes.

The problems you see with JS apps that don't work are apps written by people who don't care about their app working and don't care about accessibility. That's orthogonal to whether a JS app maintained by a competent team can have better cross-browser compatibility than one (by the same team) that leans entirely on new HTML and CSS features.

The parent commenter is saying that JavaScript in the browser MUST NOT be a dependency for core functionality because it may be disabled ("when JS cannot JS").

If your site is popular over Tor — that is, if it's used for warez or by whistleblowers and journalists who need to browse privately — this may be good advice. If it's not, people who disable a core aspect of the browsing stack are savvy enough to enable JavaScript on a site-by-site basis when necessary.

>more accessible than any other web app

Well there's our difficulty communicating. I'm talking about all web sites, not just applications that happen to be run in a browser. A regular HTML page with text in it is far more accessible than any application depending on execution could ever be. Web applications can, in very rare cases be made accessible (assuming you have perfect execution and JS feature support in the browser). But actual web pages always are. 99% of the time if you can do it with just HTML and text/images you should.

So you missed that this whole thread is about TFA, which suggests using HTML for:

* Switches

* Autocomplete input fields

* Color pickers

* Accordions

* Modals

The accordion is arguably applicable to both, but with all the others it's pretty clear that TFA is about web apps, not content-heavy web pages.

Sample URL?

I side with you.

Sadly, the article itself is of no use and only a rant, since the “you” in “you don’t need” is not defined.

Have fun checking for mobile, tablet, desktop, Android, Apple, Chrome, Firefox.

It is not that developers rejoice over creating controls all the time. There is still html and css involved.

I briefly contributed to WURFL before I got out of mobile. Being able to figure out limitations based on UA I think has a place in the world because you can generate script tags for polyfills in the head based on which you need.

But now that I’m saying this, I think an attribute for script tags that only load if the browser doesn’t support feature X (or any feature in a set, so you can roll up polyfills that tend to be needed together.

That could be backward compatible because existing browsers would just load everything, and new ones could negotiate.

> I hope we eventually get to a place where browsers that don't support these features

Uhm... I wonder whatever happened to "decay gracefully"?

Define "gracefully"?

The standard behavior of "render unknown elements as if they were a div" isn't viable for more complex elements that aren't just content holders. Alternatives that involve developers specifically coding a backup component are more expensive than just writing a bespoke component in the first place.

What sort of graceful decay are you imagining for these cases where a whole widget is missing or is implemented differently across browsers?