It’s a natural tendency to either clam up or to blather away. Obviously, avoid either case. Be friendly, but not too familiar; reserved, but not snobbish. Respect your prospect’s time, but expect them to respect yours as well. If you’re kept waiting for a half hour, don’t let it pass without mention.

There will probably be a round of introductions; if not, instigate one. You should be introduced to everyone in attendance. Remember, you have something of value.

Next,

there will usually be a brief synopsis of why you are there, and it will then be your turn to speak. After a few niceties (“nice day, nice office, blah blah”), go over a brief description of everything you’ve learned about the company, and what you understand to be the project. Then ask if your facts are correct.

This sets the stage for two-way communication and forces the prospect to get involved in your presentation. It will also help to clarify who the key players are (usually the ones whom everyone turns to when you ask a question). You can always fall back on a question or two if people seem to be losing focus, or if you’re starting to feel like a bug under a microscope.

By the end of the meeting,

you should be asked to submit a proposal. Make sure that you have a contact for any questions, that you have a firm understanding of the scope of the proposal, and that you know the exact date for when the proposal is expected.

Learn How to Handle Difficult Clients | Dansky

The Proposal

In most cases, the written proposal will reflect the size of the project. A quick “crash and burn” project may only deserve a one-page proposal, whereas a large project may require a lengthy write-up. You’ll have to guess what your prospect would like to see.

Regardless of its size, a proposal should not include any creative work on your part. You don’t work for free, and most clients won’t respect you if you do.

Most proposals will include the following:

• Executive Summary—A synopsis of the proposal
• Background—Key issues that have led to the need for the project
• Scope of Proposal—The nuts and bolts of what will be accomplished, and by whom
• Timeline—Detailing the beginning and ending of each phase of the project
• Projected Costs—Your fees for the work
• Terms—The contractual details of the agreement

Other items that might be included in a proposal are a glossary of terms, a historical look at the Internet, and other items that may help in your communication to an audience unfamiliar with the medium.

There is no set way to present a proposal, but if you can, present it in person to the main decision maker, and go over it with him or her. This will help you address any immediate issues, and may enable you to get some feedback on the spot.

The Mock-up

It’s generally not a good idea to present a mock-up of any kind until the deal is closed. This isn’t in any way sneaky—you’re not pulling a fast one. You get paid to make mock-ups; you get paid for your creativity—so giving either before you’ve been hired is counter-productive.

Once you’ve been contracted, a mock-up may be the best way to communicate your ideas for approval. Now, there are several ways in which you can mock up the “look and feel” as well as the mechanics of your system, and which you choose will depend upon your own skills and resources, as well as what you perceive as the client’s needs.

Styleboards

A styleboard is basically a piece of foamboard or cardboard upon which you’ve laid photos, rough art, and text that give the overall impression of a page or system’s look and feel. You can use photos, tissues (or layout paper), artwork, font treatments, and the like to help define what the message will be, without actually going into the mechanics of how a page or system will look in HTML. The key elements of a styleboard can include

• Photographs (if available)
• Basic color schemes
• Bulleted text for key points
• Text treatments for headers
• Key graphic elements
• Navigational concepts

Using a styleboard can be difficult,

in that it often takes more time to describe its contents and each feature than it’s worth, especially if you’re dealing with a company that has never worked with a design agency. All in all, we generally avoid styleboards for two reasons:

• In HTML design, the final medium is (still) very limited, and styleboards can give clients the impression that they will be able to achieve more than the medium allows.
• A styleboard can be very subjective, and two different designers can create two entirely different pages based on what each sees in a styleboard.

Styleboards can,

however, allow clients to see into your creative “engine”, and can help them feel like they have some control over the way in which their system is being designed. For this reason, it may be best to think of styleboards (and other proofing tools) as methods for client communication and involvement, rather than actual creative processes.

In this chapter we start testing your site; we’ll upload it, and we will discuss ways you can verify your code. Hold on, we’re about to let the world view your work!

Preparing for the Masses

The first step in preparing to go online is to test your site in all three major browsers—Microsoft Internet Explorer, Netscape Navigator, and Spyglass Mosaic—before you upload it. Start from your home page (usually index.htm), and check out each page one by one in your browser, making sure all your pages look good. Now, check your system twice more, using the two other major browsers. You are checking to make sure everything works and looks good, no matter what browser the viewer is using.

---

Tip
During this testing process, you should resize your browsers’ screens to various sizes. Although you may view the Web through your browser at full screen size (or through a large monitor), many viewers may not, and it is important to keep this in mind.

---

---

Note

If you don’t already have the three major browsers, you can download them for free from the following sites:
Microsoft Internet Explorer is available at http://www.microsoft.com/ie/download/.

Netscape Navigator is available at http://www.netscape.com/comprod/mirror/client_download.html.

Spyglass Mosaic is available at http://spyglass.com/products/index.html.

If you want to ensure total cross-compatibility, you would also test your pages with older browsers and on different machines (such as Macintosh, UNIX, and so on).

---

You can see that this same HTML file looks very similar within the different browsers. This is difficult, but not impossible to achieve. If you have trouble with this, that’s all right—just make sure that each page looks like a page you can be proud of, no matter what browser the viewer is using.

Going Live

Before you can upload your files, you must set up your FTP program. (We discuss how to set up CUTFTP—which is on your CD-ROM—in Chapter 4, “Your Domain,” in the section titled “How to Use FTP to Post and Update.“)

Now, get online and upload your files (making sure you maintain your directory structure). If your site is contained within one directory, you can simply select all of your files within that directory and drag them over to your site. (See Figure 19.4.)

If you are using multiple directories for your site, you will first need to create that directory structure on your server. You do this in CUTFTP by pressing Control + M, typing the name of the directory (see Figure 19.5), and clicking OK. Then upload each file to the correct directory on your server.

Testing 1,2,3

Now that your site is uploaded, the next step is to see if it works. Connect to the Internet, open your browser, and enter your site’s URL. Check to see if all the links on your site work now that they are online. Now, check with the other browsers. (This may seem repetitive, since you have just done this offline, but believe us, it’s important.)

Troubleshooting

Here are a few of the most common problems you could encounter at this point:

1. Graphics won’t load.
   When your page appears but the graphics don’t (see Figure 19.6), there could be a name problem or an upload problem. Make sure the graphics files are actually in the correct directory and that the filename (including the .gif or .jpg extension) matches the one in your HTML tag exactly, including the capitalization. (Windows machines, for instance, are not case-sensitive, whereas Web servers are.)

   If the problem persists, you may have an uploading problem (that is, the files may have been uploaded incorrectly). This is very rare if you are using CUTFTP, which automatically switches between ASCII and binary transfers. In some other FTP software, however, you may need to manually select the transfer protocol. Graphics files use a binary transfer.

2. File not found.
   When all you get is the message File not found (see Figure 19.7), this most commonly means that you have misspelled the filename, or that the file is not in the directory. Check to make sure that your file is actually where it should be (if not, move it or re-upload). If that doesn’t do the trick, the problem is most likely your filename. Don’t forget, filenames are case-sensitive, which is why it is a good idea to make all of your filenames lower case.

   A special note to Windows users: The problem may be that your server does not accept the .htm extension. Either configure your server to accept this extension (or ask your host to do this for you), or rename your files with the .html extension. This can be done from within CUTFTP by selecting the file, hitting Control + N, entering the correct filename (see Figure 19.8), and clicking OK.

   CGI problem: You get a 501 error when trying to submit a form.

   This error message often says something like: “We are sorry to be unable to perform the method POST to non-script at this time.” This means that the server did not recognize the referenced URL (the URL defined as the ACTION within the HTML Form) as a CGI script. Make sure that your script resides in the correct CGI BIN directory, and that it has the correct extension to be used on your server.

3. Tag formatting (such as BOLD or H1) goes on and on.
   Figure 19.9 shows a very common formatting problem, which is generally caused by one of two things: You forgot to add an ending tag (as in </BOLD>), or the ending tag is improper—you forgot one of the brackets, for example (as in /BOLD>).

    

4. You changed and reloaded the file, but it still looks the same.
   We get calls about this all the time. You make corrections and reload the file, and the file is still not fixed. This is a simple problem. It is caused by the browser keeping the file in local cache. (This most often occurs in older versions of Netscape Navigator.) The simple solution to this is to clear your cache. This is done in Netscape Navigator by choosing Network Preferences in the Options drop-down menu, and clearing both the disk and memory cache, as shown in Figure 19.10.

   ---

   Note

   If you are uploading files to a UNIX system, you may need to perform a change mod on the file (usually CMOD 755). Consult your software information or system administrator about this.

If a good Web site may take 100 hours to create, and a feature-rich Web site may take 1000 hours, you need to justify that 900 percent increase. If you’ll be gaining 10 or more times the sales, or mindshare, or whatever is your goal with the feature-rich site, it’s worth the expense (of time or money). Realistically, however, you probably won’t be looking at this type of increase.

Clients will often say something like “we want Java.” At which point we have to explain to them that Java is a programming language, not a feature. We then ask them what they want to accomplish with a Java application. Some people actually have a use for Java (such as some kind of interactivity), but 99 times out of 100, all the people want is animation.

As a commercial designer, you are looking to provide a good investment, and a good investment is rated by its returns. Your job is to provide the most effective Web site possible, under the constraints of time, money, technology, and bandwidth. The trick of the trade is to honestly assess the possible features of a site against their role in the site’s overall effectiveness.

You don’t have to be a downer, and just go in dashing everyone’s dreams of an awe-inspiring site. What you should do is sit down with the client (or by yourself) and realistically examine your options. If option X will cost $Y, and will only be viewable by Z percent of the WWW community, is it a good expense? In some cases it will be, and in others it will not. You have to put these things in perspective—this is called being a professional.

So, let’s get animated! To continue our exciting generic streak, we’ve opted to use a 3-D-rendered globe for our example. We’ve used Asymetrix 3D-FX for our rendering engine, using a globe model supplied with the software. (Hey, we said 30 minutes.)

An animation requires several frames (images) to be used in succession. To do this, we create an animation path for the model (in this case, a spinning motion), and generate snapshots for each frame (Figure 18.8).

---

Note
Most 3-D tools enable you to create animations automatically, using a variety of formats. We’ve found, however, that the compression and dithering these formats provide are inferior to static bitmaps. This is why we take a series of bitmap snapshots, rather than relying on animation tools.

For this globe, we decided to create a 16-frame rotation. This means that it requires 16 different GIFs to create the effect. The number of frames in an animation will affect the size of the final GIF file. In our sample, we used 16 files which, as individual GIFs, would be approximately 4K each. The resulting animation GIF is under 50K, which means that the size of the GIF animation is not equal to the cumulative size of all of the frames (64K).

Notice that we named the individual frames alphabetically (A,B,C) rather than numerically (1,2,3). This is to help us keep track of the sequence. If you are using more than 9 frames, you may want to name them as we’ve done, since a computer will put the number 10 before number 2 (1,10,11,12,2,3,4,). Most applications list files in alphabetical order.

Now that we have our frames (Figure 18.9), we can put them together with the GIF Construction Set (on the CD-ROM). This is a great tool, and we’re not nearly using it to its potential in this example. Please note that you do not have to replace the entire GIF in each frame—only the area that you wish to change. The construction set will enable you to place smaller files over the top of larger ones. In this case, however, the entire image changes as the globe turns (though we could have cut the size down a little be reducing the white space).

You’ll notice in Figure 18.10 that we are adding commands within the construction set. LOOP does what it implies—once the GIF has reached the end, it starts over again. The CONTROL lines enable you to set the timing of the animation (how long each frame will stay on screen before the next loads), as well as how each frame will load in relation to the last. You may need to play with the CONTROL lines quite a bit to get the desired effect for each individual animation.

As you add each image, the construction set asks what palette you want applied. Here again, you will want to play around to see what gives the best effect. More often than not, you’ll probably opt for the Use local palette selection.

Once you have created your animation GIF, you can simply place it as you would any other image. You can also resize the image within the code. In this way, one animation can be used for many applications within a site without the need for reloading. In creating a page to display our sample GIF animation, we’ve used the GIF twice at full size, and four more times as bullets. The effect is a lot of motion on the page (which you’ll just have to imagine).

Here’s the code we used:

<HTML>



<BODY BGCOLOR="#FFFFFF">



<IMG SRC="zglobe.gif" HEIGHT=75 WIDTH=100 ALIGN=LEFT>



<IMG SRC="zglobe.gif" HEIGHT=75 WIDTH=100 ALIGN=RIGHT>



<center>



<h1>Welcome to the World!</h1>



</center><P><br><br><br>



<HR>



<h2><DD>Places to Visit:<P>



<IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Forests<P>



<IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Oceans<P>



<IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Deserts<P>



<IMG SRC="zglobe.gif" HEIGHT=25 WIDTH=33 ALIGN=LEFT>Mountains<P></h2>



</BODY>



</HTML>

You’ll notice that the browser’s STOP button remains active (red) even though the document is loaded. When we first started using GIF animation, we received complaints that our pages weren’t fully loading. This is not the case. Since most animations are set to LOOP, the browser is constantly reloading the image—but it’s doing so from local memory. Even if you go offline, the image will continue to LOOP. Luckily, people have now become accustomed to this.

---

Note
Browsers that are not capable of displaying GIF animations will only display a static “snapshot” of your GIF (as will most bitmap manipulation applications). This snapshot will generally be the first or the last frame in your animation, so make sure these frames look good on their own. Viewers using older browsers won’t know what they’re missing, which is preferable to them feeling like they’re missing out.

---

And there you have it! Even with the rendering, this took less than 30 minutes (though we must admit, we’ve done this before).

If you’re not lucky enough to have 3-D rendering software, don’t despair. A simple animation can be created using any graphics program, including Paint Shop Pro on your CD-ROM. For instance, you can create a simple animation by simply opening a graphic in PSP and lightening the image, little by little, using the Adjust Brightness tool and saving the image each time as a different GIF file (Figure 18.12).

When put together in the GIF Construction Set (Figure 18.13), this can create a fade-in or fade-out animation (depending on the order you place the GIF files in the animation). We created a fade-in animation in 10 minutes using this technique. Though this type of animation is very simple to create, the effects can be amazing. For instance, this fade-in animation (when timed correctly by editing the control) can make the graphic seem to appear out of thin air—or to slowly disappear.

See, it’s easy—just use your imagination! Animation is just a series of slides. If you can make the slides, you can build the animation.

Yes, we may have been a big downer throughout this chapter. You may have had grand ideas that we shot right out of the water—which is not really our intention. Our intention was to give you our honest opinions on the use of bells and whistles. You see, as Web developers (yes, you included), we are often inundated with software companies pushing their newest feature that will “revolutionize the Web.”

We are not saying these companies are bad or lying (in fact the Web would not be what it is today without them). Far from it. They are producing a product that they believe in and we have the utmost respect for that. Our point is to bring all of this down to earth, and to give a more conservative view of things than that offered by sales hype.

In this chapter we have discussed

• If you really need all the bells and whistles
• Different ways to animate your pages
• Macromedia’s Shockwave
• Video and the WWW
• How to incorporate sound into your Web site
• The use of Java
• Microsoft’s new ActiveX
• Virtual reality and VRML
• Hybrid applications
• Justifying the bells and whistles
• How to get an animation on your page quickly using GIF animation

There are certainly reasons for using the latest whiz-bang features on a site. If you are presenting the site just for entertainment and brand recognition (like Pepsi), if you are trying to set your site apart from your competition’s, or if your company image can be enhanced by the use of bells and whistles, by all means, consider their use.

There is, of course, a caveat: Bells and whistles annoy many people. We’ve talked with many folks who have very strong opinions about the use of features like Shockwave. As you know, many people turn plain old graphics off on their browsers. You can probably imagine how they feel about huge multimedia files.

Do I Really Need All the Bells and Whistles?

In short, no. Having an extremely accessorized site may increase traffic (exponentially), but the prevailing wisdom on the subject seems to point to one fact: Hits do not mean sales. If sales are the main goal of your site (as opposed to mindshare), and you are keeping an eye on time and/or expense, you will probably keep your bells and whistles to a minimum (but don’t forget that graphics on the Web were once considered frivolous).

Having a clearly navigable,

attractive, and informative site will give people a good impression of your company. Having a few special features may help put you ahead of your competition (all other things being equal). Overloading your site with bells and whistles, just for the sake of having them, will make you look cheesy.

Think of it this way: Have you ever seen a car that was way too accessorized? Did you think “Wow, that guy has class?” or was it more like “Jeez, what a goofball! Maybe he’s a pimp.” If you do choose to employ bells and whistles, do so tastefully. In many cases, your best bet may be to let people know if they are about to enter a feature-rich site, and to give them an alternative.

This is not to say that you should be aiming at producing plain,

generic sites. What you should be doing, on a constant basis, is balancing bandwidth with communication value. You want to make the best presentation possible, and you want to do so using the least bandwidth. This is true even when you know that your site will be viewed by an audience with full T1 access—bandwidth is still a consideration.

So, what you should be thinking about is what communication value each component in your site will have, and whether it’s worth the expense of bandwidth. Many authors try to keep each page under 40K total (HTML, graphics and any other files). This is a difficult goal, and we don’t necessarily adhere to it ourselves, but we always use it as a benchmark.

When there comes a time to make a decision about including a component that will push our page size past this mark, we ask ourselves (and our client) whether this component is worth it. Sometimes it is, and sometimes it ain’t.

Animation

There are several ways to add animation to your site. Server push, client pull, applets (Java, ActiveX, and so on), embedded Shockwave, and GIF89a animation all provide movement on the screen. Each do so in a different way, and with different effects on the browser.

Server push and client pull generally reload images, one on top of the next, in order to achieve an “animation” of sorts. This is a real bandwidth hog, and the effect can be pretty untrustworthy (especially using low-speed connections). You will rarely see this on the Web anymore, not because of any specific fatal flaw, but because it was never well-hyped, and because of bandwidth issues.

A good example of server push animation is on the Armani Exchange Summer ’96 site. The opening screen (Figure 18.1) simply shows two people bundled up for winter.

After a series of slides (pages), in which the couple disrobes, the final slide (Figure 18.2) shows the logo and tagline, “Summer is here.”

It’s a very cute use of this type of animation,

though it’s also very slow. The difference between server push and client pull is implied by the name. Server push sends the information (generally via a CGI script) without request, and the connection to the server stays open until the server is finished.

Client pull requests each transfer individually (usually with the META/refresh tag), and generally necessitates the reopening of the connection each time a new page is loaded.

Client pull is generally the easiest to set up, as it requires only the addition of a tag in the <HEAD> of an HTML document. For example, adding the line <META HTTP-EQUIV=”Refresh” CONTENT=”10; URL=http://domain.com/feed2.htm”> will cause the page feed2.htm to load after 10 seconds. This page could have another “Refresh” command that would load a third page, and so on.

For the most part,

client pull and server push types of animation can be replaced through the use of GIF89a animations, which have several distinct advantages.

GIF 89a Animation

GIF animation is probably the best way to introduce animation to your pages. Both Netscape and Microsoft have expressed that they will support GIF animation in all future browsers,

it requires no plug-ins, it is relatively small, and some nice effects can be achieved by its use.

The main advantages to GIF89a animations are that they are completely portable,

do not require an open connection (like server push), and can work offline (unlike any connection-dependent animations).

The down side is that they require a special tool to make (unless you want to get into the code yourself).

Of course,

we’ve included that tool on the CD-ROM (is there no end to our forethought and generosity?). Read the Quick and Dirty Guide at the end of this chapter for step-by-step instructions for creating GIF89a animations. Also refer to Chapter 12, “Working with Graphics,” for more general information on this format.

Shockwave

Macromedia (see Figure 18.3) is the developer of the two major multimedia presentation applications on the market: Director and Authorware. Shockwave is a way to package movies and interactive applications from these programs.

Macromedia Shockwave for Director and Shockwave for Authorware are, without question, excellent interactive multimedia platforms. Unfortunately, the proprietary nature of Shockwave, and the need to download plug-ins, makes it pretty unappealing for commercial use.

Additionally, these are big files, and though the newest Shockwave for Authorware is supposed to stream (which means that you can view and interact with it while the file is downloading), there is still an issue of bandwidth.

For more information on Macromedia products, visit www.macromedia.com. If you are a multimedia developer, you’ll find plenty of information on adapting and creating WWW/Shockwave applications.

---

Note

We check all plug-in dependent applications through the BDWBWI (Better Damned Well Be Worth It) protocol. If you are expecting viewers to download and install a plug-in, then return to your page to download a large file, you’d better be sure that you’re providing them with something that’s worth the wait!

---

Video

Everyone wants their $3,000+ computer to look like a $200 television. While you can link to (and even embed) AVI, QuickTime and other video formats within your HTML pages, the files themselves are generally huge, of poor quality, and limited to 320×240 pixels.

Although the technology for streaming video (video that is presented as it loads) is being improved constantly, the price for setting up the equipment and server required to run this type of application can be extraordinary, and the quality is questionable. These are the reasons why you don’t see many video files on the WWW—yet.

MPEG (a proprietary algorithm-based compression, like JPEG) may soon change this, as MPEG allows for very aggressive compression, full-screen presentation, and high-quality sound and video. MPEG1 is often described as having similar quality to VHS video (again, the TV thing), while it’s big brother, MPEG2, has mastering digital quality.

Our advice on the use of video is to use MPEG (once it is fully supported). The WWW really isn’t a proper vehicle for huge files, and current video formats require bandwidth beyond reason. MPEG encoders and decoders are constantly being improved upon, and your best bet is to continue to search the Net for up-to-date information.

Sound

Adding sound to your pages is more difficult than you might expect. While you can always link to a sound file (of any type), this doesn’t really present a very good effect. Your viewers will need to download the entire file before they can hear it—this isn’t exactly what you think of when you want multimedia. Luckily, there are more and more options becoming available for sound.

Actual Content

If you want your page’s sound to have actual content—which is to say you want more than just noise—you will want to go with a streaming application. A streaming application does not require a complete file download, but instead allows the viewer (listener) to hear a file as it downloads. One of the most exciting sound streaming applications is RealAudio (www.realaudio.com).

RealAudio has such an aggressive compression, and such an effective packet handling protocol, you can actually have a live feed. Visit the National Public Radio site off of the RealAudio home page  for an example.

Generally,

the slower the access speed, the poorer the sound quality (because the sound file must be more highly compressed). On a 14.4 connection, RealAudio sounds like an AM radio that is not quite on the station. You can still make out the words, but it’s not exactly great sound.

If you are considering adding a vocal sound file (such as a speech) to your site,

RealAudio seems to be the best option. It will require vendor software for the server, encoding software for the designer, and decoding plug-ins for the viewers. Visit the RealAudio site for more information.

Just Plain Sound

If you are simply looking to create a background sound for your pages, you can avoid specialized server/client software in at least two ways.

Microsoft Internet Explorer and the newest version of Spry Mosaic allow for the use of a “background sound” (in the body tag: bgsound=”sound.wav”) within the code.

The sound file will download,

and then loop as many times as is specified or until the viewer leaves the page. This is, by far, the easiest way to apply sound to your page, and we anticipate that it may be included on other browsers very soon.

The second way to add sound is to use a Java applet. As with all things Java, using an applet for sound is not quite ready for prime time. The sound quality we’ve experienced on Java-enabled sites is comparable to that of old video games and low-quality MIDI players. Take heed, though, as this will likely change.

We will also have to modify a line of the CGI script (formmail.pl) to send us our e-mail in a different format (more easily read by a database).

The goal of this project is to provide a form for viewers to request a free informational brochure. After the viewers fill out the feedback form and click the Submit button, we want an HTML page to load, letting the viewers know we’ve received their form and thanking them for their time. In addition, we want our text brochure to be e-mailed to them automatically.

We also want the information they provided to be sent to our e-mail box in a manner readable by the database (for instance, Microsoft Access).

So, there are four separate files we must create in developing this form system: the HTML form itself (which will be discussed in detail in Chapter 14, “Mail Delivery Systems”); the CGI script with which to decode it (formmail.pl, as discussed in Chapter 11, “Integrating HTML with CGI,” with a small modification); the “brochure” to be mailed to them (which is any e-mailable file); and the HTML redirect page (which is also discussed in Chapter 11).

---

Note

The modification for the CGI script is very easy; simply change the code

[print MAIL "$name: $value\n"]

to read

[print MAIL "$name,$value,"]

This is saying to separate the fields by commas (comma-delimited text is easily read by most databases). That’s it!

---

And here’s how it works: The viewer clicks on the feedback link from the home page and arrives at our HTML form. They fill out the form (Figure 13.3) and click the Send The Form button.

Figure 13.3. How a viewer fills out this form example.

The form is then submitted and the viewer jumps to the thank you page (See Figure 11.6 in Chapter 11.). At the same time, the informational brochure we promised is forwarded to the viewer’s e-mail box.

Our form contents then arrive in our e-mail box, where we can save it as text (see Figure 13.4).

Figure 13.4. How the form contents look when we get them via e-mail and save them as text.

Entering this information in a database is truly simple, as most database applications allow simple importation of comma-delimited text. If your own database prefers a different layout for text input, you can make the adjustment in your CGI.

If you are running your own server, you can automate the input (which is obviously preferred) in several ways. The simplest way is to have dynamic input for your database, which will require a special CGI script/application. This configuration will depend on your database and server, and instructions may be included with your software. The second way to import directly is to give your database an e-mail box and have it import information from that.

Can Customers Find What They Are Looking for Quickly?

On a small site with good navigational aids and narrowly defined subject areas, customers should have no trouble finding what they are looking for. However, after a site grows more complex, a good internal search engine may be necessary to aid in the site’s user friendliness. (After all, no matter how good your widgets are, they won’t sell if no one can find them, right?)

A Cool Free Product: Excite for Web Servers

If you are running your site off your own server, there are some commercial “ready-made” products available for performing searches of your site, the most popular being Excite for Web Servers (Figure.13.5).

Figure 13.5. Excite for Web Servers.

Excite for Web Servers (EWS) is a new generation of Web navigation software. It gives your Web site the same search capabilities used by the Excite service (as well as the sites hosted by Netscape, Sun, Info World Electric, HotWired, Chevron, United Airlines and others).

EWS supports the following platforms:

• SunOS
• Solaris
• SGI Irix
• HP-UX
• IBM AIX
• BSDI
• Windows NT

To run the software, you need a minimum of 32MB of RAM and enough disk space for the following requirements:

• 5MB for the EWS search engine
• Sufficient disk space for your Web site document collection
• Additional disk space equal to approximately 40 percent of the size of your document collection for the indexing process

ETW uses the following searchable document formats:

• HTML
• ASCII

EWS’s underlying concept-based architecture was developed specifically for the Internet by Excite. This architecture supports not only searching (which assumes the viewer knows exactly what they’re looking for), but browsing and exploration as well. In other words, with Excite for Web Servers, viewers don’t need to know the right keywords, they can simply describe what they’re looking for in their own words.

EWS quickly returns a list of documents ranked by confidence (of keyword match), and is unique in its capability to let users sort the search results list by subject. This helps them understand what’s on your site and how it’s organized. Another unique feature is that when a viewer finds a document he or she likes, EWS’s query-by-example (with a simple click) can hunt down more just like it.

An additional feature is the EWS Notifier,

which automatically updates the Excite search service’s master index with information on your site when you add content.

Although Excite for Web Servers is free, the company currently sells maintenance agreements (which include upgrades, as well as e-mail and phone support) for $995 per year per installation. EWS contains all the functionality you need to add searching to your site—which means you do not need to purchase other products, such as a database, to use it.

Excite claims you can have EWS up and running in just 30 minutes since it writes all the CGI scripts and HTML pages for you (yeah, no programming!). You simply fill out a few forms and point EWS to your Web documents, and it creates a custom, concept-based index of the contents of your site in minutes.

Here is how the company says the installation process works, and how it can be done in under 30 minutes (times are approximate):

Step 1: Download your copy of Excite for Web Servers. (3 minutes 30 seconds)

The time varies, depending on your network connection.

You can download Excite for Web Servers free from

http://www.excite.com/navigate/download.cgi.

Step 2: Register EWS with Architext. (4 minutes)

Once you’ve agreed to the license terms, you will need to fill out their registration form.

Step 3: Configure your collection of documents. (4 minutes)

You will need to enter a name for the collection, and tell EWS which files you want included.

Step 4: Index your document collection. (3 minutes 30 seconds)

The exact amount of time needed depends on the size of your collection.

EWS is kind enough to send you an e-mail when it’s done; 300MB can be indexed by EWS in about an hour on a single processor workstation.

Step 5: Add your search page to your site. (2 minutes)

You simply define how you want your search page to look by filling out a form, and after it’s defined, EWS will create the search page, along with all the necessary CGI scripts. Link the search page to your site, and you’re up and running!

That’s all you need to do to make your site more searchable with Excite for Web Servers. It’s a strong product and, considering the price, we recommend that you at least check it out.

Figure 13.6. Excite for Web servers in action at the Reynold’s Metals Company site.

This is most likely the first use you want to learn, so we are going to take you step-by-step through this process.

By doing this, we intend to give you a general understanding of how forms work with HTML, as well as to help you to begin to understand the CGI scripts you will find available on the Web (some of which are listed in Appendix F). So here we go

As with any complex project, we begin by assessing and sketching out our goal.

The goal of this project is to provide a feedback form for viewers’ questions and comments. Once the viewers fill out the feedback form and click the Submit button, we want an HTML page to load, letting them know we received the form and thanking them for their time.

We also want the information they provided to be sent to our e-mail box in a readable manner (which requires that we decode it; without decoding, the e-mail looks like a mess and is very difficult to work with).

---

Note
If you wish to also send the viewer an e-mail in response to a form, check out Chapter 14, “Mail Delivery Systems,” after reviewing this section.

---

So, there are three separate files we must create to develop the feedback form: the HTML form itself (as in Figure 11.2), the CGI script that will decode it, and the HTML redirect page (which lets the user know that their form has been submitted).

Figure 11.2. The goal of our feedback form example.

Now that we know where we’re headed, let’s get started on the HTML form. For this very simple form we will use the code in Listing 11.1.

Listing 11.1. Our feedback form code.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN" "html.dtd">



<HTML>



<HEAD>



<TITLE>Feedback Form</TITLE>



<!-- Author:  Kim and Brad Hampton -->



</HEAD>



<BGCOLOR="FFFFFF" TEXT="000000" LINK="425AFF" VLINK="0018C4" ALINK="FFFFFF">



<H1>We would appreciate your feedback</H1>



<P>



<FONT FACE="Lucida Sans", "Arial", "Times Roman">



<FORM ACTION="/cgi-bin/formmail.pl" METHOD=POST>



<INPUT TYPE="hidden" name="recipient" value="hampton@ha.net">



<INPUT TYPE="hidden" NAME="redirect" VALUE="http://www.ha.net/thanks.htm">



<DL>



<DT><I>Subject:



    <DD><SELECT name="subject">



        <OPTION>My suggestions



        <OPTION>My comments



        <OPTION>I have a question



        <OPTION>Other



        </SELECT>



<DT>Your Name:



    <DD><input type=text name="realname" size=30>



<DT>Your Email Address:



    <DD><input type=text name="email" size=30>



<DT>Your Company Name:



    <DD><input type=text name="Company" size=30>



<DT>Your Phone:



    <DD><input type=text name="Phone" size=30>



<P>



<DT>Message:



<DT><TEXTAREA name="comments" cols=60 rows=3></TEXTAREA><p>



</DL></I>



<DT><input type=submit value="Send This Form">



<input type=reset value="Start Over">



<P>



</FONT>



</FORM>



<HR>



Please note: Although it is most unlikely that you will experience any problems responding to



this form, certain non-standard browsers will not respond properly. If you experience any difficulties,



(or if you are not using a forms-capable browser) you may email your response to this form to:



<a href="mailto:hampton@ha.net">hampton@ha.net</A>.



</BODY>



</HTML>

Now, let’s make sure you know what all this code means. Everything should look familiar until you get to the <FORM> tag, as in

<FORM ACTION="/cgi-bin/formmail.pl" METHOD=POST>

The <FORM> tags are used to define a fill-out form for processing by the HTTP server. All forms must be within these tags. You can include multiple forms within a document, but you cannot nest the forms (you cannot include a <FORM> tag within a <FORM> tag). Also, the <FORM> tag does not specify the layout of the form; you have to add regular HTML tags within the form to do that. Attributes for this tag are the following:

• ACTIONDescribes the URL of the query server to which the form contents will be submitted in our example:

  /cgi-bin/formmail.pl

• ENCTYPESpecifies the encoding of the form contents. Only applies if the METHOD attribute is set to POST. We do not use this tag in our example.
• METHODSubmits the form to the query server (which method you use depends mostly on your server). Options for this attribute are

  POST Used in our example, this option causes the form contents to be sent to the server in a data body (not as part of the URL).

  GET Causes the form contents to be appended to the URL as if it were a normal query. GET is the default, yet for most purposes POST is preferable.

---

Note

As with all newer HTML tags, it is very important to test your tables in different browsers before posting them on your site. Remember: All your table formatting will be lost in a non-tables-compatible browser.

---

As with any complex problem, the best way to learn tables is by example, and what do you know, we just happen to have one right here. First off, we should decide the goal (format) for our tables. In this case, we want our tables to look like the ones in Figure 10.6.

Figure 10.6. The goal of our table example.

To achieve this goal, we will use the code in Listing 10.2.

Listing 10.2. A simple table.

<TABLE ALIGN=RIGHT BORDER=3 BORDERCOLOR=#4682B4 WIDTH=30%>



<CAPTION ALIGN=TOP VALIGN=TOP>The caption here</CAPTION>



<TR>



<TH BGCOLOR=#4682B4>Head 1</TH>



<TH BGCOLOR=#4682B4>Head 2</TH>



<TH BGCOLOR=#4682B4>Head 3</TH>



</TR>



<TR>



<TD>info a</TD>



<TD>info b</TD>



<TD>info c</TD>



</TR>



</TABLE>

Now let’s make sure you understand what this code means.

The first element in the table is the <TABLE> tag itself . This tag is just telling the Web browser that what follows is to be laid out as a table.

In our example we use the following attributes for our <TABLE> tag:

• ALIGN=This specifies the alignment of the table as in:

  <ALIGN=RIGHT>

  Other possibilities for this attribute include ALIGN=LEFT and ALIGN=CENTER.

• BORDER=This causes a border to be placed around the table, specified by a numerical value. In this case,

  <BORDER=3>

  causes a border to be placed around the table 3 pixels wide.

• BORDERCOLOR=This defines the color of the border (A Microsoft Internet Explorer 3.0 attribute), as in

  <BORDERCOLOR=#4682B4>

  You can either use a hexadecimal color (as in our example) or use one of Microsoft’s specified color names (for example, BORDERCOLOR=RED). This attribute must be used in conjunction with BORDER=; otherwise, there is no border to color.

• WIDTH=This specifies how wide the table will be, either in pixels or as a percentage, as in

  <WIDTH=30%>

  Other attributes you could use for the <TABLE> tag include BACKGROUND, BGCOLOR, BORDERCOLORDARK, BORDERCOLORLIGHT, CELLSPACING, CELLPADDING, FRAME, HEIGHT, RULES, and VALIGN.

See the HTML reference, Appendix H of this book, for a full explanation of these tags.

The next tag in our example table is the <CAPTION> tag, which can be used to put a label on your table.

In our example we use the following attributes for our <CAPTION> tag:

• ALIGN=Used to align the caption, as in:

  <ALIGN=TOP>

  Other possibilities for this attribute include BOTTOM, LEFT, RIGHT, or CENTER.

• VALIGN=Instructs whether to place the caption on top or below the table, as in VALIGN=TOP or VALIGN=BOTTOM.
• <TR>Stands for Table Row and contains a row of table cells. All tables must include at least one <TR> element. Attributes for <TR> can include ALIGN, BACKGROUND, BGCOLOR, BORDERCOLOR, BORDERCOLORLIGHT, BORDERCOLORDARK, COLSPAN, NOWRAP, ROWSPAN, and VALIGN.
• <TH>Identifies a table heading cell. We used the BGCOLOR attribute, which can be defined as a hexadecimal value or by name as it appears in our example:

  <TH BGCOLOR=#4682B4>Head 1</TH>

  Other attributes for this tag include ALIGN, BACKGROUND, BORDERCOLOR, BORDERCOLORLIGHT, BORDERCOLORDARK, COLSPAN, NOWRAP, ROWSPAN, and VALIGN.

• <TD>Used to define a table data cell, as in

  <TD>info a</TD>

  Attributes for this tag are the same as for the <TH> tag.

And that’s about it for our tables code example! Figure 10.7 shows how it turned out. (Remember, testing is critically important, especially when using rare or new HTML tag and attributes.)

Figure 10.7. How our table turned out.

The tables template on your CD-ROM will be your best tool in designing tables of your own. Find one which is close to your goal, and simply adapt it for your use. Appendix H lists additional tags that can be used for tables.

We’ve mentioned some tricks throughout the book, and the point in discussing the attributes of HTML is so that you can figure out your own cool tricks, but there are a few techniques we want to mention that will help give your pages a polished look if you are in a rush.

Using Background Tiles

The BACKGROUND =”filename.???” attribute in a body tag enables you to place an image behind the page contents (which is why it’s called a background). This can be a great tool if used wisely, and the downfall of a page if used poorly.

The browser will take your image and tile it—which means it will place it over and over again to fill the page. Obviously, you’ll want to use a graphic that can be tiled so as to look like a complete image, as opposed to one that is obviously bordered. Here are some other tips:

• Don’t use complex patterns—they will make the text of your page difficult to read.
• Don’t use wild colors if you plan on placing text—again, it’s difficult to read.
• If you are using a gradation or color change, make sure that your text will contrast the area over which it will be placed (see the tip on tables, below).
• Make tiles as small as possible—this will save bandwidth.
• Make any horizontal tiles at least 1024 pixels wide to accommodate monitors set for this resolution.
• Don’t use long vertical tiles unless you’re absolutely positive that the page content won’t reach the bottom of the tile on any window size.

Using Tables to Layout a Page

You can use tables (usually with the border set to 0) to lay out your entire page. Since you will probably want to avoid placing text within the sidebar, this technique becomes especially useful if you want to use a background with a sidebar as illustrated in Figure 10.8.

Figure 10.8. Using background tiles and tables.

The example shown is Figure 10.8 is accomplished with the code in Listing 10.3.

Listing 10.3. Setting a table to work with a background tile.

<HTML>



<HEAD><TITLE>A COMPANY</TITLE>



</HEAD>



<BODY BACKGROUND="back3.jpg" LINK="#800000" VLINK="#000080" ALINK="#FF00FF">



<TABLE BORDER=0>



<TR>



<TD><IMG SRC="spacer.gif">



</TD>



<TD>



<CENTER>



<H1>A Company</H1>



</center>



<H3>A Company is widely recognized as being the very best at whatever it is we do.  With awards from lots of people, we believe that we've earned our reputation for excellence.



<P><I>To learn more about us, please choose from the following list of items:<I><P>



<A HREF="1"><IMG SRC="icon.gif" border=0 align=top>PRODUCTS</a><P>



<A HREF="2"><IMG SRC="icon.gif" border=0 align=top>PEOPLE</A><P>



<A HREF="3"><IMG SRC="icon.gif" border=0 align=top>CORPORATE HISTORY</A><P>



<A HREF="4"><IMG SRC="icon.gif" border=0 align=top>ORDERING</A><P>



<A HREF="5"><IMG SRC="icon.gif" border=0 align=top>SPECIALIZED SERVICES</A><P>



<A HREF="6"><IMG SRC="icon.gif" border=0 align=top>CONTACTING US</A><P>



</H4>



<HR SIZE=5>



</TD>



</TR>



</TABLE>



</BODY>



</HTML>

As you can see, the left column of the table was sized using a transparent GIF. This kind of “spacer” GIF is also useful in placing graphics in relation to each other, as shown in Figure 10.9.

Figure 10.9. Using spacer GIFs.

This was achieved with the code in Listing 10.4.

Listing 10.4. Using tables to format graphics.

<TABLE BORDER=0>



<TR>



<TD><IMG SRC="spacer.gif">



</TD>



<TD><IMG SRC="spacer.gif"><IMG SRC="spacer.gif"><IMG SRC="ball.gif">



</TD>



</TR>



<TR>



<TD></TD>



<TD><IMG SRC="spacer.gif"><IMG SRC="ball.gif">



</TD>



</TR>



<TR>



<TD></TD>



<TD><IMG SRC="ball.gif">



</TD>



</TR>



</TABLE>

These elements are rendered with a monospaced font and preserve the layout defined by spaces (like this) and line break characters.

These are used in HTML 3 to group related items together and can be used with the ALIGN attribute, as in: <DIV ALIGN=LEFT>

This is used in HTML 3 to center text contained within the tags.

This is used for long quotes or citations and is usually rendered with indented margins.

This is used to define a fill-out form for processing by the HTTP server. Attributes include ACTION, METHOD, and ENCTYPE. More on forms is presented in Chapter 11, “Integrating HTML with CGI.”;

These place a line across your page and do not have an end tag. Attributes include ALIGN (HTML 3), NOSHADE (HTML 3), SIZE (HTML 3) and WIDTH (HTML 3).

This is an HTML 3 tag. Every table can begin with an optional CAPTION followed by one or more <TR> elements, which define the table’s rows. Every row has one or more cells that are defined by <TH> or <TD> elements. Common attributes include WIDTH, ALIGN, BORDER, CELLPADDDING, and CELLSPACING. (More on tables later in this chapter.)

Text-level elements enable you to change the characteristics of the text contained within them. These can be very useful for distinguishing blocks of text or for emphasis.

---

Note

These elements do not cause paragraph breaks.

Font Style Elements
These elements all require starting and ending tags and include

< B>	Bold
< U>	(HTML 3) Underlined
< TT>	Monospaced text or teletype
< I>	Italics
< BIG>	(HTML 3) Large font
< SMALL>	(HTML 3) Small font
< SUB>	(HTML 3) Subscript
< SUP>	(HTML 3) Superscript
< S>	(HTML 3) Strike-through text
< BLINK>	(Netscape 1.0) Blinking text

The Font Element <FONT> and </FONT>
This HTML 3 element enables you to change the font color, size, and face of the enclosed text. Colors are defined in hexadecimals, or one of the understood color names. Attributes are COLOR (Netscape 2.0), SIZE and FACE (MS IExplorer). Some examples of this tag’s uses are

<FONT SIZE=+1>This font is bigger than the previous</FONT>



<FONT COLOR="#FF0000">This text is red</FONT>



<FONT FACE="Lucida Sans,Arial,Times Roman"> This text will be in either Lucida Sans, Arial, or Times Roman, depending on which fonts are installed on the viewers system, trying each in order.</FONT>

Phrase Elements
These all require starting and ending tags and include

< STRONG>	Strong emphasis, generally rendered in a bold font
< DFN>	Defining instance of the enclosed term
< EM>	The basic emphasis, normally rendered in an italic font
< CODE>	Used for extracts from program code
< KBD>	Keyboard, used for text to be typed by the viewer
< SAMP>	Used for sample output from scripts, programs, and so on
< VAR>	Used for variables or arguments to commands
< CITE>	Normally used for citations or references to other sources

Special Elements

Last but not least, these special elements can also be included in an HTML document.

The Anchor Element <A> and </A> 

This element defines hypertext links. Attributes include NAME, HREF, REL, REV, METHODS, URN, and TITLE.

NAME is used to associate a name with a part of a document that can be linked to, like this:

<A NAME="chapter1">Chapter 1</A>

You can create a link from within the page to this part of the document by using this code:

<A HREF="#chapter1">Jump to Chapter 1</A>

HREF is also used to define the URL of your linked image or document. A common usage looks like this:

<A HREF="http://www.hampton.org/index.html">Jump to hampton.org</A>

---

Note

If you are linking to documents stored on the same machine, you can simply link to the directory rather than naming the entire URL:

<A HREF="/products/widget.htm">This links to a page named widgets, which exists in the products directory</A>.

---

An anchor must include a NAME or HREF attribute, and may include both. REL, REV, TITLE, METHODS, and URN are attributes that are not commonly used.

The Line Break Tag <BR> 

This tag is one-sided and is used to force a line break. Unlike the <P> tag, the <BR> tag can be used over and over, resulting in a carriage return with each use. (The <P> tag is usually ignored if there is no code between successive uses.)

The Image Tag <IMG> 

This tag inserts images into the document and requires no ending tag. Common attributes include SRC, ALT, ALIGN (HTML 3), HEIGHT (HTML 3), WIDTH (HTML 3), BORDER (Netscape 1.0), VSPACE (HTML 3), HSPACE (HTML 3), USEMAP (HTML 3), ISMAP (HTML 3), and LOWSRC (Netscape 1.0). A common usage looks like this:

<IMG SRC="flower.gif" ALT="[A Flower]">.

More on the image tag in Chapter 12, “Working with Graphics.”;

The Applet Tag <APPLET> and </APPLET> 

This tag is an HTML 3 specification and is supported by all JAVA-enabled browsers. It enables you to embed a JAVA applet into an HTML document. The contents of the element are used as a backup if the applet can’t be loaded; it also uses associated PARAM elements to pass parameters to the applet. Attributes include CODE, CODEBASE, NAME, ALT, ALIGN, WIDTH, HEIGHT, VSPACE, and HSPACE. We discuss the applet tag more in Chapter 18, “Bells and Whistles.”;

The Image Map Tag <MAP> and </MAP> 

This HTML 3 tag enables the definition of client-side image maps and contains one or more AREA elements used to define the hot zones (linked areas) on the associated image and to bind the hot zones to specified URLs. We will discuss image mapping much more in Chapter 12.

The best way we have found to learn and absorb how HTML works is to study others’ code. Get on the Web, find cool pages, look at their source code (view source in Netscape), and see how it works. Compare the page on your browser to the source code. See how each tag affects the page.

Appendix H, “Comparative HTML Reference Guide,” will be useful when you are designing your page from scratch or finding out what a particular tag does when investigating others’ code. Another great tool for learning HTML is the shareware HTML Library included on your CD-ROM. It enables you to look up code in many different ways and can be invaluable to the beginner.

These tags contain within them the contents of the document (tags and the text) and HTML can be used to describe optional attributes of the document, such as the following:

• =”?”
• (HTML 3) This attribute describes the name (if within the same directory) or URL of the graphic which will be tiled to create a background for the page. The viewer will not see this image if they are using a noncompliant browser, if they have chosen the option of overriding background images, or if their image loading is turned off. Never use in conjunction with the BGCOLOR attribute.

• BGCOLOR=”?”

• (HTML 3) This attribute defines the background color of the page, which is specified using a hexadecimal color code (for example, white = “#FFFFFF”). The color wizard included in the HTML library on the CD-ROM is a very useful tool for determining these codes. You can also use a few select color names for this attribute: blue, fuchsia, gray, green, lime, maroon, navy, purple, olive, aqua, black, silver, red, teal, white, and so on. Never use in conjunction with the BACKGROUND attribute.
• TEXT=”?”
• (HTML 3) This attribute describes the document’s text color (in hexadecimal code or by name).
• LINK=”?”
• (HTML 3) This attribute describes the color of textual links in hexadecimal code or by name.
• VLINK=”?”
• (HTML 3) This attribute describes the color of previously visited textual links (in hexadecimal code or by name).
• ALINK =”?”
• (HTML 3) This attribute describes the color of an active textual link (in hexadecimal code or by name). This is the color that appears while the user is selecting the link (for a split second).

A common <BODY> tag looks like this:

<BODY BACKGROUND="backrd.gif" LINK="#0000FF" VLINK="#0000A0" ALINK="#FF00FF">

Block Elements

Block elements define the placement and treatment of text blocks. These can include paragraph structure, list structure, and other text formatting.

---

Note

All of these elements cause paragraph breaks.

---

Headings are always closed with a closing tag (for example, </H1>). H1 stands out the most (is the largest heading in most browsers), and H6 stands out the least (the smallest heading). In HTML 3, you can set an alignment for your heading like this:

<H1 ALIGN=CENTER>This heading is centered</H1>

Paragraphs <P>

This one is tricky. Different versions of HTML use paragraph tags differently. Originally, this tag was used as a one-sided tag and was placed at the end of a paragraph as a paragraph break (a double-return). HTML 2 and 3 indicate its use as a two-sided tag, with the <P> tag going at the beginning of the paragraph and the </P> tag being optional at the end. We never use this </P> tag; it doesn’t seem to make a difference in how the paragraph is displayed and seems unnecessary work to us. We therefore use the <P> tag as a paragraph break at the end of a paragraph (as we always have) and leave it at that. Some people recommend getting into the habit of placing your <P> tags at the beginning of the paragraph because it may become a standard; we have just gotten used to using the tag at the end and we have seen no reason (yet) to change. With this information in mind, use your own judgment in regard to where to place your <P> tag.

List options create the automatic numbering, bulleting, and/or indentation of list items. Different list options treat the enclosed text differently and can be useful when presenting long lists or important items.

Unordered Lists <UL> and </UL>

An unordered bulleted list contains one or more <LI> elements, which represent individual list items. Netscape adds a type attribute to this, which can describe whether the bullet used is a circle, disk, or square, and is used like this: <UL TYPE=circle>. Here’s an example:

<UL>



<LI> First item in the list



<LI> Last item in the list



</UL>

Ordered Lists <OL> and </OL>

An ordered list (1,2,3,) contains one or more <LI> elements, which represent individual list items. Netscape adds a type attribute to this to specify whether the list items are marked with: capital letters (TYPE=A), small letters (TYPE=a), large roman numerals (TYPE=I), small roman numerals (TYPE=i), or numbers (TYPE=1—the default—is usually numbers). Here’s an example of code that will make a lettered list:

<OL  TYPE=A>



<LI> First item in the list



<LI> Last item in the list



</OL>

Definition Lists <DL> and </DL>

A definition or glossary list contains <DT> elements that give terms, and <DD> elements that give the corresponding definitions. It is commonly used like this:

<DL>



<DT> Term to be defined #1



<DD> Definition of term #1



<DT> Term to be defined #2



<DD> Definition of term #2



</DL>

However, those bugs can usually be avoided through the use of clear HTML programming, which is what this chapter discusses.

---

Note

A comparative list of HTML tags is included in Appendix H, “Comparative HTML Reference Guide.”

---

The first thing you should take into consideration when designing HTML documents is that HTML describes the content and structure of the page, and not the appearance. If you are used to working with WYSIWYG (What You See Is What You Get) text editors like PageMaker or even Microsoft Word, you may be sadly disappointed with the lack of control over the final output that HTML provides.

Rather than describing exact page placement (as in exact X,Y coordinates), HTML describes the structure of the page by using HTML tags—it’s almost as if it’s giving the browser hints instead of solid commands. For instance, instead of enlarging the title text, you enter the text with the tag <H1> before the text, and </H1> after the text. This tells the browser to display this text as a large heading (which may look different on different browsers, but will always be larger and bolder than text without these tags). This is one of the main reasons it is so important to test your pages on different browsers and make sure they look good on all platforms (more on this in Chapter 19, “Getting It Up and Running”).

Many programmers see this lack of control as a major hurdle when designing the layout of their pages; we have found that there are ways around most of these layout limitations, which we will describe to you as this book progresses.

---

Note

It is one of your jobs to use as little HTML code as possible. This is not to say that you should be creating simple, sparse pages and sites, but that you should try to remove all unnecessary tags—they are a constant problem with many “simple to use” Web page creation software applications. The only way you’ll be able to do this is if you understand what each tag means.

---

HTML files are just ASCII text files with special commands (tags); they look like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">



<HTML>



<HEAD>



<TITLE>Your title here</TITLE>



</HEAD>



<BODY>



<H1>Welcome to a basic HTML document</H1>



This is a basic HTML document.



</BODY>



</HTML>

The text within the brackets describes the structure of the regular text (as in Figure 10.1).

Figure 10.1. A basic HTML document.

For example, if the title of your page is My Home Page, and you want that displayed as large, italicized text, your code for that would be: <H1><I>My Home Page</I></H1>. You’ll notice that you not only must define the text at the beginning, but in many cases you must also turn that definition off with an ending tag. Ending tags are defined with a slash (/) before the description; this tells the browser to discontinue that format; otherwise, the rest of your entire page will be in that style. An HTML element will include a tag name, may include some attributes and some text or hypertext, and will appear in an HTML document in one of three ways:

<tag_name> your text </tag_name>



<tag_name>



<tag_name attribute_name=argument> your text </tag_name>

So, the best way to start an HTML file is to write out all of your content in a text editor and then go back adding HTML tags.

This tag is the first to appear and is used to declare which HTML version your page is using:

• For HTML 2.0, use <!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>.
• For HTML 3.0, use <!DOCTYPE HTML PUBLIC “-//W3O//DTD W3 HTML 3.0//EN”>.
• For HTML 3.2, use <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2//EN>.

All of your text and HTML tags go within the HTML tags. This tag indicates that the file is an HTML document—it’s telling your browser what to expect.

These tags contain within them your document head elements, such as the following:

• <TITLE> and </TITLE> contain the document title. (Note: This is the title of your HTML page and appears within the browser but not as text on your page.)
• <ISINDEX> (optional) is used for simple keyword searches. It specifies that the current document describes a database that can be searched using the index search method appropriate for whatever browser is being used to read the document.
• <BASE> (optional) specifies the name of the file in which the current document is stored. It is useful when link references within the document do not include full pathnames (that is, are only partially qualified).
• <LINK> (optional) is used to define the document’s relationship with other documents.
• <META> (optional) is used to supply meta-information, and is often used to associate keywords to your documents (readable by search engines). Meta-information is generally in name/value pair form.
• <!– –> (optional) can be used anywhere in your document to place a comment within the HTML code. A comment affects the document in no way other than enabling you to place a comment within it. The most common use for this is within the < HEAD> tag for providing information about the document, such as

<!--Author: you -->

A common head element looks something like this:

<HEAD>



<TITLE>A common head element</TITLE>



<!-- Author: Kim and Brad Hampton -->



<!-- Revision: 2.0 08/08/96 -->



<META Name="description" Content="A common head element,



including the META tag!  Associate keywords to your Web documents!">



<META Name="keywords" Content="A common head element, HTML, HEAD, META, TITLE, keywords, taking advantage of HTML, Website, Kim Hampton, Brad Hampton, commercial web sites">



</HEAD>