Heal Your Church WebSite

Blog

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:

Then the broken page link:

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.

April 14, 2008
How to quickly check your error logs for oddities
With 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.
April 2, 2008
How to avoid high maintenance church website design
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)
March 31, 2008
How I fixed my Windows XP Stop c000021a {Fatal System Error} with Knoppix Linux
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.

This morning, when I powered-up my computer at work, my Windows XP-based computer booted blue, noting a file error which in turn kicked off an automatic chkdsk scan/fix of my hard drive. I got some coffee and used my smart phone to address email while all this was going on.

When the system was done “fixing” the broken files, it rebooted to something I’d never seen before – a blue screen of death with the following ubiquitous message:

Stop: c000021a {Fatal System Error}
The Session manager initialization system process terminated unexpectedly with a status of 0xc000026c (0x00000000 0x00000000).
The system has been shut down.

After a few bouts with the on/off switch, it was clear, I was dead in the water.

I walked down the hall to visit the IT guys, together we brought up the Microsoft Knowledgebase file #317189 entitled “Error Message: Stop c000021a {Fatal System Error} The Session Manager Initialization System Process…”

It had fun advice like installing Dr.Watson, running a memory dump and then sifting through the disassembled 0’s and 1’s to figure out what broke. Of course one’s machine would have to boot before that byzantine process was possible – a minor point not considered in said documentation.

There were some other things about registry files, but again, I can’t get to the the C:\> command line prompt then it doesn’t do me much good.

I did find on the Messenger Plus! Live Forums advice to run the Windows repair and replace my psapi.dll file with an older version, but again, that’d require getting onto the hard drive – and the only way I knew how to do that at this juncture would be take a route similar to the one I wrote about in 2003 in my post entitled:’Linux-based approach to fixing MSBlaster Worm infection.’

So after digging through a few drawers and CD stacks, I found a Knoppix CD I had ‘burninated’ back in October for my blogging-tour of Jordan. For those of you who don’t know, Knoppix is a Linux distribution based on Debian GNU/Linux designed to be run directly from a CD / DVD.

So I popped the Knoppix disk into the CD drive, turned on the power switch and within minutes, my machine was back up and running under Windows XP; though part of me wonders if there’s not an Ubuntu install in store for my aging home computer … but I digress …

Anyway, I figured it might be helpful to some of you out there if I provides some detailed step on how I fixed my broken Windows operating system with Linux:
1. Boot up your computer from the CD drive with your latest CD ‘burnination’ of Knoppix.
  - For me, this meant hitting the F12 key on boot up, and instructing the computer to boot from the CD/DVD drive instead of the hard drive.
  - This step also assumes that at some time in the past, you downloaded, burned and tested a Knoppix CD.
2. At the initial ‘boot:’ prompt, hit enter.
  - You may find you’ll need to boot Knoppix with various startup options to make it work on you particular hardware platform.
  - Hitting the F3 key will show you some of those options. You can also find “cheat codes” online.
3. Hopefully at this point you’ll see a “Windows-like” desktop known as KDE – and with luck – the hard drive in question will appear represented by an icon at the upper left as mounted and available for use.
4. Click on the drive icon that contains your Windows operating system. This will open up (and you Linux fans out there, please forgive me for the term I’m about to use) this will open up an “Explorer like” file window as depicted below:
  
  I suggest changing the the display to list the files in ‘detail.’
5. Sort your directory by date in descending order.
6. Expand both the found.000 (our found.001..n, etc) and your Windows/System32 directories.
7. View which files the Windows chkdsk moved into the found.000 path as listed below:
8. Check for the same file names in the System32 directory – back them up of need be – then copy the files from the found.000 path into the /Windows/System32 directory; overwriting the existing files by the same name.
  - This is a dangerous move and can entirely mess-up your system -do it at yoru own risk.
  - In my case, I would have made backups, but all of them were of a 0 byte filesize, timestamped this morning at the time of the crash.
  - This is a dangerous move and can entirely mess-up your system -do it at yoru own risk.
  - It never hurts to backup files you’re abut to overwrite.
  - This is a dangerous move and can entirely mess-up your system -do it at yoru own risk.
9. Shutdown Knoppix correctly (don’t be impatient and just pull the plug:-) – remember to remove the CD from the drive when prompted.
10. Reboot under Windows.
DISCLAIMER

: Warning – I do not recommend this course of action. I am merely enumerating the steps I took to fix my computer under my circumstances, configuration and context. Your mileage may vary – as potentially you risk losing everything in following the same above steps.

Now if you don’t mind, I have some backups and diagnostics to run. After that, time to go ‘burninate‘ a fresher Knoppix CD; you never know when it’ll come in handy.

– – – § – – –

MORE GREAT ADVICE:

– – – § – – –
March 14, 2008
Inaccessible, that’s what you are
I find too many church and charity 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 ‘snarkastic‘ enumeration of this pesky issue:

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? You becha! 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 to gauge 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’ church websites, 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 … so does Vincent Flanders who defines the practice ‘flashination‘ in a slightly more adult parlance.

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.
March 11, 2008
How to set your system clock in Linux

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!

Here are two simple command lines to synchronize your Linux system clock with the atomic clocks offered by the National Institute of Standards and Technology … hmmmm … atomic energy ….

… sorry, got distracted with all that power at my disposal. So if you have access to the root account of your server, or better yet – have access to the guy who has access to the root account, here’s all you need to know:
/usr/sbin/ntpdate -b -s time-a.nist.gov /sbin/hwclock --systohc --utc
Now if you don’t live in the EasternTime Zone as I do, then you’re NOT going to want time-a.nist.gov as your time server. Instead, go to the NIST Internet Time Service page and pick the server that best matches your timezone and daylight savings situation.

While you’re at it, you can also modify the /etc/rc.d/rc.local file to include the above commands – or at least the first command so it is executed when the server reboots.

For more gory details on this topic, here is a great little page called Linux Tips – Linux, Clocks, and Time to get ya going in the right place … at the right time (sorry, couldn’t resist the corn-ball humor opportunity).

Oh and for those in the U.S. who need to set the clock on the VCR (I know some of you still have them … blinking) and/or microwave oven to the correct time, there’s always the human readable the official U.S. time web page, also offered by NIST.

Like your mileage, your timezone may vary … and I promise … no more ‘geek speak’ for the rest of the week.

March 9, 2008
How to block a range of IPs from spamming your church website
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.

Whatâ€™s worse is that many of these attacks these days come from servers in countries where you have absolutely no legal, let alone social, recourse to stop said attacks. Take for example a recent slam of attacks on a new dedicated server Iâ€™ve been working on â€“ all which failed due to recent preventative security endeavors â€“ but all incoming from a block of related IP addresses from a server in China all of whose addresses had 218.25.161â€¦ in common.

And while these unwanted advances were successfully thwarted by various server hardening practices implementations â€“ the best way to avoid trouble from said attacker is to just deny access to anything on the server by denying the range of IP addresses indicated in my security logs.

With that in mind, I thought Iâ€™d share two approaches to blocking a range of IP addresses. One solution at the firewall level â€“ the path I prefer on dedicated servers, the other solution is blocking IP blocks via the .htaccess file, which are employed on sites hosted on a shared server.

Using APF firewall, I simply create an entry that defines the block â€“ in this case:
```
218.25.161.0/24
```
In the .htaccess file:
```
<Limit GET HEAD POST>
```
```
order allow,deny
```
```
deny from 218.25.161
```
```
allow from all
```
```
</LIMIT>
```
Both implementations block IP addresses from 218.25.161.0 through 218.25.161.255. But what happens if I only want to block addresses from a smaller set of addresses? Like those coming from someone abusing their DSL services whose range of dynamically assigned IPs may only be a range of 216.12.201.150 through 216.12.201.200.

That becomes trickier as is requires both a knowledge of the â€˜CIDR notationâ€™ and the bit mapping that goes along with it. Which is why I recommend instead using this nifty little online tool from Mikero.com. An easy-to-use service which performs all the bit-blasting, while also â€œaligningâ€ the range so it can be expressed in correct CIDR notation.

Or in laymenâ€™s terms, I add the following generated range to my firewall:
```
216.12.201.128/25
```
Or where no such firewall access is available, the following line in my .htaccess file:
```
deny from 216.12.201.128/25
```
Below are some tools and links on the topic of how to block a range of IP addresses if you want to dig into it a bit further.

Online tools to calculate an IP address range (CIDR):
- Mikero.com IP address range calculator
- IPAddressLocation.org subnet mask calculator
Online tools to check/verify your CIDR notation:
- Grox’ WhatMask IP subnet/CIDR Calculator
- Security Tools Online Painless CIDR calculator
Tutorials on blocking IP addresses and CIDR subnet masks:
- WebGeek: .Htaccess IP Banning – Block Bad Visitors
- WhatMask? from Laffey Computer Imaging
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, deny 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!
February 14, 2008
How to secure your church’s dedicated Linux server
This post is dedicated to all of you running your churchâ€™s website in the choir robe closet, or who have been graced with a generous and geeky member who has taken advantage of one of those cheap, unmanaged dedicated server deals advertised at places like WebHostingTalk:
- Richyâ€™s Random Ramblings: Techy: Handy Security Tips.
As the author plainly states, â€œThis list is not comprehensive, nor does [he] take any responsibility for any harm that may come to your server if you use any of these commands.â€

Emphasis mine, that said, I found this a very good â€œquick referenceâ€ for those of you thinking about running or leasing your own Linux/Apache server. Especially for those blissfully ignorant enough to think it can be done simply by installing ubuntu on an old machine some donated as a tax-write off.

Using Richyâ€™s sobering tips, I went out and found how-to articles on each of these “dedicated Linux server for dummies” points – just so you could realize just how much work goes into “hardening Linux servers for dummies:”
Now if this hasnâ€™t scared you out of running your own server in the basement of your church or charity (and Iâ€™m hoping it does), ~~then may suggest~~, rather â€¦ I COMMAND YOU to go buy and then read â€œHacking Linux Exposedâ€ before you take the dive.

Seriously, consider the costs of trying to save money by running a box out of an unused closet or corner of your church. It may be more expensive in time and lost off data than you think. At least think of all the work that goes into hardening Linux web servers these days.

How â€™bout some of you other pros out there? Iâ€™m sure Iâ€™ve missed something. Leave a comment, we’ll add to the list.
February 9, 2008