Home Teaching / Visiting Teaching Application

[jdlessley]

Once the decision about which system to use is made how will this decision be implemented? Will there be some way of switching off the MLS input functionality if the decision is to use the new application?

I guess I didn't mean to say "switching off the MLS input functionality" but rather switching off the MLS HT/VT reporting functionality.

If as boomerbubba suggests that some will want to have the new application be the reporting vehicle and MLS be used for internal administrative uses then I don't think you should have two applications making reports to Church headquarters for the same unit.

[mkmurray]

I guess I didn't mean to say "switching off the MLS input functionality" but rather switching off the MLS HT/VT reporting functionality.

If as boomerbubba suggests that some will want to have the new application be the reporting vehicle and MLS be used for internal administrative uses then I don't think you should have two applications making reports to Church headquarters for the same unit.

You have to remember that currently the Stake is the one that receives unit HT data. Then it's the Stake's responsibility to send that on the CHQ (I think). Also, I haven't read any plans for the new application to submit HT data in any automated way to another Church system or database. That is something that needs to be discussed (not necessarily the automated way, just which way is the Church expecting to receive it).

EDIT: Thank you, Alan, for clarifying. I agree, if HT data that is sent to the Church is minimal and only sent quarterly, then for now, the Stake can continue to send that in manually.

[aebrown]

Isn't the option a one-or-the-other choice? I ask this because Church headquarters would then be receiving reports from two sources. Which one would they choose? Would the new application report/data take precedence over the MLS report/data or vice versa? How would they know which one the unit intended them to receive?

By making this statement I assume you envision the report normally sent from MLS would not happen during a send/receive if the unit chose the new application as their reporting vehicle. RAR obviously does not send any report to Church headquarters, the new application will.

There is no home teaching report sent to Church Headquarters, and I really doubt that the new app would send a report to CHQ. The only home teaching data is a single number per ward on the Quarterly Report: the number of families visited in the last month of the reporting quarter (and a similar number for the number of sisters contacted by visiting teachers). I can't imagine that the Church would choose an alternate way to receive those two numbers on the Quarterly Report -- the Quarterly Report will still be submitted the way it is now.

For wards using the new HT/VT application, this implies that those two numbers have to find their way from the HT/VT app to the Quarterly Report, but that is surely not much of a burden, and the risk of error is slight.

[jdlessley]

OK. Then what boomerbubba describes is not a problem for Church headquarters or for the units (wards). It only then becomes an issue for the stake in gathering the data. Instead of Church headquarters being the one saddled with determining the intended data the stake has the extra burden. It is a lot easier issue to deal with at the stake but an issue none-the-less.

[mkmurray]

OK. Then what boomerbubba describes is not a problem for Church headquarters or for the units (wards). It only then becomes an issue for the stake in gathering the data. Instead of Church headquarters being the one saddled with determining the intended data the stake has the extra burden. It is a lot easier issue to deal with at the stake but an issue none-the-less.

I suppose, but the burden has always been at the Stake level to gather that information and submit to Church HQ. Now the new issue that I think you are getting at is whether the Stake will now receive data coming from 2 different sources. This is why I think the Stake should decide which method to use, not the wards, since they are the one ultimately responsible for gathering the data and sending it on to Salt Lake.

[RossEvans]

@jdlessley:

I should add a disclaimer that this suggestion -- the option of using both systems concurrently -- is nothing but my own idea, and I have about as much authority as the Tooth Fairy.

My suggestion actually flies in the face of what Tom Welch advised on the Wiki:

Our thoughts are that people will have (at least now) to pick to use MLS OR the online HT/VT version.

And also Chad Fullmer, the Product Manager representing the Priesthood Department:

Leaders will need to re-create their assignments when they first begin using the system; and reports won't sync back to MLS. This means that Church units will need to use one system or the other (old MLS or this new app)

[jdlessley]

With all that cleared up then I can assume the new application and RAR are (will be) essentially the same in end result as far as the intitial roll out is concerned - Correct? I am speaking from the unit user perspective.

[kennethjorgensen]

A lot of discussion just flew by Tom's quote here:

Tom Welch is telling us that he personally speaks with the Project Manager of MLS very often about this project. Tom said they are "on board" with this app and that "MLS will integrate with it when they are ready."

As for me, we have as good as a handshake from the MLS team. Let's go forward! The details of this MLS integration will be worked out as we go, now that we know everyone is rooting for us.

I agree, it is good enough for me too. Tom and his guys have listened to the comments been made about double entry, choosing one or the other or both, reporting, ward v stake implementation etc so if they still say "lets go" then lets wait and see if some of these "implementation issues" surface at the beta stage when actual units will participate. At that stage the process of using the MLS with the HT/VT will reveal if there are still issues to be sorted.

[kennethjorgensen]

Yes, we should absolutely create this ability. One of the purposes of having the community to help with the HT/VT app is to be able to do more of these types of add-ons to products.

Tom

That is a very good point to make. On products I have worked where we had similar situation with external people involved we initially used a lot of our own time to get the framework in place (set the scene) but once there was more we then found external people participating "found their own seat" and even more afterwards when add-ons (applications & functionality within apps) had to be added or fixes had to be done. It was often a case of us having other more pressing things to do and so the external people were a very valid source here as they could create or fix these things much faster and we were left to just review the work.

[WelchTC]

Thanks for all of the feedback everyone. Here is my take of a summary:

• Everything is open to change during the development/testing process as we want the process to be collaborative. We may find that we need "A" and need to modify "B" as we move along.
• The HT/VT will be the central repository of HT information. MLS currently does not push HT/VT information to CHQ.
• Initially STAKES will need to decide if all units in their stake will use the online system. Although stakes "could" mix -n- match MLS and HT/VT app, this would necessitate in double entry. For best results, all units in the stake should be on the same system.
• We can build importers from MLS into this system.

What else am I missing?

Tom