If Jesus Had A Website

After writing about my experiences in changing my site from table-based to CSS-and-DIV-based for the layout, I've found it to be one of the most-read articles and have frequently discussed it with readers. Therefore, I decided to start a little series that will make up a CSS Primer.

First, I want to talk a little about what CSS is. CSS is short for Cascading Style Sheet, and what they do is allow you to assign specific styles to different HTML elements, such as borders, backgrounds, and fonts styles. They've been around for nearly a decade now, and every major web browser supports them.

Take note of the cascading portion of the CSS name. What this means is that all elements within the one specified will get the same style properties. For example, without getting too technical yet, if I set a background color for the body of my document, that background will be applied to all elements within the body of the page, unless a different style is explicitly defined for that element.

Second, I'd like to look at why we want to use CSS for site design and layout. The major intent of CSS is to separate the content of a page from the design of a page. If we combine the content and design into a single entity, this means that we need to maintain them together. Separating the two allows us to worry about them individually. This is very useful for site redesigns, because we can keep the same page content, and simply change the the CSS to give the site a different appearance.

Using CSS also allows us to apply the same style to several pages more easily. Because the CSS can be kept in an entirely separate document, we can then refer to this document from several different web pages. Without this ability, this means we would have to update the appearance of each of our pages individually (which is a major pain for large sites).

One other advantage of using CSS is that it makes our web pages easier to read because they are no longer littered with style information (or extraneous table information, for that matter). Anyone who's spent a significant amount of time programming or editing code can appreciate the appeal of clean and easy-to-read code.

Now that we've discussed some of the basic advantages of using CSS for you site design and layout, next time I'll cover the basics of implementing CSS, and continue building from there.

You may not have really thought about the colors of your site before, or you may have spent hours agonizing over them, trying to get them just right. Colors are very important because they evoke different emotions and messages. The combination of colors is also important because we don't want our site to be unreadable by those who are color blind. We have to be wary of these, because colors play a big part in our first impression of a site.

So how do we go about chosing good colors for our site? Here's some suggestions:

• First, pick a primary color for your site (preferably the background). If you already have a good church logo, you probably want to pick your primary color from there, if not all your colors. Even a good photo can be used as the basis of your color scheme.
• Second, check a color match or color scheme website to see what colors work well with those you've already chosen. These will be good colors for other backgrounds on your site, links, or a number of other things.
• Third, pick out a font color. Preferably this will be a color of high contrast to your background(s).
• Once you have your core set of colors, try to limit yourself to using only three or four of them as colors for fonts and backgrounds. Too many colors become distracting.

Of course, there are an infinate number of color combinations that could work for your site. But half the fun is experimenting to see which looks best for your church!

Back in May, I wrote an article on Utilization as part of my Key Site Concepts series, and while I am still a big proponent of taking advantages of services provided by other sites, I learned a rough lesson this week.

I maintain a personal blog called Further Up and Further In (it's a Chronicles of Narnia reference from The Last Battle in case you were interested). One of the features I have on there is my weekly "most listened" lists for my music. These lists are populated by XML documents provided by Last.FM, and this week they did a major upgrade of their systems and services.

And guess what happened? There was an error with one of the XML documents, and my script that was carefully crafted around them choked. Since I did not build in any way to catch such an exception (nor had I needed one in nearly six months), my site came to a screeching halt when it tried to read from the XML. After more than two days with my blog out of commission (I would have fixed it sooner, but I was busy with work and helping a friend move), Last.FM fixed the XML and my site was back in business.

However, it made me realize the cascading nature of errors when it comes to utilizing the services of those sites. If that service goes down, so does everything that uses it. Because of this, we should always try to build our sites to deal with these failures if at all possible. If you're using a maps service for your church's website, make sure your site can have a map image (or at least just load without the map) if that service goes down or makes an upgrade where the service location changes.

If there's anything worse than out-of-date websites, it's broken websites. Don't let what happened to me happen to you too!

Over the past few years, I've really begun to see myself mature as a developer. It's not that I've learned any new mind-blowing code or languages, but instead in my development process and practices. I've developed an appreciation for well-documented and well-planned code, as well as for security practices.

Most of this maturity has been spawned by actually working with applications and databases that are meant to be used. When previously developing code on my own or for class, it was more along the lines of building a house of cards: I could put it together but it wasn't very stable. The application wasn't reasonably useful for anyone else.

While it may be nice to incorporate new features in our sites, like our faith, it's important to start with a solid foundation. We shoud strive to have websites that validate (or at least display consistently across brosers), catch errors, redirect bad links, and avoid making a visitor say "Uh Oh" or "What do I do now?" Not only that, but we should make them easy to pass on to someone else if the need ever arises.

It's something I can't even say is complete for this site (it's a long process when you can only do it in your spare time), but it's something I'm striving towards. It can be a long and not very exciting process, but in the end it does have it's rewards. Think of it as the "measure twice, cut once" of the programming world. In the end, it will save you a lot of hastles.

The coexistence of business and religion has always been an interesting one, especially for the Christian businessperson. Many people have a hard time seeing a person striving to make money and do God's will at the same time, but that doesn't mean it cannot be accomplished. In fact, I've met several people who have been blessed with both a passion for God and great business sense.

However, there are also the cases when things go awry. I stumbled across one apparrent case of this a few weeks ago when I found ChurchShoppers.com. This is a site designed to help match people up with churches if they are switching churches or moving to a new area. The site appears well-intentioned for the most part, even including a belief statement, but it's then littered with advertisements. Ok, that I can deal with as it's become pretty commonplace on the web.

The real kicker to me was that if you want to have your church listed, you have to pay a $69.97 introductory fee for a basic listing, with another $149.97 each year thereafter to remain listed. And this is for a minimal listing. Their premier listing runs $99.97/200.97. All this for a service which doesn't do any more than allow churches to list contact info and leave some basic information about themselves.

Now, if they actually sent someone out to attend a service and provide some useful feedback for users, the listing may be worth the price. For now, this is simply gouging for a service that would be less effective than making sure your church website is listed in Google.

Honestly, the site may have been started with the best of intentions, but is has seemingly lost its way of promoting the kingdom of God in favor of the mighty dollar.

The lesson to learn from this is that when you partner up with a buisness (Christian or not), make sure you take the time to learn a little about those you are getting involved with. Otherwise, you may find out too late that the "Christian" business you've chosen may be working both for your cause and against it.

This past weekend, I was given the opportunity to have a very unique experience. I was asked to preach before our congregation while our pastor was out of town at a wedding. Let me tell you, it gave me a new respect for all that a pastor needs to take care of.

Fortunately, I had several weeks to prepare for my sermon, but it still took up a lot of time to put it together. And then there was the whole public speaking aspect, which I haven't had to do since I led recitations in graduate school. Let me tell you that flow is no easy task.

And I didn't even have to worry about getting calls at home for prayer, making any hospital visits or any number of other pastoral responsibilities.

What I'm getting at is reiterating how important it is to have specific roles when it comes to the church website. In smaller churches where there is only one pastor (which happens to be most churches), we cannot expect the pastor to find the time for one more thing to worry about. If the pastor would like a blog, then more power to 'em, but expecting them to take on the responsibility of providing the church website's content is probably too much to ask.

So, I encourage you once again to spread the responsibilities among several people if at all possible. Once all the cogs are in place, it's much easier to function as a well-oiled machine.

Today I'm sharing with you a few new links I've come across this week. Use at your own discression.

First is the Evangelism Forum, a new place to discuss evangelism practices and experiences. They've also got a category specifically on web evangelism which you may find useful.

Second is a series on Church Website Annoyances by Tim Lehrian on his experiences as IS Administrator for the North Indiana Conference of The United Methodist Church. Check out all five volumes of his work below. It also sounds like there may be more to come!

• Church Website Annoyances, Volume 1
• Church Website Annoyances, Volume 2
• Church Website Annoyances, Volume 3
• Church Website Annoyances, Volume 4
• Church Website Annoyances, Volume 5

Third is a bit of fun with The Missionary Game developed by Anders Torvill Bjorvand that was unveiled at the Global Christian Internet Alliance conference. It's free and playable online, and is an interesting foray into the mix of technology and Christian faith.

That it for this edition. Make sure to swing by the main site to vote on our current poll about web-related work experience if you haven't already…I'll be hilighting the results on Monday.

I wanted to pass along this really good article from Jim Walton over at Church Tech Matters where he talks about the perceptions of those who "work with computers" and how not everyone who fits that description is the right person for specific tasks within the church (i.e. site design, web applications, tech support).

So, if you are a pastor or other leader in a church, there is a fairly good chance that you are not that technical and there is nothing wrong with that. But, how can you find the right kind of technical expertise? The truth is, being a computer guy does not mean expert at everything technical. There are different kinds of programmers, plus a graphics person is not necessarily a network administrator too and a network administrator may not be skilled at desktop support or PC troubleshooting.

Each of us has a level of expertise within our computing knowledge, and it's something that important to make clear when we are recruited for specific tasks. For example, I'd do great as a web application developer or database administrator, but I'd make a lousy graphic designer (as may be evident by my MS Paint based site logo).

Check out the rest of Jim's thoughts in his article 10 Feet Tall and Bulletproof…….Really?

A happy 4th of July to everyone around the world, and a happy Independence Day to my American bretheren. We've got rain here today, so we might not even get to have our fireworks…

But it's still a great day to reflect on the freedoms we have that so many of us take for granted. Praise the Lord for them!

Since it's a holiday weekend and we've only gotten 4 votes so far, I'm going to leave the current poll up a little longer.

Make sure to stop by the IJHAW homepage to vote!