Building a better website
Tutorial on redesigning websites to meet organizational needs
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 wantrebuilding/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 websiteand the church leadershipto 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:
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 filesseveral dozen megabyteson 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.
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 spammersor 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.
The first step was to seek advice and suggestions from RUMC's leaderswhat 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.
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.
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 areasso I sectioned the photos into five slices.
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.
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
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.
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).
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.
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 HTMLand 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.]