Live data from Hacker News

User Inyerface – A worst-practice UI experiment

userinyerface.com

61–70 of 222 posts

Re: User Inyerface – A worst-practice UI experiment

#63
post #52

Earlier quoted context omitted.

My email address has a dash in the domain and it's remarkable how many sites (and big ones, too!) reject it as an invalid domain. Discover.com, for example, rejected it when I did a card application, but disabling JavaScript let it go through on the server-side validation. Bloody weird.

Lots of websites reject email addresses at entirely valid domain names as invalid, too, such as any at some of the new TLDs like .email.

I'm a little more inclined to forgive that, but dashes in the domain have been valid for decades.

Re: User Inyerface – A worst-practice UI experiment

#65

For Canadians... I love this one: ENTER YOUR POSTAL CODE: A1A1A1 Lazy %@$# front-end devs that can't reformat the input!

My email address has a dash in the domain and it's remarkable how many sites (and big ones, too!) reject it as an invalid domain. Discover.com, for example, rejected it when I did a card application, but disabling JavaScript let it go through on the server-side validation. Bloody weird.

Really the entire idea of client/server-side email "validation" kind of seems like an ancient, cockroach-like anti-pattern that is impossible to stamp out. Like, what is the problem they're even solving? One validates email addresses by sending an email with a token the user then acts on. There are useful things to do with emails, like checking against already registered ones (including any blacklists), but I can't think of any that would result in any in-page user feedback since that would generally be a dumb information leak. Like if someone tries to register an already registered email, send an email about it don't leak that it's registered.

And as well as being useless most such scripts seem to date back a long ways and have very lazy and fixed assumptions about what constitutes a valid address. I mean, I've never been a fan of the explosion of TLDs, but it's also a reality and they're all valid. Even on the left side of the @ a surprising number of scripts seem to fail on things that are perfectly acceptable characters.

Strikes me as one of the many little minor GUI traps where new designers get carried away with the power of scripts and do without asking if they should, then further get too clever by half.

Re: User Inyerface – A worst-practice UI experiment

#66
post #47

For Canadians... I love this one: ENTER YOUR POSTAL CODE: A1A1A1 Lazy %@$# front-end devs that can't reformat the input!

I'd say it's the backend's job to accept any of those and reformat accordingly. If you rely on the frontend the backend would still have to validate it anyway.

Yup. If you’re going to do validation on the frontend, it should be for the sole purpose of improving user experience, not for making life worse!

Re: User Inyerface – A worst-practice UI experiment

#67

For Canadians... I love this one: ENTER YOUR POSTAL CODE: A1A1A1 Lazy %@$# front-end devs that can't reformat the input!

My email address has a dash in the domain and it's remarkable how many sites (and big ones, too!) reject it as an invalid domain. Discover.com, for example, rejected it when I did a card application, but disabling JavaScript let it go through on the server-side validation. Bloody weird.

My email address is "_@" followed by a domain name with a dash followed by the "shop" domain ending. It gets rejected a lot, but I won't give it up. It's a good indicator of whether I should spend more time at the website.

Re: User Inyerface – A worst-practice UI experiment

#68
post #65

Earlier quoted context omitted.

My email address has a dash in the domain and it's remarkable how many sites (and big ones, too!) reject it as an invalid domain. Discover.com, for example, rejected it when I did a card application, but disabling JavaScript let it go through on the server-side validation. Bloody weird.

Really the entire idea of client/server-side email "validation" kind of seems like an ancient, cockroach-like anti-pattern that is impossible to stamp out. Like, what is the problem they're even solving? One validates email addresses by sending an email with a token the user then acts on. There are useful things to do with emails, like checking against already registered ones (including any blacklists), but I can't t…

> Even on the left side of the @ a surprising number of scripts seem to fail on things that are perfectly acceptable characters.

I've had an input require a minimum of 3 characters on the left side of the @ to register. My email was just "me@example.com" using my own domain name. A perfectly valid email address. I am also unable to sign up for Id.me for the IRS because it rejects both of my personal email addresses. I cannot register to create NPM packages for the same reason. I also cannot sign up for Vercel either. I cannot sign up to Vercel via Github and when I try to sign up by email it says the account already exists. When I attempt to do a password recovery for the email it says "Sorry, we are unable to validate that email." So the original error of "account already exists" is actually wrong - the account doesn't exist and can't exist because they aren't able to validate the email for it.

My personal emails aren't even "weird" ones like ones with an emoji or punycode domain or non-Latin character sets.

I hate with a fiery, burning passion every site that attempts to do any kind of email validation beyond simply sending me an email and letting me click a link to verify my email exists.

Re: User Inyerface – A worst-practice UI experiment

#69

Earlier quoted context omitted.

I have a personal punishment policy for any obvious violation of UX/UI - they will permanently and irrevokably lose me as a customer. Even if they fix it, I won't budge. Leadership needs to use their own products and if they allow this to go to production, I wonder what they're doing behind the scenes. Small battles that I pick, but by god it is so satisfying.

So a small shop that can only pay 1 fresh bootcamp dev who is trying their hardest doesn’t get your business because they can’t keep up with several hundred Frontend google devs. Seems a little silly and absolutist.

Most horrible UX comes from too much software, not to little. If it was a single dev, they’d probably not have time to implement all the popups, dickbars, newsletter reminders, full screen interruptions, and dark patterns. Horrible UX takes large engineering effort.
Post reply on HN