Understand Online Forms

Much of the information on the internet is static—that means it does not change—in the same fashion that a book does not change as it sits on the shelf. But the Internet is much more versatile than ink-covered pages in a book; even though there is nothing wrong with static information, the Internet is capable of presenting information in a dynamic way.

A web page has the capability to accepting information from a visitor and processing that information. Some of that information is shared and taken behind the scenes (when you visit a web page, certain things about you are automatically given to a website such as your IP address). But the most versatile way to share information with a website is to use a Web Form.

Forms on web pages are very similar to paper forms in the real world. And to explain some of the methods and conventions web pages use on forms, we will create an analogy to real world forms.

Suppose that you go to a doctor’s office for the first time to get a physical checkup. You go to the receptionist who hands you a clipboard and some pages with forms on them. She tells you that you will have to fill out the forms before you can visit the doctor. So you sit down and start filling out the information, such as writing your name, phone number and address. There are some fields for past medical history, and you skip those because you don’t think it is important right now. After filling out most of the information, you take the forms up to the receptionist. She asks you to take a seat while she looks over the forms.

In a few minutes, she calls you back up to the window and says that you have left out some important and required information—such as your medical history and billing information. Oops! You take the forms back and finish filling out the information. After you are finally done, the receptionist accepts the information, and you are soon allowed back to see the doctor.

In this scenario, you can easily draw a straight line between the real-world people, forms and business with the online versions. The doctor’s office is like a website, the forms are forms, and the receptionist is the software that checks and processes information.

Well designed forms will make it clear which information is required as well as what kind of information the form fields are looking for. For example, a form looking for a date is best designed if it tells you that it is looking for a date—and the best forms force you to enter date information in the proper format (instead of one single date field, a good form might have option menus to choose months, days and years).

Well designed forms will also tell you if something is missing or wrong. The ways form do this is often two-fold. JavaScript (a client-side program that runs on your computer) can alert you of any problems before you even send the information to the server (in our example, before you take your papers up to the receptionist). JavaScript verification often alerts you with pop-up windows or alert pop-ups that the form is not finished—but JavaScript verifications only work if the website has made JavaScript verification for your form and you have JavaScript turned on!

Since not all users have JavaScript enabled, it is good practice to have server side verification. In our example, the receptionist looking over the form is like a server-side verification program. If designed well, the verification program will see if your information is formatted properly (that your email address contains an “@” and a “.”, that you did not leave your name blank, etc). If your information is valid, the program will usually do what it is designed to do and let you know that it was successful (maybe you are signing up for a web service, posting a blog entry or making a payment). If your information is erroneous or ill-formatted, the form website will usually return a page with information about your problems, and you will usually have a chance to update the information in the form (in our example, this is like the receptionist giving back the clipboard when you left out important information).

There is one very important convention that new Internet users must learn about forms—the Submit function. Until you manually click a submit button, a form will rarely do anything. Skipping the submit step is like going to the doctor’s office, filling out all the paperwork, but then walking out the door before you have given the receptionist the forms. In your mind you may think that you have done your end, but the receptionist and doctor still know nothing about you until you hand in those forms. The same thing goes for the internet. Until you submit a form, your information is likely not processed.*

The submit function is usually attached to a button that says “Submit”. Other common labels for a submit button are “Post” and “Update” and “Go”. There is no rule to naming a submit button, and if the webmaster wants to he can label it “hamster”—which is bad design practice, but possible. It is important to understand that as an Internet user, you must click a submit button to send the information you enter in a form to a server.

Another thing to understand is that only one form is submitted at a time—even if there are multiple forms on a page and you have information in more than one form. This is one difference between real-world forms and online forms. Only the form whose submit button you click will submit to the server—the information in other form fields is not sent to the server (unless the web designer has created a JavaScript function to collect and send information from other forms on the page as well). In the real world, you could hand the receptionist a stack of different forms all at once, but the Internet does not work that way.

In Webonizer sites, there are some pages that have multiple forms. For example, there are two forms for Editing an existing article—one deals with editing the page’s article information and loading new media files, and the other for editing information about existing media files in the article. In fact, there are often other forms on that page, including one for Associating previously loaded files to an article, one for deleting an article, and one for browsing the site for your previous files. Other common Webonizer pages with multiple forms include the account manager and the event manager page.