So you’re thinking of doing a complete redesign of your church website.  The theme is dated, the info is out of date, and those 4000kb background images were never good ideas.  That’s right.  It’s time to burn the whole thing down and start over from scratch.

Think again.  Reconsider.  You don’t want to go down this road unless it’s really necessary.  How do you know if you really need to launch in to a full redesign?  The answer depends on what you’re hoping to achieve. In this post, we'll cover six main areas to consider when starting your church website redesign:

1. Do You Really Need a Church Website Redesign?
2. Defining Your Audiences
3. Selecting a Platform
4. Understanding Basic HTML
5. Understanding CSS
6.  JavaScript with jQuery

Part 1:  Do You Really Need a Church Website Redesign?

Should you redesign to attract new members?

If this is your goal, you probably don’t need a redesign.  Websites don’t attract new members by themselves, and so often this particular rationale comes out of a situation where a congregation has lost touch with its surrounding community.  Visitors aren’t coming in, and those that do visit don’t come back a second time.  The congregation feels like it’s living on the margins of its own community, and often that no one else really cares whether they exist or not (often this is actually more or less true.)  A website will do precisely nothing to help with this scenario.  Instead focus the time, money and energy you might have put into a website into looking at your surrounding community and figuring out where your church can help meet people’s needs.  In the long run, it’ll build a better foundation for outreach than a website ever will.

Having said that, there exists a point where a congregation is well plugged into its surrounding community, but needs to take the next step.  In this scenario, a website can help make the various ministries of a congregation known in the community.  Give consideration to other options, such as social media (particularly Facebook Pages), but a website it almost certainly a piece of the solution here. If you're at that point, here are some additional articles to help you reach visitors:

• Basic Church Website Components to Help Visitors
• Prioritizing Church Website Content for Visitors

• Creating a Welcome Email Series to Follow Up with Visitors

Should you redesign if your current church website looks bad?

Unless your site is from 1997 and looks like something fresh out of Geocities, you probably don’t need a full-on redesign.  A re-theming of the colors and navigation, perhaps a bit of freshening up the content and you’ll be in pretty good shape.  Depending on your audience, your site may be better off simple and easy to use.  If most of your visitors are congregation members looking to find out what they’re supposed to bring to Sunday’s potluck, you probably don’t need parallax scrolling and a full Angular backend.  Learn a little CSS, make a backup of your current site, make a second backup and put it on a different computer, then begin working on how you can update your current content with some simple CSS work. 

It's entirely possible, though, that you actually do have a site hosted on Geocities, or one that looks like it.  You might be able to get away with an update or two, but chances are you’re also feeling the pinch of our next reason, so it’s probably time to look at shifting to something more modern and easy to maintain.

Think a redesign create a place for your members to communicate?

This is almost never a good idea.  Your members already communicate, I hope.  If they don’t, you should probably plan a potluck.  Are they clamoring for a new site to remember to visit every day and a place to move all their existing communication into a less convenient platform?  If not, don’t do it.  Chances are folks won’t use it.  Consider a Facebook group or page instead, if your members are social media savvy.

Should you redesign because your current website is hard to update?

This one’s legit.  If there is one phrase that strikes fear into the heart of every web developer I know, it’s “We designed for Internet Explorer using Frontpage.”  If there’s another one, though, it’s “Our existing website was done by a volunteer/youth group member/someone’s kid/etc., but they’re gone now and we don’t know how to update it.”  That’s almost a certain guarantee that you’re about to face a ton of spaghetti code, unmaintainable code base and a lot of sleepless nights.  It’s time to stock up on caffeine.  Unfortunately, this is where a lot of congregations find themselves, and it inevitably puts them in a difficult situation.  Kids and youth grow up and move off to school (where they hopefully learn how to code properly), volunteers come and go, and congregations often don’t have a ton of folks who are willing and able to work with back end code.  And so the website goes unused, and an out of date website is really worse than no website at all.  I’ll talk about selecting platforms in a future article, but unless you’ve got a full-time staffer with web development skills, chances are you’re needing to move to a Content Management System (CMS).

Using the ADDIE process

All right.  I can see you’re set on this thing.  So how do you even begin?  What kind of process should you use?  Notepad or a graphical editor?  What are web safe colors?  Why is lime green always a bad idea?  In the rest of this post, we’ll look at web design using the ADDIE process:

• Analyze
  • Defining Your Audience and Message
• Design
  • Choosing a Platform
  • Understanding Basic HTML, CSS and JavaScript
  • Finding Your Way Around Navigation
  • Picking Good Colors
• Develop
  • Writing Good Code
  • Writing Good Content
• Implement
  • Testing Your Site and Why It Matters
  • Getting Noticed
• Evaluate
  • Analyzing Your Analytics
  • Feeding the Beast

Any good communication plan starts with an audience analysis.  While it’s tempting to start by asking, “What do I want to say?”, it’s precisely the wrong question.  It’s far better to start with, “Who do I want to speak to and what do they need to hear from me for them to make the choices I hope they will?”  That feels a little manipulative at the outset, but it’s the real question behind most communication.  We tell people what time worship is in the hopes that they’ll show up.  We announce the potluck in the hopes that people come and eat.  We never force, and we generally don’t use guilt to persuade, but we communicate with a purpose.  Anything that gets in the way of unleashing the right response is noise for our purposes.  (For a brilliant presentation on this, see Kem Meyer’s presentation)

So how do we eliminate noise from our web content?  By first deciding who we’re talking to.  This is probably easiest to see by walking through a case study.

A Web Site Redesigned

When we began to redesign the seminary website, our first meeting involved setting out a list of everyone who presently visited our website and what they came there looking for.  I’m sure we weren’t exhaustive, but I’d bet we hit 90% of our audience.  From there we looked to see if there were natural groupings to begin to define audiences:

We immediately realized that nine audiences was too much for any single communication medium, so we  decided early in the process to split the audiences into internal and external communication and to group several similar groups by the content they were consuming:

Armed with this structure, we mapped out the content which would go on our internal site, which would require a seminary login to enter and which content would go on the main website.  Here we resisted the urge to simply take all of the old content and lump it by internal/external audience.  We knew that we had important information that wasn’t on the website, and we knew that we had pages that had been out of date since the time of the Apostle Paul, indicating that the information they contained might not have been frequently used. 

Instead we visited each key stakeholder (in our case, campus departments) to discuss which of these audiences they communicated with in a regular way and what each audience needed to hear from them.  For each audience we determined the content we already had and which content would need to be written or rewritten.  Because we also wished to unify the seminary’s branding, we also made note of which logos were in use by the stakeholders and which would need to be created to fit the new, simpler look of the seminary logo. 

Potential Challenges

The most common challenge you’ll encounter in this process is when your stakeholders don’t have a clear view of their target audience, or when their target isn’t one that you’ve initially identified.  At this point we need to ask these questions:

• whether this is a legitimate website audience which we haven’t considered and which may need to be refactored into our categories

• whether this is an audience that just doesn’t exist

• whether there’s just some information that doesn’t get included on the website. 

An example of the former category would be the need for alumni to be able to order transcripts.  We’d initially put all of the registrar functions on the internal site, but here we had a very clear case of a need for registrar content for those who aren’t immediately a part of the current campus community.  Fortunately, it fit (sort of) under resources, so we made a subsection of our resources for alumni which included the transcript request. 

The second category, content without an audience, were some of the harder conversations to have.  If an audience wasn’t one of our targeted ones, we had to weight the clutter of too many audiences vs. the ease with which other ways of communication might suffice (or even be better) for that audience.  In some cases that meant helping folks develop a separate web presence and in others it meant just simply not having the content on the page.  Be sensitive as you have these conversations.  The information is important!  It may just be that the website isn’t the right place to communicate it.

Part 3:  Selecting a Platform

What is a Platform for a Website?

When you’re creating a website, you have a few key things you’ll need to decide on.  Since we’re redesigning in this series, we’re going to assume you’ve got a webhost, hopefully a domain name and can probably install a few applications with your hosting provider if need be.  Once you’ve got the server space, though, you’ll need to ask what kind of software platform you want to build the site on.  There’s a lot of options here, but we’ll lump them into a few key categories:

WYSIWYG Editors                     

WYSIWYG is short for “What You See Is What You Get”.  A number of online hosting providers will offer these sorts of editors.  The advantage with them is that they tend to be pretty easy to use, allow you to see what you’re making as you’re working and that they’re pretty quick to work in.  Unfortunately, they also tend to come with very limited theme/style selections, and incredibly limited customization options.  As long as you intend to fit one of their stock templates, they’re workable, but go much beyond that and things get more difficult.  They also can produce some pretty ugly code in the back end, so not all browsers may render your site properly. 

CMS Systems

CMS stands for “Content Management System”.  This category includes things like Wordpress, Drupal and other software systems that allow you to easily edit content while providing a framework for doing so that doesn’t involve getting your hands dirty with the actual code (most of the time).  They’re very flexible, but require more expertise to set up than WYSIWYG editors.  Advantages to CMS systems include the nearly endless selection of themes and plugins, along with the ease of editing from within a pretty easy web based interface.  They do, however, have their limits.  If you’re looking for a very specific look and feel to your site you might have some difficulty getting the CMS system to reflect your exact vision.

Raw Code

Raw code is not for the faint of heart.  Here we’re talking about how most early websites (and may high end ones today) were made.  You’ll end up with a pile of HTML, JS and CSS files which require some technical knowledge to understand.  (More on each of those in a future article.  You’ll need them regardless of which path you take, but raw code requires KNOWING them, not just being able to edit them.)  This is a great path if you have a web development professional who’s willing to donate his or her time to maintain the church website, but most updates will require some specialized knowledge.  It’s nice to have the exact look you’re after, but the costs in flexibility of editing and maintenance generally mean this path isn’t worth it.

Part 4: Understanding Basic HTML

A Tiny Bit of History

There’s a few of us old folks around who still remember using computers during the infancy of the internet.  This is back when you had to carry the packets uphill both ways through the snow, but the bigger challenge was that you didn’t have easy ways of connecting documents to one another.  You could have a menu system (often a Gopher system), but you didn’t have images, and linking ideas together was tough.  How could you format and create connections between documents when all you could work with was pure text?

The solution came in the form of HyperText Markup Language or HTML.  Rather than fundamentally change the files, researchers elected to use special text to tell the program how to format and link to other documents.  So, for example, you might have wanted to underline a specific passage, so you would surround the text with “<u>” and “</u>”, the start and end tags (respectively) for underline formatting.  A basic set of tags emerged and HTML 1.0 was born. 

Skipping a Bit

While we could work through the changes that came with later versions of HTML and XHTML (eXtensible HTML), the reality of tech work is that in general it’s only the newest version of the standards that really matter.  Thus we’ll spend the rest of this article taking a look at the state of HTML5 today and giving you some of the basic tools and understandings to know how to read HTML5 for yourself.  This is NOT intended to be a comprehensive introduction, and you probably won’t walk away knowing everything you need to code your own web page, but you’ll get the basic concepts.  If you want to dig deeper, check out W3Schools for some great tutorials.

That doesn’t mean it won’t be useful for you if you’ve gone with a CMS system or similar.  Knowing basic HTML can help you format posts and pages properly and even make small tweaks to your overall design, albeit with some fear and trembling.

What is HTML For?

In the early days HTML was all about formatting and linking content.  Today it’s all about making documents make sense.  So, for example, while the underline tag might have been a thing in HTML 1.0, today we’d leave the styling to CSS (more on that in the next article) and use HTML to identify the navigation (<nav>), a page division (<div>), a link to another document (<a>) or an audio or video player (<audio> and <video>).  By giving HTML the clear job of providing context for our content, we enable the same HTML file to be styled in multiple ways using CSS.  It also streamlines content for reading by screenreaders, and web crawlers.

A Couple of Examples

Perhaps the best way to understand HTML5 is to see it in action. 

Lists

Let’s take the example of a grocery list.  We know it’s a list of items, so we’ll be using the list item tag (<li>), but we need to decide whether to use the order list (<ol>) or unordered list (<ul>) tag.  Because your list probably doesn’t have to go in a set order, we’ll use <ul>.  If we start with our list as “Apples”, “Oranges”, “Bananas” and “Bread”, then our HTML content will look something like this:

<ul>

<li>Apples</li>

<li>Oranges</li>

<li>Banana</li>

<li>Bread</li>

</ul>

(Try this for yourself)

Note that the <li> tags are nested inside our <ul>.  This is because all of the list items (<li>’s) are a part of the unordered list.  HTML objects can contain other HTML objects through nesting.  This is useful if you’d like to use a link (<a>) tag to contain an image or a button.  The entire image or button will then be interpreted as the link.

Tables

Another common markup scenario is creating a table of information.  There was a time in HTML history (known as the “bad old days”) when the only way to reliably layout items on a page was to use a table as the basis for your entire page.  That doesn’t happen today, and should never happen ever again.  Tables are for displaying tabular data.  Suppose you wanted to display your church’s office hours.  That’s reasonably the sort of information that could belong in a table, so we’ll try it that way.  To make a table work we need three basic tags (there are others, but these are the basics):  <table>, which defines a table of data, <tr> which defines a row in the table, and <td> which defines a cell or piece of data in the table.  Our example might end up looking like:

<table>

<tr>

<td>Day</td>

<td>Hours</td>

</tr>

<tr>

<td>Sunday</td>

<td>Worship at 8:30 am and 11:00 am  Office hours by appointment</td>

</tr>

<tr>

<td>Monday-Thursday</td>

<td>8:00 am – 5:00 pm</td>

</tr>

<tr>

<td>Friday and Saturday</td>

<td>Closed</td>

</tr>

</table>

Part 5 – Understanding CSS

In the bad old days of the web, users had to specify the formatting for every page and item on the page in the HTML tag.  This worked, but it led to a lot of repeated code, and it made changing your site’s look or design an absolute nightmare.  (In fairness, designing a site was a bit of a nightmare, so it evened out.)

Essentially the early web made the mistake of mixing content and formatting into a single file.  In good programming practice, content should be separate from display and both should be separate from behavior or interaction.  (More on that part when we hit Javascript.)

The Solution: CSS

That’s where CSS came in.  Short for “Cascading Style Sheet”, CSS allowed site designers to separate their content (HTML) from the way it would be displayed (CSS), and even to have different displays depending on the device being used.  In fact, the same HTML could look wildly different depending on the style sheet used, as the CSS Zen Garden project aptly demonstrated.

Additionally, because a single CSS file could be used by any number of HTML files, a well written site could be completely redesigned just by updating a single CSS file, and the changes would cascade through all the pages of the site. 

CSS Selectors

A CSS file consists of a number of CSS selectors, which define a part or parts of a web page and the rules that apply to those selectors.  We’ll start by understanding what selectors can do.

The simplest type of selector is the HTML tag selector.  Simply put, this applies its rules to every matching tag on the site.  So a “p” selector would define the formatting for every paragraph tag on the site, as well as any child elements, including spans, etc.  This is most often seen when formatting the <body> tag to define the base text colors, fonts, backgrounds, etc.

More useful are class selectors.  By adding a class to your HTML element (such as <p class=”announcement”>), you can use the class name preceded by a dot to select all elements of that class.  In this case, we’d use “.announcement” to format our announcement.  Remember, “In CSS, dots have class.”

If you’re really trying to hone in on a specific element, though, you can assign it an id and select it that way.  So you might, for example have a <ul id=”mainNavigation”> that lists the main links on your page.  You could then select it using the hash symbol, like this:  “#mainNavigation”.  Apparently “In CSS, hash doesn’t have class, but it does have Id.” 

There are, of course, many other ways of selecting elements in CSS, but these will do for a start.  For more advanced selectors, see the W3Schools tutorials.

Adding Some Rules

Once you have your selector, it’s time to apply some rules.  Rules go inside curly braces, “{“ and “}”.  There are CSS rules for pretty much any sort of formatting you could want to do, but the trick is knowing the right keyword to use.  Most are pretty intuitive, such as “background-color:” or “font-size:”, but some are less so, such as the vague “color:” and the obscure “font-variant-ligatures:”, which I don’t think I’ve ever used.  For a full list, again, W3Schools is a great place to start.

Each rule has a set of valid values, which go after the “:”.  You’ll have to experiment a bit to get the exact values you want, but there’s a lot of power here and you’re not likely to break much, so experiment a bit on your test copy of your website.  You do have a test copy of your website, right?

A Couple of Examples

So let’s say that we wanted to create the world’s ugliest, least user friendly website.  We could just go sign up for Geocities, but it’s far more fun to use CSS to make our own.  We’ll go with a bright green background and some nice white text for “ease” of reading.  In CSS that looks like:

body {

               background-color: #00ff00;
               color: #ffffff;

}

No truly hideous site would be complete without the abuse of fonts, so we’ll set the font family to attempt to using Comic Sans:

body {

               font-family: "Comic Sans MS", “Comic Sans”, cursive, sans-serif

}

This attempts to use “Comic Sans MS” if it’s on the user’s machine, then looks for “Comic Sans”, then falls back to a generic cursive font if not, and finally fails to a simple sans-serif font.  Notice that we reused the body selector.  In a real development environment, we’d combine those into a single CSS selector with three rules.

Finally, let’s add a heading and see what happens if we play with the text directions:

h1 {

               text-direction: rtl;

}

This should ensure that no one ever visits our site ever again.  (All we need is a marquee, a blink tag and an autoplaying video and we’ll have committed every design sin on one page.)

Want to try a terrible site?  Try it yourself! (click "Run")

Conclusion

That’s a whimsical example, but hopefully you get the ideas behind how CSS functions enough to begin making small changes to your templates or websites.  By editing code that already exists you can begin to learn how the different elements interact without having to build the entire foundation from the ground up.  It’s easier to hang a door than to build a whole house, so start by making changes to something that already exists.

Part 6: JavaScript with jQuery

While HTML does content and CSS does formatting, JavaScript does interaction. If you’ve ever been on a site that reacted to where your mouse pointer moved or that allowed you to view new content without visiting a new page, you’ve probably encountered JavaScript.

JavaScript is a programming language based on ECMAScript, and it’s used on almost every website you visit. This article will NOT teach you JavaScript. Explaining JavaScript is beyond the scope of a blog post, and it will likely take you some time to learn the language. If you’re interested, though, I suggest some of the excellent tutorials at w3schools (free), codeacademy (paid), and, if you’re really serious about learning JavaScript, O’Reilly’s rhino book.

What Will I Learn Here?

Instead of focusing on learning all the ins and outs of JavaScript, we’ll focus on a very specific, very powerful library called jQuery. Like with many things in web development, though, we’re only going to be able to scratch the surface. We’ll look at how to use jQuery to manipulate your page in response to user actions and some basic methods for making your pages seem a bit more alive.

What Should I Know Before I Start?

You should know your CSS selectors pretty well. If you need a tutorial, see the previous article in this series. You should also understand that programs operate sequentially, which means that they execute one statement before moving on to the next. (Exceptions to this exist, especially in the realm of threaded applications, but they’re far more advanced than the scope of this introduction.)

Getting Your Head Straight

The first thing you’ll need to do is include the jQuery library in the <head> section of your page or template. You can do this easily by adding this line to the end of your <head>:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>

Making Things Do Things

Here’s an example. Let’s say we have this HTML snippet somewhere on our page:

<button id=”MyButton”>Blackout!</button>

As it stands, we’ll get a button, but the button won’t actually do anything. Let’s make it do just what it sounds like; we’ll change the background color to black and the text color to black as well.

The first thing we want to do is select the button we’re going to attach an action to. To do that, we’ll use a special jQuery function called $. Yes, in Javascript, “$” is a valid function name. (Experienced programmers may take a moment to weep, if needed.) In any case, $ is a function that essentially means “find this CSS selector on the page and return all elements that match”. So $(“body”) will select the main <body> tag. $(“p”) will select all paragraphs. $(“.MyClass”) will select all elements that have the class attribute “MyClass”. Basically, if you can use it in CSS, you can feed it to jQuery and get back what you’re looking for.

So let’s start by selecting our button.

<script type=”text/javascript”>
     $(“#MyButton”)
</script>

Having selected the button, though, we actually have to do something with it. We’ll use a method called “click,” which activates when the element is, well, clicked.

<script type=”text/javascript”>
     $(“#MyButton”).click()
</script>

Note that if you try this, you’ll get an error. That’s because .click() requires a parameter, which is what we want to have included when the element is clicked. To send that info, we’ll use an anonymous function (a function that we never bother to name). It ends up looking complicated, but just know that it means “when this element is clicked, execute this function”.

<script type=”text/javascript”>
     $(“#MyButton”).click(function() {
          $(‘body’).css(‘background-color’,’#000’);
          $(‘body’).css(‘color’,”#000 !important);
     }
</script>

Notice the use of the “css” method to change the document’s CSS rules on the fly. This can be used to resize or even reposition elements based on user input.

Phenomenal Cosmic Power . . .

There’s a lot you can do with jQuery, but there’s a definite investment of time in learning how the different methods work. You can see the current list of elements in the library at https://api.jquery.com/. The best way to learn jQuery is to experiment a little bit, and feel free to reach out to me if I can help with a particularly tricky function. Next time, we’ll move on from some of the techy pieces and focus instead on how to create good navigation for your audiences.

Learn more about how to create an excellent church website with our free ebook!