User Feedback

There are many different reasons why you would want your guests to write to you. You would decide for yourself what those reasons are and include feedback capability in your web site accordingly.

In my case, there are three reasons.

1. I want to be made aware of any errors in this site. The most common would be broken links to other sites. Also, there could be typos and ambiguities that need correction.

2. You should feel invited to write to me for clarification of something I've said. Perhaps I'm just plain wrong and you want to take issue with what I've said. Perhaps I omitted an important point.

3. I need a way to know whether my site is viable. Sure I can use hit counters and other methods to get information about my visitors, but that's just a 'body count'. If my site is useful to you and you tell me so, that's my 'payback'. It's clear that I don't earn revenue here, but then, this is not about money; it's about 'feeling good' that these efforts helped real people, you.

So, how do I make it easy to get feedback from you? I could place an email link at the bottom of every page and also embed an email link in the text of some topics where feedback is appropriate. However, since I am using frames, I simply added the Contact Sam entry to my navigation tree. It's always handy, should you want to use it.

The main purpose of this topic, however, is to show you how the two different vehicles, mailto: links and forms are implemented. It's then up to you as to when you would use them.

Mailto: Links:  

Whatever HTML editor you're using, you would simply insert a graphic or select a piece of text that you want to be your link, the object that the user clicks on. Then, instead of using http://......, you would use something like the following:

mailto:me@mydomain.com?Subject=Feedback from MyWeb
or
mailto:me@mydomain.com?Subject=Catalogue Request

The 'Subject' syntax is optional but it's a handy way to have an appropriate subject appear in the user's email. They can always change it.

The response from the user's browser, when a mailto: link is clicked, is to invoke the user's mail program, if it's already loaded into the computer. Otherwise, it will load the 'default' mail program. Netscape users may see the Netscape 'Messenger' pop up, and the Internet Explorer user will find either Outlook or whatever the user has previously chosen as the 'default'. You've likely already noticed that each time you load a competing mail program, if it's not the default, it will request you to designate it so. That always makes me feel important when it happens, like I've actually got a say in what goes on here.    :>)

Forms:

Users will often prefer the flexible and comfortable feel of using their favorite email program to write their feedback. However, there's a lot to be said in favor of providing a form for them to use.

A primary reason is that a form provides a very clear structure if your intent is to solicit specific information, like "Did you like my web site", "Have you been here before", and especially if it's being used for a trouble report or a request to be on your mailing list, where very specific information is needed.

Forms provide that structure since they are quite closed-ended, very much unlike email. Information on forms can be edited and manipulated by either Javascript or some CGI program that ultimately receives the data from the form. This gives you, the designer, the ability to accept or reject (some would say 'purify') the data once the user clicks the Submit button. The form's fields can be made required or optional, and the contents can be checked for validity, especially important for money amounts and dates.

Another great value of forms is ease-of-use. Radio buttons and check boxes can be a very productive and accurate way to have the user make choices. Users also do not have to remember what information is expected from them; everything is right there on the screen.

Finally, consider the person who is a guest at your web site while s/he is using someone else's PC and their mail program is not available. Or, they may not have an email account or, for reasons, can not access it at that time.

So ... forms are important. Let's take a look at how they work on your web site.

The usual vehicle for taking data from a form and getting that data to the web site owner is a CGI script. Exceptions to this statement would be e-commerce applications which process the form's data in a very complex way or perhaps the user of FrontPage Extensions who may place the data in a file on the server for later processing.

The most popular script is formmail.cgi from Matt's Script Archive. Most companies that host web sites supply this as standard issue and most support people understand how this works. Now I'd like to conclude this topic by explaining the mechanism of such a script.

The most important item in a form is the FORM tag and its ACTION parameter. Here's the one from my own feedback form. (In this example, I changed the name of the script from "formmail.cgi" to "smgmail.cgi" because I made a couple modifications to it.)

<FORM method="POST" enctype="x-www-form-urlencoded" action="http://www.samswebstop.com/cgi-bin/smgmail.cgi" name="feedback">

When the 'submit' button is clicked, this tells the browser to send the contents to the 'smgmail' script in my CGI-BIN directory. The goal of the script is to do some basic error checking on the fields and if everything is OK to then send the data to me in the form of an email. The vehicle for doing this is by communicating with the UNIX server's SENDMAIL program. (Microsoft NT has a comparable vehicle and also supports CGI scripts).

'formmail' knows what information to send, who to send it to, what fields are required, how to confirm the acceptance to the user, and other essentials. All this is provided by the designer of the form and communicated to 'formmail' via a series of hidden fields on the form itself. You can 'view source' on my Contact Sam page, if you're curious about these.