Building Web Pages: An Overview

Generally speaking, Web sites are made up of HTML documentsplain text documents that combine text and HTML tags or codes. Each HTML document makes up a Web page. A group of related (and usually linked) Web pages make up a Web site.

In this part of the chapter, I explain the basics of building a Web site. This information is vital if you plan to build a Web site yourself and want to do it right the first time. It'll also be very helpful if you hire a Web designer and want to understand what he is doing.

A Closer Look at HTML

I introduced HTML back in Chapter 1. If you plan on creating Web pages, it's time to take a closer look at it.

HTML works by encoding plain text with HTML tags. By enclosing text within tags, you can specify how the text is to be formatted. You can also include path names or URLs within certain tags to display images or create links.

Figure 8.1 shows a very small, very simple Web page that combines text, images, and links. Figure 8.2 shows the HTML code that made up that page. Kind of scary, isn't it?

Figure 8.1. Here's an example of a very short, very simple Web page that includes formatted text, a graphic, and a link.

Figure 8.2. Here's the HTML underlying the above Web page.

Markup Languages, Programming Languages, & the Bottom Line for Web Authors

Web pages are created with a markup language that is read and interpreted by Web browsers. There are several popular markup languages-HTML, DHTML, and XML are just three of them. But the one supported by all Web browsers is HTML. And as I write this, the current version of HTML is 4.0, which is fully supported by all current Web browsers, as well as some older ones.

Web pages can also be enhanced through the use of programming languages, such as Java and JavaScript. Unfortunately, these technologies are not as widely supported as HTML by Web browsers, so not all users can see content or features created with them.

The bottom line is this: a smart Web designer will create Web pages using HTML, and use less supported markup languages or programming languages for less important content or features. This can limit the features you include on your Web site, but if your Web designer knows what he's doing, he can get around the limitations of HTML to include the content and features you need the way you want them to appear on screen.

Fortunately, as you'll learn later in this chapter, you don't have to enter all those codes manually to create a Web page. In fact, you don't even have to know HTML at allalthough a basic knowledge might be helpful for troubleshooting problems.

Building Locally, Uploading Remotely

When you create a Web site, you build it on your computer, not on the Web server. This is referred to as the local copy of your site. Then, when you are ready to put your site online, you upload it to the Web server. The Web server has the remote copy of your site.

You may already see a small problem with this. If you have two copies of your Web site, how do you know which one is the more recent copy? Well, if you're smart and organized, you'll only make changes to the copy on your computerthe local copy. Then it will always be the most up-to-date.

Of course, Web site visitors don't see the local copy. They only see the remote copy. So each time you make a change to the local copy, you must put a fresh copy on the Web server, thus updating the remote copy so it matches the local copy.

Here's a quick review of the process:

1. Create the Web site locally.

2. Upload the local copy of the Web site to the Web server to create a remote copy.

3. Make changes as necessary to the local copy of the Web site.

4. Upload the changed files in the local copy to the Web server to update the remote copy.

I'll tell you more about uploading files to a Web server in Chapter 10.

Organizing Files

When you create the local copy of your Web site, it's important to properly organize the files that will make up the site. This way, when you copy the local files to the Web server, the files will retain their relationships to one another. This assures that all links will function correctly and all images will appear as they should.

Here's a step-by-step approach to organizing your Web site's files on your hard disk.

Step 1: Create & Name the Local Root Folder

Begin by creating a folder in which to store the local copy of your Web site on your hard disk. This folder is called the local root folder because it will be at the root directory of your Web site.

You can name this folder anything you like, but I usually give it the same name as the folder in which the remote copy of the Web site will reside. For example, my local copy of the files for wickenburg-az.com is named wickenburg because that's the same name as the site's folder on the Web server.

Step 2: Create & Name Resource Folders

Resources are Web site files other than HTML documents. Resources include images, downloadable files, PDF format files, Java class files (if Java is used), and any other type of file that is used within an HTML document.

If your site will have only a few resources, one folder should do the job. Name it anything you like resources isn't a bad name.

If your site is likely to have lots of different types of resources, you might want to create a folder for each type. For example, wickenburg-az.com's site includes graphic images, photographs, and PDF format files. To best organize all of these files, I created folders called images , photos , and pdfs .

On the other hand, if your site will be so tiny that it's likely to include only a handful of files, including resources, you can skip this step.

Step 3: Create & Name Subfolders (Optional)

If your Web site will be very large, with a logical, hierarchical organization, you may want to create additional folders within the root folder in which to store groups of related Web pages. There are two benefits to doing this:

• Subfolders help you keep Web pages organized by topic. This makes it easier for you to manage HTML and related resources files.

• Subfolders help the site visitor understand where the page he is viewing fits into the site's organizational hierarchy. How? Well, the URL that appears in the Address or Location area at the top of the Web browser window includes the path from the root folder to the current document (see Figure 8.3).

  Figure 8.3. The path to a page's location on disk appears near the top of the Web browser window.

  

If each group of Web pages has its own collection of resources, you might consider creating resources folders within each subfolder. This can further aid your organization efforts if there are many files.

File Naming Conventions

Before you begin creating and saving Web pages, you should check with your ISP for any special file naming conventions. File name requirements are determined by the Web server, not the computer on which you create the files.

Specifically, ask these three questions:

• Are filename extensions on a 3-character system or a 4-character system? You'll either be required to stick to 3-character extensions (such as .htm, .gif, and .jpg) or you'll be allowed 3- or 4-character extensions (such as .html, .gif, and .jpg). No matter what, a filename extension or suffix will be requiredWeb browsers use them to identify types of files.

• What is the filename of the default page? The default page is the file that's automatically served if someone enters a URL that does not include a filename. In most cases, this will be your Home page's name. The default page filename is normally one of the following: index.html , index.htm , default.html , or default.htm .

• Is the Web server case sensitive? On some servers, Index.html is not the same as index.html. If the server is case-sensitive, you must know before you start saving files and creating links. Otherwise, if the pathnames to files you link to do not have the correct case, your links won't work.

One thing I can tell you so you don't have to ask is that filenames cannot include spaces.

If you don't get the answers to these questions before you start creating pages and you name them incorrectly, you'll have to rename pages and recreate links. Trust me, this is not something you want to do.

Creating Pages

When you're ready to begin creating Web pages for your site, fire up your Web authoring software of choice and hop to it.

Unfortunately, I can't provide detailed instructions for creating Web pages, because the task varies depending on the Web authoring software you use.

If you're brand new to building Web sites, I recommend that you work through any tutorial that may have come with your Web authoring software. If there isn't a tutorial, use the manual that came with the software to create simple pages. You can always get fancy later, once you have a good handle on how the software works. If there isn't a manual, get a how-to guide; there's a good chance it'll be better than any manual anyway.

Tip

I tell you about Web authoring software and some how-to guides to get the most of it later in this chapter.

Adding Resources & Links

Adding resources (such as images) and links to pages can be tricky. If you're going to have problems, this is probably where they'll occur.

Here are a few things to remember if you want to prevent resource and link-related problems.

• Always save a Web page file before inserting resources or creating links to other pages within it. Save the file in the correct location with the correct name.

• Create and save resources within the appropriate resources folder before creating links to them.

• Avoid letting the Web authoring software create and save image files for you. In many cases, the software will save the image in the wrong disk location with a generic name that makes the image hard to find or identify.

• Do not move or rename a resource after it has been inserted in a Web page. Doing so will invalidate the reference to the resource within the Web page and the resource will not appear.

• Do not move or rename a link's destination page. Doing so will invalidate the link.

References to resources and links to other pages within your site are usually created relative to the page on which the link resides. That's why you should avoid renaming or moving resources and pages on your site.

Testing Pages

An important (and overlooked) part of building a Web site is testing the completed Web pages. This means opening them up with a Web browser-or better yet, multiple Web browsersto make sure they appear and work the way they should. If something isn't right, use your Web authoring software to fix it (if you can) and test it again.

Using the preview feature of your Web authoring software to test a Web page is usually not enough. Only by looking at a page in a Web browser window can you be certain how it will look in that Web browser.

Tip

If possible, try testing each Web page with a variety of Web browsersincluding old browserson a variety of computer systems and screen sizes. You may be surprised how different the same page can appear when viewed with different software or computer systems (see Figure 8.4).

Figure 8.4. These two pages show the same page viewed with a variety of browsers, screen sizes, and computer platforms. Although the page doesn't look the same in every shot, it doesn't "break"look terrible or illegible in any of these combinations. This page: Top: Mac OS, Netscape Navigator 2.0, 640 x 480 screen. This version does not support style sheets, so the default font is used. Middle: Mac OS, Netscape Communicator 4.7, 640 x 480 screen. Bottom: Mac OS, Netscape Communicator, 600 x 800 screen.

Figure 8.4. This page: Top: Windows 95, Microsoft Internet Explorer, 640 x 480 screen. Middle: Windows 95, Microsoft Internet Explorer, 600 x 800 screen. Bottom: Windows 95, Netscape Navigator 4.0, 600 x 800 screen.

The testing process must be repeated every time you make a change to a Web page. If you think that could get tedious , you're very astute. But testing is the only way to assure that the page is just right.