HT/VT Reporting Website Overview

I thought I'd post some screenshots of the HT/VT Reporting System I have been working on. Perhaps they will stimulate some feedback and suggestions.

The system automatically sends e-mails that look like this:



After clicking on the link, the teacher is required to enter his or her e-mail address to gain access to the system. The e-mail address is not included in the link url:



After the user enters the first part of his or her e-mail address, the 'Reporting' screen appears:



continued in next message...

....continued from previous message....

In addition to being able to report, the teacher has the ability to change his or her e-mail address and/or leave a comment for the Presidency. Any comment entered is automatically e-mailed to all Presidency members.

A 'happy-face' shows after submitting if all households or sisters have been visited or contacted. Perhaps a bit cheesy, but a graphic file can easily be changed.

The following report is e-mailed to the Presidency automatically. Fortunately for this EQ President, this is only test data.



Optionally, the Presidency can generate the following report, which is extremely valuable for determining who has been taught and who has not.



Setting a group up to use this system takes less than 15 minutes and once it is set, there is very little that must be maintained by the Presidency. An 'Admin Menu' is available to Presidency Members, providing the ability to manually update a teacher's results and perform other important functions.

The Visiting Teaching portion of this application includes the standard "Letter/Phone/Visits" options when reporting.

I am incredibly excited about this application and its potential. The test results have even surprised me. We have found that even non-technical people can use and benefit from the system. In our testing, we have seen 70% - 90% of Home and Visiting teaching reporting completed automatically without any effort from the Presidency members. The key is to give the teachers the power to report for themselves.

Brad O.

Some wards only require a report from the home teachers for the last month of each quarter. Perhaps you already allow for that option. Great work.

Very impressive.

rickety: Is this true? I never knew that. This is exactly the type of information that I was hoping to receive. I didn't know that anyone did quarterly reporting.

Tom W. asked me to clarify two points:

• The data shown in the screenshots is all fake test data
• The site currently requires that data is exported from the MLS system and uploaded to the website. This is currently against church policy, which is why the site is currently only in testing.

Thanks for the feedback,

Brad O.

rickety wrote:Some wards only require a report from the home teachers for the last month of each quarter. Perhaps you already allow for that option. Great work.

I've never heard of that either...interesting...

rickety wrote:Some wards only require a report from the home teachers for the last month of each quarter. Perhaps you already allow for that option. Great work.

For purposes of refining requirements for the software (and _NOT_ for a discussion on policy), page 169 of book 2, section 1 says, "Each month, home teachers report to quorum or group leaders ..." and later, "The stake presidency receives a monthly home teaching report from the bishop." From page 169, "The bishop receives monthly home teaching reports from the elders quorum president and high priests group leader." and later, "Quorum and group leaders receive monthly home teaching reports from each companionship."

It would appear there is no need for the software to support end-of-quarter-only reporting.

That's good to know. Based on that, perhaps there should be an option to have the system automatically e-mail the Bishop as well? It is already possible to have it e-mail the Bishop by setting the Bishop to an access-level of "Supervisor." However, maybe a special "Bishop" access level should be added that does nothing but e-mail the reports to whoever is designated as the Bishop.

First let me say that this is very cool stuff!!!

I am amazed at what members will do of their own volition. I love it and I respect the time and effort placed in building it.

Second, let me say that I am a programmer and software engineer myself as well as the EQP for my ward. I do not say that to boast for either. It just helps to explain my perpetual curse of feeling like I can contribute.

That being said, I think that I have a few embellishments I would make on the screen shots that I see and you ca decide what if anything you want to do with them.



Sorry it's big...here are my thoughts:

Details column would be a link to more details.

As an EQP, I would not only like to know if a family was visited, but when (Is it all being done at the end of the month?) also what kind of visit (Did they just call?, Write? Show up?)

I would also like to know whether or not a lesson was given or the family has needs.

I have eliminated the notes box from your screen shot to avoid getting information saved that is confidential and replaced it with a simple checkbox requesting a PPI.

I know that a lot of this is California Dreamin' (I'm in NorCal) but I usually ask my hometeachers those questions anyway...those are my thought right now.

On a side note...are you making this available to anyone to run locally for fun? It doesn't hurt to ask...

Mr. M

I should also not that the new information that I have added would stimulate more reports, including trending (Are people calling more than visiting? Are fewer families getting lessons?) I think those things are very important when trying to figure out what is going on with families?

I also have one other embellishment that is pretty simple. You could add this URL as a link from your family name with the appropriate address information filled in:

maps.google.com/maps?q=50+W+North+Temple+Salt+Lake+City+UT

This would allow simple mapping of that families address using Google.

Just another thought.

If I’m not mistaken, quarterly VT reports are required. (If memory serves me well, we were to cut our visits to 10-15 minutes and less frequency back in the 1980’s. I lived in Hawaii at the time and my Hawaiian RS President was sooooo disappointed over that news. In that culture, such a brief visit would be downright rude, too.) However, every place that I have lived seems to continue monthly reporting. Part of this may be tradition, but I’ve also had RS presidents who felt that quarterly contact was just too infrequent. Note that I have never lived in a truly rural area where ward boundaries are enormous.

On the software ideas:
First, I think that it’s a great idea! Not everyone would use it, but as people more comfortable with technology mature, the participation will increase.

• As a visiting teaching supervisor, I have generally made sure that everyone in my district was visited at least quarterly (if they were agreeable to a visit). I have had occasions where I did all of the monthly visits that were not done by the 20th of the month because 1) several of the visiting teachers were not very active in church, 2) there was a great need for people to be visited in our young military ward, and 3) I was able to make the time to do so. I separately report the visits that I made from those of the assigned visiting teachers. It would be helpful to designate if the teacher was the supervisor or the assigned visiting teachers.
• Our area would need area codes on the chart, too.
• Full addresses, including zip codes, would be handy. (This may already be in your program, but I don’t recall seeing it.)

Addresses are currently not stored in the database since this information is not exported with the "Copy to File" command in MLS. Doing anything with addresses or any other additional data would require changes to the MLS system in addition to this HT/VT Reporting application.

scion: Area codes would show up if they were entered in MLS as such.

I like your thoughts, Mr. M. I have a couple comments.

First of all, I didn't think a "Phone" or "Letter" contact was ever counted as "Visited" for Home Teaching. For Visiting Teaching, "Phone" or "Letter" can be counted as "Contacted." This application allows the teacher to select VISITED, APPOINTMENT MADE, or NOT VISITED for Home Teaching and VISITED, PHONE CONTACT, LETTER CONTACT, or NOT CONTACTED for Visiting Teaching. I don't think a household can be marked as Visited when a Phone contact has been made, for example.

Secondly, when putting this site together I was trying to keep it as simple as possible. When the teacher has more checkboxes and comboboxes to select, in my opinion, it complicates the reporting process. I think it would be nice to optionally allow this type of data to be requested, however, the critical data is whether or not the household or sister has been taught. As the site is now, I think it covers the 'Visited" and "Visited Type" columns.

Finally, I have seen it being extremely valuable to have an open-ended comment box. This has proved to open a new line of communication between the teacher and the Presidency. There are plenty of useful comments that can be delivered to the presidency this way such as, "this person has moved," or "this person needs help moving", or "this person no longer wishes to be contacted." These comments are e-mailed to the presidency, which is basically the same as if the teacher directly e-mailed this information to the presidency.

Below is a screenshot of the Administrator's Menu for the application. It will give you some idea of what the Presidency is allowed to do. If a teacher is set to a "Supervisor" access level, only the first 5 options are available.

The address is in column 11, 12, 14, 15 16 in the Membership.csv file
that is exportable from MLS.

As far as visits, the area we are in we have more families than priesthood holders and the stake and our bishopric has made phone and mail assignments. Each home teaching companionship has two visit families to visit monthly and then a couple families that they have to call or mail with a visit quarterly. There are three stakes in this area that do the same thing, it was given to us by a GA in our stake conferences. It was taught as home teaching triage. Those members that are borderline need visits every month, those that are active get phone calls, those that are NOT active at all or disinterested get letters. Both of the latter get visits each quarter.

That is part of the reason I would want to track all that information to see the effectiveness levels of each type of visit.

Also as a point, for software to be used by everyone we need to take into consideration that different areas do things differently to make an application effective it needs to handle the least common denominator.

Again, I appreciate your hard work, it has definitely opened the door to some great ideas.

I see.... I was not aware of some of these exceptions. I agree that the application needs to be able to handle the needs of the church as a whole, but my only point was that certain enhancements need to be configurable as it seems that most wards are handled by the book (at least those that I've seen).

Those are great ideas though... they have certainly got me thinking.

The problem with the Membership file is that it requires special access to export it. I know that I've never had access to export that file in our ward's MLS system. This is why I have had to resort to a file that is easily exportable by any MLS user... this being the "Copy to File" option within the Home/Visiting Teaching section.

Brad O.

brado426 wrote:First of all, I didn't think a "Phone" or "Letter" contact was ever counted as "Visited" for Home Teaching.

Correct. However, wouldn't it be a good idea to at least be able to notate that a "non-count" contact was made as opposed to no contact at all?

You may also want to think about other exceptions such as members who have requested "no contact". In those cases, notating that post cards or bulletins have been mailed. Just because it doesn't count in the stats doesn't mean it shouldn't be done. And the knowledge that it's done and can be reported to leaders is useful to the church's primary goal.

Very good points, Russell.

Adding those additional options so that they would not count in the statistics would be extremely easy. But, would having those options available make some teachers think that a phone or letter is good enough and therefore not make an additional effort to visit? For Visiting Teaching, the church specifically asks for "phone" and "letter" options. However, for Home Teaching, the only requested information is "Visited" or "Not Visited."

My concern is that the church must have a reason for gathering different statistics from Visiting Teachers than Home Teachers. Since these guides were set up by the church, this is probably a question that only a church authority could answer.

You are right about being able to indicate any situations where contact was made but for reasons sometimes even beyond the control of the home teachers they were not able to do a visit one might call 'by the book'.

Here's an example from my experience. I've seen alot of similar situations in ten years of working with home teaching in elders quorums and high priest groups.

Let's say I had five families, and families A B and C were visited. But I only had a phone contact with family D due to their being out of town much of the time and family E doesn't let home teachers in but I am able to leave a note.

What would be the best way to record that type of matter if you were able to notate those in this proposed software?

brado426 wrote:But, would having those options available make some teachers think that a phone or letter is good enough and therefore not make an additional effort to visit?

I agree with the concern. I think that a careful screen setup could make that clear. Perhaps coloring the "non-contact" contacts differently. If not, then when the user sees their own stats, they should get the message.

brado426 wrote: My concern is that the church must have a reason for gathering different statistics from Visiting Teachers than Home Teachers. Since these guides were set up by the church, this is probably a question that only a church authority could answer.

I'd love to know the answer myself. But since this is a tech forum, I think we'll have to settle for treating HT and VT differently. I think the screens could be quite similar but using color or shading to note the difference in policy.

RussellHltn wrote:Perhaps coloring the "non-contact" contacts differently.

Perhaps something like the following:

Home Teaching:
Green - visited in person and delivered a message
Yellow - mailed letter, contacted by phone, or talked briefly at the front door
Red - no contact made

...and then something similar for Visiting Teaching. Any of the green options would be considered a "counted" visit; the other options wouldn't be "counted," but would signify if any attempt was made at all.

mkmurray wrote:Perhaps something like the following:

Home Teaching:
Green - visited in person and delivered a message
Yellow - mailed letter, contacted by phone, or talked briefly at the front door
Red - no contact made

That's one possibility. I was thinking more along the lines of coloring both the non-contact and non-counting contact the same. Or maybe more closely the same (light red instead of yellow?) The same color would communicate "same status" while everyone would hopefully understand that it's better to have shown some contact then none at all.

mkmurray wrote:Perhaps something like the following:

Home Teaching:
Green - visited in person and delivered a message
Yellow - mailed letter, contacted by phone, or talked briefly at the front door
Red - no contact made

For those of us who are color-blind, an alternative to color coding would be helpful. Usually an icon or a shape in addition to the color is sufficient.

-Hyrum

HPaulsen wrote:For those of us who are color-blind, an alternative to color coding would be helpful. Usually an icon or a shape in addition to the color is sufficient.

-Hyrum

Excellent point.

HPaulsen wrote:For those of us who are color-blind, an alternative to color coding would be helpful. Usually an icon or a shape in addition to the color is sufficient.

Wouldn't shading (making sure that the colors are not the same intensity) do the task? Granted, it wouldn't communicate status quite the same, but it would indicate grouping.

RussellHltn wrote:Wouldn't shading (making sure that the colors are not the same intensity) do the task? Granted, it wouldn't communicate status quite the same, but it would indicate grouping.

Yes, shading works. However, because I never developed the memory capacity for colors, shading does not stand out to me as do icons, patterns, and shapes. I could probably use the program for months before even noticing that there is a shading difference.

Another possibility that is easier than adding icons to drop-down boxes is to add groupings in parentheses following the visit type, e.g. "Phone contact (not counted for HT)", "Visit (counted for HT)".

Ahh...but there are those of us who do count it....

Maybe it would be helpful to manage visit types at the user lever and add a field that tracks whether or not a specific type of visit is counted.

I don't think that we can set standards for by the book or not as the program's logic won't be able to automatically adjust for inspiration, where a bishop or stake president says to count it, etc.

If we could toggle the types of visits and also whether or not they were counted that wouls allow us to make changes dynamically in cases of differing guidelines. It will also allow us to change later in a ward that has been doing it one way and gets a different directive later.

Hey, combine that with the color coding and we can even assign our our colors to each one. it wouldn't be that hard to do, it could all be tracked with user preferences.

Mr. M wrote:I don't think that we can set standards for by the book or not as the program's logic won't be able to automatically adjust for inspiration, where a bishop or stake president says to count it, etc.

If you're talking about reports for the bishop or stake president, that's fine. But most of us follow the guidelines for reporting back to church headquarters and I don't think the guidelines allows for such inspiration. Certainly that would have to be reviewed at a higher level before that feature is added to the program.

Personally I think the 3, 4 or 12 month chart that shows visit history and gives different indications for the type of visit would work well. The numbers don't always tell the story. A companionship that always misses 1 out of 5 assignments, but rotates the missed family is different then a companionship that consistently misses the same family.

The leader is free to read the chart as they wish, but the hard numbers confirm to CHQ's instructions.

RussellHltn wrote:If you're talking about reports for the bishop or stake president, that's fine. But most of us follow the guidelines for reporting back to church headquarters and I don't think the guidelines allows for such inspiration.

I know I am a new member to these forums and i don't want to ruffle any feathers but I don't question my leaders inspiration or the general authorities that ask us to count calls and letters as visitis in specific circumstances. I would ask that we focus on the the technologies ability to handle different ciircumstances and not bring our personal judgements of others inspiration into these forums.

Thank you.

Mr. M wrote:I would ask that we focus on the the technologies ability to handle different circumstances and not bring our personal judgements of others inspiration into these forums.

Flexibility is one thing, but I'd have a big problem with programs that would openly allow the system to function outside of published guidelines. At least not without review of the appropriate leaders. Perhaps there would be a "secret switch" that on approval of the proper GA, the reporting guidelines would change. I don't have a problem with allowing the underlying infrastructure to deal with such a case. It's when it's openly allowed in the preferences I have a problem.

This is not new. Try calling a Priesthood holder as the Primary President in MLS and you'll see what I mean. But that restriction is in accordance with the instructions found in the GHI.

Tom: since this borders on policy, some general guidance on the subject would be appreciated. To what extent should the technology we develop follow or not follow the guidelines? In a worldwide church which experiences a wide range of conditions there may well be exceptions. I'm guessing that it will have to be reviewed on a case by case basis, but some general statements would still be appreciated.

I guess I need to disable that MLS hack that fires the 15th of every randomly selects families and marks them as visited to keep my numbers between 76 and 87 percent.

Mr. M wrote:I guess I need to disable that MLS hack that fires the 15th of every randomly selects families and marks them as visited to keep my numbers between 76 and 87 percent.

Really! No one would believe that. It needs to be set to the 30/31st.

Mr. M.,

I really liked your suggestion to have a checkbox for scheduling an HT/VT interview. I liked it so much that I added that feature tonight. If you check this box, it now e-mails the Presidency so that they know to schedule the interview with you.

To keep the application flexible, this option can be disabled in the "System Settings" menu.

I like the ideas about shading, colors, and "Phone" and "Letter" contact options that don't count, but I think enhancements such as these would require some more discussion.

Brad O.

RussellHltn wrote:Really! No one would believe that. It needs to be set to the 30/31st.

Actually you need to implement a little uncertianity here because there are those that will get it done at the beginning of the month (low probability) and as the end of the month approaches the probabily increases until the last day you get 80% done. And of course Sunday's have higher probabily then weekdays.

Given that some wards cover many square miles and some are in areas where transporation & communication are not as readily available as in most US metropolitan areas, it seems to me that tracking all types of HT contacts is important. Although I have never lived in a very rural place as an adult, I can see the need for this. When I lived in a military ward letters were considered contact for servicemembers who were away for most or all of the month. My understanding is that those letter contacts were included in reports as contacts. Perhaps they included a note indicating these special circumstances, but I don't know for sure.

With the design of this application, the logic contained within the report is the only thing that determines whether a visit-type is counted or not. This can be changed to abide by whatever rules were decided upon by the church. If the church allowed some variance to these rules, we could easily add a configuration option that allows the Presidency to change the behavior of the report.

As it is currently,

For Home Teaching:

Visited - Counted
Appointment Made - Not Counted
Not Visited - Not Counted
Not Reported - Not Counted

For Visiting Teaching:

Not Contacted - Not Counted
Visited - Counted
Phone - Counted
Letter - Counted
Not Reported - Not Counted

Teachers have the ability to report multiple times a month. So for example, if a Home Teacher reports on the 8th or 18th of the month and marks one of his households as "Appointment Made," he is supposed to go back in at the end of the month and specify whether or not they were able to visit that household. If the teacher does not return to update this status, it is up to the Presidency to acquire that information.

Teaching companions also have the ability to report. So if a companionship has to split up during one month due to scheduling issues, each can report for the household that they have visited.

Brad O.

RussellHltn wrote:Tom: since this borders on policy, some general guidance on the subject would be appreciated. To what extent should the technology we develop follow or not follow the guidelines? In a worldwide church which experiences a wide range of conditions there may well be exceptions. I'm guessing that it will have to be reviewed on a case by case basis, but some general statements would still be appreciated.

Well I would suggest that people review their handbooks and talk with their leaders about how things should be counted. As far as the software is concerned, I believe that it should stick with what the handbook states and if there are exceptions programmed in, it should be clearly marked as exceptions and again refer people to their leaders and the handbook. The fear is that if people see an option on software then they believe that the option is to be used...even if the feature was meant to be an exception.

Tom

tomw wrote:The fear is that if people see an option on software then they believe that the option is to be used...even if the feature was meant to be an exception.

Exactly.

Thanks!

RussellHltn wrote:Really! No one would believe that. It needs to be set to the 30/31st.

What about February? Would you really want your percentages going to zero every February?

rmrichesjr wrote:What about February? Would you really want your percentages going to zero every February?

Hmm, thus the probabilistic approach would be most effective.

rmrichesjr wrote:What about February? Would you really want your percentages going to zero every February?

Ok, ok. So one would have to come up with the number of days left in the month function so that it would trigger on the proper day. :rolleyes:

Hmm how about straight submission to the clerk's computer. If the computer is on a dedicated line you could use a free dynamic dns provider like DynDNS or another one (DynDNS is not affiliated with the church and I haven't personally used it very much either) and set up the computer using the free personal web server that comes with Windows XP. You would only have to open port 80 and then the data would stay only on the computer that is was suppose to be on.

Personally this is just an idea being put out there, I don't know what church policy is on this and this might cross the border of having sensitive information "out of church control."

thedqs wrote:Hmm how about straight submission to the clerk's computer.

Personally I wouldn't be comfortable with that. I'd assume anything on the DDNS would be probed and possibly attacked. Plus all the issues of having to leave the ward computer on in an environment that may or may not be friendly to that kind of thing

What about doing this via email forms? The leader sends the customized forms to all members. They fill them out and email them back. Later submissions supersede earlier ones for the same month. There's still the issue of how to input this into MLS as I don't think it provides anyway to do that.

I know that MLS has a e-mail type system built in. Is there an external address that maps to it? Then you could have all the submissions go to the MLS account and a program which updates the account based on the email recieved.

I'm not sure exactly what problem you guys are trying to solve. Sending data via e-mail is probably the most insecure way to send anything via the Internet.

This HT/VT Reporting site uses SSL encryption, which is the same security method implemented by most banks and other sites that require secure client to server communication. In my opinion, submitting results via SSL is far more secure than sending anything via e-mail.

Setting up some sort of connection into the Clerk's computer from the outside is a huge "no no." I would not recommend that as it would be extremely unreliable and render the PC insecure.

I believe a reporting system such as this needs to run on a centralized server that is backed up and reliable in a data center. I do not see any way around a central database for something like this.

Brad O.

brado426 wrote:Setting up some sort of connection into the Clerk's computer from the outside is a huge "no no." I would not recommend that as it would be extremely unreliable and render the PC insecure.

Exactly. And that's why I proposed the email route since it would be a common denominator and wouldn't open up the ward PC to outside attack. As for email being "insecure" I think we need to define the concern. If it's the possibility that the information will "leak out", that's possible. But are we collecting/disseminating enough information in a email packet to be concerned about the risk?

I agree a central server is the best way to go, but unless the church decides to do it, I don't see it happening.

I guess the real question that needs to be answered is what are we wanting to do? Create a setup that can actually be used by a ward/stake? In that case it needs to be within the reach of ward/stakes to implement. (And setting up a secure central server probably doesn't meet that criteria.) On the other hand, if we're trying to model a setup for the church to use as a "head start" for building their application, that's a different story.

Russell: I agree with your synopsis of the situation. I believe that in order for a system such as this to become a reality, the church would need to get behind it.

I am uncertain of exactly what the future of this system is, however I believe in it and I hope to see something become of it. My intent is not to create something that can be provided to every ward today... especially if it means that the functionality of the application would be negatively affected.

My point regarding e-mail security isn't that we shouldn't be using e-mail at all. This web-based system uses E-Mail to contact the teachers for results. My point is that if we are going to go as far as setting up a reporting system, let's keep it as secure, simple and feature-rich as possible. Going with an "E-Mail Only" reporting system would require sending actual data via e-mail (a practice that I am not especially keen on) as well as decreasing and, in many cases, eliminating many of the benefits the system currently provides (I'll spare you the specifics for now ) In my opinion, the best way to do this is with a centralized website as this reporting system has been designed. Even if this design is currenly not in accordance with church policy, I still believe it keeps things as secure and simple as possible while providing some seriously powerful features. On the other hand, I fully understand why church policy is as it is and I even agree with it.

I think something will happen to make this possible one day.... I just don't know the what's, how's, and when's.

Brad O.

Best idea is to develop what you have make sure it works and have the church take it from there. The site scriptures.lds.org and the LUWS were basically done that way and that way your program gets the resources that you are wanting to run it on (dedicated server, SSL, etc.)

tomw wrote:Well I would suggest that people review their handbooks and talk with their leaders about how things should be counted. As far as the software is concerned, I believe that it should stick with what the handbook states and if there are exceptions programmed in, it should be clearly marked as exceptions and again refer people to their leaders and the handbook. The fear is that if people see an option on software then they believe that the option is to be used...even if the feature was meant to be an exception.

Tom

I completetly agree...we should review our handbooks and do what our leaders ask us to including the counting of our visits. Which is exactly what we are doing.

Thanks Tom!

Mr. M wrote:I completetly agree...we should review our handbooks and do what our leaders ask us to including the counting of our visits. Which is exactly what we are doing.

Thanks Tom!

If this does ever get official Church sanction and resources, I think providing availability for exceptions clearly marked as exceptions and only available to proper levels of authority (stake with GA review, ward with stake review) before enabling would be in order. The plain vanilla would then only show the official handbook options.

brado426 wrote: I think something will happen to make this possible one day.... I just don't know the what's, how's, and when's.

I've been talking and working with Brad since the first of the year. The application is being reviewed here at the Church. I've discussed the idea with senior managers within the proper organization. It just takes a long time for us to get something like this going because of the huge workload we are already working on. So the further along a concept is, the faster the Church can implement it should we choose to do so. Keep up the great dialog.

Tom

Does anyone know if the Home/Visiting Teaching assignments list is uploaded to Salt Lake via the MLS system? Or are only the results sent?

Brad O.

brado426 wrote:Does anyone know if the Home/Visiting Teaching assignments list is uploaded to Salt Lake via the MLS system? Or are only the results sent?

I think the answer is .... both.

I think only the stats are passed along to the stake and CHQ.

But, CHQ also makes a backup of each unit about every 30 days.

RussellHltn wrote:I think the answer is .... both..

If this were the case, it would be great. This system, of course, needs to have the latest "HT/VT Assignments List"

1. Presidency makes necessary changes to HT/VT assignments within MLS at the ward

2. Presidency triggers upload of HT/VT assignments to Salt Lake

3. The process in Salt Lake that imports the uploaded data sends a copy of the HT/VT assignments list to the HT/VT Reporting Web system.

4. Once all reporting is complete on the HT/VT Reporting Web system, Presidency can click on a button to transmit results data to the main church database (the database where results are fed from MLS today.)

This eliminates any importing/exporting of files from the MLS system. It also eliminates any data entry of HV/VT results from the website to MLS.

Of course, none of this could be done without making changes to the church back-end systems, but I think these changes would not be too major. I don't think it would require any changes to the MLS system installed on ward PCs.

Brad O.

I agree it should be do-able, but it's something it seems the church will have to do on it's own.

At this point all I can suggest is that you make the program usable for your stake on your servers and once you've got a fully functional system, then you can share the code with the church so they can speed the development along. With that in mind, you may want to emulate the look and feel of the official website - not close enough to create confusion in anyone's mind, but emulate the style at the program style level to make it easer for the developers to adapt it.

RussellHltn wrote:I agree it should be do-able, but it's something it seems the church will have to do on it's own.

Absolutely.... I'm just contemplating what would be possible if it was integrated with the church's systems.

RussellHltn wrote:At this point all I can suggest is that you make the program usable for your stake on your servers and once you've got a fully functional system...

We do have a fully functional system. I have at least two tasks that I know would need to be completed before the church could use the system. However, both tasks require guidance and specifications from the church.

Brad O.

Thanks for the suggestions, folks. One of the people currently testing the site just recommended a change that I really think is worthwhile.

We've changed wording of "Visited" to "Visited With Family" and added a new option entitled, "Attempted." The "Attempted" status is really the same thing as "Not Visited" but it is necessary to clarify to the teachers that there is a difference between visiting with the family and attempting to visit with the family.

So now we have:

For Home Teaching:

"Visited With Family" - Counted
"Appointment Made" - Not Counted
"Not Visited" - Not Counted
"Attempted" - Not Counted
(Not Reported) - Not Counted


For Visiting Teaching:

"Not Contacted" - Not Counted
"Visited With Sister" - Counted
"Phone" - Counted
"Letter" - Counted
"Attempted" - Not Counted
(Not Reported) - Not Counted

I like the addition of "attempted visit". At one time, I was assigned to visit an inactive member who did not answer the phone when I called, did not return voicemail, did not respond to mail, and did not answer the door when I dropped by her home. In addition to reporting to my supervisor, I contacted the RS president after several months of failed attempts. She reviewed her records and found that this person had allowed VT contacts in the past, but they were all old timers in the ward who knew her from years ago. The additional information led to a switch in VT assignments to someone with whom this sister felt comfortable. Attempted provides more feedback to the leadership than no visit.

I made the suggestion to include other types of visits and mark them as counted. I would still encourage the addtion even if they aren't counted with a report breaking them out. I think we got hung up on what's official to count or not and missed my point.

It is just as important to me as the EQP to know a family was called or sent a letter as anything else is. To say that a family was visited or not for numbers is fine. But HT isn't really about numbers. I can counsel my hometeachers to do their "visits" monthly as prescribed in the handbook and turn in numbers for that. Nothing would stop a home teacher from selecting "VISITED WITH FAMILY" for what they considered a visit (even if it was a phone call). However, if they had other options to select like phone call, I would know what REALLY happened with the family and EQP or HPGL not the home teacher could decide what counted.

One more thought would be to make a log for the family, instead of a single entry type selection...What if you visited a family multiple times in a month...for numbers you would only need one entry but for a resource tool you would want to know all entries.

True Scenarios...
A family lost a dad has multiple children...the VT provide dinners and child care for two weeks...HT visit daily or every other day to check in do chores etc. EQP wants to track that because it could explain why another family of that HT only got a phone call. (By the handbook neither would count as visited technically because no lesson was taught...but I would still want to know what happened with them.)
This would display as multiple entries for a single family, instead of one log as visited.

A family is preparing to go to the temple to be sealed and the HT was asked to go with a lesson twice a month. I would want to track that also to report back to the Bishop on the assignment. (This would count as visited and would show two entries a month.)

My concern isn't whether the Phone/Letter contacts are counted or not. My concern is that when the Home Teacher reports, will they see the Phone/Letter contact options and think, "I'm not going to go through the extra trouble of visiting this month because I can just do a phone or letter contact?" For Visiting Teaching, the church encourages Visits, but also encourages Phone/Letter contacts. For Home Teaching, Phone/Letter contacts are not mentioned as far as I know.

I see your point, Mr. M. and I agree that it would be good information for the Presidency. I guess I'm just not comfortable enough that the church would approve of gathering phone/letter contacts for Home Teaching. Ultimately, I think the church needs to make this decision. We talked about possibly color-coding to make it clear of what was expected of the Home Teacher, but I'm still not certain of how this should be handled.... at least not certain enough to begin making any additional changes.

I think the "Attempted" option is excellent and does not stray from church guidance. Mr. M., sorry I forgot you had also mentioned that option earlier. I guess it took two people to bring it up for me to get me to realize how great of an idea it was.

Brad O.

Two things:

First:

If the Church has IIS/.NET applications in-house, what database is being used for them? MS SQL? MySQL? I was thinking about switching this application's database to whatever the church used.

Second:

Below are some suggestions that were recently sent to me that one of the HT/VT testers has come up with and my replies to them.

I think I will add #2 as I have thought about doing that for some time. #3 doesn’t make much sense to me. I guess I need to ask him why he cares about a per-district percentage. #1 is too complicated for now and I think this is an exception that most people would not want.

One thing that has surprised me in working on this project is that each ward tends to handle their Home/Visiting teaching a little bit differently, which is why I had to add all these System Settings checkboxesto to allow the Presidency to enable and disable certain behaviors and features.



It doesn’t look as though it is possible to come up with one solution that works for everyone. The “System Settings” checkbox list continues to grow as these variances become apparent.J

E-Mail from tester below. My reply comments are bolded:

Brad,
We have been testing the system for 2 months.We have a couple of questions and
suggestions:

1. The notes that a home teacher sends in, can each note be combined and
forwarded on to someone like the Bishopric?

If you’re using an e-mail program like Microsoft Outlook, you can highlight all the comment e-mails and click forward to send them to the Bishop. The application does not currently have a way to combine and forward to the Bishop automatically.

If you’d like the HT Report to go to the Bishop automatically, you could always set his access level to Supervisor. For your Elders quorum where the Bishop is not on the list, you can simply add the Bishop to a lone companionship in MLS, upload to the website, and set the Bishop’s access level to Supervisor.

2. Is there a way to send group emails? Also, is there a way to send an
email only to those who have not reported their home teaching results?

These are both options I have thought about implementing but haven’t gotten around to yet. We’ll see.J

3. At the end of each district on the monthly report is it possible to have
the number of families in each district and the % of families that were HTed
in that district?

This is certainly possible. I’ll add this to my list.

4. Does the link have to expire each month? Some people copy the link and
paste it in their browser, but it seems to expire monthly and so they have
to keep going to the most recent's month email.

The links are designed to expire for security reasons. They expire on the 15th of the next month. For example, May’s links will expire on June 15th. This gives the teachers plenty of time to report after the end of the month. Remember that the links are coded for a particular month... you cannot use May’s link to report for June, so you always want to access your reporting page with the link that was most recently e-mailed to you.

brado426 wrote:#3 doesn’t make much sense to me. I guess I need to ask him why he cares about a per-district percentage.

Our elder's quorum secretary makes spreadsheets and charts per district. I personally think it would a great addition to be able to break down the reporting that way. It's helpful for the presidency and to the district leaders themselves. They need to know when there is a lull and extra encouraging may be needed.

Also would add some "competition" to Home Teaching. All in fun of course.

To analyze the district stats correctly, the program should follow Nelson rules to determine which are out of process and which are just part of the normal system. (Hey, if you're going to manage by numbers, do it correctly!)

I didn't think anyone really used those....lol.

RussellHltn wrote:To analyze the district stats correctly, the program should follow Nelson rules to determine which are out of process and which are just part of the normal system. (Hey, if you're going to manage by numbers, do it correctly!)

Mr. M wrote:I didn't think anyone really used those....lol.

Sadly, too many managers don't use those ..... when they should.

The sample size in a ward is probably too small to really put those in use, but the basic concept is still valid - too many attach significance to a change in the number when it's really meaningless.

brado426 wrote:Two things:

First:

If the Church has IIS/.NET applications in-house, what database is being used for them? MS SQL? MySQL? I was thinking about switching this application's database to whatever the church used.

We use Oracle quite a bit here. Most of our Web sites run out of Websphere. We may have some IIS deployments but I believe that they are rather small at the current time.

Tom
[/font][/color]

First of all I want to complement brad0426, the site looks great.

My mom is currently in the RS presidency of a rural ward; her ward has had a lot of move-ins and move-outs lately, so now they are working on reorganizing VT routes. One of the biggest problems they have is finding people with compatible schedules and that live relatively in the same area to match up.

I think it would be a great addition to this app if there were a part that would help organize VT/HT routes.



You could use the Google Maps API to show where each member lives. Color coded or different icon markers could be use to indicate if the household currently has a VT/HT. Allow for a filter option to view different availabilities (am/pm; Mon,Tue,W,T, F).



Rich

marlattrj wrote:First of all I want to complement brad0426, the site looks great.

My mom is currently in the RS presidency of a rural ward; her ward has had a lot of move-ins and move-outs lately, so now they are working on reorganizing VT routes. One of the biggest problems they have is finding people with compatible schedules and that live relatively in the same area to match up.

I think it would be a great addition to this app if there were a part that would help organize VT/HT routes.



You could use the Google Maps API to show where each member lives. Color coded or different icon markers could be use to indicate if the household currently has a VT/HT. Allow for a filter option to view different availabilities (am/pm; Mon,Tue,W,T, F).



Rich

I was thinking along the same lines per the Google API. Kevins Google API for plotting the entire ward could easily (with his permission) be incorporated into the HT/VT site.

marlattrj wrote: I think it would be a great addition to this app if there were a part that would help organize VT/HT routes.

You could use the Google Maps API to show where each member lives. Color coded or different icon markers could be use to indicate if the household currently has a VT/HT. Allow for a filter option to view different availabilities (am/pm; Mon,Tue,W,T, F).

Rich

Excellent ideas, Rich. Home addresses are not currently stored within the system, but that could change one day. I also like the availabilities suggestion... We could add a drop-down on the reporting screen that allows the teacher to specify their availability window when reporting.

I have added the "District Total" feature that was suggested. Each District now shows a total at the end:

Is there a reason not to allow the admin to define visit types, and determine which count as a visit and which do not?

I envision a screen where I can define a new visit type, and then select count / not count.

The Earl wrote:Is there a reason not to allow the admin to define visit types, and determine which count as a visit and which do not?

I envision a screen where I can define a new visit type, and then select count / not count.

This topic has already been discussed somewhere...

I think the idea was that allowing such flexibility would cause some to feel they also have the flexibility in how it is reported to the bishop and the CHQ. There is a standard policy for what should be counted for HT and VT, and this website should stick with that policy. Exceptions to the rule are to be made in few circumstances, and at the decision of local leadership consulting the Handbook. I don't think this website should be built for the exceptions; however, if it is, it shouldn't be something customizeable by just anybody.

Now, there's a difference between an EQ president wanting to see reports that breakdown what is officially "counted" differently than the standard, but that should be independent of how it is officially submitted.

In testing this site, I have found that it really needs to be kept as simple as possible... this is a system that technical and non-technical people will be using. When you provide too much functionality, the non-technical users will still try to utilize the advanced features and get confused. In my opinion, the functionality of this system in particular needs to be mostly preset and only allow changes in system behavior where absolutely necessary.

I have received several compliments from testers expressing how happy they were with the system's current ease of use. I have also heard concerns that adding additional features could make the system more complicated. A well known rule in technology is that "with flexibility comes complexity." I think it is absolutely critical that this system in particular is kept simple because of the wide-range of user experience.

As an example, at first I allowed the Presidency to schedule the automatic status-request and report e-mails to be sent on whatever days in the month they wanted. Although this provided some serious flexibility, it was a disaster and caused confusion for the users. I changed it so that it now has four pre-set schedules that can be selected. The schedules notify the teachers once, twice, and three times per month and pre-set days. This proved to make things far simpler and it really did not negatively affect the overall benefits of using the system.

Brad O.

I like the ease of use, and agree that this tool needs to be accessible to all. Absolutely, the default install should be 'by the book'.

Would it be possible to put things like the visit types and email dates in a config file? That would allow customization by those that wanted to get their hands dirty, as well as easy internationalization.

I tend to build my systems with the complexity that I want, and plan for, but I am known to hide certain configurations outside of the main UI so that I can tweak things easily if I need to.

Just a thought

What you are asking is certainly possible. I agree that there will need to be different visit types for globalization reasons.

As we were discussing earlier, the Church will need to set the guidelines as to what Visit types were available and whether they could be modified. Perhaps there could be some preset selectable sets of Visit-Types that could be selected by the Presidency. I'm thinking that it probably wouldn't be a good idea to let people type in whatever Visit-Types they want.

The Earl: What customized Visit Types are you thinking of?

Brad O.

One point I wanted to make. While some visit types could be useful information, some may be wanted just to make people look better. For example "attempted" looks better then "not visited". But how much information does that really convey to the leader? (How hard did they try? Probably not hard enough if that's all the better they can report.) Does it justify the complexity it adds?


Another thought I'd throw on the table: "refused". Yeah, I know, I'm adding complexity. But I think it would be useful information to know that. The problem is differentiating between "we couldn't come to an agreeable time on the 31st" (scheduling failure) vs. "they told us to go away" (what I'm really trying to capture). Although .... Maybe that's something for "Notes". Since I doubt someone would change on a month by month basis. However "refused" could be used for optional local stats to tell the local leaders what percentage of willing members they are able to visit. Just thinking out loud here.

Russell,

One of the individuals that suggested the "Attempted" option is helping test the site. He found that his teachers needed this option because they were getting confused about the difference between "Attempting" a visit and actually "Visiting." For example, Visiting the home and knocking on the door could be looked at as a "Visit." This is why we changed "Visited" to "Visited With Family" and added the "Attempted" option.

I think you're right.... being able to mark "Attempted" does make people *FEEL* better. All we can really do is make best-guess decisions and try to figure out what works until the Church provides some guidance.

Brad O.

I spent some time last weekend and this weekend redesigning the manual E-Mail features of the system and adding some useful new features.

The following E-Mail Options menu now appears for the Presidency if a teacher has a configured e-mail address:



Send Request for Results – Sends a request to this teacher asking him or her to report for the month.

Send Request for Results With Comments – Allows you to enter a customized comment with the request. The ‘link to report’ will show up as <LINK>, which you can reposition anywhere within your text.

Send Request for Results to ALL Not Reported – I think we have received more requests for this feature than anything else! This option can only be used between the 1st and the 7th of each month. This will send a report request to all teachers that have not yet reported. To prevent multiple Presidency members from triggering this process several times during the same month, it is only allowed to be triggered once per month. If, for any reason, a Presidency needs to resend these report requests, one can allow this by un-checking a box in the System Settings menu. This option is only available to Presidency Members and is not available to Supervisors.

Send E-Mail to this Teacher – Allows you to enter a custom e-mail to the selected teacher

Send E-Mail to this Companionship – Allows you to enter a custom e-mail to the selected companionship

Send E-Mail to ALL Teachers – Allows you to enter a custom e-mail to ALL teachers that have configured e-mail addresses. This option is only available to Presidency Members and is not available to Supervisors.

Send Request for Results to Companionship – This option automatically sends a request to all teachers within the companionship to report for the month.

Send Request for Results to Companionship w/Comments – Allows you to customize the message to all members of the companionship requesting a report for the month.

If the e-mail option above requires the user to edit the e-mail or enter comments, the following web e-mail client pops up and automatically populates the "Sender" and "Recipient" fields with the appropriate e-mail addresses:



This makes the task of contacting teachers and companionships a breeze. Simply select the teacher, click a button, and you're requesting just that teacher OR all the companions to report.

The "Send Request for Report to ALL not reported" was a challenge. We don't want to allow this option to be triggered multiple times, yet we want to give the Presidency the ability to send a final request for HT/VT results when desired.

I'm also starting to implement some limited AJAX support into the application for certain functions where it makes sense.

Brad O.

brado426 wrote:Russell,

One of the individuals that suggested the "Attempted" option is helping test the site. He found that his teachers needed this option because they were getting confused about the difference between "Attempting" a visit and actually "Visiting." For example, Visiting the home and knocking on the door could be looked at as a "Visit." This is why we changed "Visited" to "Visited With Family" and added the "Attempted" option.

I think you're right.... being able to mark "Attempted" does make people *FEEL* better. All we can really do is make best-guess decisions and try to figure out what works until the Church provides some guidance.

Brad O.

Having been frequently assigned to visit inactive people that no one knows and who don't reply to voicemail, doorbells, or snail mail, I would appreciate the idea of attempted/rejected or attempted/refused reporting. Although under current policy this data would only be reported locally, it could be used by the leadership for planning--not just for me to feel better. I'm not responsible for the recipient's response, only for my attempts & reporting.

I didn't have a specific visit type in mind, but I have a few ideas.

In essence, I think it would be useful for local leaders to add / modify visit types. If a specific EQP wants to track attempts vs. visits, we should not put barricades in his way.

A few 'special' types of visits I have been on:
New member discussions
Missionary visit to less-active members
Presidency / Bishopric 'splits'
Service visits

I have also had the unenviable task of visiting people to get their names removed, and an 'official' visit to stop HT/VT. I do not think that these should be a visit type, or even reported this way.

Maybe you could instead add an 'other' visit, that would not be counted by default, but would allow a more descriptive title.

Nevermind, that would be better served with an attention flag.....

Thanks


I

I spoke with the priesthood department about the whole "Visit Types" idea. Because of the diverse geographical and cultural issues within the Church, the definition of what a visit is will be left to the local priesthood leaders, which would favor keeping the tool simple.

Tom

My vote then is for just 'visited / not visited / not reported' default with the ability to add or modify types as needed.

tomw wrote:I spoke with the priesthood department about the whole "Visit Types" idea. Because of the diverse geographical and cultural issues within the Church, the definition of what a visit is will be left to the local priesthood leaders, which would favor keeping the tool simple.

Tom

When in doubt, keep it simple. You can always expand on it later if you need. No use spending time on complexity upfront.

In that case, I'm guessing there will need to be a "Visit-Type Configuration" option such as this:

http://htreporting.com/htrep/screenshot ... ttypes.txt

This way the Presidency could configure the Visit-Types that count as "Not Visited" to either show up as a separate item in the statistics report and pie chart or to be figured in with the rest of the "Not Visited/Contacted."

Hopefully there is a better way to word 1, 2, and 3 to make them easier to understand. I think it would be important to have pre-selectable Visit-type sets so that most Presidencies wouldn't need to deal with this.

This would be a relatively complex change.

Brad O.

I don't think you need the radio buttons.

I would use something like: Then you only have 2 flags to check.

Do you have your code available? Do you have an architecture description / diagram?

Are you looking for coding help?

Thanks
TE

The Earl wrote:I don't think you need the radio buttons.

I would use something like:

Code:

         
[font=Courier New]            Counts as visit      Chart Separate [/font]
[font=Courier New]Visited             X                [/font]
[font=Courier New]Not Visited[/font]
[font=Courier New]Phone               X                  X[/font]
[font=Courier New]Email                                  X[/font]

Then you only have 2 flags to check.

Yeah, I like that! Neither item being checked means "Not Visited." I'm feeling pretty good about this idea.

Expect a PM from me later regarding the coding help.

Brad O.

The Earl wrote:Maybe you could instead add an 'other' visit, that would not be counted by default, but would allow a more descriptive title.

"Other visit" may useful as I believe some of those visits does count as a visit but at the same time it may not be reflective of the assigned HT/VT efforts.

However I'd give some thoughts to using notes. Make the selections as only as detailed as we want for statistical purposes and use notes for the rest. For example, do we want to track "attempted" for statistical purposes, or just let people enter notes to explain why the visit didn't happen? The advantage of this approach is it keeps the summery display clean while still allowing some drill down. It also side-steps the "does it count" confusion.

brado426 wrote:Yeah, I like that! Neither item being checked means "Not Visited." I'm feeling pretty good about this idea.

Expect a PM from me later regarding the coding help.

Brad O.

I would love to help to Brad.

I also have a document to send you with my recommendations for the site. Do you want me to post them here or send them to you privately?

M

Another thought: "Out of town for the month". Last I looked membership records weren't to be moved unless the person would be gone for more then 3 months. That leaves a lot of "home for the holidays" or "home for summer". Especially for singles and student wards.

(Yeah, I know. I keep pushing for simplification and yet I keep thinking up more things.) :rolleyes:

But I guess my prior question still holds: A drop-down category or put it in "notes"?

Here's a technical concern that I'm not sure how to solve....

Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

The system currently stores up to one year of historical data so that the "History" report can be generated.

It is almost as if we would need to allow the user to configure the Visit Types the first time they used the system but never allow it again. Either that or we would need to do an UPDATE of all the IDs that were previously submitted whenever a change was made to the VisitTypes table.

The more I think about this, the more complex it gets.

I'm not sure that there are any easy answers here. Please enlighten me.

Brad O.

brado426 wrote: Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

I have run into this problem before in the past and my solution is normally to add a called "enabled" and allow the values "1" or "0" depending on weather or not the Visit-Type is wanted or not. Don't allow the Visit-Types to be deleted just disabled and enabled.

-Rich

brado426 wrote:Here's a technical concern that I'm not sure how to solve....

Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

The system currently stores up to one year of historical data so that the "History" report can be generated.

It is almost as if we would need to allow the user to configure the Visit Types the first time they used the system but never allow it again. Either that or we would need to do an UPDATE of all the IDs that were previously submitted whenever a change was made to the VisitTypes table.

The more I think about this, the more complex it gets.

I'm not sure that there are any easy answers here. Please enlighten me.

Brad O.

I would say never remove a VisitType. There's really no reason to. Just add a column to the table that signifies whether that VisitType is an active option for a Teacher to select. That way, deactivated ones can still show up in historical reports. I doubt the VisitTypes will ever get over 15 or 20 anyway.

marlattrj wrote:I have run into this problem before in the past and my solution is normally to add a called "enabled" and allow the values "1" or "0" depending on weather or not the Visit-Type is wanted or not. Don't allow the Visit-Types to be deleted just disabled and enabled.

-Rich

LOL, yeah what he said...

That makes sense. So the administrative menu for this will only allow you to add new Visit Types or Enable/Disable an existing Visit Type. Of course, Visit Type name changes would have to be prohibited.

Brad O.

brado426 wrote:Of course, Visit Type name changes would have to be prohibited.

I guess it depends on how much you want to trust your admin. It might be desirable to change the phraseology(visit, visit complete, successful visit, we came - we saw - we taught), but renaming "Visited" to "Out of Town" would be rather disastrous.

Perhaps a pop-up warning message during the rename function?

I'd also be amiss if I didn't point out the possibility of NOT referencing the visit type table and recording the current accepted value of the table into the history DB (or whatever it is). That prevents any changes to the visit type table from affecting past months. I have mixed feelings about that, but I wanted to make sure we saw all the options.

brado426 wrote:Here's a technical concern that I'm not sure how to solve....

Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

The system currently stores up to one year of historical data so that the "History" report can be generated.

It is almost as if we would need to allow the user to configure the Visit Types the first time they used the system but never allow it again. Either that or we would need to do an UPDATE of all the IDs that were previously submitted whenever a change was made to the VisitTypes table.

The more I think about this, the more complex it gets.

I'm not sure that there are any easy answers here. Please enlighten me.

Brad O.

If I understand the problem correctly, the way to resolve this is to never show the user the "Visit Type ID" but instead show them the "description". Because you are linking the talbes using the "ID", the description can change all you want. Of, however, a user wishes to delete a "visit type" after it has been used, there are two ways to handle the situation.

1. Prohibit it. Most DB's allow you to put referential checks on relationships that would throw a DB error if you try to delete a record that has links to it.
2. Set the related to tables Visit Type ID to "null" indicating that the type was removed. Again, most DB's allow a referential check to do this for you automatically.

Did I understand your problem correctly?

Tom

RussellHltn wrote:Another thought: "Out of town for the month". Last I looked membership records weren't to be moved unless the person would be gone for more then 3 months. That leaves a lot of "home for the holidays" or "home for summer". Especially for singles and student wards.

(Yeah, I know. I keep pushing for simplification and yet I keep thinking up more things.) :rolleyes:

But I guess my prior question still holds: A drop-down category or put it in "notes"?

In watching this discussion, it occurs to me that two layers of reporting might help. For example:
HT visited
HT not visited
letter
email
phone
refused
out of town
not in the ward (i.e: moved & the records need to go elsewhere)
other (defined locally)
other
VT visited
in person
phone
letter
VT not visited
email
refused
out of town
not in the ward
other
other

Local admin (RS pres, EQ pres, etc) could flag types of visits for the appropriate visited/not visited category. Statistical information could then be readily generated for the officially counted data (as determined by local leaders per Tomw) and for the subsets of visited and not visited for local planning purposes.

This would suit both types of needs.

It would also be helpful to extract historical data for visits to particular households/individuals (HT/VT). This would help leaders better analyze events in areas where leadership is more fluid, such as YSA & military wards.

NOTE:
Topics should be indented under each of the following headings:
HT visited (as a default, HT visits are in person, so I have no additional detail here)
HT not visited
VT visited
VT not visited

RussellHltn wrote:

I guess it depends on how much you want to trust your admin. It might be desirable to change the phraseology(visit, visit complete, successful visit, we came - we saw - we taught), but renaming "Visited" to "Out of Town" would be rather disastrous.

I think people would want to change the phraseology, but allowing changes like that sets the user up to cause problems. Along the lines of your example, just think if someone changed "Visited" to "Not Visited." All the historical data would be completely wrong.

I don't think we should be trusting the 'Admin. too much in this case. There would likely be hundreds of 'Admins' with varying levels of computer experience.

Tom W. wrote:

If I understand the problem correctly, the way to resolve this is to never show the user the "Visit Type ID" but instead show them the "description". Because you are linking the talbes using the "ID", the description can change all you want. Of, however, a user wishes to delete a "visit type" after it has been used, there are two ways to handle the situation.

1. Prohibit it. Most DB's allow you to put referential checks on relationships that would throw a DB error if you try to delete a record that has links to it.
2. Set the related to tables Visit Type ID to "null" indicating that the type was removed. Again, most DB's allow a referential check to do this for you automatically.

Yes, that was what I was pretty much what I was thinking. There is rarely a need to display the ID to the user.

The problem with setting an ID in the "Visit Types" table to null is that all the previously reported Visit-Types in the results table would suddenly not link to anything. We would need to somehow specify what all those links were supposed to link to. Perhaps a pop-up that allowed the user to "re-assign" all previously reported Visit Types to another value if they try to delete a Visit-Type.

I'm leaning towards only allowing adds, enables and disables, and not allowing deletes. Then, we would have the option to create a maintenance task that deleted any Visit-Types that did not exist in the "Results" table after a year to keep the "Visit-Types" table clean.

Brad O.

brado426 wrote:I'm leaning towards only allowing adds, enables and disables, and not allowing deletes. Then, we would have the option to create a maintenance task that deleted any Visit-Types that did not exist in the "Results" table after a year to keep the "Visit-Types" table clean.

And as for the rename functionality, I would just leave it at disabling the old and creating a new.

mkmurray wrote:And as for the rename functionality, I would just leave it at disabling the old and creating a new.

Absolutely! I think this solution would provide the flexibility we are looking for while restraining the admins from creating problems.

[font=&quot]Also you might want to make the VisitType not visible even to the local admin after disabling it, other wise they could end up with a mile long list of options. Just put a delete button and when they click "delete" it just disables the VisitType making it appear deleted.

-Rich
[/font]

I think you would be ok if you allowed the text of the visit type to be changed for a given ID. The two types that you would not want to edit are 'Visited' and 'Not Visited'. I would disable editing of those, as any change to them would probably lead to confusion. You could add a "Power User" edit switch that would allow changes to the two if you wanted to, but anyone smart enough to want to change those could probably do it in the DB anyway.

As for the delete, I would still call the function delete, even if you just disabled the category.

Some systems, like Bugzilla do not allow you to delete an entry that is in use. It will allow you to move all of the entries for the ID that you are trying to remove to an existing entry. You could then really delete a type, but you would have to re-assign all of its records to another type.

In some of my apps, protected options get negative IDs. That allows me to quickly verify that certain operations are permitted on them, and add additional protected types quickly.

Just a few thoughts.

The Earl wrote:I think you would be ok if you allowed the text of the visit type to be changed for a given ID. The two types that you would not want to edit are 'Visited' and 'Not Visited'. I would disable editing of those, as any change to them would probably lead to confusion. You could add a "Power User" edit switch that would allow changes to the two if you wanted to, but anyone smart enough to want to change those could probably do it in the DB anyway.

The admin wouldn't have access to the DB.... the idea is that this is a centralized application that is only installed in one place.

So you're saying, have a mandatory "Visited" and "Not Visited" option where the text could be edited and then the ability to add custom Visit-Types. If we kept it absolutely clear in the administrative interface that the "Visited" text is for "Visited" and the "Not Visited" text is for "Not Visited," I think that might work.

Brad O.

brado426 wrote:I think people would want to change the phraseology, but allowing changes like that sets the user up to cause problems. Along the lines of your example, just think if someone changed "Visited" to "Not Visited." All the historical data would be completely wrong.

Right. Question: Would you ever want a change to the visit type table to affect the historical data? If not, then I'd be inclined to NOT link the visit type and historical tables and simply write the current values into the historical table when the month becomes "history". It's not the 60's where we have to squeeze every possible byte of space anymore.

That way you can change the visit schema, phraseology and how each type counts to visit/not visited without changing your old values. The visit type table only influences the "current" month.

While the suggestions of "deletes" only mark things inactive will work, that seems much more complex and seems far more likely to run into bugs or other strange things.

If by chance you see a need to change history, you can always run a "find and replace" type of operation.

brado426 wrote:Here's a technical concern that I'm not sure how to solve....

Whenever a teacher reports, the system plugs the Visit-type ID into the "Results" database table. The VisitType ID in the VisitType table is joined with the VisitType ID in the Results table. If we allow the Visit Types to be modified/Deleted/Added in the "Visit-Types" table, what is going to happen to all the Visit Type relationships that were previously reported? If significant changes were made to the Visit-Types table, the reported visits would link to the wrong Visit-Type or possibly even link to nothing.

The system currently stores up to one year of historical data so that the "History" report can be generated.

It is almost as if we would need to allow the user to configure the Visit Types the first time they used the system but never allow it again. Either that or we would need to do an UPDATE of all the IDs that were previously submitted whenever a change was made to the VisitTypes table.

The more I think about this, the more complex it gets.

I'm not sure that there are any easy answers here. Please enlighten me.

Brad O.

Rule of thumb...never delete...only supress. I would recommend you supress the old type and have a new one created. It's like setting a type to inavtive or active. This way you never lose db integrity. You can also update the old types to the new value or you can just use the new value moving forward and consider the other legacy.

That's my 2 cents...

brado426 wrote:The admin wouldn't have access to the DB.... the idea is that this is a centralized application that is only installed in one place.

So you're saying, have a mandatory "Visited" and "Not Visited" option where the text could be edited and then the ability to add custom Visit-Types. If we kept it absolutely clear in the administrative interface that the "Visited" text is for "Visited" and the "Not Visited" text is for "Not Visited," I think that might work.

Brad O.

Won't work...think international...

Visitamos...No Visitamos...

I say you give us correct principles and let us govern ourselves...in the end I could see someone creating all their own anyway and never using visited and not visited. That's what I would do as a work around and that would render this particular solution useles..

Mr. M wrote:Won't work...think international...

Visitamos...No Visitamos...

What I meant was that the administrative dialog box for Visited and Not Visited would be mandatory and allow the user to enter whatever text they wanted for each (even in Spanish.) Can't we assume that all groups will at least need a "Visited" and "Not Visited" option?

Brad O.

brado426 wrote:What I meant was that the administrative dialog box for Visited and Not Visited would be mandatory and allow the user to enter whatever text they wanted for each (even in Spanish.) Can't we assume that all groups will at least need a "Visited" and "Not Visited" option?

Brad O.

I agree. What we could do is have a field that says Visited" and "Not Visited" and another one next to it that has the custom visit types. So if some one was to select "Visited" they could have some options as to what visit type they can select and if they select "Not Visited" they will be given choices like "Called to check up" or "Mailed a letter".

This would allow for different types of reporting but still keep with the basic visited/not visited.

Rich Marlatt

It does not matter what we call the two categories, what is important is that we have to aggregate all other types into 'visited / not visited' for reporting.

For some instances, you would change the display of these two categories, but you CANNOT change the underlying meaning. Changes to the meaning of these two categories would make the aggregation / reporting information useless.

My point earlier was that this change would only make sense at install time, and only for the installer / maintainer to make. You would never allow a user to modify these unless you could be sure that the user understood the implications of changing them. You would not allow these entries to be removed or inactivated.

If changes only make sense during installation, you can safely assume that the installer has full control over the data store and the software configuration. You could allow the installer to modify these in the DB, or in a config file, but it does not make sense to allow changes of ANY type to these on a regular basis. At most, I would require full admin privileges, and two separate confirmed steps to change these types.

One of my Palm applications has a 'dangerous' mode that allows operations that could really mess things up. You have to enable 'dangerous' mode to see the options, then there is a confirmation dialog for the dangerous operations that specifies the bad things that can happen if you perform those operations.

Again, I think you can safely assume that the installer can get into the DB and modify the 'visited / not visited' text, and that they have the required knowledge to do so. After that, I can't see a reason to change those two categories.

marlattrj wrote:I agree. What we could do is have a field that says Visited" and "Not Visited" and another one next to it that has the custom visit types. So if some one was to select "Visited" they could have some options as to what visit type they can select and if they select "Not Visited" they will be given choices like "Called to check up" or "Mailed a letter".

This would allow for different types of reporting but still keep with the basic visited/not visited.

Rich Marlatt

Here is an example of what I mean: http://marlattfamily.org/ht/test.html

This would require people to report Visited or not visited but also give them the option to report what type of visit/non-visit they did.

The Earl wrote:It does not matter what we call the two categories, what is important is that we have to aggregate all other types into 'visited / not visited' for reporting.

For official reporting to church headquarters, that's correct. But I think people are wanting some other categories for local reporting. If none of the other "unofficial" categories never make it into the local summary, then all the different visit types are pointless, no?

I put together this "Contact Type Editor" administrative screen shown below:



We have our standard contact types in the top grid that cannot be added to or deleted, however, the text can be changed. We have the custom contact types in the lower grid. For the custom contact types, new contact types can be added, the text can be changed, and the contact type can be deleted (not really deleted, but deleted as far as the user is concerned.) For each custom contact type, you can specify if it should be counted as "Visited" or "Not Visited." For Visiting Teaching, this will say, "Contacted and "Not Contacted." I'm also thinking that for Visiting Teaching, "Phone and Letter" will need to be "Standard Contact Types."

I'd like to keep it so the teacher can report by selecting only one dropdown box. The easier it is for the user to report, the more likely they will report on their own. I think some changes are in order for the "Reporting Page" to accomodate this, but I haven't thought that far ahead yet.

Comments?

Brad O.

I put together this "Contact Type Editor" administrative screen shown below:



We have our standard contact types in the top grid that cannot be added to or deleted, however, the text can be changed. We have the custom contact types in the lower grid. For the custom contact types, new contact types can be added, the text can be changed, and the contact type can be deleted (not really deleted, but deleted as far as the user is concerned.) For each custom contact type, you can specify if it should be counted as "Visited" or "Not Visited." For Visiting Teaching, this will say, "Contacted and "Not Contacted." I'm also thinking that for Visiting Teaching, "Phone and Letter" will need to be "Standard Contact Types."

I'd like to keep it so the teacher can report by selecting only one dropdown box. The easier it is for the user to report, the more likely they will report on their own. I think some changes are in order for the "Reporting Page" to accomodate this, but I haven't thought that far ahead yet.

Comments?

Brad O.

You should Switch the column order for Standard contact types so it matches the custom contact types; i.e. contact type column first

brado426 wrote:I

Comments?

That is perfect.

Again, I don't think you need the ability to change the standard types in the UI, but having the ability is only a liability if the admin does something silly.

nimebe wrote:You should Switch the column order for Standard contact types so it matches the custom contact types; i.e. contact type column first

I would have Contact Text first, but yes the same for both.

In fact, I'd go one step further - merge them into one table but omit the "delete" and "chart separately" from the two standardized types. I think the two table setup is likely to confuse a non-technical person.

Uh, what does "chart separately" do? Sorry if it's been covered before, but it's not immediately obvious to me.

The Earl wrote:That is perfect.

Again, I don't think you need the ability to change the standard types in the UI, but having the ability is only a liability if the admin does something silly.

I don't like it either, but there are cases that it would be a necessity such as for foreign languages.

I would have Contact Text first, but yes the same for both.

Yeah, you guys are right.... I'll change that.

In fact, I'd go one step further - merge them into one table but omit the "delete" and "chart separately" from the two standardized types. I think the two table setup is likely to confuse a non-technical person.

Well, I put them in two tables to make it absolutely clear which Contact Types were the standard ones and which contact types are the custom ones. If we put it in one table, I think it would be harder to differentiate between the two.

Uh, what does "chart separately" do? Sorry if it's been covered before, but it's not immediately obvious to me.

Yes, this needs to be made clearer. This option determines whether the custom type shows up as part of the "Counts As" type (in this case, Visited or Not Visited) in the statistics view and pie chart. If this box is checked, it will show up as a different section of the pie chart. For example, someone may want to give the option of "Attempted" but they just want it to be graphed as "Not Visited" along with the rest of the not visited. I think the best way to clear this up is to add some instructions.

Brad O.

brado426 wrote:Well, I put them in two tables to make it absolutely clear which Contact Types were the standard ones and which contact types are the custom ones. If we put it in one table, I think it would be harder to differentiate between the two.

My first reaction is "does it matter"? But then, I think I see what you're saying. You don't want to give the impression that the whole thing gets reported back to CHQ. Perhaps a bit of explanatory small font text could make the difference clearer. Standard - Visit types reported to Church Headquarters. Custom (perhaps "optional"?) Additional visit types for local reporting only. (Optional)

brado426 wrote:
For example, someone may want to give the option of "Attempted" but they just want it to be graphed as "Not Visited" along with the rest of the not visited. I think the best way to clear this up is to add some instructions.

My suggestion is "Tallied separately (from subcategory)", but I don't know as it's any clearer.

Edit: Is there a way of doing the chart so that the visit/not visited and the subcategories are both clear? I'm thinking of a "removed slice" to distinguish between visit/not visited while the individual subcategories are shades of the two main slices. (I'm guessing "not reported" would be considered "Not visited".) That would help make the distinction between "local" and "official" stats.

RussellHltn wrote:
Is there a way of doing the chart so that the visit/not visited and the subcategories are both clear? I'm thinking of a "removed slice" to distinguish between visit/not visited while the individual subcategories are shades of the two main slices. (I'm guessing "not reported" would be considered "Not visited".) That would help make the distinction between "local" and "official" stats.

That is something to think about. "Not Reported" actually shows up as a separate section of the pie chart. I thought it would be best to separate the "Not Visited" and "Not Reported" and allow the Presidency to manually mark anything that was still "Not Reported" at the end of the month.



I think I prefer it this way.... does anyone disagree? If we counted "Not Reported" as "Not Visited" I think we would be potentially making incorrect assumptions for the Presidency.

Brad O.

brado426 wrote:I thought it would be best to separate the "Not Visited" and "Not Reported" and allow the Presidency to manually mark anything that was still "Not Reported" at the end of the month.

I think I prefer it this way.... does anyone disagree? If we counted "Not Reported" as "Not Visited" I think we would be potentially making incorrect assumptions for the Presidency.

I agree with you for local purposes, but when it comes time to report to CHQ, an assumption must be made and it's probably more accurate to assume the families weren't visited than to assume they were.

brado426 wrote: I think I prefer it this way.... does anyone disagree? If we counted "Not Reported" as "Not Visited" I think we would be potentially making incorrect assumptions for the Presidency.

Brad O.

I also would prefer it this way.

Also what are you using to code the site in? any tool kits? I have been really active in AJAX development and there are some really nice tool kits out there that are very useful for building dynamic sites like this. if you are interested check out:

PrototypeJS http://www.prototypejs.org/
dojo http://dojotoolkit.org/

and for making chats check out http://www.liquidx.net/plotkit/

These are all AJAX based tool kits that are opensource and very useful

-Rich

marlattrj wrote:I also would prefer it this way.

Also what are you using to code the site in? any tool kits? I have been really active in AJAX development and there are some really nice tool kits out there that are very useful for building dynamic sites like this. if you are interested check out:

PrototypeJS http://www.prototypejs.org/
dojo http://dojotoolkit.org/

and for making chats check out http://www.liquidx.net/plotkit/

These are all AJAX based tool kits that are opensource and very useful

-Rich

Yeah... AJAX is fantastic! This site is developed with Visual Studio 2005 using the ASP.NET 2.0 Framework. I am also using the ASP.NET AJAX Framework.

The actual code is written in C#.

Now that I've worked with this AJAX Framework, I don't think I would do web development any other way. Postbacks are for the birds.

Brad O.

brado426 wrote:Postbacks are for the birds.

Brad O.

Ajax runs with postbacks, just that the postback is contained in an object instead of the entire page.

But yes AJAX is the best way to go especially if you are trying to get an "application" feel to the page.

brado426 wrote:

I think I prefer it this way.... does anyone disagree?

Sorry, I don't think I'm communicating well. My first suggestion is to find a way of showing both the official and local reports in one chart. The example above really doesn't show any of the added/unofficial visit types other then "appointments".

How the "not reported" is handled is separate issue.

Sorry, I don't think I'm communicating well

Is there a way of doing the chart so that the visit/not visited and the subcategories are both clear? I'm thinking of a "removed slice" to distinguish between visit/not visited while the individual subcategories are shades of the two main slices.

Sorry.... I didn't comment on separating the visited/not visited and subcategories because I'm still thinking about it.... so I ran with your "Appointments Made" comment.

Ok.

The way the data model seems to be going is that we have "Visited" and "Not visited". All of the custom visit types are subcategories of those two. I like the idea. It reinforces the concept that while the local leaders see details, they still are quite clear on what's being reported to CHQ. I'm just asking for a pie chart that reflects the category/subcategory model that we are now dealing with.

Oh... And as something else to think about - shouldn't be concentrating on VT? They are more complex with multiple official visit types. HT is a snap once we figure out how to deal with VT.

All the standard and custom contact types will show up in the pie chart. I'm just not sure of the best way to differentiate between the two graphically. Maybe we don't need to worry about differentiating... still thinking.

As for Visiting Teaching, I think this model will work great. Here is how I have the Status table layed out:

StatusId - int - ID of status
StatusName - varchar - Name of status (Visited/Not Visted/Appointment Made)
CountsAs - int - For custom contact types only - specifies the standard contact type to count as
StatusSettings - int - Boolean attributes about this status that can be retrieved by bitshifting

StatusSettings is described here:

public enum StatusSettings : byte
{
Standard = 1, // Standard Contact Type
Hidden = 2, // Contact Type has been deleted (hidden) by the user
ChartSeparately = 4 // Custom contact Type is to be charted separately from the standard contact type
}

So with Visiting Teaching, Contacted, Not Contacted, Phone Contact, and Letter Contact will be tagged as StatusSettings.Standard. Then, the Presidency has the ability to create additional custom contact types and specify that they count as one of the four Standard types.

Does that make sense?

Brad O.

Brado426:

I feel like you may not get what RussellHltn is saying about the chart. So I've created this image to help. Hopefully, I understand what RussellHltn is meaning too (please correct me if I'm wrong!).

I think he wants a chart something like this attachment...

Hope this helps.

mkmurray wrote:Brado426:

I feel like you may not get what RussellHltn is saying about the chart. So I've created this image to help. Hopefully, I understand what RussellHltn is meaning too (please correct me if I'm wrong!).

I think he wants a chart something like this attachment...

Hope this helps.

Yeah, that is pretty much how I was understanding it. Looks good to me. Hopefully that will be relatively easy to implement with my chart control.

Brad O.

mkmurray wrote:I think he wants a chart something like this attachment...

Bingo!

Thanks.

brado426 wrote:Does that make sense?

Edit: Removed stuff I was mistaken about.

Also, I'll have to check, but it sticks in my mind there are some rules with VT - like you have to have a in-person visit once a quarter. I'm not sure if it's a directive taken care of with a special report, or if it's a hard and fast rule that a letter/phone contact can't count as a visit unless there's a in-person visit in the last two months. (Or something like that.)

RussellHltn wrote:Sorry, I'm not up on my programming languages, but it looks like you're recording "charted separately" in two places - CountAs and StatusSettings?

Also, I'll have to check, but it sticks in my mind there are some rules with VT - like you have to have a in-person visit once a quarter. I'm not sure if it's a directive taken care of with a special report, or if it's a hard and fast rule that a letter/phone contact can't count as a visit unless there's a in-person visit in the last two months. (Or something like that.)

CountAs is a field that stores the Status ID of the Standard Contact Type that the Custom Contact Type should be counted as.

StatusSettings holds several attributes that describe the Contact Type.

Status is the same as Contact Type.... the table is currently named "Status" so that might be causing some confusion.

Yes, there are rules with Visiting Teaching as you mentioned. However, I don't think those rules should be handled by this system. I'm thinking that this system would only keep a record of the actual Sister Contacts and feed that data to the Church's system. The History report in this web HT/VT system can be used to help the Presidency keep track of who has not had an actual Visit in a long period of time.

Brad O.

Somehow I got CountsAs and ChartSeparately mixed up. OK, it makes sense now.

The Contact Types are now fully customizable.

The new statistics chart looks like this:



You can easily specify which "Custom Contact Types" are to be counted as Visited and which should be counted as Not Visited. You can make changes to these settings at any time without screwing anything up. If you suddenly decide that a particular Contact Type shouldn't be counted as visited, simply make the change and everything will automatically be recalculated.

Believe it or not, hunting down the right formula to make the pie chart to separate like that was a major pain in the neck.

The colors can be easily changed. I like blue and yellow for the first two "Custom Type" colors, but rest look kind of ugly.

The administrative menu allows you to remove and re-add Contact Types at will. You can delete Custom Contact types, but it won't let you delete them if anyone has ever used that Contact Type to report. Of course, you can also change the wording for any Contact Type.

I think this keeps things simple and stays within Church standards while allowing the Presidency to customize it to their reporting needs.

Brad O.

brado426 wrote:The colors can be easily changed. I like blue and yellow for the first two "Custom Type" colors, but rest look kind of ugly.

Guess you can design a type of "theme" coloring scheme that can be selected. Another is to do color wheel divisions so you divide the color wheel into x (the number of slices) even sections. You then place the opposite colors next to each other on your pie chart. A good basic review of color theory at http://www.colormatters.com/colortheory.html.

I'm not the visual designer in my family though so take this with a grain of salt.

brado426 wrote:The new statistics chart looks like this:

Excellent!! That's exactly what I had in mind.

brado426 wrote:The Contact Types are now fully customizable.

The new statistics chart looks like this:

Very nice indeed. Very easy to read. Nice work.

Tom

Thanks guys.


This should provide some additional clarity as to exactly how this new enhancement works.


New "Editable Contact Types" Feature

You now have the ability to customize the “Contact Types.” The Church has provided standards for some “Standard” Contact Types (Visited and Not Visited for Home Teaching and Contacted, Not Contacted, Phone, and Letter for Visiting Teaching.) However, you can now add your own “Custom” Contact Types to request some additional information from your teachers. For example, for Home Teaching, the Presidency could add a “Do Not Contact” contact type or a “Not Home” contact type. Each Custom Contact Type must be assigned to be counted as a Church Standard Contact Type. When you first add a new Custom Contact Type, it will be counted as “Not Visited” for HT or “Not Contacted” for VT.

Editing Contact Types

To view and edit your group’s contact type, select “System Settings” for the Admin Menu and click the “Customize Contact Types” button.

You will be presented with this screen:


Above, you can see the configured Standard Contact Types and Custom Contact Types.

Standard Contact Types

You may change the text for any Standard Contact Type by clicking on the “Edit Contact Text” link. Be sure to only use text that properly describes the Contact Type specified in the “Standard Contact Type” column.

Custom Contact Types

You may change the text, remove, or add a new or removed Custom Contact Type by clicking on the associated links next to the Custom Contact Type. If you remove a Contact Type, you can always re-add it again by clicking on “Add Custom Contact Type” and selecting the removed type from the list.

• Count As specifies which Standard Contact type this Custom Contact Type should be counted as. Every Custom Contact Type must be associated with a “Standard Contact Type.”

• Chart Separately specifies whether your Custom Contact Type shows up as a separate item on the Statistics/Pie Chart on the Report. If this is checked, it will show up as a separate item. If this is unchecked, it will show up along with the Standard contact type you have selected under the 'Count As' column.

After you make changes to the Count As or Chart Separately settings, click Submit to save your changes.

You may make these changes any time you like and they will automatically be applied to any previously reported data.

Pie Chart Changes

In addition to this change, the Statistics chart has been someone redesigned.




The pie chart is now divided into 3 subcategories and the Contact Types underneath each category are grouped together on the pie chart. Contact Types whose values are zero or do not have ‘Chart Separately’ checked will not show up as separate items in this statistics view.

‘Disable Attempted’ Option Removed

As an added note, the setting for disabling the ‘Attempted’ Contact Type has been removed. ‘Attempted’ can now be removed by using “Customize Contact Types” on the Admin Menu. Simply click on the “Remove Contact Type” link next to the “Attempted” Custom Contact Type.

brado426 wrote:The pie chart is now divided into 3 subcategories and the Contact Types underneath each category are grouped together on the pie chart. Contact Types whose values are zero or do not have ‘Chart Separately’ checked will not show up as separate items in this statistics view.

So was the value of "Attempted" zero in the pie chart? or was it merged with "Not Contacted"?

Also, the pie chart shows phone contact and letter contact as contacted...is this a VT pie chart?

Any clarity you can provide would be helpful...Thanks.

P.S. The chart stuff looks great by the way.

These charts look great! For the colorblind, labels for the pie wedges would be helpful.

brado426 wrote:When you first add a new Custom Contact Type, it will be counted as “Not Visited” for HT or “Not Contacted” for VT.

Are you saying the first Custom Contact Type must be a "Not Visited/Not Contacted"?

brado426 wrote: Chart Separately specifies whether your Custom Contact Type shows up as a separate item on the Statistics/Pie Chart on the Report. If this is checked, it will show up as a separate item. If this is unchecked, it will show up along with the Standard contact type you have selected under the 'Count As' column.After you make changes to the Count As or Chart Separately settings, click Submit to save your changes.

I understand what it does, but I think it could be worded better.

Suggested:
.... If this is unchecked, the Custom Contact Type will not be broken out for display and any visits logged under this Contact Type will be merged into the Standard contact type you have selected under the 'Count As' column.

Otherwise, excellent write-up.

One more suggestion. To avoid issues like mkmurray is asking, all visit types that are to be displayed, should appear in the legend, even if there are zero visits of that type. It may already be that way. I just can't tell from the data samples.

mkmurray wrote:So was the value of "Attempted" zero in the pie chart? or was it merged with "Not Contacted"?

Also, the pie chart shows phone contact and letter contact as contacted...is this a VT pie chart?

Any clarity you can provide would be helpful...Thanks.

P.S. The chart stuff looks great by the way.

In that case, the 'Attempted" type would not show up because 'Chart Separately' is not checked. If no one reported as "Attempted", it wouldn't show up even if 'Chart Separately' was checked. I'm thinking this is a mistake.... perhaps it should be changed so that if there are zero reports, the contact type still shows up on the statistics chart. What do you think?

Yeah, that is "Visiting Teaching." For Home Teaching, only "Visited" and "Not Visited" show up as Standard Contact Types and you have the option of adding Phone and Letter contacts as Custom Contact Types.

Brad O.

scion wrote:These charts look great! For the colorblind, labels for the pie wedges would be helpful.

I'm not sure how to facilitate that. Sometimes the pie wedges will be tiny whereas the text would not fit inside. Do you have any suggestions on how to display these labels that you are suggesting? I guess the labels could be placed somewhere with lines pointing to the pie piece, but I think that would get kind of messy.

Brad O.

Are you saying the first Custom Contact Type must be a "Not Visited/Not Contacted"?

No.... I'm just saying that when you first add a contact type, it defaults to "Not Visited/Not Contacted." You can then change it to whatever you want.

I understand what it does, but I think it could be worded better.

Suggested:
.... If this is unchecked, the Custom Contact Type will not be broken out for display and any visits logged under this Contact Type will be merged into the Standard contact type you have selected under the 'Count As' column.

Definitely much better worded. Thanks!

One more suggestion. To avoid issues like mkmurray is asking, all visit types that are to be displayed, should appear in the legend, even if there are zero visits of that type. It may already be that way. I just can't tell from the data samples.

Yeah.... I'm in total agreement with you guys. I will make that change.

I'm now looking at creating a cascading dropdown for the teachers when they report so that teachers can select the standard contact type and have the custom contact type show up underneath it (kind of how the Windows XP Start Menu works.) I think this can be done while keeping it as a one-click reporting interface. I'll let you know once I have a solution for this.

Brad O.

brado426 wrote:No.... I'm just saying that when you first add a contact type, it defaults to "Not Visited/Not Contacted." You can then change it to whatever you want.

In that case I'd leave that sentence out. Anyone should be able to figure that out.

However ..... What about defaulting to "choose type" and then requiring it to be selected before hitting "subit"? An idea, but I'm not too sure how well I like it. I kinda suspect most of the added items will be "Not Visited/Not Contacted" anyway.

Question: I've noticed that for VT they can only make things a subcategory of "Contacted" or "Not Contacted". They can't make a subcategory for say "Sent Letter". (Perhaps it would be "Sent Ward Newsletter") Is this going to work for the Relief Society?

RussellHltn wrote:In that case I'd leave that sentence out. Anyone should be able to figure that out.

However ..... What about defaulting to "choose type" and then requiring it to be selected before hitting "subit"? An idea, but I'm not too sure how well I like it. I kinda suspect most of the added items will be "Not Visited/Not Contacted" anyway.

Yeah, that is why I made it default to "Not Visited/Not Contacted." I figured that when a Custom Contact Type was added, we should assume it is not visited unless the Presidency specifies otherwise.

Question: I've noticed that for VT they can only make things a subcategory of "Contacted" or "Not Contacted". They can't make a subcategory for say "Sent Letter". (Perhaps it would be "Sent Ward Newsletter") Is this going to work for the Relief Society?

Actually, the system does allow you to classify a Custom Contact Type as 'Phone Contact' or 'Letter Contact' for Visiting Teaching.



Brad O.

brado426 wrote:Actually, the system does allow you to classify a Custom Contact Type as 'Phone Contact' or 'Letter Contact' for Visiting Teaching.

That takes care of that!

Question: You've got the current month percentages worked out - is there any plans to show historical by household/sister so the leaders can see who's been missed, etc?

RussellHltn wrote:Question: You've got the current month percentages worked out - is there any plans to show historical by household/sister so the leaders can see who's been missed, etc?

That is already worked out as well. I like these requests.... they are easy to fulfill. Keep 'em coming!

The names are blocked off on this list. Normally, you'd see the Sister Being Taught on the left and the district name at the top.



Brad O.

brado426 wrote:That is already worked out as well. I like these requests.... they are easy to fulfill. Keep 'em coming!

OK, what about the Custom Categories? All I see there are the standard ones. (Well, you said......)

Also, while the text is functional, I noticed that MLS has icons for them.

RussellHltn wrote:OK, what about the Custom Categories? All I see there are the standard ones. (Well, you said......)

That brings up a good point. When modifying the History chart to handle the custom categories, I figured we should only show the Standard Contact Types that are approved by the Church. If someone uses a Custom Contact Type to report, the History chart shows the type that it was set to Count As. Do you really think the Custom Contact Types should show up on the History chart because as of right now, I'm thinking not.

Also, while the text is functional, I noticed that MLS has icons for them.

Is that so? Perhaps that is a newer version of MLS that I haven't seen? Screenshot?

Brad O.

I think it's been there awhile. I'll have to collect a shot.

brado426 wrote:Is that so? Perhaps that is a newer version of MLS that I haven't seen? Screenshot?

VT1: Data entry screen

VT2: Printed report

RussellHltn wrote:VT1: Data entry screen

VT2: Printed report

Cool. I was released from our ward's EQ Presidency a few months ago, but I do not recall seeing those icons in our MLS system. Maybe I have just forgotten. If someone could provide me with the source images, I could look into adding them for the "Standard Contact Types."

Brad O.

brado426 wrote:If someone could provide me with the source images, I could look into adding them for the "Standard Contact Types."

They look like stock Microsoft ones: email, modem(?), group.

Based on Rich Marlatt's suggestion earlier in this thread, I have redesigned the Reporting screen to provide a hierarchical Contact-Type design. I also added some icons as RussellHltn suggested... See? I can steal graphics from Microsoft, too.

I need to mess with the stylesheets a bit more, but you get the general idea. As you can see, we now have our standard types (with icons) and the standard types that have custom types associated with them pop up when the user mouse-overs the menu. This is an AJAX menu, therefore it is still a one-click solution for the teachers.

Suggestions?



Brad O.

Looks great and very user friendly.

I like hierarchical, but as a second level menu seems like it's more work and it requires more hunting if you don't know the top-level category. Technically one mouse click, but it's two mouse movements to get there.

How about:

[INDENT]
Not Contacted
...Attempted
...Left the Country
Letter
Phone
Visit
[/INDENT]
(ignore the ... - that was the only way I could figure out to get indenting.)

I'm curious as to the order you chose. I reordered it into what I thought was a more logical order above.

Also, when a subcategory (custom visit type) is chosen, the text should show up on the screen with the top level (standard type) icon showing. So it might be something like "X - Left the Country". This way there is still a very clear indication to the teacher how this is going to be logged but the desired detail (custom type) is still there.

I can just see that if you put ALL the options in the main contacted menu then you could get an extremely long menu. On the other hand by having the sub-menu you make it smaller and more "sequential."

thedqs wrote:I can just see that if you put ALL the options in the main contacted menu then you could get an extremely long menu. On the other hand by having the sub-menu you make it smaller and more "sequential."

I think it really a function of how many options you have. If only a few, then a single list is better. If you've got a lot, then the two level makes sense. Personally I don't see any reasonable leader going that wild, but you never can tell. Make it an option?

Another thought - with the two level menus the way the screen shot shows, I think it encourages users to use the Standard Contact types and ignore the Customized ones because they are "hidden". That could easily skew the local level reporting.

Which I guess raises the question: Should we allow the admin to "block" selecting a Standard Types to force selecting a Custom one?

Perhaps it would help if you took a look at this live demo.

In this demo, you can report for our good fake friend, Erik Ashton. The first part of Erik's e-mail address is "Erik"

Don't worry about the license warning. I'll fix that later.

Click on this link to report for Erik Ashton using the new menu with Hierarchical View (Enter 'Erik' for the e-mail address.)

https://www.htreporting.com/htrepbeta/R ... pyear=2007

Click on this link to report for Erik Ashton using the old menu without Hierarchical View (Enter 'Erik' for the e-mail address.)

https://www.htreporting.com/htrep/Repor ... pyear=2007

It seems to me that the teacher can easily tell that there are additional options in the hierarchical view because when they mouse-over the standard contact type, the custom contact types pop up quickly. I think the menu backgrounds need to be darker because they kind of merge in with the background as it is now making it hard to read.

Brad O.

The new menu is prettier, especially with the icons. But for data entry, I like the old drop-down one better (if we can get it ordered and indented to show structure). In fact I ran into problems with the new menu. If I try to mouse "direct" from "Not Visited" to "Too Busy", I cut across "Visited" and loose my menu. It took a sec for me to realize what was wrong. Granted, I've seen it before with the Windows "Start" menu, but the fact it tripped me up and caused a few retries bothers me.

Another question - do we need to create a space for explanation text? Something as a context sensitive help to explain the options? For example, I saw "too busy". Who was too busy? The teacher, the companion or the family? Granted that might be fixed by changing the title a bit, but anyone setting up their contact types might want to give a little explanation as to what they mean.

Also I just wanted to make sure the question of disallowing standard contact types wasn't lost. In the example given, the leader might want to disallow selecting "Not Visited" and force the teachers to select an explanation for why the family wasn't visited. That's all dependent on the Contact Type schema that the leader comes up with and what they want.

RussellHltn wrote:The new menu is prettier, especially with the icons. But for data entry, I like the old drop-down one better (if we can get it ordered and indented to show structure). In fact I ran into problems with the new menu. If I try to mouse "direct" from "Not Visited" to "Too Busy", I cut across "Visited" and loose my menu. It took a sec for me to realize what was wrong. Granted, I've seen it before with the Windows "Start" menu, but the fact it tripped me up and caused a few retries bothers me.

Correct me if I'm wrong, but I think part of the problem you are mentioning is the colors. The colors of the menu are too close to the colors of the background making it kind of difficult to see the new menu when it pops up. I'll at least try to change those colors and see if that makes it clearer.

Also correct me if I'm wrong, but I believe it is impossible to do a hierarchical view like this with the old dropdown... I don't think you can even have different styled text in the old dropdown list. I think there are additional things that can be done to make this AJAX dropdown easier to understand and use. Remember, this is my first try at using these AJAX controls, so there are still plenty of tweaks available.

Another question - do we need to create a space for explanation text? Something as a context sensitive help to explain the options? For example, I saw "too busy". Who was too busy? The teacher, the companion or the family? Granted that might be fixed by changing the title a bit, but anyone setting up their contact types might want to give a little explanation as to what they mean.

That is a good point. Explanation text could be added.

Also I just wanted to make sure the question of disallowing standard contact types wasn't lost. In the example given, the leader might want to disallow selecting "Not Visited" and force the teachers to select an explanation for why the family wasn't visited. That's all dependent on the Contact Type schema that the leader comes up with and what they want.

There is currently no way to disallow the standard contact types. In my opinion, the standard Contact Types should always be available as a fallback option in case the presidency doesn't create a Custom Contact Type that applies to every situation. I thought the Custom Contact Types were supposed to optional.

Brad O.

brado426 wrote:Correct me if I'm wrong, but I think part of the problem you are mentioning is the colors.

I don't think so. The problem was I was mousing from "point a" to "point b" and while in-transit the menu changed under me. I could fix it only by traveling "square" - going horizontally until I was in the sub menu and then vertically until I got the desired selection. (This is where colors would help in keeping me "in the square", but it's already a problem.) The fix is probably in the timing to make sure things don't change in the fraction of a second that it takes me to move the mouse. But then what's good for one person may be still too quick for another (especially if they are using some kind of clumsy mouse because they are mobile.) and yet the delay bothers someone else. I'm not sure as there's a timing factor that keeps everyone happy. Anyone know of any standards in this area?

brado426 wrote:Also correct me if I'm wrong, but I believe it is impossible to do a hierarchical view like this with the old dropdown.

You can't force the order and use indenting?

brado426 wrote:There is currently no way to disallow the standard contact types. In my opinion, the standard Contact Types should always be available as a fallback option in case the presidency doesn't create a Custom Contact Type that applies to every situation. I thought the Custom Contact Types were supposed to optional.

I can kinda see the point. But with the Ajax menus, it takes an extra mouse movement to get there and I think it encourages members to use only the standard types.

RussellHltn wrote:I don't think so. The problem was I was mousing from "point a" to "point b" and while in-transit the menu changed under me. I could fix it only by traveling "square" - going horizontally until I was in the sub menu and then vertically until I got the desired selection. (This is where colors would help in keeping me "in the square", but it's already a problem.) The fix is probably in the timing to make sure things don't change in the fraction of a second that it takes me to move the mouse. But then what's good for one person may be still too quick for another (especially if they are using some kind of clumsy mouse because they are mobile.) and yet the delay bothers someone else. I'm not sure as there's a timing factor that keeps everyone happy. Anyone know of any standards in this area?

Timing standard no, but I have seen a 1/2 sec delay for the event in other programs. The only problem with web programming is that you cannot delaythe event just hold it. It might be possible to add a timer (that might be difficult any way and is most likely browser specific) and then have the time shoot an event off when the 1/2 sec from the mouse leaving event happens and then check the position of the mouse to see if it is in the submenu.

RussellHltn wrote:You can't force the order and use indenting?

Don't know about the AJax controls but you can force order and add spaces for indenting, though that I personally think is very bad because not all browsers will support the spaces and then you get weird indenting.

RussellHltn wrote:I can kinda see the point. But with the Ajax menus, it takes an extra mouse movement to get there and I think it encourages members to use only the standard types.

I don't know, but I think that it only accepts the leaf nodes as clickable so they'd have to select one of the sub menus. And even if they did use the standard types they would be getting the same information that they do now anyway. It would be the extra information about why that they would start getting from this site.

thedqs wrote:I don't know, but I think that it only accepts the leaf nodes as clickable so they'd have to select one of the sub menus.

The way it's currently implemented you do not have to go down to the last leaf node. That was one of the things I tested.

Question: What is lds.org using for it's top level menu? I was just there looking at something and could NOT duplicate my issue on their menu. I deliberately went slow and even highlighted some other top level selections, but the leaf menu stayed in place until I got there. Moving to a new top level selection and hovering felt like a 1/4 second delay to open/change and a good full second to close if I moved completely off.

thedqs wrote:And even if they did use the standard types they would be getting the same information that they do now anyway. It would be the extra information about why that they would start getting from this site.

Keep in mind we're now talking about the interface that the teachers use, so we're no longer talking about leaders that want to get information, but in "herding cats" mode.

If some teachers faithfully use the custom categories and other's don't, then the statistics don't mean much. You're not getting a clear picture.

Ok guys.... I'm going to make some changes and ask for your opinion again shortly.

I really appreciate your suggestions. They are well taken.

Brad O.

Is there a way, after you change the hometeaching companionships, to manually send to all companionships the new assignments? Or do you need to wait until the next scheduled interval.

Ben,

You do not have the ability to manually send global report-request e-mails at will. Since multiple Presidency members have admin access to the system, there needs to be some limitations otherwise, the e-mails could get sent out several times per month.

When adding the ability to send an e-mail to all those who had not reported, we had to be very careful to ensure that there were controls on this process. This is why it only allows you to use this function between the 1st and 7th of the month and only allows you to run the process once per month.

Brad O.

brado426 wrote: When adding the ability to send an e-mail to all those who had not reported, we had to be very careful to ensure that there were controls on this process. This is why it only allows you to use this function between the 1st and 7th of the month and only allows you to run the process once per month.

Otherwise you could get spammed at least 3 times if not more if the president or a counselor forgot he already sent one. Though Brad didn't you mention before in this thread that there was a work around for that?

thedqs wrote:Otherwise you could get spammed at least 3 times if not more if the president or a counselor forgot he already sent one. Though Brad didn't you mention before in this thread that there was a work around for that?

Yeah.... if a Presidency member kicks off the "Send E-Mail to all not reported" process, it sets a bit that prevents the process from being run again for that month.

Is someone in the presidency allowed to change that bit?

Cannot see any purpose in it but I am sure someone will come asking about it someday.

Yes.... a Presidency member can change the bit by going into the "System Settings" menu and unchecking a box. It will then allow them to once again use the "Send E-Mail to All Reported" (only if it is between the 1st and 7th of the month.)

This would really only be necessary if the e-mail process failed for some reason (which should normally never happen.) The status of all e-mail processes are available via a system log that can be accessed by the Presidency Members.

I'm just about finished with these "Contact Type Selector" changes. I'm quite pleased with it so far... we'll see how you guys feel about it soon.

Brad O.

Ok Guys... I made another attempt at this. Follow the link below and let me know what you think. First part of e-mail address is 'Erik'.

https://www.htreporting.com/htrepbeta/R ... pyear=2007

There is still some minor cleanup left to do, but it is mostly complete.

Edit: I just noticed that for some reason, the styles aren't rendering properly with IE6. It looks correct with IE7 and Firefox. I will get that fixed later.

Edit 2: It looks as though the problem was never a real problem. It was a caching issue with my IE6 browser. After I cleared history, the style looked correct.

Brad O.

Same issues still apply.

Also, I noticed that a message to the presidency is lumped together with email to companion and change email address. It took a bit before I figured out there were different functions and what element went with what function.

Hmm.... I'm not noticing anything that would cause confusion with the Contact Type menu as it is now. If we want hierarchical contact types, the child contact types need to pop up somewhere when the parent types are selected. Showing everything on the screen at once is just too much.

Looks good in Netscape 7.2, except that the "change email" button leters are cut off. Firefox 2.0.0.4 is perfect. It's not too cluttered. It's easy to know intuitively just what needs to be done. Anyone confused about what to do can follow the simple, direct instructions.

The biggest issue is timing of the menus. It's very sensitive to the speed and route I take to get from the standard contact type to the custom leaf. It could prove very frustrating to someone using an "eraser-head" mouse. As it stands now, I have to slid sideways and then vertically to find my selection. If I attempt to go "direct" the menu is likely to disappear on me.

A good example of timing is the lds.org menu system. I'm surprised how much I can deviate without getting the menu to twitch. While it is just a bit slower, it doesn't seem to be a problem.


There is no confusion with the contact types. But only in the last post did I notice that 3 other functions below the contact reporting were getting mixed together in a way that's confusing.

The links in the status column don't seem to work in Konqueror 3.5.5, release 45.4, on openSUSE 10.2.

The error I get is:

EO.Web Controls Client Side Debug Message:
Object 'ctl00_contentPane_menuStatus' does not exist.

Paulstone: This is the response I received from EssentialObjects (the company that makes the menu control I'm using.)

Konquerer is an open source browser from KDE people, I believe Apple's Safari actually used its core DHTML rendering engine KHTML. Neverthelss while Safari is officially supported by us, Konquerer is not. Due to the market share of Linux itself and the popularity of FireFox on Linux platform, Konquerer seems to be used by very few people.

Russell: I think I now understand what you are looking for. I'll make some more changes.

Brad O.

Russell, I think I have addressed the issue you were referring to. As you can see, the submenu no longer closes when you move the pointer away from it.

Please take another look and let me know.

First part of e-mail address is 'Erik'

https://www.htreporting.com/htrepbeta/R ... pyear=2007

Thanks,

Brad

It's better. However if my travel from "Not visited" to the flyout takes me across "visited" the menu changes on me. I think lds.org had a quarter second delay in changing flyouts.

It's not necessary to leave the menu on continuously if the pointer is moved off. But if you can set a delay for a second or so, that will work.

RussellHltn wrote:It's better. However if my travel from "Not visited" to the flyout takes me across "visited" the menu changes on me. I think lds.org had a quarter second delay in changing flyouts.

It's not necessary to leave the menu on continuously if the pointer is moved off. But if you can set a delay for a second or so, that will work.

There is now a quarter second delay on the submenu expansion. How is it now?

As usual, first part of e-mail is 'Erik'

https://www.htreporting.com/htrepbeta/R ... pyear=2007

Brad O.

Much better! It's functional now, but if possible, there are a couple of minor improvements. (lds.org's example spoiled me)

The first on is it would be nice of the entire menu system closed up if the mouse left it for 2 seconds. Right now it says open until something is clicked.

The second one is if from moving from "Not Visited" I drift across "Visited" and don't make it back to the flyout within the quarter second, the flyout changes even though I'm no longer hovering on "visited". I think it's because "visited" says lit even though I'm no longer on it.

RussellHltn wrote:Much better! It's functional now, but if possible, there are a couple of minor improvements. (lds.org's example spoiled me)

The first on is it would be nice of the entire menu system closed up if the mouse left it for 2 seconds. Right now it says open until something is clicked.

I'll look into that.... Though I'm sure there is a way, I'm not seeing a straightforward way to do it.

RussellHltn wrote:The second one is if from moving from "Not Visited" I drift across "Visited" and don't make it back to the flyout within the quarter second, the flyout changes even though I'm no longer hovering on "visited". I think it's because "visited" says lit even though I'm no longer on it.

It seems to me that lds.org's menu works the same way. If you scroll down to another menu item momentarily and then to your submenu, you get the submenu of the lower menu instead of the upper.

Brad O.

brado426 wrote:I'll look into that.... Though I'm sure there is a way, I'm not seeing a straightforward way to do it.

Yeah, I'm not sure what timings you have available. I don't even know if the lds.org is using the same technology.

brado426 wrote:It seems to me that lds.org's menu works the same way. If you scroll down to another menu item momentarily and then to your submenu, you get the submenu of the lower menu instead of the upper.

lds.org: Hover over "About the Church" long enough for the flyout. Now move the mouse slowly down the list. Each item will highlight as you go over it, but as long as you don't stay on for a quarter second, the flyout won't change. Now there's the difference: When you slide off the bottom of the list, "News and Events" looses the highlight. Done at the right speed, the original flyout menu from "About the Church" is still there. With this setup, I can go from "About the Church" down though the list, and then to the right to find "Stake and Ward Websites". (A wrong way "L" path) As long as I don't hover over one of the other selections, I can take my time. And once I'm off the list, I have all the time in the world to make the move to the flyout.

With htreporting, when I slide off the bottom of the list, "Visited" remains lit and then a quarter second later, the flyout from "visited" kicks in even though the mouse is no longer there. It's a different action when you slide off the first list and haven't yet gone to another. It upsets the desired timing. The key is to loose the highlight when the mouse is no longer on the object.

Got it Russell.... thanks. I think I'm going to roll the new menu out as is to the testers and see how things go. I sent out an e-mail to the testers a couple days ago and received positive feedback about the new menu. My main concern now is browser compatibility.

I added the icons to the report, which I think adds some value in that it makes the report easier to read. For the custom Contact Types, the associated Standard Contact Type icon shows.

I also redesigned the interface the allows the Presidency to manually update the reported statuses. It is far faster, easier to use and generally superior with the new AJAX menu.



Brad O.

brado426 wrote:My main concern now is browser compatibility.

Basically the major browsers IE 6/7, FireFox and Safari since those come installed by default on most machines. As for a summary of what people are viewing this site with see [thread=157]Tom's thread on how the site is doing[/thread].

Below is a summary I sent to the testers of other changes that were made over the past week.
______________________________________________________________________

In addition to the new menu, several other changes and bug-fixes have been made:

1. Contact Type icons have been added to the report as shown below. For Visiting Teaching, Phone and Letter icons appear.



2. The “Edit Results by Household/Sister” function has been completely redesigned utilizing the new menu. This makes manually changing HT/VT results much easier. When clicking on the "Edit" link, the Contact Type menu will pop up so you can quickly select the new status for the desired household/sister.



3. Added “No Change” option to Contact Type menu in case the user decides not to make a change after clicking on and opening the menu.

4. Fixed a problem that caused the Contact Type to display in the Pie Chart Legend even if it was not marked as “Chart Separately.”

5. Contact Types that are marked as "Chart Separately" now show up on the Pie Chart Legend even if their total is zero (0).

6. Fixed a problem that occasionally caused a 10 second delay when first attempting to access the site.


7. For the "Send E-Mail" option, the E-Mail options now always show at the top of the screen whether or not the teacher you have selected has a configured e-mail address. However, only the E-Mail options that are applicable to the teacher you have selected will show. For example, if you have selected a teacher that does not have a configured e-mail address, the only e-mail options that will show will be "Send E-Mail to all those not reported" and "Send E-Mail to All Teachers."

Brad O.

This is looking really good. I hope soon we can get it rolled out for testing in some units.

The Earl wrote:This is looking really good. I hope soon we can get it rolled out for testing in some units.

I want to remind everyone that the Church has a policy about exporting information from MLS or LUWS and importing that same data into a server not officially sponsored and supported by the Church. You can use the data on your own "controlled" and "secure" PC's, laptops, and PDA's. However you are not allowed to host sites for your ward that would utilize this exported information.

This project is a "prototype" of what should or could be done. It is an excellent project and we have people at the Church watching this. We are looking at ways to either use this code or use the concepts of this code to make something more official. However this process takes time as we have to code secure ways for us to allow access to key data. We are looking at alternatives to speed up the process but nothing is definitive yet.

Don't shoot the messenger.

Tom

brado426 wrote:Below is a summary I sent to the testers of other changes that were made over the past week.
______________________________________________________________________

-----snip------
2. The “Edit Results by Household/Sister” function has been completely redesigned utilizing the new menu. This makes manually changing HT/VT results much easier. When clicking on the "Edit" link, the Contact Type menu will pop up so you can quickly select the new status for the desired household/sister.
----snip----

What is meant by the term "household/sister"? VT are individually assigned. A single household may have multiple VT assigned.

scion wrote: What is meant by the term "household/sister"? VT are individually assigned. A single household may have multiple VT assigned.

Household is for Home Teaching while Sister is for Visiting Teaching.

For Home Teaching, the menu option is called "Edit Results by Household" which lists all the Households and allows the Presidency to manually edit each household's status.

For Visiting Teaching, the menu option is called "Edit Results by Sister" which lists all the Sisters and allows the Presidency to manually edit each sister's status.

The terminology is taken directly from the MLS system.

Brad O.

Thanks. That makes sense.

I want to run something by you guys.... and that is the subject of security with this site. I believe the security model is pretty good as is, but I would like to get your opinions.

First, let me say that I strongly believe that we should not require the teacher to enter a username/password combination when reporting. I believe that if we require this, it will cause way too much complication and significantly decrease the percentage of results reported by the teachers.

That being said, let me explain how the security currently works.

The url that the users link to contains a User ID, a User Code, and verification Key.

https://www.htreporting.com/htrepbeta/ReportStats.aspx?key=54a32334&id=8&userid=46&code=31321&repmonth=7&repyear=2007

The ID is an integer that tells the system which group the user belongs to.

The User ID is an integer that tells the system which user is logging in.

The code is a 3 - 5 digit hex number that is automatically generated by the system when the users e-mail address is set up. This password does not (and cannot) change unless the teacher's e-mail address is remove and re-added. If this password changes, all previous links sent to the teacher will no longer work.

The key is an 8 digit hex number that ensures that the url has not been altered. If the url is altered, the system will display a message stating as such and not allow the teacher to report.

In addition to these three pieces of information contained in the url, the teacher is required to enter the first part of his or her e-mail address before accessing the reporting screen. This ensures that if the link gets into the wrong hands, that person must also have the necessary e-mail address.

All information transferred to and fron the site is encrypted using SSL, so the data cannot be intercepted between the client and the server.

Additionally, the links expire after 2 months so even if they did get into the wrong hands, they wouldn't be of much value.

Each teacher can be assigned an access level of Teacher, Supervisor, or Presidency Member. Only Presidency Members have the ability to change the access levels. Those who have Presidency Member access will notice an "Admin Menu" button in the upper right-hand corner when they access their reporting screen for which they can easily access the 'Admin Menu.' Supervisors also see the 'Admin Menu' button, but they will not have access to all the menu-items available on the 'Admin Menu.'

I believe that things are pretty darn secure as is, but I think it could be improved.

The specific questions I have for you are:

1. Do you think the Presidency Members should have a username/password? If their link got into the wrong hands and that person knew the first part of their e-mail address, they could run a-muck if they wanted to.

2. What do you think of the "no username/password" for teachers model? In my opinion, it is absolutely critical, but I'm guessing some of you may disagree with me.

3. If a teacher does not want their name in the system at all, how should it be handled? The teacher would still need to be in the church's records... just not online for HT/VT Reporting purposes. I'm envisioning an option for the Presidency to add a particular teacher to a list of "removed" teachers and the system would make that person pretty much invisible.

Brad O.

For getting rid of the username password you could use a SAW type implementation. (SAW was developed by BYU and it is patented.) You can read more at http://isrl.cs.byu.edu/publications.php and select the paper about Simple Authentication for the Web. Since the church would be looking into implementing this site, this might be a possible way for the church to implement this security (I am assuming that the church can use BYU's patents).

By the way is the key the key used for the hash function to create the verification code? If so then once someone figures out the hash function then they could create their own url and be anyone.

thedqs wrote:By the way is the key the key used for the hash function to create the verification code? If so then once someone figures out the hash function then they could create their own url and be anyone.

Oops, the descriptions weren't matching the elements in the url. I have edited my previous post to make it clearer.

Each teacher has his or her own unique code so there is no way that anyone could modify the links to impersonate anyone else.

The key ensures that the url has not been modified. If the algorithm behind the key was somehow compromised, the worse that could happen is someone could change the link to allow them to report for a different month and year than the link was designed for. Even that wouldn't really be an issue because the system does not allow anyone to report for future months or more than 2 months in the past.

Another layer of security that could be added would be to munge the url's so that the url values wouldn't be readable at all.

I wasn't aware of that technology that BYU came up with. I'll take a look at it. Thanks.

Brad O.

What I meant about the unique code is someone could sniff the header and get a user's code. Then they could hash it and impersonate the person who's code that was. I was going from the outsider trying to get in. Of course if you generate a new pseudo user id for each month then I couldn't take last month's userid and try to report this months.

Basically the more constants you remove the better, of course that means more computing and sophistication to allow authorized users to connect.

As for the BYU tech, I hear about it every MWF since my professor is Tim and he helped create it.

brado426 wrote:1. Do you think the Presidency Members should have a username/password? If their link got into the wrong hands and that person knew the first part of their e-mail address, they could run a-muck if they wanted to.

I think that would be a good idea. Keep in mind that some families share the computer, so stuff sent via a link are not secure from other family members or house residents (think student dorms).

Now, does your system not allow traditional password/logins or is this just a way not to require them? Because as it seems now, the teacher must wait for their email for the link to get in. That may not sit well with some users who would rather be able to go to a easy to memorize URL (saved to their favorites) and log in.

And speaking of favorites ....... A URL that changes routinely is likely to create problems on that front as well. My suggestion there is if a invalid URL is found, that they are routed to the login screen. That way a saved favorite will always take them to the login screen.

RussellHltn wrote:...
Now, does your system not allow traditional password/logins or is this just a way not to require them? Because as it seems now, the teacher must wait for their email for the link to get in. That may not sit well with some users who would rather be able to go to a easy to memorize URL (saved to their favorites) and log in.
...

A question about this email message the user must wait for: Does the user trigger the email to be sent by attempting to access the site (instead of the more common username and password entry), or is this message coming from elsewhere to tell the user to go to the site and report the visits? If the former, the user may find that delays of several minutes (or longer) would be very problematic. Some ISP mail servers can delay messages by quite a few minutes. Myself, I use fetchmail on a five minute cycle.

In response to Russell's and Robert's questions about email latency. The SAW program as demonstrated seems to operate quite quickly, especially if you have the SAW toolbar. Demonstrations showed that going to the login part of the site (saw toolbar then says that you can log into the site) and clicking the button has the email sent to your account and the saw toolbar logs in and you are in very quickly. Of course you can disable the auto-email-login so maintain computer security if you have multiple users on the single account.

I am assuming that both were talking about SAW.

RussellHltn wrote:I think that would be a good idea. Keep in mind that some families share the computer, so stuff sent via a link are not secure from other family members or house residents (think student dorms).

Now, does your system not allow traditional password/logins or is this just a way not to require them? Because as it seems now, the teacher must wait for their email for the link to get in. That may not sit well with some users who would rather be able to go to a easy to memorize URL (saved to their favorites) and log in.

The system does not currently support username/password logins at all. It is all link-based. If the link makes it to your e-mail address, you can get in and report. This is why I think that at least the Presidency Members should probably be allowed to set up username/passwords to gain access. The system needs to send e-mails to the teacher to ask them to report anyway, so they will be guaranteed to get a link for the new month to report with. The frequency that the report request e-mails are sent depends on how the Presidency has configured the system.

And speaking of favorites ....... A URL that changes routinely is likely to create problems on that front as well. My suggestion there is if a invalid URL is found, that they are routed to the login screen. That way a saved favorite will always take them to the login screen.

The url for a given month never changes. So when the e-mail link for July is sent, it will work any time for reporting July's results. After the 15th of the next month (for example, August in this case), the link will expire.

rmrichesjr wrote:A question about this email message the user must wait for: Does the user trigger the email to be sent by attempting to access the site (instead of the more common username and password entry), or is this message coming from elsewhere to tell the user to go to the site and report the visits? If the former, the user may find that delays of several minutes (or longer) would be very problematic. Some ISP mail servers can delay messages by quite a few minutes. Myself, I use fetchmail on a five minute cycle.

The e-mails that request the teacher to report are scheduled by the Presidency. The Presidency can have it send requests one, two, or three times per month. There are pre-set schedules that can easily be selected. For example, one schedule is for report request e-mails to be sent on the 8th, 18th, and 2 days before the last day of the month.

The e-mails for the 8th and the 18th are considered "Preliminary Report Requests." The last request of the month is considered the "Final Report Request."

If the Presidency wants teachers to be able to report early in the month, the system can be configured to send links to the teachers on the 8th. If a teacher marks all his or her assigned families/sisters as Visited/Contacted, the system will not send any additional e-mails to the teacher.

Nothing in the process requires a teacher to wait for an e-mail to be sent. The e-mail just shows up in their inbox.

Brad O.

You guys got me thinking. I'm going to make a change so that if someone tries to pull up the same url with the wrong code too many times in a 5 minute period (maybe 3 times), it won't let them back into the system for 5 or 10 minutes. This should make it nearly impossible to hack the user access code even if the algorithm that checks the url is compromised.

Brad O.

brado426 wrote:I'm going to make a change so that if someone tries to pull up the same url with the wrong code too many times in a 5 minute period (maybe 3 times), it won't let them back into the system for 5 or 10 minutes.

That's a good idea. We can't be sure of what someone might try. Perhaps it's a anti-Mormon group that simply wants the names and addresses of someone to target. They don't care what teacher they get in as and they'll assign a random number generator until they get in.

tomw wrote:I want to remind everyone that the Church has a policy about exporting information from MLS or LUWS and importing that same data into a server not officially sponsored and supported by the Church. You can use the data on your own "controlled" and "secure" PC's, laptops, and PDA's. However you are not allowed to host sites for your ward that would utilize this exported information.

This project is a "prototype" of what should or could be done. It is an excellent project and we have people at the Church watching this. We are looking at ways to either use this code or use the concepts of this code to make something more official. However this process takes time as we have to code secure ways for us to allow access to key data. We are looking at alternatives to speed up the process but nothing is definitive yet.

Don't shoot the messenger.

Tom

Tom,

I know that approval and Churchwide distribution of this extremely valuable tool will understandably take time. However, the true value can be best demonstrated by live testing. What is the possibility of you obtaining authorization for Brad to do live testing with a handful of stakes? It is the logical next step.

Jerry

jerbarb wrote:Tom,

I know that approval and Churchwide distribution of this extremely valuable tool will understandably take time. However, the true value can be best demonstrated by live testing. What is the possibility of you obtaining authorization for Brad to do live testing with a handful of stakes? It is the logical next step.

Jerry

I've talked with Brad about some options and I can't promise anything but I am working on some shorter term alternatives.

Tom

tomw wrote:I've talked with Brad about some options and I can't promise anything but I am working on some shorter term alternatives.

Tom

Tom-

This is a terrible loss. Let us know what we need to do to save this site. Our wards Home Teaching improved by 28% as a result of this tool and two families have been reactivated as a direct result of these improvements.

This is an irreplaceable tool for those of us living in the mission field.

Enrique, are you saying that your ward or stake is currently actively using the site with real data? (Or was using since it seems that it stopped)

A few groups did use the site for a period of time with live data until it became apparent that this was not allowed by the Church.

Brad O.

thedqs wrote:Enrique, are you saying that your ward or stake is currently actively using the site with real data? (Or was using since it seems that it stopped)

thedqs-
Yep. You see unlike scouting.org and ymyw.org which it seems violate current church policy. This site only had public record data on the stie (aka Names of the head of household.)

Tomw-
What is the status of locating an internal server to park this on? We have some brethren that would be willing to contribute a server and their time to install it.

enriquer wrote:thedqs-
Yep. You see unlike scouting.org and ymyw.org which it seems violate current church policy. This site only had public record data on the stie (aka Names of the head of household.)

For everyone's information, the only data from MLS required by this HT/VT reporting application is as follows:

• Teacher Name, Phone, and E-Mail
• "Assigned Household Name" for Home Teaching or "Sister Name" for Visiting Teaching and Phone
• Percentage taught for each Household/Sister

E-Mail addresses are only needed for the Home/Visiting Teachers.

Brad O.

enriquer wrote:Tomw-
What is the status of locating an internal server to park this on? We have some brethren that would be willing to contribute a server and their time to install it.

It's not an issue of finding a server or the bandwidth. It is more a procedural issue. What kind of presidence does this set for other apps? What if the app has security issues or holes? What if the software has bugs? I just have to work through the proper channels to get all of the necessary buy-off.

Tom

tomw wrote:It's not an issue of finding a server or the bandwidth. It is more a procedural issue. What kind of presidence does this set for other apps? What if the app has security issues or holes? What if the software has bugs? I just have to work through the proper channels to get all of the necessary buy-off.

Tom

This is encouraging.

Are we talking days, weeks, or months?
Is there anything we can do to help this effort?
Given this site only contains public record data can the test environment continue until the transition to the church hosted environment is made?

enriquer wrote:This is encouraging.

Are we talking days, weeks, or months?

I don't know. Please realize that I may never get the go ahead.

Is there anything we can do to help this effort?

Not at the present time.

Given this site only contains public record data can the test environment continue until the transition to the church hosted environment is made?

Please do not continue using the site.

Tom

Would it be safe to assume that it isn't in our best interest as developers to create any tools that are web based because they would at some point require data to be stored within them? It appears that a tool such as this one that doesn't get the go ahead and actually gets shut down, is a good sign that the "support the church technology community" isn't going to work.

At least not from a "be creative" stand point.

It's really a ping the technology community for answers to the questions we ask site isn't it.

I apologize if I sound a little frustrated but, I see this type of thing happen in Bureaucratic environments where something very useful is pitched and pursued only to be shut down because of a "policy."

Isn't that contradictory to the concept that technology is here to build the kingdom. If it's secure, it works and there is no cost to the church why not use it.

I believe that I have read that the development is volunteer and the hardware can be donated to run it...what would be the hold up or concern?

Mr. M wrote:It's really a ping the technology community for answers to the questions we ask site isn't it.

I think you're way off here. Sure the Church employees have many questions they are trying to get feeback on, but I feel the site has served much more of a purpose than that. I've never seen so many great ideas and enhancements flourshing, helpful tips and fixes, productive time-savers, and so on, so forth. This has been a wellspring of thought and creativity.

Mr. M wrote:I apologize if I sound a little frustrated but, I see this type of thing happen in Bureaucratic environments where something very useful is pitched and pursued only to be shut down because of a "policy."

Isn't that contradictory to the concept that technology is here to build the kingdom. If it's secure, it works and there is no cost to the church why not use it.

I believe that I have read that the development is volunteer and the hardware can be donated to run it...what would be the hold up or concern?

First off, the project isn't shut down nor near it. Tom is just giving it to us straight so as not to get anyone's hopes up prematurely. In fact, because it's one of the first major projects actually going somewhere with the community, I bet there are many eyes from the Church watching and waiting to see what will come of it. There is a lot of infrastructure (both technological resources and human resources) to be set up in the Church to be able to cooperate with the community on such a large scale like this.

I say please be more patient as implementing such a new direction takes time and planning for such a large, global organization as the Church. Remember that we are a Church that numbers every individual, and with that comes major reponsibility for sensitive information that has to be kept secure. Can you imagine the liabilities the Church could face if something the community developed went dreadfully wrong? Also, think about the fast-paced, selfish business world that we live in today. All of the patent and copyright laws, greedful suing for money, etc. It is an environment devoid of cooperation and sharing, a dangerous environment totally against what the Church needs to grow in this way. The Church cannot waste it's time and money on lawsuits. Is it any wonder the Church is so conservative and cautious in such things?

The Church will get there to your vision in time, Mr. M. It will just take a little time. Who knows where we'll be a year from now? It may surprise you.

I think mkmurray said it pretty good.

I also think we just need to be patient. When starting this project, I realized it was probably a bit ahead of its time and understood the risks.

The benefits provided by this system are enormous, so the people that were helping test did feel a fairly significant blow once these benefits were taken away.

I do wish the Church could provide us with permission to at least run the site in a "pilot test" scenario because it is pretty much impossible to further enhance the system without it. At the same time, I understand that the concerns of the Church.

I am confident that things will work themselves out in due time.

Also, I believe this LDS Tech message board is a great thing. Look at this thread alone. There is no way we would have been able to add all these additional features and enhancments without the community's input.

Brad O.

mkmurray wrote:I think you're way off here. Sure the Church employees have many questions they are trying to get feeback on, but I feel the site has served much more of a purpose than that. I've never seen so many great ideas and enhancements flourshing, helpful tips and fixes, productive time-savers, and so on, so forth. This has been a wellspring of thought and creativity.

First off, the project isn't shut down nor near it. Tom is just giving it to us straight so as not to get anyone's hopes up prematurely. In fact, because it's one of the first major projects actually going somewhere with the community, I bet there are many eyes from the Church watching and waiting to see what will come of it. There is a lot of infrastructure (both technological resources and human resources) to be set up in the Church to be able to cooperate with the community on such a large scale like this.

I say please be more patient as implementing such a new direction takes time and planning for such a large, global organization as the Church. Remember that we are a Church that numbers every individual, and with that comes major reponsibility for sensitive information that has to be kept secure. Can you imagine the liabilities the Church could face if something the community developed went dreadfully wrong? Also, think about the fast-paced, selfish business world that we live in today. All of the patent and copyright laws, greedful suing for money, etc. It is an environment devoid of cooperation and sharing, a dangerous environment totally against what the Church needs to grow in this way. The Church cannot waste it's time and money on lawsuits. Is it any wonder the Church is so conservative and cautious in such things?

The Church will get there to your vision in time, Mr. M. It will just take a little time. Who knows where we'll be a year from now? It may surprise you.

Let me say I am a total advocate for tapping resources, I will explain shortly.

My post was based off an email that I received last week indicating that the site had been shutdown. It was from Brad, as he is trying to uphold what the church has asked of him. I came here to see if there was any update since last week and there is and it coincides with what was explained to me. I am not bashing...I don't think that I am being unfair. I am being sincere in my concern here.

I personally spent a year on a church project, that was a huge success. I made the development commitment with the "impression" that it would be used church wide for temple dedications. It was used for the Sacramento dedication. Everyone was ecstatic and it fulfilled its responsibility. Then it was passed up through the chain of command and the only thing I ever heard about it after that was, the church will get back to you but for now shut it down. I shut it down...and still a year later haven't heard anything back. I actually put a post up here a while back about it too.

It's a .NET MSSQL event volunteer mangagement system. It managed 8500 volunteers, 22 stakes, their wards, their leaders, and 175,000 visitors with reporting and printed badge generation. At the request of the church, I deleted the data immediately following the event...and kept the code base. It was not a commission project. I was the sole developer, with an support and QA team of four. If anyone would like the code. Email me and you are welcome to it.

I also want to make sure that no on thinks I am bashing...I too am just telling it straight.

Mr. M wrote:I apologize if I sound a little frustrated but, I see this type of thing happen in Bureaucratic environments where something very useful is pitched and pursued only to be shut down because of a "policy."

I appreciate your concern and even your frustration. We have so many projects on our plate right now that it just takes time to get new things reviewed.

Tom

I had a post that I debated somewhat on the lines of what Mr. M posted. I see this project as an indication of how this process works.

I understand that the church has a lot of process to get these things live.

My fear is that we will lose good people with great ideas if these projects disapear.

I have a few suggestions for a place to put these files:

1. Separate it from the existing LDS.ORG domain. It doesn't even need to be on LDS.ORG. Keep things on a separate network / vlan. You probably still want the machines in-house so you can protect them with your existing firewall / IDS / monitoring, but there is no reason for these projects to be able to talk to any church systems.

2. Only allow projects that use MLS export data and hand-entry. It sounds as though legal has determined that the MLS export data is what they are comfortable with people dragging around with them.

3. Make local admins / leadership responsible for the data. If local leaders and admins have some skin in the game, they should make educated decisions about what data to load and how security should work.

4. Allow limited testing for security. Probably the best way to verify security is to get a few people to beat on the app, and a few trusted people audit the code. These would not have to be church employees, but community members could give the app the once-over.

Let me know if there is anything I can help with to get this rolling. I can't stress enough the importance of keeping these projects moving if we want to keep this community working.

Excellent suggestions. Thanks for the input.

Tom

I forgot one suggestion.

Do you have some dummy MLS data that we could use for testing? It would be nice to be able to test the apps without worrying about the data getting out.

Here, we craft data by corrupting existing datasets. Often we replace names with fictional characters, and mix records.

We might take:
Jeff Jones
DOB: 10/12/2002
SLC, UT

Mark Waters
DOB: 10/21/1888
SF CA

and end up with Mark Jones DOB 12/10/1888, SF, UT. and Cinderella DOB 10/21/1988, SLC, UT

That gets us data that is close to our original, but does not
leave the data recognizable.

Thanks

MLS had a practice ward and stake.

Unit #108 is the ward and Unit #2224445 is the stake. If you have access to MLS, simply create the new ward and/or stake and the fake data will appear.

RussellHltn wrote:MLS had a practice ward and stake.

Unit #108 is the ward and Unit #2224445 is the stake. If you have access to MLS, simply create the new ward and/or stake and the fake data will appear.

So I assume the suggestion is that you could export the fake ward info from MLS and then upload that into the test website?

Test data can be helpful for certain things, but it only goes so far. Without feedback from an active group of users, it is extremely difficult to identify bugs and learn what works in real-life and what doesn't.

This app is kind of like a living organism. It exhibits different behaviors throughout the month. You can test all day long, but that won't guarantee you will find all the issues. For example, thousands of people need to access the system to report. This means just about every browser and security setting configuration within the browser needs to work. Also, the people using the system are of varying experience levels. What seems to be good for us tech-freaks may not work out so well for your standard EQ President or Visiting Teaching Coordinator.

The point that I am trying to get at is that I have found active testing to be absolutely critical for this project in particular.

Even more importantly, if no one is benefiting from actually using the system, my motivation level decreases to a critical level.

Brad O.

mkmurray wrote:So I assume the suggestion is that you could export the fake ward info from MLS and then upload that into the test website?

Correct. The information isn't as useful as real information. But it's a start. It saves time trying to manufacture information for first round of testing and at the same time tests the export process.

Wish I had a solution for the bigger issues here. My only hope is the church finds a way to allow for limited demonstration projects. I'm sure at some level the question is going to come up - "how much of a difference does it make? Is this just wiz-bang or does it really make a difference?" It would certainly be helpful for the church to answer those questions at low cost (and low risk).

Hopefully something can be worked out, so that with a review that reasonable precautions taken, it can be tried out without creating too much of a burden on the church's staff.

I have seen where the Church moves very slowly on these kinds of things - even slower then the staff expects. So all I can suggest at this time is patience. (And the quote that patience is the ability to hide your impatience. )

tomw wrote:I don't know. Please realize that I may never get the go ahead.

Not at the present time.

Please do not continue using the site.

Tom

Tomw-

Just so you know we have no issues complying with this. It is just unfortunate that the benefits this tool brought the familys which were visited will be lost.

I do have to report back to my leadership on this. So help me understand the logic here....if we are cannot continue using this site, which once again, only has public record info on it that is secured. They why does the church allow other less secure publicly accessible sites such as ymyw.org, scouting.org, and all the singles wards sites to continue to exist?

Shouldn't they be told to shutdown as well?

enriquer wrote:They why does the church allow other less secure publicly accessible sites such as ymyw.org, scouting.org, and all the singles wards sites to continue to exist?

Shouldn't they be told to shutdown as well?

I asked Tom the same question on [post=5243]this post[/post], but he probably didn't see the question. I am also interested in this response. Thanks.

Minor point: There is a difference between telling a private website to shutdown and telling leaders that they may not load information into it (effectively preventing leaders from using some of the ones mentioned.)

So I think a more accurate re-phrase of the question is: Why haven't the leaders been told not to use these sites?

One observation I'll make is that we, the tech folks, have been told in this forum not to upload MLS data to any website (or was that just 3rd party website?). However, no such letter has been sent to the leaders. I think that's creating some of the issues here - the leaders and the techs are not on the same page about what's allowed. The leaders are following what's in their manuals and been received on church letterhead and the tech are saying "I read in the forum....."

Worse, stakes whose techs haven't visited this forum don't know about this restriction and are happily going along. /:mad:

RussellHltn wrote:
One observation I'll make is that we, the tech folks, have been told in this forum not to upload MLS data to any website (or was that just 3rd party website?). However, no such letter has been sent to the leaders.

Worse, stakes whose techs haven't visited this forum don't know about this restriction and are happily going along. /:mad:

The leaders have been sent a letter. This letter appears to be all-inclusive and provides no exceptions whatsoever. This is the clarification that Enrique was looking for in his post in the General Discussion group. Unfortunately, I do not believe anyone has been able to acquire that needed clarification yet.

I agree that if there are other sites that are in violation of that policy, members should not be using them. What is the purpose of having a policy if it doesn't apply to everyone and everything?

I know this is the third time I'm saying this, but uploading data or entering data renders the same result. I strongly believe that the manual entry of data should not be used as a way to bypass the Church's data security policy.

Brad O.

brado426 wrote:The leaders have been sent a letter. This letter appears to be all-inclusive and provides no exceptions whatsoever.

Are you talking about one more recent? The only letter(s) I know of spells out that a unit may not have a website. I don't think it really covered use of a commercial website. The whole thing about uploading/entering member data into a website wasn't really covered except for in this forum. The whole nature of what websites were about has changed since the original letters.

RussellHltn wrote:Are you talking about one more recent? The only letter(s) I know of spells out that a unit may not have a website. I don't think it really covered use of a commercial website. The whole thing about uploading/entering member data into a website wasn't really covered except for in this forum. The whole nature of what websites were about has changed since the original letters.

I'm referring to this letter that Enrique was asking about in this thread:

http://tech.lds.org/forum/showthread.php?t=576

It says "No other websites are allowed" which seems to cover pretty much everything including commercial websites.

Brad O.

There were alot of units that had sites on the free commercial websites, e.g. Tripod.com, Angelfire.com, Xoom.com (defunct), and many others. Almost all of them disappeared after the March 2001 letter.

Most are still around, like Angelfire and Geocities, although others have either disappeared or were folded into the other services. But there is not much difference other than the coding used in some personal sites now than there was in 2001. The only other idfference is they have now have much more storage space than they did then.

There were a few LDS groups that did host unit websites also, such as ldsstakes.com, but that also went down as well.

brado426 wrote:It says "No other websites are allowed" which seems to cover pretty much everything including commercial websites.

OK, I see what you are getting at.

Still, the Church is not going to send a letter to PictureThis, Inc or to the Boy Scouts of America to take down their sites. The church will direct their own leaders to not use those sites.

As for why units use those sites despite "the letter", well, I guess that's one of the mysteries of the kingdom.

What do you people think about pilot testing the system using only Family1, Family2, Family3, Teacher1, Teacher2, Teacher3, etc? That way we could use it for real data without having any personal data in the system. The teachers would keep a printout to correlate the real names with the web codes, so it wouldn't be as convenient, but it could still be tested in a real environment and provide real value to wards.

Eric

poulsone wrote:What do you people think about pilot testing the system using only Family1, Family2, Family3, Teacher1, Teacher2, Teacher3, etc? That way we could use it for real data without having any personal data in the system. The teachers would keep a printout to correlate the real names with the web codes, so it wouldn't be as convenient, but it could still be tested in a real environment and provide real value to wards.

Eric

paulsone,

I think that would cause a bit too much confusion for those who are trying to report. The teachers wouldn't know which family they were reporting for. It is hard enough for teachers to hang on to their slip of paper to begin with. I think requiring them to hang onto a slip of paper that just has relationships between real names and fake names would hurt rather than help.

What if we removed all phone numbers and automatically converted all names into initials? I wonder if we could get away with that?

Brad O.

I am pretty sure that this system will get integrated eventually into LDS.org and we just have to be patient. And I know that all of you think the same thing. As the techies we are used to getting very fast results and resent having to wait for something (dial-up anyone?) but in this case I would want a church seal of approval and also it being hosted on a church site to prevent duplicated personal (public) information.

I just received this letter from my mom's Relief Society President, who was helping test the system. I thought I'd share it with you. I did explain the situation to her. Mickey gave me permission to post this message here on her behalf.

_____________________________________________________




To Whom It May Concern:

We in the Hacienda Heights Second Ward in California have had the great opportunity to use the Visiting Teaching Website. It is now closed down and we are disappointed and want to know when we will be able to use it again.

The sisters loved the visiting teaching program and our efforts in managing statistics and reports became more efficient and timely. One advantage was that we were able to get ahold of women for reporting much more easily. Some women were nearly impossible to get hold of and only used cell phones. With the computer program, which included reminders, they found reporting their visits to be extremely easy, and the reminders were appreciated. As a presidency we were so glad to be able to look at a chart before the month was over and see the areas of concern and then be able to do something about them before the month was over. Otherwise, we didn’t know how we did on the previous month until well into the next month.

The best part is that more sisters were visited when we used the program and those who had done the reminder and reporting calls could spend more time on humanitarian efforts. For the last month we used the program our statistics rose and the report was very near 100% visiting teaching!

Please let us know of the status of this program.

Sincerely,
President Mickey Bladh
Hacienda Heights Second Ward
Hacienda Heights, California

Here is another one. This is one is from my Ward. From what I've seen, it seems that the Sisters gained the greatest benefit from this system.



To Whom It May Concern:

The Foothill Ranch Ward found the Visiting Teaching Website to be extremely valuable.

The sisters loved the ease of reporting and the supervisors and secretary were more easily able to manage statistics and reports.

We were able to reach more sisters using the computerized reporting and had more prompt replies. The reminders to do your visiting teaching and report in a timely fashion were extremely helpful.

Through this reporting program we believe more sisters were visited because of the reminders and ease of reporting. For those sisters not acquainted with the computer, phone reporting was still available and much easier to do because of the limited number of phone calls necessary.

As a presidency we were able to consistently see how the visiting teaching program was working, see areas of concern and take immediate action.

We are all hopeful that this type of program will be accessible in the near future.

Sincerely,

Sue Murri
Relief Society PresidentFoothill Ranch Ward
California

Great to see the support, hope church side they are cutting through all the red tape so that it can bless the entire church body.

Here is another one. Allison is a Supervisor in my ward's Relief Society. The theme here seems to be that the system actually increases the number of Households/Sisters that are visited each month. This is a good thing.

Hi,

I am writing this letter to express to you how useful it was to use the Online VT Reporting Application. It was very effective because most people in our ward use a computer. I had all of my sisters except for one report on time using this system. The sister that did not use the system was still contacted by phone the old fashioned way.

Using the phone sometimes isn't as accurate because many people do not check their (land line) phone messages daily and if they do many do not respond to the message in a timely fashion. Hence, many people that have done their visiting teaching do not report as having done so. Our records are therefore not as accurate as they could be. Also the Online Reporting Application has a built in mid month reminder that reminds the sisters to do their visiting teaching!!! I have had the best results where most everyone reported 100 percent (or closer to 100%) on the months where the system was utilized.
I was hoping that you would please reconsider allowing us to use this most effective system.

Thanks,

Alison Zor
Foothill Ranch Ward

To Whom It May Concern

We in the Foothill Ranch ward of the Santa Margarita, California stake were very disappointed when we were told that the Home Teaching Web Site we were using was no longer available to be used. This was a very effective way to manage the reporting of our home teaching on a real time basis. Now we are spending a considerable amount of additional time hunting down home teachers to get their home teaching status. This is not value added.

If there is anything that can be done to bring this program back we would greatly appreciate it.

Scott Lamb
Elders Quorum President
Foothill Ranch Ward

As convincing as these letters are, it appears there have been only two wards represented so far. Apparently the Foothill Ranch ward relied on it heavily.

Just observations, by the way; I'm not trying to say much more than that...

There were quite a few wards in the San Clemente Stake that assisted in testing that provided some extremely positive feedback. However, I haven't received any formal letters from them yet, nor do I have permission to post any of the e-mails I have received from them. As I receive any formal feedback regarding the testing that has transpired, I will post it here for your information.

Brad O.

The charlottesville VA, 2nd ward was Elders quorum also using the HT site with much success. It was very easy to use and allowed for better dissemination of information. We had all but one or two of the elders using the system. We were very sad to see the program go and hope that it will return soon. We saw an increase in visits as well as a LARGE decrease in paperwork which allowed us as a presidency to focus on the individuals instead of paperwork. We hope that the program will return on line soon.
Brad was also extremely helpful in supporting the system and responded very quickly to our particular questions. It was a great service that he provided and we were greatful for it.

Benjamin Hom
Elders Quorum President
Charlottesville 2nd ward

As the membership clerk for our Ward, I don't know how many times I have had to help the Sisters set up visiting teaching districts.

I find that just recommending that they read the screen and look for the obvious, seems to work.

But I have always wondered why they got rid of old form we used to use in the 80's that actually asked for a written home teaching report.
When they had to write it down, we actually had better numbers.

But is was also fun to catch those would lie about visits, especially
on deceased members. It was fun to watch there faces in PPI's
with the Bishop when they were told they had been dead for 2 months.

I believe I was the first one in in the San Clemente Stake to start using the HT/VT Reporting Website, when I discovered it immediately after receiving my calings as High Priest Group Leader for the San Clemente 4th Ward. I found it when I was looking at LDS.org for information on my calling and ended up on ldstech.lds.org. We immediately found this tool to dramatically increase the efficiency and quality of our HT reporting, allowing th HP Group Leadership to spend less time gathering HT reports and focus more time on responding to the information gathered. After experienceing the many benefits of this tool for a couple of months, I began sharing it with others in the Stake and also helped set it up for our Relief Society and Elder's Quorum. To the best of my knowledge, it was being used by at least 4 wards in the Stake.

August was our first month without use of the tool, and it has been a great loss. We are hoping that the necessary steps will be taken soon, to allow us to continue using this invaluable tool.

In an article posted on LDS.org, titled “Talking about Technology in the Church”, Joel Dehlin, Chief Information Officer for the Church, presents a vision of what technology should do for the Church:

“It should deliver high quality content to every corner of the earth, decrease administration and increase ministration, and bring souls to Christ,” he said during a Tech Talk” discussion held in Salt Lake City on January 18 and 23.

There is a great, untapped resource of people who are tech-savvy and could improve the technology of the Church, Brother Dehlin said. The time has come to utilize their knowledge.

I would write more about the benefits of the automated reporting and the many ways it has improved our Home and Visiting Teaching, but that does not really matter if it goes against Church policy. We would greatly appreciate the efforts of anybody in a position to expedite the church-wide approval and implementation of this wonderful tool.

As one of the 20-21 original pilot sites for the ward websites, this feature is one we requested long ago. While I did not test the site here, it sounds like exactly what we needed (and what the Ward RS president - my wife) requests regularly.

We truly need to find away to enable this funtionality and facilitate the critical reporting and fellowship tools offered here. There is so much work that is put into the records that it requires a tremendous burden on the leaders when they can only access it at the church. I realize that is may be easy for highly demographically concentrated wards to get to the church, but outside of Calif, Utah and Idaho, this tool is desparately needed.
Mike Tolman
Boiling Springs Ward
Campobello, South Carolina

Nice tool Brado. I like how it helps get people in the habit of actually reporting, instead of just waiting for a phone call. I don't think there is a doubt that the Lord expects us to return and report on our own after finishing an assignment.

Have you thought how you would accommodate those that are not real familiar with computers. For some wards this would be the whole High Priest group. Could a Elder's Quorum president, or High Priest group leader have access to put in reports for those that don't use the tool?

jaredtm13 wrote:Nice tool Brado. I like how it helps get people in the habit of actually reporting, instead of just waiting for a phone call. I don't think there is a doubt that the Lord expects us to return and report on our own after finishing an assignment.

Thanks, Jared.

jaredtm13 wrote: Have you thought how you would accommodate those that are not real familiar with computers. For some wards this would be the whole High Priest group. Could a Elder's Quorum president, or High Priest group leader have access to put in reports for those that don't use the tool?

As a matter of fact, I have. Anyone that does not feel comfortable reporting via computer can report the old fashioned way. A Presidency Member or Supervisor can report for them. Even without the ability for teachers to report for themselves, the ability for the Presidency to collaborate to update the HT/VT reports is extremely beneficial to the Home/Visiting Teaching process.

To anyone that has decision-making power at the Church: I would like nothing more than to coordinate a legal pilot test right now. It is hard for anyone to realize the numerous benefits of this system unless they are actually using it.

Brad O.

brado426 wrote:Thanks, Jared.

To anyone that has decision-making power at the Church: I would like nothing more than to coordinate a legal pilot test right now. It is hard for anyone to realize the numerous benefits of this system unless they are actually using it.

Brad O.

The issue is not one of whether this is a good idea or not. It is more a privacy and security issue. The concern, while it sounds easy to solve is very complex. What we are doing at the Church is working with various groups to determine all of their concerns and then trying to figure out if we can alleviate them and still allow the community to create and develop applications like this. In addition, we are also figuring out if we can safely and security expose official data for you to build apps around.

The other idea is to take this application and host it on our servers. One would think that this would easily solve many problems. However it does not. Because we have very strict policies and procedures that we have to follow in the different products that we offer worldwide. For example in some countries this type of application may be illegal without the consent of those individuals you are tracking information on. So then we get into situations where we have to figure out how to prevent units from accessing the site.

I'm just touching the iceberg of issues that need to be resolved. Please be patient as we work through the process. I assure you that this discussion is taking place at our leadership level.

Tom

tomw wrote:The issue is not one of whether this is a good idea or not. It is more a privacy and security issue. The concern, while it sounds easy to solve is very complex. What we are doing at the Church is working with various groups to determine all of their concerns and then trying to figure out if we can alleviate them and still allow the community to create and develop applications like this. In addition, we are also figuring out if we can safely and security expose official data for you to build apps around.

The other idea is to take this application and host it on our servers. One would think that this would easily solve many problems. However it does not. Because we have very strict policies and procedures that we have to follow in the different products that we offer worldwide. For example in some countries this type of application may be illegal without the consent of those individuals you are tracking information on. So then we get into situations where we have to figure out how to prevent units from accessing the site.

I'm just touching the iceberg of issues that need to be resolved. Please be patient as we work through the process. I assure you that this discussion is taking place at our leadership level.

Tom

Tom,

I'm in no position to argue these points since I'm not familiar with the Church's IT department and policies.

However, from my point of view, a pilot test with a few Stakes within the United States should be possible without working out every single issue ahead of time. I would be more than happy to address any security concerns with the Church. As stated earlier in this thread, this application is not dealing with sensitive data.

As the application works now, no unit can access the site unless they were specifically set up to do so.

I would just like to see us get back into a situation where progress could be made again.

Brad

brado426 wrote:this application is not dealing with sensitive data.

The only thing more then LUWS is the HT/VT assignments and visit record, right?

Question: How do you handle the situation where a member has asked for their information to be removed from LUWS completely? How do you obey the spirit of that request in your system? How does the system work with a hidden member?

RussellHltn wrote:The only thing more then LUWS is the HT/VT assignments and visit record, right?

Question: How do you handle the situation where a member has asked for their information to be removed from LUWS completely? How do you obey the spirit of that request in your system? How does the system work with a hidden member?

That is correct. The only information stored by the system is the teacher and household/sister names, phone numbers, e-mail addresses (entered manually) and home/visiting teaching statistical information (entered by Home/Visiting teachers, Supervisors, or Presidency Members).

Your question has come up before with one of the groups that was assisting with testing the system. I believe a feature could be added fairly easily that would allow the Presidency to add names to a list to prevent them from showing up in the system.

Brad O.

brado426 wrote:Tom,

I'm in no position to argue these points since I'm not familiar with the Church's IT department and policies.

This is not a Church IT department policy or concern. It is a legal and data stewardship concern. From the technology perspective, I am sure that we can devise ways to secure data. But we have to properly demonstrated to those in other departments that we can protect individuals information.

brado426 wrote:As stated earlier in this thread, this application is not dealing with sensitive data.

Name, address, phone number and email address information is considered sensitive data. We have learned from sad experience what happens when this data is misused or mishandled. Please be patient with us as we work through the organizational levels and departments.

Tom

This is a real concern. I've been involved in the development of web applications that have international distribution and there are real international legal concerns about the privacy of personal information. At the very least there needs to be concerns about the impact of the European Community personal privacy laws. In the big software firms there are lawyers with CS undergrad degrees that actually review the source code of web applications to ensure that the risk of privacy breaches are minimized.

tomw wrote:This is not a Church IT department policy or concern. It is a legal and data stewardship concern. From the technology perspective, I am sure that we can devise ways to secure data. But we have to properly demonstrated to those in other departments that we can protect individuals information.


Name, address, phone number and email address information is considered sensitive data. We have learned from sad experience what happens when this data is misused or mishandled. Please be patient with us as we work through the organizational levels and departments.

Tom

tomw wrote:This is not a Church IT department policy or concern. It is a legal and data stewardship concern. From the technology perspective, I am sure that we can devise ways to secure data. But we have to properly demonstrated to those in other departments that we can protect individuals information.


Name, address, phone number and email address information is considered sensitive data. We have learned from sad experience what happens when this data is misused or mishandled. Please be patient with us as we work through the organizational levels and departments.

Tom

In another thread, someone was mentioning that other websites store the same type of data, which no one seems to think is a concern. Yes, the data is sensitive and needs to be secured, but it is not like we're storing credit card or social security numbers here. I guess I should have said, "not as sensitive as...."

Tom: I want to do as you say and be patient, but I also want to do whatever I can to push this project forward and encourage the Church to take some action. If everything is being done that can possibly be done, I cannot ask for more than that.

James: I do not see why the Church would need to worry about international law right now for this particular project. I think focusing on the US and dealing with that subject later would be a reasonable course of action.

Brad O.

I do understand your thoughts here Brad. However, I'm also coming from the perspective of do things right the first time. My opinion is that the legal protections for personally identifiable information are far stronger in other countries than in the U.S.. With that in mind, why not be the best protector of personal information of any organization operating on the web from the U.S. by complying with the most stringent protections? That's my take.

brado426 wrote:
James: I do not see why the Church would need to worry about international law right now for this particular project. I think focusing on the US and dealing with that subject later would be a reasonable course of action.

Brad O.

tomw wrote:This is not a Church IT department policy or concern. It is a legal and data stewardship concern. From the technology perspective, I am sure that we can devise ways to secure data. But we have to properly demonstrated to those in other departments that we can protect individuals information.


Name, address, phone number and email address information is considered sensitive data. We have learned from sad experience what happens when this data is misused or mishandled. Please be patient with us as we work through the organizational levels and departments.

Tom

Tom,

Could you please expand on this idea of it being a legal and data stewardship concern. It seems to me that as long as the data is secure, the only ones with access to it are the same people/leaders that have access to it directly in MLS on the ward computer. So access to that data is already part of their stewardship. I don't understand how accessing this data through the automated HT/VT is any different than accessing it directly on the ward computer.

If you are referring to the home/visiting teachers having access to the name, address, phone number and email address of the families they teach, again this is information that they already are provided as part of their stewardship. Why does it make any difference whether it is provided to them by giving them a print out, emailing it to them, or providing it through the HT/VT tool?

I must be missing something, because when this discussion began and we were asked to stop using the system, most of us understood "security of the data" to be the issue. So now you are saying " I am sure that we can devise ways to secure the data", but there are other issues. I, for one, would like a better explanation of the other issues causing concern, so that we can address them in this forum.

Name, address, phone number and email address are accessible to all members of the stake on the ward websites. Why does that not present any legal and stewardship data concerns and the HT/VT system does? If the HT/VT site is hosted on the same servers as the ward web sites, and has the same data (nothing more sensitive), what is the problem?

Jerry S

James_Francisco wrote:I do understand your thoughts here Brad. However, I'm also coming from the perspective of do things right the first time. My opinion is that the legal protections for personally identifiable information are far stronger in other countries than in the U.S.. With that in mind, why not be the best protector of personal information of any organization operating on the web from the U.S. by complying with the most stringent protections? That's my take.

James: I totally understand where you're coming from as well. I am also a proponent of doing things the "right" way the first time. However, I believe in a phased approach for potentially large projects like this. One of the many systems I am responsible for at work is a complex Document Imaging system. The whole system really needs to be replaced, however, the scope of replacing it is outrageous. I divided the system into 10 smaller managable projects. Once the 10 smaller projects are complete, our company will have a far superior system with far less production issues along the way. We have completed 4 out of the 10 projects thus far and it is amazing how much we have been able to accomplish. If we had created a single large project that replaced the system in one pass, I can guarantee that we would not have made anywhere near as much progress as we have. We would be hung up.

I would propose that we do the same thing with this project. We could do an initial security evaluation, address any security issues that were identified, and conduct a small pilot test with a handful of Stakes. In my opinion, having LDS Tech community members actually using the system and providing feedback on it would be the ultimate method of research. While all this progress was being made, time could be simultaneously spent on worrying about international legal issues. I'd rather start small and build upon it rather than start big and get hung up on the added complexity.

That's just my two cents.

Brad O.

brado426 wrote:I am also a proponent of doing things the "right" way the first time. However, I believe in a phased approach for potentially large projects like this.

And part of doing it right the first time is to prototype it - to beta test it not only to make sure the code works as expected, but to make sure it gets the expected results. This is a combination of technology and social engineering. One would not want to roll out a church-wide system without testing and evaluating before hand.

BTW, Document Imaging systems are my day job. I'd be curious about what you've been working on, but that's probably for another thread or even PM.

jerbarb wrote:Tom,

Could you please expand on this idea of it being a legal and data stewardship concern. It seems to me that as long as the data is secure, the only ones with access to it are the same people/leaders that have access to it directly in MLS on the ward computer. So access to that data is already part of their stewardship. I don't understand how accessing this data through the automated HT/VT is any different than accessing it directly on the ward computer.

It is no different if that system were housed by the Church, fully vetted with our security engineers, etc. However when it comes to other individuals or organizations hosting the information for you then it becomes a concern. I would suspect that most other organizations would try to protect that data but not all may have the resources and expertise that the Church has. So, the current discussion is having the Church either host this application or write one that does the same thing. Hosting this application means that the Church has to buy off on the code, make sure that it meets our security requirements, etc. Writing our own means we have to free up resources internally to do it. I personally would like to have the community write the application for us but even this requires internal work to ensure we are securing the data appropriately.

Tom

tomw wrote:It is no different if that system were housed by the Church, fully vetted with our security engineers, etc. However when it comes to other individuals or organizations hosting the information for you then it becomes a concern. I would suspect that most other organizations would try to protect that data but not all may have the resources and expertise that the Church has. So, the current discussion is having the Church either host this application or write one that does the same thing. Hosting this application means that the Church has to buy off on the code, make sure that it meets our security requirements, etc. Writing our own means we have to free up resources internally to do it. I personally would like to have the community write the application for us but even this requires internal work to ensure we are securing the data appropriately.

Tom

It's been mentioned before that it would be best for brado's website to go directly at the Church membership information, as oppossed to having to continually export from MLS or some similar method. We have to keep in mind what this entails. It means the Church will be creating an API that's open to code they didn't write! Is it any wonder there is debate about security and legal concerns? This is new territory for the Church. Personally, I am thrilled that the Church is considering such a project so seriously. I agree with the concerns that the project might be stalemated, but I would assert to everyone to keep in mind what is going on here: something completely new and exciting for Church technology and development! Have patience and I think we'll see the result we're looking for in due time.

tomw wrote:It is no different if that system were housed by the Church, fully vetted with our security engineers, etc. However when it comes to other individuals or organizations hosting the information for you then it becomes a concern. I would suspect that most other organizations would try to protect that data but not all may have the resources and expertise that the Church has. So, the current discussion is having the Church either host this application or write one that does the same thing. Hosting this application means that the Church has to buy off on the code, make sure that it meets our security requirements, etc. Writing our own means we have to free up resources internally to do it. I personally would like to have the community write the application for us but even this requires internal work to ensure we are securing the data appropriately.

Tom

After spending a better part of the last year on this project, I would be lying if I didn't say that I'd be disappointed if the Church said, "Thanks for all your effort, Brad... .we'll take it from here." I think it is understandable that I would want to be involved in the project, but it seems almost impossible due to all the red tape. Recently, every scenario I can think of regarding the future of this project involves me being totally out of the loop. It seems that the only possible way I could be involved with this project is to move to Salt Lake and become a Church employee (which at this point, I do not believe is too likely.)

I do not think this is a good message to send to community members that have invested their heart and soul in a project. "Thanks for all your work, but we're considering rewriting the whole thing from scratch internally." I realize that I took a big risk in spending any time on this at all, and I also realize my code isn't perfect and needs improvement, but in 9 months, I haven't been able to get anyone at the Church to even begin to evaluate the security concerns or give me any feedback as to whether it is something the Church even is interested in using. This is far from what I expected. I thought the Church would be excited and motivated to work with me on this, but I'm not getting that indication as of yet. I thought the Church would be so motivated that some exceptions could be made in policy to help this project move forward. This was a misconception also.

Also, if it has been this difficult and taken so much time to get this far, I'm imagining far worse for when things actually get going. I'm picturing added complexities and additional time required when trying to debug application issues. I am beginning to wonder if it is even possible to be an outsider (non-Church employee) and develop a project like this.

On one hand, I probably shouldn't have developed this system without working with the Church ahead of time. On the other hand, the system wouldn't exist today if I didn't go on a renegade development spree. I still hope for the best for this project, but logic is telling me that the outcome is going to be disappointing because I will not have the opportunity to be involved.

Ok, I've spilled my guts here, but let me make it clear that this is not an attack on Tom W. or anyone else. I'm just not too happy with the situation. It is clear to me that as things are now, the only projects community members should be spending their precious time on are projects that are officially endorsed on this site.

I haven't given up.... I'm just a bit frustrated (which I think is a pretty normal and reasonable emotion to have on occasion in this field.)

Brad O.

I have edited your post...

brado426 wrote:After spending a better part of the last year on this project, I would be lying if I didn't say that I'd be disappointed if the Church said, "Thanks for all your effort, Brad... .

I will be the first to say THANKS. Many people (myself included) have thought of great program ideas for church software. YOU are the only one (to date) that has been bold enough and tenacious enough to follow through to this point. YOU have pushed a functional project, a tested project, a useful project to get this process in gear. THANK YOU for being bold enough to put your time into this.

brado426 wrote: I do not think this is a good message to send to community members that have invested their heart and soul in a project.

I agree.

brado426 wrote: I thought the Church would be so motivated that some exceptions could be made in policy to help this project move forward.

I think POLICY is the operative word here. See my thoughts below.

brado426 wrote:On one hand, I probably shouldn't have developed this system without working with the Church ahead of time. On the other hand, the system wouldn't exist today if I didn't go on a renegade development spree.

Brad O.

WRONG, see above. This milestone is a needed part of the process. I understand that you are frustrated that you get to be the one to fight this fight. Understand that we, the community, are behind you. We just didn't have a project to back, so we back yours.

As developers and engineers, I think we get frustrated when we have a working project and a functional design, and it gets caught up in process and policy. I work in QA (not at the church), so I AM often the roadblock to shipping a 'working' product. The pieces of the process are there to make sure that ALL of the interested parties get their needs met by a given solution. Every piece of code that I get from dev 'works', it is my job to make sure that we understand the limits of 'works'. That doesn't mean that the software does not do what we intended it to, but that we need to understand how and where the software does not do what we intend. That includes policy, performance, scaling, and function.

From the messages I read, I think the church is still trying to hash out the policy. It is clear to them that submissions such as yours are GREAT, but they need to figure out how that fits into their greater organization. They are still working on the policies around this process.

At this point, they do not know how to involve you in rolling this out, since they do not know what they need to get this published. I do not think there is any question that this functionality needs to be implemented, the church just needs to figure out what the next steps are. When they have those steps, expect to be very busy working with them to get those done. You can't help them figure out those steps yet, because you are not part of the policy-setting group at the church. Personally, I try to avoid policy meetings, they tend to be long and boring .

In short, I don't think the church is telling you that you wasted your time, they just don't yet know where to go from here.

I think the church was surprised at the response of the community. I do not think that they expected working projects mere months after they launched this site. I do not think they had any visibility into this community before, so had no idea people were this passionate and motivated. I do not think they had policy in place for this, nor do I think they understood that they needed that policy. Now, the rubber has met the road, and they are working frantically to get the pieces in place so they can take advantage of our community.

Thanks again for your hard work.

Barrie

Brad,

I completely agree with all of The Earl's comments. I think he hit it right on the nose. I'll offer my deep thanks to you as well for being so bold and spending so much time and effort creating this project. It really is an terrific undertaking!

As for the current situation of the project in the ranks of the Church, I would say please remember that your project is the first one to go through this process. And with that, all of the policy and standards for opening projects to the community have to be established. It will naturally take quite a bit longer this first iteration. And The Earl is right, we are ALL behind you Brad!

Also, I will pipe in my opinion on the subject. I think it would be a grave mistake for the Church to establish a routine of receiving a great project idea from the community and then rewriting it themselves. That is a lot of lost time and duplicated effort. Plus, there were also be more community development resources than Church ones. The Church could gain so much from tapping into such an eager community of volunteers.

From Tom W.'s comments, it is apparent that he catches this vision as well and is currently trying to encourage that foresight out to the rest of the departments at the Church. Good luck!

The Earl wrote:I think the church is still trying to hash out the policy. It is clear to them that submissions such as yours are GREAT,

If it were not so, they wouldn't be trying to work out the issues.

I will say that in my experience the church moves very slowly. Even the insiders overestimate the speed.

My best suggestion for the time being is to put this on the back burner and start on something else. Think of it as the "watched pot never boils". Watching and waiting will just frustrate you even more.

The Earl is right on. Your work is of great value to us. It has gotten a lot of discussion going at the Church. I don't want to commit to too much here but this project has been discussed as one of the first projects to really engage the community in developing. I'd be lying if I told you that we have a lot of traction on taking your app as is and distributing it. There are too many unknowns, foremost is the duplication of data (something which causes us a lot of problems). So the next logical discussion is how do we allow the community to help build this app securely. That is the discussions going on. It may seem like we are "discussing this thing" to death but it takes a long time to get people together and build consensus.

Let me give you some insight on what has to happen. To engage the community in this project we would need to do the following:

• Create an API to the member data. Currently most apps that get membership data talk directly to the DB. We obviously cannot allow this moving forward, not only for this project but for any project. So a secure API has to be figured out, scoped out, funded, and developed.
• Necessary permission to allow access to membership data has to be secured. This sounds easier than it is. Imagine you are the data privacy officer or the data steward for the church and some project manager comes to you and says "Hey, we are going to create an API where developers who are not employees of the Church can help us build applications". They need to be assured that a) this is a necessary and needful project and b) we have taken all available means necessary to protect the data.
• Funding - to do any work we need to have a project completed, filled out, approved, and funding granted. This process alone can take months.
• Resources - We have so many projects going on at the Church, you sometimes have to wait for resources to free up. Remember, we are talking about if we were to create APIs.
• Specifications - Even though your application goes a long way to getting us a functional specification, before the Church endorses the product, a product manager from the Priesthood department will need to review it, add / subtract any features that the Church thinks important, etc. Again, this takes all of the steps above to happen.

It can be discouraging...I know. Please be patient while we work through the process. Also, my disclaimer here: I'm not promising any that this project will happen. I'm working hard to make it happen but the final decision will be made by those who have that authority.

Tom

RussellHltn wrote: My best suggestion for the time being is to put this on the back burner and start on something else. Think of it as the "watched pot never boils". Watching and waiting will just frustrate you even more.

You're right RusselHtm. And that is precisely what I am going to do since there no indication that anything will happen any time soon.

tomw wrote:

• Create an API to the member data. Currently most apps that get membership data talk directly to the DB. We obviously cannot allow this moving forward, not only for this project but for any project. So a secure API has to be figured out, scoped out, funded, and developed.

This is about what I expected. Most organizations and their software tools are not tooled to allow 3rd party plugins. This is even uncommon in publicly sold applications, firefox, eclipse and a few others being well-known exceptions.

Creating a secure API, while the right way to do this, represents a complete restructuring of the way software is written for the church. This is a HUGE and COSTLY undertaking for any group. That the church is even considering this is a big step forward. The benefits to the church development group as a whole are likely marginal to the costs without the involvement of the community. If we have tipped that scale, that speaks volumes about the perceived value of our contribution.

The company I work for has done a bit of this while modularizing our code. We managed to slip in in during rewrites, so the cost was mitigated a bit, but it was a huge undertaking, even for our relatively small codebase. Our products do not compare in any way to the size or complexity of LUWS or MLS. We also do not have 24/7 availability requirements, or users in almost every timezone on the planet.

That a public API is being discussed lets me know that the church is serious about getting these projects moving.

tomw wrote: It can be discouraging...I know. Please be patient while we work through the process. Also, my disclaimer here: I'm not promising any that this project will happen. I'm working hard to make it happen but the final decision will be made by those who have that authority.

Tom

Tom:

Keep up the good fight. Let us know what you need from us to push this ahead. You have been a real champion for community involvement. Thank you.

The Earl

Brad,

I'm not going to take the time to look it up for sure, but if the church were a corporation it would be considered something like a fortune 500 company! I can't think of a single company on that list that would be quick to allow any outside developer, no matter how revolutionary their code, to access their internal db's and write code to manipulate it. I know you don't want to lead a movement, but you are! I truly feel the church wants and is eager to have your help in this process. Don't give up, just go on to the next project until the church catches up to you.

If you need something to do, my Elder's quorum presidency would love a more robust tool for managing HT/VT companionships and assignments. How about it?

Nick

nimebe wrote:Brad,

I'm not going to take the time to look it up for sure, but if the church were a corporation it would be considered something like a fortune 500 company! I can't think of a single company on that list that would be quick to allow any outside developer, no matter how revolutionary their code, to access their internal db's and write code to manipulate it. I know you don't want to lead a movement, but you are! I truly feel the church wants and is eager to have your help in this process. Don't give up, just go on to the next project until the church catches up to you.

If you need something to do, my Elder's quorum presidency would love a more robust tool for managing HT/VT companionships and assignments. How about it?

Nick

You guys make a lot of sense. For some reason, I envisioned things being a lot different. That just shows some ignorance on my part, I guess.

And let me emphasize again that I have never asked to roll this thing out to the whole Church or even access Church data.... I have been shooting for permission to conduct a small pilot test so that further progress could be made on the actual application while all the political stuff was being worked out. Changes could be made to address issues such as duplicate data and security now. The reason I've been pushing so hard for a pilot/beta scenario is that we could slowly modify the app to better comply with the Church's policies and guidelines rather than reserving the work for a large, expensive future project.

Brad O.

tomw wrote:The Earl is right on. ...

Let me give you some insight on what has to happen. To engage the community in this project we would need to do the following:

• ...
• Resources - We have so many projects going on at the Church, you sometimes have to wait for resources to free up. Remember, we are talking about if we were to create APIs.
  ...
  
  Tom

Tom, here's a wild and crazy idea. So far, there has been discussion of two types of work and workers. First, there are Church employees working at Church headquarters, the resources mentioned above. Second, there are volunteer developers not employed in any way by the Church.

Might it be feasible to create a third category between the first two. In cases where projects are approved and funded but sit waiting for resources to free up, might it be possible to outsource specific work (perhaps at lower cost) to paid developers under tight Church control but not necessarily Church W-2 employees and not necessarily located at Church headquarters?

A few recent developments might help make that more feasible than before. If desired and permitted, the "LDS Connected" private group at LinkedIn.com might be one way to facilitate the invitation or selection of workers whose personal motivations are more aligned with Church purposes than those of the general population. Some freelance sites (an example is available on request) allow employers to invite specific professionals to bid on specific projects. They might even allow invitation-only projects.

With the Church funding the work, control would be achieved through the version of the golden rule that says he who is paying the gold makes the rules. SQA, security review, etc. could still be done by W-2 Church employees at Church headquarters. Outsourcing would be a means of expanding the leverage of those employees. Pay rates could be kept at levels consistent with the scripture that says the laborer for Zion must be motivated more by desire to build Zion than by desire for financial gain.

rmrichesjr wrote:Tom, here's a wild and crazy idea. So far, there has been discussion of two types of work and workers. First, there are Church employees working at Church headquarters, the resources mentioned above. Second, there are volunteer developers not employed in any way by the Church.

Might it be feasible to create a third category between the first two. In cases where projects are approved and funded but sit waiting for resources to free up, might it be possible to outsource specific work (perhaps at lower cost) to paid developers under tight Church control but not necessarily Church W-2 employees and not necessarily located at Church headquarters?

A few recent developments might help make that more feasible than before. If desired and permitted, the "LDS Connected" private group at LinkedIn.com might be one way to facilitate the invitation or selection of workers whose personal motivations are more aligned with Church purposes than those of the general population. Some freelance sites (an example is available on request) allow employers to invite specific professionals to bid on specific projects. They might even allow invitation-only projects.

With the Church funding the work, control would be achieved through the version of the golden rule that says he who is paying the gold makes the rules. SQA, security review, etc. could still be done by W-2 Church employees at Church headquarters. Outsourcing would be a means of expanding the leverage of those employees. Pay rates could be kept at levels consistent with the scripture that says the laborer for Zion must be motivated more by desire to build Zion than by desire for financial gain.

We actually do hire a lot of contractors for various projects. This does tend to solve problems when resources are over burdened. However broadening it to more of a bidding process is something that has not been discussed. Thanks for the suggestion!

Tom

enriquer wrote:This dialog has gotten WAY OFF TRACK.

All that the HT/VT Reporting website needs right now is to relocate in its present form. That means no API or DB connections.

Let's just keep improving the user interface and related methodology. Then once this has been finely honed we look at further integration (aka Phase II.)

I mentioned before that this was one of my objectives. However I have had strong opposition to "replicating the data". Several months back I approached leadership with this very idea. It started a very big groundswell to "get something done".

The lack of any and/or regular communication about this is killing the momentum this site created. Since this site was pulled the home teaching metrics down here nose dived by 40%.

I cannot say everything that has been discussed because it would not be appropriate for me to do that. Also you assume that things are happening faster than they do. I can assure you that there have been several email discussions, meetings, conference calls and even team meetings to discuss this. But it just takes time.

Also, technology should not be blamed for not doing one's home teaching. Yes, it can be a great help but it should never be viewed as the reason we do or don't do our home teaching.

At least the HT/VT Reporting website was a "secured" site that only contained information that is a public record anyway.

This information is not public. You have to have an LDS.org account and be associated with a specific unit before you can see the information. True you can find most information in the phone book but not all.

In summary, the HT/VT Reporting site was just what this forum was founded for. The failure of this endeavor makes it clear that this forum will never be about productive solutions. Instead it will just be a sounding board for coders and wireheads. [/font]

I can tell that some emotions are running very high and I don't want this conversation to get out of control. Please keep it civil!

Tom

I just want to echo Tom's post. I have read the posts coming out of this thread. It was very productive at first but now it has become a "soapbox" where most have been criticizing the church's policy that is there to protect not only your information but also the church's liability in the global community. This forum was created to get input from the community and maybe sponsor a few projects. Don't get me wrong, what Brad has done has been great, and has fulfilled that first mission which is to get ideas from the community.

I also have had run ins with church policy in that I was our ward's webmaster before LUWS came one. I devoted a lot of energy into the site and made it a very useful resource for the ward and especially those that couldn't come each Sunday due to health or other concerns. But when the church pulled the plug there went my site too and all that effort went away. BUT I took comfort that I was able to help some people during the time that it was active. I suggest that everyone here does the same for the time being and when the church opens doors to allow us to continue to then continue with our whole heart into the project.

Also if there are more posts that are applied to just complaining please understand that this thread might be closed in response. As Tom said, please keep it civil.

thedqs wrote:I just want to echo Tom's post. I have read the posts coming out of this thread. It was very productive at first but now it has become a "soapbox" where most have been criticizing the church's policy that is there to protect not only your information but also the church's liability in the global community. This forum was created to get input from the community and maybe sponsor a few projects. Don't get me wrong, what Brad has done has been great, and has fulfilled that first mission which is to get ideas from the community.

I also have had run ins with church policy in that I was our ward's webmaster before LUWS came one. I devoted a lot of energy into the site and made it a very useful resource for the ward and especially those that couldn't come each Sunday due to health or other concerns. But when the church pulled the plug there went my site too and all that effort went away. BUT I took comfort that I was able to help some people during the time that it was active. I suggest that everyone here does the same for the time being and when the church opens doors to allow us to continue to then continue with our whole heart into the project.

Also if there are more posts that are applied to just complaining please understand that this thread might be closed in response. As Tom said, please keep it civil.

I don't think anyone is criticizing Church policy. I think the message that I (and others) want to communicate is that the current situation is frustrating. I could continue to just be quiet and patient, but if the people with decision-making power do not realize there is a problem, they will not have the necessary knowledge to fix that problem.

In my mind, the work I have done so far can be molded into something that the Church could use. So there's some duplicate data for the pilot test.... that doesn't mean the final product would involve duplicate data. I just have to disagree with the concept of everything having to be absolutely perfect the first time. I believe that a phased approach is the most beneficial way to handle situations like this, which would result in a perfect solution in the end.

We have something that we know works. Let's resolve any security concerns and at least try it before the momentum and everyone's motivation is gone.

This is the last post I will make to this thread. I think I have communicated my feelings pretty clearly.

Brad O.

enriquer wrote:This dialog has gotten WAY OFF TRACK.

All that the HT/VT Reporting website needs right now is to relocate in its present form. That means no API or DB connections.

Let's just keep improving the user interface and related methodology. Then once this has been finely honed we look at further integration (aka Phase II.)

I don't know how this got so far off track but again all we need is somewhere to park the application.

Actually, merely relocating the web application to a different server (even Church hosted) doesn't just magically solve all the problems.

enriquer wrote:What's worse is all the excitement around it and beta.tech.lds.org has died in our stake. I am afraid this juggernaut has marginalized the value of this forum and its influence on technology in the church.

In summary, the HT/VT Reporting site was just what this forum was founded for. The failure of this endeavor makes it clear that this forum will never be about productive solutions. Instead it will just be a sounding board for coders and wireheads. [/quote]
Your comments are unjustifiably harsh. This forum's sole purpose was NOT the HT/VT Reporting site. I don't think the Church ever dreamed their would be so many volunteer developers and project ideas from the community within 6 months of launching the site.

tomw wrote:We actually do hire a lot of contractors for various projects. This does tend to solve problems when resources are over burdened. However broadening it to more of a bidding process is something that has not been discussed. Thanks for the suggestion!

Tom

Tom, if you'd like a list of some clearinghouse sites for contract/freelance work, you are welcome to email or PM me. I have a short comment about a bunch of them (written from the perspective of a worker).

Is there a method for getting on the list to be considered for contracting development work? Perhaps I'm not the only currently unemployed worker who would like a shot at contracting for the Church.

Thanks.

rmrichesjr wrote:Tom, if you'd like a list of some clearinghouse sites for contract/freelance work, you are welcome to email or PM me. I have a short comment about a bunch of them (written from the perspective of a worker).

Please pass them on to me via email. I'll forward them on to the right department.

Is there a method for getting on the list to be considered for contracting development work? Perhaps I'm not the only currently unemployed worker who would like a shot at contracting for the Church.

Send me your resume and contact info via email and I will forward it on to our those within our organization that are looking for work. I will have to figure out who that is once I see your resume. It is my understanding that normally contractors are not hired through our HR department.

Tom

To Whom It May Concern:

As secretary of the Relief Society Presidency of the F oothill Ranch Ward in California, I would like to express how extremely beneficial it was to be able to report our visiting teaching statistics online. The sisters loved the reminders and loved how easy it was to report and of course the supervisors were elated that they didn't have to spend hours tracking sisters down that simply do not return phone calls.

It was such an efficient and fast way for sisters to report each month especially where 95% of all of our sisters are "email" active. As a presidency, it was so helpful to be able to actually see where the needs of our sisters truly were and for the sisters to be able to communicate to us special needs of our sisters. With this program it was virtually impossible for sisters to be "misplaced" or not accounted for.

As you know, my calling as secretary requires monthly reporting to the stake and I cannot even begin to tell you how great it was to have accurate information pulled directly from MLS and to incorporate that into my reporting.

It was very difficult to have to go back to the "old" way of doing things after having such a user-firendly efficient program that truly was an asset in serving the sisters at full capacity. We hope that the Church will see its potential and implement it world wide.

Thank you,
Lynette Saadeh
Foothill Ranch Ward RS Secretary

Please go here for the latest info regarding this application:

http://tech.lds.org/forum/showthread.php?t=1319

For a preview of this application, please go here:

http://sites.google.com/a/eqideaexchang ... dreportorg

Thanks,

Brad O.

Very cool...thanks for the link...

Are you accepting submissions of things beneficial to the Elder's Quorum?

Mr. M wrote:Very cool...thanks for the link...

Are you accepting submissions of things beneficial to the Elder's Quorum?

The "Preview" link actually links to Douglas A. Hatch's EQ Idea Exchange site. I think it is an awesome idea and I wish that resource existed when I was in the EQ Presidency.

To get more info and learn how to gain access to add content to the site, check this thread:

http://tech.lds.org/forum/showthread.php?t=1321

Brad O.

Can I give access to my Home Teaching reports to my Bishop? He would like to see our reports. Also, this works so well for us that our Relief Society wants to use it for Visiting Teaching. Is there a demo I could provide to them to show them how this works for Visiting Teaching? -TechnoBabel

TechnoBabel wrote:Can I give access to my Home Teaching reports to my Bishop? He would like to see our reports. Also, this works so well for us that our Relief Society wants to use it for Visiting Teaching. Is there a demo I could provide to them to show them how this works for Visiting Teaching? -TechnoBabel

Hi TechnoBabel,

In the future, please use the "Technical Support" link on the Supervisor Menu to ask for help regarding ReturnAndReport.org. Since this is not an official Church system, we should probably not be discussing it here. I have sent you a private message answering your questions.

Thanks,

Brad O.

Groups (EQ/HP/RS) now have the ability to give access to their reports to anyone. The most obvious use for this feature is to provide access to a group's Bishop and/or Stake President. The "Report Viewing" user can be configured to receive an Email notification when a new report is ready if desired. Only the group's Presidency can give "Report Viewing" access to someone else.

If a "Report Viewing User" logs in, he or she will see a list of all authorized groups. The user can then either view the individual reports for each group or generate a "Group Summary" report as shown below. This report can be generated for any month within the past year.

We now have the report shown in the previous post, however I think the Stake President would also like the ability to see a summary of each group's progress for the past several months.

I'm envisioning a report that has the months on the X axis, the list of groups on the Y axis. In each grid cell, it would display Total Visited or Contacted, Percentage Visited or Contacted, and Total Teachers.

I think this is the last major report that would need to be added for this system. Does this sound about right? Does anyone have an alternate suggestion of how this data should be presented to the Stake President or Bishop?

TechnoBabel: By the way, when I said "we shouldn't discuss it here" earlier, I meant we shouldn't discuss specific technical support/how to questions. I think we need to keep any discussion relating to this isolated to general design and theory. This is the type of information the Church may find useful one day in the future.

Brad O.

Brad O, I thought that was what you meant. I would love to see that additional summary report. It sounds like your suggestion should cover everything the stake president needs.

I have decided to set up some forums specifically for this application for a couple reasons:

• I find myself answering the same questions over and over privately and need a public place for support
• I think there is enough content to justify a forum specifically dedicated to Home/Visiting Teaching

From this point forward, I will be discussing all feature enhancements and technical aspects of this application here: http://returnandreport.org/forums

Thanks so much for all your support!

Brad O.

In the event that you didn't see my announcement, the Church has just sponsored and launched a project to build a HT/VT application that we would like the community to get involved in. Thanks to Brad and all of his efforts in getting us to this point. See my [thread=1843]thread[/thread] announcing this exciting development.

Tom

great to see the "work" going forward

I wanted to use ReturnAndReport while the construction of the formal site continued, but one of the elders in my quorum said:

"My Dad's Bishop works in the CIS department of the Church. To the best of
his knowledge this site was supposed to be shut down last Friday."

Is this true?