Filtering on verified location status missing

[erinbourgeous]

But the whole point of my reviving this thread is still not accomplished. Is the filter for location status still a feature that will be implemented? I am trying to make the case that is should be, even if it's not a documented and approved reason... it is effective and has uses that make it more effective to serve those for whom we have responsibilities.

It's currently on our list for a future release. We understand that it has proven useful but due to constraints in development resources and other features receiving higher priorities it didn't make the cut for this release. I'll continue to bring this up in project planning meetings but it is up to our product owner and I can't give you a definitive answer as to when this will be completed.

[RossEvans]

Should all the members come to expect that a certain status means something specific? No, probably not, but I also see no reason why members that aren't where their address says shouldn't be unmapped, and the clerk could use that list of unmapped households to do what a clerk should do with those households, including moving them out, or correcting their address and verifying their correct location.

If you read my comment, you will see that I don't disagree that such members could be unmapped.

However, the clerk will need to record more information than that externally to track the membership-in-ward status. He must try to get a new address and record it in MLS, moving the record if necessary, or moving it to Address Unknown. Several intermediate actions are probably required, such as mailing to seek a forwarding address, searching other online resources, etc. All of that is beyond the scope of the map application. Meanwhile, the category of unmapped also can include members who actually live at addresses in the ward that are just not geocoded. So he will have to distinguish those cases outside the maps application.

Respectfully, if your goal was to convince me that our use was not really acceptable, you'll have to try again. I can be stubborn sometimes.

I don't disagree with that, either.

But I still believe that abusing designed field values for undocumented purposes is a bad practice. On that larger point we will have to agree to disagree.

[dobrichelovek]

First, Erin,

Thank you again for your response. I guess I thought that it might have made it in before turning off the other version, basically regressing a feature that already existed. I do understand the reality of resource constraints, however, and appreciate you clarifying once again that it is still a planned feature. You have told me what I hoped to know, and I'll just look forward to that capability returning.

Secondly,

If you read my comment, you will see that I don't disagree that such members could be unmapped.

However, the clerk will need to record more information than that externally to track the membership-in-ward status.

I think we are generally on the same page here, and I did see that from what you wrote. I basically said the same thing, that it's only a starting point for what a clerk would have to do more than that. No arguments or disagreements there.

But I still believe that abusing designed field values for undocumented purposes is a bad practice. On that larger point we will have to agree to disagree.

We're just not fully on the same page here, and that's fine with me, to agree to disagree. I get the point of not using field values in an undocumented fashion, in programming, and generally agree with that. For what we needed the tool as constituted served our purposes as designed, whether documented or not, of allowing us to 'filter' the households based on how we have verified the status within our own unit. The benefits of using the tool as it is for this purpose in our unit outweighed the problems that might be associated with it not being a perfect and complete solution, when other options were more cumbersome. I just don't see the point of not using a tool that works when it makes things better, but maybe, to your point of it being bad practice, I might refrain from actively advocating it any more than I have. I'm sure I've done enough damage as it is.

[jdlessley]

I find the use that dobrichelovek and his ward have come up with for the "unverified/verified" feature quite interesting. I had never thought of "verified" as having an extended definition beyond the manual agreement of a geocoded position. I like this thinking. I do, however, see some validity to RossEvan's concern about the intended use of a feature.

When we use a feature of an application beyond its intended use there is the possibility of confusing the users of the application who view the results of this creative use. For dobrichelovek and those who are "in" on the extended definition there is no problem. There is actually an added benefit. But to those who are not "in" on the extended definition there can be confusion. What happens to a member in dobrichelovek's ward who understands the definitions of verified and unverified as was used in that ward who then moves to another ward where the intended programming definition is used?

As long as those using the extended definition are aware of the intended definition then there probably is no concern.

[russellhltn]

I find the use that dobrichelovek and his ward have come up with for the "unverified/verified" feature quite interesting. I had never thought of "verified" as having an extended definition beyond the manual agreement of a geocoded position. I like this thinking. I do, however, see some validity to RossEvan's concern about the intended use of a feature.

I think dobrichelovek's use is rather clever. In most wards, "unverified" really means "we haven't gotten to it yet". His approach of not verifying until the member themselves have been verified would seem to have some merit. It is a more complicated work flow, but if they're happy to do it that way, I don't see a problem.

The only downside I can see with this unusual approach is that someone may misinterpret "unverified" as a recent move-in. But to do that, you'd have to know how often (if ever) the ward goes though verifying all the addresses. In either case, the desired report is useful for all wards because in all cases "unverified" means there's work that needs to be done.

In my mind, the bigger issue is how in-ward moves are handled. (Showing the old location as "verified".) But I think we've beaten that horse to death.

I do agree that in general trying to use things in a different manner has problems, but I'm missing the issue on this one.

[RossEvans]

The only downside I can see with this unusual approach is that someone may misinterpret "unverified" as a recent move-in. But to do that, you'd have to know how often (if ever) the ward goes though verifying all the addresses. In either case, the desired report is useful for all wards because in all cases "unverified" means there's work that needs to be done.

I think the more general downside is potential confusion. That confusion can arise among units, across member moves, and across changing callings, both in the minds of rank-and-file users and leaders.

Another practical downside is that by creatively adopting a higher bar before coding an address as "Verified," the clerk delays hitting the desired geocoding standard, thereby thwarting the common goal of capturing rooftop-accuracy geocoding for all member addresses. Capturing that fundamental data correctly is a prerequisite for actually using the lat/lon for many worthwhile purposes (emergency prep, boundary analysis, HT/VT planning, fast-offering routes, etc.).

I am quite sure that if we adopted that higher bar in our huge ward, we would never achieve "Verified" status for everyone.

One purpose of the mapping tool is to build a churchwide asset, useful across wards, stakes and areas, by capturing standardized data in a central database. That asset is devalued when local units make up their own rules for the content. This is not a free-form field, by design. The developers built a handful of discrete values that can be chosen in the user interface. Discrete, required values are supposed to have defined meanings. (Even in unstructured text fields, I also object to writing comments into fields labeled phone or street address just because a user invents some short cut. That's Database Management 101, Application Design 101 and should be Clerk Training 101, too.)

I have always thought it unfortunate that clerks are obliged to manually verify the geocoding of most addresses in the first place, given the state of the art. But the system is what it is, and clerks should follow consistent rules. For most developed areas, at least it is usually feasible for clerks to verify geocoding using online resources alone, without the additional time, work and perhaps travel required if they conflate this task with confirming each member's residential status.

Also, if some units creatively define "Verified" to mean that the member is confirmed to live at the address, another ambiguity immediately arises: As of when? If you want to record confirmed physical presence, you really need to record a date along with it because people move all the time. The right place to capture that status is in MLS, or some private leadership spreadsheet, not the maps application. By contrast, geocoding accuracy for a given address is essentially immutable. So the designed definition of the field content on the maps site is appropriate.

[russellhltn]

I think the more general downside is potential confusion. That confusion can arise among units, across member moves, and across changing callings, both in the minds of rank-and-file users and leaders.

Confusion about what? Anyone who moved into a different ward/stake is bound to be confused if the new ward has different "work ethic" on verification.

Another practical downside is that by creatively adopting a higher bar before coding an address as "Verified," the clerk delays hitting the desired geocoding standard, thereby thwarting the common goal of capturing rooftop-accuracy geocoding for all member addresses. Capturing that fundamental data correctly is a prerequisite for actually using the lat/lon for many worthwhile purposes (emergency prep, boundary analysis, HT/VT planning, fast-offering routes, etc.).

That's a trade-off that needs to be considered. OTOH, if you're not sure a member lives at that address, shouldn't that be factored into your emergency plan before you expend efforts to go across a devastation zone looking for them?

I am quite sure that if we adopted that higher bar in our huge ward, we would never achieve "Verified" status for everyone.

I don't see anyone saying that this is something all wards should follow. It's simply what that ward finds best for their needs. And I'm sure that will depend on the ward's past experience with move-ins -whether they normally be accurate or highly suspect.

One purpose of the mapping tool is to build a churchwide asset, useful across wards, stakes and areas, by capturing standardized data in a central database. That asset is devalued when local units make up their own rules for the content. This is not a free-form field, by design. The developers built a handful of discrete values that can be chosen in the user interface. Discrete, required values are supposed to have defined meanings. (Even in unstructured text fields, I also object to writing comments into fields labeled phone or street address just because a user invents some short cut. That's Database Management 101, Application Design 101 and should be Clerk Training 101, too.)

Now we come down to the heart of it. If someone sees this as a "churchwide asset", then someone above needs to make the call in how it's used and how much effort is put into it. I'm sure there are some stake/wards that have put ZERO effort into it. Others, have worked very hard on it. I fail to see how dobrichelovek's use has moved any centralized usefulness outside of those two not uncommon extremes.

If he were to use "verified" to record HT/VT visits, then I'd agree with you.

Also, if some units creatively define "Verified" to mean that the member is confirmed to live at the address, another ambiguity immediately arises: As of when?

Good point. The timeliness of that will depend on how good the HT/VT of a give ward is. And while your suggestion is a good one, that's setting the bar/workload even higher.

[RossEvans]

Confusion about what? Anyone who moved into a different ward/stake is bound to be confused if the new ward has different "work ethic" on verification.

Conflationg two concepts -- one about geocoding and another about ward membership status -- is inherently confusing.

One one hand, a user (member or leader) from this ward learns a different expectation: If a household is marked "Verified," that means something different than just geographically verified. It means the family is known for sure to live at this address because either they are active or have been visited. Under that system, a user would tend to think that anyone "Unverified" may just be inactive. But if the user moves to some other ward, "Verified" would mean something else.

On the other hand there may be some locations in this ward that leaders know to be geocoded correctly but are left "Unverified" because membership tracking lags.

OTOH, if you're not sure a member lives at that address, shouldn't that be factored into your emergency plan before you expend efforts to go across a devastation zone looking for them?

Maybe, but not at the expense of the primary meaning, which is that this address is mapped accurately.

I think you are missing a key point: By adopting this different process, a unit is less likely to get its addresses "Verified" because it takes a lot more time and work. Verification is work, but that can usually just be done online. But under this system, even a visit to the home will not result in a "Verified" status just because no one answers the door.

If emergency prep leaders are supposed to take membership and activity into account, the designers could have made that one of the private fields that are recorded for their use. But I suspect that in an emergency priesthood leaders are supposed to worry about everyone on the rolls. The primary objective should still be to get the address mapped accurately. And as I said above, if it becomes known for sure that the family does not live at this address, unmapping that family is the benign thing for the clerk to do.

For other purposes, such as boundary analysis, the address should govern whether the family comes to church, receives visitors, or not. And in our ward, we first map all members accurately so we can give priesthood holders (fast-offering teams) reliable maps to manage and assist their visits to homes in the first place. Those visits, in turn, may result in learning that the address for a family is wrong because of a move, and that information is fed back to the ward leaders for action.

Now we come down to the heart of it. If someone sees this as a "churchwide asset", then someone above needs to make the call in how it's used and how much effort is put into it. I'm sure there are some stake/wards that have put ZERO effort into it.

I do agree with you on that. My perception is that the uptake of the mapping tool by units is pretty low, especially in non-Utah areas where it might be the most useful at any level.

Unfortunately, I see this as another sad example of how the rollout of the application is falling short. Instead of automated geocoding, the tools that were delivered are ultimately manual. But the manual work is treated as optional. Compounding the problem, the church geocoding deliberately ignores moves within wards, resulting in some grossly wrong locations. Now it turns out that the tool is sometimes distorted to record different information than it was designed to track, and that seems okay with a lot of folks here.

The bottom line is that the data overall is less reliable and less understood, so the application lacks credibility. I continue to root for its success, but I know the geocoded data being captured is not great. So for real mapping work in our ward, I still bypass it and use my own geocoding because I know it to be more complete and more accurate. Of course, that does not do the users of maps.lds.org any good.

[russellhltn]

Unfortunately, I see this as another sad example of how the rollout of the application is falling short. Instead of automated geocoding, the tools that were delivered are ultimately manual. But the manual work is treated as optional. Compounding the problem, the church geocoding deliberately ignores moves within wards, resulting in some grossly wrong locations. Now it turns out that the tool is sometimes distorted to record different information than it was designed to track, and that seems okay with a lot of folks here.

Accurate geocoding is expensive. There are more important things that need to be funded. Likewise, there are more important things for members for clerks to work on. I see it as a tool provided by the church for the use of the local leadership. Local leaders use (or not use) the tool according to how useful they find it. It's up to the local leaders to decide how much effort should be put into verification. I see dobrichelovek's process as an extension of support for local leaders. So far I've not seen evidence that anyone higher then a stake is using the information.

[RossEvans]

Accurate geocoding is expensive. There are more important things that need to be funded.

Actually, the accuracy of most geocoding in our area seems to have improved over time since the early prototype of maps.lds.org. I don't know what geocoding provider(s) the church is using, but for most addresses we are getting rooftop-level accuracy now for single-family homes. However, the system is not built to recognize that, even though decent geocoders typically report that precision status on the back end. Clerks are still obliged to manually verify each address.

It's up to the local leaders to decide how much effort should be put into verification.

I understand that. In practice, I think that means stakes need to mandate the use of the process and train clerks accordingly. If and when they do, I hope they train the clerks to a consistent standard that does not conflate geocoding with membership tracking.

Since the church still does not yet provide stakes with software tools that could profitably employ the captured geocoded data for boundary analysis, there is less incentive for stake leaders to get behind the program. If they acquire such tools themselves and are under the gun to do some boundary work, they may find they are too late. The time for rolling out the process to ward clerks needs some lead time to implement. When that time comes, the more expedient course may be just to geocode all the addresses externally.