Home Teaching / Visiting Teaching Application

[mkmurray]

Are you saying that the task is so easy as to be no significant task at all, or are you proposing a new idea for a different architecture driven by the MLS client-side? In any case, I am having a hard time reconciling that assessment of difficulty with either of those estimates above.

No I suppose not. I guess it would be the same amount of work because it would use the same exposed web service to get the information to display within MLS as writing to the databases at the Church Data Center. I'm not saying it's insignificant, just that if you can get the HT/VT data trickled down to the client-side MLS, then most would probably switch over to the web app the Community develops and then write access for HT/VT would be unnecessary in the client-side desktop app.

[WelchTC]

Have you read the recent comments on the Wiki? (You mentioned that you have been out of touch for several days, and there has been a lot of activity.) The problems with lack of integration in reporting in MLS have been pretty well explored there.

Wow...looks like a novel. I'll get to it tomorrow. Meanwhile from the looks of things people may be taking everything too literal. We certainly can make an import from MLS to this app so people do not have to re-enter all of the data. What Chad has stated to me is that he does not plan on making the data synchronize between MLS and the HT/VT app. Mostly because the current MLS does not send any HT/VT to CHQ. That does not mean that as newer versions of MLS in the future come out and want to consume HT/VT data at CHQ, we can't do that. It just means that right now there is nothing at CHQ to synchronize with. So THIS project will define what data to store regarding HT/VT data. Does that make sense?

I am having a hard time reconciling your estimate of "a very long time" with Chad's estimate of "mid 2009."

Chad will have a better gage of where an online MLS product is in the development phase.

Tom

[RossEvans]

...That does not mean that as newer versions of MLS in the future come out and want to consume HT/VT data at CHQ, we can't do that. It just means that right now there is nothing at CHQ to synchronize with. So THIS project will define what data to store regarding HT/VT data. Does that make sense?

Yes, that is sort of what is being discussed on the Wiki as a missing link. See valletta's comments. The "missing" part is that the MLS team does not seem to have been enlisted to do this.

I think it would make more sense if this link were not missing from management's articulated plan.

Chad will have a better gage of where an online MLS product is in the development phase.
Tom

See also DJC's comment here, observing that the larger project "is still in the envisioning stage."

[garysturn]

Curtis Smith is working with Tom Valletta on designing the Church's back end for the HT/VT application. Curtis is in my Ward and we talk every week about this project. He is the Ward Clerk in our Ward so he understands both ends of the system. He has been working on this for some time now, so even though we haven't seen much info posted from the Church end of this project there is work going on there for this project. They are working on a sandbox database with fake data to work with as well. The back end they are designing will be used by more than just this application.

[RossEvans]

Curtis Smith is working with Tom Valletta on designing the Church's back end for the HT/VT application. Curtis is in my Ward and we talk every week about this project. He is the Ward Clerk in our Ward so he understands both ends of the system. He has been working on this for some time now, so even though we haven't seen much info posted from the Church end of this project there is work going on there for this project. They are working on a sandbox database with fake data to work with as well. The back end they are designing will be used by more than just this application.

Curtis has not yet joined the fray of comments in the Wiki, but Tom Valletta, his colleague from the Church's professional side of this team, posted a description there of the back-end service Curtis is working on to support this project. It is impressive and we can't wait to know more. But as I understand the organization, while these two are Church employees they cannot speak for the MLS unit, which would have to cooperate to make any integration happen.

I would call your attention to Tom's initial comment, which seemed like carefully chosen words:

We agree with those that have stated that it would be short sighted to ignore MLS when developing this application.

It is not the position of the technical professionals I am worried about. It is that of managers who have not secured a sign-up for the MLS group to hook into the service that Curtis is building, and have not written that into the high-level project plan.. That plan, as now articulated, calls for no integration with MLS.

[russellhltn]

Wow. A lot of stuff to read here.

One question. Since this application has been "out there" already, what have the wards that have used and loved Brad's system do?

Without wading though all the issues here, I'd expect to design the underlying database and logic to be expandable/integrable/absorbable by the next gen app and consider the user interface code to be disposable.

[RossEvans]

One question. Since this application has been "out there" already, what have the wards that have used and loved Brad's system do?

We don't (yet) use ReturnAndReport, but my understanding is that those who do use it basically do double data-entry of the districts, companionships and assignments, and rekey the monthly results gathered online into MLS.

[russellhltn]

but my understanding is that those who do use it basically do double data-entry of the districts, companionships and assignments, and rekey the monthly results gathered online into MLS.

And despite all that the wards that use it still love it? Less then optimal, but I don't see a problem.

Now, I'm not sure just how things will work. One consern I'd have is trying to keep nRR (new Return and Report) synced with the membership so move-ins are caught. My thought: it to do the districts in MLS and export it to nRR. That will get a lot of the needed info transfered.

Also, an area to explore is there *may* be a way to import in MLS. Automation software. If it can read the MLS screen, it can be taught to do the keystokes needed to enter a data file.

[kennethjorgensen]

It is by no means certain that MLS integration will be added later -- the people who have made statements to that effect are not on the MLS team and thus cannot make the decision to integrate with MLS, even if they enable such integration by providing appropriate services. However, I can certainly understand that there could be good reasons for delaying the integration for now. One big reason would be that the difficulty involved in coordinating the MLS changes with the HT/VT changes would create a significant delay in the HT/VT project.

I agree with you. It might be added later or it might not, is what I meant. If we concentrate on creating a quality application and the uptake is big then the business case for adding integration will also increase.
"Build it and they will come"

As long as the HT/VT capabilities of MLS are not neglected (and certainly not removed) prematurely, stakes will be able to decide if they want to use the new HT/VT app or not. Such a decision would be much easier if MLS integration were eventually provided. Until that point, a stake would have to weigh the loss of MLS HT/VT information against the benefits of the new HT/VT system (or the cost and risk of double entering HT/VT data -- which I'm guessing would be deemed to be prohibitive in most cases).

I agree here too. I dont think it would be a good idea to remove the HT/VT capabilities of MLS but adding any new functionality to this I would imagine to be very low priority.

It should certainly be possible for units to choose which one they want to use and weigh up benefits and challenges associated with both. One situation is that some units dont have their own building and therefore cannot (as they dont own the phone line) sign up for broadband internet (to use the new web application) but they do have dial-up access (permission to use the phone line) so can get MLS updated.

Those units might decide to keep MLS HT/VT if they do most of their data entry while at church or they might use thew new HT/VT app if they want to do it at home. The decision would entirely depend on their situation and who has/has not got internet access.

If we are to have two HT/VT systems running and sync of data willl be major task (we trust those closer to the system once we have made our point) then we will have to live with double entry (at least to start with) but something that should help not having the two out of sync would be if the new system could have a way to check for people moving in and out (check new HT/VT individuals against MLS membership records). Russell said something similar.

[WelchTC]

Curtis has not yet joined the fray of comments in the Wiki, but Tom Valletta, his colleague from the Church's professional side of this team, posted a description there of the back-end service Curtis is working on to support this project. It is impressive and we can't wait to know more. But as I understand the organization, while these two are Church employees they cannot speak for the MLS unit, which would have to cooperate to make any integration happen.

Let me assure you that we are talking with the MLS people. I sit near the PM for the project and coincidentally he is related to me through marriage. I have discussed what we are doing and he is on board. Management is on board with the decision that the HT/VT will lead the way in storing data for HT/VT and then MLS will integrate with it when they are ready. Does that make sense?

Tom