Eric's Tips: Imagemaps, Forms, and CGI Tips

ERIC'S TIPS FOR WEB AUTHORS

Imagemaps, Forms, and CGI Tips

Don't use imagemaps if you can create the same results with standard HTML. Not only is an imagemap useless on a text-only client, it is a waste of CPU and your readers' time if the imagemap isn't a "value-added" element. In other words, your imagemaps should offer a "twist" that cannot be accomplished with "vanilla" HTML. Imagemaps that are basically text-only buttons don't add anything to your pages except delays (I call them "imagemaps for the sake of imagemaps.").
Some good examples of creative and functional imagemaps are the Apple Computer Home Page and The Virtual Macintosh (although it may violate Apple's copyright).
Be sure to allow sufficient spacing between imagemap elements. It will frustrate readers if they accidentally end up somewhere they didn't want to go because the imagemap had several hotspots right next to each other. Mouse usage isn't an exact science--most people have gotten used to getting the pointer in the general neighborhood then clicking. So add enough "gutter" space between hotspots so that a person would have to be CUI (Clicking Under the Influence) to accidentally select the wrong element.
Don't be too precise with imagemap definitions. It's a common mistake to create an imagemap that requires a reader to hit the bullseye before activating. You should define your polygons and circles so they are larger than the elements you want to use for hotspots. A good rule of thumb is to define them so they will touch the boundary of the neighboring hotspot. That will give a larger room for error and cut down on the "dead" areas of the imagemap (regions of the image without a hotspot).
When using multi-line text entry fields in your forms, encourage readers to limit line lengths. Unlike the <INPUT TYPE="text"> method (which creates a one line text entry), the <TEXTAREA> tag does not support the MAXLENGTH attribute. That means you cannot limit the number of rows or columns a reader may type in a text area. This can result in hard to read output. As an example, a comment form output may look something like this:
```
Dear Eric,

I have really found your Home Page Construction Set to be a
worthwhile addition to
my personal bookmark list. I used to have a really lousy,
slow loading page until
I surfed to your tips pages. I have already recommended it
to my family, friends,
and strangers on the street. Spectacular job!
```
To avoid this, be sure to specify a conservative field width and to ask users to press enter when they reach the right edge of the field. Again, there is no way to prevent them from typing beyond the right margin of the field (it will scroll to follow the cursor), but asking never hurts.
You might try something like this:
```
<FORM METHOD="POST" ACTION="/cgi-bin/post-query">
Do you have any comments?<BR>
Please type them below, pressing Enter at the right edge of the box.<BR>
<TEXTAREA NAME="comments" ROWS="2" COLS="65">
</TEXTAREA>
</FORM>
```
Do you have any comments?
Please type them below, pressing Enter at the right edge of the box.
Now readers will be much less likely to exceed the margins when they know when they should start a new line!
Avoid the temptation of putting access counts on your pages. While it is in vogue to display a hit meter on pages lately, here are some points to consider.
- Announcing hit totals really only serves two purposes. First, it makes the page author feel good that his or her page is popular (ego boost). Second, it seeks to persuade readers that the page is popular and that they should see why everyone's loading this page. Both of these reasons are pretty weak, IMHO. If you create good pages, the real recognition will come in the form of readers' complements, people linking to your pages, or increased sales (if your pages are commercial). These are more valid and valuable ego boosters than a hit count. Similarly, if your pages are attractive and useful, you won't need a counter to persuade readers to stay a while.
- A low hit count can have a negative effect. If you get 18 hits in a month, A.) you're likely to become depressed and B.) readers are likely to assume your page stinks. In other words, your counter can backfire on you.
- Is it important to a user if she or he is the 18,342nd visitor to your site? Probably not, so why waste CPU on your server and increase download time by creating on-the-fly updates to your count total? If you really want to include an access count, perhaps a nightly update is more appropriate.
Do keep track of accesses and other statistics. While I recommend against including an on-the-fly access count on your pages, I do suggest that you collect and analyze the access and browser statistics for your pages. You can use these numbers to tailor your pages and/or server for optimal performance.
If you have access to your server's httpd log information, it is easy to find the statistics on your pages and server. If your Webmaster has not summarized this information already, you can use a tool, such as wwwstat (Unix Perl), to produce detailed summaries of all accesses. Richie B's ref-counter and agent-counter summarize NCSA httpd 1.4 referrer_log and agent_log files using Perl (Note: slow links).
If you do not have access to the daemon logs, you can still keep track of accesses by using iAudit. This is a new service, which provides detailed access information on your page for free. You don't need CGI access or any special permissions. All you have to do is set up a free account with iAudit and add a line to the bottom of your document. The catch? While iAudit is free to you, it is a commercially sponsored service, so you might have to put up with a company's logo at the bottom of your page (this is explained further in the iAudit Terms and Conditions).

[ Previous Topic | Tips Table of Contents | Home Page Construction Set ]

Last Modified: August 12, 1995
/ Eric Sasaki
gt7294b@prism.gatech.edu (feedback welcome)