|
|
|||
|
|
|
|
|
EarthWeb sites:
|
|
Chapter 14Form Design and Data Gathering with CGI Scripts
CONTENTS
Now that you've seen how to create the basic form tags, let's put that knowledge together with some of the HTML tags you've already learned and make your forms more intuitive, attractive, and meaningful to the user. You'll also look at how data is transferred to the Web server and how your scripts need to be written to deal with the data. Form Design IssuesCentral to the idea of form design is making the form as easy for users to understand and underwhelming enough that they follow through and fill out the form. The less incentive you have for them to fill out the form, the less likely they are to try. A clean, short form is more likely to entice users than a long, confusing one. There are a couple of rules you should consider when building your forms so that they're easier and more effective for users:
Sound simple enough? Let's move on to some of the specifics of this advice-and get these form tags to work. Line Breaks, Paragraphs, and Horizontal LinesThe first rule of form design tells you to use HTML appearance tags to make your forms more coherent to the user. Doing this will affect the layout in one way or another-it's up to you to decide which is best for your particular circumstance. Line BreaksUnlike text-oriented HTML, your best friend in form design is not really the paragraph tag-it's the line break tag. This is because you want to directly affect the layout of the forms, instead of leaving it up to the browser. Therefore, you've got to be a little more proactive. You'll end up with a lot of line break tags before your form is through. Consider the following example: <FORM> Figure 14.1 illustrates how this would appear in a browser. Figure 14.1 : These text boxes were inputted without <BR> tags. It doesn't look terribly clean, does it? To get each of those text boxes on a separate line, and thus more pleasing to the eye, we need to add the <BR> tag: <FORM> Adding <BR> forces each subsequent text box to the next line. This is a more attractive form, and the <BR> tags make it easier for the user to understand (see figure 14.2). Figure 14.2 : Look at the difference the <BR> tag makes! Notice then, that the parts of a form (like the <INPUT> empty tag) work a lot like text in a regular HTML document. Even if you add returns while typing, they're still ignored by the browser. You need <BR> tags to create new lines. Also notice the use of instructional text for these text boxes, which were put in boldface for the example. This is another important tenet of form design-using HTML emphasis tags to make things clear. Most of your forms will need instructions throughout, just like any paper-based form. It's a good idea to standardize your instructions, using bold or italic tags to make them stand out from your other text. Horizontal LinesAlong that same line of thought, you should not only use instructional text but also break your form into smaller chunks by using the <HR> tag. Start with Listing 14.1, which uses <BR> and emphasis tags. Listing 14.1 br_form.html Our Example so Far <FORM> Viewed in a browser, this form is easier for the user to understand, with instructions in bold and textboxes where you'd expect them (see fig. 14.3). Figure 14.3 : Adding "chunks" to the previous example. But there's still more you can do. By placing <HR> tags in your form, you make it clear that new instructions are coming up or that the form has reached the next logical chunk of entry. The <HR> tag simply makes it easier to look at as it guides the user through the different parts of the form. In Listing 14.2, you add <HR> tags at the logical breaks. Listing 14.2 hr_form.html Adding <HR> to the Form <FORM> Unfortunately, the form is a little larger now (see fig. 14.4). But I don't think you've sacrificed the approachability by adding <HR> tags. Increasing the white space in a form is nearly as important as keeping it short enough so it isn't intimidating to users. I think you'll agree that each part of the form now just makes more sense. Figure 14.4 : Adding <HR> tags to clearly define each new section of the form. As you experiment with forms, you'll find that the larger the form-and the more diverse the types of information you're asking for-the more useful the <HR> tag becomes in guiding your user's eye to the appropriate spots. Paragraph TagsParagraph tags are basically good for keeping form data together in smaller chunks. As always, paragraph tags will add space on either side of the text that they enclose. You don't always want to add <HR> tags just because your form needs some white space. For instance, here is a nice, short comment form: <FORM> Again, this is fairly easy on the eyes. But the spacing isn't really great, and there are a lot of horizontal lines (see fig. 14.5). Figure 14.5 : Comment form without the <P> tag. Let's look at this closely. Consider that second <HR> tag. Isn't that a little illogical? It seems that the user is supposed to select the product line that they'll be discussing in the comment form. The way it's set up, it isn't particularly clear that the <SELECT> menu and the comment <TEXTBOX> are related to one another. Using paragraph tags, then, you can get the desired spacing between the <SELECT> and <TEXTAREA> elements, without the horizontal line that seems to break the two apart. You can also pad the rest of the form a bit to keep it nicely spaced from the horizontal lines that you do use. The key is adding <P> tags as in the following example: <FORM> Isn't that better (see fig. 14.6)? Now, the <SELECT> and <TEXTAREA> elements appear related to one another, but things aren't as crowded as they would be if you'd just used the <BR> tag. (Of course, the <P> tags don't have to be on lines by themselves in your HTML document.)
Example: Fix-A-SiteIn this example, we'll start with a site that offers the bulk of the form elements you've learned, but none of the spacing and layout tips just discussed. It's just a plain little form. Then, let's go through it and change the way it looks to try to make it more intuitive and better looking. Of course, there aren't any truly right answers when talking about aesthetics. By the end of this example, see if you agree with the changes made. The HTML for your form is in Listing 14.3. Listing 14.3 old_form.html Making a Form Look Better <BODY> See how this looks in a browser in figure 14.7. Figure 14.7 : The initial attempt at the customer feedback form. Now, let's pull this thing apart a bit and make some changes. It's a fairly logical organization, so you should be able to figure out what the chunks are. The first chunk is the address section, which currently looks like the following: Enter your name and address: All this really needs is some HTML markup, some <BR> tags, a paragraph around it, and a horizontal line, shown in the following code: <P> As discussed in Chapter 13, it's also a good idea to set the size of your textbox a little larger than the MAXLENGTH. In this case, though, you've only changed the MAXLENGTH of state since you want to allow users to enter more than the allotted characters in other textboxes (hence, no MAXLENGTH value). Your next chunk is the computer-related questions. It might seem like two chunks, but let's use the idea of putting them in the same section of the form, since they are similar and don't take up much space. Here's the original code for this chunk: Please check the type of computer you own: How can you fix this? You need to be more specific about where the checkboxes and radio buttons end and how they are allowed to wrap with the browser screen (using <BR>). Plus, you should separate the three questions with <P> tags, like the following: <P><B>Please check the type of computer(s) you own:</B><BR> The three questions were separated into paragraphs, with an <HR> tag added at the bottom, since this would be one section. Also notice that the radio buttons all got <BR> tags, while we left the checkboxes. Why? Because it's always best to save space (by leaving the checkboxes on one line). But counting the characters in the descriptions of the radio buttons tells us that a single line of radio buttons would be well over 80 characters long-and that's likely to wrap oddly in the browser window. The final two chunks currently look like this: Please enter any additional comments below: These chunks only need minor touch ups. Let's separate the control buttons from the comment window and add some formatting: <P><B>Please enter any additional comments below:</B><BR> Then you close the form tags and you're done. By the way, that last little <HR> isn't really necessary-just my personal preference. And how does it look in a browser now? Take a look at figure 14.8. Figure 14.8 : Our mastepiece of a customer service survey. Other Tags for Form FormattingSo you've used <P>, <BR>, and <HR> tags for spacing things out and offering logical breaks for your forms. But what about other issues, like aligning form elements? You can turn to <PRE> tags and HTML list tags for that. Using the <PRE> TagOne of the most annoying parts of setting up a form so far has been the inability to line up textbox fields as they go down the page. For instance, whenever the Name: and Address: fields have been used in examples, they always look a little ragged. The solution is the <PRE> tag. Because anything between the two tags uses the spacing and returns, this tag does two things. First, it allows you to line up your textboxes. Second, it eliminates the need for <BR> tags at the end of <INPUT> tags, since the browser will recognize your returns. The following is a ragged example: Favorite Book: <INPUT TYPE="TEXT" NAME="book" SIZE="40"><BR> Displayed (between <FORM> tags) in a browser, this looks like figure 14.9. Figure 14.9 : Ragged textboxes in a form. To improve this situation, you can put this HTML between <PRE> tags and format them yourself: <PRE> Remember that you need to use spaces, not tabs, to create the space between the name of the box and the textbox itself. As before, you may need to play with the formatting a little to get things lined up like they are in figure 14.10.
Figure 14.10 : A much cleaner looking form.
Using List Tags for FormsThe last little form design tricks you'll look at involve using the list tags-especially <OL>, <UL>, and <DL>-to create organization for your forms. Nearly any form element can be part of a list, and there are often good reasons to use them. Consider the following example: <DL> You've used lists in this way before-to create indented lists or outline formats that help you communicate a little better. In this case, it also makes the form look a little better, too (see fig. 14.11). Figure 14.11 : Use list tags to spruce things up. A great excuse for using the <OL> tag is to create form elements that are numbered for some reason. Since the <LI> tag for an ordered list enters a number, you can simply add form elements to create a numbered form, as in the following example: Enter your guesses for the top three movies this week: <BR> Seen through a browser, each entry is numbered, eliminating the need for individual descriptive text (see fig. 14.12). Figure 14.12 : You can use an ordered list for your form. Example: Customer Service RevisitedLet's see if you can do an even better job with the customer service form you created earlier in this chapter. Now, you have the opportunity to clean up some of those textboxes and other chunks. Listing 14.4 shows the example as it stands (recall that figure 14.8 showed this same form in a browser). Listing 14.4 survey.html Customer Service Form <BODY> Clearly, the first chunk can benefit from the <PRE> tag so that you can line up those address lines. You might notice that because you're using the <PRE> tag, you no longer need the <BR> tag to end some of the lines, as in the following code: <P> What else can you do? Let's put the second chunk in list format. You can use a <DL> style list for the series of radio buttons. You probably shouldn't change the checkboxes since they're already formatted to appear on one line. The following code includes these changes: <P><B>Please check the type of computer(s) you own:</B><BR> Notice that the <BR> tags at the end of each radio button entry are no longer required since each <DD> tag automatically appears on its own line. The rest of the form can pretty much stand on its own. See how the whole thing looks in a browser in figure 14.13. Figure 14.13 : Our customer service form, now complete. CGI-BIN Scripts and Dealing With Form DataBefore we're finished discussing HTML forms, we should touch on how data is passed to the Web server and how your script needs to be written to handle this data. First, you'd better start with a quick discussion of CGI-BIN scripts. Using CGI-BIN ScriptsFor the most part, CGI-BIN scripts are designed to receive values from your user and then create HTML code programmatically (or on-the-fly) by way of response. Scripts are most often used to handle form data but can also be used to add things like "hit" counters and variable images (different images that appear at different times). For instance, to add a counter to your page, you might have the following: <IMG SRC="/cgi-bin/counter.pl"> This will cause the script counter.pl to be run and a value returned. The value will be the name of a graphics file, which will be used to display an odometer-style image, as in figure 14.4. Figure 14.14 : Adding a hit counter by calling a CGI-BIN script. An URL to a script can be used just about anywhere you might use an URL to another document, a hypermedia file, or an image. In a hypertext link, for instance, you might use a script that chooses a "random" Web page to return, as in the following: <A HREF="/cgi-bin/random.pl">Click me for a surprise
Actually creating the scripts is a little beyond the scope of
this book. Most of the time, CGI-BIN scripts are written in Perl,
C, Visual Basic, or a scripting language like AppleScript. If
you're a programmer, I'd recommend looking into a book that seriously
discusses the ins and outs of CGI programming. Creating scripts
can be complicated, but rewarding-especially if you have access
to your Web server and aspire to be a Webmaster as well as an
HTML designer.
In the case of forms, you've already seen that you call the CGI-BIN script in the <FORM> tag using the ACTION attribute. Once the script receives the data, it then needs to use that data to create an HTML "results" page, which is sent back to the browser. Receiving Form DataYou may recall from Chapter 13 that there are two different METHODs to pass data to the script you've created to deal with it. The two methods, GET and POST, cause data to be sent in different ways. The type of METHOD used to send the data is stored in an environment variable on the Web server called REQUEST_METHOD. The GETNT> method simply appends your form data to the URL and sends it to the server. Most servers will then store this data in another environment variable called QUERY_STRING. This string is generally limited to less than one kilobyte of data (approximately 1,000 characters) which explains why it is becoming less popular.
The POST method causes the
length of the data string to be stored in a variable called CONTENT_LENGTH,
while the data itself is redirected to stdin
(standard in). In effect, the data is made to appear to your script
or program that it was typed into the server using a typical keyboard.
Your script must then be designed to "parse" that input.
Generally speaking, programs that do this for you are already available. There are actually two steps to receiving the input: decoding and parsing. Data sent from your Web browser is encoded to avoid data loss-essentially by turning spaces into plus signs (+) and non-text characters (like !) into a percent sign (%) and a hexadecimal code. Once you've worked through the decoding process, you're left with a text input that follows this format (where the ampersand simply separates each pairing of NAME and VALUE): NAME1=VALUE1&NAME2=VALUE2&... An example of this is: ADDRESS=1234 MAIN ST&CITY=DALLAS&STATE=TX and so on. If you're not using a parsing program or library (which, ideally, would allow you to simply reassign the VALUEs in this file to variables in your script), then your script will need to accept this data, strip the ampersands, and reassign the values to appropriate variables. Your Script's OutputOutput is much easier. Because stdout (standard out) is redirected to the HTML browser, you simply need to use print (Perl and other languages), lprint (C language), or similar commands that print directly to the screen (or terminal or console). You use the print command to output HTML codes, just as if you were using your text editor. Here's a short snippet of a Perl script to do just that: print "Content-type: text\html\n\n"; In a number of programming languages \n is the newline character, which simply feeds a Return to standard out. Otherwise, this should seem (and look) rather familiar (see fig. 14.15). It's just HTML! Figure 14.15 : Results of the snippet of Perl scripting. SummaryForm design is something of an art and science-it's important that forms look good and be easy for the user to follow if they're going to be effective. There are some general rules you can follow for form design and, using other HTML commands you've learned previously, you can make your forms very easy to read. That, in turn, makes users more likely to use them. It's also important for Web designers to have some idea how forms send their data to the Web server and associated script-even if they don't intend to create the scripts themselves. A designer with almost any programming experience will find it fairly easy to manage data-gathering scripts from their Web site. Review Questions
Review Exercises
|
|
|
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |
