Download as pdf or txt
Download as pdf or txt
You are on page 1of 21

Rev 2.

3
October, 2019

Lab 7: Forms
WEB1201: Web Fundamentals

1 Introduction
So far, a lot of the HTML information has been “one-way”, i.e. from the the content creator
to the user. In this lab you will see how you can create forms that is used to collect data from
users.

2 Objectives
At the end of this lab, you should be able to:

1. Create a form and style it.


2. Explain the different elements and attributes used for creating forms.

3 Pre-requisites
Before you attempt this lab, it is important that you have completed earlier labs on HTML, CSS
and Page Layouts. You are expected to understand at least the following topics:

1. HTML terminology: elements, tags, attributes.


2. CSS terminology and knowing how to apply CSS in a variety of ways.
3. The Box Model: understanding padding, margins, etc. and how to apply them.

4 Deliverables, timing and additional notes


The estimated time of completion for this lab is approximately two hours. This does not include
the time you will need to answer the questions. You are to compile your work after every lab -
this includes all codes (and comments where necessary), documentation, completed tasks and
answered questions. Please submit your work.

5 Materials and Equipment


1. A computer with a web browser and text editor.
2. Paper and a writing instrument.

1
Note

Have a logbook to write down notes for labs. This will help you revise and reflect on the
work you have done in the lab. The lab is not intended as a typing exercise but one that
requires you to reflect and think about what you have done and learnt.

6 An introduction to forms
HTML forms are one of the main points of interaction between a user and a web site or appli-
cation. They allow users to send data to the web site. Most of the time that data is sent to the
web server, but the web page can also intercept it to use it on its own1

A HTML form like any other HTML document consists of elements. However, elements that
display information that can be changed by the user are known as control elements (i.e. can
be controlled by the user.) These control elements are also known as: widgets or control. The
built-in widgets are known as native widgets can be text fields (single line or multiline), select
boxes, buttons, checkboxes, or radio buttons (See more here). If the native form widgets are
not sufficient or do not provide what you need (e.g. because of styling or functionality, you can
build your own form widget out of raw HTML (See how to do it here).

Most of the time those widgets are paired with a label that describes their purpose — properly
implemented labels are able to clearly instruct both sighted and blind users on what to enter into
a form input.

The main difference between a HTML form and a regular HTML document is that most of the
time, the data collected by the form is sent to a web server. In that case, you need to set up a
web server to receive and process the data. You can this explore using PHP with the XAMPP
suite. If you are working on this in the lab, it is preinstalled and you need to launch it from
C:\xampp

Question(s) 1

1. What is the purpose of HTML forms?


2. How can form data be used?
3. Describe the main terms that relate to HTML forms.
4. What is the name(s) given to elements that display information and can be
changed by the user?

1
We will explore these two use cases of how the collected data can be used in later labs. For this lab, the main
aim is to first create the form.

2
7 What does a form look like?
A sample of an online form is shown in Figure 1. Look for the different parts of the form (i.e.
how the form is laid out) and the types of fields the form uses. Can you determine the type of
widgets used in this form?

Registration
Complete the form below to sign up for our membership service.

Name:
First Name Last Name

E-mail: ex: myname@example.com


example@example.com

Phone Number:
Area Code Phone Number

Address:
Street Address Line 1

Street Address Line 2

City State / Province

Postal / Zip Code

^ ^ ^
Birth Date:
Day Month Year

Where did you hear A friend or colleauge


about us?
Google
Roadshow
Article

Figure 1: An example of an online form.

8 Steps for creating a form


Before looking at how you code or implement a HTML form, we will go through the steps of
how you create a HTML form (Shown in Figure 2. This is modelled after the typical processes
of the SDLCe. We will look at each step as subsections.

3
(a)
Determine the general data to
be collected and break it down.

(b)
Determine the widgets to be
used for each field.
Requirements
Step 1:

(c)
Visualize the data and deter-
mine if the widgets are suitable
for the type of data.

You will need to ensure the


(d) user input is conforms to what
Are the you expect through validation.
widgets No
suitable?
What you should have at this point:
Yes - list of widgets (type)
- examples of visualized data
(e) - knowing how to validate the data
Determine the size of each
widget.
Design
Step 2:

(f)
Arrange the widget in a logical
layout.
What you should have at this point:
- a sketch of the form, including
(g) widget sizes, styles, borders, etc.
Code the widgets and the
layout of the form.
Implementation

The test cases should cover all


Step 3:

possible input types.


(h)
Test the form using your own Validation should ensure that
test cases. the input data is what you
Ensure validation of the expect it to be.
inputs/data work.
What you should have at this point:
- a form with widgets and valida-
(i) tion of the input data
Apply design and styles to the
Step 4:

form.
Style

Add colours, borders and


separators.

Figure 2: A flowchart of the steps in creating a form.

8.1 Step 1: Requirements

In this step, determine what general information you want to collect, for example, it can be
something very broad and general like “Personal information” or “Financial information”.

4
8.1.1 Step 1.1: Breaking it down further and determining the widgets

Saying you want to collect personal or financial information is too broad and is not useful to you
for you to start designing your form. You will need to further break this down into subcategories
and later on, into the specific fields that you will collect your data with. Here is an example of
how you can determine the general data you want and further break it down into specific fields
that you want to use to collect the data with. Note that in this example, the field type (i.e. input
or widget type) has been omitted.

Personal information Financial information


Personally identifiable details Savings/current account information
Name Bank name
First name Bank account numbers
Middle name Account type
Last name Credit/charge/debit card information
Salutation Issuing bank
Identification card/Passport number Card number
Family details Card type
Father’s name Limit
Mother’s maiden name Expiry date
Contact information Member since
Address CVV
Unit number Loan information
Unit type Loan type
Street 1 From
Street 2 Total loan amount
City Remainder
Country Duration
Postcode From:
Phone To:
Home Monthly/weekly repayment
Work
Mobile
E-mail
Social media
Other information
Date of birth
Course
Student/Member since

For now, an initial widget type will be assigned and you will determine or confirm the suitability
after you visualized the data in the next step.

Here is an example for determining the input types (in red), options (where applicable) and
what is considered valid data (in blue). Depending on the input type selected, some validation
will be performed (e.g. e-mail). While this is shown as a tree diagram as a continued example

5
from the previous step, it is easier to the fields, types, validation, size, etc. in a tabular form.
Personal information
Personally identifiable details
Name
First name Type: text (Alphabets only)
Middle name Type: text (Alphabets only)
Last name Type: text (Alphabets only)
Salutation Type: button or <select> . . . . . . . . . . . . . Note:
element. <select> is a HTML element and not a type
of input.
No validation required since options
You can read more here:
are given. Select Element
(Options: Mr., Ms., Dr., etc)
Identification card (IC)/Passport number (text) (Alphanumeric)
Malaysian IC number Type: number . . . . . . . . . Malaysian IC format is:
NNNNNN-NN-NNNN
(where N is a number).
Some forms ask for numbers only (sans
dashes).
For this, the input type number works.
Contact information
Phone
Mobile
E-mail Type: email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic validation is done using this type.
Other information
Date of birth Type: date

Remember, this is just an initial idea of what data you want to collect. You will have to refine
this once you start visualizing the data as some of the fields specified here may not be complete
suitable for the intended data you want to collect.

8.1.2 Step 1.2: Visualizing the data

At this point, you should have an initial idea of what data you want to collect from your form
and perhaps the fields you will need. You are now going to refine the initial idea by asking
yourselves these questions:

1. What does valid data look like (i.e. the format of the data you expect)?
e.g. what does a phone number look like? +(xxx)-(xxx) (xxxx)? Or a passport number?
2. Can I and would I want to collect it in a simplified manner (e.g. IC number sans dashes)?

For the sake of this discussion, we will look at the “Name” and “Phone”.

8.1.2.1 Example 1: Visualizing Names


Let us visualise some names that you might encounter in Malaysia, some more popular and
perhaps some less.

6
1. Robert Barrington
2. Muhammad Arif bin Salim
3. Anjpur A/L Siva
4. Ch’ng Ang-Lun
5. 陳港生
6. あらし

To refine your initial idea of how the data is to be collected, we are going to see if such data can
be collected by the form. Consider the following:

1. Can you split the names between first name, middle name and last name? Would you
even require it to be split? If so, why?
(a) If yes, determine how the names can be split up.
(b) If no, should your form just have the field “Name”? What are the pros and cons of
gathering the name as a single field and splitting it up?
Hint: There is a reason why localization is important.
2. Should the fields be renamed to better suit the names?
e.g. last name→family name and first name→given name
3. Also, I want you to consider the next step by thinking of the following:
(a) Can the widget support the data or input type of the fields that you have decided on?
(Look here for the different input types).
(b) Perhaps a custom widget? (Look here on how to create your own).
(c) How can you validate the input data? (either as a whole or for each widget)

8.1.2.2 Example 2: Visualizing Phone numbers


Let us visualise some phone numbers.

1. +(603)-7788 7788 5. +61 2 7010 4410


2. +60111-2324-1222 6. 7283 1231
3. +(609) 421 2142 ext 1215 7. 03-2120 42123
4. +1-202-555-0195

As with the names, to refine your initial idea of how the data is to be collected, we are going to
see if such data can be collected by the form. Consider the following:

1. What is the format of the phone numbers? Are you able to determine:
(a) The country code?
(b) The area code?
(c) Phone number itself?

7
2. What if you have an extension (typically for the office number)? How will you handle
extensions?
3. Also, I want you to consider the next step by thinking of the following:
(a) Can the widget support the data or input type of the fields that you have decided on?
(Look here for the different input types).
(b) Perhaps a custom widget? (Look here on how to create your own).
(c) How can you validate the input data? (either as a whole or for each widget)

Now that you have visualized the data, determine if the earlier chosen widgets are suitable for
collecting the data you want. At this stage (Step 1(d)), I want you to also think about how you
are going to validate the data entered by the user. You will eventually need to implement this in
Step 3.

Question(s) 2

1. Explain what web site localization means.


2. Explain how localization applies to the forms you are creating.
3. What does validation mean and entail?
4. What validation is done for the input type email?
5. (Challenge) Determine how you can validate an e-mail for Sunway University
students.
Hint: Regular expressions.
6. What kind of validation can you do for “date of birth”?

Task 1: Determining widgets and valid data types


In the example given in Step 1.1, fill in the (widget) type and valid data types (for validation) of
the fields from that example into a table.
As you are doing this, remember ask yourselves:

1. What does valid data look like?


2. Can I and would I want to collect it in a simplified manner?
3. What data or input type can support the data I am expecting?
4. How can I check if the data entered is valid? Or rather, what are the conditions I will need
to check for to ensure the values entered into the form is valid?

Here is an example of what your table should look like. As a reminder, this just an example
and your table should be one that reflects your own thinking and understanding of the questions

8
regarding the data gathering requirements. Do not expect your table to be the same. In fact, in
this example, East Asian language names have been omitted.

Table 1: Summary of widgets/field names

Widget label Type Valid data, options and validation


Name text What does valid data look like?
1. John Doe
2. Anjpur A/L Siva (or a/l, A/P, a/p)
3. Ch’ng Ang-Lun
4. Arif bin Salim (or Arif b. Salim)
5. Salima binti Salim (or Salima bt. Salim)
6. Roselynn Tan @ Tan Ros Lin
Summary of valid data:
1. Mix of alphabets, spaces and special characters
(apostrophes, at sign(@), dashes).
Note: forward-slashes and periods will be handled
as part of a keyword.
2. Uppercase characters at the beginning of the name,
after a blank space and hyphen.
3. Name may contain the following keywords found
in-between parts of the name. Keywords can only
occur once:
• A/L (ignore case)
• A/P (ignore case)
• bin
• b.
• binti
• bt.

These are additions from the next step, added to the table.

Size: 40 characters
Part of group: ......

8.2 Step 2: Design the form

In this step, you will be designing the form. This entails two main steps:

1. Determining the size of each widget.


This is fairly straightforward as it only involves how much data you expect a user to
enter. Typically, the data is saved in a database and this should equal or smaller than the

9
specified attribute (i.e. the column values).
2. Where the field is to be placed.
Just ensure that it is in a logical manner, i.e. where the reader will expect the next widget
to be. Apart from grouping the widgets, you need to determine how to layout the groups
of widgets and add appropriate headings.

At the end of this step, you should have a sketch of the form with the general placement of the
widgets, annotations on the widget that specifies its size and type (and even options), styles,
borders, lines/rules, etc.

Question(s) 3

1. When determining the size of the field, does it include blank spaces? or even the
end of line character (that indicates the start of a newline)? Newline character

8.2.1 Mockup or sketch

Designing a quick mockup will help you to define the right set of data you want to ask your
user. From a user experience (UX) point of view, it’s important to remember that the bigger your
form, the more you risk losing users (overwhelmed by the amount of data the user needs to key
in). Keep it simple and stay focused: ask only for that data you absolutely need. Designing
forms is an important step when you are building a site or application. You can read more here
and here.

Let’s start with a sketch of a simple form. A simple form was chosen for the mockup to This
was done on a grid to make it easier to visualise.

Contact

Name:
E-mail:
Message:

Send message

Figure 3: A sketch of a simple form.

10
9 Step 3: Implementing the form in code
In this section, we will look at implementing the code in three parts.

1. Understanding some basic form elements to introduce you to the form elements used for
implementation.
2. An example of the implementation of a form based on the “simple form” sketch.
3. Testing of your form.

9.1 Understanding some basic form elements

Before we look at how we are going to create this form in HTML, we will look at the building
blocks of such a form. You will encounter these elements in the explanation of how the form is
implemented.

1. <form>
• This is the element that will contain the form, i.e. a container element like <div> or
<p>.
• Requires an opening and closing tag.
• You can have multiple forms on a single web page.
• Can be configured with optional attributes that specify which server-side program or
file will process the form, how the form information will be sent to the server, and the
name of the form. Refer to Form Attributes for the form element attributes. Although
all the form attributes are optional, it is best practice to set at least:
– The action attribute defines the location (URL) where the form’s collected data
should be sent when it is submitted.
– The method attribute defines which HTTP method to send the data with (it can be
GET or POST).
2. <label>
• This element allows you to add a label (or caption) to your input.
• To associate the <label> with an <input> element:
– Method 1: Association via id
Give the <input> an id attribute. The <label> then needs a for attribute whose
value is the same as the input’s id.
// Method 1: Separate <label> and <input>
<label for="cheese">Do you like cheese?</label>
<input type="checkbox" name="likecheese" id="cheese">

– Method 2: Implicit association (by nesting)


Nest the <input> directly inside the <label>, in which case the for and id at-

11
tributes are not needed because the association is implicit.
// Method 2: Nest the <input> inside the <label>
<label for="cheese">Do you like cheese?
<input type="checkbox" name="likecheese" id="cheese">
</label>

3. <input>
• Used to create interactive controls for web-based forms in order to accept data from the
user; a wide variety of types of input data and control widgets are available, depending
on the device and user agent.
• How input works depends on it’s type attribute. By default, it is a text input type. You
can find more input types here.
• Two attributes that you need to be aware of:
– The id attribute.
This is a unique identifier for a given element (recall your CSS and HTML Global
Attributes). In the case of forms, an id is added to the input control to associate it
with a label. Remember that each id needs to be unique.
– The name attribute.
This is the name of the “variable” that is sent back to the server. A form can contain
many fields, so how can the server differentiate which date came from which field?
That is what the name attribute is for; to identify the input in the data submitted
with the form’s data.
• Apart from the type attribute, there are other attributes that determines how the input
control behaves. You can find a list here.
4. <textarea>
• Represents a multi-line plain-text editing control, useful when you want to allow users
to enter a sizeable amount of free-form text, for example a comment on a review or
feedback form.
• As it is a type of control, you associate it to a <label> just as you do with <input>; by
using the id.
<label for="story">Tell us your story:</label>
<textarea id="story" name="story"
rows="5" cols="33">
It was a dark and stormy night...
</textarea>

To explain the code:


– The rows and cols attributes allow you to specify an exact size for the <textarea>
to take. Setting these is a good idea for consistency, as browser defaults can differ.
– maxlength specifies a maximum number of characters that the <textarea> is al-

12
lowed to contain. You can also set a minimum length that is considered valid
using the minlength attribute, and specify that the <textarea> will not submit (and
is invalid) if it is empty, using the required attribute. This provides the <textarea>
with simple validation, which is more basic than the other form elements (for ex-
ample, you can’t provide specific regexs (shorthand for “regular expressions” to
validate the value against using the pattern attribute, like you can with the <input>
element).
– wrap specifies the wrapping behavior of the text when it reaches the edge of the
<textarea>.
– If you want default content for your <textarea>, you enter it between the opening
and closing tags. Unlike <input>, <textarea> does not support the value attribute
to have a default value.
5. <button>
• Represents a clickable button, which can be used in forms or anywhere in a document
that needs simple, standard button functionality. By default, HTML buttons are typi-
cally presented in a style similar to that of the host platform the user agent is running
on, but you can change the appearance of the button using CSS.

9.2 Steps to coding the sketched form

1. Create the form container using the form element in the HTML template file.
<form action="/my-handling-form-page" method="post">
...form widgets/controls go here...
</form>

2. Add control elements to your code using <label>, <input> and <textarea>.
<form action="/my-handling-form-page" method="post">
<div>
<label for="name">Name:</label>
<input type="text" id="name" name="user_name">
</div>
<div>
<label for="mail">E-mail:</label>
<input type="email" id="mail" name="user_mail">
</div>
<div>
<label for="msg">Message:</label>
<textarea id="msg" name="user_message"></textarea>
</div>
</form>

13
Now some explanation:
The <div> elements are there to conveniently structure our code and make styling easier
by allowing us to apply styles to the <div> elements. Note the use of the for attribute on
all <label> elements; it’s a formal way to link a label to a form widget. This attribute ref-
erences the id of the corresponding widget. There is some benefit to doing this. The most
obvious one is to allow the user to click on the label to activate the corresponding widget.

On the <input> element, the most important attribute is the type attribute. This attribute is
extremely important because it defines the way the <input> element behaves.
• In our simple example, we use the value text for the first input — the default value for
this attribute. It represents a basic single-line text field that accepts any kind of text
input.
• For the second input, we use the value email that defines a single-line text field that
only accepts a well-formed e-mail address. This turns a basic text field into a kind of
“intelligent” field that will perform some checks on the data typed by the user. This is
a type of form validation, e.g. if phone numbers should only contain numbers.
3. To set the default value for the input, you will need to use the value attribute.
<input type="text" value="default input text"/>

4. Now we add a button using the <button> element by adding this just before the form
closing tag.
<div class="button">
<button type="submit">Send your message</button>
</div>

You’ll see that the <button> element also accepts a type attribute — this accepts one of three
values: submit, reset, or button.
• A click on a submit button (the default value) sends the form’s data to the web page
defined by the action attribute of the <form> element.
• A click on a reset button resets all the form widgets to their default value immediately.
From a UX point of view, this is considered bad practice.
• A click on a button button does... nothing! That sounds silly, but it’s amazingly useful
for building custom buttons with JavaScript.

14
Note

FORM VALIDATION

There is one aspect of the implementation that has not been done here - Form validation. It
is important that you ensure the data is what you expect it to be as further use of the data,
either in a function or storing will expect data to confirm to a certain format or type. For
example: If you require a phone number and is expecting a number, then you should ensure
that you get a number rather than something else like “n/a” or “-” or “no number”. The
challenge here is to be able to determine how you can validate the different possible input
format for a single data (See the earlier section on Visualizing Data).

1. Discuss the pros and cons of validating data before form submission (i.e. on
the client or browser).
2. Discuss the pros and cons of validating data after form submission (i.e. on the
server side or the form handling page).

9.3 Testing your form

In this substep, you have to come up with your own test cases and methodology. As each of
your forms will be unique in some way and will be dependent on the different type of data you
intend to collect, how you visualize it, the length of it, etc. your form will have unique test
cases. Refer to the lab on Page Layouts 2 (Flexboxs) to recall how you can come up with test
cases.

At this point in time, as your form does not actually do anything until you have a form handling
page (which is what the action attribute is used for). The form handling page will have some
logic that will process the data (i.e. do something with it).

Task 2: Coming up with test cases for your form


In this task, based on your form requirements, design and visualization of the data, you are to
come up with test cases for your form.

1. Determine how many test cases you need.


2. Determine how you are going to present these test cases to a 3rd person, i.e. determine
how you are going to describe the tests and the test cases for someone else to perform the
testing.
3. Save your test description and test cases as: <studentID>_form_test_cases.pdf
(where <studentID> is your studentID sans the brackets)

15
Question(s) 4

1. Earlier, it was mentioned that “The <div> elements are there to conveniently
structure our code and make styling easier by allowing us to apply styles to the
<div> elements.”. Explain why you think this is so.
2. Explain if you are able to style the elements without the use of the <div>
elements.
3. Explain why the id attribute has to be unique.

10 Step 4: Styling (and formatting) your form


To apply styles (and perhaps formatting) to your form, you use CSS as you always have. Try to
recall the different ways of laying out pages from past labs. You can use whatever method you
feel suitable.

Reminder: Use the web development tools which you can find in most browsers. You can
activate the tools by pressing F12 or right clicking on the page and selecting “Inspect Element”
(in Firefox) or “Inspect” in Chrome. If it does not work on the browser you are currently using,
get a copy of the portable browsers from on eLearn or via a search.

Task 3: Styling a form


Modify the earlier form and style it to look like Figure 4. To do this, you will have to refer to
the lab on CSS styling and the box model (e.g. borders, text alignment, padding, margins, etc.)

Name:

E-mail:

Message:

Send your message

Figure 4: What your simple form should look like after styling.

16
To style this form:

1. Use the concepts of the box model. To be able to better visualize the box model (please
use a portable browser if you are using the lab computers), press F12 to activate the
inspector. From here, you can see the different elements on your page.
2. To layout the form, one option is to set sizes for the form elements. You can do this by
imposing the form onto a grid and giving a size to each grid cell.
Can you think of other methods to implement the form layout?
3. Check if the widgets have a size and ensure the right size.
4. Align the text. Add padding or margins as needed.
5. Save your styled form as: styled_sample_form.html

11 Reminder: Creating your own form


Here is a reminder on the main steps in creating your own form.

Step 1. Determine the general data to be collected and how you want to collect them.
(a) This means that you start off with the general data, e.g. “Name” and later on
decide what fields you will use to collect the name. For example, you could:
i. Collect the name as a single form field.
ii. Collect the name as two form fields: first name, last name
iii. Collect the name as three form fields: first name, middle name, last name
iv. Collect the name as two form fields with the salutation.
Note: Examples of salutations include: Mr., Mrs., Madam., Prof., Dr., etc.
What you should include depends on the purpose of the form.
(b) Create a form field table that will have the detailed list of fields. This table should
have three columns:
Column 1: Data fields (this will be the actual fields that go into your form)
Column 2: Input type (this will be the input type that you will use for your form)
Column 3: Description/Notes
Step 2. Design your form.
(a) Come up with a sketch of what your form will look like by arranging and grouping
the relevant fields together. For example, everything to do with the “Name” should
be put in a similar section of part of your form and not scattered all over. Perhaps
you may even want to put it under something more general such as “Personal
details” and include fields (e.g. age, gender, etc.) other than just those related to
the name.

17
Step 3. Code your form.
(a) Code your table using the fields and input type from your form field table. Do not
worry about the look of the table at this point in time.
(b) Ensure that all your fields, names, labels, default values, etc. are working as they
should.
Step 4. Style your form.
(a) Now that you have ensured that your form’s HTML code is correct, move on to
styling the form.
(b) Use divisions, separators (e.g. horizontal lines), colour, etc. to logically separate
the different components or sections of your form. Review the lab on CSS and
Page Layouts if you have problems styling your form.

Task 4: Create your own form


You are to create a form for a new user to register themselves for an e-commerce site.

Here are the steps of what you need to do. Please note that these are general steps and you will
have to figure out the details.

1. Determine what data should be collected and why. Save this in a table as: collected_
data_with_justification.pdf
Here is what the table looks like:

General data Input Notes and considerations:


type

Name Decide if you want to collect a single name or distinguish


between the first and last name.

Address How do you think addresses are normally collected? Do


you think it should be further broken down?

Contact details What kind of contact details should you collect?

Preferred method This will depend on what contact details you want to ob-
of contact tain.

Purpose of This will ask the user to input a reason for their registra-
registration tion. Do you think the user should be given options? If
so, how? What if there is more than one reason? What if
none of the options are the user’s purpose? Will they be
able to input their own reason?

18
Please note that the data described in this table does not automatically translate to fields in
your form. This is just merely a guide and you can differentiate the data you are collecting
e.g. rather than just asking for a name, you break it down into first and last name.
2. Look through the table of data to be collected. Decide how you should should collect the
data, i.e. how many fields and whether you should have any additional fields.
3. Come up with a data field table of your own with the columns:
• Data fields (this will be the actual fields that go into your form)
• Input type (this will be the input type that you will use for your form)
• Description/Notes (See Step 1)
4. Save your table as: <studentID>_widget_table.pdf
5. Based on your own table, create a sketch or a design of how you think your form should
look like. Save this sketch as: <studentID>_form_sketch.pdf
6. Assign an input type to each field.
You will notice that this have been left empty in the given table except for “Date of birth”.
The input type can be different from the table as the table does not provide the details of
each data. For instance for the data “Contact details” you can break it down into two:
phone number and e-mail, both of which should have a different input type.
Ensure that the input types for each of the different data collected are correct, e.g. a date
should have a “date” input type rather than “text”.
7. Create the form and style it where necessary. Do not forget to add a submit button. Save
the form as: <studentID>_implemented_and_styled_form.html

Note

Now that you generally know what kind of data you want to collect, how you collect it can
be different. This is where you have to take into account some of the considerations such
as the target demographic. The data “Name” will be used as an example. You could:

1. Collect the name as a single form field.


2. Collect the name as two form fields: first name, last name
3. Collect the name as three form fields: first name, middle name, last name
4. Collect the name as two form fields with the salutation.
Note: Examples of salutations include: Mr., Mrs., Madam., Prof., Dr., etc. What you
should include depends on the purpose of the form.

To recap: When you are designing your form, start with the general data you want to collect.
Next, determine how you want to collect this data, i.e. what fields do you want to use. Then,
design your form, grouping the fields in a logical manner.

19
12 Summary
This lab was to introduce you to creating your own form. It is expected that at the end of this
lab:

1. You will be able to design and create a basic form using the four steps.
2. You will be able to design and create your own form.

13 References
1. Form Attributes
2. HTML forms

Submission
In your submission archive, you should have the following files/folders:

1. All the named files in this lab

Ensure the following:

1. The file is correctly named and in the correct format. The naming convention is found on
eLearn but for the sake of completeness, for this lab it will be:
<ID>_<labNum>.zip, where:
• <ID> is your student ID, and
• <labNum> is the number of this lab.
2. Do not use any other archive type. The file you submit must be the zip format. If you
are using your laptop and do not have that software, you can download a free zip archive
creator from the 7zip download page. If you are using 7zip, remember to change the
archive format to ZIP. For Mac users, you can use Keka.

The submission link will be found on eLearn. Adhere to the guidelines and instructions on
eLearn.

20
Changelog
• Version: 2.3
Date: 18 Oct 2019
1. Changed the colour of some keywords to make reading easier.
2. Added some text to Step 4.

• Version: 2.2
Date: 14 Oct 2019
1. Added a little more explanation to Task 3. Changed the style picture as well.

• Version: 2.1
Date: 14 Oct 2019
1. Added tasks.
2. Rearranged sections.
3. Added the flowchart and sample online form.

• Version: 2.0
Date: 5 Oct 2019
1. Revamp the lab sheet. Rearranged the contents to first introduce the general steps to
create a form. Then introduce the basics of the form coding.
2. Changed the tasks to better reflect what is required.
3. Created a new LATEX class file for the lab sheets.

• Version: 1.3
Date: 4 Oct 2019
1. Updated the colours to highlight code or special keywords.
2. Updated Task 1 to include some hints or instruction on how to carry it out.

21

You might also like