Phone Number Standarization

Discussions around using and interfacing with the Church MLS program.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#21

Post by RossEvans »

RussellHltn wrote:So far no one has shown any policy or official direction that prevents the field from being used as the unit wishes. I wouldn't want to be the dba of that central database, but MLS exists to support the unit - not the other way around.

Can you point to a "policy or official direction' that says they can? Absent such explicit instructions, which would need to be documented in a data dictionary as well as end-user manuals. the common sense interpretation is that a field labeled "Name" should contain only a name, an "Address" field should contain only an address, a "Phone number" field should contain only a phone number, etc.

I am a DBA, and have seen many problems develop in government or business databases because some end-user somewhere adopted that attitude. It is simply poor practice in any organization.

The purpose of enforcing standards in a database is not to make the DBA's life easier, but to build and maintain reliable assets to support the end-users and the central organization both.
User avatar
Mikerowaved
Community Moderators
Posts: 4734
Joined: Sun Dec 23, 2007 12:56 am
Location: Layton, UT

#22

Post by Mikerowaved »

The only "official" source I can find is in the Membership MLS training videos that I just revisited. There, whenever a phone number is shown in MLS, it is in either the 555-1212 format, or the 888-555-1212 format. (On one screen it mixes both.) Baring any other directive from CHQ, I believe these are the recommended formats to store phone numbers in the US. Of course, nothing except a phone number is ever shown there.

I am also a firm believer in NOT adding any other text in the phone number field, such as "cell" or whatever. Who knows what kind of problems it may cause down the road for CHQ, or other programs that might pull data directly from MLS (such as exporting data for PDA use.)

Mike
So we can better help you, please edit your Profile to include your general location.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#23

Post by russellhltn »

boomerbubba wrote:Can you point to a "policy or official direction' that says they can? Absent such explicit instructions, which would need to be documented in a data dictionary as well as end-user manuals. the common sense interpretation is that a field labeled "Name" should contain only a name, an "Address" field should contain only an address, a "Phone number" field should contain only a phone number, etc.
I'm not suggesting that the unit places a zip code in the "phone" field. But putting a note as to why the phone number is absent or a note about the number is not that far a stretch. It would have been fairly trivial for the programmer to restrict letters from the phone field. "Beechwood 4-5789" hasn't been a valid phone number in North America in decades. And yet MLS does enforce lesser known policies of the Handbook of Instructions without comment in the end-user manuals.
User avatar
mkmurray
Senior Member
Posts: 3266
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

#24

Post by mkmurray »

RussellHltn wrote:I'm not suggesting that the unit places a zip code in the "phone" field. But putting a note as to why the phone number is absent or a note about the number is not that far a stretch. It would have been fairly trivial for the programmer to restrict letters from the phone field. "Beechwood 4-5789" hasn't been a valid phone number in North America in decades. And yet MLS does enforce lesser known policies of the Handbook of Instructions without comment in the end-user manuals.
I think we all agree the system would be vastly improved if you could enter in more than just 2 numbers for a household (or even better, individual) and have a drop down box of phone number "types" (home, cell, work, fax, etc.) for each entered phone number. Plus it would make the DBA in some of us sleep better at night.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#25

Post by RossEvans »

RussellHltn wrote: It would have been fairly trivial for the programmer to restrict letters from the phone field. "Beechwood 4-5789" hasn't been a valid phone number in North America in decades.

What makes that task non-trival is the junk that is in the distributed database today, accumulated from years of ill-trained clerks following such squishy standards as "If it is 'not that far a stretch' go ahead and key it in." So if standards and validation are ever imposed officially, the remedial task of scrubbing the legacy data will be a big distributed job.

There are similar problems with email fields. I have seen some horror stories there.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#26

Post by russellhltn »

boomerbubba wrote:What makes that task non-trival is the junk that is in the distributed database today
It would be trivial to prevent the data entry of new information that way. That would keep things from getting worse and normal move in/out would do some cleaning before "the big one".
jbh001
Senior Member
Posts: 856
Joined: Thu Mar 13, 2008 6:17 pm
Location: Las Vegas, NV

#27

Post by jbh001 »

boomerbubba wrote:Whether that is legitimate is controversial. I, for one, disagree.
Apparently you don't have members in your unit with agoraphobia. Even though someone's phone number may be readily obtainable, some well-meaning clerk may unwittingly fix a "blank" field thinking they are doing the ward leaders a service. Being able to flag a number as UNLISTED or PRIVATE, should send a red flag to the clerk to ask about it should he stumble across a phone number for a member that is not in MLS.

MLS needs to have a way to handle this. While the free-form text field may not be the most elegant solution, it is much more than adequate to the task at hand. And as much as I am against "do not contact" lists, puting DNC in the primary phone number or street address 1 field more than adequately provides a needed function even if is is aesthetically irritating and kludgy. Are the more graceful solutions? Yes. But I would rather see other improvements to MLS have a higher priority than something that is already more than adequate.

Maybe by MLS 4.0 a more elegant solution will be incorporated. But if not, what we have still works. Column widths in MLS can be adjusted in every MLS report (both preformated and custom) that I have tried to adjust, including membership directories and other reports that contain telephone/address information. This just ain't broke enough to bother fixing right now, IMO, regardless of how ugly or imperfect others may deem it.

I not a database administrator (DBA), so I don't see the problems of not having the data in pristine condition (or as Mary Poppins would say "a 1000 ciphers neatly in a row"). As long as it is functional/usable, it is fine. I don't think this issue will become a high priority until MLS migrates from being a Java-based application to a Web-based application and more members want to download the ward directory into their iPhone or smartphone. Only then will there be enough drive to impose a formatiing standard in MLS.
User avatar
AileneRHerrick
Member
Posts: 299
Joined: Mon Dec 08, 2008 2:33 pm
Location: Moses Lake, Washington, United States

#28

Post by AileneRHerrick »

Just my two cents on this (very old) thread. I am all for phone numbers in the United States being in a 10-digit format. Our cell phone area code is not the same as the area code of most members in our ward, and so we almost always have to dial ten digits when calling. That means if we use the LDS Tools application, and someone's phone number is entered as only 7-digits, then we have to go through a little extra effort to call them (making note of the number, then entering it with the area code on our keypad, instead of just clicking on it). It's not impossible to call someone, but it's just a few more steps than what a lazy person would prefer. :p
JamesAnderson
Senior Member
Posts: 773
Joined: Tue Jan 23, 2007 2:03 pm

#29

Post by JamesAnderson »

You're in an 'overlay' area, which means all calls are 10-digit dialing now. We have that in the Salt Lake metro, and most larger cities now have that as well as some other areas, it's more efficient to overlay than split now, so we're going to see that more and more as time goes on where there are overlay codes.

So it is essential that we get this into the app, and due to the fact that not all areas are overlay areas, it should be done where you can select if you are in an overlay area, and it will dial the ten-digit number if you are in the overlay areas, and if you are in an area where it is still only the one area code, 7 digits. That way, it future-proofs the app as well for you.
User avatar
AileneRHerrick
Member
Posts: 299
Joined: Mon Dec 08, 2008 2:33 pm
Location: Moses Lake, Washington, United States

#30

Post by AileneRHerrick »

JamesAnderson wrote:So it is essential that we get this into the app, and due to the fact that not all areas are overlay areas, it should be done where you can select if you are in an overlay area, and it will dial the ten-digit number if you are in the overlay areas, and if you are in an area where it is still only the one area code, 7 digits. That way, it future-proofs the app as well for you.
Or, just have the app dial all numbers as 10-digit numbers. That'd probably be simpler to program that having a variable.
Locked

Return to “MLS Support, Help, and Feedback”