Webmasters looking to refine their troubleshooting techniques should consult the works of Sir Arthur Conan Doyle. Though no Internet expert, the turn-of-the-century author's primary character, detective Sherlock Holmes, possessed traits now essential to modern-day site sleuths. Holmes could crack a case by looking at a speck of mud on a suspect's shoe or spying a stray paint chip under a fingernail. Through the art of association and impeccable attention to detail, he solved even the most confounding mysteries.

"Webmasters have to be part detective," says Kevin Broderick, a network specialist who monitors and troubleshoots networks for the University of Washington and NWNet, a regional network service provider (NSP) located in Seattle, Washington (U.S.A.). "They need to be able to check the broadest possible problems first, then work their way down into more detail through a process of elimination."

Because any number of issues -- from obscure coding oversights to obvious network connectivity problems -- can render a Web site inaccessible, Broderick thinks troubleshooters need to understand both the structure of the site and the Internet's end-to-end connection. The trick is knowing where to look for clues.

Before You Go Live: HTML Basics

Of course one of the best ways to manage problems -- Web-site related or otherwise -- is to prevent them from happening in the first place. Careful attention to detail when you're building your site will save headaches later. In working with HTML, one forgotten parenthesis or a single misplaced quotation mark can skew the appearance of a site or make it completely unreadable.

There are automated HTML validation tools available to check your code for the kinds of mistakes noted above; a couple are Spyglass HTML Validator (which is not customizable, but has an easy-to-use interface) and CSE 3310 (which is not as immediately user-friendly, but is highly customizable). To find others, you can start with Yahoo's computer section under "Validation and Checkers".

Dan Shepherd, a principal at Emergent Media, Inc., a Pacific Northwest firm that specializes in Web-site technical development, offers the following check points for HTML troubleshooters:

• Make sure graphics files are uploaded to the server. Because graphics files are separate from HTML files, it's easy to forget to upload both to the server. Without the graphics files, your page will show all the text, but the images will be missing.

• Understand the page's linking structure. "Some ISPs (Internet service providers) have Web server directory structures that use a 'virtual root' or a special path for different Web sites housed on the same machine," says Shepherd. "If your site is housed at an ISP, check with them about how to reference your URL."

• Name files with lower-case letters. Shepherd advises keeping all your filenames in lower-case letters to avoid problems with character- or case-sensitive operating systems like UNIX. And don't use spaces in your filenames. Instead, use underscores ( _ ) or dashes (-) to separate words.

• Check all links before your pages go live. "Make sure all links to your site's sub-pages work," says Shepherd. "And check links back to 'home' and the navigational menu bars on all of your sub-pages." Also remember to check internally referenced links such as "Back to Top."

• Know your ISP's default page extensions. A default file is the page that comes up when you type in a URL. Different servers require different default file extensions. Webmasters need to determine their ISP's default extensions and make sure their pages match or they won't be accessible.

• Check table tags. Indent all table tag coding. "It will make it easier to reference and to check to see if you've missed a tag later on," explains Shepherd. Avoid multiple sets of embedded tables because there's more chance for error. And remember that all tables require a closing tag.

• Watch typos. Improper characters and spaces, or using curly quotes instead of straight quotes, can screw up your coding.

• Test your design on different browsers and machines. Microsoft® Internet Explorer and Netscape®'s browsers read and display HTML differently. Internet Explorer has features that Netscape can't read and vice versa. Be aware of what browser you're designing for, and compare the way your site looks on more than one browser, on a PC and a Macintosh, and on different screen sizes.

• Keep the size of your page (including graphics) under 100K. A smaller file size ensures more reasonable download times.

After You Go Live: A Case of Connectivity

If you're certain your code is both immaculate and intact, and you still can't see your Web site when you type in the URL, it's possible that your connection to the Internet is down. Broderick says the first step is to make sure the power to your computer and your modem is on. "You'd be amazed by how many people call us for help only to find that a power switch is off or a machine is unplugged," he says.

Once you are sure that the power is on, the next step is to make sure that you typed your URL correctly. The steps that follow assume you are using an Internet service provider (ISP) to host your site rather than operating your own Web server. If you use an ISP, you can probably call for technical support. But Broderick suggests doing some troubleshooting first. "The more a Webmaster knows," he says, "the more quickly a technician can help. Besides, some ISPs actually charge for help calls."

To troubleshoot your Web site hosted by an ISP, follow these steps (not necessarily in this order):

• Make sure you are connected to the Internet. Try connecting to a site that is not on your server to make sure you can actually go out on the Internet. If not, check your local connections (computer, modem).

• Try to access other Web sites hosted by your ISP. If you can see other pages on your ISP's server, check with them to make sure your pages are still on their server, that they haven't been deleted, or that the disk hasn't crashed.

• Check the error message. If you received a "server not responding" error message, it probably means your ISP's server is down. Call the ISP to determine the server's status.

  Other error messages: A "file not found" message could mean you've typed the URL incorrectly. "Host/server busy" means the server is overloaded with users or has crashed. "Page not found" means the URL is wrong or someone has deleted the page from the server.

• Have patience. If an ISP technician tells you that there's a problem with the network service provider (NSP) or at one of the Internet backbones (such as Sprint, MCI, UUNet), there's not much you can do but wait it out. Ask your ISP to keep you posted.

CSE 3310: http://htmlvalidator.com/

Spyglass HTML Validator: http://www.spyglass.com/

Yahoo's computer section under "Validation and Checkers": http://www.yahoo.com/Computers_and_Internet/Information_and_
Documentation/Data_Formats/HTML/Validation_and_Checkers/

HTML: Acronym for Hypertext Markup Language, the directions (or coding) that tell your browser how to display the text and graphics on a Web page.
[Back]

URL: Acronym for Uniform Resource Locator. An address for a resource on the Internet. URLs are used by Web browsers to locate Internet resources. A URL specifies the protocol to be used in accessing the resource (such as http: for a World Wide Web page or ftp: for an FTP site), the name of the server on which the resource resides (such as //www.whitehouse.gov), and, optionally, the path to a resource (such as an HTML document or a file on that server).
[Back]

Page size: The size of your .HTM file (where your page is saved) determines how fast a server can download it to users who are trying to read it on the Web. The larger your page size, the longer readers have to wait for it to load. Long wait times = not many readers.
Text doesn't take up much space in a file. Graphics -- even simple ones -- can use up a lot of space in a hurry. Use them sparingly.
[Back]