Heal Your Church WebSite

For what will it profit a man if his church website is the slickest in the Internet if he has to forfeit a month’s collections just to change the welcome message?

If you haven’t guessed by the play on Matthew 16:26 (&/or Mark 8:36, &/or Luke 9:25), or the somewhat wordy “bad church web design poster #006,” the topic of today’s “sermonette” is website maintenance.

You see, there’s a dirty little secret that professional web developers such as Tim Bednar, Mike Boyink, and myself have known for years:

Creating and designing websites is alluring and hi-profile work - whereas maintaining code and a consistent stream of compelling content is difficult and is about as glamorous as the janitor who keeps the church toilets clean.

A point made all the more sharper, like a pointy stick in the eye sharper, when you fall into the trap of having that college kid studying home on spring break create for a really super-click Flash-based church website that everyone - and only - those in his age group and demographic can ‘really appreciate.’

Then the train wreck occurs sometime in early October when said student is back at art school and your poor church Secretary has to post updates from those in the field on summer mission programs.

Sound Familiar?

If not, just give it time. Since 2002 when I started out on my crusade to teach, rebuke correct & train others in righteous web design I’ve seen literally hundreds - perhaps thousands - of church websites that went down this path to obscurity and frustration.

And this is why we find churches equipped with data-driven content management systems, or at least driven-by a reasonable blogging system, providing pages with excellent search engine rankings and the visitors and conversion rates to show for it.

Sound Good?

Okay, so if I’ve sold you on the concept that maintenance is the key to a successful online ministry, then perhaps then I can also convince you and/or your church to engage in the following processes to keep it going for years and years even though your resources are tight and your time tighter:

• Establish a web ministry team comprised of the following mix of talents:
  • a member of the church staff
  • a software developer type
  • a hardware geek
  • a graphic artist type
  • a word-smith
  • a marketeer
• Consider employing a content management &/or a logging service to render your church website such as:
  • TypePad,
  • Blogger,
  • WordPress,
  • Drupal,
  • Church Community Builder,
  • E-Zekiel,
  • Fellowship Technologies,
  • For Ministry,
  • MercyTree,
  • SiteStrux;
• Engage in a formalized design process before writing a single line of HTML/code that includes:
  • reviewing what’s out there
  • understanding your neighborhood
  • setting attainable goals and objectives
  • establishing minimum requirements
  • defining an informational architecture
  • creating a project plan
• Execute a development plan that includes the following steps:
  • designing a prototype
  • soliciting user feedback
  • building the system
  • testing functionality
  • testing use cases
  • testing loads and bandwidth
• Follow-up with a maintenance plan that includes:
  • user education
  • staff training
  • analysis of web analytics
  • data & system backups
  • disaster recovery drills
  • security audits
  • error-log reviews
  • checks of search engine ranking
  • software upgrades
• Security ongoing success with:
  • rotating in/out new members to your committee;
  • occasionally testing new applications and technologies;
  • periodically soliciting feedback from seekers and church members;
  • make sure there’s a line item in the church budget for the website.

Sound Too Hard?

Now if you’re panicking a bit over some of the items above - don’t sweat it. If you’ve took my advice to create a team that includes both a hardware and software geek, you’re good to go on those issues like “use-case testing” or “disaster recovery drills.”

And if you’re too small to do the above - again, don’t sweat it - simply figure out what you can do from the above list with what you’ve got, never forgetting that putting up a website is easy - it’s the maintenance that’s a killer.

For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it? Otherwise, when he has laid a foundation and is not able to finish, all who see it begin to mock him, saying, ‘This man began to build and was not able to finish.’ Or what king, going out to encounter another king in war, will not sit down first and deliberate whether he is able with ten thousand to meet him who comes against him with twenty thousand? And if not, while the other is yet a great way off, he sends a delegation and asks for terms of peace. So therefore, any one of you who does not renounce all that he has cannot be my disciple. - Luke 14:28-33

(psst: oh yeah, in case you didn’t figure it out, you click on the small image of the poster above to get to the really-big version you can print out and nail to the door of your church)

Multiple column, table-less layouts using CSS isn’t so hard the CSS Grids Builder tool provided as part of the Yahoo! User Interface (YUI) library. Just enter the number of columns, the widths and positions, and presto - a very small XHTML footprint driven by some rather clever formatting wrapped-up into a nicely compressed cascading style sheets is your for the taking … free!

Even though I encourage church webmaster to leverage existing blogging system, content management tools, and such to create and maintain their church websites - from time to time, some of us need to create a page from scratch. And in the past, when it came to creating stuff like 3 column tableless layouts, well let’s just say that not everyone’s browser worked and played well with even the most careful design.

And while the blame rests clearly on broken browsers, the responsibility invariably lands on the shoulders of the web developer. For example, in the past I’d use the most excellent online ‘CSS Layout Generator‘ tool. However one need only look at the generated code to see the numbers of hacks, quirks and work-arounds required to see why not ever user experience was the same.

However yesterday, quite by accident - or perhaps should I say by ‘gAccident,‘ yesterday I stumbled upon Jeremy Zawodny’s review of the YUI CSS Grids Builder; and this free, online tool’s uniquely different, but effective approach to table-less mutli-column layouts.

As best I can tell from my experiments and the generated CSS, it appears to that the YUI approach is one in which all browser differences are nuked, or should I say ‘Reset‘ using CSS to remove and neutralize the inconsistent default styling of HTML elements — creating a level playing field across various brands of browsers.

In other words, no more having to “clear floats” through any variety of methods, no more ‘bodges’ to work around annoying issues such as dealing with the max-width in Internet Explorer 6, or imposing minimum widths with CSS in FireFox, max-width in Internet Explorer and so on. Instead, by leveraging the YUI CSS Framework one can dispense with many CSS tricks you may, or may not know.

Instead, one needs only to enjoy the YUI Grids CSS offering of four preset page widths, six preset templates, and the ability to stack and nest subdivided regions of two, three, or four columns - the 4kb file provides over 1000 page layout combinations; including:

• Supports fluid-width (100%) layouts as well as preset fixed-width layouts at 750px, 950px, and 974px, and the ability to easily customize to any number.
• Supports easy customization of the width for fixed-width layouts.
• Flexible in response to user initiated font-size adjustments.
• Template columns are source-order independent, so you can put your most important content first in the markup layer for improved accessibility and search engine optimization (SEO).
• Self-clearing footer. No matter which column is longer, the footer stays at the bottom.
• Layouts less than 100% are automatically centered.

I know this to be true because I gave a slightly modified version of the YUI generated CSS on multiple browsers both at my work — and using the cool, free, online multi-browser test tool offered over at Browsershots.com!

The only questions I have left to ask now are:

1. How permanent is their BSD licensing? Meaning, will my church and/or charity get in trouble using this?
2. As I examine the YUI, I have to ask, what’s in it for Yahoo! to provide all this free of charge? Or will I have to eventually run ads?
3. How poorly will the upcoming release of IE8 mangle this approach?

Other than these three issues, I for one can’t see any reason not making the Yahoo! User Interface (YUI) library a pivitol piece of anyone’s “CSS Survival Kit.”

What is it with fundamental, KJV only, pre-millennial, independent Baptist churches and web design that wants to party like it’s 1999? Case in point, the website for the Faith Baptist Church of Dayton Ohio.

I’ve said this a couple times before, if a congregation desires to follow and worship God with such strictness where only a single interpretation of the original Hebrew and Greek - that’s fine. I’m no likelier to get bent out of shape over this issue as I am over the debate whether Manischewitz® matzos make for a more Biblical communion experience than Saltines® - this and other issues well covered by Paul in 1 Corinthians 10.

What does confound me is how people whom love the law in just about every other area of their lives, practice web design as if no governing standard and/or practices exist; such as the W3C. Especially in a day and age when so many inexpensive and/or free web standards-based publishing systems exist.

I just don’t get it.

What I do get is that today’s example proves once again that FrontPage doesn’t kill web sites, but that people with FrontPage kill websites. Especially people who borrow designs from “Greg and Violet Preston BBFI Missionaries here in Panama” - whose sending church is some other church than FBC of Dayton - though I find no credit given to either.

All this in mind, here are 5 things I’ve visually annotated, and would change about the Faith Baptist Church of Dayton Ohio website:

1. Lose the annoying animated GIF banners. Usability guru Jakob Nielsen sums up why this is such a bad practice:
   

   Some links to applications use animated words in an attempt to appear even more attractive and promote the application’s various benefits. This technique backfires even more, because users firmly believe that anything containing moving or blinking words is bound to be a useless advertisement. This belief is typically true, and saves users much time once they’ve developed the ability to ignore moving text. - “Nielsen: Ephemeral Web-Based Applications“

2. Stop using graphics to represent, render and/or otherwise display text. Search engines cannot index them, and in the case of today’s example, when poorly rendered with grainy backgrounds and/or inconsistent type faces, humans have difficulty reading them as well.
3. Image Bloat, in this case best represented by the the image of the church on the home page that suffers a malady described by Father Flanders in his now famous sermon for Sunday, July 13, 2003:
   

   Just because Jesus miraculously turned water into wine doesn’t mean he can miraculously turn your 1280- x 1024-pixel image whose file size is 1.8Mb into an image whose file size is only 74Kb just because you changed the WIDTH= and HEIGHT= attributes to WIDTH=”420″ and HEIGHT=”336″.

   In other words, if you’re going to put an image of a lifeless brick building on your church’s homepage - at least run it through the free and easy to use image optimization program IrfanView.

4. It no longer takes alchemy or rocket science to ‘embed Google Maps on your church website‘ … as the Web now offers any number of online programs that make it ‘easier way to integrate Google Maps into your church website.’ Use them to create a separate “Directions” page that not only contains all the essential info for getting to the church - but can be printed out onto a single piece of paper that people can use on the driver there.
5. Enough with FrontPage. The product is dead, it only inspires crufty, web-standards and search engine hostile designs and limits updates to the one or two persons who own the software application license. Instead, consider employing a content management &/or a blogging service to render your church website such as:
   • TypePad,
   • Blogger,
   • WordPress,
   • Drupal,
   • Church Community Builder,
   • E-Zekiel,
   • Fellowship Technologies,
   • For Ministry,
   • MercyTree,
   • SiteStrux;

   If nothing else, most if not all of the above tools would help generate a more readable and manageable set of menu navigation items than is currently offered.

There is actually much more we could point out here, but the purpose here isn’t to excoriate the good people of the Faith Baptist Church of Dayton Ohio, but rather to point out that they need to carefully reconsider they message they are currently sending with their current web design - along with considering the cost to render it using the arcane tools and metaphors it currently portends.

Similarly, if you can point out - in instructive love - other items we can all consider, then leave a comment.

Though still under development, the upcoming release of WordPress 2.5 is already receiving some very positive reviews. One in particular I’d like to share with you from a church-blogging perspective is entitled ‘10 Things You Need to Know About WordPress 2.5′ by Aaron Brazell at TechSailor; who asserts that “this is a huge release.” Here are 10 reasons why I agree.

It never ceases to amaze me how as a Body of individuals whom collectively and voluntarily ascribe just about every other aspect of our lives to a set of well-defined tenants and standards, that we are so hard-headed when it comes to the methods we use to present our online ministries along the same lines. Case in point: BibleJim.com.

Below are steps describing how I used Knoppix Linux to fix the dreaded Windows XP ‘Error Message: Stop c000021a {Fatal System Error} The Session Manager Initialization System Process…’ failure.

I find too many church websites putting their best information out of reach. Hence the idea driving today’s bad church web design poster is best sung to the tune of Nat King Cole’s classic, “Unforgettable” followed by my usual pithy enumeration of this pesky issue:

So once again, that infernal Daylight saving time thingie bothers us by automatically setting, or perhaps not setting our system clocks on your Ubuntu, Red Hat, Fedora, Debian, Knoppix, or Suse install either an hour ahead, or remaining an hour late!

Microsoft Office doesn’t just cost you $139 per user, it also costs you in money and man-hours required to manage keeping the various products up-to-date, secured, and backed-up on computer hardware that often requires additional disk and/or RAM with each iteration of Office and/or the Windows operating system. Why bother with all that hassle when Google now provides the education edition of Google Aps to non-profits with current 501(c)(3) status in the U.S.?

I feel like a little boy yelling down the street to announce the arrival of the circus. “They’re here! They’re Here! They’re HERE!” Yes folks, the JotSpot WIKI technology that Google acquired back in October of 2006 is now a service available via Google Aps - a service entitled “Google Sites.”

A service that I as soon as it appeared on my aggregator, I added to HealYourChurchWebSite.com - taking screen shots and notes so you too can add Google Sites’ WIKI-like capabilities to your church and/or charity website.

Here are 5 comments from visitors that I think are worth restating in a post as they each address larger issues facing many of us who design, develop, deploy and maintain church and/or charity websites. The format will be a brief on what the original article stated, and then snippets of what the commenter contributed; so in no particular order:

Using a blog to manage a website’s content is a flexible and affordable solution more and more churches are employing to effectively present their message online. There is however one drawback – in that some of the open source blogging solutions used as content management on the cheap also tend to attract attention from nere-do-wells who attack the comment and content functions of application such as WordPress and MovableType with robotic floods of advertisements offering anything from enlarging various appendages to curing male baldness all while losing your life’s saving playing poker online.