Multipart Secure Forms Hosting by SSNet, Inc.

Form Design Tips

This document is designed to give novice and advanced form designers some tips and tricks to designing forms that work well - and work well with our Secure Forms Hosting Service.

Please Note: This document is not intended to be an all-inclusive tutorial on form design. It covers some basics and specific areas of form design that may effect the functionality of forms used with our hosting service. There are many sites available with full tutorials on form design. Please check your favorite search engine for such sites if desired.

This document covers the following areas:

Basic Form Components Form Field Names
Using the Proper Field Types
Using Tables in Forms / Field Sorting
Using Standard Form Field Attributes
Form Field Validation
Don't Use Proprietary Extensions

Basic Form Components

There may be one or more forms within a single webpage. As with many other components of a webpage, a form is defined by an opening and closing tag - i.e., <FORM> </FORM>. However, in order for a form to actual do something, other variables are defined within the opening <FORM> tag such as the form's name (used for java script form field validation), the ACTION - what process or event should happen upon submission of the form, and more.

Additional parameters or options can be further defined with hidden input tags if the processing system allow for that.

A form must contain one or more form fields - i.e, text box, text area, drop-down selection box, checkboxes or radio buttons. Many attributes of a form field can be contained in the line of code for that field. This would include the field's name, it's value, its size, the maximum number of characters allowed to be input and more.

A form (to be functional) must also contain a "Submit" button. A "Clear" button can also be used that will clear all the inputted data from a form.

The HTML page containing the form may also have additional coding for java validation.

Form Field Names

A form field name is NOT what you may see while viewing a form. For instance, a form may contain a blank text box with the label "Your Daytime Phone Number" to its left. However, the actual field name is contained in the line of code that produces that particular text box, and is the form name that will be with the data in that box when the form is processed. A typical example would be: <INPUT TYPE="text" NAME="Customer Phone Number" VALUE="">.

In the above example, the actual form field name is "Customer Phone Number", regardless of what you may call it on the viewable portion of the webpage.

It is very IMPORTANT that your form fields have names that will make sense to both you and your customer if they will see the form results in the way of a confirmation email message or an instant HTML receipt. In the worst cases, we have seen some forms produced with automated HTML editing software where ALL the form fields were named exactly alike, albeit for a digit increment - i.e., "field1", "field2", etc. The results of such a form are meaningless to you and your customers.

As a general rule, try to stay away from special characters in your field names such as ',"!# and the like. Non-alphanumeric characters may cause problems with certain types of java validation and/or the final scripts that process the form data. Such special characters may be interpreted as command functions.

So, instead of naming a field "Cardholder's Name", use "Cardholders Name" or "Cardholders_Name" instead. The underscore is optional but may be required by certain types of java validation and/or the final scripts that process the form data.

SSNet NOTE: If you are using our Standard Forms Hosting, where the results are Emailed directly to you, underscores in field names will not disrupt the process but they WILL show up on the results. HOWEVER, if you are using our Gateway Database Hosting, you MUST use the underscores between words in field names. The underscores will automatically be replaced with spaces in the form results.

Using the Proper Field Types

There are only a few types of fields that can be used on a form as follows:

Text Box - used for a single line of text. A sample and the underlying code is below

When it comes to forms, it is best to remember two old sayings - "Keep It Simple" and "Don't make it hard for your customers to buy from you."

Unless you have a compelling reason to use multiple form fields where one will work - don't! For instance, unless your orders are kept in a database that requires the ability to sort by first name, last name, middle initial and such, why make you customers navigate through 3 different fields. Which of the below is easier to complete?

Using Tables in Forms / Field Sorting

Putting your forms within tables has several advantages. It keeps the form neat and tidy by having clean, even separations between the field labels - i.e., Full Name: - and the actual form field boxes. Secondly, by using table, row and table cell colors, you can design very attractive forms that are extremely low bandwidth because no graphics are used. Our payment forms are a good example of this. However, there is one thing about using tables that could effect the form results - or at least the order they appear. Look at the sample below. It appears fine and will work fine - except, because it is done in nested tables, the actual order of the form fields - from top to bottom in the HTML of the form is: First Name - Address - Last Name - City, State, Zip. Most form scripts process the fields in the order they appear in the HTML of the page - so when the results are sent to you, they would also be in a mixed up order.

First Name: Address:

Last Name: City, State, Zip

SSNet NOTE: One of the Hidden input fields in our Form Action lines allows you to have our process sort all the fields on your form exactly as you want them to appear in the HTML receipt and the results to you. You must also include the fields on our payment forms in the sort. Please review the Instructions document for details.

Using Standard Form Field Attributes

Most form fields have attributes that can be set right in the line of code for the field. For instance, this code for a standard text box - <input type="text" name="FieldName" size="30" maxlength="50"> - will produce a text box that is 30 characters wide - but allows a maximum of 50 characters to be entered.

Whereas, the code below defines a text area that is 40 columns wide by 3 rows. Any text between the opening and closing tags appears in the textbox as the default value. Any default value will be sent with the form results if the user does not change it.

<textarea cols="40" rows="3" name="MyTextArea">
Default content to show in textbox
</textarea>

A point made above needs further explanation. Many forms use default values for the form labels or for additional instructions such as this:

It is HIGHLY recommended that you do NOT do this. It makes form field validation extremely difficult (since there is already a value for the field), and all such default values are processed and sent along with the form results.

The exception to this would be if you actually want the default value processed unless the user changes that value - i.e., if you use a text area for Billing Address and another text area for Shipping Address, you could use "Same as Billing Address" as the default value for the Shipping text area. If that address was different, the user would change to default value to their shipping address. If the address was the same, the Same as Billing Address would appear in the form results for the Shipping Address field.

Form Field Validation

Enough can not be said of the value of validating the data a user submits. This can go far beyond making certain fields required - i.e., some value must be entered for such fields. For instance, just making the field "Full Name:" required does not prevent someone from submitting either "F" or "f39f08" as a valid entry.

Nor would you want to receive "3452354" as an area code and phone number, nor "fdfd.545.fsd" as an email address. It helps both you and your customers if the data they submit the first time is the data you need.

There are two types of form field validation - client-side or server-side. We strongly recommend client-side. Client-side validation checks all the form data BEFORE the data is submitted for processing. If the user makes a mistake, that mistake can be clearing spelled out to them and their cursor placed directly back into the form field in question for them to correct the mistake.

With server-side validation, the actual processing script checks the form fields AFTER they are submitted to the server. Error messages are produced - but then the user usually has to use their browser's Back button to return to the form and field the field in error.

After 6 years in this business, we have finally found a very powerful, yet easy to use java script validation that we highly recommend, even for novice users. Please refer to our java script form field validation documents for complete details and instructions.

SSNet NOTE: Many web design tools such as Front Page and others use their own validation scripts that are inserted into your form pages. If you are comfortable and satisfied with such, please feel free to use them. But we recommended that you at least review the capabilities of the script above.

Don't Use Proprietary Extensions

If you use an automated web design or HTML editor such as Front Page, Cold Fusion, Dream Weaver or the like, you need to be careful about their proprietary extensions and coding. For instance, Front Page has many features that will not work on a server unless the server runs the proper Front Page extensions.

Many such features may be passed to the server in the way of hidden input fields. Our servers only run the time-tested, dependable and secure UNIX/Apache server system. We do not run Front Page or other extensions. Unknown command lines or hidden input fields may disrupt or have undesired effects on your forms that ultimately run through our system.

Remember to Keep It Simple! When designing or modifying your forms to run on our system, try to stay away from any bells or whistles that are not necessary that may be proprietary to your design program. As noted above, most java script form field validation will work because it is browser based, and you may be safe using other extensions on your base form since it will be running on your own website - as long as such features do not send unknown fields along to our server. The best way to test is to do just that. Set up your form and once we have confirmed your URL is in our database - test it to see if the results are what you want and expected.