Web Design

Russell Kelfer
Discipleship Tape Ministries
Into His Likeness Bible Studies
Web Design Principles and Objectives

 

Introduction

The design behind this website is not without careful thought and consideration. This document explains my approach and the reasons behind it.

My father was very much "into" the Internet from it's inception. (At one point, the ministry even had one of the first searchable versions of the Bible on the Internet that was linked to his lessons and vice a versa.) At the time of his passing the ministry already had a good deal of his lessons online with more being added regularly. Putting my father's materials on the Internet, however, is a challenging proposition due to the fact that most of his materials predate the Internet age and in fact some of it predates even the computer age. Much of his materials were created using programs that no longer exist, for example. They were not written with the Internet in mind because it did not yet exist. He used many different types of computers and software programs and writing styles over a period of close to 30 years. As I will explain later, this creates some very significant challenges.

Today, nearly 20 years after his passing I have been asked to help with producing a library of his work that will be freely accessible to all people on the planet without charge. I am very grateful to participate in this venture. Praise the Lord!

I have had unique life experience in the area of computers and the Internet that I believe was God ordained to prepare me for just such a task. For a special testimony on that click here.

So, I would like to share some of my thoughts on the best way to go about all this.

Purpose and Basic Objectives

To understand this approach we must first define what the purpose of the website is. From my perspective, this website is meant to enable my father's teachings to reach the entirety of the planet as we are instructed in Scripture to "Go ye unto ALL the world and preach the gospel." The Internet certainly allows you to do that.

The website should allow for a central repository of my father's life's work in a manner that is consistent with the philosophy established for the ministry before his passing. He believed that all materials should be available free of charge. To anyone. Period. This work should neither be abridged or altered in any way. And it should be accessible in multiple formats in order to accommodate as many people as possible.

The site needs to be simple and easy to use. It doesn't need to be flashy, my father was never into flash, just substance. However, the site SHOULD be of high caliber and up to the standards that would bring praise and glory to Jesus' name.

Beyond that, I am designing this website to meet certain other criteria:

1) it needs to work on as many different platforms as possible and be as independent as possible from any third party software

2) it needs to be accessible both on computer as well as other smart devices like phones and tablets

3) where possible, it should be available both on and off-line

4) it should be appealing to a wide audience both young and old, of any race or ethnicity, in as many languages as possible

5) it should be maintainable in the long term

6) it should also be free of errors or any shoddy work

7) it should be able to be thoroughly backed up with files stored both locally and off- site.

There are several types of approaches to website design. Each have their advantages and disadvantages.

Third Party Template Based

The most common form of website design today utilizes templates and third-party backend software. (Think Wix, godaddy) This type of approach is designed primarily for people who do not know HTML and just want to plug content into an already predesigned framework of HTML code. The advantages to this type of approach are that the cost to entry is low, and the end-user does not need to know or understand anything about HTML design. The disadvantages are that the code produced is often quite poor, it is not unique (as in many people share the same template), and it depends upon programs that run on the host owned and operated by a third party. If this third-party fails or goes away, all of your website design goes with it. You are at the mercy of the provider. Furthermore, this approach is open-ended,meaning that even once the design is complete you will continue to pay. It's really more of a lease than an own.

Another problem with this design approach is that it is typically only useful for smaller websites that need to manage only a few pages. The more webpages a website has the more cumbersome it becomes to manage to the point of absurdity. This website is going to cover probably close to 15,000 pages of content when done.

We have already experienced the pain of being tied to a third-party that decided to end it's business. None of the HTML was actually in the possession of the ministry so when the company/host ended it's business, for whatever reason, we lost all our work and were forced to start over.

This brings me to another disadvantage: proper backups. Because the HTML code is being generated by the design host software, there is no good way to thoroughly backup your website. If you simply hit "file-save as" on your computer, the file you get will contain hundreds of references to files and programs you do not have, (and never will), meaning that these files will never run anywhere but from the third- party host. Basically, the only person that can truly backup this type of site, is the host itself.

Third Party Software Develoment

Another common form of website design used by most third-party independent developers, is that of sites designed using third-party programs running on someone's computer. An example of this would be sites created using something like Adobe In-Design. There are a number of software programs designed to operate in this manner. The end-user does not need to know all of the intricacies of HTML or website design (although they generally know a bit more than the average site owner). This approach does allow more flexibility for users who understand a little bit of it but at the end of the day it's still a program that's generating the code.

There are pros and cons to this that we will get into later. One of the biggest disadvantages to this approach however is that it requires these third party software programs to maintain and edit. The code generated is often convoluted and not easily human readable or maintainable. Most of the time, it will not even validate without error. And every software produced website has limitations imposed inherently by the software app design itself.

Server Scripted Data Driven

Another form of website design mixes HTML with what's known as backend server scripting. (Most template sites mentioned above like WIX are actually using this method to deliver their services). In this case the HTML files don't actually exist in the real world. They don't actually exist on disk anywhere. Instead, the all content is actually stored in databases. The content is "data-driven". Content is extracted from these databases and the files are constructed in real time "on-the-fly" by these computer programs as needed temporarily.

The advantage to this approach is that you can manage large amounts of information using standard database methods making maintenance changes in large scope possible and easy. For example, you could change the header on 1 million pages of information in one simple line of computer code that affects all pages. Although most large-scale template sites use this method, this is also the type of website created generally for large amounts of information that changes all of the time, like shopping sites. (Think Amazon and Walmart).

There are some other advantages to this approachl. Because all of the code runs on the server, any and all errors are evident and can be addressed from a single location. When there is a problem, the problem can be addressed one time that solves the issue for all users going forward. No action is required by the end-user. Often they aren't even aware of these mitigations.

The disadvantage to this type of approach is that it relies on computer code, not HTML. The computer code must take the content and create the HTML on demand. These sites require a great deal more expertise to construct, are much more expensive to create and maintain, and are best suited for large amounts of information that is in constant flux.

Hand Coded

Still yet another form of website design, and the one that I will using for this project, is one where someone with good knowledge of HTML handcrafts the code to a specific standard. There are many advantages to this. The code can be written in such a way that is uniquely specific to the website's particular needs and is humanly readable and maintainable and can be manipulated using any simple text editor without any dependencies upon third-party products. It can produce truly error-free code. There are no limitations to design or implementation except those imposed by the HTML standard itself.

This type of development is generally slower and more expensive. But it has huge payoffs. This is the type of development I am pursuing for this resource.

In the end the person doing the development is truly knowledgeable in the HTML and CSS markup languages.

A few other words about style and function:

Home page

Many studies have shown that when someone new lands on your homepage you typically have only a few seconds to grab their attention and keep them from bouncing. But there is more to keeping someone on your homepage than just cosmetics. Someone coming to you for the first time must be able to glance at your page and very quickly understand who you are, what you are doing, and what the purpose of the website is.

Just as importantly, if you want to be found in search engines indexes so they can drive new visitors to your website, your homepage must be search engine friendly. This typically means deciding what keywords describe your overall content and creating natural dialogue containing those keywords in proportion to their importance on your site. Google also uses other factors such as what keywords are in your headings and titles, and the relation of these headings and titles to each other on the page. File names and domain names are also important to search engines, and care needs to be taken so that all of this put together gives search engines an accurate picture of what your site is for and how it is to be classified.

The goal then, is to create a homepage that allows an end-user to instantly know what the website is for, while at the same time, also providing clues to the search engines as to what type of content your website contains.

Modularity

In any sites that is more than a few pages modularity becomes key to making the site maintainable. For example, should you want to change the header or footer on a page across all pages on the site want to be able to make that change in one location and not have to open all of this pages on your site and edit the headers/footers one at a time. This is typically done using server-side includes which allow you to insert a one line command that references an external file that is treated is in line HTML when the pages called. It requires a bit more set up but has big payoff the larger the site becomes. This is true not only for headers and footers, but logos, running graphics, and any other kind of content is typically repeated across more than a single page.

CSS

Like modularity, CSS (cascading style sheets) is a way of controlling formatting and styling across the entirety of your website from a single file. The use of in-line styling is not recommended because it not only means that changes must be made on all pages individually one at a time, it also reduces the page content readabilty significantly. Properly designed CSS can allow you to change font size, color, line spacing, etc., on certain blocks of text scattered throughout all of your pages by making a change one place in the stylesheet rather than across all of your files individually. CSS can be complicated. There are all kinds of inheritance rules and such that can make implementation a bit of a chore at the outset. But like server-side includes, it can mean the difference between a site that is truly maintainable and one that is a mess.

Backend scripting. (perl, asp, php, etc.)

As for backend server scripting, although the existing lessons are presently being served in this manner, it is my goal to eliminate this from the website under construction. Backend server scripting creates all kinds of dependencies. If the backend server goes away, so does your website. As server operating systems change, the code may become unserviceable. The code created generally will only run on certain types of computers and certain types of operating systems that are configured in specific ways, further limiting the websites usefulness outside of these environments and limiting your choice for hosting.

Front-end scripting (Javascript, Java, etc.)

Another problem with flashy design is it often depends upon JavaScript (or other code) that runs from within the computer or phones's browser directly. JavaScript, for example, is computer code that runs from within the end-user's browser. This is important because the code is running on the users end and not at the website's server. Because of this, the developer is hard-pressed to know anything about errors that are occurring in the real world. The errors occur on the users computer and there's virtually no way to reliably transmit this information back to the developer.

There are also many, many different versions of JavaScript and you cannot control which version is installed, if at all, on the end-user's machine. This makes it very difficult to test. Code which runs perfectly fine on the development environment may not run at all on users computers, and you will have no way to know it. Often times developers use third-party JavaScript libraries which may become outdated, broken or unsupported in the future.

In my opinion, use of JavaScript should be limited to the core libraries created by the Ecma TC39 committee which is responsible for evolving the ECMAScript programming language and authoring the specification. The committee operates by consensus and has discretion to alter the specification as it sees fit. Although there are literally thousands of third-party libraries, their use should be limited as much as possible if you want your code to remain viable and maintainable long into the future.

JavaScript is also difficult to read and requires computer programming expertise on top of HTML expertise to utilize. While many libraries are available, again use of these libraries creates dependencies for your website on third parties that can change or go away in the future rendering your website broken.

So for these reasons, I strive to utilize as little JavaScript as humanly possible, even if some "flash" is sacrificed. This site uses very little JavaScript, mainly within the ordering functions, which is probably unavoidable. However, the user will not require JavaScript to read, listen or view the lesson content, only to use the shopping cart to order. There are alternative ways to order so this is not a limiting factor.

Flash and Dazzle!

Today, in web design, people are often impressed by flash and dazzle. But this is superficial. Especially in a website where the primary use is going to be research regarding materials that are primarily text and audio based, flash is not only not necessary, it can limit your audience. Although computer speeds have improved greatly in recent years, as has the speed of the Internet, we're trying to reach a global community. Much of this global community will not have access to resources that translate well to flashy graphics and convoluted scrolling windows and such. What I aim to do is to provide a site that can work anywhere on the planet, even where there are slow connection speeds and a very poor audience with nothing but access to a smart phone or tablet.

Validation

Most websites on the Internet contain many errors. Often, the browsers being used by the end-users will attempt to self-correct for these errors and in many cases the end-user will not know they are there. However, in some cases, these errors can cause display problems for certain users that you will never know about. And just as importantly, all of the search engines that are trying to read your pages in order to include them in their index and search results, pay attention to this carefully. The more errors your page has the lower the rankings it will be given and if it has too many errors it may be disregarded altogether.

My goal is to create straight HTML versions of my father's lessons that validate 100% and have no outside dependencies, neither backend scripting, operating systems, computer types, severs, or third-party software programs. A pure HTML file carefully crafted can be run anywhere without any concern over operating systems, computer brand, etc. They can even be run off-line.

At the bottom of each page on this site at the bottom of each page on this site you will see a small rectangular button in the footer that says "W3C". Clicking on this button will submit that particular page to the W3C validator. We want all our pages to validate 100%. Should you ever find a page that is not validating 100% please let the webmaster know.

Cross browser testing

In addition to validating HTML for coding errors, a good webmaster will test the overall design against as many different receiving environments as possible. The reason for this is that everyone's computer and browser combination can yield different results. Something that looks fine in the development environment may not look as expected on someone who is using a different type of computer and/or browser. In addition to operating systems, (PC,MAC,Linux), device types (computer, smartphone, tablet, smarttv), screen resolution, browser types (Safari, Firefox, Chrome), even browser version numbers can all affect how a webpage displays at the endpoint. While it is impossible to cover every possible combination there are sites like "crossbrowsertesting.com" that allow a webmaster to view how their webpage appears in an literally thousands of different combinations of the above. These sites have fairly steep subscription fees and can only provide a clue as to any problems or this discrepancies that may exist. But their use, and the discipline of constructing a page that looks good across many different endpoints is important, not only to the end-user but to search engine rankings as well.

This is especially true these days regarding mobile content. A website should look good both on a computer screen or tv, as well as smaller handheld devices like smart phones and tablets. Search engine rankings are often affected by whether or not the search engine think sure site works well both places. These days, search engines place a premium on mobile content because mobile content now outranks desktop computer use. Although desktop computers will never go away, the sheer number of phones and tablets in use will mean that your content is likely to be viewed more from mobile devices than desktops now and into the future.

Readability

In order to maintain a site properly, the source files should be human readable. This is where handcrafting code really shines. Computer programs that generate HTML, whether they be front-end or backend, are typically very difficult to read. They are designed to be read by the computer and not a human. To maintain these pages you generally need the software that was used to create them which creates dependencies that may work against you in the future.

Take a look at the code snippet below, generated by Microsoft Word exporting a document as HTML, something that is quite common. It produces code that is not only invalid, it uses a combination of in-line styling as well as poorly designed CSS. This type of document is difficult to read and even more difficult to maintain.

The output of this type of export can vary significantly even from version to version of Word. Again, this makes this type of management troublesome as in order to keep things consistent and have continuity the same version of Word must be used always, something that is not maintainable at all.

By contrast, look at the code snippet below which has been handcrafted. This page can be understood by any human who understands HTML just by glancing at it. There's plenty of white space and proper indentation to understand relational structure. This code will validate. And if for some reason it doesn't it's easy to troubleshoot whereas trying to troubleshoot generated code can be next to impossible.

Handcrafted code can be edited using a simple text editor and is not dependent upon third-party software that is constantly under revision.

Backup

With the website the size of DTM, it is imperative that we keep good backups, both on-site and off- site. This is something that the majority of people in the computer world never deal with correctly or to the extent truly necessary. One of the problems with third-party sites is that they cannot be truly backed up by the end-user, they must depend upon the host. If the host dies or becomes unserviceable you can lose all of your HTML work and have to start over. This has already happened to us twice. At one point, all of digital copies of Russels lessons were lost and not easily retrievable. More recently, a third-party decided to go out of business after many years rendering much of the front end lost. Most users of these types of websites don't understand that they don't really own or control the HTML portion of their webpages as this information is provided by the servers at the hosting end. You can't just simply save the file to your hard drive using "File->Save As" and have a copy of a file that can be uploaded anywhere else. This is because that file will contain all kinds of code references to things on the third-party hosting server that no longer exists, and even if they did you would not have access to them.

I have created a system that keeps the website backed up not just once, not just twice, but close to a dozen times, over different computers, on different hard drives both external and internal as well as in the cloud and off-site. You can never have enough backups. At least some of these backups need to be complete snapshots saved over time so that you can always go back to how a website looked on a previous date. This is important for many reasons. If something should become corrupted and there's no easy or quick fix it may be simpler to go back to a previous version than to try to troubleshoot a problem buried in many thousands of pages of code. It also allows you to reuse older pages that may been removed at one point for some reason but need to be restored later.

Going Forward

Going forward, the vast majority of the work to be done falls into four categories:

1. The first is to finish the work of converting all of the lessons material into proper HTML onto a single page that has both summaries and audio included with updated graphics. This process will transfer the lesson material from a database script driven format straight HTML without any unnecessary dependencies.

2. Secondly, PDF files intended for print need to be created for each lesson so that the most recent transcripts can be downloaded directly. We probably need both PDF formats, 8.5 x 11 single or double-sided as well as the smaller booklet format intended to be printed for fold-over distribution. Both PDF and HTML are needed in order to provide both search engine friendly, web viewing friendly and hard print friendly versions.

3. Third, audio files may need to be re-tagged with updated intros and outros. In some cases, there may need to be some additional audio work done to clean up noise where possible.

4. Lastly, the ordering system needs overall. The current system has some outdated features and is cumbersome. Going forward we will need an ordering system that operates like any other shopping cart on the Internet with the important exception that no money is involved. This is going to involve some front in scripting work that can be removed from any off-line versions later. We also need to ask ourselves if some of the options in the current system is still relevant. Is anyone really still ordering cassette tape, for example?

Let's look at each one of these one at a time.

HTML Lesson Content

The most important part of this long term project is permanently memorializing my father's lessons in a format that can be sustainable long-term. Since the information is no longer changing there is no reason for this to be data-driven. The current situation is that none of my father's lessons are being properly indexed by Google. This is approximately 15,000 pages of content. This is for two reasons. One, the information is currently data-driven and coming from a separate domain. Proper HTML copies of these lessons need to be made and placed on the Russell Kelfer domain in order for search engines to give the domain proper credit.

The other is that the information contained in the database, although somewhat improved from its non-html original format, still contains hundreds of errors in any given lesson that not only prevent it from being maintainable, it's preventing it from being indexed. And display is at best sub optimal. The content is full of non-printable characters, for example. Some of these are invisible nonprinting characters that although invisible to the naked eye cause problems for browsers and/or appear in strange icons scattered throughout the text. Some of these embedded characters also cause strange line and paragraph breaks. These characters came originally from very old word processors before web standards existed.

For example, there is a difference between single quote, double quotes with curved angles "and the standard quotes that are considered web friendly. It is common even today for some word processors to allow the use of punctuation characters that are not part of the web standard and will not display correctly across platforms. To be web friendly these characters must be within the range of 32 to 128 decimal value. While wordprocessing programs can interpret characters above that value properly within their programs, they are considered illegal characters by web standards. At the very least they must be escaped to a special HTML code rather than simply expressed as an ASCII value. Best design is to avoid characters over 128 if at all possible. Even characters below 128 should be properly 'escaped'. This means replacing the word processor decimal value with its HTML equivalent. For example, a double quote should really be '"' instead of just ' " '. For more information, click here.

Additionally, these files contain nonprintable characters that are invisible. They typically contained special sequences that were specific to the word processor used at the time which are no longer supported. To find these problem childs, a hex editor must be used to look at the actual hex values, try to determine what values they should be converted to if any and or simply removed from the file. This cannot be done in a normal text editor as they are invisible and unable to be easily deleted. Instead a script must be written to process the file and convert these characters as needed. This process is different for different files due to the fact that so many different programs were used over so many years to create the content. Russell used word processors early on like the RadioShack TRS 80 that save data to huge floppy disks. Later on he used Max that say to high density smaller floppy disks, then smaller non-.floppy disks and then finally to hard disk and CD. Over the course of these many years many different programs and platforms are used resulting in files with many different types of embedded illegal characters.

There are other problems with these files. Because of the way they were created and/or edited there are many improper paragraph breaks and embedded carriage returns, both of the linefeed carriage return type as well as just the line feed type. These must be found and corrected.

There are also issues with what is known as nonbreaking space. This is where for whatever reason you do not want the browser to allow a line break. Browsers tend to reflow content as people resize the browser window. In some cases this can produce unnatural results. These nonbreaking spaces must be identified and replaced with the HTML escape sequence " ".

Then there is the issue of embedded styles. Much of the content at one point or another that existed in Word was exported as an HTML file using MS Word's internal functions. Unfortunately this was well before the time when there were the current web standards. Most of this content we generated what's known as in-line styling instead of using proper CSS. This content fills the file with unreadable text that is not maintainable outside of the original Word version of the document. It also runs contrary to standard web practice and will not validate. It also breaks the rules we've said earlier for being able to manage a large site format from a single added point. Because the files were done at different times there is no consistent standard on top of that so each file or set of files must be evaluated and processed independently.

Then there is the issue of formatting. Much of the formatting has been lost over the years and what is left is often again not up to web standards. Although some things like bold and italics can be retained in SOME files by careful translation, much of it cannot. This means that the only proper way to process these files is to break them down to text-only and reformat them from the ground up. This means everything from paragraph breaks to indentation, headings, as well as bold and italics, etc.

The goal of our finished product is to have something that validates 100% up to web standards that will look good on all browsers. And we want the finished product to be indepesndent of any unnecessary scripting so that all that is needed for the library to run properly is any web browser without regard or third-party hosting or server configurations. I intend to make two versions that can be interchangeable, one for use over the Internet and one for distribution as a standalone if and when the time comes that this is needed. This will require some programming that can take the one form and convert it to the other and back again. The end-user will not need these programs only the webmaster.

At the end of the day, each lesson and/or series of lessons must be analyzed to determine exactly what needs to be done to break down and rebuild the lesson into the new destination format. Each lesson and/or series of lessons may have completely different issues. The target format can be seen here.

PDF Lesson Content

Currently, the only versions of lesson material we have in print form as a PDF are formatted in small booklet format which is intended to be printed in a folded stapled fashion. While this works for printing booklets at the office to ship out it does not work for an end-user who simply wants to read the lesson from a PDF file. Because the file is formatted for folding print the pages are out of order when viewed in a standard PDF viewer and only makes sense once printed, folded and stapled. We also need standard 8.5/11 normally paginated PDF versions for use by web viewers. It might not hurt to offer users both versions so that if they wanted to they could download the booklet style and print their own booklets for distribution at their own Bible studies. This would save the ministry money in both postage and time. It would not restrict the ministry from doing the printing and mailing them in those cases where the end-user does not have the ability to do it on their own. Like everything else technology-related, it is quite likely that 90% or more of your end-users have the ability to do this on their own. It seems like maybe a better use of ministry money would be to offer that service only where required.

Audio Content

The audio content currently in circulation and streamed from our server contains intros and outros that are outdated. We may wish to have two versions, one for radio, and one for everything else that ties into the new domain name and titling that is aimed at age groups both young and old. Additionally, while doing that there may be some series that could use some additional editing and noise suppression work.

Note that I have omitted video content from this list for now. This is because streaming video requires much greater bandwidth and it has been suggested that my father was uncomfortable with this format. I am, however, open to pursuing this line of delivery.

Ordering System

The ordering system in place now was never intended to be anything more than a stopgap measure as was the data-driven content for the lessons that exists. It relies on backend server scripting which is becoming outdated. It is cumbersome to say the least. It works, if not very efficiently. When creating this mockup several years ago I started building and ordering system that works like the shopping carts in wide use today that people are used to. Unfortunately, we cannot use standard off-the-shelf shopping cart libraries because they all revolve around commercial monetary exchange something we do not want. This code is unfinished but it is a shopping cart tailored specifically to the ministry. It does not rely on prices or monetary transactions and it deals specifically with ordering formats at the ministry supports, including CD, tape, transcripts and books. Eventually CD and tape will become a non-issue where the few instances where people require this format can be accomplished through a simple email or phone call. In fact, some day I would hope that the ordering system with become a nonessential item, as the standard should be streaming and PDF download on demand. Anything else can be handled on a case-by-case basis by phone or email. Really, in my opinion, we are already at that point has very few CDs are ordered, and it is a small enough number that it could be handled without shopping cart type functions. I'm not so certain but that except for books, once PDFs have been generated, that the need for an extensive online ordering system will diminish.

Conclusion

cross

matte control forward matte control back

Debug

Debug2

Debug3

Debug4

Debug5

BGround:

Header:

Matter:

Logo:

cookies

ip info

theme info