Spring Cleaning, or time for a HealYourChurchWebsite do-over.

Time for Heal Your Church Website to upgrade her browsing experience.The birds are singing, the flowers are blooming and WordPress 2.5 has been ‘in the wild’ for a couple of weeks. These factors, and the fact that my own blog is getting a bit crufty has me thinking it is time for yet another Heal Your Church Website do-over. That and I’ve been getting some ‘love notes’ that either fall into the category “how do I get started” or “you reviewed my site, so here is why your blog sucks.” I figure success is the best response, so here’s my initial game plan – thinking out loud as some of you may be in a similar situation of having to freshen up your church and/or charity website.

  1. Research

    I’ve already got a good idea of what I want to say, so mostly in this case I need study what resonates via the results I’ve been collecting via Google Analytics and FeedBurner, including:

    • keywords,
    • popular pages,
    • unusual usages of feeds,
    • any patterns in exit pages,
    • any patterns in entry pages,
    • and any patterns in people navigating into the site.

    I’ll couple this with looking over my error logs to see where people are stumbling the most. I think looking over some of the nicer ‘love notes’ may also be useful as they’re often requests for information I’ve published before.

  2. Plan and ‘objectifry’

    Meaning, based on the research above – along with day-to-day experiences, enumerate a set of requirements and objectives mostly based on needs, though since it is a personal blog, some wants too.

  3. Backup everything

    I need to not only save everything, but also insure I have an effective restoration/rollback plan in the off-chance things go horribly wrong (like I don’t have the right version of PHP or MySQL, etc …).

  4. Re-factor my categories

    Some of these old categories are crufty and unintelligible. They need my healin’ sooner than later and I’m thinking probably better to do it before the upgrade than after – though the new version of WordPress may have some features and/or plug-ins that make such a migration less painful. I’ll have to research that.

  5. Draw out a new template

    First on paper, then later using PhotoShop or PhotoImpact. Don’t get me wrong, I still like the whole Byzantine Cross on the blue domes of Orthodox Churches at Santorini, and may have an opportunity soon to be there – but overall the current theme is beginning to wear. That and it’s just too darn dark. Perhaps rotating images like I recently wrote when I developed the almost ready for public purview Oliver North’s and Chuck Holton’s American Heroes book blog.

  6. Upgrade to WordPress 2.5

    Knowing already that this step will likely include the following plugins:

    I already use some of the above, I also know others come ‘bundled’ with the WordPress 2.5 release. Also a word of warning to WordPress “n00bz” – I’ve got a very good idea of what I’m delivering here content-wise, so any and/or all of the selections above are based upon those needs; rather than those ‘neato-keen‘ inspirations.

  7. Update the Theme

    Either generate from scratch and/or adopt and/or modify an existing WordPress theme that is

    • A wider fixed or fluid width
    • Widget ready
    • Has an options page
    • 2 or 3 columns
    • Right sidebar
    • Brighter colors

    I also need to code the theme (or write a plugin) so the last 2 or 3 posts display in full, the next 8 or 10 as excerpts.

  8. Test the site

    • first for functional soundness (technical testing)
    • then to see if it meets my goals/objectives (use cases)
  9. Clean up crufty content

    Go through older articles, eliminating/archiving stuff that’s no longer relevant and cleaning-up some that got hammered by moving from MT 1.0 through 3.0 then to WP 1.5 through to 2.5.

  10. Sit back and enjoy

    Create numerous annoying posts about what pains I suffered executing on the above game plan.

So here’s your chance kids – got something you’d like to see done differently here? Speak up, now’s your chance.

Oh and if I get enough love notes and/or comments on this topic, I’ll discuss answers in a fun follow-up post. So be sure to make your notes to me pithy and quotable (and don’t forget the link to your site !-).

Posted in Uncategorized

Vista vs. Ubuntu and the value proposition of a work in progress

Ubuntu vs. Vista and the cost of waiting on a work in progressLast Thursday, Microsoft CEO Steve Ballmer created a virtual firestorm when he said the following about the much maligned Vista operating system:

Windows Vista: A work in progress. [Laughter, applause.] A very important piece of work, and I think we did a lot of things right, and I think we have a lot of things we need to learn from. Certainly, you never want to let five years go between releases. Can we just sort of kiss that stone and move on? – Todd Bishop’s Microsoft Blog, SeattlePI.com

While I’m glad to see Mr. Ballmer’s frankness regarding the ongoing issues with their most recent operating system offering, on the other hand I need to ask the simple question any and all individuals involved in supporting a church or charity’s IT operations needs to ask:

If my office, contact management, presentation, web administration, and other applications are all web-based, then what is the value proposition of sticking it out with Microsoft’s expensive work in progress, versus a more cost effective work in progress such as Ubuntu? – Dean Peters, Heal Your Church Website

In other words, did Steve Ballmer accidentally commit an act of software seppuku through this self-inflicted F.U.D.? Or is this a CEO’s way of cutting Vista losses so more development resources can be relegated to Microsoft’s Singularity efforts?

I can’t tell. Meaning, I am in no more of a position of visibility to clearly see if that’s what’s actually happening here than Microsoft Vice President Chris Capossela appears to have of Microsoft Work’s competition from Google Apps.

What I can tell for now is that:
Cornucopia of online office suite logos

  • Ubuntu, also a work in progress, offers a platform that won’t require expensive hardware and software upgrades in the short to mid-term;
  • Online office suites such as Zoho and Google Apps allow me to work collaboratively and concurrently across diverse locations and computer platforms; and
  • Microsoft continues to move the goal posts, perpetually engaging in long-standing practice to significantly change applications, operating systems and programming languages.

Such ‘fog of war‘ is never a good thing when making potentially expensive operational decisions. And if good stewardship means making decisions that won’t cost my church or charity in terms of money, man hours, and madness, then do heavy investments in client-based applications for either Ubuntu or Vista make sense?

All the more so when one considers that the majority of the work is occurring not just in a single office, but also in the homes and office desktops of the various laypersons and volunteers whom shoulder the brunt of the workload and expense?

What about you and your organization? Can you afford to feed dollars and hours into a work in progress that will likely require upgrading not only hardware, but a number of the residing desktop applications … or is it time to consider moving off the desktop and into the web space?

This one has been buggin’ me all weekend, so comments and opinions please …

… meanwhile, some additional links on the Ubuntu vs. Microsoft Vista topic:

Posted in Uncategorized

5 things the Holy See website could do with the Pope’s visit to the U.S. and UN

See large screen shot pointing out some of the recommendationsI realize, understand, and respect the Catholic tenant that their faith is built upon a combination of Scripture and historic tradition. That said, there’s no reason the Vatican website should continue to ineffectively rock like it’1999. With that in mind, here are 5 things I’d do to enhance the Holy See website to better publicize and describe Pope Benedict XVI’s April 15-21, 2008 Apostolic Journey to the United States of America and visit to the United Nations Organization Headquarters:

  1. Deal with the annoying home page issue
  2. Lose the Mystery Meat Navigation
  3. Provide an RSS feed for the trip events page
  4. Embed a Google map of the journey on the the trip events page
  5. Offer immediate YouTube videos the events

Allow me to explain:

1. Deal with the annoying home page issue
I completely understand the point of offering a point of entry for multiple languages and cultures – what I don’t understand is why this splash page is actually defaulted as the home page. Meaning, once an individual selects a language, cookie that up and redirect the user back to the main navigation page of their desired dialect – rather than send a visitor back to the language selection splash page each and every time the they click on a link for the home page.And while we’re at it, how about providing similar language support/options on the footer of the page as some may enter the site via sub pages via search engines? Especially in a day and age where identifying the country of a visitor’s ISP is possible, making default language options a possibility.
2. Lose the Mystery Meat Navigation
The rollover links on the main navigation page have got to go. I realize there is some mystery about one’s faith – however that should never be extended website navigation. Especially as this particular annoyance was first identified back in March of 1998 in Vincent Flanders’ seminal work “Web Pages that Suck.” For more information, I recommend studying Father Flanders’ sermon on the topic of “Mystery Meat Navigation.”
3. Provide an RSS feed for the trip events page
If you’re going to enumerate news events of the Pope’s visit to the U.S., then provide Real Simple Syndication (RSS). The cost of implementing RSS are miniscule – yet the return on investment is potentially huge as it allows aggregators, bloggers, news services, search engines, email programs and browser applications to plug-in and peruse up-to-date articles on the Pontiff’s journey shortly after their posted.
4. Embed a Google map of the journey on the the trip events page
While the Vatican Holy See website has at least provided a page dedicated to the Papal visit to the United States, it could offer quite a bit more by embedding a Google Map instead of the current, dull, static picture of America with dots rendering.Taking this approach brings the trip to life – I should know, I’m nowhere near as famous as the Pope, yet I received quite a few daily hits to a travel map of Jordan I created on Google Earth and then coverted into a Google Map.
5. Offer immediate YouTube videos the events
Here’s another no brainer I blogged about in preparation for my recent tour of the ‘other’ Holy Land. Consider the recent PC Magazine article entitled “February Web Video Views Top 10 Billion” which informs us that “U.S. Internet users viewed more than 10 billion online videos during February 2008. “Meaning, someone associated with the Holy See should be following Pope Benedict about with a video camera, posting to YouTube, and then embedding/linking up the videos on the Vatican website.

Along with the items I’ve enumerated above, I suspect the larger problem here seems to me a long running reticence to revitalize this site to take into consideration the changing face of the web.

Whether this is a result of bureaucratic turf wars and/or simply a lack of training and talent – one immediate way of remedying this issue is for more fast and flexible to change blog-based Catholic church websites, along with a number of popular Papal bloggers to go ahead and employ my ‘fast five’ recommendations – if nothing else as an educational opportunity and service of and to the Body.

One other aside note – usually when I blog about anything Catholic, I get one or two “love notes” and or long-winded comments attempting to teach to see their theological reasoning as to why I shouldn’t “assist those people.” Please be aware that I’m very busy these days, so please save such ‘compelling‘ content for your own Chick-Track blog.

Posted in Uncategorized

Jakob Nielsen: Four Bad Designs and a 403 error to boot!

What could be more ironic than to receive an email from Jakob Nielsen’s Alertbox on the topic of “Bad content, bad links, bad navigation, bad category pages” that links to a page that throws a 403, permission access denied page?-) Fortunately for you, I got screenshots, followed by some commentary on the article once the good folks at UseIt.com realized the error or their ways.

First the email:

Jakob Nilesen’s altert box email of 14-Apr-08

Then the broken page link:

Jakob Nilesen’s broken page link to 4 bad design

Now onto the article …

Yeah, I know, I’ve offered similar errors before – but then again, I’m a one man operation who posts whenever I feel I have something compelling to discuss. In this case, I think the content of Nielsen’s article “Four Bad Designs,” once liberated from the restrictions of an errant and untested .htaccess file and/or mod_apache directive provides both a compelling and worthy discussion of:

Bad content, bad links, bad navigation, bad category pages… which is worst for business? In these examples, bad content takes the prize for costing the company the most money.

Bad Content: Jazz at Lincoln Center

Here, the good Dr. poses the age-old question “where’s the beef!?” And while his point is about scant detail about an upcoming performer, I could say the same applies to church websites when announcing guest speakers and/or special events.

Links without Information Scent: New York Times

If Jakob Nielsen were writing about church websites, he’d perhaps pose the question ‘Who’d want to click on “Next Sermon in Tithing”?

In other words, give your links some “what’s in it for the reader” type jazz.

Interior Splash Pages: Christopher Norman Chocolates

This is directed at the growing number of church and/or charity web masters who think for some reason it is compelling and cool to embed huge, bandwidth consuming Flash-based slide shows for each and every category of your website.

I think Nielsen sums up my opinion of this sin when he opines:

Splash screens are bad enough when they sit in front of a site’s real homepage, but at least users encounter those screens only once. With a splash screen for every category, users have to click through many extra pages to see all the products.

Amen, preach it brother!

Metaphor Run Amok: Specialized Bicycles

Dr. Nielsen’s point also applies to gizmos, gadgets, and special effects that continue to plague a plethora of parishioner inspired web pages.

The Business Cost of Bad Design

Two words: empty pews.

Meaning, the general reaction by first time visitors to the above design issues is that they become one time, never again visitors.

Think about that the next time someone comes to you with a a website idea that is more style than substance. Better yet, send a link to this article to your pastor and youth minister – so the next time they hit you up with a “great idea” you can remind them of that “4 bad designs” article link you sent them back on April 14, 2008.

Posted in Uncategorized

How to quickly check your error logs for oddities

 Sample of error logs and stats screensWith more church webmasters taking advantage of free, one-click installs (e.g. WordPress, Drupal, etc …) provided by inexpensive web hosting solutions, I figure it is time to provide a quick tutorial on how to harvest useful operational, user and security information the error logs using a variety of commands already at your disposal – free.

I have error logs” some ask? To which my response is: “Probably, did you ask your host provider?

Once you do find your error log file(s) – and most reputable hosts do provide them, usually through whatever host management application they provide (e.g. CPanel, Plesk, etc …) – then it’s time to answer the not asked often enough question “what do I do with them?

Below is ny semi-definitive, and most certainly emphatic response:

Resolve 404 errors

404 is an HTTP response by your website’s server to a user-browser request to a file not found. This information is tracked in your access logs, but usually and often is included in your error logs.

Here is why this is important to you – reducing 404 errors:

  • reduces user frustration;
  • points out bugs in your configuration;
  • saves you gobs and gobs of disk space;
  • points out potential vulnerabilities; and
  • once fixed, improves available user bandwidth.

First thing you need to do is figure out how your error log works, and what type of verbose messages it may or may not offer.

Then you need to make sure you have enough SSH access (e.g. via tools like Putty) to run the Linux commands grep, egrep, tail, more and perl against your error logs.

Short digression: Yes folks, for today’s lesson I’m assuming you are hosting on some form of a *nix platform – though one can actually perform the following functions on a Windows-based machine applying command line UnxUtils against a long file either on a server or FTP’d to your home computer.

Getting back to today’s lesson, here’s a simple example of what command-line I would enter if I wanted to see the last 50 lines of my error log:

tail -50 error.log

This quickly gives me insight on the type of error messages available. For the ubiquitous 404 error – which in my world is recorded in the error log file in plain English as “File does not exist” … your mileage will likely vary. With this key phrase in mind, I can now enter the command:

grep "File does not exist" -i error_log

Parsing logs into human-readable columns

Problem is, I probably get more information than I want. What I’m simply after is which IP is getting the error, how often, and on what page request. For that, I “pipe” the output from the “grep” command through Perl – which in turn parses the results by spaces.

grep "File does not exist" -i error_log | perl -l -a -n -e 'print $F[7]," ",$F[12]'

Counting the spaces, the IP address in my logs hits at position 7, the errant file at column 12. You’ll likely have to figit with these to get it to produce the results you’re interested in.

Once you do, my suggestion is directing these results into a temporary file you can visit for later use. For example:

grep "File does not exist" -i error_log | perl -l -a -n -e 'print $F[7]," ",$F[12]' > 404errors.05mar08.txt

Once you see where the errors are occurring, usually its just a matter of creating a more comprehensive 404 request manager, and/or replacing a file that got accidentally deleted.

Excluding certain entries

One last trick – let’s say you’ve fixed two of your errant files, and now want to see what remains in your error log.

Try this one on for size:

grep "File does not exist" -i error_log | egrep "\/(file1\.html|file2\.png)" -i -v | perl -l -a -n -e 'print $F[7]," ",$F[12]' > 404errors.05mar08.txt

Note that I used egrep instead of grep, the ‘e’ standing for regular ‘e’xpressions, which when coupled with the “exclude” operator of ‘-v’, provides us with a list of errant files excluding those you just fixed.

Closing ‘args’

I realize that this may sound like ‘ancient geek’ to some. If that’s the case, then my advice is ask your hosting provider what type of error stats may be available through a pre-packaged application that many hosts provide such as “awstats” and/or “webalizer.” They don’t provide the ‘gory details’ one gets with the command line options above, but it’s good enough.

Yet for those who dare, there are additional benefits to learning how to parse your own error logs – for example, scheduling the above commands (that pipe into a file) in your cron table so you can quickly identify broken files and/or interesting inquiries from bad boys using a variety of anonymous proxy services and/or browsers in an attempt to set-up my blog as their own personal spam-bay.

You can also save money, support calls, and/or bandwidth by identifying missing pages, images and other fixable omissions.

For them, I have some .htaccess hacks awaiting them based on the useful input they provided me via my personally parsed error log.

Posted in Uncategorized