Can phone and vanity number be combined in admin interface?

[anselmbradford]

As far as I know, vanity numbers (letters in place of numbers http://en.wikipedia.org/wiki/Phoneword) can be mapped to phone numbers behind the scenes, so could a data maintainer be able to enter either a full phone number or a vanity number into the phone number field and the system can figure out what the number is if a vanity number is entered. This would allow individual contacts to use vanity numbers that their organization uses and also would remove an extra field from the admin interface.

[monfresh]

I think this would add more complexity without adding much benefit. Here are the problems with getting rid of the vanity number field from the admin interface:

1. If there is only one field, that means that the only way for both the regular number and the vanity number to be exposed by the API is for the data maintainer to always remember to enter the vanity number. If they enter a regular number, then they'll have to delete that number and start all over making sure to enter the vanity number. They can't simply add the regular number as a new number, because that would be a different number.
2. In order for the API to expose both the regular and vanity numbers, it would have to add additional logic to convert the vanity number to a regular number. This would still require an additional field in the DB to store both numbers separately. Alternatively, the second number field could be created during JSON serialization, which would slow down the API response time. In the latter case, the regular number wouldn't be displayed in the admin interface because it reads directly from the DB, not the API.

[anselmbradford]

If there is only one field, that means that the only way for both the regular number and the vanity number to be exposed by the API is for the data maintainer to always remember to enter the vanity number. If they enter a regular number, then they'll have to delete that number and start all over making sure to enter the vanity number. They can't simply add the regular number as a new number, because that would be a different number.

I wonder if an organization would be swapping between numbers? My guess would be they'd be using the vanity number primarily or the numeric number primarily, but maybe not. If an organization used a vanity number, would that be the one that a contact was familiar with? At least it seems like it would be helpful to have validation that the vanity number and actual number are the same number. Like a contact may be familiar with the vanity number and have to look up the numeric number, which could mean they could miss errors in the number more easily.

In order for the API to expose both the regular and vanity numbers, it would have to add additional logic to convert the vanity number to a regular number. This would still require an additional field in the DB to store both numbers separately. Alternatively, the second number field could be created during JSON serialization, which would slow down the API response time. In the latter case, the regular number wouldn't be displayed in the admin interface because it reads directly from the DB, not the API.

I wasn't suggesting an on-the-fly solution, I was thinking behind the scenes it would be two fields. There would be extra logic, but the complexity of mapping phoneword letters to digits seems minimal.

Anyway, thoughts for an enhancement. It seems problematic to me that the system allows a difference between the vanity number and numeric number that could be missed and that a contact can't use the same vanity number that a location may be using.

[monfresh]

I wonder if an organization would be swapping between numbers? My guess would be they'd be using the vanity number primarily or the numeric number primarily, but maybe not.

Based on SMC data, every single vanity number has a corresponding regular number. Also, I find it much easier to dial when I just have digits to deal with than having to figure out which digit to press based on the letter. I bet you many other people feel the same way, and I'm pretty sure most organizations that have a vanity number also provide the regular number.

Like a contact may be familiar with the vanity number and have to look up the numeric number, which could mean they could miss errors in the number more easily. [...] It seems problematic to me that the system allows a difference between the vanity number and numeric number that could be missed

It's possible, but using SMC data as a reference, not a single error was made. I personally verified them all, and they were all correct. This leads me to believe that the regular number was already available for the person entering the data so that they didn't have to figure it out on their own.

a contact can't use the same vanity number that a location may be using.

I think vanity numbers are usually associated with the general phone number, not a specific contact's number. I don't think I've ever seen a specific contact's number listed as a vanity number. The OpenReferral spec currently doesn't define a vanity number for a Contact, so if you think it should be available, I would open an issue there.

There would be extra logic, but the complexity of mapping phoneword letters to digits seems minimal.

It all adds up, and I'd prefer to avoid adding new features based on speculation (that organizations only use one type of number, that data entry mistakes happen often when dealing with both vanity and regular numbers, and that contacts want to use vanity numbers), as opposed to user feedback or actual data. Also, based on SMC data, vanity numbers are not very popular. There are exactly 61 vanity numbers, and 3630 regular numbers.

One of my favorite quotes is this one, from Antoine de Saint-Exupéry:

It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.

[anselmbradford]

Okay, fair enough. To clarify I meant two fields in the database so the vanity number and numeric number could still be displayed together in ohana-web-search (or in the admin interface as a display only value for one of them). I was speculating that eliminating fields that have to be updated and maintained in the admin interface when their values could be automated would be helpful. This could be a client-side task as well. For example, upon updating either field give a prompt to update the other, or an alert when they differ.

[anselmbradford]

*Err not either field, but when updating the vanity field.