Home Teaching / Visiting Teaching Application

[RossEvans]

I don't know if I'm totally convinced that the use of MLS export files is as widespread as you propose. Perhaps all of your bishops have used such exports because you were there working them?

This is why a focus group might be helpful, or perhaps a survey sent out to Ward Clerks/Bishops or something. It could ask them if they even knew you could export from MLS and if/how they use the exports.

I think the use of export for third-party helper apps such as Ward Tools (PDA-based, not free) and MLS Companion (personal-computer-based, free) is quite common. What is probably less common are uses such as my own ad hoc queries of the files, because they do require a clerk or bishopric member who is DB-savvy.

As I have suggested in the Wiki, I think early focus groups are a great idea. I have participated in such groups to shape development of commercial online products. The key to eliciting valuable information from focus groups is to educate them about what the real tradeoffs are and get them to own the choices. If you structure a focus group as a sales pitch for a new idea, you just get your own sales pitch parrotted back to you.

Ask me if I want a pony or a speedboat and I might say, "Cool." Ask me if I want a speedboat, but I would have to give up restaurants, and I would think differently.

Also, as Alan_Brown reminds us, the tradeoffs here are not all about the export files, but also about intrinsic functionality that exists in MLS already.

[jdlessley]

I don't know if I'm totally convinced that the use of MLS export files is as widespread as you propose. Perhaps all of your bishops have used such exports because you were there working them?

This is why a focus group might be helpful, or perhaps a survey sent out to Ward Clerks/Bishops or something. It could ask them if they even knew you could export from MLS and if/how they use the exports.

I am tending to go along with mkmurray on this. Just as a piece of information - there are no Bishops/Branch Presidents in our stake who use exported MLS data. Part of the reason is because most are not technically competent enough to do so. Two of the eight who are technically capable probably do not export data because they are not aware they can.

I would note that removing HT/VT data would lead to significant losses in administrative capability in MLS even if the data is never exported.

For example:

The New Member report lists the recent convert's home teachers. If companionships and assignments are not in MLS, this will be blank.
The Household Report shows the household members, the HT district, home teachers, and visit record (and the same for VT).

These reports will no longer have meaningful data if the HT/VT data regarding companionships and visits is balkanized to a separate system.

Also, as Alan_Brown reminds us, the tradeoffs here are not all about the export files, but also about intrinsic functionality that exists in MLS already.

I think both of you are making a design assumption that may not be true or does not have to be true. Balkanization does not have to happen. There is already the capability in MLS to have data flow two ways between units and Church headquarters. There has not been a need up to now to do so with regards to HT/VT. There can be a flow of data between MLS and the HT/VT application if it is so designed into both systems. I envision this design feature being done on the backend or on the servers/between the servers at Church headquarters. The HT/VT data could populate MLS at the unit each time an MLS send/receive is accomplished. Of course this could take its toll on transmission times.

[aebrown]

I think both of you are making a design assumption that may not be true or does not have to be true. Balkanization does not have to happen. There is already the capability in MLS to have data flow two ways between units and Church headquarters. There has not been a need up to now to do so with regards to HT/VT. There can be a flow of data between MLS and the HT/VT application if it is so designed into both systems. I envision this design feature being done on the backend or on the servers/between the servers at Church headquarters. The HT/VT data could populate MLS at the unit each time an MLS send/receive is accomplished. Of course this could take its toll on transmission times.

We are not making a design assumption. We are well aware that the design could be changed to provide integration with MLS. What we are responding to is this post which quotes from the HT/VT project lead on a discussion on the LDS Tech wiki. We're simply trying to point out the negative impact of the balkanization inherent in the current design.

[RossEvans]

We are not making a design assumption. We are well aware that the design could be changed to provide integration with MLS. What we are responding to is this post which quotes from the HT/VT project lead on a discussion on the LDS Tech wiki. We're simply trying to point out the negative impact of the balkanization inherent in the current design.

@ jdlessley,

Alan_Brown is right about this. The real design tradeoff that is evident in the description of the project is basically not between having this new HT/VT reporting functionality and keeping the data in MLS, but one of timing: Get this project out the door ASAP (and have the outside developer Community do it with no integration) or plan for a longer period of development and have the benefits of both.

[mkmurray]

@ jdlessley,

Alan_Brown is right about this. The real design tradeoff that is evident in the description of the project is basically not between having this new HT/VT reporting functionality and keeping the data in MLS, but one of timing: Get this project out the door ASAP (and have the outside developer Community do it with no integration) or plan for a longer period of development and have the benefits of both.

Tom Valleta, a Church employee working on this new HT/VT project with us (the Community), just posted a comment on the wiki. He mentioned he would like this designed so that the new App is the owner of the data, and that other services (he specifically named MLS as one of them) could consume that information for their purposes. Obviously, the code changes in MLS would have to come from Church developers, but we could design the web service for the Church to consume our data.

[mkmurray]

Tom Valleta, a Church employee working on this new HT/VT project with us (the Community), just posted a comment on the wiki. He mentioned he would like this designed so that the new App is the owner of the data, and that other services (he specifically named MLS as one of them) could consume that information for their purposes. Obviously, the code changes in MLS would have to come from Church developers, but we could design the web service for the Church to consume our data.

So I guess my follow-up question is how do you feel about this?

Apparently our tables and services will be the owner of all things HT/VT. We can then let other applications within the Church consume this data through a web service.

With this solution, or we planning suffieciently for the future? Are we good to mark the discussion as resolved and go forward with further detailed design?

[jdlessley]

I had not been to the HT/VT application wiki - just haven't had the time to get involved. Thanks for pointing me to that for these issues. Having read those statements on the wiki regarding the proposed development then I am going to agree with boomerbubba and Alan abut those issues of balknaization. I don't think any of the unit leaders in our stake are going to be happy. If they are aware of the loss of those administrative features I am certain they will elect to stay with MLS rather than migrating to the new application.

P.S. I posted this before seeing mkmurry's posts. His posts indicate that there is some thought going on to address these types of issues.

[RossEvans]

So I guess my follow-up question is how do you feel about this?

Apparently our tables and services will be the owner of all things HT/VT. We can then let other applications within the Church consume this data through a web service.

As I have remarked on the Wiki, my concerns do go beyond just the data-integration issues we have discussed above. I also am concerned about ownership of part of the web-based interface: who develops all the Adminstrative screens in the front end (for defining districts and companionships, and assigning families and sisters to those companionships).

I have qualms about "the Community" taking ownership of all this, because I think that in the long run this functionality should be owned by Church developers. See my remarks in the Wiki under the heading "Administrative Requirements and Integration with 'MLS Web.'" (Rossevans = boomerbubba)

[RossEvans]

Tom Valleta, a Church employee working on this new HT/VT project with us (the Community), just posted a comment on the wiki. He mentioned he would like this designed so that the new App is the owner of the data, and that other services (he specifically named MLS as one of them) could consume that information for their purposes. Obviously, the code changes in MLS would have to come from Church developers, but we could design the web service for the Church to consume our data.

The operative word there is "could."

As Tom says elsewhere:

By using a service oriented approach, we will have the data available to the developers of MLS should they choose to consume it down the road. That is a separate group with their own set of priorities. I cannot speak for that group, nor can I make them consume our data. But I would expect that the benefits of integrating the HT/VT data would be too great to ignore for long.

This is not a done deal. It is an unresolved management issue, which I think would be better resolved up-front. So far, the working assumption of management, as articulated by other senior leaders of the project team, is that there are no concrete plans for integration.

[mkmurray]

As I have remarked on the Wiki, my concerns do go beyond just the data-integration issues we have discussed above. I also am concerned about ownership of part of the web-based interface: who develops all the Adminstrative screens in the front end (for defining districts and companionships, and assigning families and sisters to those companionships).

I have qualms about "the Community" taking ownership of all this, because I think that in the long run this functionality should be owned by Church developers. See my remarks in the Wiki under the heading "Administrative Requirements and Integration with 'MLS Web.'" (Rossevans = boomerbubba)

I want to make sure I don't misunderstand your comments on the wiki. The reason you think that the Community should not develop the Administrative screens for HT/VT App is because it is likely this App will be absorbed by "MLS Web." We could design that module with the ability to be carved out later, but this will be so closely tied to the underlying data that it will be difficult to be completly modular.

Is this all correct?

Let me ask this then...why do only the Administrative functions exhibit this problem? Why not reporting as well? Or other features? If we apply this logic to the extreme, a case could be made that the Church should develop the whole App then.

To me, it appears that MLS Web is just an idea and hope right now. It very could be that the Community might develop much of MLS Web (not all, as I can imagine there will be pieces the Church just can't delegate to us). I don't think the Church Developers have to right the Administrative module on the sole concern that it would integrate better with MLS Web later. I just don't think that's true. I believe the Community can design and implement something that would easily integrate with whatever the Church has later on for MLS Web. The key would be to have enough Church employee guidance to help us in designing something they will be able to use easily.