Forms and dynamic sites
A Web form is a collection of GUI controls on a page. The user selects options in the controls, and then submits the form to the server. The server performs processing based on the user's selections and returns a resulting page to the user.
Form processing implies that action is taken on the server, and therefore requires server support for one or more server-side programming technologies. Programming ability is normally required.
Forms are made up of standard GUI controls such as checkboxes, text fields, and buttons. The user can operate these controls with the mouse or keyboard in order to 'fill' the form with their data.
User submits form
A form does not normally 'do' anything until the user submits it. The form is initially downloaded from the server as part of the normal HTML page; there is no further communication until the user submits a form.
Forms are submitted to the Web server at a URL given in the <form> tag.
Server processes form
The server is sent form data in one of two ways: either as part of the requested URL (which is appropriate if the amount of data is small), or in additional data sent with the URL request (which is appropriate if the amount of data is larger or if the data could cause some kind of effect, rather than just requesting information).
The Web server generally acts on the request by passing it along to associated software designed to handle it. The software may communicate with a database in order to handle the request. It then returns a resulting page to the user which indicates the result of the action.
If you want your site to handle information from forms, then the server must be able to run software to handle that data. Most free providers do not include support for this, so you will generally have to pay for Web hosting that includes this.
Even if you want to use other people's software out of the box to process your forms, installing server-side software is usually a difficult administration task, and you must be sure that your Web host supports the particular required technologies.
Obviously, developing your own custom software to respond to forms requires programming skill.
Forms are included in a <form> tag, and made up of standard GUI controls. Each control is given a name, which identifies the data from that control when it is returned to the server.
All form controls should be contained within a form tag. The form tag specifies where a form will be sent when it is submitted, and groups controls. All the controls within one form tag are considered to be part of that form; you can have multiple forms on a page if you want, using different form tags.
Checkboxes (<input type="checkbox">)
These are small squares; clicking the mouse on them places or removes a tick mark. Checkboxes are used when the user has to make an 'on/off' decision.
Radio buttons (<input type="radio">)
These are small circles in groups; clicking on a radio button makes that radio button selected, and all the others in the group unselected. Radio buttons are used when the user has to pick a single option from a small number of choices.
Drop-down lists (<select>)
These controls show the currently-selected option, with a downwards triangle to indicate that more are available. Clicking on the option brings up a (scrollable) list of all available options, from which the user can pick. Drop-down lists are appropriate when the user has to pick a single option from many options.
Text fields (<input type="text">)
Text fields allow the user to enter a single line of text. This would be appropriate, for example, if you wished to query the user's name.
Text areas (<textarea>)
Text areas allow the user to enter multiple lines of text. For example, you would use a text area if you wanted to allow the user to write a general comment about your site, as this might be more than one line long.
Submit buttons (<input type="submit">)
The user clicks on a submit button when they have finished editing the form; the data is then sent to the server.
Graphics (<input type="image">)
Graphics can be used instead of submit buttons.
In this case, the co-ordinates within the graphic on which the user clicked are returned, so that you could (for example) allow the user to click on a map and then show them a zoomed-in version of the area in which they clicked.
When a user clicks the Submit button, the form is submitted to the server as a standard HTTP request.
There are two form submission methods, which can be selected using an attribute of the <form> tag. One, called GET, causes the form data to be appended to the URL request. The other, POST, includes the form data elsewhere in the HTTP request and has a fixed URL.
Submission is standard HTTP request
When you submit a form, the browser sends an HTTP request to the Web server that includes your form data. This is a standard HTTP request; there is no fundamental difference between this request and a request for a normal URL.
The base URL for the Web server to which the form should be submitted is given in the <form> tag.
One way to submit forms is called a GET request. The GET request is the same type of request that's used normally to request a URL from the server. When submitting a form this way, the form data is converted appropriately and then included on the end of the URL.
For example, if the form URL was http://www.google.com/, and the form contained a single text field which had been given the name 'search', then after the user typed in 'apple pie' and clicked submit, the URL http://www.google.com/?search=apple+pie would be requested. (Spaces are converted to + because spaces are not permitted in URLs.)
The other submission method is POST. This works slightly differently; the browser contacts a fixed URL, which is not changed to handle different form data. However, the POST request includes the form data separately.
If the example form above used the POST method, then the plain URL http://www.google.com/ would be requested, but additional information would be sent to the server along with the request, including the 'apple pie' search term.
Choosing GET or POST
It can be difficult to decide which method is best for a particular form, but there are some specific rules.
The most important restriction is that forms sent using GET should not cause any significant action to be carried out. For example, a final order form at an online store should not use the GET method to place orders - but it would be acceptable to use a form with GET to retrieve customer information or to search the product database.
A general guideline is that if submitting the form data twice would be a problem - it might generate two orders, bomb two small developing nations, etc. - then the form must use POST instead of GET. This is required by the specification, and is important because Web browsers will never send POST data twice without querying the user, whereas they will send GET data again (thus ordering a second book or destroying a second country) if the user clicks their Back button.
Another advantage of POST is that it can cope with data of arbitrary length. GET, on the other hand, is restricted to relatively short data because URLs are limited in length. For example, GET could not be used for an email form (even if the above restriction did not apply, which it does) because the user might type a long email that won't fit in a URL.
GET, however, is useful when it is an option (for queries which don't cause any significant effect and which contain only a small amount of data) because GET queries are only standard URLs and can therefore be bookmarked, linked to, etc.
Once a form is submitted, the server generally takes some action with the processed form. It then returns a standard HTTP response (i.e. a page) to the user which indicates the results of their request in some way.
Basic form handling
When a form is received by the server, it is handled in some way. The web server's configuration determines what initial action is taken based on the URL; normally, this would involve passing the form's contents to a separate program written in an appropriate programming language.
For example, if a server receives a GET request for /search.cgi?keywords=apple, then it might be configured to handle that request by running the separate program stored in its software folder and named 'search.cgi', passing the form contents (keywords=apple) to the program. The server would then accept the output from the search.cgi program, and send it back to the requesting client as an HTTP response.
Similarly, if a server receives a GET request for /customerinfo.asp?id=3345, then it might be configured to handle that request by launching an ASP interpreter and interpreting the template customerinfo.asp. The template contains HTML to be output, interspersed with programming code which generates additional parts of the HTML, probably by accessing a database to find information about customer 3345.
Database software manages large quantities of information in a structured format. From within other software, you can update the database and query it for information.
For example, you might have an order database. When somebody places an order on your online site, the program which handles the form communicates with your database to create a database record for that order, containing the key details (user's details, product ordered, etc.)
It isn't always necessary to use a database when responding to form input (for example, if you have a response form where people can give comments on the site, the software might simply email their comments to a particular address; there would be no need to store the comments in a database). However, databases are often useful.
There are various database technologies, from free (MySQL), through moderately-priced (Microsoft Access), up to higher-priced solutions like Oracle and Microsoft SQL Server. All of these will work fine for a small site (although Access really isn't a good idea for medium or large sites). If you purchase Web hosting rather than hosting your own server, you will need to pay attention to the database that is included by your hosting company.
There are different technologies used for server-side processing software, but they all do basically the same thing. One difference is between template-based and code-based technologies.
Code-based systems require you to develop a piece of software. The software accepts some input (the form data) and must produce some output (the form result page).
Some code-based technologies are:
- CGI (normally uses the Perl programming language; free, very widely supported)
- Java Servlets (uses the Java programming language; free, not widely supported)
Template-based systems require you to create a template for your output result page. This template is standard HTML, but includes portions of programming code where the HTML needs to be generated dynamically. For example, a search results template would begin with standard HTML, but would have sections of code to report the number of results and then to report the results themselves. So the code is interpersed with the HTML.
Some template-based technologies are:
- ASP (normally uses Visual Basic, but you can also use real programming languages; widely supported, but mainly on Microsoft servers; included with server)
- PHP (similar to ASP, but uses a language a bit like Perl; fairly widely supported; free)
- JSP (similar to ASP, but uses Java; not widely supported; free)
- ColdFusion (similar to ASP, but uses a slightly simpler tag-based programming language; reasonably supported; CF servers cost money)
No real difference
In practice, there is little real difference between the two categories of software; when creating code-based software, you normally pull the 'standard' bits of the output from template files.
Beginners might find the template-based systems easier to use, provided that they are experienced in HTML markup - but programming isn't a spectacularly easy task, and learning to program in any mode is going to require a degree of effort and dedication.
Tried and tested
If you have no specific preferences, the most popular options are as follows:
- CGI with Perl (when you want it to work nearly everywhere)
- PHP with MySQL (a modern free option, preferred by computer geeks)
- ASP (the Microsoft option, when you are running an MS server and need to integrate with other MS solutions)
Using pre-built software
Pre-built software is available in all these languages, but is of varying quality.
You should not use pre-built software unless you understand it enough to be sure there is no security risk, or you have it checked over by somebody else, or you are certain it is from a reputable company who make security their top priority and you know that this particular piece of software has a good reputation among the user community. Installing unsafe software on your site could have serious consequences, especially if it deals with security-critical information.
Form usability is a complicated topic. Here are some basic guidelines that can help you avoid the worst mistakes.
Use appropriate controls
For example, do not use checkboxes when a user is supposed to select only a single option. Do not use radio buttons when there are 20 options.
Validate and restrict input...
You need to make sure (in your server-side code) to check that the form is correctly filled in. If there are any errors, you should return the user to the form page, highlighting those errors.
For example, if a user neglects to fill in an email address, you can return them to a form with the 'Email address' label in red and text at the top explaining that an email address is required.
You can also restrict data prior to this stage. For example, if the user is supposed to indicate whether they are male or female, do not include a text box for them to type 'm' or 'f'; include two radio buttons. If a user is supposed to indicate their country of residence, do not include a box for them to type it (where they might make a typing mistake etc.); include a drop-down list of all countries.
...but not too much
Be sure that your form can be filled in by all users. For example, you might require a postal code; don't attempt to validate this code because users from a different country might have a different format. In fact, you shouldn't require a postal code at all because some countries do not have postal codes.
Similar details apply to telephone numbers; for example, do not attempt to 'validate' a telephone number by checking that it only contains digits, -, (, and ); international telephone numbers are listed with a + at the beginning, and other countries might use additional symbols in telephone numbers.
Do not make the user retype
In cases where the user needs to re-submit a form (because there was some mistake), ensure that they do not need to retype the correct information. When the form is sent back to them, it should already contain all the correct data they entered.
Do not include a 'Reset' button
HTML provides for a 'reset' button which clears the form data. Users often click this button by mistake when they intend to submit the form. The button usually has no purpose, so don't include it just because you can.
Provide all necessary instructions
Forms can be complicated and time-consuming to fill in, so be sure to include all necessary information. For example, indicate required fields in some way, so that the user knows they can't leave those blank.
If a user might not understand one piece of requested information (for example, the security number on a VISA card), explain that information for them.
If an explanation would be too long to fit on the form, include a link to it. Make sure the link pops up in a separate browser window so that the user doesn't lose their form data, and make sure that the link text indicates it will use a separate window so that the user isn't scared to click it.
Let user confirm important actions
Always give the user a 'last chance' stage to confirm any important actions such as a purchase. This stage should give the details of exactly what the user is about to commit to, and should clearly indicate that, when the submit button on this page is clicked, the action will be taken.
Include support contacts
If the form is an important one (for example, an order form for your business) and you care if somebody can't figure it out, make sure that you provide some way to get help, such as an email address, and prominently display it on that page.
With a form, users can contact your Web site to request a service, provide information, etc.
Created in HTML
You use standard HTML tags to create a form using a set of available GUI controls.
Sent to the server
When the user submits a form, it is sent to the server as an HTTP request using either the GET method (if it is a small amount of data with no practical effect) or the POST method.
Processed by software on the server
The server processes forms using software written in any of a variety of languages or technologies. Often, that software will connect to a database to obtain or store information.
Form result is an HTTP response
The form result is an HTTP response (normally a Web page), for example a page saying 'Thank you for your order', or a page containing the same form again with an indication of information that was missed out and needs to be included.
Usability is paramount
Because forms are more complicated than navigating the Web generally is, their usability is very important and designing them requires a lot of thought.