The future of MLS exports

[RossEvans]

I have encountered informed speculation in some circles lately about the future of the MLS export function. The gist of the speculation is that as MLS-like functionality migrates to the web, someday the Church may expand its APIs to allow authenticated users to download such content from lds.org, and that the use of these APIs would be limited to Church-sponsored apps. One scenario is that the generic export functionality such as MLS now provides then would disappear. It's only speculation, but I think it is worth discussion here.

My own opinion is that expanding API functionality, authenticated via LDS Account, would be great. So would the creation of popular apps, such as those on handheld devices, under Church auspices instead of just leaving that development to third parties. (So far the only apps announced, notably Mobile Member, have been limited to a small subset of data available to rank-and-file users on the web, and no decision has been made about leadership-oriented apps driven by a superset of more confidential data such as MLS exports provide.)

But I think eliminating generic export functionality, which has always been part of MLS and its predecessor MIS, would be a big mistake.

No matter how clever the central developers are -- either Church developers or "community" developers -- it is folly to think that the apps they build will exhaust all the possibilities and meet all the needs of local priesthood leaders and clerks. Life and software development just don't work that way. As an assistant clerk, I do lots of things for my bishopric using the generic export files, and this forum is replete with creative ideas from many other contributors.

Additionally, although sophisticated APIs can provide a higher level of technical service available to a relative handful of technically adept developers, that still does not substitute for the lower common denominator of CSV files that most any bishopric member, stake leader or clerk can access using commonly available tools.

My own hope is that as MLS functions move to the web, there will be a parallel migration of export functionality. A good transitional step would be the replication of the core CSV export files from MLS, with some of their worst deficiencies corrected, available online with LDS Account authentication. This path then can supplement the development of new programmers' APIs and community apps.

The ultimate users being served are the local priesthood leaders, who have stewardship over this data because it is integral to their callings. Whatever happens, it is not a good idea to lock them out of access to the raw data in easily accessible form.

I just want to voice that opinion here in case this really is a serious possibility under consideration.

[nutterb]

I'm with you on this. I find the Export .csv's to be indispensible. I use them to do a number of tasks that I'm asked to do routinely that aren't part of MLS including some larger, less frequent tasks (like building my preferred structure for a ward photo directory). My calling would require an incredible increase in time just to do some simple tasks without these.

[jbh001]

On the flip side, eliminating the export function means that the Church has more control over how the data is used, thus reducing its risk. As long as the modeling and custom reporting tools made available to local leadership via some future hybrid implementation of MLS via LUWS are actually worthwhile then I don't have much of a problem with losing export function.

For example, if accessing the LUWS membership directory via iPhone/iPad was at least as good as Ward Tools on the iPhone, then I would not mind losing MLS export functions.

When some web pages detect that they are serving to an iPhone or iPad they serve specialized content that make the web page appear and behave more like native iPhone/iPad app than a typical web page, like Apple's iPhone user guide when viewed from Safari in the iPhone (http://help.apple.com/iphone/3/mobile/).

Example 1, Example 2, Example 3

[russellhltn]

For example, if accessing the LUWS membership directory via iPhone/iPad was at least as good as Ward Tools on the iPhone, then I would not mind losing MLS export functions.

But taking that from the personal case to the general case, that becomes a big "if". It would have to match the performance of not just Ward Tools for the iPhone, but the leading applications for each platform. It would also have to work when the data connection is flaky or non-existent. (Considering that Verizon users can't browse and use the phone at the same time, that will be significant for Verizon users.)

Right now I'm dealing with the fact that the new beta LUWS is less functional on my phone then the existing LUWS.

Keep in mind that one has to have Admin rights on MLS to get access to the data. I don't mind that the church is developing additional applications that will minimize the need for exported data. I don't know as the church has to remove the export function to improve security. I'd prefer that they take a "competitive" view that they will offer both and hope that their offering leaves exports unused. After all, having to use exports is a pain since you have to manually export and transfer the data. A over-the-air/web connection would be so much better for most users. As exports become more the exception, then it becomes easier for local priesthood to monitor who gets them.

[RossEvans]

On the flip side, eliminating the export function means that the Church has more control over how the data is used, thus reducing its risk. As long as the modeling and custom reporting tools made available to local leadership via some future hybrid implementation of MLS via LUWS are actually worthwhile then I don't have much of a problem with losing export function.

For example, if accessing the LUWS membership directory via iPhone/iPad was at least as good as Ward Tools on the iPhone, then I would not mind losing MLS export functions.

Of course there are concerns about protecting the data content, which have always existed since the revolutionary "three-ring binder" and photocopier technology was introduced decades ago and put the portable membership content into local leaders' hands. I suggest that since local priesthood leaders own that fundamental responsibility, it basically applies to protecting the content regardless of form. No doubt there are better security tools (encryption, for example) that can be provided to help local leaders handle this responsibility. It also would not hurt to flesh out the policy guidance governing such access. But prudent mitigation is a far cry from cutting off access to exports altogether.

A handheld app like Ward Tools is great as far as it goes. (I happen to work on that project.) But it is just one dedicated end-user app, and populating such a handheld tool is far from the only reason for MLS exports to exist. Like any dedicated app, Ward Tools has certain defined and limited functionality. Likewise, the custom-report function within MLS is also very useful -- up to a point. In fact, one of the most useful properties of the custom-reports feature is that it embodies its own export function. By design, if the MLS user has the privilege to view or print a custom report, he has the privilege to export it to a delimited data file or spreadsheet. I can recall some important tasks I have accomplished for my bishop that involved both MLS custom reports and exports, with the final product produced in an external database and delivered in a spreadsheet.

There are many tasks I have handled as a clerk that really could not have been done effectively without the flexibility of exporting the data and crunching it in external software. One such monthly task happens to be on my plate right now. Our bishopric has mandated a process, specific to our ward, to maintain fast-offering routes and produce custom printed maps for the priesthood teams to service. I doubt that any such functionality will exist in centrally delivered applications in the foreseeable future, especially since every ward has its own particular needs. Even once the beta maps application goes live, the way it could be incorporated into this process would be for the clerk to capture its geocoded export files, which are there by design for authenticated callings, and crunch them with MLS exports in external software.

I have spent much of my career building data-driven applications on various platforms, and I have never seen any end-user application anywhere that does absolutely everything its user base might want or need. Realistically, applicaton architects tend to aim for an 80-20 ideal in what they can deliver, with some of the uncovered 20 percent of the use cases being open-ended and undefined. Thankfully the designers of MLS (and MIS before it) were wise to include generic export functionality to fill in such gaps.

[drewy]

I like the export option:

I use notepad++'s compare function to see whats changed recently in the csv files