0% found this document useful (0 votes)
174 views5 pages

Job Info and Pay Calculator App

The document outlines requirements for a web application with four pages: a homepage, pay calculator, job information page, and about page. The pay calculator and job pages should use APIs to retrieve pay data. The application needs to be responsive, include validation, and follow best practices for accessibility, semantics, styling and code quality. Sources of any reused content or code must be cited.

Uploaded by

nazim virani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
174 views5 pages

Job Info and Pay Calculator App

The document outlines requirements for a web application with four pages: a homepage, pay calculator, job information page, and about page. The pay calculator and job pages should use APIs to retrieve pay data. The application needs to be responsive, include validation, and follow best practices for accessibility, semantics, styling and code quality. Sources of any reused content or code must be cited.

Uploaded by

nazim virani
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Implement a web application using the technologies and concepts you have learned in this

module. The goal is to develop a web application that provides users with information about
jobs and provides a pay calculator.

Web Application
The web application should follow a well thought out style and consistent design. It should
consist of FOUR web pages whose content is specified as follows:

1 - Homepage ([Link])
The main page should serve as a landing page for users. You should include an image and
general information about the application and its functions.

2 - Pay Calculator ([Link])


This page provides users with a pay calculator based on their wage and hours worked per
week. You should build an input form to allow users to enter their wage in GBP (with
options to select year/month/week/hour) and their hours worked.
Upon confirmation by the user, the page should then provide a styled output showing the
user their yearly- monthly- weekly- and hourly- wage. Calculations need to be performed
using client-side JavaScript.

Example: User enters £500 weekly pay and 35h per week worked. The page calculates the
yearly pay (£500*52), monthly pay (£500*52/12) and hourly pay (£500/35) and displays the
output to the user. Note: All pay should be rounded to two digits after the decimal dot.

3- Job Information ([Link])


This page will provide users with information about different jobs.
At the minimum, users should be able to enter a job title and then select the correct one
from a list of matching jobs. After selecting the job, users are then shown a well styled
output of the description, qualifications and tasks of that particular job.
Additionally, that page should also provide information about the most recent yearly pay of
that job.

In detail, you are required to use the LMI For ALL APIs ([Link] to
retrieve the job information and pay data. The first API will give you various information
about particular jobs and a SOC code. You can then use the SOC code to access more
information from the other APIs such as a jobs pay data.
Figure 1 LMI For ALL API to get Job Information

Use the /soc/search API (shown in Figure 1) to get access to detailed information about the
jobs based on search keywords.

This API returns up to 30 jobs matching the queried description. It also includes each jobs
title, description, qualifications, tasks and the jobs particular SOC code.

You are tasked to dynamically display the top TEN of those results. The user then can select
any of the results and the detailed description, qualifications and tasks of that particular job
will be shown.

Payment information for the selected job should also be included within this page. The
result of the previous API call returns a SOC code for each job, which needs to be used to
query the ashe/estimatedPay API (see
Figure 2). This returns historical data about the development of that jobs pay rate (per
week).

Figure 2 LMI For All API to get Historical Pay Rate Information

You should then reuse the JavaScript functions from the Pay Calculator page to calculate the
most recent annual pay for this job and display it.

Using the LMI For All Widget ([Link] will NOT give you any
marks, you are expected to build the API access and dynamic display part on your own.
Example: User enters “gardener” in the input field. The API queries the URL:
[Link]
The top 10 results are shown, and the user selects the first one: “Gardeners and landscape
gardeners”. The user is then shown the description, qualifications and tasks of that job.
Additionally, the SOC code (5113 in that example) of that “Gardeners and landscape
gardeners” result is then used to query the estimatedPay API with the following URL:
[Link]
This returns a list of pay rates per year. The most recent one will be selected and multiplied
by the number of weeks in a year, showing an annual salary (2019) of 52weeks*£840=
£43,680.

4 - About Us ([Link])
The About Us page should contain some content about the developer of this page.
You should also include a contact-us form. This form should at minimum have the following
fields/options:
- First Name Field
- Last Name Field
- Email Field
- How did you hear about us Field (allows users to select one option out of multiple)
- Message Field
This form does not need to be connected to any kind of database. As this module did not
cover connecting this, it is sufficient to display a JavaScript Browser Alert once the user clicks
on the Submit button (replace the content in square brackets with the user submitted
values):

First Name: [submitted First Name]


Last Name: [submitted Last Name]
Email: [submitted Email]
How did you hear about us: [submitted selection]
Message: [submitted message]

Other Web Application Criteria


In addition to the aforementioned functions of the web application there are also other
criteria that have to be met:

• The web application should be responsive and should be designed to display across a
range of different platforms (at least mobile and desktop)
• Sufficient navigation options should be provided such as links between the different
pages and internal links (if used).
• For all input fields, sufficient warnings should be added if the user does not enter
correct data. This means that when the user enters text into a field that is designated
for numeric values or the user enters something which is not an email into an email
field, an appropriately styled warning should appear
• You should use a user-friendly colour scheme. Some inspirations for this can be
drawn from pages like: [Link] [Link]
[Link]
• You should NOT use sample text; your web application should serve as a finished
product.
• The use of Content Management Systems such as Wordpress, Drupal, Joomla or
prewritten frameworks is NOT allowed.
• Code libraries such as jQuery and Bootstrap are allowed
• You should use semantic-markup as appropriate (<main>, <header>, <footer>,
<section>, <figure> & <article>)
• External Stylesheets and JavaScript files should be used
• Styles should use different kinds of selectors, in particular
o Element, Class, ID and Pseudo-Selectors
• All code files must include sufficient comments. It is not necessary to comment on
every single line of code but larger- or more complicated code should include them
(This also applies for CSS)
• The web application must work correctly in CHROME or FIREFOX.
• All HTML and CSS files must be validated. The results of the validation for each of the
four pages as well as the validation report for CSS used need to be included in the
submission. Use the validators at:
o [Link]
o [Link]
Take a screenshot of the validation report, label it accordingly such as “validation
[Link]” and save it within your submission

Sources
You need to ensure that you specify where you obtained any material you use and how
you have modified it. This MUST include specific web addresses (not just [Link]).

Table 1 Sources Template

Type Sources
CSS Table Styling
[Link]
us/articles/115001399529-Use-CSS-to-change-the-style-of-each-
row-depending-on-the-content
JavaScript (modified) Splitting String in split_string JavaScript function:
[Link]
string-breaking-at-a-particular-character
Image GCU Logo
[Link]

You might also like