If Jesus Had A Website

This is the second in a series of key concepts for your site that should help to make it a better place for all those involved.

Do you remember your years in elementary and high school when you got the lecture on the virtues of doing things on your own? The lesson was that if you didn't actually do the work yourself, you may still get a passing grade but you will not have learned anything.

It's one of life's important lessons, but here's another one for you: Don't do work that someone else has already done for you!

One of my favorite things that has arisen out of the Web2.0 is the plethora of services that have become available through the use of API's (or Application Programming Interfaces). The benefit of these services are that many of them have already created a framework to implement some of the complicated things you want to do to make them easier to include in your site.

Let me give you two examples from the site I recently redesigned for my home church, South Pittsburgh Assembly of God:

• Calendar: A good calendar is a relatively difficult thing to program, and adding events to that structure can be even more difficult (especially if you have events of the "third Thursday of the month" variety). It's something that really isn't worth all the development effort for inclusion on your site. Instead, there are a number of calendar services you can use to create that calendar. In this case, I chose Kiko to manage our events, and then used an RSS feed built off that to display the Upcoming Week At SPAG section on our main page. Google Calendar is another popular option, but I found that it's ability to put recurring events into a reusable format was a bit lacking for what I needed to do.
• Map: Every church website needs a good map! How else is anyone going to find your building come Sunday morning? Sure, it's easy enough to go to MapQuest and save the image that is returned, but there are limitations to that method. Sometimes the names of roads (even major roads) are left off of them or are too small to be readable. Plus, depending on the area covered on the map, some people may not see a road they are familiar with. However, thanks to Web2.0 applications, we now have web applications like Google Maps and Yahoo Maps to build off. For our location page, I chose to use the Yahoo Maps API to create a fixed size map that was zoomable and movable. This helped to solve the road name and map scope problems I mentioned above.

In both cases, I had something I wanted to do, but I had neither the experience or resources to develop it on my own. Instead, I used publically available and free APIs to do the hard parts for me, and worked them into my design. Usually the most you have to do is apply for a free API key so that they can track who is using their service.

The only thing you will need to do is review an API before you decide to implement it. For example, the reason I chose the Yahoo Maps API over the Google Maps API was that the Google Maps API key was only valid on the domain, but I did all of my development of the site on a separate computer, and I wasn't about to deploy any code I hadn't had the chance to test first. Therefore, I settled on the Yahoo Maps API because it's key was domain independent. Sometimes it requires experimentation as well, as was the case in my calendar searches.

So, in this case, don't try to do it all by yourself. There's lots of tools out there to help you do what you need to do. You just have to find the ones that work best for you!

As my experience with CSS has grown, I'd grown less and less pleased with the layout and appearance of the site…so I decided to go ahead and make a change.

The new design is intended to be a bit more clear and organized, in more of a traditional blog layout.

So, what do you think?

This is going to be the first in a series of key concepts for your site that should help to make it a better place for all those involved.

About two months ago I changed jobs, going from being a do-everything developer/database administrator/IT guy for a research study to being a database administrator for a mid-sized company. I spent most of my final two weeks at my old job gathering documentation, commenting code, and training our junior developer how to do as much as I could. Then I came to my current position, and struggled a bit with the transition for one clear reason…nothing was documented!

I know what you're thinking…"Wow, Greg…that stinks, but what does that have to do with my church's web site?"

In all honesty, it probably means a lot more than you realize.

Documentation is a key element to any kind of programming, and it applies to all web site work whether you work with ASP, ColdFusion, PSP, or basic HTML. However, many of us programmers are not always good at keeping up with our comments and documentation. Most of us are convinced we can just read the code anyway. However, I know I've gone through a few late-night coding sessions and regretted not keeping up with my documentation.

Some other good reasons to keep up with documentation:

• You're Not Going To Run Your Church's Website Forever – Probably the most important reason to document the code that you create. It gives the next person to come in or additional people coming on board an insight into what you've been trying to do. It helps them get up to speed faster. This can also be a real time-saver, as I know I've seen more than one webmaster decide to "reinvent the wheel" for their site because they couldn't decipher what the last webmaster was trying to do because nothing was commented.
• You May Not Update Pages Frequently – Chances are there are some pages in your site that don't need updated very often, but you want to make sure that you don't forget what you did on them and why. For example, you may use a content management system but make a lot of changes to customize it for your uses. If you don't document these changes, you may forget why you made them and accidentally change them and lose something. With properly documented code, it's easier to make the appropriate decision for the changes you want to make.
• Comments Make Great Notes – When you are putting together code, you may want to make a change somewhere but haven't decided the best way to do it or you just don't have the time to do all the coding right then. Instead, you can leave comments as reminders to yourself as to what you'd like to do. It's a great practice to get into, and it also keeps you from forgetting to do things that you think of while you're working on something else.

I know, I know…documentation always sounds boring and mundane. Many people even feel that it slows them down in their work, but any good programmer can probably tell you about how much time they've saved in the long run by taking the time out to complete their documentation when needed. If there were ever a lesson to take from the corporate world of software development, it's this one!

This week, Google Labs has rolled out their new tool, Google Trends. What this tool allows is for you to enter a set of search terms and see their popularity over the last few years of records. It allows us to see trends that we may not have otherwise been able to see.

Some interesting trends:

• Church Fellowship vs. Evangelism
• Preaching Focus
• God vs. Money
• Gifts Are More of a focus than Tithes or Donations
• Major Religions (by faith, book and building)

It's very interesting to see the trends of what people are searching on and placing their focus on. Check it out on your own, and you may find new ways to reach out to people.

Well, this year's Internet Evangelism Day (IED) has come and gone, and I'd like to get a sense of how it went overall.

1. What did you or your church do for IED?
2. Did you make any special changes or post information on your website about IED?
3. Did you think it made any difference?

For the recap at my church:

1. Unfortunately, a large portion of our congregation is not web savvy, so we simply included a brief announcement about IED and what it was all about as a part of our service. We also already had a Spring Brunch planned for the day, so IED was definately not a focus.
2. As for our website, I rolled out a new layout for the site that is much more professional than our last version. It's also easier for our pastor to use, so I have been trying to encourage him to make it more of a focus for our announcments and scheduling. As far as anything specific on the site about IED, we did not post anything. However, here at IJHAW, I've kept the IED banner flying for the better part of the last few months in anticipation.
3. It's always hard to judge the impact of the little things we do, but I did notice some eyes opening up when we mentioned different ways to use the internet for evangelism during our IED announcement. So many times we use the internet for useless things, it was nice to see some people respond to getting that first thought of it as an evangelism tool.

It may not have been a momentus change, but I'm more than happy enough to plant the seed. After all, if we don't at least plant the seed, then nothing can ever grow.

For those of you who didn't make your way to IJHAW via the article, I wanted to let you know that I had an article featured over at Church Marketing Sucks, a prominent website dedicated to making the church matter (and if you wonder about or question their provocative site name, you should check out their explanation of the choice here). You can check it out at the link below.

4 Questions About Church Websites

It was definately cool to have my work featured elsewhere.

And if you came to find us through that article, I encourage you to leave me a message in the comments below. It's always nice to know if you've made an impact with others!