March 31st, 2022

SimplyPet

Everything you and

your pet need in one
app

Computing Project 2 - IS52018 (2021-2022)

A web application designed to aggregate the most important features a pet
owner will need into one place, to make pet owning simpler.
Brought by 6 passionate, pet-loving students.

Filip Condac - [email protected], 33684536

Sebastian Farrant - [email protected], 33643814
Edoardo Fiore - [email protected], 33655793
Omar Tahir - [email protected], 33684350
Riann Rahman - [email protected], 33638195
Zofia Kaska - [email protected], 33672521
Content
Introduction 4
The Lean Start-Up Method 5
Project Management 7
The Team 7
Methods and style 8
Specification 11
Functional Requirements 11
Non-Functional Requirements 11
System performance and scalability 11
Usability and accessibility 12
Security and reliability 12
Technical Specification 13
Code Style 13
Technical Challenges 13
Pet Passport Page 13
Pet Tracker Page 13
Booking Page 14
Technical Architecture 15
Software Architecture 15
Log In System 16
Pet Passport Storing Data 17
Booking system back-end 17
Pet tracker system back-end 17
Design 18
Overview 18
User Guide 20
Home Page 20
Log-In & Sign-Up Page 21
Pet Tracker 22
Pet Passport 23
Booking Page 24
About Page 25
Contact Us Page 26
End-Product Testing 27
UI + Usability evaluation 28
Testing methods 28
Results 29

2
 Testing methods 31
Results 31
Home Page Analysis 32
Notable Thoughts 32
Pet Passport Page Analysis 33
Notable Thoughts 33
Pet Tracker Page Analysis 34
Notable Thoughts 34
Appointments Page Analysis 35
Notable Thoughts 35
Contact Us Page Analysis 36
Notable Thoughts 36
Conclusion 36
Functionality Evaluation 37
Error handling 37
Test driven development and unit testing 37
Evaluation Plan 39
User evaluation involving representative stakeholders 39
1. Pet owners 40
2. Veterinary Practices 40
3. Developers 40
4. Sponsors 41
Evaluation 41
Future Work 41
Ethical Audit 43
Conclusion 44
Bibliography 45
Appendices 49
1) Meeting Log 49
2) Online Resources used during the project 53

3
Introduction
The second half of this project, and subsequently this report, is the product of our team
utilising market research and knowledge we obtained when developing our project
proposal to bring our idea to life. We have developed and outlined our software’s value
proposition and key functions in accordance with our market research and competitor
analysis through the means of research backed by data (appendix 2.8), surveying,
designing, and prototyping that was conducted in the proposal phase of our project.

Our initial M.V.P. (Moogk et. al, 2012), includes software functions such as the ability to
schedule veterinary appointments, aforementioned ‘Pet Passports’, and a pet tracking
service. Drawing back to our critical evaluation and evaluation plan conducted at the
end of our project proposal report, we are placing a great emphasis on the streamlined
simplicity and ease of use of our software application - abstracting anything that is not of
direct use to our potential users, ensuring the product was easy on the eye and simple
to navigate. This was one of the underlying key concepts discovered when researching
and analysing other successful services operating in a similar field to ours. Using our
earlier prototypes and subsequently the insight they gave us, we know our software has
to look professional, sharp and clean. We have identified the most applicable colour and
design schemes for our application, taking inspiration and incorporating elements from
successful competitors.

4
The Lean Start-Up Method
Referencing the double diamond approach (Rugman et. al, 1993), to product
development and design, we have now completed our initial research stage, the
diverging process, where we discovered insight into our problems and the many ways
they could be solved. Subsequently, in our research converging process we refined our
potential solutions and narrowed our scope into an idea of what our product needed to
be. We are now converging our ideas and research conducted in our project proposal
into a tangible product and working solution. This report is a comprehensive
documentation of our development process following on from our design and research
phase. We will be outlining our project management, development specification, coding
styles and exhaustive testing techniques as well as any relevant technicalities and
challenges we face along the way. A complete evaluation is present at the end of this
report critiquing our subsequent work and examining any challenges we faced. We have
also reflected on how we could refine our development process for any projects we
decide to undertake in the future.

5
 Double Diamond Approach (appendix 2.5)

Using the Lean Start-up Methodology, the platform’s objective will be to create a
minimal viable product, which will avoid creating products that users may reject nor
require, allowing developers to collect the most amount of verified learning with the least
amount of work while providing a high-quality result (Duc et. al, 2016; Ries, 2011).
Creating a clear MVP, measuring, and learning will be essential, as will actionable data
that indicates the cause-and-effect question (ibid). To attract early investment, Simply
Pet will focus only on the booking system, pet tracker and pet passport (Blank, 2013),
while the final goal will be a multi-featured pet services aggregator. To develop a solid
and durable MVP, the strengths, weaknesses, opportunities, and threats analysis is an
essential tool and will help measure the potential benefit and cost trade-offs (Sabbaghi
et. al, 2004). When we look at the SimplyPet’s SWOT analysis diagram designed with
Venngage (appendix 2.6), we can see that it has potential, but also many challenges
ahead, such as maintaining a high degree of accessibility and inclusion after the product
is deployed. The platform is particularly vulnerable to imitation and substitution, which,
when paired with a high barrier to entry imposed by the significant financial investment
required to establish it, might lead to increased competition if imitators or replacements
gain momentum (Porter, 1989).

6
7
Project Management

The Team

The Team (appendix 2.13)

Fortunately, the evaluation of our technical architecture from our project proposal
showed what we planned to use will work best for our team, allowing us to work in such
a way that we can all be efficiently engaged in all areas of the project. Each team
member will be able to utilise their skillset to the highest degree, encouraging the
highest level of productivity. We did initially consider utilising more complex options and
processes but did not want to take the risk of being unable to complete the project or
having to backtrack on ourselves to find an easier alternative.
As the project became more technical, we decided to proactively section the team in
two smaller groups. Sebastian and Ed would focus on the report using Google Doc

8
(appendix 2.15) and subsequently formatting it on a Word document (appendix 2.16).
Would then carry on with the testing, and the business side of things, as their university
programmes are more entrepreneurship/business focused.
On the other hand, Filip, Zofia, Omar and Riann would work on the development of the
application, with Filip assigned as the team leader given his extensive knowledge in this
field. Although the team was split in two mini-teams, collaboration, and communication
across the two teams has been necessary to keep pivoting and re-iterating as the steps
progressed. On the two weekly meetings the development team would present to the
business team the progress done, share the contents, whilst the business team would
present the progress made on the report and on the testing. Each team then carried on,
on their specific tasks as a group and individual tasks, always reporting the progress on
the Gantt diagram and meeting log.

Methods and style

Following the presentation and design of the application, we kept working as a team
slightly differently than we did in the first part of the project. Meetings took place twice a
week in person and on Teams (appendix 2.14), and after every lecture with Sean we
would then meet up and reiterate based on his feedback.
We kept using Trello (appendix 2.9) as a project management tool (see board below).

https://trello.com/b/J4FkiPZ2/software-project-2

9
We added any applicable research or knowledge discovered to Trello, in line with the
progress made with the testing phase. We also shared links to various documents
stored in the cloud such as Gantt Chart, Final Report, Surveys, and other spreadsheets
we used to monitor the testing phases of the project to Trello. Trello also allowed us,
along with the meeting log (appendix.1), to assign tasks to each of us and track, monitor
and assess the outcomes collectively on each weekly meeting.

One of the fundamental project management methods we are incorporating during this
phase of the project is using Git (see below gif going through the steps for pulling and
committing changes). The development team adds and implements their contribution
from their personal devices, through Visual Studio (appendix 2.12). They send requests
to the GitHub project, and then one of the other team members amends and approves
the contributions.

10
This allowed the development team to work collaboratively on the project, still doing
their own parts of code and general parts of the project to GitHub (appendix 2.10).
This allows everyone to see each other's code and subsequent updates to certain areas
of the software in real time, letting us continuously monitor and evaluate its
development.

The project on GitHub was split into multiple branches dedicated to individual pages of
the software application. This separation reduces error severity as they were unable to
affect the project as a whole; errors are limited to the branch they were caused in. Once
the project had finalised these branches then merged into a whole functional project.
We scheduled two weekly meetings as a team, Monday at 12pm and Wednesday at
9am. The business team meets once more per week to work together and motor the
progress of the testing and report. During these meetings we discuss and assess what
progress we have made throughout the week, as well as bring up any potential
difficulties we are facing, collecting feedback, and seeking help from each other when
needed.
A record log, shown at the end of this report (appendix 1), keeps tabs on these
meetings and thus allows us to track our progress and make sure we are staying on
course in respect of our timeframe. This record log also ensures each member is kept in
the loop irrespective if they are unable to attend one of the meetings.
A Gantt chart (Kumar, 2005) was also used across the period for the project to monitor
and track personal and group tasks. See snapshot below, taken on March 8th.

11
 Gantt chart used during the project development

Specification

Functional Requirements
Functional requirements are product attributes and properties that are required for users
to accomplish their tasks and for the system to perform as intended.
Our functional requirements remain unchanged for the most part from our design phase.
We have outlined that the system must be able to register user accounts and those
users must be able to log into those accounts that they have created. The passwords
entered in by the users when logging in and registering must be hashed and stored
securely in the database. The system must check new login details against existing
details in the database to ensure no duplicate emails and usernames are created, and
instead ask the user(s) to sign up using a different username or email. The system must
allow users to register with supported Veterinary practices on the software, enabling
them to schedule and book appointments as well as to cancel them. The software
allows users to create ‘Pet Passports’ where they can create, store, edit and access
information about their pet(s). This information should also be able to be shared to their
registered veterinary practice. The users should be able to track their pets on the
system by connecting a compatible third-party tracking device. The software should
work across all mainstream operating systems and should be supported on all
mainstream browsers. It should not require any exceptional computing power with
regards to CPU and GPU standards. The application is lightweight and should have
minimal latency running on commercial internet speeds.

Non-Functional Requirements

System performance and scalability

(Nielsen, 1993) Outlined three primary metrics for response time for webpage loading.
For loading times of 0.1 seconds and below, the user feels as if the software is reacting
instantaneously. For loading times of around a second, the user will notice a delay but
not experience any interrupted thought patterns. Loading times of ten seconds or more
will result in the loss of the user's attention. Following these guidelines and expectations
for web application performance, the software should start up within 5 seconds of
loading. Running on a stable internet connection, the software should also incur minimal
latency in the range of <2 seconds when traversing between different pages on the site.
This is not considering loading and response times from third party software on our web

12
application, which has been used for the geo tracking feature. The software should be
able to perform within these ranges +-20% when operating at perceived maximum
capacity.

Usability and accessibility

There is an appropriate use of metadata on the web application, specifically the use of
alt tags describing any images that are present on the site. There is a high polarity
between relevant foreground information and elements existing in the background to
make relevant text and objects easy to read and interpret. Information text is displayed
clearly and concisely to adhere to an accessible reading level thus providing a high level
of learnability. The interface’s layout is also consistent when traversing different pages
to ensure a proficient level of memorability for users interacting with the software.
Appropriate error handling has been put in place to ensure continued and streamlined
usability of the application regardless of erroneous action.

Security and reliability

Passwords generated and entered the software will be subsequently hashed and stored
securely on the database which prohibits unauthorised access. The application ensures
no duplicated details can be entered into the database by running a check every time a
user signs up thus ensuring protection of sensitive information from other users. The
password is never displayed publicly and hidden from the users throughout the web
application. The pet tracking data will also be stored securely and not accessible to
anyone but the relevant users and third-party handlers.

13
Technical Specification

Code Style
The development team had some meetings before beginning where some standards
and coding guidelines were defined. Code has always been indented according to the
general coding indentation rules for comprehensibility (Mara et. al, 1983), same went for
comments all cross to make it easy to read and understand even if you were not
involved on that task would allow you to understand it (McConnell, 2004).
We generated a template HTML that has the header, footer, and all semantic tags and
has been passed on to all website pages.
When building the programme, accessibility was also considered, with high semantic
tags and alt text for images. Except for several internal inline CSS needed for some
special conditions, CSS has been kept mostly external to enable tracking and editing of
the programme.
Even in the early prototypes, we employed CSS tags like REM to make the website as
responsive as possible. Gifs showing page responsiveness are included in the design
section.

Technical Challenges

Pet Passport Page

Some of the problems we had with the initial pet passport page design were primarily
with the ID card organisation and layout. The key goal was to keep the pages both
accessible but also design orientated to enhance user experience. The ID cards needed
to shrink according to the page size in a way that protects their specific shape and
layout, while also organising them into appropriate columns relative to window size. We
subsequently ran into a greater problem with the page, which forced us to redesign it.
This was due to EJS's lack of support for dynamic client-side rendering, which meant
that the page body content could not dynamically alter based on the pet picked using
the ID cards. Before the database was connected, this was accomplished via JavaScript
functions. As a result, we had to alter the page to include a linear design with a tabular
structure.

14
Pet Tracker Page
During this section of programming, we faced several challenges, including ensuring
that the pet tracker tracks the device's location rather than simply pinning a random
location on the map. Tutorials assisted us in overcoming this obstacle, and we were
able to write the code that would provide the exact location of the device in real time.
Another challenge we faced was ensuring that the map is clear and large enough for the
user to navigate.

Booking Page
One of the things we struggled with when coding the Appointments page was creating a
clickable dropdown menu. This drop-down menu was required because it would have
been utilised to assist clients in navigating the website by prompting them to pick an
option for the queries that asked them what difficulty their pet was having.
The expected conclusion was to question the user: "What appears to be the issue with
your pet?" via a form, and then to click on the drop-down menu to show alternatives
such as "Eye difficulties," "Fleas," and "Vomiting," among many others.
Setting up the structure and styling/layout of the drop-down menu using HTML and CSS
wasn't difficult at first, but the issue emerged when we realised the drop-down menu
wasn't as functional as I wanted it to be. This was attributable to the following factors:
1.We only wanted the drop-down menu to appear if the user selected one of the options
from the drop-down menu.
2. If the user clicked outside of the "drop down menu parameter," I wanted the
dropdown menu to shut.
To solve both issues, I rapidly realised that JavaScript would be required to implement
my ideas. To solve problem number one, I used a JavaScript method to toggle between
concealing and exposing the content of the drop-down menu. This was accomplished
by renaming the element and setting the toggle to "display." This was a little trickier, but
it involved adding an if statement to the file that stated that if the "selection" arrow
detected that it was hovering around the drop down menu button, it would then enter the
next if statement, which stated that if it detected a click within the length of the drop
down menu button, it would show the options, and otherwise it would hide them. When
it came to creating the Date and Time selecting capabilities, a lot of thought went into
figuring out what JavaScript knowledge was necessary. This entailed a great deal of
study on sites like Udemy, YouTube, and Google. Understanding how to combine all the
parts to develop a working functionality for booking appointments was critical.

15
Technical Architecture

Software Architecture
The front-end of our software application will be displayed using HTML with its core
functionalities handled by JavaScript and CSS. We are also making use of Bootstrap,
an open-source JavaScript and CSS library and framework as it has many useful built-in
design features and functions that will aid and streamline our development process
enabling quick, responsive programming (Gaikwad et. al, 2019).
The reasons why we have decided to adopt this specific framework is speed of
development as it is one of the most significant advantages of adopting Bootstrap. It
also has a large support community behind it, so we were able to find assistance when
needed. Furthermore, Bootstrap is always being updated, and the designers have done
an excellent job in constantly releasing new versions and great updates.

The back end of our software application will be handled by Express and Node.JS,
since Node.JS Node.js is easily used as a server-side proxy, allowing it to manage a
huge number of simultaneous connections while being non-blocking. It's particularly
handy for proxying various services with varying response times or gathering data from
many sources (Tilkov et. al, 2010). Node.JS will assist handling our inputs and outputs
and any event driven server-side obstacles. We require Express’s ability to handle
requests as not every user will be requesting the same data.
We use Google Cloud SQL (appendix 2.11) for the database, a database service
managed and owned by Google Inc, and very versatile as all applications hosted on
Google Compute Engine, Google App Engine apps, and external applications and users
outside of the Google Cloud Platform can access MySQL databases stored on Cloud
SQL. Moreover, it is reliable, quick, and free (Krishnan et. al, 2015). We will be using a
simple MySQL database running on our server which will be displayed on the front-end
using EJS and Express. This will make the process of transmitting and storing data
much less troublesome.

The login system will function through an express session and cookies. Once the login
has been accepted the session begins. This means we can have differing sessions,
thus allowing multiple users to interact with the system simultaneously. There is a
routing system, created through express that handles the requests and results. Once
the user is logged in the web applications pages are rendered (App, Pet tracker and Pet
Passport). This in turn switches the login status to true. A false status redirects users to
the login page.

16
Users sign up by entering in an email, username, and password. A post method is then
used to grab these details and check for any potential matches against emails and
usernames already registered in the database to avoid any duplicate entries. If a match
is found the database handles the error by denying it and asking the user to try again.

Log In System
The express session, working mainly with “if” statements, employs cookies, and after
the login is approved, the session begins; this allows us to have many sessions if
multiple users use the system at the same time. We have created a routing system
using express to manage requests and outcomes; after the user is logged in, the three
pages (app, pet tracker, passport) are rendered, and the login status is changed to true.
We utilise a post method to sign up, which gets the user's email username and
password, then validates if the user exists by reviewing emails and eliminating duplicate
entries. If the email address already exists, the database handles the problem, refuses
the request, and redirects the user to the main sign-up page. Because our database is
remote, we can't utilise async functions because the latency between database
requests and server responses will cause it to crash. As a result, we employ promises
to inform the application to wait for a response before proceeding. If the email is new
(valid input from the user), the promise produces a result that creates a user by
inserting the data into the database and saving the email username and password. If
the data is invalid, we will reject it. We check for existing database entries with email
and passwords by establishing a promise that searches the database and returns true if
the user exists, then signs them in and establishes a logged in session. Also stores the
session email to the database's associated email, saving the session and any
modifications made by the user in his profile/session.

Pet Passport back-end

The back end of this page is quite simple and straight forward. We have our main page
which initially when a new user logs in it will be empty as they haven’t added any pets to

17
their account. This will display a table with empty fields. The function getPet pulls all
results based on the sessions email.

The object with the results gets passed in through the get method while loading the
page.

The results are then looped through and displayed in a bootstrap table which generates
based on the results.

18
This is the generated table from the code above:

The form below is used to add pets to the table by first requesting the information the
user put in from the body in a post function. After the required information has been
filled in the database function ‘createPet’ gets called.

19
This function works by creating a promise which sends back a resolve, or a reject based
on its success of the query. If we get a true, our query has been successful and the
information has been inserted and the user gets redirected to the pet passport page and
the response ends displaying a new pet on display in the table.

Errors:
If the user inputs a invalid input, the query will throw an error and return the user back to
the page. The error is then logged in the console with a status of 500 which is failed
query

Booking system back-end

20
The appointments back end is comparable to the pet passport in that it has a similar
structure and displays pet appointments using the same table structure. Similarly, this
information is generated by looping through the results returned by the getAppointmnets
method, which is a DB query within a promise that returns our information based on the
session email.

21
The results are similarly provided into an object, which is subsequently looped into the table.
Bootstrap made this process a lot easier by providing easily scalable table formats, and it saved
us a lot of time compared to designing our own.

Create Appointment

We use a similar structure to the pet passport to establish the appointment, with the exception
that we use a calendar to set the time and day, which has no influence on the back end and is
entirely design focused. Similarly, we request information from the body and record it in our
appointment book. We use comparable procedures for most back end jobs, and while they are
monotonous, they get the job done. It was a difficulty in and of itself to figure out how to make
these requests work and display our content

The information was stored in our SQL database table which looks like this.

Pet tracker system back-end

Google API maps can be used for multiple purposes such as pinpointing a location,
calculating distance between two points etc. However, in our case we are using it to
calculate the current geo location of the user's pet so they can track them. To
Implement google maps API you need to access google developers (appendix 2.1) and
access the java code which allows you to use Google Maps on your HTML code.
Afterwards for your map to work you need to access Google Maps platform to generate
a specific API key Which will allow you access to Google Maps. The tracking page has
been made amazingly simple for the user so they can easily understand how to use it.

22
They must enter the microchip number of their pet into the search bar and that will help
them to track their pets in real time. To track the user’s location most of the help was
taken from this video on YouTube (appendix 2.2). This tutorial was straight forward and
helped us understand how to use tracking on Google maps and without any issues we
were able to implement this code into our HTML and got the tracking function working.

23
Design

Overview
We created low, medium, and high-resolution wireframes throughout the initial phase of
the project. We tweaked the look of the pages after some revisions and consultation
with designers. We also veered off course to create a single online application with
extremely responsive behaviour that could be used on both PCs, tablets, and
smartphones.
We began by building a website mind map with Miro to help the development team
understand how the pages will be connected logically and graphically.

Website Mind Map (Appendix 2.7)

Users will first arrive at the homepage, where they will find the three main features of
the web application (pet tracker, appointment scheduling, and pet passport), as well as
the ability to log in or register, as well as a help page with information about ourselves

24
and some frequently asked questions. Each page inside the home page, the
login/register area, and the about part is connected to make it easy to travel back and
forth.
The entire website was built with the goal of being as accessible and responsive as
feasible. For accessibility, we employed semantic tags, metadata and alt images across
the html template that was used by all pages (Gardner, 2011). Another important
consideration was responsiveness, therefore we used bootstrap and rem measures in
the external CSS code for pictures and boxes (ibid). After conducting research and
testing the pages with colour blind potential users, the colour palette and fonts were
chosen (Karreman et. al, 2007). Since the beginning, accessibility and responsiveness
have been top concerns. Let's now delve into each scenario's individual pages.

Home page Responsiveness

25
 Pet passport page responsiveness

User Guide
A user guide would be a useful tool for assisting potential users in learning how to
navigate and get the most out of our online platform. To make it accessible and easy to
use, it is designed to be user-friendly and aimed at non-technical users.
To enable faultless navigation and user engagement, we simply upload images of the
front-end interface and define what the actions are.

Home Page

26
We chose a homepage that is small, basic, and appealing. The major goal is to avoid
overwhelming users when they first visit our website. The homepage has a logo in the
header, a login-register area in the header, and a link to the about page in the footer.
When browsing the website, the footer and header will always be constant, allowing the
visitor to go back and forth easily and logically.

Log-In & Sign-Up Page

27
The login and sign-up page are just the page where a user can register for the system
or log in. Users will log in or create an account by entering their email address and
creating a password. If the back end of the system allows it then the user will be able to
access the 3 main pages of the website (booking, tracking, passport). The page has a
simple interface where the user inputs his information or is asked to sign up.

Pet Tracker

Only accessible if the user is logged in. Using Google Maps API, this page will allow
users to track and monitor their pet's whereabouts in real time. The user interface
consists of a map with a location bullet for the user's pet. There isn't much you can do in
terms of designing the map itself as it is straight forward. The map is the centre of the
page and to track their pets’ users must enter the microchip number into the search bar
located below to map and they can start tracking their pets. The page is designed this
way so the users do not get confused and can start the tracking process as soon as
possible.

28
Pet Passport

29
On the pet passport page, the user would be able to input the pet’s details, save them
and store the information in his account. On the first picture below, we can see the first
layout where the user can see the registered pet, add more, edit, or remove.

30
Only accessible if the user is logged in. There are not as many resources for designing
a pet profiles page, however some elements from user’s profile pages can be used as
inspiration. The researched website shows some basics of designing a user profile
page, including data that should be displayed to the user (e.g. a profile picture and basic
information) as well as provides some layout ideas and the AgenteStudio (appendix
2.25) website has also provided useful information on what user profiles should include,
which are directly transferable to the pet profile context. Resources found on Inoxoft
(appendix 2.24), for example, it has enforced the need for intuitive navigation – which
can apply to toggling between different pets saved under the user’s account. To
accommodate for this, our initial prototyping idea of having a small dropdown of pets in
the corner of the page (used to display different pet profiles depending on selection),
might not be the most intuitive for some users. We have therefore decided to
incorporate a larger, more clear selection section, with id-looking cards for each pet.
The article also refers to screen-size. This has also been taken into consideration when
designing the pet passport page, making sure that information is clearly visible after
resizing the window.

Booking Page

Booking page shows a simple form where the user can add all his details and submit his
booking. It is only accessible if the user is logged in. This page will enable users to book
appointments with their vet, scheduling slots through the calendar interface and save
them in their account.

31
About Page

Appendix 2.3

The about section will tell users about our personal experiences, backgrounds, mission,
and vision for SimplyPet. An about us page may be made in a variety of ways.
However, we wanted to create one that was more appealing to the eye, thus the about
us page has a design that is comparable to the homepage. We added a section called
Meet the Team to that website, where you can see five cards of each individual team
member and what projects they've worked on, as well as their social media profiles, so if
a user wants to contact one of us, he should have no trouble doing so.

32
Contact Us Page

Appendix 2.4

A contact Us page will allow users to get in touch with us.

Users may fill out a simple form with their name, email address, and a message for the
staff. Will also provide a phone number for customer service and an email address in
case they wish to contact us directly. The user will receive an automated email verifying
that we have received their inquiry and that we will contact them within 48 hours.

33
End-Product Testing
E2E testing is required to assess the product's overall performance empirically (Tsai et.
al, 2001). We went through each step of the web application in order, from inputting the
URL to logging out and exiting, to properly conduct end-product testing.
We sought to maximise our outcomes given the available time because end-product
testing is undoubtedly one of the most time-consuming phases in a product deployment.
Integration testing has always been difficult, especially when the system under test is
complex and includes multiple subsystems and interfaces (ibid), and even though our
web application is not that sophisticated, it took a lot of hard work to come up with
significant results to fully approve and be accepted.

Prioritised for the end user and maintaining the order of the applications the steps taken
were:
1. Home Page as a guest
2. Sign In
2.1 add details, log in
2.2 forgot password and retrieve password
3. Sign up
3.1 add details
3.2 confirm email
4. Booking page
3.1 add appointment - select date and time
3.2 edit appointment - select date and time
3.3 select appointment
3.4 cancel appointment
5. Pet passport
4.1 add pet
4.2 edit pet
4.3 remove pet
4.4 share pet passport
6. Pet Tracker
5.1 register device
5.2 enable location service
5.3 share pet location
7. Contact Us
6.1 fill up the form and send enquiry
8. About us
7.1 view team member social media account and details

34
 9. Log out and close the system.

UI + Usability evaluation
This form of testing will be exploring and evaluating any part of the software that the
users have the capability to interact with. For any computer application to perform
successfully, it must be able to facilitate the necessary tools for the task at hand in such
a way that enables the users to utilise them efficiently (Dillon, n.d.). We will be testing all
the visual elements of our software application to evaluate whether they meet the
expected requirements for performance and functionality. With regards to said user
interface, one must consider the way in which users will consider certain behaviours,
which design features will draw their attention and the level of knowledge they will
require to respond to software stimulus in a correct and timely manner (ibid).

A high performing user interface must allow users to quickly and accurately absorb
visual stimuli presented to them by the software (Marcus et. al, 1991). Current design
guidance recommends the use of strong image polarity to provide a contrast between
varying elements of the user interface. Users are often resistant to software instruction
tutorials and tend to interact with the software regardless of their prior knowledge.
Instead of looking towards the removal of erroneous performance, the software should
focus on informative and efficient feedback, paired with the ability to undo mistakes to
aid and cushion users through the learning process (ibid) i.e. placing an importance on
the learnability and memorability of our software application.

We will be evaluating several factors regarding our user interface. Navigational

elements will be checked for functionality and accuracy. Data type errors will also be
checked, to ensure that only valid data can be entered by the user e.g., numbers for
dates and ages. Confirm action buttons will be checked to ensure the users receive
confirmation every time they input data, save, or generally interact with the software.
Menu items will be evaluated too, to ensure the software application only displays the
correct menu items when in specific states of use. We will also be testing end-to-end
elements specific to our Software application, such as the process of creating a ‘pet
passport’ (Creating and adding details for a user's pet) and the communication channels
between users and their vets.

Testing methods
We will be performing several testing methods to ensure the validity, reliability, and
performance of our UI design. Taking inspiration from traditional usability studies
(Dôgan et. al, 2014), we will be identifying any problems in the design fundamentals of
our software which will subsequently reveal opportunities for us to refine and improve

35
our user interface. We will also gain insightful knowledge into our target user bases’
behaviour and preferences when interacting with our product. This will also test the
learnability and memorability of our user interface (Li et. al, 2014).

Due to limited accessibility to advanced automated testing software, the testing type we
will undergo will be manual UI testing. Our manual testing will involve numerous
participants of varying backgrounds performing different tasks and operations on the
software application such as inputting data and viewing relevant information. One of our
team members will act as the designated facilitator as they will have extensive
knowledge of our software’s user interface. They will guide the participants through the
testing process. The participants will be users who would find relevance using our
product; promoting a realistic representation of the service being studied. Ten
participants from varying demographic and psychographic backgrounds that could be
seen as realistic potential users of our software application were recruited to undergo
this study. The aspect of our user interface performance to be tested was efficiency
(backed against the expected performance in our non-functional requirements) which
was recorded with time to complete a task as the single metric.

Results
Users were instructed to complete the following tasks in order (see tabs below):

1. Create a user account

2. Login using their username and password
3. Log out of their account
4. Change / Retrieve Password

Navigation from the landing Page:

5. Navigate to Pet Passport Page

6. Navigate to the Appointments Page

7. Navigate to Pet Tracker Page

8. Navigate into About Us

9. Navigate to Contact us Page

End to End from the Landing Page

10. Create Pet Passport

11. View Pet Passport

36
 12. Schedule Appointment

13. View Appointment

The results are displayed in an Excel (appendix 2.23) spreadsheet below (1) listing the
users and their recorded times for each task they completed. The users are listed in
rows from numbers 1-10 and the tasks they have completed are listed in columns from
1 to 13, following the order listed above. Being able to analyse and collect users’
performance data when completing certain tasks is a fundamental part of usability
testing. (Sharp et. al, 2015) Evaluating the average time from the users completing
tasks can verify that users are able to complete the required tasks in an acceptable
manner in accordance to our expected outputs outlined in our non-functional
requirements. All the users were able to complete the tasks required of them. It is noted
that improvements could be made to the visibility of the log-in and signup buttons as
whilst the times fell into an exceptional range per our expected outputs, they performed
worse than the other tasks in comparison. There were no exceptional outliers noted.

37
 (1) Excel spreadsheet listing the users and their recorded times for each task they completed.

UX Evaluation
The UX or user experience encountered when a user interacts with a product can be
described as “all aspects of the end-user's interaction with the company, its services,
and its products.” (Nielsen et. al, 2014) It goes beyond a user's performance when
interacting with a product, but their impression and feelings towards the product; the
quality of the experience they had. One cannot design a user experience, but simply
design with a positive user experience in mind (op cit). The experience must instil a
sense of value towards the product in the user, as well as a sense of trust. Reaching
further, one should also consider users' design influenced presumptions and
expectations that can affect their experience when interacting with a product. (McCarthy
et. al, 2004) When performing our UX evaluation, we must determine all points of
contact between the user and the product. This includes the interaction with the web
application itself, any subsequent manuals and documentation that accompany the
software and its ‘in the field’ usage, e.g., tracking one’s pet or displaying the pet
passport to your local vet. The product's accessibility must also be considered.

Testing methods
When evaluating the UX when interacting with the web application, we will use ‘think
aloud’ testing. Think aloud testing encourages users to verbalise their thoughts and
feelings when interacting and moving through the interface. (Nielsen, 2010) This is a
flexible testing model that will provide us with a lot of qualitative feedback directly from
users. We can also use this testing method throughout multiple stages of the
development lifecycle - utilising different users each time - suitable as we are utilising an
agile framework. Five participants were instructed to navigate and interact with the web
application freely as to position them into a more natural situation when conducting this
study, though were encouraged to explore all the pages on the site. During this, they
were encouraged to voice their thoughts and opinions out loud. They are then asked to
summarise their overall experience at intervals (between sections) with ratings “very
negative”, “negative”, “neutral”, “positive” and “very positive”.

Results
The results are divided between the five main pages: Home, Pet Passport, Pet Tracker,
Appointments and Contact us. The data is summarised into bar graphs and any
statements or queries worth noting during the study are recorded below:

38
Home Page Analysis

Notable Thoughts
● “Good use of a landing header, clear and concise, I know what the website is
about from the get-go”
● “Colour contrasts aren’t that visually appealing, with the blue and purple clash”
● “Logo doesn’t sit very well against the purple”
● “Good Contrast for the menu bar bit, the white against purple is easy to read”
● “I like how I can scroll down and there are other bits of information available [...] I
don’t have to click off the home screen instantly”

39
Pet Passport Page Analysis

Notable Thoughts

● “There could be more spacing between the border and the current appointments
bit”
● “The background could be a more appealing colour and have some gradient to it”
● “I like the green and red for vaccinated or not vaccinated”
● “It's easy to read but feels like it could be positioned a bit better”
● “The paw print background when you click on a pet is a bit 90’s”

40
Pet Tracker Page Analysis

Notable Thoughts

● “Still not a fan of the paw print background”

● “It’s not very clear how you would use this to track a pet”
● “What is entered in the search area?”
● “I think some borders around the map specifically could make it look a bit nicer”

41
Appointments Page Analysis

Notable Thoughts

● “The calendar looks really clean and modern”

● “The spacing between items is done better on this page”
● “It’s easy to understand”
● “I’m not a fan of there being a second header [...] in that style”

42
Contact Us Page Analysis

Notable Thoughts

● “The form looks really professional”

● “The contact us bit could be placed a bit higher up and the customer service title
placed a bit lower down”
● “Again, simple and nice”
● “The placement of the items on the screen could be readjusted”

Conclusion
Analysing the key points made by our user testing it is clear to see a common theme
amongst some of our design specifications. Users were not particularly fond of the paw
print background as it did not align with their views of a modern looking website and
preferred the pages where it was replaced with a clear opaque background. They also
felt some of the padding around particular objects on pages could be improved to
remove cramping. This was particularly noted on the forms and pet passports. They felt
(with exception to the geo tracker) that it was a friendly looking and easy to understand

43
website but some of the colour combinations weren’t easy on the eye as they clashed,
such as the purple and blue; they preferred the higher polarity combinations such as the
white text blue background navigation bar on the home screen. There was only one
incident of neutral feelings towards a page (the geo tracker) and the primary feelings
and thoughts expressed towards the pages and website were overarchingly positive,
coupled with a few neutral responses, primarily catering to easily remedied problems
such as the backgrounds and object padding. The consensus by our testers has shown
that whilst there are areas for improvement, our web application meets user experience
performance needs outlined in our non-functional requirements and initial research prior
to the results.

Functionality Evaluation
Functionality testing, although underestimated for a long time in project management
(Lech, 2013), will allow us to test and evaluate whether all parts of the system are
working as intended. We will be validating our specific functions of our software
application by providing appropriate inputs and validating the outputs against the
expected results outlined in our functional requirements. We will cover all the main
functions in our testing such as creating / logging into accounts, creating / viewing pet
passports, using the geolocation feature and scheduling appointments in the calendar.
These tests will be performed in all the main web browsers identified as being used in
our market research: Safari (appendix 2.17), Google Chrome (appendix 2.18) and
Firefox (appendix 2.19). This is to ensure maximum accessibility to our market users
(Saar et. al, 2014).

Error handling
We will also be testing the software’s error handling. This is to ensure the system can
deal with any sort of errors under any circumstances that may occur during use
(Weimer et. al, 2004). We will be using the standard testing protocol when doing error
handling evaluation which goes as follows:

Test driven development and unit testing

Unit testing relates to the practice of validating small and specific portions of code
(Garousi et. al, 2013). The test is coded in an automated process where the data is
passed through the code and evaluates whether the output matches the expected
result. We have utilised the software practice known as test driven development. This is
an approach where unit tests are written before the code is implemented. Unit testing
cases using minimal code that perform the primary function of the area are created then
tested. The test is then run, and any necessary refactoring is subsequently completed.
This moderate increase in development effort greatly reduces the error rate in our

44
coding process. The tests are small in scope and are run frequently to minimise
backtracking to resolve errors. Our test-driven development process is outlined below:

1. Setting up the testing environment

2. Generating cases for the test
3. Executing the test cases
4. Results and analysis / refactoring
5. Re-testing

The test environment is set up in accordance with the test being run. Significant data
such as user login details will be stored elsewhere to ensure no losses if a crash occurs.
We will be generating different cases that may result and provoke errors in our software,
such as entering incorrect data types when filling out the Pet Passport. We will then
analyse the results and compare them to the expected results detailed in our functional
requirements. If the tests fail, the code is refactored, and the process is repeated until
the expected outputs are met.

45
Evaluation Plan

User evaluation involving representative stakeholders

We acquired enough data from our initial research into stakeholders' requirements and
expectations to completely comprehend the aims and goals we were striving for as we
moved into the development process.
Initially, several stages of the apps were tested and presented to gather feedback and
repeat based on it and comparing the initial MVP to the final one provided us a clear
idea of the requirements we needed to set and keep throughout the development
period.

With image below taken from the first report, we can observe who the stakeholders for
SimplyPet are:

Stakeholder diagram

We focused our summative stakeholder evaluation only on the first 3 circles in the
following order:

46
1. Pet owners
They considered the app to be incredibly useful and usable, and based on our testing,
they were all able to effectively run our app and were excited to see a genuine version
hit the market soon.
In terms of earning points, the function of storing pet records was the most popular, and
it was deemed extremely essential to them since the challenge to keep records in order
and on track even while working remotely is a real user requirement.
The booking system has also been quite successful, however they noted that because
the programme is still in its early stages, the few functions may make it more difficult
than just calling the veterinary services.
Pet trackers have also been viewed favourably, albeit it may be claimed that because
most pets nowadays are not connected to any GPS device, the function may be
rendered worthless for many.

2. Veterinary Practices
Although veterinary offices were not as active in the process as pet owners, they played
an important part in the MVP draft, because one of SimplyPet's primary features is the
ability to arrange an appointment with them.
The veterinarians questioned all expressed reservations about the booking system's
practicality, believing that we would not be able to maintain a clear and error-free
system. Overbooking and malfunctions were the two major factors that caused us to
consider how critical it would be to incorporate a fully working and tested environment to
prevent causing more harm than good. SimplyPet's long-term goal is to make pet
owners' and veterinarians' life simpler by enabling them to be less engaged in the
booking system. For now, we've kept the functionality simple, and with more time, we'll
grow it into a more complex booking system (see future work description). Our
functionality appealed to small practices with little resources, making it potentially
beneficial in terms of recruiting new customers and, as a result, extra bookings. Big
practises with an online ecosystem thought this would just be another platform for them,
but small practices with fewer resources found our feature very appealing and
potentially remunerative for acquiring future customers and thus more bookings.

3. Developers
The developers' judgement has been challenging since they are biased towards the
entire process because they developed it. Despite the positive and inspiring comments,
they recognise the need of maintaining and producing high-quality work to ensure
SimplyPet's success and survival against prospective competitors soon. Taking a new
perspective on the project, they are confident in their ability to deliver and excited to
take SimplyPet to the next level in terms of UX, back end, and design.

47
4. Sponsors
Sponsors are going to be critical to SimplyPet's long-term survival and development.
We attempted to interview a few potential angel investors and gathered some helpful
feedback that would help them develop and enter this enterprise with ease.
The sponsors' major aim was to be able to follow and foresee an exit plan, and they
wanted to know how we might help them with that.
Their idea was to include veterinary offices in the marketing phase, encouraging them to
promote our platform and to join a partnership programme in which each veterinarian
practise would pay us a fee for each reservation made through our platform.
Another tip they provided us was to include pet service advertisements and partners in
the region. This would enhance income and allow us to establish a network of pet
services in one location, benefiting many small companies in the area.

Evaluation
To assess our project management, we all got together and spoke about what went well
and what didn't, as well as what we would do differently, how, and why if we had to do it
all over again.
One of the things we agreed on was that, after seeing how successfully the second
phase of the project went, separating the team into smaller groups could have been a
good idea in the first portion as well, as we found it to be quite beneficial and efficient.
In terms of development, it was tough to communicate with one another when things
were past due but owing to strong soft skills and straightforward and open
communication, we were able to talk about it and appreciate how important this project
was to all of us, expressing our own goals and objectives. This significantly increased
the level of effort and time each of us invested in the project, allowing us to make
significant progress in a short period of time.

Another observation is that the pet tracking system we have devised thus far may not
be sufficiently robust to please our consumers; for example, certain pets may not have a
GPS device, and the microchip may not be compatible with the GPS network. Overall, it
could have been preferable to focus more on the scheduling and pet passport functions,
but we did manage to construct a working website that locates pet owners and can
successfully locate the pet by inputting the GPS device code.

Future Work
Although this project taught us how difficult it is to make things function, even if they are
few and simple, there are things we would like to work on and develop in the future.

48
One of the first goals would be to create an ever-growing database of veterinary clinics
that would allow users to evaluate and review them, as well as filter them based on
ratings, price, and location.
Even though the pet location feature is currently quite limited, it could be expanded to
allow users to not only locate their pets but also set alerts for when their pet's distance
from the set location or the user's location exceeds a certain threshold (e.g., when the
pet is 2+ miles from the set location or the user's location).

The booking system would also be improved, allowing you to send reminders and
automatically construct email/SMS as reminders or booking confirmations in conjunction
with calendar events in Google and Apple calendars. In addition, Maps APIs will be
used to direct you to the practice at the time of your appointment.
Additionally, we would have added a function to the calendar that shows which dates
are already booked by other patients, so that the calendar only shows the dates with
available appointments. I believe this would have been beneficial, allowing the system
to spread appointments out across several days or weeks, avoiding a potential overflow
of users at the same time. This approach may have been used not just with dates, but
also with available times within a single day.
Finally, we would have included a function that allowed users to upload material, such
as photos or videos, of their pets to demonstrate their issues or concerns.

Pet passports, which are now only available to users/veterinary practises, might be
expanded further to become an official document that can be downloaded in digital
format and used to travel abroad, share with insurance companies, and so on.

Simply Pets survival and future growth will also depend on having a sound monetisation
plan in place. Pet services providers, such as pet stores and pet sitters, social pet
friendly events, and a blog/forum where users can express their opinions or experiences
with their animals are just some of the concepts that might be incorporated at a later
stage.
In terms of usability and accessibility, improving the overall design, and creating a
mobile application for both Android (appendix 2.20) and iOS (appendix 2.21) would be
an essential step, allowing consumers to access the services at any time and from any
location.

49
Ethical Audit
When it comes to our web-based application, there are several factors to consider
maintaining the greatest levels of ethics and privacy.
Beginning with the premise that everyone should be able to utilise web apps, the
system has been developed on a foundation of continual development, with accessibility
at the forefront. Conducting usability, accessibility, and responsiveness testing with real-
world users aided us in the process of ensuring the application was usable, accessible,
and responsive.
We also believe in sharing information and assisting other developers working on
similar projects, which is why the project will be open source and available through
websites like GitHub and GitLab (appendix 2.22).

On the other hand, there is a backend system for a website, there are plenty of things to
consider. Security and data privacy are most likely the most crucial aspects to protect to
provide a seamless user experience and peace of mind (McConnell, 2004). Because
our system requires the usage of cookies, it is critical that we guarantee that the data is
secure and that it is not shared with third parties unless absolutely required, as this may
easily endanger the user's privacy. (Zimmerman, 2000).
Given that we are utilising a third-party API, it may be worthwhile to investigate several
choices and select the safest and most stringent in terms of data privacy protection
(Doty et. al, 2010). The location of their pets, as well as any other sensitive private
information they reveal about themselves and their pets (email, password, address,
etc.) shall be kept completely confidential and not shared with third parties unless the
user chooses to do so. Maintaining a strong security protocol and making sure we're
taking appropriate precautions to keep people and their data safe (Bélanger et. al,
2011).

To achieve those security standards, the measures we have put in place are:
- Unauthorised access is not permitted to the database where the user credentials
are kept.
- The application only accepts one set of credentials at a time (no duplicate user
IDs or emails).
- At no time is the password visible in any section of the programme.

50
Conclusion

SimplyPet cleared the path for a significant shift in how pet owners maintain track of
their animals and manage their interactions with veterinarians.
We expect that more and more individuals will require such an app for their everyday
needs relating to their dogs, as evidenced by the extensive study undertaken prior to
development and the testing and research conducted after the prototype was created.
Because mobile and online apps are here to stay, we must ensure that usability and
user experience only serve to support and ease the user's wants and objectives.
Today's technology has made information more accessible than ever before, which is
why we believe SimplyPet will considerably reduce the need for users to maintain their
pet data organised and visible in the case of a vacation, a medical appointment, or a pet
loss. Veterinary clinics sometimes lack the infrastructure needed to support larger-scale
bookings, which we feel might be an asset for monetisation in the future.

This group project experience has taught us a lot about teamwork and software
development but also about pet’s management and user needs. Therefore, if we had
more time and resources, we would absolutely invest more into the development of
Simply Pet and make it a reality rather than a university project.
Simply pet offers the groundwork for an engaging and useful tool for pet owners and
veterinary practices, with a wealth of possibilities and opportunities.

51
Bibliography
Bélanger, F. and Crossler, R.E., 2011. Privacy in the digital age: a review of information
privacy research in information systems. MIS quarterly, pp.1017-1041.

Bourdieu, P. (1986). The forms of capital. In: Richardson, J., Handbook of Theory and
Research for the Sociology of Education.

Blank, S., 2013. Why the Lean Start-Up Changes Everything. the Magazine, May.

Dillon, A., n.d. User Interface Design Introductory Article. User Interface Design, [online]
Available at: <https://www.researchgate.net/profile/Andrew-Dillon-5/publication/
227998407_User_Interface_Design/links/5c75aaa692851c695043accc/User-Interface-
Design.pdf> [Accessed 14 February 2022].

Doğan, S., Betin-Can, A. and Garousi, V., 2014. Web application testing: A systematic
literature review. Journal of Systems and Software, 91, pp.174-201.

Doty, N., Mulligan, D.K. and Wilde, E., 2010. Privacy issues of the W3C Geolocation
API. arXiv preprint arXiv:1003.1775.

Duc, A. N. & Abrahamsson, P., 2016. Minimum Viable Product or Multiple Facet
Product? The Role of MVP in Software Startups. Agile Processes, in Software
Engineering, and Extreme Programming, Volume 251.

Gaikwad, SURAJ SHAHU, and P. R. A. T. I. B. H. A. Adkar. "A review paper on

bootstrap framework." IRE Journals 2.10 (2019).

Gardner, Brett S. "Responsive web design: Enriching the user experience." Sigma
Journal: Inside the Digital Ecosystem 11.1 (2011): 13-19.

Garousi, V., Mesbah, A., Betin-Can, A. and Mirshokraie, S., 2013. A systematic
mapping study of web application testing. Information and Software Technology, 55(8),
pp.1374-1396.

Kumar, P.P., 2005. Effective use of Gantt chart for managing large scale projects. Cost
engineering, 47(7), p.14.

52
Lech, P., 2013. Time, budget, and functionality?—IT project success criteria revised.
Information Systems Management, 30(3), pp.263-275.

Li, Y.F., Das, P.K. and Dowe, D.L., 2014. Two decades of Web application testing—A
survey of recent advances. Information Systems, 43, pp.20-54.

Marcus, A. and Van Dam, A., 1991. User-interface developments for the nineties.
Computer, 24(9), pp.49-57.

Miara, Richard J.; Musselman, Joyce A.; Navarro, Juan A. & Shneiderman, Ben
(November 1983). "Program Indentation and Comprehensibility" (PDF).
Communications of the ACM. 26 (11): 861–867. doi:10.1145/182.358437. S2CID
11767796. Retrieved 3 March 2022.

Mccarthy, J. & Wright, Peter. (2004). Technology as Experience. [online] Available at: <
https://www.researchgate.net/publication/224927635_Technology_as_Experience>
[Accessed 22 February 2022].

McConnell, Steve (2004). Code Complete: A practical handbook of software

construction. Redmond, WA: Microsoft Press.

Moin Shaikh, F., Sabir, S. and Abbas, D., n.d. An Optimised Approach for Graphical
User Interface Testing. [online] Islamabad. Available at:
<https://www.researchgate.net/profile/Shaista-Sabir-3/publication/
318531643_AN_OPTIMIZED_APPROACH_FOR_GRAPHICAL_USER_INTERFACE_T
ESTING/links/596f5334aca27227101361f0/AN-OPTIMIZED-APPROACH-FOR-
GRAPHICAL-USER-INTERFACE-TESTING.pdf> [Accessed 14 February 2022].

Moogk, Dobrila Rancic. "Minimum viable product and the importance of experimentation
in technology startups." Technology Innovation Management Review 2.3 (2012).

Nielsen, J., 1993. Response Time Limits: Article by Jakob Nielsen. [online] Nielsen
Norman Group. Available at: <https://www.nngroup.com/articles/response-times-3-
important-limits/> [Accessed 15 March 2022].

Nielsen, J., 2010. Usability engineering. Amsterdam: Morgan Kaufmann.

Karreman, Joyce, Thea Van Der Geest, and Esmee Buursink. "Accessible website
content guidelines for users with intellectual disabilities." Journal of applied research in
intellectual disabilities 20.6 (2007): 510-518.

53
Krishnan, S.P.T. and Gonzalez, J.L.U., 2015. Google Cloud SQL. In Building Your Next
Big Thing with Google Cloud Platform (pp. 159-183). Apress, Berkeley, CA.

Perfecto by Perforce. 2022. UI Testing: A Comprehensive Guide | by Perforce. [online]

Available at: <https://www.perfecto.io/blog/ui-testing-comprehensive-guide> [Accessed
14 February 2022].

Porter, M. E., 1989. How Competitive Forces Shape Strategy. Readings in Strategic
Management..
Ries, E., 2011. The lean startup: How today's entrepreneurs use continuous innovation
to create radically successful businesses. S.l.:s.n.

Rugman, Alan M., and Joseph R. D'cruz. "The" double diamond" model of international
competitiveness: The Canadian experience." MIR: Management International Review
(1993): 17-39.

Saar, T., Dumas, M., Kaljuve, M. and Semenenko, N., 2014, July. Cross-browser testing
in browserbite. In International Conference on Web Engineering (pp. 503-506).
Springer, Cham.

Sabbaghi, A. & Vaidyanathan, G., 2004. SWOT Analysis and Theory of Constraint in
Information Technology Projects. Information Systems Education Journal, 13
April.2(23).

Sharp, H., Preece, J. and Rogers, Y., 2015. Interaction design: Beyond Human-
Computer Interaction. 4th ed. [online] Available at
<http://prof.mau.ac.ir/images/Uploaded_files/Jenny%20Preece,%20Helen%20Sharp,
%20Yvonne%20Rogers-Interaction%20Design_%20Beyond%20Human-Computer
%20Interaction-Wiley%20(2015)[369707].PDF> [Accessed 22 February 2022].

Tilkov, S. and Vinoski, S., 2010. Node. js: Using JavaScript to build high-performance
network programs. IEEE Internet Computing, 14(6), pp.80-83.

W. T. Tsai, Xiaoying Bai, R. Paul, Weiguang Shao and V. Agarwal, "End-to-end

integration testing design," 25th Annual International Computer Software and
Applications Conference. COMPSAC 2001, 2001, pp. 166-171, doi:
10.1109/CMPSAC.2001.960613.

Webaim.org. 2022. WebAIM: Contrast Checker. [online] Available at:

<https://webaim.org/resources/contrastchecker/> [Accessed 18 February 2022].

54
Weimer, W. and Necula, G.C., 2004, October. Finding and preventing run-time error
handling mistakes. In Proceedings of the 19th annua

Wixon, D. and Wilson, C., 1997. The usability engineering framework for product design
and evaluation. 2nd ed. Amsterdam. [Accessed 22 February 2022].

ZIMMERMAN, Rachel K. The way the cookies crumble: internet privacy and data
protection in the twenty-first century. NYUJ Legis. & Pub. Pol'y, 2000, 4: 439.

55
 Appendices

1) Meeting Log
Date Place & Summary
Attendance

Wednesday Team Meeting We got together to discuss and evaluate the first assignment mark,
19/01/22 09:00 - 10:00 we read through the feedback and worked out what the expectation
(GMT) is for this next chapter. We allocated 2 meetings a week for this
All present second assignment Wednesday morning and Monday am.

Monday Team Meeting Walked through the rubric for the assignment and listed a to-do list
24/01/22 11:00 - 12:30 of things to run through. Set up new slots on Trello for project
(GMT) management and defined and created a new report structure.
All present

Wednesday Team Meeting Discussed software developments steps and stilled the next steps:
26/01/22 09:00 - 10:00 set up a coworking development environment so we can all
Zofia, Ed, Fil. contribute and have access. Created a new Trello board for the
second part of the assignment. First, look at reactJS. Drafted
technical questions to ask Sean on Thursday’s lecture.
We will use Visual Studio as IDE, Fil will set up a GitHub, and
introduce the environment to the group to make it evenly accessible
and fully collaborative. The aim is to have a headings structure for
the report done in the next meeting on Monday 31st.

Monday Team Meeting Explained to everyone how we are going to work on GitHub, set up a
31/01/22 12:00 - 13:00 terminal command to save and change code. We will pull requests
Zofia, Ed, Fi, Seb. each time we want to commit a change and someone else from the
group will have to approve. By doing so we will keep track of all
versions and be able to collaborate efficiently. Considering the idea
of only focusing on mobile or web apps instead of doing both.
Wednesday we will define the report structure and headings and
start coding.

Wednesday Team Meeting Ed worked on the headings and table of contents, finished the first
02/02/22 9:00 - 10:00 draft, and finished setting up git with Fil for the collaborative code
Seb, Fil, Ed, environment. Zofia will organise the report heading on the report as
Zofia. she did very well on part 1, Fil sorted the git issues we were having
and set it up properly for all. Seb started making research on what
testing might be more efficient for our software. We will meet
Saturday to start coding and assign specific coding tasks to each of
us.

56
Saturday Team Meeting Fixed an issue preventing Ed from effectively uploading and
05/02/22 11:00 - 12:00 committing changes on git. We went through the same thing with
Ed, Omar, Fil. Omar and set git properly with the right SSH keys.
We started basic coding for the html index and routing.

Wednesday Team Meeting Discussed and evaluated Sean's feedback from Tuesday 8th lecture.
09/02/22 09:00 - 10:00 Riann, Oma, Fil, Zofia: Dev side - tasks will be split in further
Ed, Omar, Zofia, meetings, where more specific roles will be determined within this
Seb, Riann, Filip. group. General run through of what will need to be done has been
discussed during the meeting. This includes re-evaluating what
information will need to be stored and how on the database, as well
as discussing basic formatting we will use across the web app. Filip
will draft the first page of the web app, which will be used to
consistently format the rest of the project.
Seb - Ed: Report (as business focus programs), testing, evaluation,
etc. work alongside and with the development side group to keep
iterating and pivoting what does and doesn't work.
Set up a meeting in person for next Tuesday in the library to cover
up Sean's feedback and have the chance to reiterate it at next
Thursday's lecture.

Saturday Team Meeting Went through the first home page, started testing on the home page
12/02/2022 11:00 - 12:00 and collected feedback.
Ed, Seb, Zofia, Monday Seb and Ed will start to finish structuring the final version of
Riann, Filip, the report and start filling in some sections.
Omar. Zofia will implement the Gantt chart with this phase goals and
timelines.
Web site pages are split in the following order: Zofia, Pet Passport;
Riann, Appointments Page; Omar, Pet location page.
We access the initial and header and footer in all the pages, and the
CSS as a guideline for the whole website.
We decided to do a mind map for the website as a clear guideline.

Monday In Person Meeting Finalised the report structure with headers and sub headers, started
14/02/2022 14:00 - 15:00 collecting data and resources for the final report specifically for the
Ed, Seb user testing.
Collected references and data about the first testing of the initial
wireframe done for the web-based app.
Drafted a few questions about the report for Sean’s lecture
tomorrow Tuesday 15th.

Tuesday Hybrid Met with Sean to show what we have done so far, collected feedback
15/02/2022 11:30 - 15:30 and re iterated over the points that need adjusting.
Ed, Seb, Zofia,
Omar, Riann

Saturday Team Meeting Seb Told us the things he has started working on alongside Ed.
19/02/2022 11:00 - 11:30 Riann, Zofia and Omar caught up with each other and we concluded
Riann, Zofia, Seb, that everything will be done by Tuesday 22nd, Zofia will finish her
Omar Pet passport page, Omar will apply Google maps onto his page, and
Riann will take care of the appointments page.

57
Tuesday Team Meeting Final report work, worked on the introduction, software architecture,
22/02/22 13:30 - 16:30 Project management section; created a GIF to display the phases
Ed, Seb regarding pulling requests and committing changes on git-hub.

Saturday Team Meeting Revised the software architecture in the report (Using google cloud
26/02/22 11:00-11:30 for databases, not using React.JS.)
Filip, Seb, Omar, Updated the references list
Riann Explored more testing techniques to be implemented for when the
MVP is available (Eye tracking / heat mapping UI + Automated UI
colour polarity testing)
Set due date for finalising MVP (next Saturday)
Discussed Login/Verification architecture for the web-application +
Plus how unique ID user pages will be displayed.

Wednesday Team Meeting Development team meeting, Fil showed the team how to properly
02/03/22 11:00-11:30 use node. Development team is almost done with the development
Filip, Seb, Omar, of the front end and transitioning on the back-end side of things. We
Riann did commit a big change in the way the pages were displayed as it
will be described on the report.

03/03/22 In Person Worked on the report, collected some information from the
14:00 - 16:00 development team and articulated the design section with a brief
Seb, Ed description of each page within the user guide.

05/03/22 Team Meeting Fil supported Riann to implement the calendar on his assigned page,
11:00 - 13:00 the calendar framework now appears. Also split the GitHub into
Fil, Riann branches for each functioning page.

07/03/22 Team Meeting Fil described the backend functionalities and progresses of the
18:00 - 19:00 development team, talked in depth about potential changes in
Fil, Ed design before entering the testing phase, and described in detail
how the backend for sign up / log in works,

09/03/22 Team Meeting Added the SWOT analysis to the report, added the code style
14:30 - 16:30 section; implemented more detailed bits into the software
Fil, Ed, Seb architecture thanks to the intel provided by the dev team.
Working on the functional requirements.
Worked on the database back end so the website would show the
pet accounts added to the website.

11/03/22 Team Meeting Discussed the next steps, set a deadline for the whole front end by
10:00 - 12:00 Monday 14/03; updated the report on project management adding
Ed, Seb, Zofia, the Team header and description and started on the ethical
Fil, Omar, Riann evaluation.
Monday the testing will begin.

21/03/22 Team Meeting Evaluation of teamwork so far, feedback, experiences and personal
15:00 - 17:00 opinion on how we did so far. Thoughts were then drafted and added
All present to the report in the evaluation section.

25/03/22 In Person Testing procedures within the last version of the web application,

58
 15:00 - 17:00 drafted the conclusion of the report and finalised references and
Seb, Ed appendices. Created a few GIFs to show the responsiveness and
included all relevant missing screenshots for user guide.

28/03/22 Team Meeting We all got together to discuss and walk through the respective
11:00 - 13:00 progresses both on dev and business. We were considering making
All present a video presenting the project but considering the few time left we
decided to focus entirely on the finalisation of what has been done
so far to maximise results and limit risks of missing bits.

30/03/2022 Team Meeting We went through the final report, Seb finished the last bits of UX
14:00 – 16:00 testing and Ed completed the Stakeholder Summative Evaluation.
All present Fil described in detail how the back end works for the booking
system and the passport system to be included in the report as a
description.

31/03/2022 Team Meeting We walked through the final report. Seb and Ed have been
16:00 – 18:00 formatting it on a word doc from the original google doc that was
All present drafted in. Final minor edits and submission.

59
2) Online Resources used during the project
1. Google Maps Platform Documentation | Google Developers
2. Track User location - Google Map JavaScript API - API Key
3. https://youtu.be/GWE9ay9H7uU
4. https://codepen.io/leenalavanya/pen/mPWdPZ
5. https://www.figma.com/community/file/1006761362053746059
6. https://infograph.venngage.com/view/7eaf2b4d-3e95-4b4b-aacd-c055580a9fc6
7. https://miro.com/app/board/uXjVOKtwo1Q=/
8. https://scholar.google.com/schhp?hl=en&as_sdt=0,5
9. https://trello.com/
10. https://github.com/
11. https://cloud.google.com/sql
12. https://visualstudio.microsoft.com/
13. https://infograph.venngage.com/infographics
14. https://www.microsoft.com/en-gb/microsoft-teams/group-chat-software?rtc=1
15. https://www.google.co.uk/docs/about/
16. https://office.live.com/start/word.aspx
17. https://www.apple.com/uk/safari/
18. https://www.google.com/intl/en_uk/chrome/
19. https://www.mozilla.org/en-GB/firefox/new/
20. https://www.android.com/intl/en_uk/
21. https://www.apple.com/uk/ios/ios-15/
22. https://about.gitlab.com/?
utm_medium=cpc&utm_source=google&utm_campaign=brand_emea_pr_rsa_br
_exact&utm_content=homepage_digital_x-
pr_english_&_bt=363211725518&_bk=gitlab&_bm=e&_bn=g&_bg=7529458631
9&gclid=CjwKCAjwuYWSBhByEiwAKd_n_lW2D81KF55LI6HcPoS9Ku5trFxliykja
bFRSTWE7G9WIjY9o0GC4hoCUoIQAvD_BwE
23. https://www.microsoft.com/en-us/microsoft-365/excel
24. https://inoxoft.com/blog/best-practices-on-user-profile-design-with-examples/

60
25. https://agentestudio.com/blog/design-user-profile-page

61