retrieval system without
prior written permission of the publisher except in the case of brief quotations
embodied in critical articles and reviews. Making copies of any part of
this book for any purpose other than your own personal use is a violation
of United States copyright laws. For information, address Que Corporation,
201 West 103rd Street, Indianapolis, IN 46290 or at support@mcp.com.
Notice: This material is excerpted from Special Edition Using HTML, 2nd Edition, ISBN: 0-7897-0758-6. This material has not yet been through the final proof reading stage that it will pass through before being published in printed form. Some errors may exist here that will be corrected before the book is published. This material is provided "as is" without any warranty of any kind.
by Bill Brandon
Many people are accustomed to thinking of the Internet and the World
Wide Web as a kind of reference library. If you need information, you do
a search for it, download it, and log off. At any point you may never be
aware of the many other people who may be viewing the same pages at the
same time along with you.
This experience is somewhat contrary to the rest of your experience of life. If you go to a diner and sit at the counter, the interaction with the other people there is a key part of the experience. Just because the person next to you is reading a book doesn't make your outing into a trip to the library.
The vision of the citizens of the World Wide Web is being expanded by
new opportunities for interactivity. Not only interactivity between each
individual user and the system, but interactivity between users is here
and growing. Increasingly, people go on-line to meet other people.
In this chapter, you learn about the following:
Chat Page Demonstration - There are many places on the Web where
you can go to see and use a chat page. Chat, in one form or another, has been a feature of computer networks
for decades. On the earliest systems with remote terminals for access,
users could send messages to each other and to the system operator. In
the early 1980s, CompuServe added the CB Simulator feature, enabling worldwide
chat between hundreds of people at a time. Other commercial on-line services
soon followed with similar features. Internet Relay Chat has also been
around for several years.
You can easily forget that chat features developed early in the history of distributed computing. However, in the immediate future you won't be able to overlook the fact that they are an important part of the services people expect from their networked systems. At first, of course, the tendency in computing was to emphasize information and data, calculation and rules. People adapted to the system and the rules, not the other way around. Over time the systems matured, users became more sophisticated, and each adapted to the other. Now users have become much more interested in the capacity of systems to build and support relationships and interaction between people.
A natural outcome of this change is that the Internet is becoming more
interactive in nature. The World Wide Web itself is a response to this
trend. You see the rapid addition of interactive features to the Web, but
it has a price. Bandwidth becomes a critical resource, and all features
compete for it. As in any other situation, features that offer more value
are rewarded with a bigger share of that bandwidth. At this point, chat
appears to offer a great deal of value to many Web users, so much so that
they seek out this facility for communicating directly and immediately
with their fellow explorers.
For these reasons, you may want to consider adding a chat page to your Web site. As you will see, some serious business outcomes can be attained by doing so. Far from being just a way for idlers to pass the time, chat is a simple tool that can support major strategies.
Bandwidth is a major concern when considering the options you may wish to add to your Web pages. Users with 14.4 modems may become discouraged and give up trying to use an
What is "chat"? For the purposes of this chapter, chat is a system feature that enables Web users to do two things:
Other Web services and interactive system features are similar to chat,
but they are generally implemented separately. Such features include conferencing
(bulletin board) systems, for example. The chief difference is immediacy.
In chat, all users participating in the discussion are on-line at the same
time and their comments (graphics, voices, typed comments) are shown to
the other participants right away (allowing for server delays, of course).
In other interactive Web features, user comments are stored for later,
repeated display to other users.
Another difference is that, in chat, you are communicating with other people, not with a system or program. You can create a program that seems to respond to typed comments in much the same way that a person would respond. Such a program is often called a robot or 'bot. This program is not the same thing as chat.
What's a 'bot? Early
A 'bot performs whatever function its creator intended. A helpful bot can engage in a little light conversation, respond to specific words typed into the channel, and moderate topics. Some tend bar, some are card dealers, and some enforce rules. There are also malevolent bots that try to annoy, confuse, or harrass users. Many servers ban 'bots totally, while others will allow trusted users to bring their 'bots in with them. If this reminds you of the bar scene in Star Wars, it should. Actually, a lot of IRC seems to be based on that scene.
Internet Relay Chat is a client-server arrangement that connects
users to each other in channels.
In the beginning on the Internet, chat was supported through IRC (Internet Relay Chat). This way to chat is relatively crude and is based on the client-server model. (See fig. 25.1.) To connect to other Internet users in real-time chat, using IRC, you have to do the following:
IRC Host, and you must all agree on the room name you will
use. The first one onto the IRC Host types the command /join #<channel>
to create a virtual space for the conversation; each other party joins
in by typing the same /join #<channel> command. If you are content to chat with anyone who may be available on the IRC Host, you don't have to do the coordination part in step 5. However, you have to remember (or have written down) the commands to enter to find out who else is present, how to send a message, and so on.
The point is that this process takes effort and knowledge of out-of-the-way information. And yet thousands of people make the effort every day, testifying to the power and attraction of chat in an otherwise anonymous medium. Now consider the newer alternative.
With a chat page, you type in the URL of the page. After you're on the page, you probably have to enter an alias (which can be your real name), but that's all. You and your colleagues (or newfound friends) are ready to chat.
On most chat pages, you find out who else is present by clicking on a button or by scrolling to the bottom of the page where a current roster is kept. You click on another button to send a message that you have typed into a text box on the chat page. If you want to send others a picture of yourself with your messages, you enter the URL where your picture can be found. No wonder chat pages are an instant success any place they are added!
Of what possible use is chat? As it turns out, the chat feature can
be an important part of building an excellent Web site and even a part
of your business strategy. Chat is being used today to do the following:
Expect to see these uses increase in variety and importance over time.
Finding chat pages is very easy. Do a Yahoo search on the word "chat."
You will get dozens of hits. Some of them are IRC servers or hosts, but
many are interactive chat pages. Table 25.1 lists four of these choices.
The list of large companies that have included chat facilities in their
Web sites is very impressive.
This whole area is one of great ferment, with companies springing up,
being bought, and merging on a weekly basis. For example, Ubique, which
has a 3-D chat product called Virtual Places, was bought by America Online;
AOL will incorporate this technology into future offerings. The software
could at one time be downloaded for use by Webmasters under license, but
it is no longer available. The Global Chat experiment, sponsored by Digital
Equipment Corp., is now operated by AcmeWeb Services, Inc. You can still
obtain the Global Chat software for use on your system, however.
Table 25.1 Choices for chat on the Web.
| Name | URL |
|---|---|
| WebChat | http://www.irsociety.com/webchat/webchat.html |
| ESPNET SportsZone | http://espnet.sportszone.com/editors/talk/index.html |
| Intercontinental Conferencing Services (was DEC Global Chat) | http://chat.acmeweb.com |
| Cybersight | http://cybersight.com/cgi-bin/cs/ch/chat |
Try the pages shown in table 25.1 to get a better idea of the way chat pages work. All of them are based on forms (your browser must support forms to use them) and work approximately the same way.
Chat is addictive! (Don't say I didn't warn you.)
The most common form of live chat page uses forms. (An alternative is described in the section "Linking Live Chat to Browsers.")
By using forms, you make chat available to most of the browsers in use today. Your guests or customers do not need additional software because the action takes place on the server side.
The following sections give you an overview of the principles involved in chat pages and present an example of their implementation. Finally, I outline a general procedure that you can use to create your own implementation of chat. This process is really much easier than you would think!
All form-based chat systems have two things in common. First, they are client/server-type applications. Second, the server part of the application is always a CGI script; the browser is the client side. The script handles all input from chat participants and also returns updated chat pages to the participants.
Figure 25.2 shows an overview of the process. Each user accessing the page is presented with a form that provides a text area into which comments can be typed. Other information (the user's name or an alias, for example) may also be entered. When the form is submitted (by clicking on a Talk or Chat button), the chat script running on the server processes the input. This processing consists of parsing the information on the form, adding the user's comments to those made by other people who are also using the same page at the same time, and generating a new form that is sent back to the user. Each user at any given moment may be looking at a unique screen, depending on when he or she last clicked on the Talk button.
The overall process behind the operation of a Web chat page.
Figure 25.3 is an example of such a chat page. In this case, it is a screen shot taken while I was using the ESPNET SportsTalk page. As you can see, the browser is looking at the bottom of the form. One participant's comment is visible at the top of the window; you view the other comments by scrolling up.
A typical chat page arrangement with output and input areas.
Below the user's comment in figure 25.3, you see a list of the other individuals who were on-line at the time this screen shot was made. To see what others have been posting while you were reading the comments, you click on Show New Messages. You can keep any number of old messages at the top of the form to help maintain context. Finally, you can enter your name or an alias so that your comments are attributed to you. Using a name or alias makes it easier for others to address their replies to you.
When you type in text and click on the Post Message button, you are submitting your comments to the server. The CGI script running on the server adds your comment to the others and creates a new page to send back to you. This new page contains your comment, all the comments of other participants added since you last chose Show New Messages, and however many old messages you said you wanted to keep. Probably no other participant will be looking at exactly the same page you are at any given moment.
The chat page in Figure 25.3 has the same structure as many other chat pages. The conversation transcript comes first. Some chat pages add new comments to the top of the list; others, to the bottom. In the middle of the page is a set of user options, including a way to enter your name or alias, and to specify the number of old comments you want to keep on the page when you post a message or show new ones. Finally, at the bottom of the page is the input area, where you enter your comments and submit the form to the server.
The script takes the input from the user and extracts the various parts to various files on the server. For example, the alias is added to a list of the people currently taking part in the chat. The comments are filed as a single numbered paragraph, in sequence with all the other comments.
Normally a well-behaved script will acknowledge form input from a user, with a message such as Your input has been received, thanks for stopping by. A chat script, however, creates a new version of the form on the fly and sends it back to the user. That is, the entire form, including the conversation area, the user options area, and the input area, is generated instantly (or very quickly, at least) and sent back to the user.
Just how you accomplish this task is the subject of "How to Set Up Chat with Forms on Your Site." For now, take a look at another example.
WebChat is one of the more successful chat systems. It is unusual for
two reasons. First, it offers full multimedia capability (including live
video feed). Second, it is the product of an open collaborative project,
sponsored by the Internet Roundtable Society. The software is free and
may be copied and modified under the terms of the GNU Public License. You
can buy a commercial version as well. The free version supports a single
channel, whereas the commercial version supports multiple channels and
other features.
Because WebChat is forms based, you need only a standard browser to use it. The Netscape, Microsoft Internet Explorer, AOL, Prodigy, and CompuServe browsers all work equally well. To try WebChat, point your browser to the Web Broadcasting System (WBS1) at http://www.irsociety.com/webchat/webchat.html.
Figure 25.4 shows the lower part of a
WebChat form. It is similar to what you saw with ESPNET in the "Basic
Principles" section of this chapter. The most apparent difference
is that some capabilities have been added.
The user option and input area for WebChat.
For example, WebChat can use client pull to refresh your screen automatically if you are using the Microsoft Internet Explorer or Netscape. You do not need to keep clicking on a button to update the conversation. You set the refresh rate in the user options area.WebChat allows you to select the number of context paragraphs that will be displayed when you update the conversation. A context paragraph is one that you have already seen prior to the update. Having several context paragraphs on your screen helps you keep track of the multiple simultaneous conversations that tend to take place on the typical chat page. Other chat page programs may not give you any context paragraphs, or they may use a fixed number that you cannot change.
Keep the refresh rate in WebChat set to the recommended number or slower. If you increase the number of context paragraphs, slow the refresh rate further. Four to five context paragraphs should be plenty.
Another difference is that you can send a picture with any or all of your WebChat messages. If you have a GIF or JPEG image of yourself, your house, or anything else, as long as the image is available at a URL, you can enter the location in the space provided, and it is then placed to the left of your entry. You can also embed images within any of your entries by simply typing the URL into the body of the message. The image then appears in-line.
The WebChat site offers an extensive library of small images that you
can insert into your conversation. To reach this library, click on PICS
Library at the bottom of the form. The images in the library have
their URLs listed next to them. If your browser supports copying and pasting,
highlight the URL of the image you want, copy it, return to your message,
and paste the locator into the text.
In a similar fashion, you can insert a link into any entry. Just enter the URL. Readers then see a highlighted link. If they click on the link, they will go to that URL. If you have a video or audio clip somewhere on the Internet, insert the URL, and readers will see or hear it when they click on the resulting link.
You can also add your home page or e-mail address to your messages by entering them in the text boxes provided. They show up as highlighted links.
Because all the activity on WebChat pages is handled by the server,
you might experience a performance penalty. When a large number of people
are using the same Web page for chat, WebChat may run slow or skip messages.
This is especially true if many of the users have entered an address for
a graphic to be displayed next to their input.
If you are using a
WebChat does not show the current users on the same screen with the conversation. You click on the Who's On? link to get this information (see fig. 25.5). WBS1 also tells you how many people are in channels other than the one where you are. WBS1 offers a large number of channels, all available through a unique "Tune" feature.
If there are more than about 12 users in a WebChat channel, pick another channel for your conversation to minimize lag problems.
WebChat shows you the names of other users via the Who's On? feature.
You can download all the software needed to set up and run a single
channel WebChat right from the WebChat Home Page. The necessary scripts,
forms, and other materials are provided in a single TAR file. This method
is probably the single easiest way to add chat to your own home page, not
to mention the cheapest. You can also easily modify the user interface
to suit your requirements.
Chat done with forms is created entirely by a CGI script running on
a server. In this section, you look at the HTML created by the script and
sent to the user's browser. Everything the user sees, with the exception
of what he or she inputs onto the form, is created by the script for
that user alone.
Listing 25.1 shows typical HTML source built by the server to create
a basic chat input area.
Listing 25.1. This source code could be generated by script to provide a basic chat input area.
<HTML> <HEAD> <TITLE>Chat Input Area Example</TITLE> </HEAD> <BODY> <FORM ACTION="http://www.someplace.com/" METHOD="POST"> </FORM> <A HREF="\relative\who.html"> Who's here? </A> <BR> <HR> <FORM> <P> What's your alias? <BR> <INPUT NAME="alias" VALUE="anonymous" > <P>What do you have to say? <TEXTAREA NAME="UserInput" ROWS=5 COLS=75> </TEXTAREA> <BR> <BR> <CENTER> <INPUT TYPE="submit" NAME="Talk" VALUE="TALK"> </CENTER><BR> </FORM> </BODY> </HTML>
This listing places the words "Chat Input Area Example" in the title bar of the browser. You can make your own personalized script insert something more apropos, such as "Chuck's Chat Center for Chiropractors."
Next, the browser is told where to send the information entered on the page when the submit button ("TALK") is selected:
<FORM ACTION="http://www.someplace.com/" METHOD="POST">
"POST" tells the browser to send the data to the processing program rather than wait for the program to retrieve the data from the current document.
"Who's here?" is actually a user option, not an input.
Accessing who.html causes the script to output the current list
of users on the fly.
Many users prefer to keep the updated list of users visible at all times, rather than having to constantly refresh the list. The ESPNET SportsZone is a good example of a system that does this.
The user input form area begins just after the horizontal rule under the user option. It consists of two parts: one to capture the user's alias and the other to capture the user's comments.
<P> What's your alias? <INPUT NAME="alias" VALUE="anonymous" > <P>What do you have to say? <TEXTAREA NAME="UserInput" ROWS=5 COLS=75> </TEXTAREA> <INPUT TYPE="submit" NAME="Talk" VALUE="TALK">
The input area can appear at the top or bottom of the chat page (that is, before or after the conversation transcript). When the user clicks on TALK, the alias and the text in the input area are submitted to the server to be processed.
As you can see in figure 25.6, this code produces a very basic kind of input area. This form has no frills at all. It submits a user name and a comment to the server. The chat script breaks them apart. The user name is added to a list of current users, and the comment is added to a file of user comments.
The type of input area generated by a Web chat page script.
To return the names or aliases of others on-line, the script sets up a list of individuals currently accessing the page. At first, the script merely detects the user at the time of connection to the page. The server can then add an alias for an individual when he or she provides one, use a default alias (such as "anonymous") until an individual alias is entered, or not include individuals on the list until they enter actual comments. This action depends on the way you write the script. The script also needs to detect when someone leaves the page and then remove his or her alias from the list.
When someone clicks on the Who's Here? link, the server returns the names on the list at that moment. The user may believe he or she is viewing a Web page containing this list. In fact, what the user sees only a virtual page created on the fly in response to his or her request. Other users on-line at the same time may see a different list. Some servers (such as WebChat) update the list when the user clicks on the Refresh button on his or her browser.
Returning an updated chat transcript is a bit more complicated. How much more complicated depends on the features you decide to implement. For example, if you want to provide some context paragraphs, as WebChat does, all comments submitted must be tracked with a unique identification number. (Not all chat pages provide context paragraphs.) This number is assigned by the script as each comment is received. The script could begin numbering comments with "1" (say, at noon GMT), or it could use the time the comment was received.
This identification number is used to select the comments that are returned
when the user enters the chat channel or clicks on the Chat or Update buttons.
The system knows the number of the last paragraph seen by the user. It
knows the number of the latest comment submitted, and it knows how many
comments to repeat for context. A little math identifies the comments that
must be shown.
Give the user about five context paragraphs on entering a channel, to help get things started.
You might want to make it possible for users to enter live links as part of their comments. These links could be to images, sounds, or pages. This setup requires your CGI script to parse the user's input, identify URLs, and output the links in a way that browsers will recognize, display, and treat as links.
The next task for the script is to format the entire page. Listing 25.2
shows the HTML source that might be generated and sent to the user's browser
during a chat session. (This source code will be found on the CD-ROM as
CHATPAGE.HTM. Notice that much of this source is the same as shown in listing
25.1. The difference is that the conversation transcript has been added.
Each individual paragraph of the transcript has the same formatting applied:
<B>Paladin@123.456.78.90</B>: 20:52 GMT <BR> Mike: I'm back<BR CLEAR=left><P>
The preceding is the paragraph (or comment) submitted by a user who
calls himself "Paladin." The CGI script has taken his input and
pulled out the alias. To the alias, the script appended the Host IP address
that it captured when Paladin accessed the chat page. These elements were
dropped into a bold format and the time at which Paladin's input was received
was appended to them. A line break was added. Then Paladin's comment was
added to the next line, followed by another line break. Incidentally, the
Mike: that begins Paladin's comment is something that Paladin
typed himself. On a busy chat page, most users provide some kind of reference
that helps other users keep track of the conversations.
Listing 25.2. HTML source generated by the Web chat script, to return
an updated conversation to the user.
<HTML> <HEAD> <TITLE>My Chat Page on the Web</TITLE> </HEAD> <BODY> <H1>Welcome to My Chat Page!</H1> <HR> <FORM ACTION="http://www.someplace.com/" METHOD="POST"> </FORM> <B>Paladin@123.456.78.90</B>: 20:52 GMT <BR> Mike: I'm back<BR CLEAR=left><P> <B>Joker@098.765.43.21</B>: 20:52 GMT <BR> Indy: It would seem you have some competition for your name.<BR CLEAR=left><P> <B>Megan@135.792.46.80</B>: 20:53 GMT <BR> MARIE -- Guess what! I had an argument with them (BUT IT WAS NOT MY FAULT!) <BR CLEAR=left><P> <B>My Name Is Mike@246.801.35.79</B>: 20:53 GMT <BR> PALADIN: Where did you go?<BR CLEAR=left><P> <BR> <HR> <A HREF="\relative\who.html"> Who's here? </A> <BR> <HR> <FORM> <P> What's your alias? <BR> <INPUT NAME="alias" VALUE=""> <P> What do you have to say? <BR> <TEXTAREA NAME="UserInput" ROWS=5 COLS=75> </TEXTAREA> <BR> <BR> <CENTER><INPUT TYPE="submit" NAME="Talk" VALUE="TALK"></CENTER><BR> </FORM> </BODY> </HTML>
The server script simply keeps adding comments and formatting them until
all the user inputs down to the very last one are in this format and strung
together. Then the whole chunk of HTML source is sent back to the individual
user, who sees something like figure 25.7
on his or her browser.
The way the user sees the updated conversation provided by the HTML
source in listing 25.2.
Figure 25.8 depicts the way that the server script parses input and generates output.
The Web chat script parses input from all users and assembles output
that is returned to users individually.
You can find the basic elements of a script that performs these tasks
in chapter 24. The guestbook application in that chapter
can serve as the start for your own efforts.
In addition, you can download the WebChat software and modify it to suit your own purposes. Using it saves a great deal of time. The functions provided in the WebChat CGI script include the following:
Note that you can adapt the WebChat script in whatever way is required for your application. However, you must retain the copyright notice that appears in the script, document the modifications, and give credit for use of the library of PERL routines.
As noted previously, you can also license a more complete version of WebChat from the Internet Roundtable Society. Full information is available at the following WebChat site:
http://www.irsociety.com/webchat/webchat.html.
For more information on setting up a form on a Web page, see "Forms and How They Work"
You can find out more about writing CGI scripts to support chat features
in "Sample Code and CGI Scripts"
Systems such as WebChat put all the processing on the server side of the Web. Although doing so assures access by users with different browsers, it also may slow down the server to the point that users will abandon their efforts to chat.
You can create a program for the client side that relieves the server of some of the burden. The client-side application can also automate updating of the conversation, even if the user's browser does not support client-side pull.
In these programs, the application runs concurrently with the user's
browser. The user goes to a page that is enabled for this type of chat
and clicks on a Connect button (or something similar) on that page. The
client-side application is called and links to the page. At this point,
the user can chat.
UgaliChat is an example of this approach. In this commercial system,
the server manager sets up UgaliChat-enabled pages or makes it possible
for users to create their own chat pages. This is done by installing the
UgaliChat Server on the host computer. The server can be modified by the
manager (it's another simple script), and server access can be limited.
The UgaliChat Server performs various housekeeping functions automatically.
These functions include removing inactive clients, providing new users
with several minutes of past conversation, and presenting an information
page on use of UgaliChat to the users' Web browsers. The Server also tracks
user counts. The Server advises the server manager of chat-enabled pages
that have been set up on the system. The manager can disable chat functionality
on individual pages, and can also set the Server up so that the manager's
approval is required in order to chat-enable a page.
From the user's perspective, the UgaliChat page automatically displays a list of users on-line, with a notice indicating that UgaliChat is available. The client-side application (the Ugali Communicator) is a MIME reader that automatically updates the reader's display at intervals determined by the user. The user types a message and presses Enter when ready to send it to the other users.
The UgaliChat server is provided and supported for a fee that varies
by the type of service provider. The Communicator is free to those who
use it in their private homes or in certain educational institutions. For
all others, a fee is required for each copy of the Communicator program.
Although the use of a client-side application makes chat run faster, there are some drawbacks. First, you have no guarantee that the application will work with all browsers. Second, although the server manager can change the server code at any time, the code for the client side may not be modified directly. Third, the client-side application requires installing a proprietary reader on the user's system. This is not always desirable and may limit the number of people who can use the Chat system. Finally, the practice of charging a fee for use of the client-side application may make these systems less attractive to businesses.
The evolution of interactivity on the World Wide Web has been the subject
of a great deal of discussion. An influential project was done between
1994 and 1995 at the Massachusetts Institute of Technology (MIT). This
project, called the Sociable Web, is no longer available. However, you
can still read the white paper on the project by pointing your browser
to the following:
http://judith.www.media.mit.edu/SocialWeb/
Although this paper is brief, it is worth study for its definition of
a number of key concepts that are likely to be influential in future Web
chat page systems. The Web is a social environment, so the important features
are the ones that enhance interaction. The authors of the Sociable Web
placed their focus on four of these features:
Much of the functionality described by Judith Donath, Niel Robertson,
and their colleagues at the MIT Media Lab has already been or is being
realized in WebChat. However, the notion of a "virtual location"
has yet to be implemented. A virtual location is a "place" at
which contact with an individual user can usually be made, even though
that user may be off wandering the Web most of the time.
Web chat pages as now implemented require all the users to be simultaneously
accessing the same page and no others. A virtual location would permit
users to carry on conversations even if they were not all accessing the
same page. This process is a little like monitoring a certain channel on
a CB radio while driving your car across country. Your friends would know
that they could contact you on that channel no matter where you were.
And the idea of social uses of the Web is growing beyond what was foreseen
in the Sociable Web. You now see applications that allow a group of individuals
to tour around the Web together, for example. Other developments under
way make it possible to converse with a Web page, and for Web pages to
make small talk, respond to questions, and carry out searches. A good Web
page would be able to do searches while serving as the virtual host for
a group conference, for example. Finally, you can also expect to see pages
that can support simultaneous public and private conversations.
|
