This is the second post in our “What Everyone Needs to Know About Building a Church Website”. Read the previous post here.

On a given day, Tom finds himself doing everything from onboarding new staff with phone, Internet, email, computer, etc., to updating computers with new software releases, to reviewing church data and presenting it to church leadership, to maintaining the ChMS (Church Management System) and troubleshooting problem areas.

Whew! Tom's duties are vast and varied. While there are nuances depending on what type of context Tom finds himself in (e.g. large or small), Tom is a doer at the core of his being.

Being a doer, Tom needs to know what goes in to building the church website.

What Web Geeks Care About

If you're using a CMS (Content Management System), he'll want to know a few things about the platform before getting started:

Control Panel. How easy is the "back end" to work with? What settings can he change from the admin panel itself? Simply put, what can Tom tweak without having to dig into the guts of the system. At the same time, Tom doesn't want something wimpy. The control panel has to be more than just a WYSIWYG editor!

User Roles. In some settings, Tom will be working with other people to ensure the site is running in tip-top shape. Can he easily assign user roles to other people (e.g. admin, editor, user, etc.), controlling the level of content they have access to? (Ekklesia 360 has this nifty little feature.) If Tom is responsible for the upkeep of the site, he wants to ensure any changes made, content or otherwise, are approved by him first.

FTP Access. Tom will want to know if he can work with the site at the FTP level. FTP (file transfer protocol) simply means users who have access can log in and play with files and code at a base level. Think of FTP as mixing the concrete for a house's foundation. Tom digs access, so having the ability to do this is key.

For instance, when Monk clients request this feature, it allows them to edit the files that power the layout and design of their site. (FTP access also provides them access to advanced CMS modules such as Monklets and Templates, which is where things really get fun!)

Codebase Access. Warning: highly specialized web geekery talk ahead! If Tom is of a particular techie type, he'll want the ability to create code he can plug in to your chosen CMS. Officially it's called "application programming interface," or API. Unofficially, it's the ability to take a technology product and customize it to your liking. Think of it as a synergistic online version of "Pimp My Ride". Yeah, like that.

I'm going to throw a few terms under this category Tom also cares about. The first being "proprietary," the second being "open-source."

Proprietary: Roughly speaking, Tom would use this term if he's referring to a company's product. (For instance, Ekklesia 360 is MonkDev's proprietary software.) When a company develops a solution, it's theirs.

Open-Source: When a website solution is open, it means anyone can make changes to it. It's a little more complex than that, but in essence, you can contribute to the development of an open-source solution in one form or another. Ekklesia 360 is a closed system, but there is an API (see above) to let Tom make certain changes if he'd like.

Of course, an open-source solution like WordPress comes with the challenge of maintaining code and upgrades all by your lonesome. We've seen some nasty situations where volunteers maintaing a church's open-source website essentially take it hostage. Ekklesia 360, by contrast, is maintained by our ministry-focused team, letting churches focus on creating great content for their people. 

Conclusion

Tom is a doer. He wants to work with a team to build the best solution possible for his church. These are some the things he cares about. If you work with a Techie Tom, it would be helpful to know

If you do nothing else: What are some of the other technology needs Tom is concerned about?