From: "Idaho Joe" <[EMAIL PROTECTED]>
Reply-To: LDS Open Source Software <ldsoss@lists.ldsoss.org>
To: "LDS Open Source Software" <ldsoss@lists.ldsoss.org>
Subject: [Ldsoss] MLS blocking (was: Wireless Networks in Church Buildings)
Date: Wed, 22 Nov 2006 16:07:43 -0700
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
