Each of the controls included in a GUI interface must have some way of storing the data associated with the control. On a Web page this is done using a name and a value pair that are transmitted to the server or in an email sent along with the form, such as a name of city and a value of Paris. The name is defined on the Web page form and the server software must recognize the name to understand what to do with the value or data sent with the Web form.
How the value is obtained differs for each Web form control. In text boxes or text areas, the value consists of the characters keyed into the boxes. In radio buttons and check boxes, the text that displays to the right of each radio button or check box is for human use only. The value is defined in the Web form and is transmitted when the form is sent. If these data are used to update a database, the values are often codes that are sent and then stored at the server, and the analyst must decide what the appropriate values should be when each radio button or check box is clicked.
Figure illustrated below is an example of a form used to obtain prices and to register for a cruise. The text in the Name, Address, City, State, Zip, Phone, and Email areas is sent to the server when the form is submitted. Only one of the radio buttons for the 4-day, 7-day, or 14-day cruise may be selected.
The values sent are S for short if the 4-day cruise is selected, A for average length if 7 days has been selected, and L for a long cruise if the 14-day cruise is selected. In addition, when one of these cruises is selected, the dollar amount is inserted into one of the text boxes on the left side of the Web form, and any previously selected radio buttons and amounts are cleared. If the ocean side room check box is checked, a value of Y for yes is transmitted to the server, the amount is inserted into the left-side text box, and the total is updated. If the customer tries to change the amounts in the calculated text boxes, they are reset. When the submit button is clicked, the amounts are sent to the server along with all the other data.
Another type of control found on Web forms is a hidden field. These are not visible to the viewer, do not take up any space on the Web page, and can contain only a name and a value. Often hidden fields are used to store values sent from one Web form to the server. These typically need to be included on a second form when multiple forms are required to capture all the transaction data. Sometimes they are used to retain information about the type of browser being used, the viewer’s operating system, and so on. Sometimes a hidden field will contain a key field used to locate a record for the customer or the browsing session.
When there are complicated interactions on a Web form (or any other GUI form), an event response chart may be used to list the variety of events that can occur. Event-response charts may be used at a high level to model business events and responses (covered in Chapter “Using Data Flow Diagrams“), but the events that occur on a Web form or other display are usually limited to user actions. These events may be clicking a button, changing a value, focusing the field (moving the cursor inside the field or to a radio button, check box, or other control), blurring a field (the user moves the cursor out of the field), loading the Web page, detecting keystrokes, and many other events. The response lists how the Web page should react when the event occurs. Events are for a particular object, such as a button, a text field, the whole Web page, and so on.
Figure illustrated below is a Web site used to estimate the cost of staying at a resort. The user can enter the number of people, change the starting and ending dates, and enter the number of people for a variety of extra activities, such as scuba diving or golf.
The event-response chart is shown in the figure below. Notice that there may be a number of events for each Web form control. Since the user may do any number of actions in any order, the event-response chart is useful to show what should happen. For example, the user may click the Calculate button first, change the starting and ending dates, or change the number of people. The event-response chart is also useful for building a Web form that requires minimal action from the user. An example of this is when the user changes the starting month or day; the ending month or day is then changed to match the starting month or day. The year changes when the month is earlier than the current month, since people cannot stay at the resort prior to the current day in the same year.
Sometimes the event-response chart may be used to explore improvements to the Web page. Suppose that the resort determined that most of its customers stayed for seven days. When the starting month or day changes, the ending date could be set for seven days in the future as a default. It might also be a good idea to have radio buttons that allow the customer to select a stay of 4, 7, or 14 days and calculate the ending date. Other improvements to a Web page might be detecting when a number of characters have been entered, for example the three digits that comprise a U.S. telephone area code, and then moving the cursor into the next field.
Events are not limited to working within a single Web page. They may also be used to control navigation among Web pages. This can happen when changing a selection in a drop-down list or clicking a radio button. Events may also be used to change the contents of drop-down lists. For example, on a job search page, by selecting one category of job, detailed positions for that job appear in a second drop-down list.