Train-ee | Learn Expression Engine Fast

01 - Why ExpressionEngine for a Church Site?

Before getting into the “rubber hits the road” details of implementing a church site on ExpressionEngine, I thought it might make sense to talk about the “business case” for using EE for this purpose and how it stacks up against a Dreamweaver/FrontPage approach, an open source CMS approach, and an Application Service Provider approach.

 

If nothing else, building a website is certainly a project that offers choices.  Vast numbers of choices.  Do you rent (use an Application Service Provider) or buy (create a custom site)?  What should the architecture be?  What color scheme should it use?  Where should you host the site?  Who should maintain it?  Add a hundred more questions to that list and you could still just be getting started on a design or redesign project.

I really don’t envy people new to the web development world - the sheer number of choices in getting a site published must be overwhelming.

Churches typically have their own circumstances that make the web design and development process even more confounding:

• Ownership/final responsibility for the site is often unclear.
• Content ownership is often split across multiple departments and people.
• Content owners are often volunteers.
• Technical staff responsible for designing/implementing the site are also often volunteers.
• Those volunteers often don’t have office space at the church, or access to the church network.
• Those volunteers often have a high burn-out rate, which means a constant stream of turnover.
• Churches often have a hard time funding development for a professional website.
• The traditional power/authority model of church leadership runs at odds to the level playing field of the Internet.
• Churches usually have more content types to publish than the typical small business (events, podcasts, etc).

And there are more, of course - but you get the idea. 

However - I think the combination of ExpressionEngine along with either a custom-designed site or commercial template is a great solution for many churches, solving a number of those issues as much as they can from a technical perspective.

So - let’s pit EE against some other options for a church site and see how it stacks up.

First - a disclaimer:  I work on a part time basis for EllisLab, the company that publishes ExpressionEngine.  The views below, however, are the reason I took the job, and not vice/versa and if the job ended today I’d stand behind these views and continue to use EE in my work.

OK..on with it then…

ExpressionEngine vs. Dreamweaver/Contribute or FrontPage
This argument really doesn’t come up much anymore, but then again I just ran across some of these types of sites yesterday while looking for an evening Easter service to attend.

At a high level - the Dreamweaver/Frontpage site is “static”—you create web pages and save them to the web server much as you would a Word document.  The Contribute client for Dreamweaver then allows you to establish editable regions on those pages, and assign people to be able to change them - after installing the Contribute client on their computer.

This is still a workable way of doing a website, and can—with the right design and guidance - produce a usable site. However, it’s just not the most ideal way anymore.  ExpressionEngine along with other Content Management Systems (CMS) pull pages together in what’s called a “dynamic” way.  The content of the page is stored in a database, and the CMS stores a template.  When a page is requested the web server mashes the two together and spits out a web page.

The benefits are legion, here are some of the big ‘uns:

• The CMS is installed once on the web server - which means you don’t have to install software each time a new volunteer takes over your children’s ministry.
• The CMS allows the site to be updated from any device with an internet connection and web browser - including your youth pastor’s iPhone from the mission trip in Romania.
• The CMS allows content to be entered once and used in many places on the site - enter the data for a marriage retreat once and it shows on the home page and on the Adults page .
• The CMS allows more dynamic features on the site - pastor weblogs, visitor comments, photo galleries for your pig roast or Easter Pageant, etc.
• The CMS keeps content separate from the code/graphics that handle the design aspect of your site - making it much harder for your “less than technical” staff to “break” the site while editing content.

ExpressionEngine vs. Open Source Software
So—you’ve looked around at different CMS’s and have found that there are also some open source versions, which are free to download and use.  Hey - churches are often on tight budgets so why not go this route?

Now - realize that in the tech world the debate over commercial vs. open source is often similar to a religious debate.  Some people like the fact that open source software is community developed, with no corporation profiting, while others are more comfortable with commercial software with paid tech support.

I fall firmly in the second camp.  As a business owner who develops websites for churches and other companies, I’m just more comfortable putting clients on a ExpressionEngine site, knowing that if there are issues I can get technical support for them.  And that ultimately there are people who’s livelihood depends on this software working as it should.

This can be especially important for churches in light of how often volunteers turn over.  When your open-source loving web guy decides he needs to spend more time with his new baby or moves on to a new church, how easy is your site going to be to transition to a new person?  Having paid tech support for that next person coming on might help save your church from the “new techie volunteer means a whole new site” problem I see so often.

Next?  Security.  ExpressionEngine just flat-out has a better track record than the open source alternatives when it comes to keeping your site secure. In its four-year history, EE has only had two updates to fix a security-related issue (just make sure to choose a good webhost as placing EE in a non-secure environment can still lead to your site getting hacked.  Basic moral - don’t choose the cheapest host).

ExpressionEngine vs. an ASP
In the church website world, there are a number of Application Service Providers (ASP) who specialize in church websites.  Go ahead - just run a Google search on “church website” and explore the results, especially the sponsored links.

Some of these providers are actually a pretty good deal—and if you are completely new to building websites or this is a site for completely new church, spend some serious time looking at them.

However - know that from a technical/implementation/coding perspective some of those options have, in the past, been pretty bad.  Articles like this one on Sonspring.com took them to task for spitting out poor code.  That was a couple of years ago, though, and I know that some of them have improved their offerings from a code-quality and usability/accessibility perspective.

Also keep an eye on the pricing schemes.  While $50/month might sound good to get started, two years down the road you’ll have $1200 invested - and that’s assuming you didn’t also pay a one-time setup fee.

Depending on how the ASP prices themselves, ExpressionEngine may or may not be a clear winner from a pricing perspective. While the EE non-profit license is currently $100 and design templates can be found for under that, most of the time/cost in getting an EE site live is the EE implementation, and depending on how complex your site requirements are the ASP approach might be a cheaper way to go.

Or - buy EE, a design template, and follow along with this series…;)

Where EE can be preferable to the ASP model is in terms of design - not locking you into a pre-built set of template libraries to choose from. 

Functionality-wise it’s probably about a wash - the ASPs tend to have developed many features specific to churches that EE won’t have by default (like tracking registrants for an event, for an example).

However if you need something not offered by the ASP it might be more difficult to get from the ASP than on an EE-based site.  EE is by nature a very flexible/extensible web publishing platform, and there is also an active community of 3rd party designers and developers both familiar with EE and publishing add-ons to extend its out of the box functionality.

Another thing to explore with the ASP is what happens to your content if you decide to move away from them - say they worked fine for when your church was new, but after two years you need a more complex/custom site.  Can you get your data from them in some fashion that you’ll be able to import into a new system?

Wrap-up
OK - this article on the EE for a church website is by no means exhaustive.  EE certainly isn’t the perfect solution for every church site.  But - it’s a pretty killer solution on a number of levels.

A church site built on ExpressionEngine solution:

• Allows unlimited number of people to maintain the content.
• Can be configured to have content changes approved by a content manager.
• Has no “Seat-based” or “user-based” licensing to keep track of.
• Includes paid tech support for your current web developer, and the next one.
• Has lots of features to help create a dynamic, easily-updateable site.
• Doesn’t get in the way of a designer wanting to create a unique custom design for your church.
• Doesn’t get in the way of a coder wanting to code a standards-based site for your church.
• Can be configured to deliver all the content types a church needs to deliver - pastor blogs, sermon podcasts, event calendars, photo galleries, etc.
• Can be hosted with a large variety of web-hosts, so you aren’t locked into the pricing whims of an ASP.
• Can be moved from one host to another in a straight-forward manner.
• Is paid for once developed.  The only required recurring costs are your monthly hosting.

Not a bad list - and if it speaks to you and your church website, stay tuned.  I have a bit of back-end prep work to get done yet but in the next installment I’ll lay out some design requirements, talk about the “custom design vs. template” argument, and I’ll choose a template for the project.

 

 

 

 

Category Navigation

<< Previous Entry   

Next Entry >>

 

Previous Comments

Add Your Comment

Commenting is not available in this channel entry.