Page 1 of 2
Posted: Fri Jun 08, 2007 6:53 pm
The current implementation of the LUWS aimed to accomplish alot. Just look at what the original designers tried to pack into it, everything from a building reservation system, to calendaring, to email groups.
Maybe they tried to pack in too much.
Let's forget for a minute about all talk of new features. What if the current offering was simply re-tooled to do what it set out to do in the first place? ...but do it well? What if the current feature set was, well, complete?
What if a member could create and retrieve his own account username or password without the clerk's help? What if the Membership Directory could list cell phones and emails for un-registered individuals? What if email addresses and preferred names were synced between MLS and LUWS? What if members could update their own address and phone? What if Admins could properly administrate their email groups and subscriptions? What if a Relief Society President could send an email to the RS group without being an Admin? What if that same RS Pres could compose/send that email from her own familiar email application? What if you could print the Photo Directory on a reasonable number of pages? What if the calendar worked like iCal? What if maintaining the Leadership Directory wasn't double data entry?
Would that save you and your bishopric any time? Would that make the LUWS more useful to more members? Would that allow wards to keep better records? Would that allow you to focus efforts where it counts most? Ultimately, would fewer members fall through the cracks and more saints be perfected?
If I understand right, the MSR Department is the client for MLS/LUWS. Where does saving the time and improving the effectiveness of unit leaders through technology fall on the MSR Department's priorities?
Posted: Fri Jun 08, 2007 10:34 pm
Some excellent points in my opinion. Thank you for your thoughts.
Posted: Sat Jun 09, 2007 7:20 pm
grhart wrote:Let's forget for a minute about all talk of new features. What if the current offering was simply re-tooled to do what it set out to do in the first place? ...but do it well? What if the current feature set was, well, complete?
Actually, I think most of the requested features is to do exactly that. (HT/VT being the only exception that comes to mind.)
Posted: Mon Jun 18, 2007 1:48 pm
grhart, these are excellent recommendations. I'll be honest, I have and still am considering rewriting the entire Church's online system in Ruby on Rails to show them how agile and powerful that platform is in order to accomplish the apparent goals in a more refined and appropriate way and then putting it forth for examination and review for possible acceptance. My problem is that of lacking the time to do so as a result of not having the funds to pursue it.
There are many things that need to be refined and resolved and it is unfortunate that the Church is utilizing a bulky underlying technology.
Finally, one thing that has been nagging at me terribly is that of keeping an up-to-date ical feed so that my various calendaring systems (iCal on Mac OS X as well as Google's Gmail Calendar) can feed off of the General, Stake and Unit calendars (I would prefer not to have to write a script that deletes, logs in, pulls down a new ical export, and imports that if I can avoid it). One thing that would be profoundly useful would be to not only have this but to also have a much more flexible calendaring system with various fields. Our stake seems to really botch up the apparent intended use of the calendar by putting things on there that are superfluous to quickly seeing what pertains to our unit versus the stake versus families, etc.
There are many other things that could be tied into this system as well besides those above if they were all resources loosely tied together in a RESTful approach. We could have an astounding information management tool for not only Church functionality, but for family use and planning as well, including individual lesson and talk planning, etc.
Posted: Mon Jun 18, 2007 6:03 pm
ylon wrote:There are many things that need to be refined and resolved and it is unfortunate that the Church is utilizing a bulky underlying technology.
Which technology is bulky? Just out of curiosity...
Keep in mind that the Church seems to have taken a position to keep up with new technologies, but they don't really jump on the bandwagon until it has been tried and true to meet their needs and be flexible enough for the future. (I'm not saying anything of the merits of Ruby on Rails, I've heard nothing but good about that technology).
Posted: Mon Jun 18, 2007 8:44 pm
Certainly, not a problem. I am basing my comments on what I've found on Joel's blog.
No matter which way you slice it, the java stack is bulky. Now, having said that, groovy does go a long way in making it even more agile, per se, than that which is outlined in the blog above.
I completely understand being cautious, however in this situation with an open platform that is proven, stable and robust it no longer lacks the requirement of being cautious on this matter.
Interestingly some of the primary folks behind Ruby and Rails are LDS. For example Yukihiro Matsumoto, or "Matz," as he is known online, is the father of Ruby and is a Latter-day Saint from Japan. You can find him talking of when he was a missionary and I've even seen him quote the Book of Mormon in his comments for a Ruby book. Jamis Buck, from BYU, is also another driving individual on the Rails core team.
The reason I mention this is that I find that using the Ruby programming language is a lot like the gospel in that there is a "coming home" feeling that I first felt while learning the language. Interestingly I had a similar feeling with Mac OS X after fighting between Windows and Linux for many years. Some things seem to just click and make everything more beautiful and just make the world a little better place.
At any rate, enough musings I guess. If you personally would like to see just how "agile" a development stack can be I would highly recommend that you take a look at hobocentral.net and see how far Tom Locke has driven rapid web app development. Very interesting stuff and very good abstraction between logic and design.
Just a cute note, I got a kick out of the commercials that these fellows made for Rails:
http://www.railsenvy.com/2007/5/14/ruby ... commercial
Posted: Tue Jun 19, 2007 7:20 am
We have people working with and investigating Ruby internally. When you read about our Java stack, you are assuming that the stack is used for everything we do. We try to pick the best environment for the task at hand (also considering what platform and hardware we need to run on). So we do have a lot of Java development here, along with .Net development. We continue to look at Ruby as a possible development platform in the future.
Posted: Tue Jun 19, 2007 7:42 am
Hi Tom, thanks for the note. I had assumed that this may be true prior to writing this, but I'm glad to hear it from someone from within.
Posted: Mon Jun 25, 2007 3:28 pm
tomw wrote:We have people working with and investigating Ruby internally. When you read about our Java stack, you are assuming that the stack is used for everything we do. We try to pick the best environment for the task at hand (also considering what platform and hardware we need to run on). So we do have a lot of Java development here, along with .Net development. We continue to look at Ruby as a possible development platform in the future.
Does the Church have a separate team that researches new and emerging technologies or is it like most companies where the developers play with it and test it on internal applications?
Posted: Tue Jun 26, 2007 7:11 am
bhofmann wrote:Does the Church have a separate team that researches new and emerging technologies or is it like most companies where the developers play with it and test it on internal applications?
Some of both. At times we do assign developers on "research" type projects to determine the feasibility of a particular technology. Other times it "morphs" into the organization through individual experience.