Ward Mission Program

Discussions around miscellaneous technologies and projects for the general membership.
Post Reply
User avatar
bhofmann
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

#41

Post by bhofmann »

tomw wrote:The app was really designed to help a ward mission leader, who would want to know dates.
Even though we don't use the convert baptism checklist much anymore we still try to have new converts make it to the temple at one year from their baptism. It would be helpful to know the baptism date for that too.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#42

Post by WelchTC »

nimebe wrote:The baptism date isn't as much of a concern. Does the same need hold true for the confirmation date? That seems to be the more sensitive information as far as the church is concerned.
There is a place on the official "Teaching Record" that missionaries use for confirmation date. However because we don't need to track anything from that, I could probably lose that field.
nimebe wrote:Don't get me wrong, I see your program as a great resource and tool! I wouldn't take the time to ask questions otherwise. I'm also not saying that it shouldn't be this way, I'm just trying to understand better.
I very much appreciate your time reviewing the project! Thanks!
nimbebe wrote:I think your application has so much more potential, such as use by the Elders Quorum to track HT visits to certain families. I know it's hard enough sometimes for the Elders Quorum to even get people to report their home teaching as done or not done but for some families it would be great to have a record of each visit and how the visit went and what the family need etc.
I hadn't thought of that but you are right. It could be extended into a lot of other directions.
nimebe wrote:I was looking at this and the Emergency Preparedness Program at http://jay.askren.net/emergency/ . Would there be any possibility, point, or reason to combine the two programs into a more comprehensive single unit? Just wondering. Thanks again Tom!

Possibly. Currently that would require a fair amount of redesign on one or both of the programs but it is not out of the range of possibilities. My thought was that they serve different purposes. Chances are that the emergency preparedness person from the ward would not be the same as the ward mission leader. However, as the program expands, they could merge.

Tom
User avatar
albertoaflores-p40
New Member
Posts: 6
Joined: Thu Jan 25, 2007 7:28 am
Location: Elkridge, MD
Contact:

#43

Post by albertoaflores-p40 »

Hello,

I recently downloaded the binary file from your site. It looks like a great tool to have. Having served in that calling in the past, I was able to get a feel of the features I can find helpful during correlation meetings, PEC and Ward council. While in that calling (2002) I maintained most of my information on an spreadsheet (excel). I used this spreadsheet and maintained it every week (will probably revised it twice a week at a minimum). That helped me produced nice graphs, statistics, etc for then passing those graphics as part of my report to the bishopric during PEC meetings. I have always wanted to build (or help build) an app that helps other WML in their calling and when I saw this post I was very thrilled. May I help out in any way? I have Swing and J2EE background that I hope it can be of some help.

Some aspects that I think this tool can greatly benefit are:

- Reporting tools. Graphs, statistics, trends are just numbers but these can help discover certain facts of missionary efforts that could help improve the time and energy we spend on our work (e.g. how many families feed the missionaries, number of hours missionaries spend on conversion, retention, etc, averages, means, standard deviation). I apologize if I sound like there would be too much "math" involved, but it's a science we can put to use in this equation. :)
- Embed some "workflow" engine in the app. This means that an "investigator" record could be configured to be "commented" or "reviewed" by a leader (e.g. EQ president, RS president, Bishopric, etc). This could greatly improve the way a WML can view the work on specific families and report back (and quicker) during PEC. There are records the missionaries use (e.g. "Investigator record", "New Convert record", others?) that can be tracked by this workflow engine and have a proper followup (similar to what a issue tracking system would be in software engineering). Once again, this is a reporting feature.
- A Geospatial analysis (based on addresses) can be used to analyze and discover some interesting facts. For example, latest area tracked, percentage of referrals obtained by sector, membership location per investigator capita. This can lead to effectively cover the area assigned by missionaries with coordination from the WML.
- This tools could interact with a remote server for persistence (as opposed to the local drive). This would lead to a web-based integration solution where users (WML) can interact from anyplace (workplace, other home computers, etc). There are a number of known "cons" about the client/server model that would make this issue to be discussed further down the road. I know that when I served in that calling, one of my main problems was that I had to carry my laptop with me all the time. If I were to be at work and I wanted to review my spreadsheet, I would not be able to (if I don't have my laptop with me). Carrying my entire laptop just for that app was probably not an option for me at the time. Now we have Google gadget tools, web-based solutions, SMS solutions that could certainly help out tremendously only if we have a "web-based" support.

Let me know if I can be of assistance and whether there are any features I could start looking to implement.

Thanks!
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#44

Post by WelchTC »

albertoaflores wrote: Let me know if I can be of assistance and whether there are any features I could start looking to implement.
Reports was next on my list. As you can see from the application, there is a "reports" module but it does not do anything yet. I was thinking on using JasperReports as the reporting engine. We could use iReports to create report files.

I love your vision on where we could go with this project. If anyone is interested, we could have a chat session and I could talk about how the program is structured and we could make some decisions on next actions to take.

Tom
JamesAnderson
Senior Member
Posts: 773
Joined: Tue Jan 23, 2007 2:03 pm

#45

Post by JamesAnderson »

This even has application in family history now that there may be multiple consultants in any given unit doing a variety of things, including member visits.

So what may be needing to be done to make it more versatile, is to have a way to set up fields for various positions, and that would allow the user to set up the program based on the position the tracking would be fore, it would be different for missionary, family history, EQ, etc.
User avatar
albertoaflores-p40
New Member
Posts: 6
Joined: Thu Jan 25, 2007 7:28 am
Location: Elkridge, MD
Contact:

#46

Post by albertoaflores-p40 »

Tom,

I would be interested in a chat. I'm typically online (Google-Jabber, AIM, Yahoo) pretty much all day - Easter Time). I can always accomodate my schedule to meet yours.

Let me know!
kgcrowther-p40
New Member
Posts: 14
Joined: Fri May 18, 2007 2:07 pm
Location: Charlottesville, VA

Rules of Data Normalization

#47

Post by kgcrowther-p40 »

Tom, I would like to say that the concept of the Ward Mission Program is excellent. I do seem to have trouble getting it to save the dates that I enter, but I have a larger question that is of interest to me.

The proliferation of data modules and tracking programs across auxiliaries and units of the church seems to be breaking the second laws of data normalization (i.e., delete all data redundancy). (I found a version of the rules for refresher http://www.datamodel.org/NormalizationRules.html) Membership records exist and are maintained annually (usually at the end of the year during tithing settlement). Changes occur across the ward in phone numbers, addresses, names, status, etc. Setting up a system that requires multiple updates each time an object has characteristics redefined seems to introduce additional and unnecessary complexity to a system that should be unburdened with such heavy data tracking requirements.

This has been in on my mind since I first began to feel that a little technology and analysis would help me in my calling. However, I feel so uncomfortable with the duplication of information and the associated burdens to maintain the data in such dynamic wards and missionary environments.

I would like to know how others feel. Entering in information into a full database application can be burdensome over time, but not add a huge benefit over storage in, say, an Excel spreadsheet (or its opensource counterparts) - wherein small macros could be written in VBA (or python, etc.) to generate the reports. Stability, exception handling, and error checking is already built in to such applications. Does this justify the construction of new application? (It seems that it would only if it connects directly to the original data source - membership records)

Tom, I must admit your application is slick, but all the requirements and application details on your web site are technology driven. I don't see a requirements document that details the data and functionality requirements that are independent of a technology, or a rough technology review that demonstrates the cost-benefit advantage to the technology choice - given the available technologies.

Please don't read this post as a criticism. I would just like to bring up the subject of "data and functional requirements before technology," and know how people think about it.

--Kenneth
Charlottesvlle, VA
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#48

Post by WelchTC »

kgcrowther wrote:Tom, I would like to say that the concept of the Ward Mission Program is excellent. I do seem to have trouble getting it to save the dates that I enter, but I have a larger question that is of interest to me.
Yes, dates need to be cleaned up. Right now you must enter in the dates as "mm/dd/yyyy". It is important to put the full 4 digit year. Also, you cannot use dashes (-) between the numbers but must instead uses slashes (/).
kgcrowther wrote:The proliferation of data modules and tracking programs across auxiliaries and units of the church seems to be breaking the second laws of data normalization (i.e., delete all data redundancy). (I found a version of the rules for refresher http://www.datamodel.org/NormalizationRules.html) Membership records exist and are maintained annually (usually at the end of the year during tithing settlement). Changes occur across the ward in phone numbers, addresses, names, status, etc. Setting up a system that requires multiple updates each time an object has characteristics redefined seems to introduce additional and unnecessary complexity to a system that should be unburdened with such heavy data tracking requirements.
I agree. However since MLS does not have a good ward mission module, this has become somewhat necessary. This was one reason that when I created the program, I specifically kept the information about "members" very light.
kgcrowther wrote:Entering in information into a full database application can be burdensome over time, but not add a huge benefit over storage in, say, an Excel spreadsheet (or its opensource counterparts) - wherein small macros could be written in VBA (or python, etc.) to generate the reports. Stability, exception handling, and error checking is already built in to such applications. Does this justify the construction of new application? (It seems that it would only if it connects directly to the original data source - membership records)
I think if someone creates such a spreadsheet, they should tell people about it and share it. I wrote this program because:
  1. I wanted something to help me with my calling.
  2. I enjoyed it. Most open source or free software is written by people because they enjoy the process.
Is there more effective or efficient ways to do the same job as my program does? I'm sure that there are. I'd love 10 ward mission programs or spreadsheets.
kgcrowther wrote: Tom, I must admit your application is slick, but all the requirements and application details on your web site are technology driven. I don't see a requirements document that details the data and functionality requirements that are independent of a technology, or a rough technology review that demonstrates the cost-benefit advantage to the technology choice - given the available technologies.
Yup, you are right. I wrote this for myself and then later decided to share it. I have on my site a "documentation" section that I've been meaning to get to.
kgcrowther wrote: Please don't read this post as a criticism. I would just like to bring up the subject of "data and functional requirements before technology," and know how people think about it.
We need people who are good at gathering and documenting specifications to help out on various projects. For those writers out there, speak up and we can give you some work!

Tom
kgcrowther-p40
New Member
Posts: 14
Joined: Fri May 18, 2007 2:07 pm
Location: Charlottesville, VA

Great Attitude

#49

Post by kgcrowther-p40 »

tomw wrote:I think if someone creates such a spreadsheet, they should tell people about it and share it. I wrote this program because:
  1. I wanted something to help me with my calling.
  2. I enjoyed it. Most open source or free software is written by people because they enjoy the process.
Is there more effective or efficient ways to do the same job as my program does? I'm sure that there are. I'd love 10 ward mission programs or spreadsheets.
Thanks Tom. I think that is a good attitude. And, I must say that I agree. Creating something that is helpful to self and then sharing can inspire concepts and ideas for others to build on, and collectively can lead to major innovation.
kgcrowther-p40
New Member
Posts: 14
Joined: Fri May 18, 2007 2:07 pm
Location: Charlottesville, VA

Collective Functional and Operation Requirements for a Ward Mission Program

#50

Post by kgcrowther-p40 »

I have read through all the comments in this thread and tried to collect the comments into a single outline of requirements for a advanced-generation ward mission program. (Tom's does most of the more critical tasks.) I invite any comments about the priority, necessity / criticality, or potential technology that relates to any of the requirements... Perhaps we can build this list to conceptually create the ideal to provide direction for any technological solutions.

A.Audience
1.Ward Mission Leader
2.Ward Missionaries (to a lesser extend)
3.Missionary Meal Coordinator (if applicable)
4.Missionary Exchange Coordinator (if applicable)
5.Bishopric and Bishopric Representatives (mainly through reports and record updates)
6.Priesthood and Auxiliary Leaders and Their Representatives (mainly through reports)

B.Main Functional Objectives
1.Track investigators being taught in the ward[INDENT] a. Utilize whatever relevant from teaching report
b. Track church attendance
c. Track progress through missionary lessons
d. Active/inactive flag
e. Store address (or lat./long.) of investigators (to compare to tracking areas and population densities)
2.Track new members and new member work
a. Utilize whatever relevant from convert baptism checklist
b. Track progress through new member lessons
c. Track when new members talk in sacrament meeting
d. Track when new members bear their testimony
e. Track church attendance
f. Track fellowshipping efforts
i. Track home teaching and visiting teaching visits
g. Track callings
h. Track plans for temple attendance
i. Store address/location of new members
[/INDENT]3.Track relevant ward efforts with part-member
4.Track relevant efforts with less active families
5.Track relevant missionary efforts with active ward members
6.Track meals for missionaries[INDENT] a. Allow schedule 6-12 months in advance
b. Track locations with respect to evening appointments
[/INDENT]7.Track missionary exchanges[INDENT] a. Allow schedule 6-12 months in advance
b. Future capability to auto-assign exchanges based on objectives and member info.
c. Store locations/address of appointments and members
[/INDENT]8.Enable sharing/collaboration among members of the ward missionary correlation meeting (ward mission leader, ward missionaries, full time missionaries, member of bishopric, representative from priesthood and relief society)[INDENT] a. Simple and intuitive interface
b. Provide reporting capability that passes relevant information
c. Provide specific report for the bishop
d. Flag/alert/report concerns based on tracked information compared to expectation
e. Store reports (or generate reports) for any relevant time frame
f. Export/Import capabilities of databases to standard format (e.g., CSV) for loading most updated member information
g. Export/Import capability of databases with comparison algorithms to identify the most up-to-date information (the ward mission is frequently able to get more updated member information that can be passed to the bishopric)
h. Export/Import capability of calendars to an HTML or iCal file for sharing
i. Potential for coordination with LUWS resource calendar
i. Architecture consistent with church info. systems (LUWS, referral system, etc.) for potential future integration
j. Enable import/export of referrals for sharing across ward boundaries
k. Provide potential for PDA-ready application
l. Graphs, statistics, and trends of various areas that are specified in the ward mission plan to be improved
m. Geospatial reports
[/INDENT]9.Improve performance beyond paper report systems
10.Should phase to a secure web-based technology

C.Major Operational Requirements
1.Should be maintained by Ward Mission Leader or someone permanent
2.Provide technology that could begin to replace functionality of the area book (when missionaries begin greater use of technology in their work)
3.Protect confidential information (e.g., confirmation date)
4.Control sharing of program and program information
5.Embed some workflow aspects to the application so that records/reports (or instances of records) can be passed around without duplication or simultaneous edits
6.Potential integration with a synchronization server (database stored locally, but when Internet connection available it syncs up with across other ward clients)
Post Reply

Return to “Other Member Technologies”