Ward Area Book

[russellhltn]

Did they say anything about uploading MLS data? I know that was another concern.

[topherreynoso]

They did not have any other issues with this site. Like I said, I can't speak for any other site or its use of data. But they were familiar with this forum discussion and did take a look at this site and created an account while we were on the phone and we discussed its uses and features. The only thing they gave a resounding "no" on was the use of LDS account credentials. Since that is not an issue with this site, it is ok for use.

Thanks for the help, Russell.

[RossEvans]

I do find it interesting that church representatives expressed no problems with the site. That may be in part because the users have to key in all the names, addresses, etc. themselves, manually delete or archive members' unofficial records when they move out, and manually maintain any detail changes such as address edits. I would not be too keen on doing that with a large ward that has a lot of turnover. (That problem seems inherent in any system that has no reliable logical links from the official database of record.) If there were more import-export functionality, with unique but non-confidential keys that the clerk could link to MLS data, that problem might at least be mitigated in some external tool for clerks alone to use. At least that could identify records to add, delete or edit. Still a lot of administrative work to maintain just the basic directory data that MLS has, before any new content such as contact notes is ever added.

One other observation is that the logic and structure of the site are hard-wired according a certain methodology and flow, which might not match different processes that other ward councils invent for themselves. For example, you have built in one subset category called "Watch List," but other councils might prefer more categories of their own devising. As another example, wards might want to track which quorums have primary HT responsibility for each family, and their move-in dates, but there is no place to record these variables or slice and dice the roster this way.

Because of such diverse local "business rules," different units might prefer the flexibility of generalized tools such as shared spreadsheets. (Which, of course, present their own set of problems precisely because they do lack the discipline of a structured user interface and many-to-one relationships in a database.)

I mean all this constructively.

[topherreynoso]

I can't tell you how nice it is to have feedback on the actual app rather than a discussion on church policy (albeit an understandably important discussion).

The app does allow you to import a csv of user info and import another csv with updated info at any time. This will automatically let you know when families should be moved to the archive and when new families should be added. It also identifies families with info that is different than the csv, letting you see and decide what to update and what to leave out. I like this format because it allows the ward council, who often ends up with updated contact info, to input this info in the area book (since most of them don't have MLS access) and it let's me, the clerk, see that our ward book has info that I need to submit to MLS. Minimal maintenance effort. It's a matter of getting the csv and checking a few boxes at import time.

I do agree that some more flexibility would be good and I am open to suggestions! Thanks for the feedback.

[RossEvans]

The app does allow you to import a csv of user info and import another csv with updated info at any time. This will automatically let you know when families should be moved to the archive and when new families should be added. It also identifies families with info that is different than the csv, letting you see and decide what to update and what to leave out. I like this format because it allows the ward council, who often ends up with updated contact info, to input this info in the area book (since most of them don't have MLS access) and it let's me, the clerk, see that our ward book has info that I need to submit to MLS. Minimal maintenance effort. It's a matter of getting the csv and checking a few boxes at import time.

I like the idea of a csv import. (I had misunderstood from the earlier discussion, thinking all such functionality had been removed to satisfy the forum policy police.) Is this csv format designed to your own spec, or is it an export format from either MLS or lds.org? It is not very feasible to mix up these two sources of directory content, because their name content is not compatible. In my ward, for example, almost 15 percent of the household names disagree between the MLS and lds.org directories for various reasons -- mostly because non-member spouse names are included in the latter but not the former.

Allowing council members to update contact info raises a huge red flag for me as a clerk. There has to be a single authoritative source of such data, and it is dangerous to encourage the council to edit this ad hoc database and think the master database has been updated when it has not. MLS and lds.org, which are cross-synced, comprise that authoritative source. If other council members have updated contact info, they should communicate it to the clerks to update the authoritative source. (Your finding-note transaction items are a good place to do this.) I suggest making all the name-address-contact fields themselves read-only except for clerks.

[topherreynoso]

You can use a csv from lds.org but you are also free to make changes or create your own, the lds.org export is just the fastest way to get to a list of household names. I think you misunderstand the import and ability for ward council members to update info. The ward area book is not the authoritative source of member info, that would be MLS and lds.org (since lds.org derives its info from MLS). But allowing ward council members to update family info in the area book isn't at all an issue because any changes are easily set back by doing an update from a csv if the administrator so chooses. It's quick and pretty simple but, alternatively, during that update if I notice that info is different I'll look at the date of update and know whether the ward area book has more recent data or if the new csv import has the more recent data and I can decide whether or not an update to MLS is appropriate for me to make.

One day a month our entire ward council gets together, meets for just five minutes and then we all go out to see individuals and families that our organizations are focusing on or new members, or less active members that we have little information on. We live in a beach city so we get a good amount of traffic, transients, young adults, people we have little information on etc. on almost a monthly basis. This allows the ward council, in our monthly efforts, to gather information in these situations without me having to spend much time chasing behind each ward council member, they just report their visits here, update info they receive here (after all the ward council group is a generally responsible and reliable group) and then the bishopric can follow their progress, review knowledge about families and individuals easily without having to do it all in WC meetings.

[RossEvans]

One other feature that many ward councils would want is a free-form notes field attached to the header record for each household. As I understand your structure, the only free-form text fields are in the time-stamped finding-transaction records.

I have seen lots of ad hoc spreadsheets concocted by various councils, PECs, quorum presidencies, etc. over the years to record stuff about members and/or households. All have had such notes content because no one can keep all that straight in their heads. It is a good bet that headquarters will never add such features to official systems. But local leaders usually want them in their own files somehow, despite the risk of misuse.

BTW, I am glad to hear that the church representatives did not express objection to importing basic csv directory files exported from lds.org. (Structurally, I would prefer the MLS export format, or even both to accommodate differences.) But the export-import precedent is important to know.

[topherreynoso]

Excellent point on the family notations and one that a few other members of my ward council had requested. I will set about implementing it in the next few days.

RE: importing CSVs (sorry to turn this back into that discussion, because it's not an interesting discussion to me and I hope this is the last time I address it, I'm far more interested in ways to actually help ward councils)

I don't know what the exact policy is other than what is posted on lds.org which has been discussed in detail on this forum. I don't know how these policies will be handled in other situations. All I can tell you is what I built and what I've heard from the church regarding what I built. I built a tool from which I derive no profit and which is publicly available on a code level with an import feature in which all imported data is always encrypted on the server in a way that not even a server admin has access to decrypted data, and which the person who imports it has complete control over who can view the data. How much of that is required to avoid violating a policy? I have no clue. All I know is that I have been contacted by people who are actually authorized to speak on behalf of the Church and no violation of the policy has been indicated to me.

It is encouraging to know that Google and Dropbox servers are not the only servers deemed worthy of holding data like this, especially given the motivations and security issues of companies like those (not to imply that they're evil or anything, I'm just saying it would be strange to "ok" a company that literally crawls your documents to identify better ads for you but restrict an app like this one).

[topherreynoso]

Quick update: the app now supports family notes as previously mentioned by RossEvans. I also cleaned up some scrollbar issues that were quirky in IE. I don't have regular access to an IE browser so if anyone sees anything else that seems off, feel free to mention it to me here or raise an issue on the Github site and I'll get it resolved.

[Uknown4now]

I am very happy to have found this! A tool that is pretty well developed already and has much of the functionality needed. I am a Ward Mission Leader and therefore a ward council member and I would love to leverage this tool to help manage ward mission efforts in addition to general ward council efforts. I have many ideas and there has been a form started on linked in for the same. I will direct them here and I imagine you will have plenty of feedback.

On a side note, I do not see the ability to import csv data. Is this because I am not set up as a ward clerk? How can I gain this ability as I will be the one managing the site for now?

I am going to give it a good look over and offer some feedback. Thank you for your efforts!