Posted by flickerfly on March 18, 2009 at 1:25am
It seems the variety of options to create some sort of distro or feature set or pattern or template or whatever are broad, but one thing that is united under all of them is the need to collect a list of what sort of features should be included in this. So what features do you think every or most church websites should have. Let's stay away from modules, how it would be accomplished.
This is a question about defining the problem. We can figure out how to solve it later.
Comments
Church Website Feature Definitions & Roles Brainstorm
So I'm thinking we need to have a variety of
content typesfeatures. Maybe in the end some could be optional add-ons depending on the church.I'm thinking that content types also suggest a list of features such as attached views for the various content types.I'm also thinking we need a few roles pre-defined:
Edit:
I'd originally talked about features as equivalent to Content Types. I'm thinking this as a mistake. Bringing Drupal terminology in at all at the problem definition level is probably asking for distraction. Sorry about that. I've also added a couple of the ideas.
Sermon Series
How about Sermon Series?
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Volunteer Opportunities
How about volunteer opportunities where it is easy to post an event or node and have a Volunteers section where the creator can add various volunteer roles (setup, clean-up, hospitality, greeting, logistics like directing people, parking lot attendants, etc.) with a quantity required for each role. Then give people a link to sign up for the volunteer role. When they do an email is sent to the creator or coordinator so they know someone has volunteered.
ChMS
This sounds interesting, but I'm not sure what it would really look like though. Would this be attached to events? Would we have pre-set volunteer opportunities or would we need to have the ability to easily create new volunteer positions?
@roydean, have you done this already?
No, I have not done this
Not trying to solve the problem yet, but. . . .
My thought is to create a recordset of volunteer requirements or roles or positions or whatever you want to call it as you are creating the event. Maybe it could be a separate tab on the create content process that for any node you could have the ability to create volunteer opportunities.
I am thinking this way because many church posts will be about events or things you want people to get involved in. Currently these posts are limited to announcement type posts where you simply expect people to read and if interested they will participate. Sometimes people need to know in what ways they can participate. Perhaps they don't want to attend a seminar, but they would be happy to serve in a hospitality role. Making sure the room is set up, coffee, water, etc. All these things are needs in a church community. I don't know if this is even something that should be part of a post, but it seems interesting to me. I would be inclined to use a module or workflow or process or whatever that provided this functionality.
Additionally, as people see the opportunities to serve, they can put their name in as being willing to help. Like a subscription process, but the wording would be "I can help with . . ." and then give them a set of checkboxes or something to check off how they can help.
An interesting thought. If it does not pan out or if someone is not interested in writing the code, then it will die because I am not capable of writing code like this. Thanks for letting me throw out an idea.
Here's another somewhat
Here's another somewhat complex feature that CiviCRM already provides. (granted, it's not particularly friendly to set-up, because it requires setting up a 'CiviCRM Profile')
For a pure drupal solution, perhaps Events are an Ubercart product with an option for 'participant role' where volunteer roles set the price to $0.00 ? Any uber-builders around who can verify if this works?
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Let's not solve the problem
Let's not solve the problem quite yet. First we have to know what we're solving or our solution will end up being of limited use.
cck
seems to me this functionality can all be provided by cck, and maybe a webform / trigger / action type setup. Perhaps a wizard that sets it up would be good, but I don't think all that needs to be duplicated. plus then you'd still have all the control of cck and views, etc
Yes, probably so . . .
I am just not real familiar with how to set something like that up. I am just getting my feet wet and it is a very long learning curve for me. I think that if I just jump in and see how things behave I would be more comfortable, but I keep worrying that I might hose a site.
No one is suggesting that we
No one is suggesting that we shouldn't use CCK, etc. The trick is packaging together these cck/views/trigger configurations in a re-usable way, e.g., via patterns or install profiles. Maybe that's what you mean by 'wizard' ?
If so, the Patterns Install profile allows the user to select from various patterns during install, as a sort of wizard:
http://drupal.org/project/patterns_profile
Screenshot: http://drupal.org/node/410742
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Great discussion - can you add to wiki?
Some good thoughts and features...please add to the wiki anything you want to see in a distribution and your thoughts on how to best accomplish.
If you haven't seen it the wiki is here: http://groups.drupal.org/node/19972
Lee
Obi-Wan (Lee Raney)
Dallas Drupal Group
www.KoineMedia.com
www.Christian.com
Lee Raney
Dallas Drupal Group
www.ChurchFinder.com
I started this discussion in
I started this discussion in hopes of defining the objectives. The wiki you linked is, in my opinion, putting the cart before the horse. It is encouraging the discussion of a solution to problems that I don't think we globally understand yet. What a sermon is to one church is different from what a sermon is to another church. I've done two church sites at this point. The sermon to one was simply an audio file, speaker and a description. On the other site, they wanted notes, transcripts, passage of scripture, series and so forth. On other sites, they want to have video and audio content. Other places may want to link the sermon to a service or provide for bible study recordings that are similar but different.
Which of these types of requirements are we trying to solve?
I suggest that we need to decide what of these are common enough, and still leave an option to add the others without much hassle.
Our initial outline should be able to be used as guidelines fon any CMS to create a church distribution. It would be not unlike the guidelines I've heard talked about for the much publiziced drupal, joomla, wordpress shoot-out at SXSW. Maybe it could also be used by CiviCRM guys to see the differences.
Sounds good use this post to discuss
Sounds good Josiah. This post is a good place to discuss requirements, features, etc. Maybe as things are agreed upon the are added to the wiki? You are right whatever is decided could be used by any CMS not just Drupal so we should think about at that level before going into Drupal solutions.
We'll never have complete consensus but what we will end up with are several scenarios:
Feature Every Church Wants
Feature Every Church Wants
Feature Some Churches Want
Feature Some Churches Want
I think for #1 and #2 those would be included in distribution, for #3 items after more discussion if a majority consensus is reached we make a decision, and for #4 maybe not even put in the distribution.
BTW not sure if there was a drupal-joomla-wordpress shoot-out this year I was only there for part of SXSW but did not hear about it. I heard about that last year and heard it was good.
Lee
Obi-Wan (Lee Raney)
Dallas Drupal Group
www.KoineMedia.com
www.Christian.com
Lee Raney
Dallas Drupal Group
www.ChurchFinder.com
Agreed, we will, even do,
Agreed, we will, even do, need a place to put solutions to the problems determined here. That wiki page seems like a good place for it.
I like your categories for features. We may want to investigate spaces and context modules for sets of features in the future. I was just watching some screenshots on them and they may provide some neat options to package features up as optional add-ons.
No, this is Drupal...
@flickerfly
This group is committed to using Drupal, so why shouldn't we use the vocabulary of Drupal to define the problem?
To continue your example, the issue is not really a different view of 'sermons' if a 'sermon' is a Drupal node type.
We can easily define the 'sermon' node type as containing one or more files of any type: audio, video, PDF whatever.
Then, notes, transcripts, scripture lists, series, etc, are additional note types (node-referene'd to sermons) or taxonomy vocabularies that can easily be enabled or disabled on a site-by-site basis. We include them all, and church that don't need them can ignore or disable at will.
There is one key question that we need to discuss for clarification of the end goal. I can best phrase it by way of metaphor:
Drupal is a huge box of legos; you can use them to build a house or a helicopter. Are we looking to deliver a finished house, or just a subset of legos for building your own house more quickly and more easily, with some of the pieces pre-connected?
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
The reason it is important
The reason it is important to not define the problem using drupal vocabulary is because drupal vocabulary is a technical vocabulary dedicated to defining solutions, not problems. The usability team noted the same problem when doing usability testing. The leader of the testing has stated in at least a few places publicly that one of her greatest challenges was keeping engineers from solving the problems before they were clearly demonstrated and understood.
By talking about solutions and problems at the same time, we end up restricting our understanding of the problem to solutions that are already know and keeping us from the opportunity of creatively seeing a better, more efficient and potentially easier solution once the problem is fully stated. In other words, we only see the problems we think we can fix and neglect those that are difficult or we see only part of a problem and end up with a solution that only helps a limited amount of the potential group.
Part of this structure is increasingly needed simply because of the openness of the project. Clear communication will simple result in better results. Clear communication is rarely a mistake.
I respectfully disagree
I respectfully disagree with your approach. Part of the reason is represented well in this short essay:
http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_...
In general, the time lost by re-building or revising a feature which has been created prematurely is less than the time lost trying to define problems that don't exist yet. Stated another way, time spent thinking of problems is time better spent solving the problems we already know about. Imaginary problems might go away once we get busy with the real work, and even if they don't, they become easier to define and solve once we're in the midst of a real project. I can't think of any scenario where we lose by starting as soon as possible, especially if the work is done by volunteers, and especially if we architect the project on the assumption that things will changes as we gain greater insight into the challenges we are facing.
Those who are interested in beginning work may contact me privately to receive access to a sandbox and task list.
Best,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
No problem. I'm glad to see
No problem. I'm glad to see progress made on this in any direction and wish you well in your endeavor. You may very well be right and I hope you can find people with the interest and time to commit to make that happen.
Agreed - Determine Needs First
I agree Josiah, that it would be best to just brainstorm about the needs of churches without letting any tools or solutions inhibit or lead us to certain conclusions.
To come up with this list I would recommend doing some "competitive analysis". Simply go to a bunch of church websites and see what they are doing.
That information will be very useful and get you most of the way there, but of course we have to keep in mind that maybe church websites are doing what they ought to be or could be doing...
-Brad
Directory
You should add an opt in extended directory, that allows opt in and segmented visibility. Each users should also be able to construct a landing page so others could get to know them.
So to define this out more.
So to define this out more. You're talking about 2 features. Please look over my summary of what I understood you to say and let me know if I have it. Others please also feel free to add stuff that you'd like to shoot for.
Extended Directory: Allow people to opt-in to be shown in the online version of the church directory. Permissions settings should be made available to the user permitting them to provide information to others based on the other users level of access to the site.
Landing Page: A page that would gather information about their activity on the site, their interests as listed in their profile and maybe information from various other place.
Some of the confusion here
Some of the confusion here is because even the original post is mixing up features and functions and solutions.
So I would say some of the big needs of a church website are:
A way of storing information about past and future sermons, including text, audio, and video files that might be hosted on the church site or elsewhere. An archive of previous sermons should contain those files and be filterable by date, preacher, and maybe scripture or text. It should include links to related information like quick links to the full text of scripture passages, related sermons (maybe by sermon series) and useful third party information.
A way of managing church events so they can be created easily by many people and viewed in various formats, including a calendar view. Allow people to sign up to attend events (or help out with them), easily add those events to their personal calendars, and customize event views so that you can filter down to see events for specific groups within the church as well as church-wide events, have a way to send out reminders to the people who are attending an event or to notify them if there are any changes in plans, and let attendees see who else is attending (with a way to contact other attendees to arrange things like carpools).
A way of organizing church groups: classes, choirs, prayer groups, lay leaders, and other groups. Each group should probably have some 'home' or landing page where they can see information specific to their group. Ideally there will be ways for group members to see and connect with other group members, and group leaders should have ways to communicate with all group members via email or posting notices on the group page. Groups may have files (text, images, audio, or video) that they want to store and display in galleries. Groups may have their own events, and the events might be on church property, or in members' homes. In the case of the latter, addresses, maps, and directions may be needed.
A place on the site for visitors that introduces the church and its history, mission, and philosophy. There should be easy ways for visitors to contact appropriate people in the church for more information and to learn about membership. The visitor information should include maps, directions, building layout, and anything else that would help a visitor get oriented.
A place on the site for people who need help, including contact information, links to prayer groups, and other ways to get assistance. There should be a prominent link on the home page to get them to this information. It would be nice to have automated ways to triage prayer requests and determine which should go only to a pastor and which can go out immediately to prayer chains.
A place on the site for mission information.
A place on the site for donations and fund raising.
A place on the site for administrative information.
As you can see I kind of ran out of steam at the end in coming up with complete descriptions of the kinds of things that might be needed, but you get the general idea. A well fleshed out list like this would be a great starting point (and these features are what I am using as a basis for the church site I'm working on now).
Yep, you're absolutely
Yep, you're absolutely right. I did confuse things in my original post. Sorry about that.
Thanks a bunch for your list and definitions. I think you've done some great defining of the problem and clarified things for me and my understanding of things. I hope others find it to be the same. At some point I plan to gather the points of this discussion and what you wrote looks very much like what I want to come up with.
internal or external focus
Thanks for taking the time to post this list. We are just starting to get organized in our effort to rebuild our website. Most of the items you mention also apply to us. One issue we are still struggling with is where does the line get drawn between features & functionality that are available to everyone without logging in and features & functionality that requires a login in order to access. What are your thoughts on this?
it's difficult
it is difficult to just list needs without running it through a filter of "howto", and then modifying those needs to fit what I already know how to do. You mention calendars and users having their own and I'm already thinking of the views filters to use along with maybe flags. I have the same trouble when designing a site, it's really important to define the site and then find solutions, not let the solutions design the site.
I would agree for the most part with your list Karen. And make them as easy as possible to admin and to set up. checkbox or dropdown functionality - "Always show map on event pages" / "Allow user to choose - default on" / etc. Make the layout clean and usable out of the box, however very theme-able.
I think the main goal of this should be usability. Most if not all features discussed here can be currently accomplished. The thing is that you have to know which modules to install, and how to use them together to accomplish a certain feature - and probably do some custom theming.
Calendar and Room/ Equipment Reservation
There is one need that most churches have and satisfy some way (often manually): the ability to schedule a meeting and reserve a room for that meeting. Some also have the need to reserve equipment. Ideally, this is integrated with a calendar so that a meeting or event can be placed on the calendar and also a room reserved at the same time.
BTW, I don't know of a Drupal solution for this. Wish I did, as I need it.
CCK, Date + small hook implementation does it
Create 3 node types: 'Meeting', 'Room', and 'Equipment'.
On the Meeting type, create two node reference fields: one that selects a Room, and another that selects Equipment.
On all types, create multi-value date fields.
Write a small module with hook_nodeapi('validate') to check when a Meeting node is submitted to ensure that the room and equipment do not already have overlapping dates. If not, add the date to the nodes.
Best,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Module list
Here's my current module list for developing church sites:
admin_menu
ajax
calendar
cck
cvs_deploy
date
dbscripts
devel
drush
drush_mm
email
fckeditor
feedapi
ffpc
filefield
flashnode
google_analytics
imageapi
imagecache
imagefield
imce
imceimage
imce_mkdir
itunes
link
messaging
nice_menus
notifications
og
pathauto
patterns
print
recaptcha
swftools
taxonomy_simplify
token
transliteration
views
webform
CiviCRM is absent because I'm waiting to see if the Ubercart Donations project makes UC a suitable replacement.
Feedback welcome.
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Module list example
Hi Matt - Thanks for the module list. Can you post an example site where you have all those modules in use so I can see it all "in action"!???
This does not use ALL of
This does not use ALL of them, but many of them:
http://www.bbcsantafe.org
This site was built on a volunteer basis, hence the lack of professional design, and you'll see some outstanding bugs very obviously on some pages, but it's been a nice real-world guinea pig for us.
Here's another site with better design and a few more features that I intend to compile into my church package:
http://www.orphanjusticemission.org
Best,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Warning message on bbcsantafe.org
You may want to take a look at the warning messages here:
warning: Invalid argument supplied for foreach() in /home4/mattchap/public_html/drupal-6.8/sites/all/modules/flashnode/flashnode.module on line 339.
No player is configured to play a series mixed media files. Check the SWF Tools file handling settings on the configuration page.
If nothing else, you may want to disable the warning messages being made public. ;0)
I tried with 3 different browsers, and I got these:
Browsers used = IE6, FF 3 Portable, Google Chrome Portable
Drupal Distribution for Churches Wiki discussion..
Further to this discussion, I have created a link to a WIKI where a more structured list of features can be defined, I hope this helps further develop the ideas on this list..
Russ
This is from my own current
This is from my own current struggles in learning drupal for a recently-migrated church site (www.centralpc.org), but here are some things that would be useful to me, and probably generally useful to other church sites.
a way to define sermon series, with a few fields of data about each series (title, abstract, anchor, link to artwork) and ability to easily assign a sermon to a particular series (or as standalone)... views that show sermons by series.
Includes pretty printing theme/option for sermon pages.
bonus for migration support that offers a way to bring in large numbers of static html sermons from an older site (though priority on the new stuff)
I've been reading and experimenting and don't have my own solution worked out yet, but I'll be glad to share details of whatever I come up with when it is stable and working. Mine will even have some built-in support for inclusion of sermon or series artwork, since we're lucky enough to have some very creative artists doing the slide backgrounds for us. ;-)
Anyway, things to consider for this drupal for churches idea...
(recommendations to me would certainly be welcomed in the meantime, though any probably shouldn't be in this thread)
thanks,
jeff wilkinson