|
Web presentations that inform or entertain by their content are fun, but interactive Web pages are even more fun. Web pages that allow your readers to enter input and get something back can really draw readers in and keep them coming back to your site. Interactive Web pages can also allow your readers to leave their mark on your site. This chapter describes the following three real-life interactive presentations you can create on the Web using forms and CGI scripts:
As in the previous chapter, we'll go through these presentations step by step and explain the design decisions that were made in each one. Of course, these presentations are shorter than the last ones, but there are organization and design decisions to be made here as well.
As with the personal and company presentations in the last chapter, the examples in this chapter are available on the Web. To get the full effect of what these presentations do, you should try them out. That URL again is http://www.lne.com/Web/Examples/.
| Note |
As I noted in the previous chapter, each of these presentations will change and get better after the book is published, so check back to the site and see what new good stuff has appeared. |
Also, because these are interactive examples, all of them have CGI scripts that do the real work. Although I won't be going through the scripts line by line as I did in Chapter 20, "Useful Forms and Scripts" (we would be here for days if I did), you can see the extensively documented scripts on this Web site as well.
You're interested in what your readers think. It doesn't matter what it's about: politics, how they use the Web, their sex life, whatever. The Web, with its form capability, is an excellent environment with which to run a survey. Just write a form, publish it, advertise, collect your data, and print results. You can get only a cross-section of the population on the Web, of course, and then only those who decide to respond to your survey. Therefore, your results won't be perfect, but you can still get some interesting information.
The presentation we'll go through in this section is a Web developer's survey-a survey on what sort of things HTML authors are doing with their pages and how they are testing them, all correlated against the browser and the connection they're using. (Will Netscape users be more prone to including Netscape extensions in their documents? Well, probably, but how much? Now you can find out.)
There are three parts to this presentation:
When you first encounter the survey, you are presented with the page shown in Figure 22.1.
Figure 22.1 : The survey introduction.
This page explains the survey, who's doing it, why, and how the results will be used. It's a general overview of the survey itself. From here you have two choices: you can take the survey itself, or you can see the results either in HTML 3.2 or text-only tables.
Let's start by taking the survey itself. If you've filled out forms before, this should look quite familiar. The survey is actually divided into three main parts:
The first part (shown in Figure 22.2) contains three sections: the type of browser you use (with the top three-Netscape, Mosaic, and Lynx-having individual buttons, and everything else coming under Other); the type of connection you use to connect to the Net (direct or dialup); and, if you use a dialup connection, at what speed you use it. We don't really care about what speed your connection is if you're on a direct connection-fast is fast.
Figure 22.2 : The survey form, first section.
The second part (shown in Figure 22.3) refers to what focus your presentation has and the HTML features you use in that presentation. For the focus options, you have four choices (and you can pick all that apply); for the features, you choose Yes or No for each one (No is the default). The features include Netscape extensions, tables, or using lots of images.
Figure 22.3 : The survey form, second section.
The third and final part (shown in Figure 22.4) refers to how you test your pages (and warns you to be honest). Here, you have three choices for each item, depending on how often you use that item: Never, Sometimes, and Always. Each item asks a question such as, "Do you test your pages in a text-only browser?" The default for each is Never.
Figure 22.4 : The survey form, third section.
After filling out all the sections, all that's left is to submit the form (or clear it, of course). The form script on the server side works away, and you get the response page shown in Figure 22.5.
From here, you have two choices: go back to the home page (of course), or view the results. Let's view the results.
You have two choices of how you can view the results: in HTML 3.2 table form or as text-only tables. As in the Beanpole software presentation in the previous chapter, it's a good idea to provide multiple renditions of the same table for browsers that don't support tables. Survey results, however, are a great use for tables, so we don't want to avoid them altogether. It's extra work to create both of these pages, but the result is compatible with most browsers and looks nice in the browsers that can support it.
Let's look at the version that has the HTML 3.2 tables. The wording in the link from the response page notes that processing the results might take a little time, so we might have to wait a few seconds before the page appears. The link to the results page is actually a script that calculates the results from the data on the fly, which means that the calculations could take some time. Figure 22.6 shows the top part of the results page, including the total number of responses and the first table that shows the summary of who is using what browser.
Figure 22.6 : The results page (tables).
| Note |
I made up the data for this particular example (although the results are similar to those that other Web surveys are getting). If you visit the site with this survey and take it yourself, you'll get current results based on real responses from people like you. |
A nice touch here is the note at the top that warns people who might have stumbled upon this page by mistake. It explains why the page might look strange and points the reader to the text-only page.
There are several result tables on this page, which include both overall percentages of browser use and connection speed, as well as various correlations between browser types and connection speeds, features, and testing types (see Figure 22.7).
Figure 22.7 : The Features Used versus Browser Type table.
| Note |
I'm not going to show you all the tables here. You can visit the Web site and see them for yourself. |
After studying the tables, you can return to the survey home page (see Figure 22.8).
Figure 22.8 : Back to the survey home page.
The text-only version of these tables is quite similar (and you'll get the same results from either one, just in a different format). For comparison, Figure 22.9 shows the Features Used versus Browser Type table in text form.
Figure 22.9 : The Feature Used versus Browser Type table (text only)
In case you're curious, here's a quick overview of how the survey and results scripts work.
When you submit the form, a script called wdb.collect.cgi collects all the items you selected as special key/value pairs and writes them to a special file called results.txt. Multiple form submissions end up in multiple records, separated by a blank line. A typical data record from the results file might look like this:
browser=netscape connection=dialup speed=fast
info= service= entertain=on creative=on
center=no bg=no blink=no align=yes netscape=yes
forms=yes table=no mailto=yes
3images=yes 5images=no
htmltest=sometimes browsertest=always
textest=always platformtest=never
speedtest=never
To keep the results file from getting written to by multiple instances of the survey form script, the script also locks the file while it's writing to it. When the script is done saving the results to the data file, it returns a page with the appropriate links (as you saw previously).
There are two results scripts, one for the table output (called wds.results.cgi) and one for the text-only output (called wds.resultstext.cgi). Each one is called directly from the links on the home page or the survey page; no form or arguments are required. Both result scripts do similar things:
See the code for the script for the specifics of how this presentation works.
WebZone magazine is a nifty new online magazine for Web developers, which has a unique feature that other online magazines don't have: it customizes itself for each reader, based on a short user profile that the reader gives when signing up for the magazine. If you're a subscriber to WebZone, when you sign on you get only the information you're interested in. Of course, you're always welcome to explore any part of the WebZone magazine and change your profile to include the parts you find interesting.
In order to accomplish this system of automatically customizing the magazine based on a stored user profile, WebZone has all its pages protected with access control. You must be a subscriber and be authenticated in order to access them. But becoming a subscriber simply involves filling out a form; it costs nothing, and your subscriber information is never sold to any vendors or greedy mailing list brokers.
The WebZone subscription information is kept in a subscriber database on the WebZone server. By allowing subscribers to add information, change their profiles, and unsubscribe (delete their profiles), you're effectively adding, searching, changing, and deleting records from a small database. This simple model of database management could be extended for just about any purpose you might choose.
Let's walk through the process of subscribing and unsubscribing to WebZone, as well as updating the current user profile so you can get a feel for how the forms and authentication work for this system.
When you visit the WebZone, the first page you see is one called the Front Door. From the Front Door, you can enter the WebZone if you have a subscription, or you can visit the Subscription Manager page, as shown in Figure 22.10.
Figure 22.10 : The WebZone Subscription Manager page.
From this unprotected page, you can choose to subscribe to WebZone, view or change your current user profile, or unsubscribe. Of course, to do the latter you'll have to type in your name and password; you don't want total strangers to be able to access your profiles. From here, you can also look at the subscription information, which explains what the profile is used for and why you need one for WebZone to work.
Let's move through each of the subscriber links in turn.
The first step is subscribing to WebZone. When you select the Subscribe link, the form shown in Figure 22.11 appears.
Figure 22.11 : The WebZone subscription form.
There are several parts of this form to fill out. The first part contains information about you and your subscription, such as your real name, your e-mail address, and the login ID and password you'll use to access WebZone in the future (see Figure 22.12).
Figure 22.12 : Subscription information.
The second part of the form deals with your initial user profile: the software and hardware you use and how you author your Web pages. Some of this section is shown in Figure 22.13.
Figure 22.13 : The user profile.
The final portion of the form deals with the sections of WebZone magazine itself that you're interested in. There are eight of them; you can choose those that look interesting (see Figure 22.14).
Figure 22.14 : The WebZone section.
Finally, it's time to actually subscribe. After choosing the subscribe button, you'll get the response shown in Figure 22.15 from the server.
Figure 22.15 : The subscription verification.
Part of the verification process for making sure that you did indeed want to be subscribed to WebZone involves sending you mail (at the e-mail address you provided in the form). The verification e-mail is shown in Figure 22.16.
Figure 22.16 : The verification e-mail.
After you've subscribed to WebZone, you can start reading its files immediately by following the Enter the WebZone link. You'll be asked for your user name and password (the ones you entered into the subscription form), and your customized magazine page appears.
The WebZone subscription manager (which you can get back to from inside the WebZone pages) also enables you to change your subscription profile. From the subscription manager page, you select the View or Change link. If you haven't yet logged into the WebZone, you'll be asked for your name and password. When authentication has occurred, you'll be given a form that is already filled out with the information you included in your user profile. Figure 22.17 shows the one for my profile.
Figure 22.17 : The WebZone change form.
From here, you can change any of the information in the form (including your password) and then choose the Change My Profile button (see Figure 22.18).
Figure 22.18 : Change the profile.
Figure 22.19 shows the response you get back after you submit your changes.
Figure 22.19 : The changed profile verification.
Just as when you subscribed to the WebZone, you'll get a verification e-mail (see Figure 22.20). The e-mail is used to make sure that you did intend to change your profile and that no one has broken into your account. Your old profile is saved for three days, and if you do nothing to reply to the e-mail, it is eventually deleted.
Figure 22.20 : The WebZone verification e-mail.
You've read the WebZone for awhile, and it really doesn't appeal to you. You would like to unsubscribe. So back to the subscription manager page you go, and you choose the Unsubscribe link.
If you haven't yet been authenticated for the WebZone, you'll be asked for your name and password. Otherwise, the page shown in Figure 22.21 appears.
Figure 22.21 : The WebZone unsubscribing form.
If you made a mistake and ended up on this page, you can choose to go back to the subscription manager page (by using the link or submitting the form, although the former makes more sense). If you truly did mean to unsubscribe, you can choose Yes and submit the form.
Figure 22.22 shows the response you get back from the form.
Figure 22.22 : The unsubscribe verification.
You'll also get an e-mail similar to the previous e-mail messages, just to be absolutely certain you did want to unsubscribe (see Figure 22.23).
Figure 22.23 : The WebZone delete verification e-mail.
By doing nothing, your profile has been removed from the system; the next time you try to access WebZone, you will not be authorized to do so.
The WebZone subscription forms (and the WebZone magazine) work using a combination of scripts, a small-profile database, and authentication. The setup contains several directories:
The script to add a subscription is simple enough. It takes the user information submitted from the form, creates a user profile in the subscription database, creates an entry in the appropriate password file for the authentication (which is why the password needs to be typed twice in the form), and then sends mail back to the given e-mail address for verification.
The change-profile script is slightly more complicated. Based on the authentication information for the reader, it reads the profile from the subscription database and generates a form on-the-fly with the appropriate values filled in (the VALUE attribute for text input fields, and the appropriate radio buttons and checkboxes checked). Because the original password is encoded when the user subscribed, you can't decode it, so you'll leave those fields blank. When the form is resubmitted, you update the subscription database and password files as necessary. You also keep the old information around in a temporary file in case the user made a mistake or someone has broken into her account and changed her profile. The old profiles are cleaned up by the system after three days.
Finally, the delete-user script is called from the unsubscribe form (the one with Yes and No on it). If the user checked No, nothing happens (although why anyone would check No and submit the form, I'm not sure). If the user really did mean to unsubscribe, the script saves the profile and password to another temporary file and sends out the verification. Just as with the old profiles from the change-profile script, the temporary files are deleted after three days.
Just what is a BBS or conferencing system? Both are a sort of discussion group in which people post opinions or questions, and then other people post their conflicting opinions or answers to the questions. If you're familiar with Usenet News, that's a type of conferencing system, although following a thread of conversation is a bit more complicated given the amount of traffic that your average newsgroup gets. Many online systems such as CompuServe have conferencing systems.
Conferencing systems tend to be organized by topic, with each topic containing a set of postings. Depending on the system, you might be able to create your own topics, or the moderator of the system might have to do it for you. You should be able to add your own postings, however.
In this section, we'll look at a conferencing system that runs over the Web. This one is for a gardening BBS, in which the creator wants to foster communication about growing plants and trees and anything else that grows.
When you first enter the top level of the gardening BBS, you will
get the page shown in
Figure 22.24.
Figure 22.24 : The gardening BBS topic index.
This index page contains a list of all the topics available for posting. The topics include Annuals, Vegetables, Fruit Trees, and Bugs. At the bottom of the page is a form for adding a new topic. We'll look at this form later on, but first let's visit one of the topics.
Let's pick the Bugs topic because it looks by far the most interesting. Figure 22.25 shows the postings that have been made to this topic.
Figure 22.25 : The Bugs topic page.
Does it look familiar? It should. Each individual topic file is the same HTML file (and corresponding script) that you learned about in Chapter 20 with the guestbook. The same principles apply: you can add postings and reply to other people in the same way that you added your mark to the guestbook.
For example, let's add a topic to the Bugs topic page. As with the guestbook, there's a form at the bottom of the page, shown in Figure 22.26.
Figure 22.26 : The form for adding a post.
Type in your name and address (which mark the top of each post) and the content of the post itself. You can include HTML in the body of the posting, including character tags, links and anchors, and images (as long as the SRC attribute points to a full URL). For example, Figure 22.27 shows a posting I'm about to make to the Bugs topic, referring to another site that has information about snails.
Figure 22.27 : The filled out form.
After filling out the form and selecting POST, a confirmation page is displayed (as shown in Figure 22.28).
Figure 22.28 : The confirmation page.
When you go back to the topic page, the new post is already there (see Figure 22.29).
Figure 22.29 : The new post has been added.
What if you have a subject that you want to talk about that doesn't fall under one of the current topics? You can add a new topic to the list on the index, which creates a new topic page and sets up the proper links.
| Note |
The BBS system I'm describing in this book is set up such that the owner of the BBS can choose not to let random people, like you, create new topics. In this case, you can. If you decide to use this BBS system for your own presentations, keep in mind that you do have a choice for how strictly you want to manage the files. |
To create a new topic, you scroll down to the form at the bottom of the topic index page (if you haven't gone back to it, do that now). This form (shown in Figure 22.30) looks a lot like the form for adding a new posting, with some extra information about the actual filename for the new topic (the form needs to know this so it can create a link).
Figure 22.30 : The form for adding a new topic.
The topic title is the part that forms the actual link in the list of topics. Make it descriptive but not too long. It also is put in the header to the topic page itself.
The topic's HTML filename is simply the name of the file as it will be created on the disk. You need this so the script that creates the topic page knows where to put the file and where to create the link to. The filename should have an .html extension.
Finally, the description text describes what the topic is all about. You can be verbose in this section and include other bits of HTML such as character styles or images. The description text is added to the topic index to describe the topic.
Fill out the form and select POST. You get a confirmation page (which is effectively the same confirmation page that you got when you added a new posting, so I won't bother to show it here). When you go back to the index, your new topic has appeared. (Here, it's a topic on bulbs, as shown in Figure 22.31.)
If you now visit that topic, you'll note that there aren't any postings. It's a good idea to add a posting to the new topic when you create it so that people have a chance to respond to you. Otherwise, your new topic might remain empty and unused.
You saw a lot of how the HTML BBS system works when we worked through the guestbook example in Chapter 20. Both the topic and the index pages rely on the fact that there are special comments in the HTML files that tell the script where to put new topic headers and new postings. In this case, there is one script for adding new topics that updates the index file and creates the new topic file. The second script adds new postings to the topic file itself, the same way the guestbook added new entries (and, in fact, they are the same source).
The HTML BBS system also has methods for creating new conferences, which are new directories with blank index files so that you can start a whole new BBS. You can have multiple directories containing multiple topics for any major subject you might want to deal with.
The system also includes special scripts for topic management, including scripts to archive postings (because the files can get pretty long), and to edit and delete both topics and postings from the index and topic files. I won't describe those in this book; if you're interested, take a look at the actual package on the Web site for this book.
Interactivity allows an enormous amount of power in how you design and organize your presentations. Without interactivity, your job is basically to create pages for the reader to passively look at. You don't know who they are; they wander through your pages and perhaps send you mail if they were particularly amused or touched. But add interactivity, and you can suddenly communicate with your readers, either directly through the use of forms or indirectly with CGI scripts that they can run again and again. With interactivity, your readers can even communicate with each other, as you saw in the conferencing system example.
In this chapter, you've looked at some interactive presentations that take advantage of various parts of CGI: forms that allow you to gather input from the user, scripts that do something with that input, and scripts that modify the environment your readers are exploring as they explore it. Really, your only limits on what you can do with this kind of interactivity are based on what you can program on your server's computer. When you combine an interesting interactive presentation with a well-designed and interesting informational presentation, word will get out and your site will get attention (although it doesn't hurt to advertise).
| Q | Those tables you created for the survey form are awful! I don't know why you've chosen to correlate things like that. It's very confusing. |
| A | I agree. I'm not a very good statistician. My intent was not to create a really good form, but rather to show an example of how data can be collected, sorted, and processed using forms and CGI scripts. |
| Q | In the subscription form for WebZone, you have the user typing her password into a form. Although the characters themselves are hidden by the browser, I assume those passwords are sent to the server as clear text. So someone watching the network could snag those passwords. That isn't very secure, is it? |
| A | No, it's not. This is why I warn readers not to use a login ID or password that they use for any regular system. But, you're right. It's also not very secure for the magazine itself. However, how secure do you need it to be? It's only a magazine; you're not sending your credit cards or other very private information over the Web. This password deal happens only once, and any changes are verified via e-mail. I would argue that for this particular application, making sure that the passwords are secure isn't all that important. |
| Q | I've been experimenting with the WebZone subscription forms, and I noticed that I only need to enter a user name and password once, and then it works for all the WebZone pages. If all the pages inside a certain directory are protected, shouldn't the browser ask me for my name and password each time? |
| A | Browsers cache user names and passwords the same way they do pages and images. To save time, the browser will keep track of the user name and password for a given directory, and then send it for you for every protected page. |
| Q | I used the WebZone subscriptions to add a subscription. Then I changed my password. But then when I tried to go back to another page, it said "Authorization Failed!" But I didn't even try! And even worse, when I tried logging in again, it continued to insist that the authorization had failed. What's going on here? |
| A | This is an unfortunate side effect of the browser caching your name and password information, as I noted in the previous example. When you change your password, the browser still has your old information, but the server has your new information. So when you try to go back, the browser doesn't know anything has changed, so it automatically sends the original information, which is now wrong. When you try again, you should enter the new information, not the old, in order to get back into the WebZone. |
| Q | The HTML BBS would make more sense if it added postings to the top of the page, in reverse order, instead of to the bottom of the page. That way your readers could get the newest stuff first, in the same way that the What's New pages work. |
| A | I agree, and we discussed this when we were writing the system. Basically, from what we saw, people using this BBS tend to want to reply to each other, and the continuity between postings seems strange when the postings are in reverse order. (People are used to having continuity flow downward.) However, modifying the scripts so that postings get added in reverse order is trivial. Just add another comment, modify a couple more lines, and you're done |