If it looks like a duck, swims like a duck and quacks like a duck, then it probably is a duck.

Which is why I find myself  a little bit confused when stumbled onto the  ‘Jesus Christ Celebriduck Limited Edition Collectible Rubber Duck‘ parodied in the instructional poster below:

Call me old school but as I recall a rubber ducky is, as Ernie of Sesame Street so aptly described in song a “ .. little fella who’s Cute and yellow and chubby …”

Now I know what some of you are thinking “Dean, you dope, the Celebriduck is a collector item thing … of course it doesn’t look like a duck!” …

… kidding aside, I already figured out it’s some niche merchandise marketed who also speak other arcane dialects such as “Beanie Baby” … but that gets to my point!

Using insider jargon-eze is a sure fire way to relegate your website the non-desirable’ SEO’ known as ‘search-engine obscurity.‘

Consider this:  in the U.S. 1 in 3 adults is unchurched. Meaning 1 in 3 adults don’t understand the ‘church-speak‘ that bables-up and out of expensive color brochures, sermon videos and web sites.

So when it comes to the purpose and personality of your organization, speak clearly and say it plain. Tell visitors precisely what THEY seek in terms THEY understand.

Put another way, by avoiding ‘clique chat‘  you’ll not only make your site more usable to individuals trying to find what you have to offer, but you’ll also help avoid spending $5k on a Search Engine Optimization (SEO) expert.

What usability issue? Well if I’m a user sitting across the room at 11:23, and possibly at 4:55 and 8:05, I might find it hard to see what time it is because of the dark black lines of the artwork create a dark black background for the thin black arms of the clock.

So what has this got to do with my church or charity website? Glad you asked.

What we want to take away from today’s example is the concept that part of a successful user interface isn’t just design that looks good (not that I find the clock artwork all that inspiring) — but also a design facilitates a positive and productive user experience.

This can be measured in ‘conversion rates,’ that is the rate at which the user successfully uses the website (or clock) to accomplish some item of work or information gathering.

This means we need to avoid design elements get in the way of a web page’s core functionality, otherwise we’re left with the antithesis of conversion – the user abandons the product – often quantified as the ‘bounce rate.‘

To help avoid this common pitfall, I offer this “fast five” lists of things to remember when designing a webpage:

1. You are not your user;
2. solve their problems, don’t burden them yours;
3. don’t assume all any of your users are idiots;
4. engage in user testing – where non-geeks attempt simple, common tasks; and
5. when a problem and/or encumbrance by a user is reported – do what it takes to provide the user a clear path to operational/work-flow success.

On that last point, think Amazon.com, the premier example of conversion goals in action. When they hear of something that gets in the user’s way – even if it sounds stupid – they fix their site to accommodate the customer.

I’d recommend doing the same, perhaps starting with some good-old-fashioned hallway testing and moving out from there.

And while the product parodied above is applied a slightly different meaning of “fail” the point is hardware failures, power outages, software bugs, stolen computers, cross site scripted SQL injections, and/or zombie induced denial of service attacks can all turn your church and/or charity website into a tub of techno-mush quicker than you can recurse a binary tree.

The only real defense against such failures is to plan for them – anticipating them in three ways:

• backing up your data
• moving your backed-up data off site
• having and practicing how to restore backed-up data

Here’s a very simple snippet from an oldie but goldie article entitled “How to backup your MySQL tables and data every night using a bash script and cron:“

#!/bin/sh
# backup data
mysqldump -uroot -ppwd --opt db1 > /sqldata/db1.sql
mysqldump -uroot -ppwd --opt db2 > /sqldata/db2.sql
# zip up data
cd /sqldata/ 
tar -zcvf sqldata.tgz *.sql
# email data off-site
cd /scripts/
perl emailsql.cgi

The article also displays a script on how to email the data off site, not a bad deal if your data is small – such backups being just as simple to restore with this dynamic command line duo of directives:

tar -zxvf sqldata.tgz
mysql -uroot -ppwd db1 < db1.sql

Things get trickier when you have tons of data, in which it may play into one’s restoration plan better to backup and restore a database by individual tables. Here is a set of articles that describes how to do this that includes some script examples you can modify to suite your needs:

• MySQL: How do I dump all tables in a database into separate files?
• MySQL: How do I import individual table dump files in to MySQL using shell script?

Either way, then it is just a manner of putting the shell script on a timer, or in the vernacular of crontab:

1 3 * * * /usr/home/mysite.com/prvt/tbak.sh > /usr/home/logs/tbak.log

If either of these shell script, bash-based approach seems to complex then perhaps one of the control panel, web-based method offered by UpStartBlogger’s post “8 MySQL Backup Strategies for WordPress Bloggers (And Others)” will do the trick.

Here are some other related articles that might help, the last two include automagic date stamping of the backup files:

• MDLog:/sysadmin – Backup your MySQL databases automatically with AutoMySQLBackup
• Automatic MySql Backup Script – Dagon Design
• Justin-Cook – Automatic cPanel backup (domain & MySQL) with cron & PHP
• Simple MySQL Backup – Holy Smoly
• DreamHost Forum – Crontab/backup

The bottom line is this: just Peter implores us to make a ready defense in 1 Peter 3:15, so I’m asking you always be ready to make a defense to anything that endangers the data that is on your system so you’re not found tearfully dissheveled cowering in a corner meek and fearful, mumbling something about how you should have planned for such failures.

You’ll be glad you did – probably at the most inopportune time possible.

Unlike the 5.5″ The Kneeling Santa Claus Musical Christmas Water Globe parodies above, there are some real threats to your website that are an unfortunate aspect of the “World Wide” nature of the Web.

Specifically, I’m talking about the army of professional hackers employed in far flung regions such as China, Nigeria and of course what is now the former U.S.S.R.

For that, I recommend a modification to your  .htaccess file such as:

<Limit GET HEAD POST>
deny from 218.25.161
allow from all
</LIMIT>

If you look close, I’m only using 3 levels of the IP address to 218.25.161.0 through 218.25.161.255.

And where does one get a block of  IPs to block? Glad you asked …

Pre-fabricated blacklists to block IP addresses of entire countries:

• WizCraft – Server .htaccess Blocklists for exploited servers (e.g. Russia and China)
• Block a country.com – block by ip address, block access by country

A bit more on .htaccess and mod_access:

• Apache Project: Module mod_access (v. 1.3) – allow
• ClockWatchers.com – .htaccess Tutorial how to block an IP address

Just remember to keep good backups of whatever files you’re working on – and try not to lock yourself out while experimenting with changes!

So how do we avoid the type of ‘accidental-message-myopia‘ that produces a design that includes a not-so Middle-East,  blond haired (and possibly blue-eyed)  baby Jesus?  Two words “Hallway Testing.”

The Wikipedia describes hallway testing as:

Hallway testing (or hallway usability testing) is a specific methodology of software usability testing. Rather than using an in-house, trained group of testers, just five to six random people, indicative of a cross-section of end users, are brought in to test the software (be it an application, web site, etc.); the name of the technique refers to the fact that the testers should be random people who pass by in the hallway. The theory, as adopted from Jakob Nielsen’s research, is that 95% of usability problems can be discovered using this technique.

In short, hallway testing is the simple act of accosting … I mean drafting … I mean enlisting 5 or 6 random individuals to inspect your designs to insure among other things, you’re not overlooking some detail great or small that accidentally sends the wrong message.

I know it’s an extra step in the web design process, but when one considers alternatives as the above parody poster depiction, it’s probably worth it.

• Main Entry: Feature Creep
• Pronunciation: \ˈfē-chər ˈkrēp\
• Function: intransitive verb
• Etymology: Middle English feture crepen, from the act of over-building something
• Date: July 24, 2009

Remember folks, flee from temptation to ‘gizmo’ up your site.

The misguided notion that somehow more is always better.

Instead, focus on workflow – that is the things your users want/need to do/learn from visiting your website.

WHOOOOSH – flame on!

I should know, as I’ve been engaged in mental combat with these forces of evil web design idioms since the turn of the new Millennium, first in collaborating with Vincent Flanders on his second book, an act which lead to the eventually May 2002 establishment of Heal Your Church Website.

But enough of my credentials, lest I start this post start sounding like a Pauline epistle, though I should probably mention that I do the software as a service thing for a living … but that’s plenty about me, as others equally qualified have since dashed headlong into the breach.

This would include Cory Miller and James Dalman at Church Communications Pro (CCP), the latter of whom begged the all important question: “Is Church marketing dead?” Specifically, pondering aloud:

“There is something going on but I quite can’t put my finger on it. It’s a gut feeling that’s right more often than not. I think the church landscape is drastically changing and that church as we know it now is going to evolve (no, I am not supporting Darwin) into something much different. It’s just a hypothesis or idea I’m working on, whatever that’s worth.”

To which my response is: “James, let me save you a few steps. Church marketing isn’t dead, it’s just stuck on stupid!”

If that weren’t the case, why would sites and services such as CCP, Church Marketing Sucks, For God’s Sake Shut Up, and a handful of others continue to, and with apologies to Vincent Flanders, offer weekly lessons in good church marketing by looking at examples of bad church marketing?

I mean, how many examples of church websites adorned with the cliché gold lamé animated gif of a spinning cross that screams “everything I know about website design I learned from Strong Bad!“ do we need to ‘Fisk‘ to make our point?

Or on a more serious note, how many of us seen all to many unique local churches dive through the porpoise-driven hoops of Warren-ology just to become different like everyone else?

And that’s really my point, it’s not that church marketing is dead, it is that we’re stuck on driving down the wide and easy path to church marketing, rather than seek out a difficult path that includes:

• Studying Scripture to see where marketing and evangelism intersect;
• Teaching lay staff and church on what real marketing is and how it works;
• Understanding that the Church didn’t start in 2000, but rather 2000 years ago;
• Putting aside the need to agree 100% with everyone 100% of the time;
• Initiating marketing teams as opposed the message controlled at a single point;
• Daring to be different without amputating one’s self from the Body.

Look, we have centuries of beautiful sacred songs, art and literature as the result of the artistry that was once the Church’s … why can’t we have the same for church marketing in the 21st century?”

Or put another way, Franky Schaeffer was right when he asserted that Christians are no longer influencing society through various forms of media, but are instead influenced BY it. A neat trick when you think Francis Shaeffer’s son warned us about this as far back as 1981!

WHOOOOSH – flame off!

Oh, and before I forget, to my Eastern Orthodox friends … a belated Χριστός Ανέστη!

Check out these recent tales of real-life virtual horror as told by a variety of news sources from around the globe:

• The outgoing Italian government posted the entire population’s tax returns on the internet causing a mad scramble which crashed the system.
• Obama supporters were in for a surprise Monday when an attacker executed code on Barack Obama’s Presidential campaign Website that redirected users to Democratic rival Hillary Clinton’s campaign site.
• According to police reports, a computer was stolen from the ADT Home Security branch on Sunbeam Center Drive sometime between April 12th and April 13th.
• Tens of thousands of people were feeling short changed last night after a massive system failure wiped out all the Northern Bank’s ATMs.
• A statewide computer problem again hobbled the state’s digital driver license system on Friday.

The point is, hardware failures, power outages, software bugs, stolen computers, cross site scripted SQL injections, and/or zombie induced denial of service attacks can all turn your church and/or charity website into a tub of techno-mush quicker than you can recurse a binary tree.

The only real defense against such failures is to plan for them – anticipating them in three ways:

• backing up your data
• moving your backed-up data off site
• having and practicing how to restore backed-up data

Here’s a very simple snippet from an oldie but goldie article entitled “How to backup your MySQL tables and data every night using a bash script and cron:”

#!/bin/sh
# backup data
mysqldump -uroot -ppwd --opt db1 > /sqldata/db1.sql
mysqldump -uroot -ppwd --opt db2 > /sqldata/db2.sql
# zip up data
cd /sqldata/ 
tar -zcvf sqldata.tgz *.sql
# email data off-site
cd /scripts/
perl emailsql.cgi

The article also displays a script on how to email the data off site, not a bad deal if your data is small – such backups being just as simple to restore with this dynamic command line duo of directives:

tar -zxvf sqldata.tgz
mysql -uroot -ppwd db1 < db1.sql

Things get trickier when you have tons of data, in which it may play into one’s restoration plan better to backup and restore a database by individual tables. Here is a set of articles that describes how to do this that includes some script examples you can modify to suite your needs:

• MySQL: How do I dump all tables in a database into separate files?
• MySQL: How do I import individual table dump files in to MySQL using shell script?

Either way, then it is just a manner of putting the shell script on a timer, or in the vernacular of crontab:

1 3 * * * /usr/home/mysite.com/prvt/tbak.sh > /usr/home/logs/tbak.log

If either of these shell script, bash-based approach seems to complex then perhaps one of the control panel, web-based method offered by UpStartBlogger’s post “8 MySQL Backup Strategies for WordPress Bloggers (And Others)” will do the trick.

Here are some other related articles that might help, the last two include automagic date stamping of the backup files:

• MDLog:/sysadmin – Backup your MySQL databases automatically with AutoMySQLBackup
• Automatic MySql Backup Script – Dagon Design
• Justin-Cook – Automatic cPanel backup (domain & MySQL) with cron & PHP
• Simple MySQL Backup – Holy Smoly
• DreamHost Forum – Crontab/backup

The bottom line is this: just Peter implores us to make a ready defense in 1 Peter 3:15, so I’m asking you always be ready to make a defense to anything that endangers the data that is on your system so you’re not found tearfully dissheveled cowering in a corner meek and fearful, mumbling something about how you should have planned for such failures.

You’ll be glad you did – probably at the most inopportune time possible.

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)

Inaccessible, that’s what you are
Inaccessible so near, yet so far
Like a hy-per-link that eludes me
How the four-o-four page so annoys me
Never before has one suffered more

Inaccessible in many ways
And forever more, that’s how it stays
That’s why, ad-min, it’s incredible
That something so intolerable
Thinks that I am intolerable too

<instrumental interlude>
No never before
has one suffered more ooh

Pretty corny? Sure! Pretty common, absolutely. In fact, when it comes to accessibility and church websites – I think the out-of-reach bag of chips pictured in the poster photograph sum up the frustration often felt by many seekers who visit church websites, only to loose their cents and their sanity selecting options that take them nowhere.

In other words, though most talks of web accessibility are often limited to those topics covered in Mark Pilgrim’s seminal “Dive Into Accessibility” — I would like to expand the conversation today a number of examples where I find church webmasters needlessly impairing their users in the following ways:

• Bed and breakfast markup
• Employing browser-specific navigation
• Charging a fee to read sermons and/or Bible studies
• Not thinking through the information architecture of the website
• Displaying Flash content with no browser detection and alternative content

Bread and BReakfast!

‘B and BReakfast markup’ is a handy mnemonic mechanism to memorize how not to semantically collude your online sermons and studies with misused taggery such as < b > and < br >.

There’s enough existing (x)HTML taggery out there to make your markup match the meaning of your message. Trust me, you’ll thank me for this when you eventually publish a book and/or study guide based on your blogged sermons.

I write about this in some detail though recent improvements in better-written blogging and CMS applications are making this less and less an issue over time.

Browser-Specific Navigation

Here I’m describing those instances where someone employs something like those nifty cool slide-in, drop-down, tree-expanding menus that only work on Microsoft Internet Explorer.

Or just as evil, uses a DuHtml menu whose sub-choices require the lightening fast reflexes of an over-caffeinated super-hero to click before they disappear.

Charging for Sermons

I had actually received an email on the topic – but lost the link (bad dean, bad!). None-the-less, my point is, sermons, Bible studies and other such “opium content” are critical elements that those shopping for churches online use togauge whether or not they’re going to visit a particular church on Sunday.

More on this in my post “Is your church website little more than brochureware?”

Information Architecture

Also known as your informational hierarchy, your navigational hierarchy, your navigation tree and/or your site map.

This rose by whatever name needs to be well organized enough for the average Joe or Jane to figure out.

Yes, it means putting down the mouse and thinking first then coding – but it is well worth it as categorizing information enhances church website conversion goals.

Flashination

About the only thing more annoying to me than the spinning .gifs of gold lamé crosses on KJV only churches, are Flash-based church websites – or heavy Flash use church websites – that provide no alternative content for those who have not installed the latest and greatest Flash reader plug-in; and/or just don’t view Flash due to restrictions of work, bandwidth and/or physical disability.

I write on this over-used and/or poorly implemented media all too often here to cite a singular article.

Betcha can’t eat just one

Bottom line is, having inaccessible content is about as frustrating as offering a person a single Lay’s potato chip – whereas making things easy to reach and read is like providing them a sumptuous feast of data that will keep them coming back for more.

The choice is yours.