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.
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.
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?
> 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?
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 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'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 :-)
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.
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.