OK, now your user has finished the questionnaire, and has clicked on the submit button at the bottom of the form (see form objects for a description of a submit button). When this happens, the web page will execute a little piece of code at the top of the form. Remember when you set up a form, the form began with some html code that read <form ...>.? Well, when the user presses the submit button at the bottom of the form, the form sends the user input to a location that is specified here.

When you insert a form in Dreamweaver, the default heading inserted looks like this in html:

<form method="post" action="">

See those two quotation marks after the action tag? That is the destination you must designate, the place where user input of the form will be sent. Naturally, you'll want the data to be sent to somewhere that you can retrieve it easily. At Drew, you have three basic options:

1. The "mailto:" method. This method send the form output to your e-mail address.
2. Use the "formmail" .cgi script: This method sends the form output to a versatile little program that academic technology has been nice enough to place on a server for your use. This script processes the form output and sends it to you in an easy-to-read format.
3. An easy-to-use .cgi script: This is the best method, which can store form output in a database for easy retrieval, or can send it to you in an e-mail, and can redirect users to a new page.

A. The mailto: method

This is the easiest way to set up your form for submitting data, but it has some definite downsides. For simple forms with limited items and respondents, though, it's definitely adequate. Here's how you would modify the "form" code:

<form method="post" action="mailto:jsmith@drew.edu">

When your users successfully submit the form, and click "OK" on the security pop-up message described above, they are left looking at the same web page, and their entered data will not be reset. Many users will erroneously interpret this to mean that the submit has failed, and will try to submit again. More "determined" users will submit multiple times. It might seem simple to just attach a "go to URL" behavior to the submit button, and you can do this, and it will work, but the problem is that it will cancel the mailto: function. The form simply won't be submitted. Fortunately, you can extend Dreamweaver to add a Behavior that does this. You can download it and install it to you Dreamweaver3/Configuration/Behaviors/Actions/ directory, restart Dreamweaver, and it will appear in your Behaviors list. The extension is available for free at a web site called Dreamweaver fever. What this does is delay the onClick behavior and redirect for a sufficient time you designate (say 4-5 seconds) to allow the form to be sent first. You simply create a web page that says "thank you" and have the mailto: button redirect to this page. Neat!

The last problem with this method is that the data arrive in your e-mail in a very messy format. It's full of ampersands and the spacing is weird and difficult, though not impossible to read. Two ways around this:

If you're good with using the "find/replace" function available in your word processing software, you can save the contents of the e-mail(s) as a text file (ascii) and then rework the contents into a readable format (see the processing output section).

You can download a small piece of freeware that will convert those messy e-mail or text files into a neat, readable format for you. Here are four such (freeware) programs, in order of those I would recommend:

• Formkeeper
• URLcook
• InFORMer
• Newman's Trombone

B. The Formmail method

The nice folks in academic technology have installed a very versatile program called "formmail" in a place that can be accessed by your web page, by filling in the Action="" part of the form script with the following: /cgi-bin/formmail.pl (see also the academic technology page on using formmail).

So that your complete edited form code at the beginning of your web form would read:

<form method="post" action="/cgi-bin/formmail.pl">

When you do this, your form is set up to send the data the user has entered to the formmail program that is stored at this location. But the program doesn't automatically know where you want the results sent. Which is why you must add the following line of text, so that it will read

<form method="post" action="/cgi-bin/formmail.pl">
<input type="hidden" name="recipient" value="jsmith@drew.edu">

So now formmail knows to mail the output to your e-mail (which you would insert in place of "jsmith@drew.edu" NOTE: The web form must be stored on a Drew server, but the email address receiving the data does not have to be an @drew.edu e-mail address).

That's it. The main advantage of using the formmail method is that your data come back to you in a nice, neat manner, that has the form variablename: value. So a text field asking for a respondent's age would, when correctly filled out, return the text age: 19 to your e-mail for that respondent.

There are a number of other useful things you can do with the formmail script. One basic feature you should use is to set up a subject line for the e-mail message. You would do this by adding another line after the two above that has the format:

<input type="hidden" name="subject" value="my questionnaire">

Now when you receive those e-mails, they would have the text "my questionnaire" in the subject line. This is a very useful feature if you're planning to use filters on your e-mail that can automatically direct e-mail to a separate folder, based on the subject line. That way your form data can remain separate from your regular e-mail

For more advanced users, you should also know that formmail has many other advanced features that you may find useful. You can, for instance, instruct formmail to return empty fields for fields that the user left blank, can have formmail redirect the user on submit, can have formmail tell you from where on the network the user submitted the form, and can tell you what browser the user was using, among other things. For more advanced information on formmail's features and optional fields, click here. Also see the academic technology page on using formmail.

C. The script at http://helpdesk.drew.edu/forms/submit.php3

The folks in academic technology (Thanks, Eric!) have programmed a nice script that is less versatile that formmail in some ways, but has some real advantages. For one thing, all you need to put into your web form is the following:

<form method="post" action="http://forms.drew.edu/">

Then, as the form owner, you should go submit a blank form yourself. The first time you do this, you will get an easy-to-use interface that lets you choose some options. Your users will not see this (nor will you if you fill out the form again). You can select:

• Whether you want your form data submitted to you as an e-mail or saved in a database (more on this useful feature below) or both.
• You can select a web address to which your users will be redirected upon completing the form (if you don't a standard "thank you" page will appear).

The database feature is extremely useful when it comes to the next, and final stage, of handling form data, processing output and importing into a spreadsheet-based data analysis program that will allow you to manipulate and analyze it. The database option will, when your users submit the completed for, send the form data to a web page for storage in a comma-delimited format. Subsequent users of you form will have their data sent to the same web page on the next row of comma-delimited data. So if you have a form that collects data from 10 radio-button format responses, and five people complete it, the web page will collect the data and allow you to access it as something like the following:

1,4,2,3,5,6,6,3,5,2
4,6,5,7,3,7,5,2,6,5
3,1,2,2,4,5,3,4,6,5
4,3,6,7,8,5,3,5,3,5
4,6,3,7,3,4,6,4,6,5

To get to the web page that collects your form data, point your web browser to the address http://forms.drew.edu/manage/ which will prompt you for your Netware password, and then give you a menu that will allow you to view your data received or delete it or change that form's properties. Neat!

IMPORTANT: When forms.drew.edu processes data, it SORTS THE DATA FIELDS BY THE ALPHANUMERIC CODE OF THE FIELD NAME. If you are using this method, make sure you name your variables clearly, so you can be sure of to what they refer. If you want the output to be ordered according to a defined format, simply precede each variable name with a number. But make sure you use 01, 02, 03, not just 1, 2, 3. For instance, if you had a form with fields named "age", "sex", and "name," the data would be returned to you in the following order:

19, maria, female
21, bob, male
22, suzanne, female

If you want the data ordered in the sequence the fields appear in the form: simply name them "01age", "02sex", "03name". Similarly, if you have a long list of items whose field names are simply numbers, say with 30 items. make sure you use the 01 numbering system. Otherwise the data will be returned to you in the following order, with data from: 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 3, 30. This can be very confusing, and potentially disastrous, if all the answers are simply numbers themselves that correspond to structured responses like "agree" "disagree" and so on. You won't know which column of the data file corresponds to which item.

Now you can cut and paste this data from the web page into a text file, which can then be imported very easily into any spreadsheet-based data analysis program like SPSS.

Neat! If you choose to have the data sent to you as an e-mail file, you'll get the data in the variablename: value format, and you'll have to get rid of all that text in the variable names before you can import to SPSS.

Miscellaneous Tips

Using hidden fields

Because web forms handle missing fields erratically, you will probably want to insert "markers" in your data to ensure that the values you're reading correspond to the right items. This is especially true if you're using database data collection. Consider the following data, which correspond to user input from three users that completed a questionnaire with ten items:

1,4,2,3,5,6,6,3,5,2
4,6,5,7,3,7,5,2,6
3,1,2,2,4,5,3,4,6,3

See how the second user has one item missing? You're wrong if you think that's the 10th item they didn't answer. It could be any one of the items, 1-10, if they all had the same response format to begin with. Since you don't know which one they didn't answer, you can't be sure of which values correspond to which items for any of the 10 items.

Now, what if you programmed your form to submit a "marker" field like "item5" between items 5 and 6? You would do this by inserting a hidden field directly into you web form in the physical space between items 5 and 6. Your users will not see or interact with this field in any way on the web page (hence the term "hidden"), but it will send a fixed value, "item5" at that point in the data for every user that presses the submit button. The tag for the hidden field can be inserted by Dreamweaver with the click of a button, or can be coded manually as:

<input type="hidden" name="marker#1" value="item5">

Then the same data would look like this:

1,4,2,3,5,item5,6,6,3,5,2
4,6,5,7,3,item5,7,5,2,6
3,1,2,2,4,item5,5,3,4,6,3

Now you can clearly see that the user with the missing value missed one of the items 6-10. You still don't know which one, but maybe you can figure it out now with a narrower field to look through. Or at least if you have to treat all the items as missing, you can still use their responses to items 1-5.

If you were very concerned with missing values, you can insert a hidden field before every single item. This is not a bad idea. Even if you're using formmail data submission, which generates variable names along with the values so you can be sure what values go with what variables, this is still not a bad idea. If you are receiving a lot of e-mail data submissions, you're probably not going to want to go through each one by hand, checking for missing values, but will want to paste their contents into a text file and use the form/replace option in a word processor to "clean up" the data all at once to import into SPSS for analysis. Here you will end up with a database file with comma-delimited data without variable names, and will have the same problem as above (see the next section on processing output to see why this is the case). In any case, it's always safe to have too much information in your data file, whereas too little can render all of your data meaningless if it means you can't identify for sure what values correspond to what variables. Plan for the worst and insert hidden marker fields liberally, at least every five items or so.

Entry validation

You can get your web forms to ensure that all or only selected fields are completed by the user before the user is allowed to submit the form. Instead, when they try to submit or move on to the next item, they will receive a message asking them to go back and complete the required fields. This is an advanced feature that Dreamweaver makes fairly easy to implement. I would use it sparingly if at all, if only because the extra programming increases the number of opportunities for user confusion or computer "bugs" to make themselves known.

If you do want to use this feature, limit use to especially critical fields without which your data will be useless, or fields that users might be tempted to skip because of their sensitive nature. There's no need to check each and every field -- remember that if you "force" your user to complete too many fields that they don't want to, you're likely to be rewarded for your effort with bogus answers.