Key Site Concepts: Utilization

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!