The AEI Guide to Updating Site Content
For those who don't mind getting a little code on their hands

updated 6.25.03

Table of Contents

1. The Basics

HTML - the foundation of the web

We'll start by explaining the structure and terminology of exactly what happens when you work with website files. Like most things, websites really aren't as complex as they might seem on the surface. In fact, at its core a website is just a text file or group of text files - they may have an '.html' extension, but they're still just made up of text. The 'html' extension tells your web browser that the file is web code and that it should be rendered as a web page and not just shown as text.

Unless a special configuration is being used, these files can be viewed directly from your computer's hard drive (this is your local copy of the website) the same way they are read from the web; the only difference in viewing a site locally and viewing it on the web is the location of the files. For that reason, virtually all websites are viewed, edited, proofread, etc. on the editor's own computer before being sent to the web server - a hard drive that hosts websites.

The code used for web pages is called HTML - HyperText Markup Language. Since HTML is only made up of text, all that is necessary to edit HTML files is a text editor. In fact, it's a good idea to stick with a text-only application (like Windows Notepad or Apple TextEdit *1) rather than use an actual word processor (such as MS Word) since robust programs like that have a habit of adding lots of things that don't translate well to the web. On the other hand, it's even easier (especially for a web novice) to use a full-fledged web editor like Adobe Dreamweaver, since those programs allow you to edit the code while looking at the actual web page. This document is primarily intended to help those using text editors, but much of the information will be helpful for anyone learning to edit websites.

Transferring files with FTP

In order to transfer an HTML file from your computer to the web server you need to use an FTP client, a program specifically designed to send and retrieve files to and from remote locations. FTP clients for Windows can be found here and FTP clients for the Mac can be found here. Philosophies on the best FTP methods vary, but it's hard to go wrong with an FTP client that will allow you to simply drag updated files from your desktop onto the file listing of your web server (not all FTP clients do this).

To upload a file you first need to have the login information for your web server. This will consist of the web server's address, your username and your password, all of which should be given to you by the company running the web server. You must first connect to the web server by pasting this information into the correct fields in your FTP client (check the software documentation if this is unclear). Hint: it will be very helpful for your future updates if you can save a bookmark or shortcut to your web server so that you don't have to input this information every time you want to upload something.

Once you have connected to your web server you should see a list of the files it currently contains (which are also accessible to the world). If you have an FTP client that allows you to upload by dragging your files to the FTP window, then that's all you have to do - select whatever group of files you wish to publish to the web and drag them onto the file listing. You should then see your FTP client at work uploading the files. The same can be done in the opposite direction - if you want to download any files you can just select them and drag them out of the file listing onto your local website window.

If your FTP client does not support dragging files then you will probably need to click an "Upload" or "Put" button in order to upload your files - consult your client's documentation for specific instructions on that software.

2. Editing

Code fundamentals

The simplest and most common method of learning the way HTML works is to simply compare the code to what you see in the browser; much of the code can easily be understood by the behavior it produces. HTML code is made up of two parts: tags, which are basic instructions for the web browser, and attributes, which are descriptive arguments inside tags that dictate appearance or behavior of the tag they reside in.

For example, the most common way of dividing a block of text into paragraphs is to use the <P>, or "paragraph" tag. To divide the following text block into two paragraphs...

...you would simply need to write the code like this:

The resulting text would look like this in the web browser:

However, the <P> tag can also have an ALIGN attribute, with which you can center or right-justify your text. The following code:

<P ALIGN="right">
This is right-justified text. This is right-justified text.<BR>
This is right-justified text. This is right-justified text.<BR>
This is right-justified text.

...will render like this in your browser:

This is right-justified text. This is right-justified text.
This is right-justified text. This is right-justified text.
This is right-justified text.

<TABLE BORDER="0">
<TR VALIGN="top">
<TD WIDTH="200">

This is a <B>test table</B>.

</TD>
</TR>
</TABLE>

...will render exactly the same as this code:

<TABLE BORDER="0"> <TR VALIGN="top"> <TD WIDTH="200"> This is a <B>test table</B>. </TD> </TR> </TABLE>

The first example is much easier for the person writing the code to read (and troubleshoot, which is important), but it makes no difference to the browser - all it cares about are the code and the actual text. Whenever you need to use line breaks you must tell the browser so explicitly, using line break tags, paragraph tags or other methods. Tabs and superfluous spaces are also ignored (i.e., ten spaces in a row is just treated as one space by the web browser).

While you are free to write the code any way you want, it is important to try to be clean and consistent so that it's easier to scan and understand the code you've written. One of the hurdles for novice HTML coders is learning to pinpoint what is causing visual defects in your browser - it's often easy to miss an omitted quotation mark or tag bracket (<>), mistakes that would seem small but can sometimes cause dramatic glitches in your web page.

When in doubt, compare. Find another page or section that does what you're trying to do and compare your broken code to the properly-working code. If all else fails, strip the code out and write it again - that's often easier than spending an hour trying to figure out why the existing code isn't working right, especially if you've compared it with a working example and still can't figure out what's going wrong.

No trespassing

Learning to write HTML is one thing, but learning to work with pre-existing code that's beyond your current level of understanding introduces some touchy issues. When you are working with code that was originally written by an experienced web designer/developer it is important to leave code that you don't understand alone - not only because you might unintentionally create rendering problems but also because you may end up causing additional problems down the road for the original developer.

Most web professionals, for example, use templates to some degree or another in the production of their web materials. This practice helps to streamline production and ensure that all the pages on a given site render the same in the web browser. Another important benefit is that if the framework code on every page is the same, developers can perform global search and replace operations to correct problems that are found (i.e., they can use software to search for a block of faulty code and replace it with corrected code).

If someone then comes along and makes even the slightest changes to code that is otherwise the same on all pages, search and replace operations will fail on that page; if you make changes to the code, it won't match what the developer is trying to search for.

Still, this seldom becomes an issue, mostly because the typical content-savvy client has little interest in touching the structural code of their site - all they're concerned with is updating and editing the website content. This is made even easier in sites designed by Angled End because I place comments (inert code that the browser won't show on the rendered page but can be seen in the HTML) in the code of my client's sites that indicate where the regions are that can be safely edited. An example:

<TABLE BORDER="0">
<TR VALIGN="top">
<TD WIDTH="250">

<!-- ******** BEGIN CONTENT ******** -->

<P>
<B>Main content</B>
</P>

<P>
This is the main content of the page - this can be edited without affecting the fundamental structure or rendering behavior of the page.
</P>

<!-- ******** END CONTENT ******** -->

</TD>
</TR>
</TABLE>

Everything in between the <!-- ******** --> lines can be changed to whatever you want it to be. The *'s and capitalized instructions are present to make the comments easier to find.

3. Version Control

One of the most important issues in updating websites is version control. If more than one person is in a position to edit site content, you run the risk of inadvertently overwriting a page that another person had already made changes to since your version of that document was last edited. For that reason it is usually wise for one person to be considered the lead editor and any others to be considered subordinate editors.

The lead editor, who makes the vast majority of site edits, can safely assume that the copies of the site documents that they have on their computer are the latest versions. Only when a subordinate editor tells the lead editor explicitly that they are making a change does the lead editor need to pay attention to version control (and update their files with the newly updated document[s]).

The subordinate editors, on the other hand, must always assume that their copies are outdated and download completely new copies of whatever documents they intend to be working on before making any edits. If these edits are expected to take more than a few minutes, it is important that they contact the lead editor and instruct them not to make changes to those particular documents until the subordinate editor has finished and published their updates.

4. Conclusion

Editing website content can be as simple or complex as you're prepared to make it - there is practically no end to the codes and techniques that you can learn. AEI has known company employees to love coding so much that they evolved from HTML rookies to bona fide webmasters. Writing HTML can be a frustrating process even to the most hardened coders, but getting enough of the basics down to publish your own content is a manageable task that can empower you to take direct control of your website.