Dreamweaver II | Form Page Design

Form Page Design

No need for the panic button. Creating a user input form can be a tricky proposition with both design and technology concerns, but you'll tackle it in this lesson and exercise.

Forms are a great way to add interactivity to a Web site. Guest books, polls, and quizzes get visitors directly involved. Forms also provide site managers (you or your client) with useful data (addresses for a mailing list, purchase details, and so on).

It's hardly surprising that everyone wants a form. The good news is that Dreamweaver gets you on the right track by creating the front-end interface. Text fields, checkboxes, radio buttons, lists, menus, Submit buttons—you can insert these elements with ease, creating an intuitive form design.

The bad news? Dreamweaver can't handle much of the "back-end" creation and processing of the behind-the-scenes code that makes your forms actually do something, like submit data.

But in this lesson, we'll show you how to use free Web resources to handle form data. In the exercise, you'll design and "hook up" a basic form that looks and works great.

 

Forms contain two main components: the front-end and the back-end. The front-end includes all of the elements that the user sees and interacts with. The back-end is invisible to the viewer and constitutes the code and server interaction that generates results or transmits data.

If you send someone money through PayPal (for your latest eBay win, perhaps?) you'll start the process by filling out a form on the front-end. When you submit the form, the back-end code will be processed to transmit the necessary information to PayPal's server.

Designing the Front End

In a few moments, we'll talk about all of the different types of form elements and how to insert them using Dreamweaver. But first, let's look at some of the design and usability considerations that affect form design.

Filling out a form is considered work to the user because it switches him or her from passive browsing to active participation. A good design can make the work less of a chore.

Form labels must be large enough to read easily. Any instructions must be brief. The user should be able to differentiate between required and optional form elements, and press the correct button with just a glance.

These goals can be easily achieved by sticking to design conventions of form presentation. Keep it simple—this is not the time to go avant-garde.

	1. The overall page design should be consistent with the other pages in the site, including the site logo and navigation. Sounds like common sense, but if this is overlooked, users feel like their form results will be going somewhere other than the intended site. Global colors and graphics help to make the Hertz rental car form part of a clear and consistent design. 2. Align all form elements to the left. Centered alignment will slow down the process of clicking from one form element to the next. 3. Use a white or light colored background and black or dark-colored text. Make sure the value contrast is sufficient, so the labels are easy to read. 4. Avoid excessive rollover graphics or animations. Don't distract the user from the task at hand. 5. Mark required form fields by using a different text color, a bolder font weight, or an asterisk and include a "key" at the top. In this enrollment form, the user is informed that required fields are in bold and marked with an asterisk. 6. Group related form elements into fieldsets. For example, you might create separate fieldsets for "personal information" and "comments." Fieldsets divide long forms into more manageable sections. The legend tag provides a descriptive title for each fieldset. By default, fieldsets are bordered by a thin gray line. You can override fieldset background colors and borders using CSS. 7. Place your Submit button in a clear location, and make sure it is labeled with a logical name ("Submit" or "Send Form" not "Go," "Done," or other terms that don't make it clear that the form data will be sent to the server). If you are using a Reset button next to your Submit button, the Web standard is to place the Submit button to the left.

Implementing the Back End

To make a form work, you'll need to place back-end code called a form handler on your server. A form handler is a specially-coded script that tells the form data what to do. One form handler might tell the data to go sit in certain fields of an existing database, while another might process the user's response to a poll and calculate the resulting statistics.

Form handlers are typically Perl or PHP-coded CGI scripts, though they can employ other scripts like ASP instead. If this is all alphabet soup to you, don't worry. In many cases you can find a free or inexpensive pre-written script online that does exactly what you want it to and you're ready to go. Some scripts will need to be transferred to your server, while others are hosted on outside servers. Even better, many Web hosting companies provide scripts, so you may not have to look further than your own host.

When a user takes the Mensa Workout test, test answers are submitted to the Mensa Web server where scores are calculated. Results are instantly returned to the user (displayed in the browser) and may also be kept in a database on the server. All of this is achieved through the form handler.

In most cases, you'll use a CGI script to process your forms. To implement CGI form handlers, your server will need to have a special directory called a cgi-bin (you cannot create this directory yourself or use a different directory instead—it is supplied by your host).

Now would be a great time to see if your Web host has a cgi-bin for your CGI form handlers. Expand the Files panel and connect to your Web server. View the files on your server in the Remote Site panel. If you see a folder called "cgi-bin" at the root of your site, you've got one and you're all set.

In my Remote Site files, I have a cgi-bin directory. In fact, my host even supplies a form handler for me to use. To learn how this free form handler works and what it does, I can check the documentation for my host or contact their tech support.

If you don't have this directory, contact your host to see what other form handling options you have. Some hosts, particularly free or very low-cost hosting plans, will not offer form handling in any way. However, you can still use handlers provided by outside servers, as we'll see in the exercise. The ability to process a script on your own server is not required for this class.

Forms and Form Elements
Starting a Form

Let's put the craziness of back-end scripting on the back burner for a while so we can focus on front-end form design and how each form element operates.

Download the recipetree folder from the course downloads area and move it into your local root folder. Open form.html.

Insert your cursor inside the #mainContent div, below "Please fill out the form below to subscribe to Recipe Tree. *Bold fields are required."

Every form begins with, well, a form. In Code view, the form area is defined by <form> tags. In Design view, the form area is defined by a red border. Turn on your invisible elements (View > Visual Aids > Invisible Elements), if they're not already on, while you work on your form so that you can see the red border. Form elements must be placed within the form area to function.

Open the Insert panel (Window > Insert) and choose the Forms category.

The Forms category of the Insert panel offers quick access to common form elements.

In Dreamweaver CS3, users will find the Insert panel at top of the Document window. The panel is a different shape, but the contents are the same.

The Insert panel in Dreamweaver CS3 is a long, horizontal bar at the top of the Document window. If you can't figure out which button is which, hover your mouse over each icon for a descriptive tooltip.

Click the Form button to insert a form. Or, if you prefer, go to Insert > Form > Form.

The red form border is only visible in Design view (not in the Web browser)—it is a visual aid to show you where to place your form elements.

The form, indicated by a red border, has been inserted into the #mainContent div. Notice that non-form elements are placed outside of the form area.

Fieldsets and Legends

Now that the form area is defined, we can add the first fieldset. Click inside the red form border. Press Return a few times to give yourself some space to work with. Then choose the Fieldset button or go to Insert > Form > Fieldset. Enter "user name and password" into the Legend field.

If the Fieldset dialog doesn't pop up, go to Dreamweaver > Preferences (or Edit > Preferences in Windows). In the General category, select "Show dialog when inserting objects".

The thin gray fieldset border might be hard to see at first. Click your right arrow key to move to the right of the legend.

Let's restyle the fieldset to make it stand out more. Create a new CSS rule for the fieldset tag.

Background colors, borders, and margins are useful properties to style fieldsets.

In the Background category, choose a pale background color, #EDEEF0.

In the Border category, choose a solid 1 pixel brown border, #503B37 (same for all).

In the Box category, add 10 pixels of margin (same for all). Click OK.

Create a new CSS rule to style the "user name and password" legend.

Font weight and color can be used to style legends.

In the Type category, set the font-weight to bold and the color to brown, #503B37. Click OK.

With your cursor planted inside your freshly painted fieldset, go to Insert > Table. Yes, you heard that right! Tables are still a good way to hold rows of form elements in place. However, some people might argue that this it not semantically correct since form elements aren't tabular data. We'll create a form layout using purely CSS later on, and you can decide which method you like best.

In the Table dialog, give the table 3 rows and 2 columns. Set the table width to 500 pixels, the border to 0 pixels, and the cell padding to 5 pixels.

Insert a table to hold the rows and columns of form elements.

Click inside the top-left table cell, then drag down, selecting all three table cells in the left column.

Using the Property inspector, set the horizontal and vertical alignment to "right" and "top". This will help to align our labels later on. Also, set the width of these cells to "150".

Insert your cursor below the fieldset (but still within the red dotted border). If you don't have any space below your fieldset, select the <fieldset> tag using the Tag selector in the lower left corner of the Document window, then press your right-arrow key to move your cursor to the right of the fieldset. Press Return to move down to the next line.

Choose the Fieldset button (or Insert > Form > Fieldset) to insert a new fieldset. Enter "about you" into the Legend field.

We need one more fieldset. Insert your cursor below the "about you" fieldset and click the Fieldset button once again. Enter "newsletters" into the Legend field.

To finish up, copy the table from the "user name and password" fieldset and paste into the "about you" and "newsletters" fieldsets.

Starting with a fieldset structure will keep your form elements organized.

The fieldset structure is in place. You're ready to insert the form elements—the items that the user types in, selects, or clicks to input information.

Text Fields

Text fields are used to capture user data like names, addresses, and passwords.

Insert your cursor inside the upper-right table cell of your user name and password fieldset, then click the Text Field button in the Insert panel (or Insert > Form > Text Field).

When the Input Tag Accessibility Attributes dialog opens up, type "user_name" in the ID field and "user name" in the the label field. Choose the "Attach label tag" option to associate the label with the form element.

The ID will be added to the back-end code. The ID is quite important because it will identify this line of data when you view the results from your server. For example, if you call input for the user name "user_name", and the user types "Jane" in this input, the result will appear as "user_name: Jane."

The label will appear in the front-end user interface. Use clear, descriptive labels so the user will know what to enter in each text field.

Click OK to exit the Input Tag Accessibility Attributes dialog. The label and text field will appear in the table. Now, we need to move the label over to the left cell. First, click your cursor somewhere inside the "user name" label. Then use the Tag selector in the lower left corner of the Document window to select the <label> tag. Drag and drop into the left cell.

Use the tag selector to select the label.

Then drag the label into the left cell.

If you take a look at the Code view, you'll see that the label is attached with a "for" attribute. This element is "for" the text field with the ID of "user_name". Even though the label and field are in separate table cells, they are still associated.

If your form IDs are renamed after you move them to another cell, go to your Dreamweaver Preferences (Code Rewriting category) and make sure that "Rename form items when pasting" is not checked.

Make sure that "Rename form items when pasting" is disabled. This will cause your carefully named and labeled form items to go haywire.

Select the text field and take a look at the Property inspector. A number of properties are available such as Char width (this setting determines width of the text field) and Max Chars (the number of characters a user is allowed to enter, for example you might use a Max of three for an area code).

Enter a value of "20" in the character width field, and "10" in the maximum characters field.

You can also set an initial value (Init Val) for the field—text that will appear in the field until the user types over it, for example "Type name here."

If you do not set a Char width, a default will be chosen for you. If you do not set Max Chars, the number of characters allowed in a field will be unlimited.

On to the next form element. Insert your cursor in the second row of the right column. Click the Text Field button in the Insert panel. When the Input Tag Accessibility Attributes dialog opens up, give the text field an ID of "password" and a label of "password".

Grab the "password" label and drag it into the left table cell. Select the text field and set the character width to "20" in the Property inspector. Select the Password radio button. This shields the user's entry from onlookers using symbols instead of the actual characters. You've seen such a field in action when logging into your courses here at Sessions.

One more to go—insert your cursor in the third row of the right column. Give this text field an ID of "email_address" and a label of "email address". Select the label and drop it in the left cell. In the Property inspector, set the character width to "20".

The table is used to align the labels and text fields into a neat grid.

This is starting to look more like a form! Ready for the next fieldset?

Drop-Down Menus

A drop-down menu gives the user a list of choices. Drop-down menus are often used to choose a state or country in a subscription form or to choose the color or size of a product.

Insert your cursor in the upper-right table cell of the "about you" fieldset. Click the List/Menu icon in Insert panel (or Insert > Form > List/Menu).

Give the menu an ID of "birth_year" and a label of "birth year" in the Input Tag Accessibility Attributes dialog.

A small drop-down menu will appear along with the "birth year" label. Select the label and drag it into the left table cell.

Select the drop-down menu and click the List Values button in the Property inspector to add the list items.

Make sure the Menu radio button is selected (we'll look at Lists shortly), then click List Values to enter the menu items.

Add a few list items for the "birth year" drop-down menu. Give each entry an Item Label (the text the user will see for each choice) as well as a Value (the results you will receive).

Use the plus icon to add list items, and the minus icon to subtract items.

Did you notice in my above example that I included an Item Label called "Select One:"? I don't want my users to actually pick this, but it is a helpful reminder to choose an item from the menu rather than leave it untouched.

To make sure "Select One:" is visible when the page first loads, use the Initially selected option in the Property inspector.

Select the list item that you would like to appear when the page first loads.

Try out this drop-down menu to see another way to format a menu visually. This formatting method won't change how you receive the form results, but it will help to organize the items for the user:

--Choose Nearest Store-- USA -New York, NY -Philadelphia, PA -Topeka, KS -Portland, OR

Now look at the List Values for this drop-down menu:

Notice how simple punctuation helps to break up the menu so that the many choices are quicker to scan and select.

List Boxes

List boxes bear a distinct similarity to drop-down menus. So much so that they share the same insert button, Property inspector options, and List Values window. The difference? A list box can be several lines long, and it allows for multiple choices if the user holds down the Ctrl key (PC) or Command key (Mac). In fact, it's helpful to remind the user of these keys with instructions such as "To make multiple selections, hold down your Ctrl key (PC) or Command key (Mac)."

Insert your cursor in the right column of the second row and click the List/Menu icon in the Insert panel.

In the Input Tag Accessibility Attributes dialog, give the menu an ID of "interests" and a label of "what types of recipes interest you?"

Select the label and drag it over to the left cell.

Then click the List radio button in the Property inspector to make it a list menu rather than a drop-down menu.

Choose the number of visible lines with the Height option. Check "Allow Multiple" to allow users to select multiple items. The List Values dialog is handled the same way as the drop-down menu.

Notice the scroll bar in the above example. It doesn't matter how many items are added to this list box—they will only take up five lines of space.

Text Areas

A text area is simply a multi-line text field. Text areas are useful for comments, message board posts, and other lengthy typed responses.

Insert your cursor in the right column of the third row. Click the Text area button in the Insert panel (or Insert > Form > Textarea). Give the text area an ID of "comments" and a label of "comments".

Select the "comments" label and drag it over to the left cell.

The width of the text area is dictated by the Char width field in the Property inspector. Change this value to "30".

Always allow a little extra space to the right of the text area—the character width may vary depending on the user's default font size.

The height of the text area is set by a property called Num Lines (number of lines). If the user types beyond the allotted space, scrollbars will appear.

Even though I have chosen a visual area of 30 characters wide by five lines tall, the amount of text the user can enter is unlimited and scrollbars will appear if needed.

This fieldset is finished—ready for the next set of elements?

Checkboxes

Checkboxes are used to allow selection of multiple options. To remind a user of this functionality, "Check all that apply:" is often used to introduce a series of checkboxes.

Click inside the upper-right cell of the "newsletters" table. We will use a nested fieldset in this cell to contain a series of checkboxes. Choose the Fieldset button (or Insert > Form > Fieldset) to insert a new fieldset. Enter "sign me up for the following newsletters:" into the Legend field.

Press your right arrow key to move your cursor to the right of the legend. Then click the Checkbox button in the Insert panel or choose Insert > Form > Checkbox. Give the checkbox an ID of "daily_dish" and a label of "daily dish".

Press Shift-Return to create a line break, then insert another check box with an ID of "cooking_news" and a label of "cooking news".

Press Shift-Return again to insert a third check box. Give it an ID of "recipe_notes" and a label of "recipe notes". Done!

Radio Buttons

Radio buttons are used in groups of two or more to retrieve mutually exclusive data. Only one option can be selected. Clicking one radio button in the group turns off all the others. Try it here:

My favorite color is: Red Blue Green Other

Click your cursor inside the second row, right column of the "newsletters" table. Choose the Fieldset button (or Insert > Form > Fieldset) to insert a new fieldset. Enter "please send occasional email updates" as the fieldset legend.

Press your right arrow key to move your cursor to the right of the legend, then click the Radio Button icon in the Insert panel or go to Insert > Form > Radio Button. Give the radio button an ID and checked value of "yes". Then hit Shift-Return and add another radio button with an ID and value of "no".

After creating both buttons, make sure that they are both assigned the name "updates" in the left field of the Property inspector. When several radio buttons have the same name, they are part of the same group. If you plan to have two or more sets of radio buttons, each set should have a different name so they don't exclude each other's choices.

Both the "yes" and "no" radio buttons have the same name. This tells the browser that they are part of the same group.

Another way to create a group of radio buttons is with the Radio Group option in the Insert panel. This opens a dialog in which you can program all of your radio buttons at once to avoid any naming mistakes.

Buttons

In order to submit a form, you'll need a Submit button that tells the data where to go (this is where the back-end processing comes in, which we'll discuss soon).

Many forms also contain Reset buttons to clear all the data, but many users find this to be redundant or confusing (wouldn't you hate to accidentally click Reset after filling out a long form instead of clicking Submit)?

Insert your cursor in the last row, right column of the nested table and click the Button icon in the Insert panel, or Insert > Form > Button. Enter "submit" in the ID field and leave the label blank. Also, select No label tag from the style menu.

Buttons don't require a separate label.

The button label is determined by the Value field in the Property inspector. You can enter any label you like, just make sure that it clearly explains what the button will do.

When you insert a button, it has a "Submit form" action by default and is labeled "Submit." Selecting "Reset form" or "None" will change its action as well as its label.

The most important feature of a button is its action. You can't re-label a Reset button with the name "Submit" and expect it to submit the form. You must choose the correct action using the radio buttons in the Property inspector. Let's examine each action:

	Submit form: This button submits the data to the form handler. Reset form: This button clears all of the data entered in the form by the user. None: On its own, this button will do absolutely nothing when clicked. That's right, nothing! However, special code can be added to the form to give a None button special attributes—for example, you can select the button and apply a behavior such as a form validation script.

Buttons look like gray boxes in Windows or blue/clear "jellybeans" on Mac OS X. These standard buttons are the best bet since they are familiar and conventional. However, if you want to use a custom image button so it meshes better with your design, Dreamweaver gives you this option.

To add an image submit button, click the Image Field icon in the Insert panel or go to Insert > Form > Image Field. You can then browse for an image on your hard drive. The image will automatically be given "Submit form" properties and there will be a dotted line around the image so you know it is an image Submit button rather than a regular image. That's it—the "Submit form" action and the form handler code will take care of the rest.

Final Design Adjustments

One more detail to finish up. Previewing the form in a browser, you might notice that there is a lot of space around the nested fieldsets.

There is too much space surrounding the nested fieldsets. Also, the borders might be overkill.

This is easy to modify using CSS. Create a new CSS rule, choosing the Compound selector type (Dreamweaver CS3 users: choose "Advanced"). Type fieldset fieldset into the Selector Name field. This is a descendant selector that means "select any fieldset that is nested inside another fieldset".

This descendant selector only applies to nested fieldsets. The main fieldsets will not be affected.

In the Box category, set the margins and padding to "0" (same for all). In the Border category, set the border style to "none" (same for all). Click OK. Preview in a browser to see how it looks.

The margins, padding, and borders have been removed from the nested fieldsets.

Other Form Elements

There are a few other form elements in the Insert panel. You won't use them often, but you should know what they do.

	Hidden Field: Hidden fields are used to provide important data to the server without the user seeing it. For example, each time a form is sent to the Webmaster as an email (rather than to a database), the form needs to know the Webmaster's email address. You'd enclose this data in a hidden field so it is transmitted without the user seeing it. File Field: This adds a field and Browse button to a form so that the user can upload a file to your server or send one to you as an attachment. Using such a field requires some complex scripting on your part (or your tech person's part!) and a server that can accept files from outside sources. Jump Menu: A Jump Menu is used for drop-down menu navigation bars rather than drop-down menu form inputs. Using a Jump Menu, you can add navigation options to a drop-down menu. After selecting an option, the user is sent to a specified hyperlink.

Spry Validation Widgets

You'll want to know what these icons are:

These icons look just like their text field, textarea, checkbox, and drop-down menu counterparts, but the orange starburst seems to indicate some kind of special power. Let's try them out to see how they work.

Open the form_spry.html file from the recipetree folder. A fieldset and table have been set up for you. Click inside the upper-right cell of the table, then choose the Spry Validation Text Field icon from the Insert panel, or Insert > Form > Spry Validation Text Field.

The Input Tag Accessibility Attributes dialog looks the same as always. Insert a label and ID—for example, "name". Choose the "Attach label tag" option, and click OK to exit the dialog.

If you mouse over the text field in the Document window, you'll notice a blue tab that identifies it as a Spry text field.

Let's get the label and form element positioned properly in the table. Click your cursor inside the label, then use the Tag selector to select the <label> tag. Drag and drop into the left cell.

Save and preview in a browser. Don't fill anything into the name field—just click the "Submit" button. Sure enough, a message will pop up stating that this is a required field.

Let's go back to Dreamweaver to see how this magic works.

If you select the text field, you'll see the regular text field properties in the Property inspector. However, if you click the blue tab, the Property inspector will show the Spry properties.

Lots of goodies here:

	The Type menu allows you to validate against a certain type of data, for example, the data must be formatted as an email address, a credit card number, a phone number, or a URL. If you just want the field to be completed but don't have a specific requirement regarding the format, like in our name example, leave the type set to "None". It is helpful to give users a hint for how to enter the data. For example, a hint for "date of birth" might read "MM/DD/YYYY". The Validate on checkboxes determine when the validation process will occur: Blur (as soon as the user clicks outside the field), Change (as the user changes text inside the field), or Submit (when the user tries to submit the form). The Preview states menu allows you to preview how the field will look in its valid or required states. If you want to go easy on your users, uncheck Required. Your users will get the same validation prompts, but they will be able to submit the form even if it isn't perfectly filled out.

Choose Required from the Preview states menu in the Property inspector. If your user forgets to fill in this field, he or she will get a default error message "A value is required." Enter something more user friendly, like "Please enter your name."

The Spry Validation Textarea, Checkbox, and Select widgets work much the same way. Try them out—insert one of each and play around with the settings.

Each validation widget comes with an external style sheet. You might decide to change the background color of the valid state to blue instead of green, or maybe you want the error message text to appear in a darker shade of red.

Dreamweaver CS4 users have three additional Spry validation widgets:

The Validation Password widget enforces rules for passwords. For example, you could require all passwords to contain a minimum of five characters. If your user enters four characters, he or she will get an error:

If your user is setting up a new account, you might want to use a Validation Confirm widget. After creating a new password, ask the user to retype the password. If the user fails to type the exact same password, the widget returns an error message stating that the values do not match. This will prevent any potential password errors—maybe your user thought he typed "tomato", but really, he typed "tomatoo".

The Validation Radio Group widget requires that the user make a selection from a group of radio buttons

CSS Form Design

Tables are a practical way to organize form elements, but CSS fanatics might want to use divs instead. Let's explore this now. Open form_tableless.html from the recipetree folder.

Click inside the "user name and password" fieldset. Go to Insert > Layout Objects > Div Tag. Give the div a class of "required" and click OK.

The new div appears in the fieldset. The yellow div outline is hard to see against the pale background. Be careful as you insert the form element into the div.

First, press the right arrow key on your keyboard to move your cursor to the right of the 'Content for class "required" Goes Here' filler text.

Click the Text Field button in the Insert panel (or Insert > Form > Text Field) to insert a text field into the div.

And finally, delete the 'Content for class "required" Goes Here' filler text.

Let's create a few styles to format what we've got here. Start with the div—create a new CSS Rule and choose the Compound selector type (or Advanced in CS3). Type form div into the Selector Name field. This is a descendant selector that will style divs within the form area.

In the Box category, set clear to "both" (this will force each div to appear in separate rows), padding to "5" (this will add some padding inside the div), and margin to "5" (this will add a margin between the divs). Click OK.

Remember that we gave this div a class of "required". This will allow us to apply special formatting to the required form element labels. Create a new CSS rule and type form div.required into the Selector Name field. This rule will apply to any div with a class of "required" inside the form area.

In the Type category, set the font weight to "bold" and click OK.

We will also create an optional class style for the optional form elements. Create a new CSS rule and type form div.optional into the Selector Name field. This will select any div with a class of optional within the form area.

The optional form element labels should be set to "normal" font-weight.

One more element to style: labels. Create a new rule for form div label. This will style any label inside a div inside the form area.

In the Box category, set the labels to float "left" (this turns the label into a block element and pushes it to the left) and set the width to 150 pixels (this will create a column effect). Uncheck "same for all" under padding and add 5 pixels of right padding.

In the Block category, set the text-align to "right". This will right-align the labels against the form elements. Click OK and see how it looks.

Click below the div, then go to Insert > Layout Objects > Div Tag to insert another div. Choose a class of "required" from the Class menu in the Insert Div Tag dialog.

Insert a "password" text field with a label of "password" into the new div.

To finish up this fieldset, insert a third div with a class of "required". You'll need another text field labeled "email address".

As you can see, aligning text fields with CSS is quite easy. However, it gets a little trickier when you add checkboxes.

Click inside the "newsletters" fieldset and insert a new div, choosing "optional" from the Class menu in the Insert Div Tag dialog.

Insert a checkbox with a label of "sign me up".

Checkboxes and radio buttons require extra formatting.

This might look a little out of whack. The checkbox label, normally placed to to right of the checkbox, is pushed over 150 pixels due to the form div label selector we created earlier.

To override this, create a new CSS rule called .radiolabel. This class selector can be applied to check box and radio button labels to shift them back into place.

In the Block category, set the text-align to "left" and display to "inline". This will left-align the labels next to the check box.

In the Box category, set float to "none". This overrides the "left" float on the form div label selector. Click OK.

Select the "sign me up" label (click inside the label, then use the Tag selector to click the <label> tag). Then apply the .radiolabel style. Problem solved.

This worked great on the check box, so let's try a radio group. Insert a div with a class of "required". Click inside the new div and insert a fieldset (radio button groups look nicer nested inside their own fieldsets). Give the fieldset a legend of "please send occasional e-mail updates" and click OK.

The new fieldset will appear in the Document window. Click your right arrow key to move your cursor to the right of the fieldset legend, then click the radio group button in the Insert panel.

Name the radio group "email_updates" (this will identify the group in your form results but won't display in the browser) and add "yes" and "no" labels and values.

The labels will be staggered at first:

Select the "yes" label and apply the .radiolabel style to push it into place. Repeat with the "no" label.

As a final touch, you could edit the fieldset fieldset rule and add a 150 pixel left margin (so it lines up with the column of text field form elements). Any additional formatting adjustments are up to you!

 

Form Properties

The moment you've been waiting for! You've got the tools to create a lovely-looking form with logical inputs that will grab user data quickly and easily. Now you just need to make it work. As you've been warned, this is the tough part because Dreamweaver can only help to a certain extent...

We'll begin with the parts that Dreamweaver can handle. If you click on the red form border or the <form> tag in the Tag selector, you'll see the form properties in the Property inspector.

As with all form elements, give your form itself a simple, logical name. This will define your form data when you see it in an email or database.

The Action field refers to the form scripting—where the form needs to go to be processed. The Method refers to how it will be sent. Let's look at the Method field first.

GET and POST Methods

There are only two choices for the method field, GET and POST. Thankfully, it is pretty simple to determine which method to use. The GET method is used for forms that are not meant to be secure and have no sensitive or personal data being transferred—primarily site search forms.

The POST method is typically used for forms that contain personal information or any other data that should be more carefully masked from prying eyes. The POST method can also contain much more data than the GET method (the GET method can only transfer up to 255 characters), making it useful for lengthy forms and message board posts.

Always choose one of the two methods, rather than going with the browser default (which is usually the less-secure GET method).

So, why is the GET method less secure than the POST method? Let's look at a GET method in action and you'll see the answer:

A search on Yahoo.com was conducted using the term "honda civic." When the search form was submitted, the URL highlighted above appeared.

In the Yahoo! example above, look closely at the URL. Because it used the GET method, the form data was popped right into the new URL. No problem for a search engine, but imagine if a GET method was used for an e-commerce form with your credit card data in it!

I know you're wondering why you'd even bother using the GET method at all—seems like POST is always the way to go. POST is nine times out of ten the method you'll want, however it has a little drawback of its own. The POST method is a little slower than the GET method—not by a lot, but enough to make GET a better choice for site searches.

Form Handlers: Dreamweaver's Side

When it comes to form handler scripts, Dreamweaver must perforce leave you to find one and set it up (don't worry, we won't leave you stranded!). Once you've got a handler installed on your server, Dreamweaver allows you to define the location of your handler file.

In the Action field of the Property inspector, you can enter the URL of a form handler file—usually a CGI handler, such as a Perl script with a .pl extension installed in the server's cgi-bin. In many cases, the script will reside on your server and not on your hard drive, so you'll want to enter in an absolute path to the file, starting with http:// and including the full address, file name, and extension of the file. Sometimes, you might use a handler that resides on someone else's server through a form handler service. In that case, an absolute path would be required.

If you choose to use a relative path, make sure that the location of the script on your hard drive is the same as the location of the script on your server—the same way you'd handle image and other file locations so you don't end up with broken links or images.

That part's pretty painless, but what about the form handler script itself? Onward!

Form Handlers: Your Side

As we talked about earlier, it is important to check with your hosting provider to see what kinds of form handlers you're able to use, if any, as well as where you should place any form handlers on your server. Usually, if you're paying for server space, you'll have a cgi-bin directory to house CGI scripts based in Perl, PHP, and other languages, or an area for alternate types of scripts such as ASP.

This varies from host to host, so please be sure to check this out on your host's Web site or by calling their tech support.

Form handlers can be found all over the Web for free or a very low cost. Most can be downloaded, customized, and installed with step-by-step documentation. The script is usually installed by FTPing it to the proper area on your server.

In most cases, form handlers will submit form results to your email inbox. To submit to a database, you'll need a custom script. If necessary, you can hire a tech professional to develop one to your specifications.

If you do not have form handler support on your server, you can use a form handler service that hosts the script for you and sends you the data when a user submits your form.

Below is a list of popular resources for form handlers. Included are remotely-hosted services (if you have no form capabilities on your server) as well as scripts that you can download and use on your own server. You can find many more by searching the Web or visiting your favorite Web development sites.

A word of caution before you go merrily script hunting. Read all documentation or "readme" files for any scripts or services before downloading them or signing up. They will explain how to customize the script to work with your form and where to place the file on your server (if necessary). Before customizing, you'll want to hang on to a backup of the original downloaded file in case you make a mistake.

	Remote Form Handler Services: Formmail: This popular service charges $1 a month to process your forms and email you the data. Customization is handled without the need to deal with any code. HForm: This is another service that ranges in price from free to a few dollars a month, depending on the features you prefer. Results of your form are emailed to you. Response-O-Matic: This form emailing service includes a large amount of documentation and troubleshooting information to make it easy to set up and use, though there is a fee. FormBuddy: This service is similar to Response-O-Matic. However, it has an advantage—you can design your own confirmation page. Form Handlers for Your Server: Your host: Visit your host's Web site or talk to tech support to see if they have any form handlers you can use. Form handlers might already be installed on your server or take just a bit of configuration to set up. FreeScripts: This site features many types of scripts including a customizable, Perl-based "Form Processor" for your cgi-bin. CGI Resource Index: This Web site includes a large section of Perl-based form handlers of many types. The scripts are user-rated, but the amount of documentation varies from script to script.

Encoding

Another field in the Property inspector worth noting is Enctype which stands for encoding type. Enctype defines the way the data is encoded for security when sent to the server via the POST method.

The documentation of your form handler script will tell you which type of encoding to use so the results are submitted properly and visible on your end—though this is almost always the Enctype application/x-www-form-urlencoded, which is an option in the Enctype field of the Property inspector. The other Enctype option, multipart/form-data, is typically used when files are uploaded in a form.

When using the POST method, you'll typically choose the first of the two Enctype options, unless the documentation of your form handler tells you otherwise.

Occasionally when using a GET method, particularly in an email form (where the data goes to your email rather than your server), you'll use an Enctype of "text/plain" so that the text will be sent to you in a completely unencoded, readable state. Again, the documentation of the form handler you've chosen will dictate this, so you don't need to decide which Enctype to use on your own.

Handling Errors

Accidents happen, and when you're dealing with forms this can mean that your data isn't going where it should or going anywhere at all. So we wrap up this admittedly challenging topic with a handy list of common problems and their solutions (or what to check to find a solution).

	My email form seems to work, but I don't receive any data! If you are using a service, visit its Web site FAQ/support area. Make sure you have supplied the service with your correct email address. If the form handler is on your server, check that you have customized the script with the correct email address according to the documentation. These scripts occasionally contain a "dummy" email address that you must change to a valid one before using. When a user clicks Submit, nothing happens or an error appears. Make sure you have used a Submit button action rather than a None button action. Select the button in Dreamweaver and review its properties. Check that you have applied all of the required properties for the form, including the correct location of the handler (in the Action field). Make sure the script is located in the correct directory of your live Web server, supplied by your host as an area for form handlers to reside. Check that you have customized the script properly and have not changed any code that makes the form operational. You may need to open your backup of the original script and start fresh (make a new backup first!). If you are using a service, check its Web site to see if it's temporarily down or having problems with the servers where your script is located. I received all the data, but I can't tell what info goes with what field of the form. Check that each of your form elements has a logical ID. For example, the field used to retrieve someone's city would be called "city". If the user enters Atlanta in the city field, you'll see "city: Atlanta" in your results rather than "textfield3: Atlanta" (or other Dreamweaver default field name). I received all the data, but it's garbled so I can't read it. Check that you are using the proper Enctype for your form (refer to the documentation for the script). If you are using the GET method, you may either need to leave the Enctype field blank or enter "text/plain" (without the quotes). If you are using the POST method, you will usually use "application/x-www-form-urlencoded," though some forms require "multipart/form-data."

Exercise Design and publish a working form. Discussion Share your thoughts on data collection with other students.