Form Objects

A form object is an element of a web page that allows that user to submit specific types of information. All form objects MUST reside within a form that has a specified name in order to work. A form can take up an entire web page, or just part of it. You can also have several forms on a single web page. You CANNOT, however, have a single form span multiple web pages.

In html code the <form> tag anchors the beginning of the form area of the web page, and the </form> tag anchors the end of the form area. In Dreamweaver when you insert a form, the form area appears surrounded by a dotted red line.

Here are the various form objects you have at your disposal, as well as a description of how they process data.

Text field

 

This field allows your user to type information using the keyboard. I try to avoid using them whenever possible, unless it's absolutely essential that you receive open-ended input from your user. In Dreamweaver, it's easy to control the way text fields appear on the web page by setting the width and height (number of lines); you can limit the number of characters your user can enter (the "max characters" option), and can even have the text field display an initial value like, "please type your answer here."

You assign each text field a separate name, and when the user submits data, their input will attached to this name.


Checkbox(es)

 

This is a simple form object. The user creates a little check inside the box by clicking on it, or leaves it blank. These are useful when your user is expected to select multiple objects from a list (If your user is only supposed to select one option from a list, use a radio button).

You assign a name to the checkbox, and simply specify what kind of data the form will output when it's been selected. The output can be a number (e.g., a binary "1" for selected), or a word, which can be the same as the checkbox name if you want.


Radio Button

 

Radio buttons are probably the most useful form objects for online questionnaires. They are like checkboxes, with an important twist: only one radio button can be selected from a "family" of radio buttons that have the same name (Like the mechanical preset station selectors in old car radios, hence the name, radio buttons)

Naming the radio button is particularly important, since the name defines the "family" the radio button is from, and therefore the group from which a user may only choose one option. For instance, suppose you have a questionnaire item where the responses are "Agree," "Disagree," and "Neutral." Obviously your user cannot both agree and disagree at the same time, so this is a good application for radio buttons. You assign the same name to the three radio buttons corresponding to the three answer choices, but attach a different "checked value" to each. The form will then output the radio button family name along with the value corresponding to the radio button that was checked.


List / Menu

 

These are very versatile little objects, which can behave like checkboxes or radio buttons when you want a user to select options from among a list. A "menu" behaves like radio buttons, in that the user can only select one option. A "list" behaves like checkboxes, in that the user can select multiple options (though in a rather awkward way, by holding down the Shift or Ctrl key).

You name the list / menu, and then you enter the options you want your user to choose from (these will appear on the web page). Then you attach values to each option, usually sequential numbers. The form will output the list / menu name with the value(s) that correspond to the selected option(s).

With a list, you can allow users to choose multiple options, and can have these all be displayed initially by setting the height (number of lines displayed) of the list, so that users don't have to scroll through their choices.

Another related type of form object is called a "jump menu" (available in Dreamweaver). When the user chooses an option, two things will happen. The form will output the value associated with that choice (as with a list or menu), but will also redirect the user to a new location, either an anchor on the existing web page or a new web page altogether.

 

These are probably the most important part of the web form. Though these buttons appear similar (and are created in the same way using the form objects menu in Dreamweaver), they are very different.

Submit button: This form object has one purpose. It submits the data from the form (see section on submitting data for information on how to select a destination for form output). You can also attach behaviors to a submit button as with regular buttons, such as a "Go to URL" behavior that redirects users to a "Thank you" page.

Regular button: These don't perform any actions unless you tell them to. Go ahead, press the "Button" button. Nothing happens. They are useful mainly as navigational tools, by attaching behaviors to them.

Reset button: I have never understood why you'd want to have this button in a questionnaire, because what it does is clear all the user's input. In theory, this might be nice they've made a mistake, or if the form is to be used repeatedly by multiple users, but it's probably a mistake to put it on your page. If your user hits it by accident, they may (1) think they've submitted the form, and move on, or, (2) know they've made a mistake, and not invest the time in filling it out again. My advice: if your user makes a mistake, let them correct it by re-entering the answer (nothing's final until they press submit).

Hidden fields
 

These are hidden so you can't see them ;-). This is not a joke. These are extremely useful tags you can insert into your online questionnaire. The user cannot see them, and so they cannot manipulate them to submit any of their information. In fact, all they do is routinely submit the same fixed data along with the user's input when the user hits "submit."

So why would you want this predetermined output cluttering up the really useful information entered by your user? For any number of reasons:

(1) Suppose you have multiple versions of the same questionnaire, that mix up the items to avoid order effects (response biases related to the position of a particular item -- beginning, middle, or end -- in a questionnaire). Well, you can insert a hidden field that outputs the questionnaire version number along with the form data, so you don't get them mixed up.

(2) Hidden fields can be used to make sure that form data you're looking at corresponds to the right questionnaire items. When you use certain techniques to submit your forms, the output will be in the form of just comma-delimited numbers (values) like so: 1,3,2,5,2,3,6,3,5 corresponding to the values you set for radio buttons, checkboxes, etc. It's nice to insert simple hidden fields like "item05" or "endofsection02" every few items or so indicating where the user is in the questionnaire when a particular item was submitted, so that your output will be easy to read and line up when you're getting ready to analyze it in SPSS or a spreadsheet.

Two more important questions to consider in this section, both of which have to do with the appearance of your web page. There is a saying in research, "garbage in, garbage out," which means if your data are crummy (not valid, unrealiable, full of errors, based on flawed reasoning, etc.), they're not going to tell you very much of importance. This applies to questionnaires as well, whether online or offline. If you don't put in the time to make your web page attractive, clear, and easy to complete, your user won't put in the time to give you good responses. On the other hand, if your questionnaire IS visually appealing, clearly laid out, and easy to complete (web pages have a major advantage here because they are a relatively new way of completing questionnaires), your user will likely respond by giving you thorough, well-thought-out responses.

  1. Do you need your users to see all the responses at one time to make a choice? In some cases, it's desirable that your users consider all possible responses before making a choice. In this case using a list / menu drop-down box is a bad idea. You users have to execute an action -- clicking on the menu -- to see all the choices, and by this time they may have already spent some time thinking about their answer. Likert-type items are cases where you want uses to see all the choices ahead of time, because you want them to be thinking of their response in terms of the rather restrictive categories (e.g., strongly agree, agree, disagree, strongly disagree) you've limited them to. Other items, such as "what is your age" are good candidates for drop-down boxes. My age is my age, and I'll hunt around a little if need be to find the appropriate number in a list or menu. The advantage to drop-down boxes, which you should use when you can (but which isn't all that often), is that they use space efficiently. Displaying all those answers takes a lot of space, and you should avoid it if you can.
  2. Make sure your item text is clearly associated with the appropriate form object. See the section on using tables for some advice on how to do this effectively. When possible, orient responses vertically, so it's clear which answer goes with which option. Which of the following is clearer?

What is your sex?
Single, never married
Married
Divorced
Separated
Widowed

What is your marital status?
 Single, never married  Married  Divorced  Separate  Widowed


The second option uses less vertical space, which is good, but if I'm answering the questionnaire quickly, and my status is, say, married, it's possible that I could click the third radio button, thinking that it is associated with the "married" text. Bad, bad, bad. This won't happen with the first option. Another reason the first option is better is that different screen sizes, browser window size, etc., are not likely mess up the layout too much. With the second option, a smaller screen might "wrap" the text "widowed" around to the next line, but leave it's radio button on the first line. Bad, bad, bad. Here's another questionnaire where this actually happens. Yuk! Actually, in this particular example, you'd be better off using a drop-down menu.