Developing Web Applic

Case Study Report

TRIMESTER 2 2021

SID:
Contents

1 - Introduction........................................................................................................................................2

1.1 - Project aims:................................................................................................................................2

1.2 - Resources:....................................................................................................................................3

1.3 - List of User Stories:.....................................................................................................................4

2 - Literature Review...............................................................................................................................6

3 - Software Design.................................................................................................................................8

3.1 - General application decision flow chart......................................................................................8

3.2 - User Interface/Wireframe............................................................................................................9

3.3 - Database Design........................................................................................................................13

4 - Software Development Documentation...........................................................................................18

4.1 - User Story 1...............................................................................................................................18

As an interviewer I want to be able to log in so that I can access the system securely................18

4.2 - User Story 2...............................................................................................................................21

As an interviewer I want to be able to see from the home page the list of vacancies, the list

should tell me if I need to create a template or if I need to complete feedback for a vacancy......21

5 - Testing..............................................................................................................................................26

6 - Conclusions......................................................................................................................................28

6.1 - Advantages................................................................................................................................28

6.2 - Limitations.................................................................................................................................28

6.3 - Recommendations for improvement.........................................................................................28

7 - References........................................................................................................................................30
1 - Introduction

1.1 - Project aims:

A successful project aims to create an easy to use web application that allows the company

HappyTech to provide feedback to all applicants, regardless of position and stage in

recruitment.

The application should create a standard template to provide feedback to all applicants. This

template will include information regarding the person the feedback is for, details of who is

providing the feedback and what the feedback is related to.

Once created, the user will then use checkboxes and radio buttons to provide feedback. There

will also be an option to have a text box to provide specific feedback. This stage requires an

option to edit the template in the event it is insufficiently specific.

Once all feedback is collated, it should be saved as a PDF file, using the applicant’s name.

Once the interview process has been completed, all feedback sends automatically.

The project involves working incrementally towards the target, prioritising the tasks by

importance. Working collaboratively is valued, with the belief that working together on

changes facilitates rapid iteration.

The scope of the project is within this module, not for commercial use. Risks include the

project not being completed on time and errors in the code not being spotted.
1.2 - Resources:

Team members include:

All team members are responsible for managing and completing the project. The team

members will communicate via Outlook and Microsoft Teams. The team will look to Cristina

Luca for mentoring and training.

The tools used to complete the project are:

 Visual Studio Code

 Atom Code Editor

 GitHub

 Microsoft Publisher

 Codecademy

 W3 Schools Website

 Coolors Website

A team meeting will be held every Thursday 2pm - 4pm. This meeting will consist of a

progress review from the previous week, setting aims for next session, along with client

updates (Christina Luca).

A mid-week review of progress will be carried out every Monday at 7pm. This meeting will

review the progress for that week and allow for any issues to be resolved.

Frequent communication between these meetings will be maintained to ensure that the

workload is correctly managed and that team members can access help and support from the

rest of the team as required.

1.3 - List of User Stories:

 As an interviewer I want to be able to login so that I can access the system securely.

 As an interviewer I want to be able to see from the home page the list of vacancies,

the list should tell me if I need to create a template or if I need to complete feedback

for a vacancy.

 As an interviewer I want to be able to select the name of the interviewer and candidate

from a drop-down list

 As an interviewer I want to add custom feedback options with the possibility to delete

them so that I can customize the feedback form for every vacancy.

 As an interviewer I want to be able to save a created template so that I do not have to

repeat it once more.

 As an interviewer I want to be brought back to the home page when I save a template

so that I can quickly move on to creating the next template/see all vacancies and their

templates.

 As an interviewer I want to be able to delete a created template so that unnecessary/

unused templates do not take up space.

 As an interviewer I want to be able to navigate between templates, feedback form and

saved feedbacks so that I can quickly move on to next task.

 As an interviewer I want to be able to select what interview stage I'm providing

feedback from.

 As an interviewer I want to be able to use a template to quickly provide feedback for

candidates.
  As an interviewer I want to be able to retrieve and edit the feedback during the review

before submitting.

 As an interviewer I want to review the feedback and save it as a PDF.

 As an interviewer I want to be able to email all saved feedback to the candidates at

once.

2 - Literature Review

Dynamic HR web applications can massively reduce labour costs. Typeform1 is a customer

feedback tool. It puts surveys together, allowing the user to add questions and choose
templates. This site is user-friendly and runs smoothly. The questions, once answered by the

intended flows away and onto the next question. Whilst this is stylistically appealing, it does

not allow the user to go back and edit any answers to the questions. Another example,

15Five2 is an employee engagement survey platform. Managers are able to create custom

questions, set reviewers & employees, whilst allowing answers to be sent to other people.

The customisable questions afford the user flexibility. Promoter.io3 demonstrates an easy to

use navigation panel to the left of the main information. The main information contains

previously saved information and advises statistics regarding the information stored.

Figure 1 - Promoter.io - Navigation page

DocuSign similarly has a navigation panel to the left hand side, and a similar layout for the

main information stored on the right. You are able to manage these items, and see when it

was last changed.

Figure 2 - DocuSign - Template selector

There was not an exact example of the program this paper will build, but taking useful

features from the above listed resources may be useful. Additionally, being able to re-visit

any questions or templates to edit them in the future could be useful for a user.
3 - Software Design

3.1 - General application decision flow chart

Figure 3 - Application flow diagram

3.2 - User Interface/Wireframe

The wireframe contains two parts, the first page to create a template and the second page uses

this created template to allow the user to create feedback and save it as a PDF file.

The first page contains a header. This header shows the user that they are in the create

template stage. There are two drop down menus, one which will feed in the vacancies from

the database and allow the user to select which job they are reviewing candidates for. A

second drop down menu allows the feedback-provider to select their own name. This list is

pre-populated using the database of staff. Next to these options is a set of three radio buttons,

allowing the user to select what is being reviewed, either a CV, interview or technical

interview.

In the main content box there is a section for standard feedback options. This includes tick

boxes allowing the user to select what they wish to comment on. If, for example, the user

selects qualifications, in the next stage the user will be presented with two YES or NO

options in the feedback form to display the corresponding text, either ‘You have the required

qualifications for this role’ or ‘you do not have the required qualifications for this role’.

There is an option for custom feedback. The user will be able to click the ‘add’ button and be

presented with a text box that allows them to write in custom feedback. This will also

generate a ‘delete’ button in order to delete any unwanted rows.

Finally at the bottom, there are two buttons to save and delete the template.
The second page the user sees is the feedback page. The header contains a drop down menu

to select the candidate to be reviewed.

In the main body of the feedback form, the standard options selected via the tick boxes at the

template stage have appeared. There are radio buttons, YES and NO. Dependant on what the

user selects, text will generate next to this option, displaying a sample of the message sent to

the candidate.

Underneath the standard options are the custom options created in the previous page. The

user will then select the appropriate response via tick boxes. There is a free text box

underneath, allowing the user to write any further comments.

There are radio buttons at the bottom of the page, allowing the user to select which action

they want for the next step, telephone interview, technical interview etc.

Finally, buttons allow the user to save the feedback, reset the feedback, preview and edit the

template. If the user selects ‘edit template’, they are taken back to the previous creation page

to allow them to make any changes.

3.3 - Database Design
Overview: Happy Tech’s database is a relational database and consists of 9 tables. This can

be broadly split into three functionalities to reflect the flow of the program:

1. Storing users & candidates –

The database needs to store users of the software, also a list of vacancies and the respective

candidates that have applied.

The table users stores a user’s username & password needed to access the system. The

primary key is the UserID, and this table is linked to the feedback table, this is a one-to-

many relationship. This is used to show the logged in user the list of all feedback they have

generated.

The candidates table contains the Primary Key of CandidateID which is linked to the

application table via a one-to-one relationship. The purpose of this table is to register

applications from candidates and link them to a vacancy.

The table vacancies has the Primary Key of VacancyID and is linked to the tables

application and templates via a one-to-many relationship. The purpose of this table is to

store the list of vacancies on the database, and enable the gathering at runtime of linked

applications and feedback templates.

2. Storing templates & custom feedback options –

The database must store created templates.

The table templates has a primary key of TemplateID and is linked to vacancies via a one-

to-one relationship, and feedback and comments as one-to-many. The comments table

allows custom comments stored in the database to be linked to a TemplateID. This template

can then be linked to a specific vacancy.

 3. Storing feedback & providing feedback –

Finally the database will store feedback and provide the feedback to candidates.

The table feedback has the primary key of FeedbackID. This table stores the feedback and

which application and candidates it applies to. It is linked to the tables; application, users,

templates, and feedbackcomments.

The table feedbackcomments, stores free form comments entered onto the template at the

stage of completing the feedback. This has a primary key of FCID and is linked via a one-to-

one relationship to tables feedback and comments.

The table feedbackfile is responsible for storing all of the completed feedback in relation to

one candidate. It is then used when generating the preview page, and subsequently emailing

the feedback to candidates. It has the primary key of FileId, however it is linked to the table

feedback via a one-to-one relationship with the FeedbackID key.

4 - Software Development Documentation

4.1 - User Story 1

As an interviewer I want to be able to log in so that I can access the system securely.

Design – For the front end I used a simple login page from W3Schools4. To login a user

would be provided with a username and password, which is stored in the database in the users

table. Aside from the standard styling with .css elements, the login page included styling for

the colour of the login button and the submission form. The colour palette was provided by

coolors5

Implementation –

Core Files:

 login.php

 loginbackend.php

 nav.php

 createtemplatefail.php

 feedbackfail.php

When the user arrives on any page with protected access, a php script will check if session

variables have been set for their username. These session variables can only be set via the

login page when a login has been completed successfully. In the event that no session

variable has been set for the user they will instead be presented with a message advising them

to login.
The page login.php provides a form for users to provide their login information to. This is a

html form with two text inputs, username and password. It also has a submit button which

will post the form contents to loginbackend.php.

The page loginbackend.php is where user credentials are verified, it creates a connection to

the backend mySQL database using PDO. PDO is the preferred connection over mySQLi –

using PDO means that only a few lines of code will have to be changed if another database

needs to be used, as opposed to a full rewrite if mySQLi were to be used. The username that

was posted from the login form in login.php is used as a query to select rows from the users

database table. The first error case is that the username cannot be found in the users table. If

this occurs, the user is informed that their username was not found and is redirected to

login.php, to try again.

If the username was found, it is then necessary to check that the password is also correct.

Passwords stored in the users table are all hashed using the default password_hash(). Doing

this prevents the user from having their passwords stolen in the event of a security breach.

The password_verify function in php takes a raw text password as an input, hashes it with

password_hash function and compares it to the hash of password retrieved from elsewhere. If

it evaluates to true, this means that the hash of the raw text password and the saved hash

password match.

If the user logs in successfully, two session variables will be set (Username, LoggedIn).

Other restricted access pages can then check these variables to see if the user should be

allowed to access their content. If password doesn’t match, the user is redirected to the login

page to try again.

So that all pages can check if the user is logged in without explicitly starting a session at the

same time, the script nav.php will always check if a session has been started for that page and

if not, will start one.

4.2 - User Story 2

As an interviewer I want to be able to see from the home page the list of vacancies, the list

should tell me if I need to create a template or if I need to complete feedback for a vacancy.

Design – Once logged in a user will be presented with a list of vacancies that are stored in the

database in the table ‘vacancies’. The user will be able to see from looking at this list which

vacancies have a template created, and which do not. Buttons will show asking the user to

either create a template, or to complete feedback for a vacancy. The table is generated from

the database, checking if a vacancy has a corresponding template in the table ‘template’. This

page was created to make it easy for the user to see what they needed to do when logging in.

Implementation –

Core Files:

 index.php

 IDX_delete_template.php

 IDX_generatetable.php

Index.php is the default page for a logged in user. The dynamically generated table will only

be generated if the user arrives at this page after having logged in successfully. This is

ensured by wrapping the database access and html creation functions in an if statement which

checks for the existence of session variables.

The table is generated by two functions. The first connects to a mySQL database and gathers

information (getVacancyData()) and the second generates HTML to represent that data

(echoTableHTML()).

The first part of the function involves preparing two mySQL statements. The first is a simple

query to retrieve every row from the vacancies table. The second query is a conditional

statement for selecting rows from the templates table. The condition selected upon is the

VacancyID. A dynamic parameter is used for VacancyID so that arbitrary values can be

provided to the statement when it is executed. The function then initialises three arrays which

will be used to contain return values.

Upon successful retrieval of the data, the if statement will evaluate as ‘true’, and the

contained code block will execute. The main loop is a while loop which fetches individual

rows from the vacancies table and continues to loop conditionally upon the successful

retrieval of the next row. For each row that is retrieved, the VacancyID that it contains will be

provided to the prepared template query as its dynamic parameter. This query will then be

requested to fetch a matching row from the templates table. Since the relationship between

templates and vacancies is one-to-one no code is needed for a case when multiple rows are

returned. If a vacancy row was successfully retrieved we append a ‘true’ value to the $found

array, the TemplateID to the $templateIDs array, in addition to the entire vacancy row which

was appended to the $vacancies array at the start of the loop. If a corresponding template was

not found, a ‘false’ value is appended to the $found array and a -1 value is appended to the

$templateIDs array. Appending to all three arrays each time the loop executes guarantees

each index position in all three arrays will always point to the same template/vacancy

combination. These three arrays are added to an array themselves to be returned as php does

not support multiple return values from a function.

The HTML generation function accepts a single array as an argument which then expanded to

recover the three arrays populated in the database access function. The function then creates

the static part of the HTML table which is it’s header row.

A for loop is used to iterate through the three arrays. Since the arrays all have the same

length, the same value ($x) can be used to index all of them. Each row in the table consists of

two parts, the first part, consists of three columns with data from the vacancies table. A table

row (<tr>) is generated containing the three variables retrieved from the current row that was

fetched from the vacancies table.

The second part of a table row contains a set of user options which are conditional upon

whether or not a corresponding template was retrieved for that vacancy. The php script

generates two sets of buttons, wrapped in HTML forms. $buttons1 is displayed if a template

is found in the database, indicating to the user to complete feedback. It contains two forms,

the first form posts to feedback.php, and the second posts to IDX_delete_template.php. These

are the destinations for the ‘Complete Feedback’ and ‘Delete Template’ buttons respectively.

These forms also contain hidden fields which are provided with the current respective

templateID. This propagates templateID to the pages posted to.

$buttons2 is displayed if no template is found and prompts the user to create a template.

Similar to the previous, a form posts to createtemplate_main.php. However, in this case since

no template exists, the vacancyID is posted so one can be created for it.

Finally, an if statement evaluates whether or not a template row was retrieved for this

vacancy using the $found array. This logic controls whether or not buttons 1 or 2 gets echoed

alongside the start and tail of the table.

5 - Testing

Test Condition Expected Response Pass/Fail

No user name ‘Please fill in this field’ PASS

No password

Correct Username ‘Your password is incorrect’ PASS

Incorrect password

Incorrect Username ‘Your username is incorrect’ PASS

Correct Password

Correct username Redirect to nav.php PASS

Correct Password

Test Condition Expected Response Pass/Fail

Display list of vacancies + Display correctly relevant vacancies PASS

actions from database

Complete feedback Allows user to complete feedback PASS

Create template Takes user to template creation PASS

Edit Template Takes to template, allows user to PASS

change

Delete template Delete template and remove from PASS

database

Logout Logs user out/destroys session PASS

Test Condition Expected Response Pass/Fail

Create name Allows user to select name PASS

List vacancy name Displays name from database PASS

Select radio buttons for stage Allows user to select stage PASS
 commenting on

Tick box for pre-populated Tick boxes for pre-populated radio PASS

feedback buttons on template

Add custom feedback Add button creates new row PASS

Delete custom feedback Delete button removes row PASS

Save Template Saves template to database PASS

Test Condition Expected Response Pass/Fail

Select Candidate Select user from drop down and PASS

populate feedback

Radio buttons for generic Populate positive sentence PASS

feedback – YES

Radio buttons for generic Populate negative sentence PASS

feedback – NO

Custom comments displayed Pre-written comments displayed PASS

Text box for other comments Allows entry of comments PASS

Decision selector Populates decision PASS

Save Saves to database PASS

Reset Reset all selections PASS

Preview Shows all feedback PASS

Save PDF PDF populates PASS

6 - Conclusions

6.1 - Advantages

 The application relies on a relational database, this allows programmatic access to

data and is easily queried. In addition, relational database designs can be visualised

and modified quickly with the current range of mySQL tools. All information is

divided into appropriate manageable tables. Key matching between tables enables a

suitable range of query types for this tool.

 The application makes it easy to see if the user is logged in or logged out, by checking

session variables have been set before displaying data on the each page. If they do not

exist a message is echoed asking the user to consider logging in.

6.2 - Limitations

 With regard to the original brief set by the customer, the program is unable to email

feedback automatically to applicants. Whilst the program can generate a PDF, which

can then be saved and then emailed to candidates, it would have been preferable and

user friendly to have a button after the preview screen to allow the user to email this

PDF to an applicant, providing the automated feedback. This could be achieved using

an addon or using the mail() function.

 Once a user logs in they remain logged in until they choose to logout. This is

dangerous as this could make to program vulnerable to attack. This could be rectified

by using the ini_set function, to set a session timeout.

6.3 - Recommendations for improvement

 After initial implementation, the testing phase was slow due to imprecise definitions

of each function/page’s exact purpose. Test driven development would streamlined

the team’s development efforts here. Performing manual testing is time consuming
 and not as reliable, as there is no way to consistently perform the same tasks required

to test the full functionality of the program. Whilst manual testing is easier and better

for UI testing, it would have been preferable to write automated tests before building

the application, as this would have made testing compatibility of new features easier

and quicker, in line with the Agile methodology.

 The application is not compatible with all browsers, the program was not tested on

Safari, and Chrome displays an error when the password is entered. The password is

hashed, allowing the user to enter ‘Password1’ but as this is such a vulnerable and

common password Chrome displays a message stating that the user’s login details

have been compromised. The application runs smoothly without any errors on

Microsoft Edge and Opera. For further improvement, work could be done to ensure

that the application is compatible with all browsers, especially chrome as it is

commonplace.

 The structure of the application could be easier to use. Rather than navigating through

several different pages, it may be easier for all of the interaction to take place from a

more modern ‘single-page’ webapp, which frameworks like React and Angular

facilitate. Currently, a user is presented with a navigation panel and then has to click

to different pages, and then back to the home page. It would be better for the user to

be presented with the navigation panel, have the forms they wish to use ‘pop-up’

when clicked on from the navigation panel. Once all data is saved the pop-up would

then disappear. This would be a better alternative as it would stop the user having to

navigate continuously.
7 - References
1
Typeform.com [online] available at > https://www.typeform.com/product/ [accessed 19/02/2021]
2
15five.com [online] available at > https://www.15five.com/ [accessed 19/02/2021]
3
Promoter.io [online] available at > https://www.promoter.io/ [accessed 19/02/2021]
4
W3Schools [online] available at > https://www.w3schools.com/howto/howto_css_login_form.asp [accessed 24/03/2021]
5
Coolors [online] available at > https://coolors.co/f4f1de-e07a5f-3d405b-81b29a-f2cc8f [accessed 24/03/2021]