Okay, I just removed my previous post. I'm not sure what I was thinking, but I think everyone here can post full stories when they have something interesting. Bah. ;)
Anyway, I did want to make a post about the management aspect of running a church web site. This isn't particularly related to og or even Drupal, but I did want to make a few comments since I've been the volunteer webmaster of our church for three years.
I like to say that patience is a matter of months or years rather than a matter of days or weeks. That's certainly been true here. I've been working with the church staff to develop this site since 2003 and we've had something up since that time. The first site was just a site to show visitors who we were. This reflected the mentality of the church staff at the time: the only folks that would visit the site are going to be folks looking for a church. Which, was of course, not at all true. The majority of our visitors were members of our church. Mostly the visitors were those who were curious to see if we had a web site and to see what was there. It's taken three years, but the church staff is coming to see the vision that a web site can be much, much more and that the members will use whatever resources we provide. Beyond a few basics, it's probably that most visitors won't know they want a web site resource until they find it.
Therefore, my advice when dealing with your church staff is to be gentle and be patient. "The meek shall inherit the earth." That's more than good theory.
So now, I've got the church more or less on my side of the communication and collaboration issue. Now, I have to do something about it. Man, am I busy all of a sudden!
On Monday, I had a face-to-face meeting with the Pastor of Community, Todd. In this meeting we talked over the kinds of things I think we can do. He can work a computer to do what he needs, but he's really got no experience with anything like this, so he doesn't know what we can do. The first step is education. I have to explain scenarios he can understand and he will find useful. This is a 100% push by myself. I've felt a bit, sometimes, like nobody cares. The reality, I've come to realize, is that nobody knows what the tools can do until I tell them. Really, they don't know until I show them, give them a reason to use them, and then they try them out. Others can then find them useful by looking at the examples of others.
Okay, so I've told him what's coming. I've used some materials for the latest study we're doing in the main gathering to create the basis for a new leadership group to give an initial demonstration. I've put the ball in Todd's court to try things out, but I don't really expect him to do anything with it until he has something concrete to do. Therefore, my next task is to get him on the phone and figure out if I can help him find something to do with the system. Todd leads one of the small groups, perhaps I can get him to try creating a group and see about getting him to talk to his group about trying it. If I can get him to try it, he can start pushing back and tell me what works and what's broke. If he can get a couple of his group members involved in that process as well, bonus.
At this point, I'm just trying to build momentum for the idea itself. On the technical side, there are a few stumbling blocks that do need to be dealt with. Our site is ugly. The new design should be up this month, but that's just one part of the problem. The standard Drupal UI has a few gnarly edges and I need to be careful that those don't create too steep of a curve. However, I can overcome technical problems with enough time to make the changes required and patch or build the necessary modules. I'm not too worried about them at this point.
The main issue remains the people. When that flips over or I come up with something interesting beyond what's found in the OG documentation, I'll post some commentary on the software aspects.
Cheers.
Comments
Excellent points
I'm a bit further back in the process, but I can relate. Been working on the site for nearly 6 months. About 2 months ago, I realized that it's going to take me sitting down one-on-one with the head of each ministry and walking them throught what I think the site can do for them. Then letting them tell me what they like and don't like. Of course right about that time, everyone went on vacation.
So I've spent some time working on ease-of-use features like jscalendar, TinyMCE, Scripture filter and implementing some sort of comment moderation. I think my best bet to get staff buy-in is to make the site as easy to use for the non-techie as possible. An attractive layout will make people eager to try it out (that's next) but if it's not super simple to use, they'll probably write it off as counter-productive.
Wish me luck with my web-evangelization task next week.
Luck has nothing to do with it...
Godspeed, skor.
I'm writing a "How to use
I'm writing a "How to use the website" document to give to the content creators. I'm walking them step by step through the process of creating events, news posts, and newsletters.
I'm also going to have three 1-hour training sessions with all the users via a laptop and projector.
@ericatkins
A Bit Further Along But Going Through Much Of The Same Process
I am a bit further along, having worked on our website for about 2 years now. Drupal is in fact the third CMS that I have used. The first was WebGUI (Perl based) and ran on a server in the church building. The second, currently in use at http://www.barcroft.org, is Mambo (Php based). I was forced to move to a Php based CMS because of limitations on the ISP (they refused to load some specific Perl modules). We are currently in the process of moving the Mambo based site to a Drupal based site, at http://drupal.barcroft.org (currently very ugly, but due to change in the next 2 weeks). I understand the interface to the church administration very well. We went through an analysis of what we ultimately wanted to do and then formulated how that would be displayed to the user. From Comments that I made on a previous blog at http://healyourchurchwebsite.com/2004/09/13/call-for-some-purpose-driven... :
"I am an elder at Barcroft Bible Church in Fairfax, VA. My Worship/Music pastor and I are in the process of revamping our church website. By day my job is as a Tech Advisor/Sr. Software Engineer for a defense contractor and I am very familiar with the need for a requirements statement prior to going into battle with system development. My Worship/Music pastor just recently completed his Masters in which his thesis revolved around what you can do with church websites. So at least we were on some common footing.
Looking at our website, we put forth three propositions of what we wanted our website to do: (1) to be a means of advertising the church to the community (who we are, how to get to us, what to expect, what we believe, etc.); (2) to be a place for the congregation to communicate with each other (prayer, discussion, calendar, contact elders, conduct church business, etc.); and (3) once the communication has been achieved, to encourage the members of the congregation to participate in evangelistic outreach by posting stories, material, movie reviews, etc. on the website. These three things became our statement of vision for the website.
From the statement of vision, I constructed a strawman requirements statement broken down into ministry and technical requirements. This requirements statement was passed around to several individuals in the congregation for comment and along with the statement of vision, amounts to about 6 pages of type.
One of the technical requirements forced us into an early tactical decision. We wanted to be able to give different individuals in the congregation the ability to change a specific portion of the website, without huge expense in buying development software - and be able to control what individuals see depending on their “rights” within the website. This led to the decision to use a Content Managment System which would allow login and close control of implementation. We wanted to give individuals involved with our Adult Bible Fellowship classes, for instance to grow their portion of the website as they saw fit to meet their specific needs. We settled on WebGUI."
BTW, I highly recommend http://www.healyourchurchwebsite.com as a source for all kinds of things to do and not do on a church website.
As far as Drupal is concerned, I am currently in the process of figuring out an access control mechanism to constrain individuals in different categories to see/edit specific parts of the website without allowing the casual visitor to see the whole thing. So far the Container/Category module appears to be the way to go. I haven't quite decided if it has enough security however. Any thoughts on this?
Geek Herder
Geek Herder
taxonomy access
use taxonomy access to control access to certain parts of the site - by category - for different user roles
Your choices are essentially TA or OG
You're at yet another fork in the road. Drupal has two main different modules for access control, and they're incompatible with each other. I implemented Taxonomy access because it seemed the better choice, but it has some significant gotchas. It works well if you have a very simple structure, i.e., if you have only a few roles, and those roles are homogeneous.
However, it sounds as though the path you're heading down might be one that is better served by the Organic Groups module. OG (as it is known around here) allows for simpler administration of many different subgroups (roles) each with access to a different subset of nodes.
I still haven't found a satisfactory piece of documentation that explains all the ramifications of choosing one over the other, which is a major flaw, IMHO. It's a big, important decision that needs to be made early on in the life of a site, and it can't really be understood when it needs to be made.
TA or OG- I prefer OG and here is why
I have used both and I think that OG is the answer to this question:
It is:
more straightforward
easier to understand because it relates content to people via groups
node creation allows you to select which groups can see the node
dovetails nicely with alot of other modules
Tax access relates categories with roles. Roles is suited, IMHO, more for who can do what on the web site. The interface can get real busy the more kinds of nodes that you have.
For example,
With TA, you would create a ROLES for PASTORS and grant them certain permissions for certain TAXONOMIES. All PASTORS would have the same rights. This is not what you want on your CMS. A novice could really break alot of things.
With OG, you would create a group for PASTORS and then grant permissions via ROLES. Then each PASTOR can be put into a ROLE (call it editor) and they be granted access to the GROUP. The ROLE would be based on the their own Drupal skills and still allow them ACCESS to content relating to the GROUP.
Enjoy!