TIP: Transfer HTML documents and other text-based files in ASCII mode, and transfer graphics, sounds, and executable programs in BINARY mode.
When uploading or downloading HTML files using an FTP (File Transfer Protocol) program, always use ASCII mode rather than BINARY. The reason for this is that different operating systems vary in how they represent line breaks. MS-DOS and Windows systems use a carriage return followed by a linefeed (ASCII characters #13 and #10) at each line break, which is the traditional standard dating back to 1960s Teletypes which needed both characters to get the terminal to both move the carriage to the left margin and move down a line. Developers of some operating systems have decided that this is wasteful and a single character would suffice, but unfortunately they weren't consistent: UNIX ended up using a linefeed (#10) alone (which Unix developers refer to as a "newline" character), while Apple computers (both the old Apple II line and the Macintosh) chose the opposite course of using a carriage return (#13) by itself.
The result is that there are three different ways of denoting the end of a line, and software can fail if faced with a file that is delimited in a manner different from your operating system's convention. For instance, Windows Notepad will discard all line breaks if they're nonstandard, producing a file that's all on one line. (Perversely, this Notepad bug doesn't show itself until you've first loaded the file, which looks fine initially, then saved it; at that point, the line breaks collapse so the next time you load the file it will be messed up.) To avoid these problems, the FTP protocol was developed with an "ASCII mode" that converts line breaks to the appropriate style for the destination system. When you're sending from a UNIX server to a Windows PC, it adds a carriage return before each linefeed. Transferring the other way, it strips the carriage return. Transferring from UNIX to a Mac, it converts the linefeeds to carriage returns. Thus, the integrity of the file is maintained no matter what systems it's transferred between.
It's possible that file transfers in ASCII mode may perform other conversions depending on your system. Perhaps special extended characters will be converted from your system-specific values to the ISO standard (see my section on character sets). If so, this may enable you to edit text files with special characters in your word processor and store them in a manner that works on the Web, but watch out for unwanted conversions of characters you didn't want to alter. Check your FTP program's documentation for details.
Be sure to use BINARY mode instead if transferring non-text-based files such as graphics, sound files, and executable programs. Most FTP programs let you set extension recognition to use the proper mode for different file types. Set it to use ASCII mode for .htm, .html, and .txt files, and any other text-based files you may be using: style sheets (.css), image-map data (.map), CGI scripts in PERL or UNIX Shell (.pl, .sh, .cgi), program source code (.c, .h, .pas, .java), etc., and use BINARY mode for everything else (.gif, .jpg, .jpeg, .exe, .wav, .class, etc.)
If your Web site is trying to communicate information about a subject, it may detract rather than enhance this if you try to "show off" by loading it with Java applets, animated GIFs, blinking text, a kaleidoscope of colors and fonts, a profusion of frames and tables, a MIDI background sound with a stolen pop-song melody you hope you don't get sued over, and every other fancy trick you've learned how to do. But does your Web-based chart of the schedule of your upcoming convention really gain anything by having an embedded applet giving the current time in Outer Mongolia? Unless the whole purpose of the site is to show off your bag of Web tricks, it may be better to "keep it simple, stupid!" (the [in]famous "KISS Principle") and stick to the content, presented in a straight, logical manner, with a few carefully-chosen visual enhancements designed to emphasise the important parts of the site rather than distract the user from them.
It can be a big turn-off to a user when, upon entering a site, there are long delays with status messages like "Loading Applet", "Loading Plug-In", etc.; some popular browsers implement such things so poorly that the user loses control of his/her browser for an indefinite period while all the fancy stuff loads and initializes, unable even to scroll in the page or use the "Back" button to get out of it. And sometimes the browser even crashes, especially if memory or disk space is getting low. Are your "snazzy" effects really worth that?
A guestbook is a feature, present on many Web pages, that lets a user type comments which get posted to a page on the Web site, so that visitors can see what comments other visitors have written and leave notes of their own. It's kind of like a graffiti wall. (See my guestbook!)
A reply form, on the other hand, is a form users can fill in to leave a private message to the Webmaster. They're used on many sites to let users give feedback to the developer, as well as on commercial sites to let potential customers request more product information, etc.
Many Web sites, though, have a link labelled "guestbook" that actually goes to a reply form which sends information to the developer, not to a publicly-posted page. This is sloppy and misleading terminology. I can understand why some sites (especially commercial ones) would prefer not to have a public guestbook where people might post nasty or obscene stuff that would reflect badly on their business, but they shouldn't claim to have a "guestbook" in that case. "Feedback" or "Reply Form" would be a better link title. (However, I've actually run into some sites with so-called "guestbooks" that aren't even feedback forms -- they simply have fields to type your name and email address, or maybe your postal address too, but no place to write any sort of comments. They're just a means of attempting to harvest addresses of suckers to spam, probably. (On the other hand, real guestbooks are increasingly becoming targets of spam, especially when they let people post Web links... a distressingly high proportion of guestbook entries these days tend to be links to porn or make-money-fast scams, with generic comments like "Nice site!" pasted in to make them seem like real feedback.)
If you're wondering how to set up a guestbook or a reply form in your site, this goes beyond the scope of these Web tips; it involves use of a CGI script rather than just simple HTML. You'll have to check with the administrator of your server to find out what scripts are available for your use; there may be response form or guestbook scripts already in place, and the administrator can tell you what you have to do in your HTML documents to refer to them.
Make your site better by looking at other sites that show, by example, what not to do!
NOTE: The inclusion of a site in my "Hall of Shame" links should not be construed as any sort of personal attack on the site's creator, who may be a really great person, or even an attack on the linked Web site as a whole, which may be a source of really great information and/or entertainment. Rather, it is simply to highlight specific features (intentional or accidental) of the linked sites which cause problems that could have been avoided by better design. If you find one of your sites is linked here, don't get offended; improve your site so that I'll have to take down the link!
This page was first created 13 Jul 1997, and was last modified 26 Dec 2012.