Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

At the right time, provide the right information

Mandatory reading, an article at Boxes and Arrows entitled “Ten Quotable Moments: Challenges and Responses for UI Designers.” If nothing else, but for the following quote:

“Interfaces don’t become simpler by hiding information and requiring more clicks; they become simpler when they provide the right information at the right time.”

And all the congregation said, AMEN!

There are many more notable quotables in this article as well. I suggest printing it out, putting it aside, and taking it with you when you make your daily trip to the ‘reading room.’ Not because it belongs there, but because the article is SO ON TARGET for church web sites that it requires your undivided attention. Mine often occurs in the privacy and solitude of the water closet. But I digress.

The point here is not potty humor. The point here is not hiding your light under a bowl of insidious navigation. This is especially true for many FrontPage generated sites I visit. Pertinent information that is buried so deep that no one knows its there. Then in an attempt to bring it forward, I’ve seen church web sites resort to scrolling marquees, pop-up windows and putting links to everything at the top level of the web site. All of which is as equally defeating as hiding the good stuff.

This was one of the compelling reasons for some of the design decisions I made with the redesign of Redland Baptist. The original front page was a nice picture, and a DHTML hierarchical menu. Upon looking over the user base, it was clear that one of the compelling reasons people wanted to visit the site was to find out when things happened, and how to get there. Hence, if you look to the left, above the fold, “Getting There: … ” and “When it Happens: …,” the former with our address and links to maps and driving directions, the later with the services schedule and a link to our calendar of events page.

Similarly, I took a more “blog” approach to the front page, where we include time-sensitive information from our “Items of Interest,” which depending on the content, may have links to other pages on the site, such as Missions or Vacation Bible School. Finally, I added a DHTML-based drop-down menu which essentially enumerates every page on the site. That said, I still need to generate a site map.

On the sub pages, I use the left column to list the titles and links to the other subpages within the same category. The thought being here is that those who wish to explore what Redland Baptist is about, are given the pertinent pages at the right time. I also make sure the overview page offers links to our Sermons page, which essentially exposes our theology, and our Music and Youth pages, which identify our two other big ministries. In fact, all of our major ministries can be reached by use of subdomains, such as youth.redlandbaptist.org and music.redlandbaptist.org as a further aid to navigation. That said, I still need to modify the navigation for the Sermons page, as I want to list related sermons whenever you’re reading a particular sermon within a series (so little time, so much to code).

Finally, you’ll notice a little icon on the subpages back to the home page. A search box on the left navigation column. Breadcrumb navigation. The DHTML menu at the top, and text links of the major categories and some other featured information at the very bottom. Or what I like to call, suspenders and a belt navigation. Hopefully, while complex in design, it is simple in use. Or from the aforementioned article, hopefully my approach answers the following concern:

“I’m suspicious that these users will ever be able to figure out something that isn’t instantly clear to me, especially something with a complex implementation.”

In other words, despite the old programmer’s adage “if it’s hard to write, it should be hard to read …,” what we really need to strive for is keeping the interface as intuitive as possible, while offering the most relevant links at the right time.

One Comment

  1. Strange conversation found in the comments to that article though. The author actually recommends (if I’m following it right) to NOT make an active tab obvious on a site featuring tab-based navigation because “a tab that calls
    attention to itself will be somewhat tiresome”. and “Calling attention to the active tab, the one you can’t click on, would invite people to click it anyway.”

    Yeah, let’s camoflauge those street signs so they’re not so “tiresome” calling attention to themselves all day. Hooey.