3 ms·

So far, everyone is focusing on the JSON vs regex thing, but that's not the worst of the criticisms leveled here. Not being able to use the +44 prefix, or form

So far, everyone is focusing on the JSON vs regex thing, but that's not the worst of the criticisms leveled here. Not being able to use the +44 prefix, or format the number with dashes are stunningly obvious usability problems that honestly should not have made it out of QA. You'll see the same thing on different sites with credit card numbers. See, every credit card issuer uses a scheme called an "issuer identification number" to tell you what type of card it is. And, there's a list of them [0]. So, for instance, I can tell that any valid credit card number that starts with 4 must be a Visa. So, why ask me what type of card it is, when you can figure it out yourself? Those rare sites where you actually want to put your Social Security number in have these sorts of issues, too. Some of them require dashes, some of them don't. Some of them will only allow you to enter 9 characters, but won't tell you not to use dashes. It's infuriating, really. And, any site where you enter an account number can potentially have these types of issues. It's not like being just a little more flexible with input formatting is a major feature with huge implementation costs and security risks, either. We're talking about failing to take a few minutes' thought in order to be a little more kind to the user, and that's just inexcusable, IMO. --- [0]: https://stevemorse.org/ssn/List_of_Bank_Identification_Numbers.html https://stevemorse.org/ssn/List_of_Bank_Identification_Numbe...

Dunedan 5y ago
> It's not like being just a little more flexible with input formatting is a major feature with huge implementation costs and security risks, either. Just in case somebody considers implementing phone number parsing and normalizing: Just don't and use Googles libphonenumber, which offers solid, ready to use implementations in various languages (there also exist ports for other languages too): https://github.com/google/libphonenumber/ https://github.com/google/libphonenumber/
- hallway_monitor 5y ago
  In case anyone asks you to implement any input formatting, see if you can get them to change their minds. IMO the most bug-prone and useless feature of websites. Let the user put in whatever they want and just input.replace(/[^0-9]+/, ''). You, your users and your product owners will be happier.
  - Dunedan 5y ago
    This doesn't work for phone numbers if you want to do something programmatically with them. In Germany it's for example common to include the international prefix _and_ a trunk prefix like this in written phone numbers: +49 (0)30 23125 123 Your naive approach to just replace non-number characters would lead to an invalid number in such a case. Using libphonenumber you'd get a correctly normalized phone number while the user doesn't get bothered for inputting a technically invalid number: https://libphonenumber.appspot.com/phonenumberparser?number=%2B49+%280%2930+23125+123 https://libphonenumber.appspot.com/phonenumberparser?number=...

Dunedan 5y ago

> It's not like being just a little more flexible with input formatting is a major feature with huge implementation costs and security risks, either. Just in case somebody considers implementing phone number parsing and normalizing: Just don't and use Googles libphonenumber, which offers solid, ready to use implementations in various languages (there also exist ports for other languages too): https://github.com/google/libphonenumber/ https://github.com/google/libphonenumber/

hallway_monitor 5y ago
In case anyone asks you to implement any input formatting, see if you can get them to change their minds. IMO the most bug-prone and useless feature of websites. Let the user put in whatever they want and just input.replace(/[^0-9]+/, ''). You, your users and your product owners will be happier.
- Dunedan 5y ago
  This doesn't work for phone numbers if you want to do something programmatically with them. In Germany it's for example common to include the international prefix _and_ a trunk prefix like this in written phone numbers: +49 (0)30 23125 123 Your naive approach to just replace non-number characters would lead to an invalid number in such a case. Using libphonenumber you'd get a correctly normalized phone number while the user doesn't get bothered for inputting a technically invalid number: https://libphonenumber.appspot.com/phonenumberparser?number=%2B49+%280%2930+23125+123 https://libphonenumber.appspot.com/phonenumberparser?number=...