On 11/22/06, Ben Galbraith <[EMAIL PROTECTED]> wrote:
On 11/22/06, Idaho Joe <[EMAIL PROTECTED]> wrote: > By the way, it's been one of my pet peeves since I started using MLS, but I > was wondering if I was the only one that thought that locking MLS and > preventing any further action during transmission was a poor design idea on > their part? Good feedback. In general, making user interfaces concurrent result in significant additional complexity, which in turn requires a good deal of effort to engineer properly. I'll pass your feedback along. How much of your time does this behavior wind up wasting?
I agree that it can add a lot of complexity to the problem, which is why I would propose that they still lock it for updates, but can be opened for read-only access (like printing roles, or a custom report that someone wanted or looking up a membership record, or printing out the year-to-date donations for a member, or whatever.) It almost never fails, just as soon as I click transmit, someone will walk through the door, and wants to lookup a membership record number or something. As for how much time it "wastes" that's relative to how much data the membership clerk, or HQ has modified and needs to be transmitted. We're still using a modem, so it can take upwards of 15-30 minutes. Generally however, it's only 5-10 minutes. So I do get a chance to get to know a member of the ward or two now and again. But personally, I'd rather do it under other circumstances.
Also, as finance clerk, I'm pretty good at making sure I transmit my changes > to SLC. However, it often annoys me that instead of taking just a short > time to transmit my finances, I get a lot of membership updates, and have to > print out all those reports. Sometimes I really wish that if a finance guy > transmits, only the finances are dealt with. Likewise for membership I'm > sure. (Although I doubt he ever gets finance reports) Good feedback; I'll pass that along.
I haven't given this a whole lot of thought, but I have given an initial consideration as to how I would solve this. At first I though of simply transmiting/receiving only the things that an account has access to modify. (the check boxes in the permissions section of the account setup screen) But once in a while a finance clerk or membership clerk may have admin rights for whatever reason. This would then mean that a finance clerk would have update rights to membership data and so on. So account permissions isn't necessarily a slam dunk. So far, the only solution I've even come close to arriving at is one based on callings. MLS would have to be smart enough to know that the "jgrover" MLS account is attached to record number xxx-xxxxx-xxx which is currently called as "the finance clerk", and therefore would only submit and accept finance update transmissions. EQ Pres would only have to transmit HT visit info, the Ward Clerk would send both finance and membership data, and so forth.
My apologies for the tirade. It's just something that has always bothered > me, and I can't explain why. It's a separate thread to explore this topic, but of course we're all very bothered by software that forces us to go through extra work to accomplish repetitive tasks -- especially those of us who by our natures try and be as efficient as possible.
I realize this may not be the place, but I just though I would mention it because I suspect I'm not the only one noticing these things. -- -- Joe
_______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss