Richard Pyne wrote:
If the application is written as a hosted web app, it really doesn't matter what platform the end user has as long as it has a browser and net access. I have no doubt that there are plenty of people out there (me included) who would be happy to host it for our units, and likely other units, if the Church doesn't.
The argument to a hosted app that continues to be hashed on this list is that most of the meeting places don't have internet access. Also, someone on this list mentioned that leaders don't want to write down information (i.e. update printed reports) and then have to enter this information once they get internet access. In other words, they would like to only have to record it once. Finally, there is the argument that if information is on-line it will get hacked, used by pedophiles, the church will get sued for all it is worth, etc., etc. I personally think these are all weak arguments because at some point, in order for scout tracking software to be more useful than what is already available (e.g. "troopmaster"), the database will need to be on-line:
(1) Unless there is only one scout leader that does everything the database will need to be shared by the other scout leaders and, not to mention, the YM leaders, bishopric, etc. Troopmaster, for example, solves this problem with its "dot net" product. In short, it uses FTP to upload the database to an on-line repository and then other leaders then can download the database. However, in order to update the database someone has to upload a "lock" to the repository. If the lock is present then others can't update the database until the lock is removed. Of course, folks forget to unlock the database and no one else can update the database. A hosted app would solve the locking problem since the database would only be locked for *single transaction* and not an *entire session*.
(2) One of the things that is emphasized in the church handbook of instructions is that the YM (and scout) leaders should support the parent-child relationship and not compete with it or substitute it. A hosted app allows the parent to be more involved since they could review their Son's progress on-line and even update requirements to be passed off by the merit badge councilor, etc. The troopmaster dotnet software model does not work here since installing and supporting an app on every parent's computer could be a support nightmare. A hosted app works as long as the parent has a working browser on whatever flavor or version of operating system they may be running.
(3) etrailtoeagle.com has a nice feature for setting up email "report subscriptions" that we have found to be useful. We use etrailtoeagle.com to track Duty to God (D2G) progress for each of the YM. We have set it up so at the first of the month the individual D2G progress report for each YM is automatically emailed to the parent. Parents find this useful because it lets them know what has been passed off in quorum meetings. Also, it is kind of a friendly reminder to the parents about things they can be working on for the upcoming month. We also will get a lot of feedback from parents about things they passed off in the previous month that has not be recorded shortly after the reports have been emailed. In addition, the YM president and bishop get summaries of the YM's progress. The summaries show the percentage of the requirements, broken down by section, that have been passed off. It also shows the tenare % and days left before they are of age to advanced in the priesthood. These numbers to YM president or bishop can be more informative about how an YM is doing than just attendance records.
(4) Having the database hosted can help with the problem of backups. I have personally found that a lot of people don't regularly backup their desktops but most hosting providers will provide this service on a regular schedule. Another possible option for those that don't trust their hosting provider is to have the hosted app automatically email a few of the leaders a backup of the database on a periodic basis.
In my opinion, the ideal scout/YM tracking software would be both a hosted and desktop/laptop application. The main database and web interface would be a hosted application. If a scout/YM leader would like to work with the data disconnected then he could download the database to a desktop application version of the scout/YM tracking software. Any update transactions he makes to the downloaded database could be "replayed" to the hosted application version of the database when the scout/YM leader is connected to the internet (aka. "sync'ing"). Since the database is only updated (usually) in a "forward" manner then sync'ing should be trivial. There may be cases where another leader has passed off and recorded the same requirement for a YM. The sync'ing software could simply display a warning in this case (e.g. "Scout Billy has already passed off such and such requirement."). Other not so trivial sync'ing conflicts may require a little human intervention. In short, the desktop application would keep a transaction log and replay the transactions when it syncs to the master (hosted) database.
Please note that either version of the scout/YM tracking application could run totally independent of the other. Running the hosting app version of the software without the desktop version is obvious. Running only the desktop/laptop version only could be done as well. One would never "sync".
The only thing that needs to be the same between the desktop and hosted version of the application is really the database structure and the sync'ing protocol. This could be spec'ed in an open RFC-like document. Once the RFC is approved then developers are pretty much on their own to provide the implementation in whatever language/database they fancy for each version of the application. For example, the desktop version of the application may be written in Java so it could be used on Windows, Mac OS X, or Linux/FreeBSD. The hosted application version may be written in something that most hosting providers have on their servers like PHP or Perl so it is only it only works with a small subset of the hosting providers available. Our RFC shouldn't dictate the implementation just like IETF RFC's. The implementation is left up to the programmer(s).
FWIIW, -stacey. _______________________________________________ Ldsoss mailing list [email protected] http://lists.ldsoss.org/mailman/listinfo/ldsoss
