I’m currently in the midst of a flurry of activity as I try to get as many things done as possible before we leave for Japan next week. Most of them are work-related — getting projects to a good stopping point, writing documentation so others can pick up where I left off, etc. — but there are several “personal” projects that I’m also in the process wrapping up.
At the top of the “personal” list is the website for Redeemer, the church plant that Renae, Simon, and I are a part of. When we — myself and others in the church — started working on the website, we had pretty grandiose ideas. But honestly, we bit off quite a bit more than we could chew, and as such, the website kept getting delayed. So a few weeks ago, we decided to just take a step back, move everything that we’d been working on with regards to the website to the back burner, and start from a clean slate — just so we’d finally have something other than a “coming soon” page.
And so I’m very pleased to say that the Redeemer website — or at least the first version of it — is now live. In the coming weeks and months, we’ll be fleshing it out a bit more, but for the time being, what you’ll see is an extremely condensed, streamlined version of the site.
The first thing you’ll probably notice is that the website is just one single page. I’ve been wanting to do a single page website for awhile now, as I find the approach comes with a few interesting challenges of its own.
It requires a slightly different way at approaching the design because each pixel means so much more. You can’t just assume that this graphic or that piece of content can be moved to another page because there is no other page. You have to use the space more efficiently — you can’t just cram everything you want onto the page because that will quickly lead to a page that’s far too much in terms of filesize, bandwidth usage, scrolling, etc. You’re forced to strip away all of the inessential stuff, in terms of both the content and design, so that the final product isn’t too cumbersome and find different ways of presenting the content.
For example, I’m using a slightly modified form of the jQuery UI’s tab functionality to display the ministries. Clicking on the ministries menu will display each of the ministries in the same space, allowing the user to quickly cycle through the content. In essence, you’re condensing a whole section’s worth of content into a single space.
Of course, there are trade-offs. If someone wanted to a bookmark a particular ministry’s “page”, it’s possible but a little more involved than simply hitting Ctrl-D or Command-D in their browser. And the scrolling isn’t perfect. If someone has a big monitor and/or expanded their browser window, than scrolling down to the “Get Connected” section might be cut-off due to the amount of space available for scrolling (try scrolling down the website with your browser window set to different heights to see what I’m talking about).
But there are always going to be trade-offs, that’s just the nature of web design. And you always have to evaluate which trade-offs are acceptable to make in order to reach your final goals, be they getting a website launched quickly, building the foundation for future website growth, getting information out there in a timely and efficient fashion, or some combination thereof.
And of course, the website is running on ExpressionEngine. For example, the photos in the upper-right corner are managed by the photo gallery module. The list of ministries is coming out of its own weblog, and the other pieces of the website are individual entries in their own weblog as well. Which, IMHO, is yet another testament to EE’s flexibility.
Want to ensure Opus’ continued existence and get special perks? Become a supporter today. Your contribution helps offset the cost of running Opus.
I've also written for Christ and Pop Culture, ScreenAnarchy, Filmwell, and Christian Research Journal. I pay the bills by creating beautiful user interfaces and websites for Firespring and Red Bicycle.