This instructions page contain the following:
This is the sixth part of a multi-part project related to the fictional Oregon Film Festival site.
The fourth and last page you create for the Oregon Film Festival site will be the Contact page. It is based on the Home page structure without the need to revise it.
The Contact page will contain a contact form.
Below is a finished sample of how the Web page should look like when completed.
For the Oregon Film Festival site, we'll start by creating the fourth Web page.You have an index page (created in OYO 4), and you'll use that as the basis of your Contact page. The wireframe is the same as the one in OYO 4.
There are no changes to the div structure that was copied from the index.html page.
You'll first remove some content that carried over from the index.html page to this page. It's more accurate to delete whole tags in Code view.
You'll edit and update the content of the index.html page that copied over into this page. You need make it appropriate for this new page. Also, you can do much of this in Design view, or just stay in Code view if you prefer.
Laugh.
Love.
Learn.
Llama.
Our festival has all kinds of films.
A form is the most common interactive feature of a website. In this sense, "interactive" means how users can interact or do something with the elements of your pages. Of course, specifically, the form is how users contact you through your website. For almost all websites, the form is a required feature.
The form you create for this assignment will not actually work because that requires server-side scripting (like PHP) to make that happen. Server-side scripts can process the data submitted with a form and do things with that data like convert it into an email message that it sends to an email account, or put the data into a database, or use the data as the basis of a search for a search engine, or to output in some other format like XML, etc. The process of making forms work is covered in greater detail in CAS 222, Intermediate Website Design. For the purposes of this class, you'll just concentrate on the form design and how it looks.
It's common for beginning Web designers to mix up the term "form" with the term "field". A field is one box you can type text into, put a check mark in, or is a pull-down menu from which you can make selections. The form is all of the fields, plus the labels of the fields, plus the submit button.
This is an example of a typical contact form: (This is not the form we'll be doing in this assignment.)
For this Contact page, we'll add a form. Inside that form, we'll include a table. We'll place our labels and fields inside the table.
Instructor Note:
This is one of the very rare times I find a table useful (other than for just plain tabular data like the schedule in OYO 6). Since the content of the form (the labels and fields) will rarely change, if ever, a table is useful to keep them all lined up neatly.
Instructor Note:
It's very important to remember: a form consists of one form tag, and all of the table, input, textarea and Spry fields are nested inside that one form tag. That's ONE FORM TAG. You are doing it correctly in Dreamweaver if, in Design view, you have only one red dashed box surrounding all of the fields of the form.
Consider the disaster if you have multiple form tags. If your Submit button is in a separate form tag by itself, it has no relationship to the fields that are in other form tags. When you click that Submit button, it submits nothing.
Unfortunately, in Dreamweaver Design, if you forget to start off with a form tag, everytime you insert a field, it automatically surrounds it with a new form tag... a new form tag for EVERY field... thus making your form useless... ugh!
Now we can begin inserting the fields inside the table cells (tds).
Instructor Note:
Remember, rows are horizontal and columns are vertical.
Instructor Note:
This is a critical step. ALL form fields should have a unique ID and that ID should be lower case and no spaces -- it will appear in Code view in the HTML as both an ID attribute and a name attribute. The ID attribute will be used if you want to style the fields in CSS using an ID selector or target it with JavaScript. The name attribute is called by the server-side script to pull the data contained within the field into the server-side file for processing.
It's important that each field have both an ID and name attribute, and it's acceptable that those two attributes have the same value, in this case "name", since the attributes are used in two different ways. Dreamweaver automatically gives you both an ID and name attribute with the value you put in that ID field in the Input Tag Accessibility Attributes window.
The label field, however, can have any characters in it -- it's just text, so feel free to use caps, spaces and symbols for the label if you want.
Finally, the reason you're choosing Attach label tag... is to ensure that the label is connected to the correct field. This is an accessibility issue. If the label is associated with a field, then the form user can click on the label and have the cursor automatically position itself in the field. This is for people who have motor control or hand-eye coordination disabilities. Their assistive software can usually increase the size of a text label, but not the field itself. So, for them, they have an easier time targeting a label with the mouse than they do the field itself. When they click the label, the cursor jumps to the field, then they can begin typing in the field. This is also useful for people with visual impairments who are using screen readers to "read" the Web page for them. The screen reader can only read the label and not the field, so the user may not know where or how to click in the field. They can however use the screen reader to help them target the label, and by clicking on the label, they are automatically sent into the field so long as you have a for attribute in the label tag (as you selected in the Input Tag Accessibility Attributes window). If you selected that option, you can literally move the label anywhere on the page, although it's best to keep it near the field it's associated with for usability purposes.
Instructor Note:
A couple of your last actions are important to the success of moving a label away from a field. There has been a known issue or quirk in some versions of Dreamweaver with this process in Design view. If you insert the field with its label into Column 1, then attempt to move the field away from the label, the 'for' attribute will get lost (either completely removed or it will point to the wrong target field). It's best in Dreamweaver to move the label away from the field. Once again, move the label away from the field, and DO NOT move the field away from the label. It sounds like a minor issue, but it will make a big difference in how the label and field connect to each other. This is why you start by inserting all fields into Column 2, then pull their labels into Column 1.
Instructor Note:
The label doesn't have to match the value. The label will be seen by the person using the form, but the value is what's sent to the server-side script (if you have that set up) and what's received by the form data receiver (usually you). You can be quite creative with your values! Of course, these values can be seen in Code view... ahem...
Hold down Ctrl (Windows) or Cmd (Mac) and click to select multiple interests.
Instructor Note:
There are two button types. Submit will send the data contents of a form to a server-side script if all the form and field values are set properly. Reset will clear the fields so the user can re-enter their data. You can create both buttons on your form if you prefer.
Now we'll add the last two fields in rows 2 and 3. Both of these require editing the code. Also, because these are HTML5 additions to the form tags, you'll need to be sure your doctype for the HTML is in proper HTML5 format:
<!doctype html>
Instructor Note:
Notice that required is an attribute that doesn't have a value following it. The only value that is valid for it is "required", however required="required" was considered redundant, so you only need to go with the attribute alone.
That required attribute can go in any order in the input tag and is just shown at the end of that tag in the example above.
For this part, you'll use the CSS Styles Panel (All Button) to add to your existing oregonff.css style sheet for this page.
The lines on all the tds are a bit distracting on this table. To override the existing td style, you can use a descendant selector.
Instructor Note:
As you should be in the habit of doing, be sure to use a browser (or more than one browser) to check your Web pages on the SWS to ensure everything works properly.