Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Phone number datatype feedback #159

Open
plocket opened this issue Feb 16, 2023 · 0 comments
Open

Phone number datatype feedback #159

plocket opened this issue Feb 16, 2023 · 0 comments

Comments

@plocket
Copy link
Collaborator

plocket commented Feb 16, 2023

These were things that tripped me up when I was testing this feature.

(1) It let me get through with one or two letters in the number in various spots, even though that led to there being extra characters. (set to US)

[e.g. 41937jj78469 is valid]

(2a) My instinct on how to use this was to select my country first and then type in the number. Based on what I’ve documented below, I wonder if it’s just not designed to be used like that?

(2b) This is the suggested number it displays once I select Afghanistan as my country. It shows the country code (+93) while selecting the country, but NOT once it has been selected. The example number given makes it seem like you should leave out the country code.

[e.g. example placeholder for Afghanistan is "070 123 4567"]

(2c) Because it doesn’t display the + and country code, the error message you get is confusing. In the example below, the problem is that I added an extra digit to the valid Afghan phone number. The error message tells me the problem is the lack of + sign, but that’s not what’s preventing acceptance. If I just delete the extra number it would be accepted.

[e.g. 07012345673 with invalid input feedback of 'This phone number doesn't look right. Note that a non-US number needs a "+" before the number'

(2d) It accepted and then displayed the number below for Afghanistan (i.e. while Afghan flag was displaying in the little box) despite leaving out the + sign and country code. It seems like it should require and display a country code for foreign numbers.

[e.g. on display page: Your numbers were: 0701235343]

(2e) When I enter a foreign number this way and then go Back, the country resets to the US, even though it retains the foreign phone number I entered.

[e.g. US flag next to an Afghanistan number]

(Note, Afghanistan also has 10-digit numbers like the US, but similar things happen if you do this with Spain, for example, which has a 9-digit number (not including country code).)

(3) If you accidentally set it to a foreign country, then try to type in a valid US number, it doesn’t recognize what you’re doing and gives you a message that doesn’t really make sense. (The error message assumes you are trying to enter a foreign number, but you are really trying to enter a US number. What you need is a prompt to select USA as your country, or to enter +1 for a US number. Or for it to default to the US in this situation.) Since most numbers we get will likely be US numbers, I can see this being confusing.

[e.g. Afghanistan flag next to US number "4193778468]

(4) When you hit Back it adds the country code for US numbers even if you didn’t include it originally. I think that might be confusing for people.

(5) This is more a wishlist thing. I was hoping for something that would format/break up the numbers in an expected way when displaying the output. (e.g. (xxx) xxx-xxxx for US numbers).

Responses:

1

the users[0].phone_numbers() method will also reformat the number (does the same thing as Matt's code, with a little added safety in case it's an international number).

I do wish we could do input "combing" (the automatic adding of punctuation to the number). The library we use used to support combing, but they ran into too many edge cases with various international numbers. it's a hard problem to solve and we didn't find a library that did a good job of handling both international numbers and the automatic "combing"

2

The letters in the number is a good catch. I think we may need to dig into it a little. It's probably something in the library, not in our code, and we may not have much control over it, but we can look into it and file an issue in the library if needed.

Additional note

I remember reading that changing user input is something that's often discouraged, but will have to try to find a source for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant