Michael Quin Heavener

Search: 

Building a better website

Tutorial on redesigning websites to meet organizational needs

. Screen capture of Redmond UMC home page
 

.
Image rollovers on Redmond UMC's home page
allow glimpses from the outside into our
sanctuary even when scripting is disabled.

.

As the Redmond United Methodist Church webmaster, I've worked closely with a select group of leaders to teach them what websites in general, and our church's site specifically, are doing to enhance organizational and programmatic growth.

I willingly took on a role no one else seemed to want—rebuilding/redesigning the church's antiquated website to meet the changing needs of our programs, of the congregation as a whole, and of our greater community. Though I served as a volunteer, the process took all of my professional, creative, and diplomatic skills.

I believe the end result is worth the effort. My intent for taking on the task was not only to create an attractive new interface that engaged visitors but also to prepare the website—and the church leadership—to better communicate now and in the future.

[Ed. note: For an update about this website's disposition, see the pop-up.]

The goals for the 2006 redesign of the Redmond UMC website were:

  • To create a website that promotes our church, explains our programs to the community, and encourages outreach and missional ministry in the community.
  • To give the congregation a place to look for information about church programs, activities, events, and issues.
  • To push content development into the hands of the committees, work area chairs, and program volunteers.
  • To create a site simple to navigate, yet rich enough to attract visitors and show them what RUMC means to them.
  • To be flexible enough that new pages and new content could be added at any time.
  • To make the site's upkeep a team process so no one person is chained to it.

Colorful history

The website had a checkered history of benign neglect. It was started in the late 1990s by one of the church leaders as a way to keep his son active in the church youth group.

Another of the church's young members took over the website and used it to teach himself Active Server Pages (ASP) so he could apply for (and get) a job as a web developer. For his own purposes, he stored all his working files—several dozen megabytes—on the RUMC server. His intent was to publish church member data using SQL and Access (more on this).

Unfortunately, his involvement in the church did not last long and the website was, more or less, abandoned. The only other person with access and password was the pastor, and he was only interested in publishing his sermons each week. The site languished and data grew stale, out of date.

Finally, after visitors complained about dates and times being wrong for services and events, I was asked to "fix" the website. I looked at the ASP code and all the developmental files on the server and determined that most of it was garbage.

Security risk

At the same time, I started asking about the intended database and what security was to be provided to prevent member data from falling into the hands of spammers—or worse, youth data being used by stalkers and predators. I watched as bells went off.

I recommended that the church not publish member data until we had better control of the website and could establish guidelines for implementing security systems that would lock the database to prying eyes.

The internet service provider (ISP) became an issue and change was obvious. When I investigated, I discovered the church was paying more every two months for hosting than we should have paid an entire year.

During migration to the new hosting program, I simplified the ASP into straight HTML and removed the excessive file overhead. The church's leadership, primarily the outgoing pastor, were still not committed to exploiting the full promotional value of the site.

With the new pastor, the site took on new meaning. Pastor Robert Henre was supportive of my attempts to focus the RUMC site on three goals. With his blessing, I embarked on a redevelopment process.

. New exterior photo of Redmond UMC
 

.
After 18 years, we have a new exterior
building photo and, finally,
an interior photo of the sanctuary.
.

  Interior photo of RUMC sanctuary
 

.
Photos © 2006 Hannah E. Heavener.
All rights reserved. Used by permission.

Gathering input

The first step was to seek advice and suggestions from RUMC's leaders—what would they like to see on the website that would help them do their jobs … help them explain what they were doing.

Once the input was analyzed, I created a test site that was nothing more than a long wish list that I asked the leaders to browse and add, subtract, or modify. When people complained the list was too long and unfocused, I developed a DHTML hierarchy that allowed them to click open their specific sections.

During this first review period, I experimented with several JavaScript-driven user interfaces. There was a yellow/red one, a brown one, and—at the pastor's suggestion—a blue one. Some usability testing was done informally, and the blue site was selected.

As comments were received from the reviewers, I added them to the test site. During this period, I created a "page" for each page I anticipated the site, using page-shaped rectangles with the work area content items. The review comments were boldfaced and I added explanations where needed to addresses comment issues.

The review helped give the site a stronger congregational focus.

Creative interface

During the comment period, I began developing the user interface for the site. I wanted the initial reaction to be "gee whiz!" The church office uses a postcard of the exterior of our 1987 sanctuary addition to remind members of meetings and activities. The photo is dated by the spindly trees, which 18 years later have grown taller and filled out, blocking more of the facility from view.

Since my daughter, Hannah, is studying photography, we decided to take a new exterior photo and supplement it with an interior of the sanctuary (needed for her architectural photography class).

Putting the two photos together on a light box convinced me to do a "rollover," where running the mouse cursor across the exterior photo causes it to reveal the interior photo. At the time, the church had five program areas—so I sectioned the photos into five slices.

Rolling picture

The first implementation used JavaScript to produce the rollover effect. The problem with JavaScript is that it can be turned off by the end user, which would ruin the effect and might cripple the page at an awkward moment at loading.

A conversation with a co-worker, however, resulted in his suggesting the effect could be duplicated using only cascading style sheets (CSS). His rollovers worked even when he forcibly turned off script support in his browser. They also worked in Firefox, another influencing factor.

I took his demonstration code and applied it to the website. At first, it performed too slowly to satisfy the office staff (the church was using dial-up at the time). So the co-worker helped me optimize the CSS and code.

The toughest part about doing the rollovers with CSS was the upfront prep needed in Photoshop. The JavaScript rollovers popped up different images based on the presence of the mouse—simple slice and save development. The CSS version moved each image's visible half a fixed negative distance (to the left) to reveal the hidden half.

In other words, each of the six slices had to have the exterior on the left and the corresponding interior on the right. I discovered Photoshop 6.21 (I haven't upgraded to CS yet) has a one-pixel inaccuracy margin. Too much caused a thin black line to appear between the slices; too little caused a thin white line.

It took nearly four hours to get exactly the effect I needed. Part of that time was lining up the Photoshop text so it didn't jump around when the rollover triggered. Many layers and multiple interim TIF files later, the website had its desired interactivity.

Some scripting remains

There is still JavaScript on the site to maintain the interactivity and keep visitors interested. But the main sectioned photo, and excerpted slices on the program pages function no matter what browser is used and when scripting is disabled. The other scripts degrade to a statement that appears on pages advising that some functionality is not available.

The biggest loss of functionality is that email addresses disappear. To prevent them from being harvested by spammers, I use JavaScript to concatenate the address components—see my blog entry at Wordpress.

Flow chart/site map of RUMC website initial phase implementation .

.
Simple site map reveals some
interesting operational complexities
that kept the website on hold until
the church restructured its programs.

 
.

Programs changing

The other major issue with the test website was that certain program elements refused to fit where I was trying to shoehorn them. They fought back. The website was paralleling our actual experience trying to operate the church with programs in the same managerial framework. The website was merely mimicking our spiritual life but none of my reviewers nor I knew it.

Church leadership was responsive to these needs and had already embarked on a re-invention process based on Alice Mann's book Raising the Roof. As I was working on the test website, they were working on a new "roadmap" for the church.

When the roadmap was unveiled at a church potluck/conference, I took one look and knew it was perfect to restructure the website's architectural backbone. The end result was six … not five … rollover slices, corresponding to the five program elements of Mann's exploratory process plus a support section for the site's nuts-and-bolts.

Multi-phase implementation

The RUMC website is being implemented in phases. The first phase launched the new interface, with its rollovers and handsome color scheme. This iteration does not use menus and is simple to navigate with the text links included for accessibility and to prepare the site for search engine optimization (SEO).

Later, hierarchical JavaScript menus will be added, when section pages become multiple pages with subsections and subpages fleshing out program details. The site map will parallel these menus (in HTML for those without scripting), giving visitors a visual overview of the entire church.

As programs need additional content, the work area leaders will be trained to identify how and where their needs fit into the church overall, and in the website. They will be encouraged to develop their own content. I will offer advice and support but I don't want the website to be a burden to any single person, nor suffer when that person is not available.

Quick implementation

To make this easier, I created a template using Microsoft Word. The template will be distributed by the church secretary as needed. Since Word is a tool with which almost everyone at RUMC is familiar, there should not be any concerns about not knowing how to make websites.

At its heart, the Word document is a single cell table and an abbreviated set of headline, text, and bullet style. When it is returned to the secretary, I can quickly save from Word as HTML—and then paste the table into the website's HTML template, which will be pre-loaded with the necessary scripting and style sheets.

The beauty of this is that I have taught a handful of other "techie" people at the church to do the conversion process. We all know to use the templates and tools I developed, so if I'm not available, the site can still be updated as needed.

[Ed. note: For an update about this website's disposition, see the pop-up.]

 

About   |   Career   |   Creative   |   Faith   |   Family   |   Railroads
Home   |   Portfolio   |   Site Map   |   Privacy Policy

Copyright © 1997- Michael Quin Heavener. All Rights Reserved Worldwide.
DHTML Menu by Milonic