These two go together: I don't think the church would be okay with you
pulling all of that very confidential information (birthdates and
membership numbers?) out of MLS and into some other system. I also don't
see how membership numbers help in an emergency preparedness system.
Birthdates are understandable, but I think that substantially the same
thing could be accomplished with a birthyear or age field instead. The
contact information isn't quite as sensitive, in my opinion, as much of
it is already published elsewhere.
 
Very good points.  The birthdates are only there for calculating age.  Birth year should be good enough for my purposes as well.  I was planning on only showing the current age anyhow.  I was going to use the membership number because the plan is to import names and contact info from MLS and I wanted an easy way to link the MLS records to my records, but you are right.  It would probably be better to link them by name and assume two people in the same ward won't have the same first last and middle name.  I will still have a problem if someone changes there name, but I guess if that happens I can just delete the old record and create a new record. 
 
 

If you can eliminate the need for especially sensitive information, and
use SSL (even a self-signed cert), and know what you're doing in your web
development, it isn't impossible to write a secure application. Of course,
the security of the machine hosting it is also a factor in the overall
security of your data. So on MS Windows, it might be a losing battle no
matter what... ;)
 
 
 

> 3.  Administration
> If we create a web application, we would also need someone who can do basic
> administration stuff, like redeploy the application when it goes down and
> stuff like that.  That means if I move, either we find someone else to do it
> in the ward to do basic admin stuff, or the emergency preparedness program
> dies.  If they have a simple application, practically anyone can use it who
> can use a computer.

This is going to be an issue with any system. Ease of use and ease of
administration are separate issues, but I think you may be right, an app
that doesn't require a web server would probably be easier to administer.
Though make sure to consider how to install it, import and export data,
and migrate it from one computer to another.

The counter argument to this is that having it available on just one
computer as a desktop app means only one person can view or edit it at a
time, and they have to be physically present at the computer where the
program runs. Which would basically force it to be a clerk's office
program in most cases. And a clerk's office computer already has enough
contention for getting into MLS in most wards.
 
Our Emergency Preparedness representative will be the one using it.  It can easily be carried around on a thumb drive for portability.  I believe the plan is no one else will use it other than him.  And if someone else wants to it will be simple to import and export data.  I'll probably have the software create paper or email reports as well that can be handed out to the leaders of the zones. I plan to create an installer so installation should be a breeze.

> 4.  Without internet access, the app can't be used.
>
> 5.  Web hosting generally cost money

Both of these go away if the computer hosting it is running Apache (for
example). It's easy to host an Apache+PHP system on any OS (especially
with WAMP or LAMP setups, or even on OSX). This would also mean your
program could be cross platform, both for hosting it and for accessing it.
And when the machine is connected to the internet, the program would be
accessible, and when it isn't, it would still work locally. At least then
you'd have the choice of internet operation or not.
 
It is easy for people like us who are more technically inclined, but not so easy for someone who is not as familiar with computers.  The person who asked me to do this and who will be using the software decided not to buy a router because it's too complicated to set up.  He decided the web page configuration was too much to worry about.  Not to mention he uses dialup for his internet access, so setting up a server at his home would be less effective.  Of course maybe others will want a web app, so if someone wanted to and thought this was a useful app, they are welcome to create a web version if they are so inclined.


If you're going to make this open source, writing it in PHP for example
would make it more accessible to people who want to customize it.
 

Also, believe it or not, some clerk's offices are authorized for internet
access, and I hope they continue in that direction. When your clerk or
exec sec (whoever's in charge of the web site on lds.org) doesn't have
internet at home, it's a real pain, not to mention the difficulty of
getting everything updated when you can't just pull it up along side MLS
to compare.
 
I've heard that.  Unfortunately, our ward isn't there yet.  :(

One last note: I may be wrong about this, but last time I looked, I seem
to remember that MLS had support for adding custom "talents" or somesuch
to a user's record, so that things like has a truck, chainsaw, or
generator, is a doctor, nurse, or EMT, or is trained in CPR, first aid,
home construction, or emergency radio communications, could be added
directly in MLS, so you wouldn't need to write a separate application at
all, nor worry about exporting sensitive MLS data to somewhere else. Plus
it would get backed up automatically every time MLS gets backed up, and
possibly even backed up to Church HQ with the other data.
 
Interesting, I'll have to check into that.  Can MLS then export the data?  Part of the purpose of the software is to create reports, visualize the data, and help the Emergency Preparedness create zones that I mention on the web page.  It would be really nice if I could write a plugin for MLS to do this.

Mac

--
Mac Newbold             MNE - Mac Newbold Enterprises, LLC
[EMAIL PROTECTED]      http://www.macnewbold.com/
_______________________________________________
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss

_______________________________________________
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss

Reply via email to