8 Web Site Design Q&A with The Church at Brook Hills’ Gene Mason

Great insights!

One area of disagreement, however. A content management system is helpful to churches precisely because not everybody has the time, skills and other resources necessary to build and maintain a nice looking site. In my experience, it is a lot easier for church staff and/or volunteers to manage the tools offered by most CMS providers than it is for them to figure out Flash, GoLive, etc. Not to mention the fact that these software packages can be pretty pricey.

And the vast majority of churches in the US are not anywhere near the size of The Church at Brook Hills. They don’t have a communication staff. Most are blessed just to have a pastor and a part-time secretary.

CMS providers offer efficient, cost-effective, highest-quality solutions for most churches.

Gene: We invested $100 in a content management system that works flawlessly for our needs. You might have heard of ExpressionEngine.

As Digital Pastor, it is my sole responsibility to create and maintain the various web identities of our church. However, it is impossible for me to manage each and every section of content on our sites. Therefore, content management systems help us communicate more effectively and more quickly by empowering church staff and ministry leaders to make changes to web content. Of course, each “moderator” is approved to handle communicating at this level, but it’s an excellent and productive way for us to publish.

For $100, we implemented an incredibly extensible, powerful CMS that adapts to suit our needs on the fly. And for pages that need more structure, the system allows me to lock down style and presentation to pixel-perfect degree.

I’m glad to hear you aren’t completely against managing content dynamically, but I’d also encourage you to consider the benefits for your communications team as well. Why build code just to publish a new page or rebuild code to modify an existing one? It’s much more simple and more productive to build that code once when implementing a CMS and then allow the power of the system to go to work for you when making changes to the site.

Cool. I think whatever works best for all folks involved is the right way to go. So I certainly can’t dispute your process. After all, it’s yours—and only you can know what’s right for you, your team and your content.
That said, it sounds like you’ve been burned by a CMS (or two.) I can agree that most “stock” content management systems won’t solve every need out of the box, even though so many systems claim to do just that. Other systems (especially those heralded as “commercial”) can be an absolute nightmare to maintain and use simply because they have bloated feature sets, poor UI and complex functionality. Those systems can also be atrociously expensive. Trust me, I’ve been there too.

But systems that are created with a simple focus, small footprint and extensible frame can be a powerful solution with some effort. It will take an decent investment of time to structure such a system at the onset, but in the end I believe that time will be made up in future development budget and time. You just have to find the right system.

You are right though. A $100 system is usually not the complete solution and it wasn’t in our case. (Although ExpressionEngine is ready to rock right out of the gate, it isn’t until you flex it’s muscle that you really see the power of the system. And once you see that power, you want to put it to work for you.) I probably invested about 150 hours in developing the system that powers theaterchurch.com—much of that was learning EE’s tags and templating system (I could build it now in a third of the time). There is some dev time remaining for two or three small projects that we’re implementing soon as well, but I see the initial investment rewarding us already—and I hope future projects are just as rewarding.

I can also imagine that a site as heavy on content as brookhills.org must be quite daunting to maintain and perhaps even more daunting to think of converting that much data into a CMS. But 2,500 pages is quite manageable by a standard PHP/MySQL-based CMS and there is even more overhead and power in a PostgreSQL environment.

Languages can be handled with EE. Again, there is an investment of time to develop the back-end properly, but if done right it can be strikingly successful. In our case, we’re launching a Spanish service in February and we’ll have a distinct URL and site structure for cineigelsia.com. However, all content will be managed from within one installation (and database) of EE allowing us to bring our English data into a form for immediate translation to Spanish on the publish page of the administrative control panel. This simply means, our translators insert their content into the same “place” as our English content, except their data is delivered to the Spanish site. Some strucure will change, so not all page administration will be “side-by-side”, but for the most part it will be as such. (About pages, etc.)

I’m not sure what you mean by “tree structure” other than standard sitemaps that often follow a tree structure. I’m also not sure what you mean by “popping from link-to-link-to-link”. I assume you have some simple dynamic system in place that lets you call up certain links, perhaps based on relevance, to another page or article. If that’s the case, it should be manageable by a good CMS. But if you already have some system in place, you could even find a CMS which will adapt to your system of linking so that nothing really changes. The meta data dynamism would work the same way. Keep your existing library in place and embed that information based on any number of variables (site section, page author) or even page-to-page if you prefer.

But even if your current system could be adapted to a CMS, it’s still your call whether it would be worth the investment. I can only say it has been for us. And in every other site I’ve built it’s been worth the time and energy as well. In fact, I hardly ever build a static site anymore—and when I do, I always leverage the power of dynamic middleware (in my case, PHP) and I usually end up going back and implementing a full CMS anyway. Just because it’s that easy and it’s worth it.

I’m not sure if EE will blow you away as it did me, but I’m happy to arrange a virtual meeting with you to show you what’s under our hood and how I’ve built the basics of our system if you are interested.

And I should mention, I’m certainly not trying to duke it out with you over this issue. I mean, I’m no expert on anything. I’m also not criticizing your approach to content management. Again, you know what’s best there. I would simply encourage you to avoid over-generalizing the current state of content management. Don’t disregard the power and efficiency that a well-written CMS can provide, especially if such thoughts are based on past experiences with less-than-savvy systems.

I didn’t see any poking. So you got away with it if you did. Thanks for the props.

Yeah, I’m actually planning on implementing an evite system on a couple of our sites now. There are a few PHP scripts out there, but I’m probably just going to build one out. Happy to share it when I’m through if you can run PHP. I’ll post here in case anyone else runs across the thread looking for the same.

I’ll email you to begin our dialogue.