Master Thesis: A Report on “Gole” a dynamic Time-Management System

Msc Computer Science

Project Report

Loic Yatou

Supervisor: Dr. Mathew Leeke

Department of Computer Science

University Of Birmingham

2022-23
Table Of Contents

1. Abstract
2. Introduction
3. Research
4.
Abstract

Effective time management is associated with greater academic performance, job satisfaction and efficient
work-flow. However, many professionals and students struggle to strike a balance between their daily lives and
achieving their goals. In response this paper outlines the development of a preliminary desktop prototype Gole,
a productivity tool designed to partly address both the lack of tenacity among academic and professional
workers and streamline the productivity of active workers. Instead of helping users organise and block out time
on their calendar to focus on key tasks as is the case with standard productivity software, this project will
dynamically build a user’s schedule with respect to personal static variables. In addition, it will allow users to
integrate predefined programs into their unique personal schedule without assuming the responsibility to find
appropriate time for them. The developed prototype yields promising results, guided by rigorous testing and
evaluation procedures and supported by the amalgamation of academic and technical research. By summarising
the findings into the following discussion piece, this paper aims to encourage productivity software providers to
build adaptive personal information agents that mould around a user's individual schedule rather than
accustoming users to the generalised software.
Chapter 1: Introduction

1.1 Motivation

Setting goals is simple, but achieving them is hard. Why? This question has bewildered academia for centuries.
Indeed, despite the abundance of digital and physical resources available, only 9% of people actively choose to
change career paths (National Statistics, 2019) despite 85% believing their jobs will become obsolete because of
technology (Gallup, 2021), and 43% believing they have lost control over their futures, personal lives, and
careers (Brower, 2021). Many academics have sought to tackle this issue, attributing it to a lack of motivation
(Berkman, 2018), low self-esteem and a low regard for particular work (Ford, 2013). However, it appears that
the most widely acknowledged factor is time management, particularly a sense of time, a sense of the things that
occupy time, and effective work habits (Kelly, 2011). For example, Lay & Schouwenburg contend that
individuals typically underestimate or overestimate how long it takes to complete a task rarely giving an
accurate estimation (1993), and Gerrard & Variawa discovered that at the University of Toronto, there was a
direct correlation between how students perceived difficulty and the amount of time spent on assessments, with
time having the greatest impact (2017).

While there has been a growing economic response to time management issues by the productivity market,
which is expected to reach £5.6 Billion by 2027 (SNS Insider, 2022), many of the current solutions are quite
rudimentary, especially for students or professionals who have no experience with goal planning or struggle
with procrastination. Solutions such as Evernote currently allow for the insertion of some metadata (e.g. due
dates and categorization) that typically integrates with an existing calendar and email. In practice however, this
can be difficult to manage or maintain, as one must first become familiar with navigating their own calendar in
order to find time, and also assumes that users have a sufficient sense of time control. You may also be able to
download and edit a template before using it in some cases. As an example, Any.do offers templates for project
management, such as "Sprint Planning" and "Inventory Tracking," which may be useful to leaders, but are
almost irrelevant to the average professional or student. Additionally, this also falls into the aforementioned
pitfall of requiring users to already be used to tailoring programs to their personal schedules, a prerequisite that
is not applicable to the average student or working professional.

1.2 Project Aims

The project's goals are the same as those stated in the specifications, with the ultimate objective of developing a
time-management tool that assumes the responsibility of finding, scheduling and reshaping a user's perceived
control of time when goal setting. This application consists of three key features: (1) Auto task insertion, (2)
Auto rescheduling, and (3) Integration with community programs. The auto task insertion relieves the user from
having to find time to complete a task. Instead, Gole will locate time for the user to complete a task depending
on user-defined soft preferences and task duration. In response to higher priority jobs requiring immediate
planned attention, the Auto-reschedule will reorganise specified tasks whose completion date is negotiable.
Finally, the Community programme integration enables users to add programmes such as a high-achievers guide
to exam prep or an introductory course to OOP that is also automatically tailored to a user's schedule based on
their soft-preferences. This project involves full-stack development which means the prototype must be of an
appropriate standard to demonstrate the basic plausibility of the aforementioned features. However this does
mean there is a lack of academic/scientific focus. As a result this paper will extend some of the possibilities of
the Gole application, specifically elaborating on the potential use of natural language processing (NLP) models
to make suggestions on tasks based on user input, choice of degree or career. If a user indicates an interest in
Augmented Reality for instance, the application can suggest some C# courses to integrate into their personal
schedule. In so doing, users are encouraged to upskill or reskill with specific as opposed to generic - and often
not useful - time frames as to when their schedules allow for its completion. Naturally this will require extensive
research into machine learning algorithms and NLP frameworks, contributing some academic rigour to the
overall project.

1.3 Project Stakeholders

For this project the main stakeholders consist of the Developer Loic Yatou, a project supervisor, Dr. Matthew
Leeke and potential users, student and agency owner Kupa Mugs and student/software engineer James
Haeksworth. Since the end goal is to deploy the application for consumer use the feedback by the
aforementioned is crucial in building a comprehensive, safe and scalable solution and will be noted where
appropriate throughout the report and particularly in the testing chapter.

1.4 Report Structure

There are three main sections that define this report: Preliminary Research, Production and Reflection. Using
this architecture, readers are provided with the quantitative and qualitative research supporting the incarnation of
Gole, market research as to the competition within the market and an insight into key design decisions that guide
development.

Preliminary Research

Preliminary research is represented by Chapters 2 – 5. Ultimately, this section introduces the proposed
application by stating the problem statement, its importance, and how the Gole application proposes to solve it.
For example, Chapter 2 summarises the primary academic consensus on time management, procrastination, and
its prevalence in the academic and working environments. Chapter 3 focuses on the potential legal, social,
ethical, and professional difficulties that may arise as a result of Gole's presence, ensuring that it does not breach
anticipated and professional conduct. Chapter 4 will explore the applications of Natural Language Processing
(NLP) in the context of a to-do list application, focusing on how NLP can provide intelligent suggestions to
users for their tasks. Additionally, it will delve into the algorithms, use cases, and software frameworks relevant
to implementing NLP-driven task suggestions. Chapter 5 finally establishes the system requirements for the
production based on the basic standards of the productivity market and research presented in Chapter 2.

Production

The production section is represented by Chapters 6 - 8 and will be the primary emphasis of this report. Chapter
6 delves deeply into technical design decisions and, if applicable, future enhancements with respect to NLPs as
outlined in Chapter 4. Chapter 7 complements the software methodology by providing step-by-step descriptions
of the development process. Finally, Chapter 8 discusses the testing of the implemented features and presents
some of the results, such as data on performance.

Reflection

The remaining chapters will evaluate the systems development process. Chapter 9 will summarise the project's
software methodology and include sprint-planning samples, revealing how the development cycle was
structured. Chapter 10 compares the preliminary software requirements to the prototype, confirming that the
core functions of the envisioned system are met while demonstrating why other negotiable functions are not.
Finally, in light of the project's overall scope, Chapter 11 will finish with constructive critique for future
iterations of Goles production as well as proposals for future market developments.
Chapter 2: Research

The use and invention of productivity applications has exploded in the recent decade. Indeed, its estimated
market value as of 2022 is $4.6bn and is expected to rise by 8.2% annually leading to a $7.22bn valuation by
2027. Surveys also reveal that productivity applications scored highest in terms of usage for 96.77% of
applicants (Raymond, 2023), making it a staple in the arsenal of many smart-phone users, particularly in
developed countries. Despite their widespread use in modern society, the historical origins of "productivity
apps"or “to do lists' are mostly obscure. It's possible that this is because "productivity apps" is more of an
umbrella phrase than a fixed concept. Roe, Classens, Erde and Ruttes definition will serve as precedent for this
project, defining it as “behaviours that aim at achieving an effective use of time while performing certain goal-
directed activities”. This paper, like them, finds it suitable since it clarifies that the use of time is not an aim in
itself, because time cannot be regulated and is an inaccessible factor, and that the focus is instead on goal-
directed activities such as fulfilling work tasks or academic duties (Roe, 2012).With this in mind, the following
will look at the academic history of to-do lists as well as the trajectory in light of contemporary technological
breakthroughs.

2.1 Brief History On To-Do-List applications

Scientists, Inventors and Epistemology

1600: As previously discussed, the historical origins of the phrase "to do lists" or simply "lists" are unknown.
However, the widespread view is that the term was coined or became popular throughout the Middle Ages. "A
very clear image of the universe existed in the middle ages, and there were lists," says Umberto Eco, a
mediaeval historian (Eco, 2009)This would make sense since a new astronomical worldview began to dominate
the Renaissance and Baroque eras, prompting the need for a mechanism to organise and arrange star collections.
Circa Navigate are in accordance with Umberto Eco here, also pointing out that jousting tournaments held
during this era were dubbed "The Lists" or "List fields," with knights described as "meeting in lists,"
emphasising the link between lists and organisation or grouping. The etymology certainly supports the
aforementioned conceptions, with lists defined in Middle English as a "catalogue consistent of names in a row
or series" (Middle English, 1600).

Figure 2.1 A page from Leonardo Da Vinci to-do list

Leonardo Da Vinci created some of the first historical records of to-do "lists" centred on personal improvement
or organisation. Aside from the thousands of pages of notes, schematics, and sketches that Leonardo is tasked
with making, Robert Krulwich translates a sampling from his page of to dos in figure 2.1, some of which are as
follows: Discover the measurement of Corte Vecchio (Courtyard in a Dukes Palace); Get the master of
arithmetic to show you how to square a triangle; Examine the crossbow of Maestro Gianetto.

Figure 2.2 Benjamin Franklins 12 virtues

Benjamin Franklin, one of the founding fathers of the United States, is also documented to have been an avid
self-development guru, devising lists like his "12 virtues": a list consisting of traits like "temperance" and
"frugality" as part of his daily routine as evident in figure 2.2 and his famous 5am - 10PM daily routine marked
with 6 blocks of scheduled time allocated to tasks like "afternoon work" that lasted 4 hours or "review of current
projects" that lasted 2. Finally, as testament to the widespread adoption of to-do lists in the postmodern era,
Maria Poova discovered journals by Thomas Edison that had lengthy to-do lists for a variety of tasks. Examples
of Edison's self-documented curiosities were, but not limited to: Creating a deaf apparatus; Cotton Picker i.e.
Farm Truck; Development of an Electrical Piano. While the origins of the "to do list" or the conceptualization of
"productivity tools" are unknown, it is apparent that it has been used as a time management tool for at least the
previous 400 years.

Evolution of To-Do List Applications and their future

To-do lists have come a long way since the days of Benjamin Franklin and Thomas Edison. Beginning in the
early 2000s, digitised alternatives to the traditional notepad and pen exploded. The first to-do list programme is
typically credited to Omar Kilani and Emily Boyd "Remember the milk" app, which they created in 2004,
frustrated with the exiting task management systems of the time (Remember the milk, 2020). To-do list apps
have grown in popularity and sophistication since then, encompassing a wide range of features and
functionality. The following will provide a brief overview of the several pioneering tools that emerge, as well as
the years they were released. It should be noted, however, that while many of the following companies may not
be responsible for the initial development of the retrospective technologies, they are notable for their adoption.

2004: Remember the milk introduced the use of Metadata like due dates, setting priorities, setting reminders and
sharing tasks with others. In its first inception it functioned as an add-on using google's experimental API to
manage tasks in Gmail (Remember the milk, 2020).

2005: Toodledo is also recognised for being one of the first to offer customizable tagging, prioritisation and the
ability to create multiple tasks lists separated via labels (Toodledo, n.d.).
2007: Todoist made major innovations, introducing natural language parsing, an interface allowing users to
easily enter tasks in simple sentences and have them automatically organised into objectives throughout the day
– month (Bednarski, 2022).

2010: Wunderlist offered a clean and intuitive user interface, with streamlining tools like task sharing, cloud
syncing and the ability to add notes and attachments to tasks (Bednarski, 2021)

2019: Any.do integrated with popular voice assistants like Google Assistant and Amazon Alexa, allowing users
to add and manage tasks through voice commands (Any.do, 2019).

Since then, countless new productivity applications have arisen on the market, each putting its own twist to the
aforementioned innovations, with smart suggestions and cross-platform synchronisation being notable
examples. In regards to the future of To list applications, there are a number of external breakthroughs that are
expected to find their way into the productivity arena. For example companies like Motion have demonstrated
limited but very valuable functionalities such as AI powered suggestion tools for job prioritisation, smart
scheduling, and automatic task completion (Motion, 2023). Integration with IoT devices is also a possibility,
with to-do applications integrating with smart home gadgets and wearables for cross-platform task management.
One example is enhanced voice control, which could employ NLP to improve task input and administration.

2.2 Academic Research on the connection between Time Management, Procrastination and Academic
Success

User: Students

In academia there are two strands of evidence that support the notion that effective organisation and time
management plays a vital role in improving a students academic performance and achievements. First, empirical
studies have found a positive relationship between indicators of time management and course grades or other
aspects of academic performance (Basila, 2014). Crede and Phillips for instance concluded, based on a meta-
analysis drawing on more than 20 studies, that the scale most representative of time management was predictive
of both course grades and overall GPA (2011). McCann (2012) also presented similar findings, amongst full and
part time community college students, that time management fully mediated the relationship between
consciousness and overall GPA. Finally, George went so far as to claim that time management was the sole
predictor of university students' CGPA, academic and personal success (2018). According to the data he
collected, time management skills have a moderate positive correlation with GPA (r = .38, p < 0.001) and a
moderate positive beta coefficient (β = .242, p < .001) (George, 2008). In terms of total success clearly defined
goals had a significant beta coefficient and positive correlation with (β = .302, p < .001) indicative of the latter
and (r = .49, p < .001) of the former (George, 2008). Despite the overwhelming evidence supporting the claim
that time management and academic success have a positive correlation, a large portion of students fail, struggle
or feel a lack of support in managing their time. Rabin for instance found that 30-60% of students postpone their
academic tasks despite recognising time management as their most crucial problem (Rabin, 2011). Furthermore,
Malik, Sharif, and Khan (2020) discovered that undergraduate students at universities had below-average time
management behaviour, including setting objectives, priorities, and time management methods. Despite this,
they discovered that students had a greater mean perceived control of time than any other management
behaviour dimension, implying that students were generally more conscious of their time use but struggled with
making to-do lists, planning, and managing their time for both short and long term goals (Malik, Sharif, Khan,
2020). Ultimately, the aforementioned demonstrates an increasing need for successful time management
solutions that do not rely solely on your perception of your priorities/program, but also on a system that can
dynamically change and provide recommendations for you.

Students' misappropriation of time and its relationship to academic achievement and well-being is a second
distinct but complementary topic of research on the importance of time management (Aeon and Aguinis 2017).
Indeed, students spend a significant amount of time engaged in activities that are either not immediately relevant
or are likely to impede academic duties and the achievement of crucial personal goals (Liborius 2017).
Examples include, but are not limited to, social networking, viewing videos, computer gaming, and other social
or recreational activities that are unlikely to improve their academic performance. It's no surprise then that many
students struggle to manage their study time, keep up with their work, or even attend lectures. Kim and Seo
(2015) however report that the most definitive reason for a misappropriation of time is procrastination. Steel
states that "to procrastinate is to voluntarily postpone an intended course of action despite expecting to be worse
off as a result of the delay," (Koppenborg, Klingsieck, 2022) a phenomenon that is particularly frequent among
students, with around 60% of them procrastinating whether studying for exams, writing term papers, or reading
weekly assignments (Beswick 1988). Moon And Illingworth describe the process of procrastination as
“following a curvilinear trajectory over time, academic procrastinators tend to delay working until the last
minute”(2005) . Although, it is important to note that longitudinal studies representing actual learning behaviour
before a deadline is scarce with the majority of students (irrespective of procrastination) concentrating their
efforts to the last week before exams (2001). Nonetheless, students lack of sufficient self-regulation abilities has
been recognised as a primary cause of procrastination. According to Howell and Watsfor, there is a negative
relationship between procrastination and the application of cognitive and meta-cognitive methods (Howell,
2006). They also discovered a strong correlation between disorganisation and procrastination, supporting the
notion of procrastination as a failure of self-regulation (Howell, 2006).

The aforementioned have shown a strong correlation between time-management and academic success, and the
consequences due to a lack thereof. And whilst research concerning the interventions to avoid procrastination is
scarce, this project will follow the popular claim that to improve self-regulatory skills one must learn to practice
better time management (Lynch 2008). Meer (2019) suggests that universities "could and should play a more
active role in assisting first-year students in making sense of time management."(2019) . Indeed, students often
experience an increase in autonomy and responsibility as they progress from secondary school to university
because they are obliged to participate in more learning activities outside of the classroom, on their own time,
and under their own direction. However, this essentially leaves students with little direction/structure and, in
many cases, a cycle of trial and error with various time management approaches far into their second and third
years of university, at the expense of their grades. It is on this premise that a student may find the Gole
application a suitable solution to effectively manage their study schedule as well as mediate or eradicate
procrastination.

User: Active Workers

There is a scarcity of scholarly research attention on the implications of time management on job performance,
future prospects or the ability to plan. In terms of why there are two viable explanations proposed in academia.
(1) In many workplaces, it is impossible to organise one's workday since management or workflow protocols
govern the order and timing of operations. Indeed, several of the most frequent occupations in the UK, such as
sales and retail, have minimal job autonomy, and as a result, time management may not be an option. (2) In
order to assess the effects of time management on job performance, the study itself necessitates extensive
detailed planning, such as prioritising or planning secondary tasks in case the original study cannot be carried
out due to work interruptions or a lack of information, both of which serve as deterrents to organisations
agreeing to participate in such studies. Nevertheless there have been some academic studies carried out, limited
as they are, that assess the relationship between task-management and job performance/satisfaction.

Figure 2.4 Path co-efficient for the proposed process model of time
management, using employee sample data * p < .05 ** p<.01

There is some debate in the literature about whether the promised benefits of time management are realised in
practice. One heavily cited study is by Macan, who in 1994 proposed and tested a process model of time
management in the workplace and found that time management training was not effective in improving job
performance. Indeed, as can be seen in the data model in figure 2.4, it is evident that whilst time management
behaviours were somewhat effective, time-management training had little influence on whether respondents
engaged in the positive job behaviours: Setting goals ; Making Lists/Scheduling; Preference For Organization.
In addition, contrary to popular belief he found that giving a person the perception that they have control over
their time, e.g. by encouraging list making or scheduling activities, did not necessarily result in a better sense of
control over their time. A similar reaction could be expected with productivity applications. It is not
unreasonable to believe that if a person fails to accomplish the projects specified, utilising the to-do list as an
objective feedback mechanism regarding their progress, projects, or duties, they would feel even less in control
of their time.

Figure 2.5 Path co-efficient for the proposed process model of time
management, using employee sample data * p < .05 ** p<.01
However, as Macan and numerous opposing academics have acknowledged, there are a variety of limitations
and explanations for his study's findings. For example, Macan acknowledges that, while the non-significant
relationship between job performance and perceived control of time may reflect the genuine state of affairs, it is
also likely that his results were influenced by unique elements of the research sample. It is not unreasonable to
believe that only certain sorts of people or persons in specific jobs do better when engaging in time management
habits. When you consider Macans subjects, this becomes even more credible. He chose 341 undergraduate
students who are less likely/incentivized to completely use TM training to increase job performance, job
satisfaction, or job-induced tensions. Indeed, these roles are typically part-time, temporary, and insufficiently
challenging in relation to the students' qualifications - for example, a law student working as a retail assistant -
and as such, there is no real drive to appropriately employ TM techniques as one might as a full-timer in their
chosen career. Alkhateeb contends that the focus on the primary predictive effects of time management
behaviours is the main cause for Macans findings. Macans' study, for example, looked at the direct and indirect
effects on time management and job performance whereas it is more acceptable to evaluate the time
management aspects that interact with job performance (Alkhateeb and Almsafr, 2012) This idea is consistent
with the fact that job performance is a multiplicative function of both skill level and motivation, and as such,
engaging in time management behaviours may be viewed as an individual difference in skills, rather than a
direct increase in performance for all individuals. This is reasonable as well. It is not inconceivable that time
management behaviours will disproportionately improve the effectiveness of motivated employees as opposed
to unmotivated employees.

Alkhateeb and Amsfr conducted a counter study (survey) to Macans suggestions by assembling a group of
respondents who’s background were consistent enough to flatten the potential bias between unmotivated and
motivated employees but different enough to achieve 0.7+ in reliability as per the Cronbach's alpha measure -
examples of factors are: employees were all from UNITEN university, equal distribution among the 3 major
races, and every member had some form of formal qualifications (Alkhateeb and Almsafr, 2012).According to
the findings, (H1) there is a substantial association between time planning (TP) and job performance (JP):
Figure 2.4 shows a spearman's rank correlation coefficient (SRCC) of 0.382 between TP and JP at a significant
level of 0.01. Alay & Kocak (2002) are useful here in defining time planning as embracing a range of items that
need planning. (H2) There is a strong association between time attitudes (TA) and JP: the SRCC discovered a
0.4 correlation between TA and JP at a significant level of 0.02. Finally (H3), there is a substantial association
between time wasters (TW) and JP: most notably, the SRCC discovered a correlation between TW and JP of -
276 at a significant level of 0.01. This is a significant inverse association correlation, implying that TW has a
strong inverse relationship with JP that grows inversely as TW increases. Limoncelli (2005) is also useful here
in defining time wasters as any activities that include low quantitative relation of profit to time spent.

Other academics in numerous industries have reached similar results. Melad, Talebb, and Abbas, for example,
conducted detailed SRCC analyses at a number of five-star hotels. They discovered that factors such as gender,
tenure, and education had little to no statistical significance in terms of job performance, as determined by
credible tests such as the Mann-Whitney test and the Kruskal-Wallis test, whereas time management,
specifically time strategies, had a 16.7% impact on JP, the highest percentage influence of all dimensions.
(Ahmad et al., 2012)further proves the significance of time management and job performance in the events
industry but also adds that orientation to time differs relativity with respect to different cultures or norms of each
workers, groups, departments and countries, factors of which are difficult to truly consider even when all job
related dimensions are reasonably analysed as done by the aforementioned academics.

While some may be sceptical about the effects of employing time management practises on job performance,
scientific studies have effectively proved that time management's popularity is justified. Previous research has
consistently found evidence of the favourable effects of time management on perceived control of time, job
satisfaction, and job performance. However, it is important to note that when compared to other dimensions of
study in this sector, such as the effect of time management on students, academia is insufficient, and the hope is
that this paper will encourage further extensive studies, especially given the popularity of productivity
applications. And while the preceding does not directly imply that a time management tool will encourage adults
to advance in their careers or change their overall sense of control over time - for example, when it comes to
reskilling - it is reasonable to assume that similar effects in the workplace can translate to their own personal
lives and organisation. One can certainly imagine the resemblance between efficiently managing work tasks
within the window of a 9 -5 and managing personal interests within the window before work or after. It also
illustrates that the Gole system might be quite useful in the workplace, particularly because it will automatically
carry out some of the essential duties that workers are taught, such as task management.
2.3 Market research on existing systems

To determine the strengths of competitive productivity applications and how they could limit or be applied to
the Gole App, a competitive analysis methodology is conducted. To do so a varied array of time-management
applications thought to be prospective competitors are assessed. Whilst competitive analysis will usually include
research on their advertisement techniques, pricing and deployment strategies this research will focus solely on
the functionalities of these applications (Hubspot, 2022). The following headings guided research:

 Features: What key features are provided by competitor's applications, and why will/will not this
feature be implemented in Gole? This will not focus on the generic features inherent in many time
management systems (e.g. CRUD task capabilities)

 Analysis of user experience: Qualitative analysis of the competitor's application's navigation paths,
user interface, and interaction design

 Functional Evaluation: A list of the functions performed by the competitor's application, as well as
how they apply to my target market.

 Technical Specifications: A surface-level examination of the technical specs of rivals' apps and
potential imitated integration.

2.3.1 ToDoIst

ToDoIst is a well-known task-management programme that allows users to

organise, prioritise and collaborate on to-do-lists. The app employs a
straightforward approach which for some makes it easy to get started with
even for first-time users. The app for instance allows users to create tasks, set
due dates and priorities, create sub-tasks, add labels and tags, attach files and
set reminders. Users are also able to organise tasks into projects and sections
further customising the workflow here with filters, labels and favourites.
Other than the aforementioned tools ToDoIst distinguishes itself from the
competition through two main features: (1) Third-party integrations: Todoist
supports the integration of other popular programmes into the software, such
as Outlook, Calendar, and Google Drive. Furthermore, if they do not already
Figure 2.6 ToDoIst App Icon
supply a certain solution, they allow you to provide API proposals (ToDoIst,
2023). (2) Natural language support: ToDoIst supports the use of natural language to effortlessly schedule tasks
instead of clicking several fields and entering information in each (ToDoIst, 2023). Here the premise is that you
tell the computer what to do just like you’d tell another human being, and in response ToDoIst is looking for
keywords to understand when a task is due, whether or not it should be repeated etc. Additionally it supports the
use of symbols to tell todoist what project or context to assign the task to, who to assign it to if it's a shared
project and more. Like many other solutions these features are also accompanied by a clean and user-friendly
interface, making it easy to create tasks, set due dates, add lakes and assign priorities (ToDoIst, 2023).

However, this may only be true for individuals who have prior familiarity with similar applications. While it
provides a helpful and extensive collection of functionality, the developer discovered that the user interface can
be intimidating, especially for a newcomer. Some customers have also encountered occasional sync difficulties
between their devices, which can result in task and reminder anomalies (Google Play Store, 2023).

User Experience:

The UI is clear, uncluttered and offers a simple organised layout. The dashboard displays your active projects
and tasks using a Kanban board which is an industry standard for displaying easy-to-read lists, offering the
option of expanding or collapsing projects for easy navigation. Task creation is straightforward offering all of
the basic CRUD operations with some additional smart features. The interface is clearly designed to encourage
users to enter tasks quickly and easily and even offers natural language inputs to rapidly create tasks. Overall it
offers a streamlined and efficient way to create, navigate and manage tasks.

Availability: IOS/Android
Price: Free with premium features available at a subscription

Apple Store Description: Apple store app description (App Store, 2023):

 Trusted by 30+ million people and teams worldwide. Todoist is a delightfully simple yet powerful task
manager and to-do list app. Finally, organise your work and life.

 Reach that mental clarity you’ve been longing for by using Quick Add to capture and schedule tasks
the moment they pop into your head.

 Add tasks like “Read work emails every day at 10am” using Todoist’s powerful everyday language
recognition and recurring due dates.

 Available on any device – with apps, extensions, and widgets – Todoist will quickly become your hub
for getting work and life organised.

 Link Todoist with your calendar, voice assistant, and 60+ other tools such as Outlook, Gmail, and
Slack.

 Collaborate on projects of all sizes by assigning tasks to others. You can also leave comments, voice
notes, and attach files to tasks.

 Project templates available to help you tackle everything (from meeting agendas and accounting tasks,
to packing lists and wedding planning).

 See what’s most important by setting visual task priority levels.

Tech Stack:

 Cloud: Amazon AWS Services

 Language & Framework Javascript & React Front-End

 Analytics: Google Analytics / HeatJar Analytics (awsometechstack, 2022)

Applicability To Gole:

The Gole application's initial version will not have as much third-party integration. This is primarily due to time
restrictions and the incompatibility of web-based APIs with Java's desktop platform JavaFX. Nonetheless, the
developer has not shied away from using existing frameworks to improve the overall quality of the programme.
CalanderFX for instance was a better option than building the calendar interface from scratch, and using an
industry standard for encryption with authenticating users significantly boosted the security of the in-house
designed login system. Future iterations of the Gole application could certainly benefit from natural language
processing, using services like Google Cloud NLP or spaCy to help facilitate the test parsing and interpretation
steps but even this feature is beyond the scope of the current Gole iteration.
2.3.2 Trello

Trello is a web-based project management programme that provides

professionals with a visual way to track and collaborate on assignments. Its
system makes use of boards, lists, and cards to allow users to efficiently
develop and manage projects (Trello, 2019). Indeed, users can build boards for
various projects and then add lists inside those projects to represent the various
stages or categories of a project. Cards can then be produced within lists to
represent particular tasks or objects that must be accomplished and can be
assigned to a team member (Trello, 2019). A description, assignees, due dates,
attachments, and labels can all be included on these cards. There are two
primary tools that distinguish the Trello App from the competition.(1)
Automation: Trello is one of the few systems that lets you construct automated
actions. These are rules, buttons, and commands that are triggered by a specific
condition to dictate activities on a project. Pattern recognition is also used to Figure 2.7 Trello App Icon
suggest automatic activities with a single click. (2) Community Templates:
Trello offers community templates that equip experts with blueprints for various sectors or stages in the life
cycle of a product. For example, one can use a marketing context catalogue to shape around a specific project or
adhere to a website task planner.

Trello truly distinguishes itself for its simplicity and user-friendliness. Overall, it provides users with an easy-to-
understand and visually pleasing experience. Its drag-and-drop capability allows for smooth task organising and
prioritising, and it is unrivalled when it comes to allowing real-time collaboration among huge teams.

Despite its many advantages, Trello lacks some functionality when compared to more complex project
management solutions. A product clearly designed for small to big teams rather than individuals may not be
appropriate for complex projects requiring substantial job interdependence, resource allocation, or tight
schedules. Furthermore, its overreliance on third-party integrations can lead to some serious security concerns
due to the inconsistency of data privacy and security amongst its partners, not to mention the possibility of
limited compatibility issues with a user's personal software. Finally, because Trello is largely a web-based
application, it has limited offline capabilities, which is especially troublesome for users who need to access and
manage their projects in places with inconsistent internet availability.

User Experience:

Trello's design is simple and straightforward, with a white (configurable) background and simple colour
coordinate cards organised into a general workflow. Although the plethora of options and capabilities can be
intimidating for newcomers, the navigation bar offers easy access to the board, cards, and settings, and
conducting CRUD operations is pretty simple. It also employs the traditional Kanban style layout, which is
intuitive and user friendly. This is ideal for those who are unfamiliar with workflow organisation. Trello
however appears to be better suited to intermediate - expert time-management users with familiarity with time-
management solutions.

Availability: IOS/Android

Price: Free with premium features available at a subscription

Apple Store Description: Apple store app description (App Store, 2023):

Manage any team project or task thanks to Trello’s boards, cards and checklists. Improve collaboration and
productivity—join our community of 50 million registered users!

 Get more done with Trello’s customizable-yet-simple boards, lists, and cards.

 Go from idea to action in seconds by creating cards and dragging them across the board to follow
your project’s progress.

 Add checklists, labels, and due dates the way you see fit and give your projects the fuel they need to get
across the finish line.
  Free your brain from remembering every planning detail.

 Add Power-Ups like a Calendar view of your due dates or add locations to cards to get a Map view—
your project will take on a whole new perspective.

 To stay organised no matter where you are, turn on notifications and stay informed when cards are
assigned, updated, and completed.

 Trello works offline! Add information to your boards and cards at any time and it will be saved for
when you need it. We got your back.

Tech Stack

 Languages & Frameworks: Javascript,Node.JS, Redis, Coffee Script for front and backend

 Data Storage: MongoDB and Redis for database management

 Analytics: Google analytics

 Cloud & Code Management: Github for code management (Stackshare, 2014)

Applicability To Gole:

The Gole application will use a more sophisticated version of community project templates. Rather than
requiring users to enter a programme - Trello allows users to get a copy of their own versions of predefined
templates - the Gole application will shape programmes to fit their existing schedule. Many solutions on the
market do not provide consumers with a realistic time frame to accomplish tasks, thus this is considered a
superior offering. It is not unreasonable to believe that users would benefit from a programme that integrated
automatically, evaluating their preferences solely at the accelerated speed of a machine rather than manually by
an individual.

2.3.3 Evernote

Evernote is a powerful suite of software and services designed for note

taking and organisation. It allows users to capture, organise and find
information across numerous devices with notes or tasks taking the form of
documentation, web-clippings, images, audio-recordings and much more
(Evernote, 2018). It also serves as a digital workspace for small-medium
size teams to collaborate effectively, praised for its cross-device
synchronicity (Evernote, 2018). There is one unique feature of the Evernote
application that distinguishes it from its competitors and that is its robust
search capabilities. Indeed, users are able to find specific text within
images, handwritten notes and scanned documents (Evernote, 2018). Such
options are uniquely superior to its counterparts since users can hand draw
to-do-lists but with the portability of a wireless device and the easy
retrieval of information to quickly locate specific tasks or items without
manually searching through noted documents. Figure 2.8 Trello App Icon

However there are some considerable drawbacks to the Evernote application in comparison to substitutes on the
market. The biggest issue is limited collaboration features. Whilst it allows some collaboration features between
users, they are not as extensive as those offered by other note-taking software like google docs particularly real-
time collaboration. With no capability for two people to work alongside each other on the same note, work-flow
may become inefficient in comparison to competitors. In addition it lacks considerable productivity features.
Unlike ToDoIst or Trello, its task management is reduced to basic checklists. Even with an upgrade to the
premium plan you cannot track progress, manage workload or customise a task status.

User Experience:
Evernote offers a straightforward and user-friendly UI. The homescreen presents all notes and notebooks in a
tiled format, making it extremely easy to navigate among notes. The sidebar provides users with an efficient
way to access frequently used features such as notebooks, tags, and shortcuts. The notes section provides all
formatting and attachment choices, making it useful for both students and professionals in a variety of
professions. Overall, it is one of the most user-friendly interfaces on the market, emphasising on note taking
rather than organisation and scheduling.

Availability: IOS/Android

Price: Free with premium features available at a subscription

Apple Store Description: Apple store app description (App Store, 2023):

Capture ideas when inspiration strikes. Bring your notes, to-dos, and schedule together to tame life’s
distractions and accomplish more—at work, at home, and everywhere in between.

Evernote syncs to all your devices, so you can stay productive on the go. Tackle your to-do list with Tasks,
connect your Google Calendar to stay on top of your schedule, and see your most relevant information quickly
with a customizable Home dashboard.

 Manage your to-do list with Tasks—set due dates and reminders, so you never miss a deadline.

 Connect Evernote and Google Calendar to bring your schedule and your notes together.

 See your most relevant information instantly on the Home dashboard.

 Create separate notebooks to organise receipts, bills, and invoices.

 Find anything fast—Evernote's powerful search can even find text in images and handwritten notes.

Tech Stack:

 Languages & Frameworks: React, React Native, JavaScript and Java for frontend and backend.

 Libraries: Node.Js for server-side code

 Data Storage: PostGresSQL

 Cloud: Github for control of code base, Amazon Web Services for cloud infrastructure (Quora, 2023)

Applicability To Gole:

While the Gole programme will not provide enhanced note-taking capabilities, future iterations may
contemplate allowing users to scan hand-drawn to-do lists and have them available in digital form. Furthermore,
for course programmes that encourage reflection on tasks, it is not unreasonable to imagine users using the
description box of a task to do so, and thus improving search capabilities could be useful, especially if the
reflection was written by hand and scanned into digital form.
2.3.3 Motion

Motion is an AI-powered productivity tool that helps users focus, arrange

tasks, and enhance productivity. Motion's clean and user-friendly design
enables users to swiftly build to-do lists, make reminders, and manage
their time. The programme also includes options such as progress
tracking, time logging, and the ability to categorise tasks, all of which
help users manage their workload effectively. The most significant
feature that helps Motion stand out from its competitors is the integration
of Artificial Intelligence. Motion plugs tasks into available time slots in
your schedule based on task parameters such as deadline, priority, and
duration. It also allows you to divide tasks into blocks and set the shortest
length of time for each block - a handy tool for deep work that you don't
want divided into numerous short time blocks. A stand out aspect of this
tool is that if you miss deadlines or start tasks late the application will
automatically reschedule your task allowing you to keep your priorities in
Figure 2.9 Motion App Icon
place a feature many of the other services on the market fall short off.
Another standout feature is the meeting assistance. This feature is great
for users who are used to meetings taking over their schedule, with the app automatically blocking meeting
requests during periods of pre-defined focus. However this is only useful for users with complete control of their
schedule and perhaps not as useful for the regular employee.

Despite Motion's enhanced scheduling tools, it neglects some of its competitors' advanced functionality. For
example, unlike its competitors, the note taking space does not enable formatting choices such as hyperlinks or
new lines. Furthermore, unlike Trello, it does not support third-party integration, which compels you to stay
within the ecosystem rather than making it a branch of a bigger workflow. Finally, if a user does not participate
in a lot of meetings or project management workflows, the application may not be as useful, which implies that
a huge section of customers who are wanting to optimise their personal calendar may not find it as appropriate
as a simpler solution like todoist. It’s worth noting however that Motion is still in its development phase unlike
other solutions on the market and may intend to introduce these features later on, just as the Gole application
will.

User Experience:

Overall, the motion application features a smooth and user-friendly design that instructs users on how to utilise
its utility to increase productivity and time management. It is divided into two sections: the calendar and
projects and tasks. The calendar portion includes a weekly or daily view, and the sidebar organises tasks by day.
The project and tasks area also offers two views, a standard list view and a kanban board, which is advantageous
because avid users of productivity software, such as Trello and Todoist, are familiar with this interface. The
colour scheme is also pleasing to the eye in both of these sections but it is fixed on a darker colour theme which
may not be appealing to some.

Availability: IOS/Android

Price: Free with premium features available at a subscription

Apple Store Description: Apple store app description (App Store, 2023):

An A.I. executive assistant for task and calendar event management.

Ranked #1 fastest-growing product in 2022 by Amplitude's Product Report.

Motion uses automation and AI to intelligently plan your day, schedule meetings, and build the perfect to-do
list. Used by 50,000 busy professionals and teams to

 Automatically plan your day

 View to-dos on your calendar

  Collaborate with your team

 Schedule meetings in 1-click

 With Motion, your AI executive assistant, you no longer:

 Manually reorganise tasks and meetings

 Keep track of fragmented calendars

 Spend time coordinating meetings

Tech Stack:

 Analytics: Optimise, Google Tag Manager, Google Analytics

 Data storage: Amazon S3

 Languages & Frameworks: Node.JS, Javascript, HTML5, CS3

 Libraries: React.Js ((Himalayas, n.d.)

Applicability To Gole:

Given the time constraints, adding AI features to this iteration of the Gole programme was unfeasible. However,
as noted with ToDoIst, adding NLP frameworks to task inputs is on the agenda. The Auto-Scheduling feature of
Motion will however be improved by the Gole application. As per the academic conducted study, it seems a tool
that automatically schedules complete programmes into a specified timetable could effectively curb or eliminate
procrastination while also showing people a new or better way to manage their time. Given the success of the
Motion application, which was named Amplitude's fastest growing product in 2022, it seems there is a potential
market for software that relieves users of this responsibility.

2.3.4 Unique Offerings: Gole Application

The capacity to incorporate programmes into a user's calendar, moulding around their present commitments,
will be one of the Gole application's primary distinguishing features. Currently there does not exist a
productivity application which encourages users to follow well-established academic programmes that will
uniquely fit their personal schedule. The closest market offering to this functionality is Motion's AI-powered
auto-scheduler, which schedules users' individual tasks into preset windows - a feature Gole also commits to
providing. However this does not consider the fact that user’s may be unaware of the type of tasks necessary in
pursuit of an aspiration, as well as how those tasks can fit within their life. Additionally current offerings do not
consider intricate user information such as their weekly burnout rate. The Gole application thus intends to
remind users how far or close they are to approaching that zone. This provides users with a broader view of their
ability to progress on any goal, achieving continuous steps towards it rather than unexpected bursts and fall
periods.

2.4 Conclusion to Preliminary Research

The aforementioned studies show that students have below-average time management skills, and professional
workers struggle to imagine incorporating a re-skilling/up-skilling programme into their daily lives, despite the
importance of the need. They struggle in particular with setting objectives and priorities, arranging their time for
different projects, establishing to-do lists, feeling in control of time, procrastination, and estimating the time
required to complete tasks. To further reduce procrastination and ease professional or academic transitions, an
application that dynamically adjusts a programme based on static variables, makes suggestions based on tasks or
a user's current professional standing, and allows you to integrate the successful programmes of high achieving
endorsers provides an invaluable solution that is currently not served by the productivity market. And, while
high-achievers naturally have less need for time management systems, a skill that is inherent in their socio-
economic position, it is clear that a system that dynamically re-organizes a schedule based on changing static
variables will be extremely beneficial in reducing their time spent on personal organisation. Completing the
Gole application will thus not only address poor time-management but contribute to the lack of academic
solutions to procrastination.
Chapter 3: Legal, Ethical, Social and Professional Issues

The Gole programme seeks to gather, process, and at times shape users' personal data, so adhering to ethical
principles and guaranteeing user confidence and safety in data management and storage is critical. The
following will cover various concerns that may arise during Gole's development in the legal, ethical, social, and
professional realms if not carefully planned and considered. The British Computing Society Code of Practice
was used to aid the developer. However, the set of regulations is vast and not all relevant, therefore the
following will just outline those that are pertinent.

3.1 Legal Issues

The primary legal considerations are privacy, intellectual property, and liability. Because the Gole application
will collect personal information about the user such as name, profession, and email address, GDPR compliance
is critical. Before collecting personal data, it is critical that users provide explicit and informed consent (ICO,
2023). The use of clear and straightforward language in the terminus and conditions allows consumers to opt in
or out. Another technique to preserve users' privacy is to secure their data. Third-party providers such as Google
or Firebase are appropriate since they use the greatest level of encryption, access limits, and frequent security
audits to reduce the possibility of cyber assaults (Firebase, 2019). When integrating programmes or suggesting
tasks, Gole must take care not to infringe on the intellectual property rights of others. To avoid this, Gole will
initially gather tasks solely from Udemy or other sites whose APIs encourage and provide coverage for using
courses. It will also encourage endorsers to build their programs within the Gole ecosystem signing waivers in
respect to the tasks usage. Finally, detailed terms of service and user agreements outlining the boundaries of
liability will ensure that no penalties result from auto-insertion or integration features moulding a user's day,
week, or month.

3.2 Ethical Issues

The two key ethical concerns are privacy, specifically the preservation of personal information, and content
filtering. As previously stated, using third-party services such as Google or Firebase eliminates the need to store
and maintain passwords or other alike personal information. In terms of content filtering, the Gole app can
verify that community programmes and AI generated suggestions are appropriate in two ways. The first is
relying on external APIs: relying on the Udemy API, for example, means that the platform guarantees that each
course is entirely educational and will be prefiltered as such (Udemy, 2015). Furthermore, when employing
NLP frameworks such as Apache openNLP (ApacheNLP, 2017) can assist in detecting and filtering out
offensive or unsuitable language in user input or generated suggestions. Sentiment analysis tools, such as
Stanford CoreNLP as an alternative, will additionally examine the sentiment and emotional tone of user inputs
and recommendations (CoreNLP, n.d.).Second, the Gole app's developer can build a set of rules or guidelines
that specify what is considered proper or ethical material, at least in future incarnations. This can include
curating or moderating ideas given by an open NLP, utilising machine learning to train a model for content
screening, or having an administrative window where published courses are first vetted for platform suitability
before being made public.

3.3 Societal Issues

The primary societal challenges are inadequate work-life balance, production pressure, and accessibility. The
first two issues arise if the Gole programme does not take into account the need for relaxation in between tasks.
To mediate this, the Gole application should track working hours - including both formal work and personal
interests - throughout the week and encourage users to take breaks as they approach the average known burnout
(Hu and Cheng's study found that long working hours approaching 40-60 hours are likely to lead to burnout)
(Hu, Chen and Cheng, 2016). Other than encouraging the user to take breaks via pop ups or notifications as they
approach the 40-60 hour window, the app will encourage the utility of the “productivity method” feature. This
feature of the application will allow users to select from a variety of well-known productivity strategies such as
the "pomodoro technique" to ensure that breaks are taken into account when allocating time slots to activities
(Almalki et al., 2020). Furthermore, while the Gole app will not make it impossible, it will strongly discourage
users from filing every available minute of their schedule, which can lead to fatigue and stress. Finally in respect
to accessibility, the app will be designed to be largely intuitive and simple in its UI/UX design so that users can
benefit from its features regardless of physical or cognitive limitations.
3.4 Professional Issues

The main issues in respect to professionalism are accuracy and reliability, competence and professional
boundaries. As aforementioned the app will rely on third parties to generate community programs as well as
moderate published programs by endorsers. Using pre-defined rules like only allowing the highest rated
programs from Udemy to be published on the Gole app as well as utilising a revised version of their course
requirements checklist for programs created directly on the Gole app means it can reasonably ensure that
inaccuracies or errors are kept to a minimum. Administrators on the Gole app can also check courses for their
accuracy or bring in external experts (like university lectures) to revise the content and criticise where relevant.
The competence of the developer is also in question. At least for the prototype it's appropriate to rely on the
languages the developer is most confident in, which on one hand may unavoidably limit the potential of the
Gole application, but at least ensures the MVP meets the basic user expectations. Assessing future developers'
qualifications or previous work can ensure that future iterations are just as accurate as the initial prototype.
Finally in respect to professional boundaries as aforementioned, security in the deployed version of the Gole app
will be handled by an external API like google or firebase. One of the key features provided by firebase is
periodically deleting user data (Firebase, 2019). In combination with Java logic, the Gole app can completely
eradicate confidential or work-related information in the database as well as give users the option to do so
prematurely.
Chapter 4: System Requirements

Capturing the desired behaviours of an application is one of the most important components of software
development. To do so the following first clarifies the scope of the project and the initial intended users. Then it
divides the requirements into two parts: Functional and Non-Functional requirements. The functional
requirements will concentrate on essential specifications, particularly the relationship between inputs and
outputs. Non-functional requirements, on the other hand, will impose constraints on the design implementation,
such as performance requirements, security, or reliability. Ultimately it will indicate the direction the developers
design and implementation of the productivity application intends to take.

4.1 Refinement of proposal requirements

There are some small discrepancies between the initial idea and the system discussed in this report, as will be
clarified in the reflection section. As development began, the basic idea gradually evolved into the prototype
displayed, owing to time constraints and the ability of the Agile Scrum process to re-establish priorities.
Nonetheless, the current report reflects both the project's current stage and ambition, as well as prospective next
steps to address those requirements not met in the proposal.

4.2 Project Scope

The initial prototype is exclusively a desktop application, assisting users in organising busy schedules to make
time for personal goals. The main focus is automatic task allocation based on soft preferences, moulding
programs around schedules and re-organising negotiable tasks to make space for priorities.

System Purpose

For Users :

1. Students: Students will use this productivity application to have automated revision schedules catered
to their chosen course. The main advantage here is having a dynamic revision schedule that can mould
around your current schedule.

 Goal Example: Prepare for term examination by having revision sessions moulded around
lectures, part-time roles or hobbies.

2. Professionals: The system will provide career professionals with dynamic schedules catered around
priority graded obstacles (9-5, kids etc) in respect to personal goals (e.g. reskill, upskill, marathon
training, gym etc)

 Goal Example: Reskill into a career in cybersecurity, completing a cyber security course and
having the course tasks moulded around your personal schedule.
 Goal Example: Re-allocating negotiable tasks to new time slots to make space for sudden
priorities like a last minute meeting.

Location:

Any user with access to the internet and a GitHub account can download the appropriate Java files and follow
the instructions for the relevant dependencies (JavaFX, JDBC, etc.). Because the database is kept on Firebase,
the aforementioned is all that is required to test the application's operation.

Main Responsibilities

1. Provide a user-friendly interface that allows users to easily create and manage tasks
2. Create dynamic study schedules that mould around users priority graded obstacles (e.g. gym)
3. Track and generate reports on tasks
4. Allow endorsers to upload productivity plans in respect to expertise
5. Allow users to set due dates, priorities and reminders for their tasks
 6. Be reliable and ensure that all tasks and reminders are saved and sent on time.
7. Protect users personal information and ensure data privacy
8. Allow users to reorganise schedule to make space for new priority tasks

4.3 Functional Requirements

F1: The system must access and store third-party data

1. The system must connect to the given cloud storage and authentication services
a. Google
b. Firebase
2. The system must store and convert data from selected third parties in a common format.
a. Google
b. Firebase
3. The system must allow users to connect to third-party services to register or be authenticated for
logging into the platform.

F2: The system should allow users to automatically insert tasks into their schedule

1. A user must be able to specify there time preferences for task allocation
2. The preferences set must be stored in a database ready for every session
3. If time cannot be found the App must inform the user to widen the preferences

F3: The system must allow users to integrate community programs into there personal schedule

1. The system must store a selection of programs to integrate into the users personal schedule
2. The programs must not overlap with current tasks
3. The program must satisfy the users soft-preferences

F4: The system should allow users to decide the priority of an identified goal.

1. The system must allow users to change the flexibility of a task from negotiable to non-negotiable at any
time
2. The preferences of a task must be stored and retrieved whenever a user signs into the application

F5: The system shall allow users to perform all CRUD operations with tasks

1. The system must allow users to create tasks

2. The system must allow users to read tasks
3. The system must allow users to update tasks
4. The system must allow users to delete tasks
5. The system must store tasks in a database retrieved once logged in

F6: User aggregated data in the system must belong solely to a single individual at maximum

F7: The system must store input data obtained from users for potential natural language processing for future
task suggestions

1. The system must store input data so that natural language processing models can come up with
potential task suggestions based off user history

F8: The system must provide an engaging, focused and informative way of presenting tasks to users

1. Titles for for each program must be provided

2. Descriptions for each program must be provided
3. When a specific function is clicked viewing experience must be focused on one feature at a time
4. The current dates tasks must be on the homescreen on launch when navigated back to.
F9: The user interface must provide appropriate functionality for a user

1. Authenticated users must be able to view their personal tasks

2. Authenticated users must be able to view community programs
3. Authenticated users must be able to perform CRUD operations easily and intuitively
4. A user must be able to change tabs easily
5. A user must be able to log in and out easily
6. A user must be able to register easily
7. All users must have access to the terms and conditions as well as privacy policy.

F10: The user must be able to view there tasks on a calendar

1. The user must have the option to view their tasks on a daily, weekly, monthly or yearly calendar
2. The calendar must automatically update when CRUD operations are performed on tasks
3. The calendar must allow you to perform CRUD operations

4.4: Non-Functional Requirements

To-do list apps are frequently used ritualistically. As a result, it is critical that the non-functional criteria ensure
a seamless user experience that allows users to manage their activities with comfort and ease. Non-functional
requirements are prioritised not only to improve program functionality, but also to assure customer satisfaction
in attaining organised and productive job management.

NF1: The system must be modular

1. Components program must be easily accessible, editable and replaceable by the developer and future
developers
2. Each component, method and class must address a particular function

NF2: The system should be maintainable, commented and provide strong documentation for future iterations

1. A detailed report of the system and its workings must be provided with the prototype
2. Non-trivial areas of the codebase must be heavily commented to guide future work and aid
understanding
3. The MVC architecture must be adhered to

NF3: The system should be secure

1. Users must not be able to surpass the login or registration pages without valid login details
2. User information must only be available to the specific authenticated user
3. A user must not be personally identifiable to other users and vice versa

NF4: The system shall load a users information in a reasonable amount of time

1. The system must respond to commands in a reasonable amount of time

NF5: The system should be easy to navigate and understand

1. The user interface should intuitive enough so as to not require specialised training or support to utilise
2. The user experience should be consistent

NF6: The application must be accessible to users at all times of the day
Chapter 5: Design

The preceding research and requirements chapters lay the groundwork for developing Gole's software code. The
final step in this preparatory phase is software design, which, along with the previous steps, attains the highest
level of abstraction, allowing the developer to comprehend better and meet the objectives. The following will
focus on breaking down the two main phases of desktop application development: Front-end Development and
Backend Development. Front-end Development is described as “a focus on the visual aspects of a website - the
part that users interact with” whilst backend development “comprises a sites structure, system, data and logic”
(Simmons, 2022).

Figure 5.1 Visual representation of the MVC

Architecture

The Model, View, and Controller (MVC) architecture was chosen as the overall system design. This design
pattern is designed to separate the user interface (view), the data (model), and the application logic (controller).
The model component corresponds to all of the data-related logic with which a user interacts. This could be data
sent between the view and controller components, or it could be other business logic-related data, such as query
results returned from databases. View, on the other hand, is largely utilised for all of an application's UI logic.
CSS style sheets are also frequently used in conjunction with the view UI features, as will be addressed further
throughout this report. Finally, the controller serves as a bridge between the Model and View Components,
handling all business logic and incoming requests, manipulating data with the model component, and
communicating with views to generate the final output. The primary rationale for employing this paradigm is
that it encourages maintainability and scalability of an application. Because of the limited time available to
create a full report and prototype, future modifications of the Gole application are unavoidable. As a result, it is
critical that developers avoid tight coupling and code duplication. Ultimately, it makes it easier to modify,
extend, and reuse code.

5.2 Front-End User Interface

Because of the nature of productivity applications, particularly the regularity with which users interact with their
schedule, it is critical that users have a seamless UI experience with the Gole application. To achieve the
objectives outlined in Chapter 4, the sections that follow will discuss major UI design decisions using mock ups
to strengthen visualisation.
5.2.1 Login & Registration

Figure 5.2 Sign-Up Page Figma Mock up

Unless a user is already logged in, the login screen is the first interaction a user will have with the Gole
application. As seen in the wireframes, the logo appears in the upper right corner of both pages, followed by a
login form on the left of the login page and a signup form in the centre of the registration page. If the user
already has an account, they can input it in the text boxes or sign in via a third-party API, which in the deployed
version of Gole is Google. The prototype does not limit the number of incorrect details that a user can enter, but
it does display a red warning whenever the user's email or password is typed incorrectly. It is vital to keep in
mind that without a confirmed account, it is not possible to advance beyond these two pages. If a person wants
to create a new account, they can go to the registration page by clicking the link underlined "sign up." They are
then routed to a sign-up form that requires an email address and a password. Due to self-enforced database
limits, users must use a unique email address and will not be able to establish multiple accounts. Here the
application will also use red error messages if the email is in the incorrect format or the password does not meet
the basic complexity standards to deter potential brute force cyber-attacks. There is also another hyperlink at the
bottom of the page enabling users to read the terms and conditions of using the Gole application, satisfying
some of the LESP conditions described in chapter 3. Finally, users are directed to the login page using the
"Login" hyperlink in order to proceed to their home page.

5.2.2 Username & Type of user

Figure 5.3 Username and Type Of

User Pages Figma Mock up
The following pages are only displayed when a new account is created for the first time. Here the user will
enter a username into the textfield, which will also be an option for signing in, to attach to their account. They
are then redirected to the type of user page, where they will select the proper category choicebox reflecting their
aim using the Gole app. In doing so, the objective is that details about their intention would direct task
suggestions or encourage certain programs, such as a revision timetable for when exams are approaching in
future iterations of the Gole application.
5.2.3 Homepage

Figure 5.4 Homepage Figma Mock up

The home page is either the initial page the user is forwarded to after signing in or the page that follows after
they select the category to which they belong. The centre of the page is dedicated to listing the user's duties for
the day, as indicated by updating date at the top. As to their current tasks, users can execute CRUD actions. The
user can also alter their soft preferences or log out by clicking the menu button on the upper right (figure 5.5).
The homepage also has a Spotify component that suggests podcast episodes based on the user's profile. This
isn't a priority for the Gole app, but future iterations may be able to track users' goals and narrow down a
random selection of related podcasts for the user to enjoy. Finally, there is the side menu. There are multiple
hyperlinks here that will take you to various application windows. They are not all functional in the prototype,
but this will be explained in the preceding chapters. Labels near the bottom of the side menu under "current
projects" display the user's current projects, which can be cross-referenced by the task summaries in their to-do
list. It is expected that users will spend the majority of their time on this page.

5.2.4 CRUD: New Task

Figure 5.5 Creating a new task pop-up Figma Mock up

When a user clicks the "add task" button in figure 5.4, the pop-up window in figure 5.6 opens. In the "name of
event" text field, a user can enter the title of their task, and the description of the task in the text area directly
below. Other details such as data, time, and length can be chosen from the drop down boxes below the
description section, or users can leave the data and time blank if they want the GOLE program to identify a
vacant space in their schedule. The flexibility toggle switch will alternate between a red "non-negotiable" box
indicating that the task must not be reallocated to make room for higher priority tasks and a green "negotiable"
box indicating that the user would like it to move. Because the auto and flexible features are not as intuitive as
the others, there is text to guide the user's understanding underneath them. The user can also optionally choose a
label for the project on the bottom left, which corresponds to the list of projects in figure 5.4's side menu.
Finally, two buttons are provided to close the pop-up window: "Cancel" is used when you want to cancel or
make a task, in which case the task will appear on the homepage or in the calendar for a future date.

5.2.4 CRUD: Edit Task

Figure 5.6 Settings Figma Mock up

When a user selects a specified task, the pop up window shown in figure 5.7 appears. The user can conduct all
RUD activities from CRUD here. READ: Users can acquire more information on a certain task by seeing the
title at the top and the description straight below. Update: By selecting the edit icon, users can change the title or
description box, as well as toggle the same settings seen in figure 5.6, such as the flexibility and project label.
However, there are two additional features visible. 1) Users can assign a label to a job that reflects its urgency,
or choose a sub-label to a project, such as a study sub-label for one of the tasks in a full-stack programming
course. 2) The user can also set reminders by using the reminder drop-down menu at the bottom of the side
menu. This corresponds to alerts preceding the relevant event. Delete: Finally users can select the 3-dot menu
icon at the top of the pop up window if they’d like to delete, update or label the task as complete.
5.2.5 Calendar

Figure 5.7 Calendar View Figma Mock up

When a user selects "schedule" from the homepage side menu, they are taken to a calendar view of their
schedule. A familiar format is adopted. The time is displayed on the left side, with a blue line indicating the
current time of day. The day of the week is at the top, with tasks filling in the vacant spots in the middle as
appropriate. On the top menu the user can opt to do 3 things: (1) The user can change the calendar view from
day to week to month to year by selecting the 'change view" button on the top menu. (2) Select "Search
programs and integrate," which opens the community program box in figure 5.9, allowing them to add a new
program to their schedule. Finally, (3) the user can pick the "add task" button to open the pop-up window shown
in figure 5.4 to create a new task. Overall this window is a way for users to see their entire schedule from an
abstract perspective.
5.2.5 Community Programs

Figure 5.8 Community Program popup window Figma Mock up

When a user clicks the "community program" hyperlink, the pop-up window shown in Figure 5.9 appears. On
the display, users will be able to choose from a variety of programs to incorporate into their schedule. Each
component will provide the program's title and a brief description of what the program includes. Circular profile
pictures and cover images are also used to further identify the designer of the program and the activities featured
in it. The names of the current categories on the Gole system can be found in the left side menu. Clicking on a
title changes the programs displayed in the content box; for example, Sports & Fitness will only show fitness-
related programs. Clicking on a program leads to a new window as in figure 5.10
5.2.6 Community Programs: Program Summary

Clicking on a program on the community program pop up in figure 5.9 takes you to a window with program-
specific information. To begin, the title of the application is displayed at the top, along with the creator's name
and a profile icon similar to those seen in Figure 5.9. The program is described in full below, with the ability to
include graphics to depict what a user's schedule would look like once it is implemented. In addition, you can
search for a new template using the text field on the right side menu, which brings up the familiar community
program pop up box. You can also choose to incorporate the program into your schedule by selecting the "Use
program" button, in which case tasks will be assigned to each of your program's free time slots in the sequence
specified by the developer. Below that is a report on your progress with the present program. A circular loading
component signifies the completion of the software that you are currently working on. There are also
rectangular components that give the following metrics as a supplement: How many tasks are in the program,
how many have been finished by the user, how many are currently in process, and how many are still pending.
Finally, it estimates how long it will take the user to complete the software based on their existing schedule.

5.2.7: Soft Preferences

Figure 5.9 A program summary page Figma Mock up

When soft-preferences are selected from the settings menu, a pop-up window appears. The pop up in this first
iteration of the Gole program will prompt the user to select a desired "period" of the day during which they
would like to complete tasks. These times are as follows: morning, afternoon, and evening. Depending on their
choices, two choice boxes are enabled (they remain disabled until a period is picked) with all of the start and
finish time options for their chosen period. For example, if User A prefers to accomplish activities in the
morning, the start time can be between 00:00:00 AM and 11:00:00 AM, and the finish time can be between
01:00:00 AM and 12:00:00 PM. After making a selection, the user clicks "apply," and these preferences will
govern both the "auto" insert feature and how programs are tailored to a user's schedule.

5.2.7 Soft Preferences

When soft-preferences are selected from the settings menu, a pop-up window appears. The pop up in this first
iteration of the Gole program will prompt the user to select a desired "period" of the day during which they
would like to complete tasks. These times are as follows: morning, afternoon, and evening. Depending on their
choices, two choice boxes are enabled (they remain disabled until a period is picked) with all of the start and
finish time options for their chosen period. For example, if User A prefers to accomplish activities in the
morning, the start time can be between 00:00:00 AM and 11:00:00 AM, and the finish time can be between
01:00:00 AM and 12:00:00 PM. After making a selection, the user clicks "apply," and these preferences will
govern both the "auto" insert feature and how programs are tailored to a user's schedule.
5.2.7 Colour Scheme, Typography

44

Figure 5.11 Colour & text typography representation Figma Mock up

The colour scheme for this first iteration of the Gole app is very simple, mainly because it is not a priority. The
designer has opted to use a range of greys primarily because it’s an unemotional colour and dictates a state of
confidence or calm, both necessary traits when moulding another person's schedule. It is also a versatile colour,
so making unique modifications that are best represented by other perhaps vibrant colours schemes will always
match. The only additional colours in the system are a selected shade of red and green. Red is used to represent
everything that is unchangeable or final. One example is the "flexibility" options, which allow the system to
move tasks to make room for higher priority ones. Green is thus used to represent flexibility; a good example is
the auto button, which is clicked when a user wants the system to locate time in the schedule for them to
complete a task. The chosen font for the entire system is “League Spartan”. It’s modern, bold and aesthetically
pleasing geometrically, complimenting a system users are expected to utilise for a large portion of time.

5.3 Back-End: Data and Logic

The Gole application is currently constructed entirely within the Java ecosystem. As a result, the front-end and
back-end are seamlessly integrated and structured according to the MVC architecture. This was done primarily
because of the developers' current skill sets, but also due to the fact that OOP concepts are naturally expandable,
scalable, and flexible. Indeed, OOP employs polymorphism, which enables developers to code to an interface
that reduces coupling while enhancing code dependability and compatibility for future developers. In light of the
foregoing, the following will provide an abstraction of how the complete system's backend interacts with the
front-end. It is important to note, however, that the developers' limited experience with computer science, as
well as the limited time available to build and report on the system, means that knowledge of some of the API's
used is only on a superficial level and may not fully cover the extent to which it contributes to the fluidity of the
Gole application.
5.3.1: Login & Registration

As the entire systems front-end is built with JavaFX, notably FXML in the view layer of the MVC architecture,
the UI interacts with the controller classes and changes visually in reaction to its response. Here when a user
enters their login information, the controller class parses it and sends it to the Mode layer, which authenticates
users by checking the database for a match. This is made possible by a data-base API that allows developers to
enquire with familiar syntax translated to SQL on demand. Ultimately, users will either be redirected to the
homepage or stuck at the login or registration pages until a match is found.

Registration

Users must have a unique username for registration, which will be used to identify a matching account when
attempting to login. The matching keys are a username and a password. The system initially demands an email -
mostly so that subsequent iterations can authenticate users by contacting the registered email - which must
follow the basic email format, i.e. local-part@domin, where the local part can be up to 64 octets long and the
domain can be up to 255 octets long. When users seek to register an email, the database constraints ensure that it
is unique and, as a result, will not allow them to progress until a unique and syntactically appropriate email is
used. The password is subject to three main conditions: It must have at least one uppercase letter, one number,
and one symbol. Failure to execute any of the aforementioned will result in error messages informing the user
that their login details are invalid. If a user's information is accepted, an encrypted password and unique salt
(produced cryptographically at random) are generated for each user and kept in the database to be used to
authenticate the user when they login. This ensures that developers will never have access to the user's raw
password, nor will they be able to reverse engineer it using the salt.

Login

The controller & model classes capture the submitted username and use it to retrieve the appropriate salt value,
encrypted password, and user ID from the database. When the following circumstances occur, error messages
indicating problems with the email or password are displayed: The user provides a username that does not exist
in the database; the user enters a password that, when encrypted with the corresponding salt value, returns a
password that differs from the password contained in the database. On successful authentication, the user's ID
number is returned, used to load their personal information across the rest of the application context.

5.3.2 Home Page

The homepage must load all of the user's tasks that correspond with the current date. To do so the user's User ID
is retrieved on authentication and used to cross-reference tasks from the database. The result from the
aforementioned query will return a date column and based on this the rows whose dates match the current date
are returned and placed on the homepage whilst the rest appear in the calendar.

Side Menu

The only purpose of the side menu is to redirect or open popup windows. Hyperlinks will open the proper
window, such as the community programs window or the calendar, to accomplish this. Because this is a desktop
application rather than a web application, maintaining a consistent session across the board is tough. To avoid
this, controllers are manually created when the user needs to launch a new window. This allows you to transmit
information across objects just like any other Java program making it appear as though it is the same session in
the background.

5.3.3 New task

In order to create a new task, the model class will parse user inputs into the appropriate format for an SQL
query. Once the information is parsed appropriately, an “insertion” query is made that will store the user input
into a database ready to be reloaded onto the homepage and calendar.

5.3.4 Edit task

Editing tasks, like creating new ones, require the model classes to translate user inputs into "update" query
syntax before interacting with the database. However, in this case, the task ID linked with each job is used to
locate the precise row and column that has to be updated. Each task is functionally an object instance with
multiple values that are uniquely connected with it, and it is in this manner that the task ID number may be
obtained, first from the database. Changes to the database are also reflected in the homepage or calendar.

5.3.5 Calendar

The calendar view must load all of the tasks associated with the user - both past, present and future. To do so the
users User ID and a range of “select” and “natural join” queries are made to find, parse and load the users tasks
onto the calendar. The associated column values with each task will determine the dates, time and features on
display in the UI.

5.3.6: Community Programs

Courses in community programs must be displayed according to their categorization. To accomplish this, a
query is run to find the categorically relevant program, which is then parsed into instantiation objects. Each
object will then hold information about the application, such as the title and description, which the controller
class will take and provide to the display layer (UI). Searching for a program works in a similar way, matching
the user input with every course that has an associated word, for example, searching for "programming" will
naturally bring up any computer science related program. When an object/program is selected, it will open up
the community program summary window in 5.3.7 and be ready and loaded with the program's overall summary
and expected time of completion.

5.3.7: Community program summary

The community program summary, like 5.3.6, retrieves information from instantiated objects and displays it as
needed. The biggest difference is in the approximation values. A query must be conducted to seek for gaps in
the user's schedule based on the soft preferences selected in 5.3 in order to get the "approximate" completion
date. To do this, a database query is executed that accumulates the difference between task finish times until the
program's duration is reached. Based on the accumulated value (in minutes), a Java function will convert the
sum to the appropriate format - if the minutes do not exceed the hour window, it is displayed as minutes, if it
does, it is displayed as hours, and so on. The result is delivered to the view layer and shown to the user. A
comparable query will accumulate the number of completed tasks in the user's schedule (based on each task's
unique task ID and a completion boolean value), which can then be subtracted from the overall number of tasks
in a course to provide the tasks remaining to finish. Pending tasks are those that have yet to be finished but are
displayed on the home page, or those whose due dates have passed but have not yet been marked as complete.

5.3.8: Soft Preferences

Time intervals and times are not directly maintained in a database. Rather, these constants are part of the java
logic; when users select a time period, the java logic will load the relevant times, allowing them to specify their
window. Instead, when a user sets their preferences, a query will change a start and finish time in the user table,
indicating the window in which the system can enter new tasks. These are then loaded in the same way that any
other task is when connected with a user's ID.
5.4 Data Storage

As previously stated, the Gole program is significantly reliant on databases to function. As a result, it is critical
to select a solution that promotes rapid performance and scalability. The sections that follow will compare the
two primary options, SQL and NoSQL, database service providers, and lastly the justifications for using the
relational model PostGresSQL.

5.4.1 SQL vs NoSQL

SQL, which stands for "Structured query language," is a programming language used in relational database
management systems to handle and maintain data. In this context, relational refers to a database that stores and
provides access to data points that are related to each other (Oracle, 2023). Data is kept in rows and tables that
are linked in various ways, such as foreign keys, which impose the restriction that values in one column must
first exist in another. NoSQL, on the other hand, is non-relational, which implies it can store values in data
structures other than rows and columns. In this regard, it is a more adaptable approach to databases that supports
tailoring models to data rather than data to the model. These two techniques are best compared in three areas:
Properties, Scalability, and Structure

Scalability

Figure 5.11 Graphical representation of the dfference between SQL and NoQL

SQL databases are said to scale vertically. This means in order to increase obese server capacity you must
migrate to a larger server with superior CPU, RAM or SSD capability (MongoDB, 2023). It’s important to note
that this does not mean it cannot scale horizontally but the techniques to do so are not used often because of its
inferior capability: Sharding ,partitioning logic etc (Mukherjee, 2019). NoSQL, on the other side, excels in
horizontal scaling. It specifically enables sharding significantly better, by partitioning table data across data
storage nodes based on some unique identifier, eliminating the need to construct a relationship between other
data structures that may later identify that node for all data operations (Mukherjee, 2019). Even at scale, if each
node has a limited quantity of data to operate on, it is highly fast and efficient (Cattell, 2011). Furthermore
inexpensive commodity devices can be leveraged to expand the overall ecosystem's CPU and memory (Cattell,
2011).

Structure

As stated SQL databases organise data in a relational manner, using tables with columns and rows of records.
This means rigours organisation is often needed to structure data per the strictly predefined scheme before
starting with the SQL database. NoSQL is not relational and as such does not solely store data in rows and
tables. Some of the common data structures are: Key-Value nodes, Only Columns or Document Stores
(Mukherjee, 2019)..

Properties
Adopting SQL in an RDBMS requires adherence to four principles known as the acronym ACID. The goal of
this technique is to ensure that each transaction is executed successfully and does not jeopardise the database's
reliability. Atomicity requires that all transactions either succeed or fail fully. In the extreme, leaving
transactions partially completed can result in system failure. Consistency: The database must adhere to strict
standards that validate or present data corruption. Concurrent transitions cannot affect each other due to
isolation. Durability: All transactions are final and cannot be undone, even if the system fails (IBM, 2022).

Chosen Schema: SQL

A relational database was chosen as the best option for developing a working system within the project deadline.
The main reason for this is that the developer is already familiar with RDBMS, notably PostgreSQL, but has no
prior expertise with NoSQL databases. Furthermore, the data for this project may be organised into structured
tables with no issues about scalability with a prototype. This may be reviewed in future revisions of the Gole
program, especially since the amount of information required to store can grow exponentially, but in the short
term, this is inconsequential.

5.4.2: SQL Database Providers

There are numerous RDBMS providers available, including but not limited to MySQL, PostgresQL, and Oracle.
Initially, the developer planned to utilise MySQL because of how well the schema is integrated in the spring
boot framework, but this was reassessed due to the project's time frame, which skewed the risk-to-reward of
learning a new framework before constructing a solution. PostgreSQL was chosen as an appropriate option
because it is well-established within the Java ecosystem via the JDBC API.
Chapter 6: Implementation

The following details how the Gole applications research and planning evolved into a functional prototype. To
demonstrate this the development process was documented, with an emphasis on the primary features, the
challenges encountered and the solutions to address them. In order to do so effectively, each component's
codebase is organised with respect to the three layers of the MVC architecture.

6.1 Early Development

6.1.1 Deciding on a front-end development framework

In terms of the front-end framework there were three options to choose from: Vaadin, SprintBoot and JavaFX.
Vaadin is a web-application platform designed to allow users to build web-applications solely with Java as
opposed to switching to a Javascript web-stack. The problem encountered was that the tools offered mostly
focused on rapidly deploying business applications - these are applications that are predominantly composed of
forms and tables (Vaadin, 2023). Creating elaborate and custom UI to solve this would necessitate fine-grained
and direct access to the DOM, a skill beyond the developers current expertise and of little reward with respect to
the time allocated to the project. An alternative was Spring Boot. This is a well-known production grade
platform that simplified deploying Java based microservices and web apps (SpringBoot, 2023). Java as the
backend and Spring Boot as the front would have been an appropriate combination for an application like Gole
but the main issue once again was time. It was determined that the limited time was better suited to constructing
a functioning proof of concept as opposed to learning new frameworks. This resulted in relying on JavaFX.
Whilst it has been discontinued by Oracle, it still has a robust open source community and a plethora of tools for
creating bespoke desktop applications (Openjfx, 2023). The developer had also spent a large majority of time as
a student familiarising with this framework and thus concluded on it as the user-interface.

6.1.2 Data Storage

Initially the developer considered storing user tasks onto a text file and having the information filtered via some
Java logic before presenting them where relevant to users. This idea was quickly dispensed with and replaced
with a relational schema, PostGresSQL, for a number of reasons. The most important was ease of management.
Databases offer a structured way to store and manage data. They also provide CRUD operations, indexing,
querying, transition support and data integrity checks that text files fail to provide or require extensive code-
based logic to perform. They also offer superior scalability. Databases are designed to handle large amounts of
data efficiently. As the to-do list application grows and more users start using it to store tasks during the
prototype phase, a database will handle the increasing workload better than a text file which will ultimately
become slower and harder to manage with a growing number of tasks. Finally it is better at data organisation
and relationships. It allowed the developer to better structure the data, define relationships between tables and
enforce data integrity constraints using foreign keys. All of these are especially vital for an application that
intends to mould around its users.
 Figure 6.1 Gole Database Schema on PGAdmin4

As previously stated, PostGresSQL was used to create and manage the database. The relevant linkages and
integrity constraints are described below. It is crucial to note that the database was altered several times during
the development process, but for clarity, it will be explained in its entirety here.

6.1.3: Entities & Relationships

The table has 10 entities, each of which will have one of the 4 major types of relationship with another entity.
They are listed and described with their relevant ER relationships below

Figure 6.2 PostgresSQL trigger for the signup and login tables
Sign-Up

The sign-up table is in charge of saving the users' first login information before prompting them to create a
username. When a person creates an account, their email address and password are saved in this database. There
is also room for additional information such as their first name, last name, phone number, and so on, but these
are only placeholders for future editions. The "insert_signup_trigger" is the most significant component of the
Sign-up table, as seen in figure 6.2. Once the user hits finish, this technique will immediately insert the
registered user's username and password into the login database. Users can then immediately connect to the
application after being forwarded to the login page.

Login

The login table is used to authenticate user login details. The most important columns are: id, username,
password and saltval.

 The username and password combination are used in conjunction with the salt value to confirm
whether the inputted password and the encrypted password match.
 The ID number is a primary key to uniquely input or update a specific user's information. It is
referenced in a one - to - one relationship with the user tasks table for instance to map users to specific
tasks. It is also used to identify a users unique set of preferences in a one to one relationship with the
AutoPref Table

Tasks

Tasks stores all of the tasks created within the Gole application. There are numerous columns within the tasks
table, most of which are intuitive but the most important is course_id, label and task_ID.

 Course_ID is responsible for clarifying whether a task is uniquely created by the user or belongs to a
predefined collection of tasks in the course table. Course_ID is thus referenced as a foreign key from
the course table and they share a one - to many relationship.
 Label is responsible for clarifying the type of task being performed. It has a one-to-one relationship
with the tasks table since any given task can only have one label.
 Task_ID uniquely identifies a specific task. This ID number is used to map users to their tasks in the
user_task table so that every user has access to (and only to) their tasks. This is a part of a one - to one
relationship with the usertasks table since task_id exists only once in any given table.

User Tasks

User tasks are responsible for matching users with their specific tasks. It only has two columns: User_ID and
Task_ID. These have already been discussed above.

Course

The course table stores the programs available for integration into a users schedule. Each row will state the
course title and relevant descriptions concerning the course i.e. name, number of tasks etc. Throughout the
implementation section these will be expanded where relevant but the most important column is Course_ID.

 Course_ID is referenced as a foreign key in course_summary. It uniquely identifies a row of

information concerning a single course and thus has a one-to-one relationship.
 Course_ID also references a foreign key in coursetasks. This table lists the individual tasks associated
with a course. As a result they have a one - to - many relationship since courses can have multiple
tasks.
 Finally Course_ID is referenced as a foreign key task for reasons discussed above.

Coursetasks

Course tasks stores all of the tasks associated with a course in the course table. Each task is uniquely referenced
by a combination of course_id and task_id both of which are referenced by tables already mentioned.
AutoPref

AutoPref is responsible for storing each user's unique preferences. Those preferences are the time to start and
finish completing tasks and their personal burnout point. The only relevant relationship here is the one-to-one
relationship with the login table discussed above.

Label

The Label table stores the various labels to describe a particular task. It is not used as much in the application
context but is open to users for describing a particular task. The only relevant relationship is a one to many
relationship with the tasks table since multiple tasks can have the same label.6.3:
6.2 Overall Application Context

There are various functionalities of the Gole application that are almost always the same. Thus the following
will outline those features abstractly so as to not repeat them throughout the implementation section.

6.2.1: Pop-Up Windows

The process for opening pop-up windows is consistent. The only difference between some are the UI
components that need populating before the pop-up appears. These nuances are explained where relevant but for
the sake of simplicity a few examples below are shown and explained abstractly.
Pop-up windows appear on top of the caller window (i.e. the view & controller that invokes the window to
action), preventing all external interactions until its content is addressed. In figure 6.3 for instance, when a
button is pressed the homepageController opens a newTaskDialog window (pop-up window for creating a new
task) and the home page cannot be interacted with until this task is either stored in the database or cancelled.
There are various methods for determining the content of the pop-up windows but the developer decided to
design each of them in the scene builder and load the subsequent FXML files onto the pop-up. The Dialog Pane
in figure 6.3 for instance is instantiated but its content is obtained from the addTask.fxml file and then loaded
by the FXMLLoader class. In some of the pop-up windows the FXML files direct control may be referenced to
further define the windows content. This is discussed further below. JavaFX offers some default methods
associated with pop-up windows. In most of the pop-up methods the default cancel and apply buttons are
manipulated so that some behaviour can be implemented when pressed. For instance in the case of figure 6.3
when the cancelButton UI element is clicked, it closes the pop-up window.
6.2.2: New Windows

Figure 6.4 Exemplar method to open a new window.

As with a pop-up window, amongst numerous options the developer has opted to define the content of pop-up
windows in FXML files designed on scenebuilder. Thus the approach here is merely a simpler version of
opening a pop-up window. The first step is thus to load the FXML file, in this case the login page design, onto
an FXMLLoader object. A parent object frequently referred to as a root is then constructed to re-establish the
root window which in this context will now be the login page. Following that the stage intended to replace is
obtained via a new stage object and this is replaced with the new scene i.e. the login window. Finally using the
stage.show() method the window is opened and the caller method removed from cached memory.

6.2.3 Event Listeners

Figure 6.5: An anonymous event listener that was given a name handler to
make it more readable to others. This method goes into an initialiser.
 Figure 6.6: Another event handler that’s triggered whenever the logOutMenuItem
UI element is selected

One of JavaFX main features is event handling. Event handlers handle events generated by source nodes, such
as keyboard or mouse actions. Thus event handling is a mechanism that manages the event and determines what
should happen once it occurs. Because these notions are utilised regularly within the Gole programme they can
be discussed abstractly, focusing solely on the nuances throughout the rest of the implementation section.

Figure 6.5 and 6.6 present two types of event handlers used within the application but fundamentally they do the
same thing. Figure 6.6 depicts an anonymous inner class event listener that the developer abstracts into a method
from the initialiser for readability purposes only. It attaches a listener to the full taskListView UI element and
waits for the user to click anywhere on its surface. If the selected element is an item and that item is not null, i.e.
if they choose a list cell and that list cell is not uninhabited, the displayEditWindow() method will be called.
Figure 6.7 shows the other form of listener, called on an onAction event. Here any action taken on the
logOutMenuItem element will call the openLoginPage() method, which will send users to the login view. The
only difference here is that the UI element it’s listening on is not explicitly stated in the method itself and
instead passed as a parameter in the FXML code. Event listeners like figure 6.5 are used primarily when
business logic is performed on only one UI element, whilst figure 6.6 can be used on multiple UI elements so as
to reduce code redundancy.

6.2.4 Important Classes

There are various classes used throughout the application context that are vital for the overall application
functionality. The most important of these are discussed below so as to not repeat key details. These are:
taskItemClass and taskData
taskItemClass Class

Figure 6.7 taskData class in the model layer for interacting with the database

taskItemClass is responsible for temporarily storing user tasks. It is thus used mostly in conjunction with either
the data layer to store tasks into the database or with the view layer to display details concerning a task. Since
tasks can either take the form of a singular task or course task there are numerous class constructors within this
method. The only differences between them is that when a task concerns a course it also accepts a course_ID.
Finally the methods within this class are all getters and setters since business logic is separated pragmatically,
ultimately making the entire codebase more readable and intuitive.

taskData Class

taskData is wholly responsible for interacting with the database and as such makes up the entire data layer of the
MVC architecture. All of its methods involve one or more of the CRUD operations, supplemented by some
business logic mainly to protect the integrity of the database. There are numerous benefits to having the
database separated from the rest of the application logic via the taskData class but the most important is
separation of concern. Because taskData is only used for database interactions, it is isolated from the rest of the
application logic. Many of these procedures might have easily been included in the homePageController, but
separating them makes the codebase easier to maintain and comprehend. Another consideration is modularity
and reusability. Encapsulating data-related processes in one area made it easy to introduce innovations like auto-
insertion techniques or integrating programmes within a timetable without changing the rest of the application.
Finally, it is scalable. The developer was able to optimise and fine-tune code specifically for database
interactions by handling database activities through a distinct class. The findFreeTimeSlot() method, for
example, was streamlined to conduct two of the largest actions, auto insertion and the insertion of whole course
programmes, rather than rewriting unnecessary code - this is discussed further below.

6.2.5 Layout

The final contextual element to discuss are layouts. In javaFX the arrangement of components within a container
is called the “Layout of the container”. These are essentially pre-defined rules that guide the placing of all the
components at a particular position within a container. There are several layouts provided by JavaFX but the
main layouts used within the Gole application are the Gridpane and AnchorPane. When a GridPane is used all
the nodes that are added to it are arranged in a way that forms a grid of rows and columns. This layout is
particularly useful for clearly separating out UI element concerns i.e. A button and text field are logically placed
together in a cell, whilst a Logo might be placed on its own in another. Throughout the Gole application the
Gridpane is usually the parent pane with other layouts used on a micro-scale within the cells. The Anchorpane is
one of those layouts. The Anchorpane allows the edges of child nodes to be anchored to an offset from the
anchor pane's edges. Essentially this gives the developer free-range flexibility to place elements anywhere
within the Anchorpane sheet. The only drawback to this is that if misused it stops the layout from remaining
dynamic when resized by the user.

6.3: Login & Registration

6.3.1: Front-End
The final version of the Login & Registration pages perfectly resemble the design outlined in section 4 (see
figure 5.2). The login uses a Gridpane layout with two columns. The first contains a login form, whereas the
second contains a visual image. The text and password fields for the user login combination, buttons to
authenticate the user details, and a hyperlink to the registration page and terms and conditions page are the UI
elements in the login form. The registration page, ƒon the other hand, is divided into three rows. The first row of
UI includes a logo, error warnings, and a link to the login page. The second row comprises a text and password
box, while the last row contains further alerts and a button to register the user's information in the database. As
stated in section 6.2.5, the layout defines the arrangement of UI elements, hence an Anchor pane was utilised in
each cell to provide the developer complete control over the component placement. The sole disadvantage was
that when the user resized the program's screen size, the dynamism was lost. The thought process here was that
it was an acceptable trade-off for an early prototype but would almost certainly need to be corrected in a future
edition. Nonetheless, the developer chooses to restrict stage resizing by calling stage.setResizable(false). As a
result, the page's aesthetics remain consistent.

6.3.2 Back-end

The following will outline the functionality of the login, registration and authentication procedures. They will be
described in the order they were implemented.

Registration

Figure 6.9: The acceptUserDetails() method located in the signUpController class

(controller layer)
 Figure 6.10 Methods to check the strength of user login details

Between the Controller and Model layers, two methods must initially return true in order to register users: (1)
isValidEmail() and (2) CheckPasswordStength() (see Figures 6.10). (1) IsValidEmail is a straightforward
method that uses the EmailValidator class to enforce RFC 822 compliance on user-defined emails. This standard
specifies that a typical email address should include the following: Local-port: the part of the email address
before the "@" symbol that can contain alphanumeric characters, special characters and can be case-sensitive;
the "@" symbol to separate the local port from the domain port; Domain-Port: the domain of the email address,
such as a server or organisation; Period (dot) the second portion of the domain name, such as "google.com". (2)
CheckPasswordStrength() is derived from a developer-created Register class and employs a Pattern matcher to
determine whether the user password is at least 12 characters long and contains at least one uppercase letter and
symbol. If all of these conditions are met, the method returns true; otherwise, it returns false and prevents the
user's details from being imported into the database and proceeding to the homepage. Before the Model layer
contacts the database to import new user details, both of these conditions must be met. Here however, the
developer encounters the first challenge, which leads to the establishment of an encryption method.
 Registration Encryption

Figure 6.11 Data layer method that imports user details into the database

Figure 6.12 The first two images are the methods to encrypt user password before it enters the database. The last image is an
example of user details stored in the database post encryption

As noted in the preceding paragraph, there were two major challenges encountered at this time. The first issue
was one of security. According to the LESP in Chapter 3, privacy is a major legal and ethical problem with the
Gole application. Indeed, gathering personal information about the user, like an email and password, and
making it available to developers via a simple select query breaches the BCACP code that this service promises
to follow. To circumvent this, a form of encryption was created that precludes administrators or developers from
having access to raw passwords or the ability to reverse engineer them. To do so, an encryption class password
is required. If a user's email and password are sufficiently sophisticated, acceptUserDetails() (see figure 6.9)
passes them via another condition procedure called importUserDetails() (see figure 6.11). The password is then
passed via another method called hashPassword() (see figure 6.12), which returns the encrypted form of the
password before it is stored in the database. For a variety of reasons, the developers chose the Argon2ID key
derivation function as the hashing technique in the hashPassword() method. The first is that it won the password
hashing competition in 2013, which was held to pick a variety of password hash algorithms to be recognised as
industry standards. Second, the OWASP foundation recommends it as one of the few modern password hashing
solutions, and finally, Bouncy Castle provides an API integration that abstracts the hashing procedures.There are
two major steps from an abstract standpoint. First, generateSalt16Byte() will use a cryptographic number
generator to generate a secure salt value at random. This random salt will be used to make the hash more unique
and prevent hash attacks like precomputed hash tables or rainbow tables. Secondly further series of actions are
carried out in hashPassword(): The salt is produced in the manner described above; The Argon2
Parameter.builder object is then invoked with the desired Argon2 algorithm parameters, such as the version to
execute, the number of iterations, memory limit parallelism, and the created salt. The rawPassword is then
passed to the Argon2BytesGenerator, which converts it to bytes using UTF-8 encoding and places it in the
results array; eventually, the hash password is returned. Ultimately in doing so, by the time the
importUserDetails() method establishes a connection with the database the raw password can no longer be
inferred or reverse engineered, with the encrypted version and the relevant salt value stored instead. An example
of how users' details appear in the database is shown in figure 6.12.

The issue with using Third-Party API

Another option to prevent developers from inferring user details is to use third-party authentication services like
Google or Apple. Had the prototype been a web-application, this would have been simple to implement, handing
the responsibility to provide security to a third-party. However, the problem the developer encountered was that
third-party APIs are mostly designed and optimised solely for web application, and not a desktop application as
is the initial Gole prototype. Indeed, APIS like googles, are designed to be used in web-applications that run on
a browser environment. They rely heavily on client-side Javascript & HTML and thus don't offer the same level
of support or compatibility for standalone Java applications. To offer such services at this preliminary stage
requires sufficient work around and intermediate components to enable communication between the application
and API’s and thus the developer found that at this stage adding that level of cross-platform compatibility is not
a priority for a prototype.

Login & Authentication

At this stage, users were able to register an account and have their details stored in the database. The next
logical step is establishing a login procedure.

At the Login Controller layer, there are two key methods of concern: onLoginClick() and onInputType().
Similarly to the registration form, onLoginClick() is called whenever an action event matching the login button
is triggered. It then checks to see if the username and password text boxes are empty, and then proceeds to
authenticate the user using the Login Class's authenticateUser() method, which will be explained further below.
The only other function that is relevant in this instance is onInputType(). If users enter wrong user information,
a red error message shows at the bottom of the screen, as seen in figure 6.8. To remove this error code from the
screen, the onInputType function checks all text fields to determine if any new information is being entered and
then eliminates the error. This was done to provide consumers a subtle signal that the new set of details might be
included in the database, while only flashing a warning if it isn't. If the user is correctly authenticated it opens up
the Home page (see figure 6.14) per the openHomePage() method. To do so it creates an FXMLLoader object
that specifies the location of the file you're trying to open i.e. the FXML file that provides the GUI for the
homepage. It then changes the current scene, in this case the login page, to a new scene which would be the
home page and makes it visible to the user.
 Figure 6.13 Authenticating user login details by checking if its present in the
database

To proceed past the login or homepage, user information must be present in the login database. Because no raw
passwords are retained, the user's entered password must first be converted into its encrypted equivalent. To
accomplish this, the user's username is matched to its relevant salt value pair within the getUsersSalt() method,
provided the username already exists in the database. If a matched pair is identified, the raw password and the
salt value are passed through an overloaded version of the hashPassword() method, with the only difference
being that we send through a predetermined salt value rather than producing a new one. At this point the user's
entered password has been converted to its encrypted counterpart. This password version is then supplied as a
parameter in a database select query that searches for any usernames and passwords that match the user's input.
Under typical circumstances, the while loop should cycle once, saving the user's ID for future methods and
eventually returning true. There are only two circumstances in which the while loop either never triggers or
iterates multiple times, returning false: (1) More than one record was returned. This is more of a precautionary
approach in case the database's unique restrictions are deleted, which theoretically cannot happen. However, if
more than one row is returned, the break condition within the while loop is activated, which can only happen on
the second iteration of the while loop, implying several rows. (2) The user information does not exist. This can
happen if the user entered an incorrect password, resulting in a mismatched encrypted value, or if the user has
not yet registered their details. Regardless of the circumstances, the user will be unable to advance unless they
fix one of their login credentials or generate new ones.

6.4: Homepage

The homepage, new task dialogue, and edit task dialogue were all constructed concurrently. This is due to the
fact that several of their qualities interact in a circular fashion, relying on the advancement of one to continue
with the other. As a result, certain functionalities may be discussed without extensive context on the assumption
that they will be covered as the report progresses. This is done to make the report structure easier to comprehend
by describing each component one at a time rather than all at once.
 Figure 6.14 The homepage displaying the users current tasks and CSS Style sheets to
adjust behaviour of button pressing

6.4.1 Front-End
Homepage

The homepage's GUI, like the Login and Registration pages, largely resembles the earlier designs. The styling
of the task list view however is the most visible difference. The developer chose to leave the default task list
GUI because the prototype is a proof of concept and design is not a key emphasis of this project. The GridPane
was chosen as the overall layout, with two columns separating the side menu and the main tasklist display. Each
title in the side menu is a button that takes you to the relevant pages. These are then enhanced with CSS styling,
as illustrated in figure 6.14, to accentuate the button pressing and suggest that these titles can be interacted with.
The developer has utilised two labels in the second column to convey to the user that the current tasks belong to
the current date - with the backend guaranteeing the label conforms to the current date. The current jobs are all
presented on the listview component, each of which is an object displaying the title; however, this will be
discussed further below. Finally, there are two buttons that open new windows. The first is the "+ Add a new
task" button, which opens a pop-up window where you can insert a new task. The second button is the settings
button, which offers a drop down menu where the user can adjust their soft preferences or log out of the system.
6.3.2 Backend

Opening a new task window

 Figure 6.15 Method to open an new task window

One of the main functions of the homepage controller is opening a new task window when the “add new task”
button is clicked. Here the homepage controller interacts with the view layer by utilising an @FXML tag on the
showNewTaskDialog() method, the method intended to trigger once the button is clicked, and passing the
method as a parameters to a listener directly in the buttons FXML code. Once the buttons are clicked the method
first initialises a new dialog pane. A dialog pane in javafx refers to a pop up window that freezes all other
functions until the content within the pane is addressed. Preliminary details like the pane's owner (the
homepage), its title and the relevant FXML file (GUI for the actual task window itself) are also initialised but as
discussed in section 6.2.5 the generic structure of opening new windows and pop ups are the same. The main
issue that arose here is the next line, specifically the create and cancel buttons.

Figure 6.16 Method to open a new task window

The cancel and create task buttons' primary purpose is to terminate the task window and disregard any user
input, or to create a new task and pass its values to the model layer. However, because the homePageController
was simply loading the FXML file for the new task window rather than being in direct communication with its
components, its buttons were not listening to close/create events. Indeed, they were wholly new buttons from the
perspective of the homePageController, not the same buttons that had been referenced in taskController for the
cancel or control events. To get around this, I had to refer to the specific buttons from the dialogue window that
the method was supposed to open and apply listener events to them. To do this, the taskController, the controller
in direct communication with the components and responsible for the pop up windows user interface, was
initialised, and its buttons were supplied as references to the new create and cancel buttons (see figure 6.16). As
a result, whenever the taskController encountered a button press event, it was also encountered by the new
buttons because they referenced the same components. Figure 6.16 serves as a graphic demonstration of the
aforementioned issue and solution.
Populating the task list on the homepage

Figure 6.17 populates each cell of the list view with a users task

Figure 6.18 Method in taskData class primarily responsible to contacting the

database and storing their results within the respective classes
 Figure 6.19: taskData class Static method storing the usersID when they log
in to be shared amongst all instances of the taskData class

The current day's task is displayed on the homepage. This is accomplished through the use of two methods.
The first function comes from the taskData class and is called loadTodaysItemsListView(). This function
interacts with the database to retrieve all tasks for the current date that are associated with the current user. To
accomplish this, it creates a natural join between the userTasks and tasks tables (userTasks maps userId to
taskId, and tasks holds all tasks that are uniquely recognised by their task id, regardless of user).To identify the
user, the userId is stored in a static variable during the login phase and called upon by a getter available for the
entire application context (see figure 6.19). The current date is obtained from a system clock via the LocalDate
method. If there are corresponding tasks that match the aforementioned combination, the while loop iterates
through each row parsing every column value to the relevant variable. Before the while loop enters its next
iteration it will pass the collected values into an instance of the TaskItemClass, and store that instance into an
Observable Array List. At this point however the developer encountered an issue.

Figure 6.20: Observable array list storing all taskItemClass objects i.e. user tasks
Initially to display the titles of tasks on the listview, the developer had to iterate through the todaysItemLoad
(see figure 6.20) grab each task's title and set it as a cell value. This means that when users clicked on a cell to
view the details of a task, you'd have to run a SQL query against the database to identify the details of the given
task via its username. But this was problematic because it wasn't scalable if you have to communicate with the
database on every cell click and would cause errors if two or more tasks have the same title. To solve this, it was
necessary for each cell to reference an object as opposed to mere text. To do so the developer adjusts the
behaviour of the ListCell, an API tightly bound to the list view, specifically its reaction to cell clicks. By
overriding the updateItem method (see figure 6.21), the developer could instead pass instances of the
taskItemClass objects stored in an observable array list (see figure 6.20) and display the title representing the
object rather than storing the title itself with no reference to its object. This is visible in the populateListView
method (see figure 6.17), where the items of each cell corresponded to the taskItemClass instances in the
observable array list todaysItemsLoad (see figure 6.18), and the displayed text of each cell was taken directly
from the cell object itself, as seen in updateItem (see figure 6.19). Ultimately, each cell became an object,
including all of the parameters of the task to which it referred, without having to visit the database again or get
disoriented amongst tasks with the same title. Finally, to display the actual tasks on the listview, the
populateListView method is called on the initialiser method, triggered whenever the homepage window is
opened.

Display “Edit Task” Window

 Figure 6.22: Method to open the edit task window located in the
homepage controller

The edit task window appears as a pop-up whenever a cell item is chosen. The pop up window functions
similarly to the previously stated pop up windows, hence this aspect of the component will not be detailed. The
key distinction is in gathering and configuring values for the pop up window. Unlike a "new task window," the
edit task window must dynamically link its components to task data such as the task title, description, label, and
so on. To do this, two controllers must communicate: (1) the homepage controller, which opens the pop up
window, and (2) the editTaskWindow controller, which is responsible for the pop up window's user
interface.The first step is making sure both controllers are aware of the specific task selected. To accomplish
this, the static method "setTaskId" is called and passed the selected tasks taskId, making it available to all
instances of the editTaskController task (see figure 6.22).
This taskID is then used in

Figure 6.23: populateWindow() method located in the homepage

controller to populate the edit task window with the corresponding
task values

populateWindow() (see figure 6.23) in the editTaskController to find the corresponding task within the
taskItemClass observable arraylist and then set each component of the task window, e.g. title, duration, auto
value, with its corresponding taskItemClass object value - this will be discussed further in the
editTaskController section but for now it's important to note that editTaskController is directly responsible for
setting values onto the editTaskWindow itself. Returning to the homePageController, an instance of the
editTaskController is created, with each of its components referenced via getters and passed as values to dummy
variables within the homePageController, such as title = controller.getTitle.getText (see figure 6.22 second and
third images for examples). Since auto and flexibility buttons change colours based on their value rather than
displaying the value itself, the if condition selects which colour to display. If autoBool was true, indicating that
the auto button was pressed when the task was first created, the if condition proceeds to change the auto button's
background green. Otherwise, it's grey. Similarly, if the flexibility button was toggled on and hence true, the
button appeared green; otherwise, the button appeared red.

Homepage Current Date Label

Figure 6.24: The three methods used to format and update the date on the homepage so
that it corresponds to the users current date
The current date is displayed at the top of the homepage. Three methods are used to keep it up to date and
properly formatted. populateTodaysDate is the main function, and its sole purpose is to call the other two and
set the text onto the UI element todaysDate, which is a label with the current date. The first method employed is
getCurrentDateFormat(). This method initiates a LocalDate object with the current date, taken from the system
clock in the default time-zone. It then formats the given date as "day of the week, day of the month, month,"
which people find more visually appealing. It does this by combining the DateTimeFormatter object with a
string to reconstruct the date. Finally, after receiving a formatted date, the captilizeWords method converts the
initial letter of each word to uppercase. Because all spaces are immediately followed by a new word, it loops
over each character until it finds an empty space and capitalises the next character. The complete date is then
returned to the populateTodaysDate() method and set onto the UI element, which is displayed to the user when
the Gole programme is launched.

6.5: New Task Window

Whilst the new task window appears on the homepage controller, it has its own controller class. The following
will mainly describe how the controller interacts with the UI to display certain elements or details
6.5.1 Front End

Setting defeault values on the new task window

 Figure 6.26: The three methods used to format and update the date on the
homepage so that it corresponds to the users current date

There are three drop down interfaces to fill with values, as shown in figure 6.26. The datepicker is the first and
most basic. This element only has to be declared (i.e., a datePicker object is declared and placed in
scenebuilder), with JavaFX handling the rest of the UI and functionality. The setDurationTime method is
responsible for the two choice boxes that provide options for hour and minute durations to assign to a task. To
accomplish this, this method runs two "do while" loops, one for the hour choicebox and one for the minute
choicebox, beginning at 1 hour and 10 minutes respectively and increasing by 1 hour and 5 minutes
respectively. The while condition indicates that the longest hourly time a task can be assigned is 24 hours, and
the maximum minutes is 55. Because users can utilise both of them simultaneously, the maximum duration that
a task can be assigned is 24 hours and 55 minutes, which covers the majority of scenarios. For the sake of
simplicity and demonstration, certain default values have been assigned to and supplied as an array to the label
UI element. Finally, the handleToggleButton and handleAutoButton methods both change the colour of their
respective buttons when a user clicks them. Because they can only be one of two colours, the if conditions check
the current colour and replace it with its substitute before changing its boolean counterpart to true or false
depending on the option selected. For example, if the user wants the task to be automatically scheduled, the
button will be grey and then changed green, changing the boolean autoVal to true. All of the aforementioned
methods are called in the initializer() method, making the default values immediately available to users when
they open the new task window.

6.5.2: Backend

Storing a task in the database

When a user defines the objective of their task and clicks the “create button” the setTaskValues function
captures user task input and stores it in a taskItemClass Object. To do so it must first determine whether the user
wishes to have the task automatically scheduled. If the user does the first “if” condition is met, which loads the
users preferences from the database to assess whether the task fits within their preferences window. To do so
loadSoftPref() gets triggered. This method gets the users preferences from the database and saves them in a
softPreferences class object. The class is then called to ascertain the users start-time, end time and difference to
get the window in minutes.A series of temporary operators then check whether users have given the task a
duration in hours or minutes, defaulting it as 0 respectively on the occasion that they have not. In a similar
fashion the duration of the task is converted to minutes and compared with the window. If the task in minutes is
greater than the window and the user intends for the task to be scheduled automatically then an “Error” type
alert object is created to notify the user of the aforementioned error. They will not be able to move past this error
unless they change their window, shorten the tasks time or turn auto scheduling off. Once the aforementioned
pre-conditions are met or skipped, a set of code sequences collects and saves the remaining task components.
It’s important to note here however that some components of the task may change if it requires re-scheduling -
as shall be clear later on - such as the date and end time of the task. After the taskItemClass object has been
supplied its parameters, it is saved in the array of all taskItemClass objects (i.e. an array containing all of the
user's tasks). The method can then take one of two paths with these tasks. Either the task is simply saved in the
database at the stated time, or the Gole programme must automatically schedule a time slot. These two pathways
will be explained further below.
 Figure 6.27: Method to instantiate a new taskItemClass object before storing a task into
the database.

Pathway 1 (No Auto-Scheduler):The first path a task can take is an insertion query with the database at the
user-specified time. This indicates that the user did not pick the auto-button while creating their task, causing
storeToDoItem() to be called in the else statement at the end of the setTaskValues() method. The first goal of
storeToDoItem() is to find the task that the user wants to save in the database. To do this, an iterator object is
created, with taskItemClass as a parameter and the taskItemClass array referenced via iterator(). Iterating over
the reference object in this way (i.e. taskItems.iterator()) allows navigating among java collections to perform
read and remove operations easier. A while loop is then initiated and given the condition to continue iteration as
long as there are tasks to parse. The familiar prepared statement is then invoked and given an insertion query, as
well as a command to the bring forth unique key generated. In this instance, the keys are the taskID’s that will
be mapped with the users ID in the relationship table userTasks later on in the code block. The following if
condition is then a precautionary break condition, to skip any iteration whose taskItemClass object is a true auto
boolean. Indeed, at present the application is not automatically scheduling the task. Finally a series of code will
inject the task components into the insertion query. It is important to note that the endTime is set dynamically in
this case since the end time and date of the task can change depending on whether it exceeds the 24 hour time
range. To do this, a LocalDateTime object named "endDateTime" is constructed and initialised using the
taskItemClass object's date and time. The duration of the task in hours and minutes is also extracted from the
taskItemClass object and added to the endDateTime object. Finally, the code uses setEndTime() to set the task's
finish time within the taskItemClass object, and setEndDate() to set the task's end date. The toLocalTime and
toLocateDate() methods were used to retrieve the end date and time from the endDateTime object.

The developer chooses executeUpdate() to run the query. This is due to the fact that it returns the number of
rows that have been affected. If the number of rows affected is not exactly one, the query fails in some way,
either because less than one row was affected or because more than one row was affected. If the queries are
successful, the tasks are loaded into the database and the created key is gathered and stored in the variables
generatedKeys. This variable is then used, together with the userID obtained at the beginning of the procedure,
to map the query to the task in the userTasks table. This final step must be completed in order to properly link
users to tasks within the application context.
Pathway 2 (Using Auto-Scheduler): The second pathway means the user has opted to have their task
automatically scheduled. As a result, the condition in setTaskValues() triggers the findAutoItemInList() method.
It’s important to note at this point that the series of methods below could have all been in one method. But for
readability they were separated into logical components, making it easier for subsequent developers to improve
the codebase.

Figure: TaskData class method that searches the taskItemClass arraylist for tasks the user
wants to have automatically scheduled

Figure 6.28: TaskData class method that searches the taskItemClass arraylist for tasks the user wants
to have automatically scheduled

findAutoItemList() is important for distinguishing between tasks which require and do not require auto-
scheduling. Similarly to the preceding, it will traverse through the array with an iterator() and initiate a while
loop on the condition that there are additional tasks to parse. Within the code block a further condition stipulates
that If the tasks auto boolean is false, it will skip the iteration, and if it is true, it proceeds to the
findFreeTimeSlot() procedure.
Figure 6.29: TaskData class method that searches the taskItemClass arraylist for tasks the user
wants to have automatically scheduled
The largest procedure in the Gole application is findFreeTimeSlot(). It is the process of locating a time slot in a
user's schedule that is not only large enough for a task but also fits within the user's window. The main
developer rationale here is that the system must first bring forward tasks that fit within the user's preference
window, in order of start-time, either because the full task is conducted within it or because the task in question
finishes or starts within the window. Because the system does not allow tasks to overlap, the table returned is
assured to include time gaps where applicable. As a result, the application can iterate through the returned table
and determine whether the time between the completion of one job and the beginning of another is appropriate
for the user's tasks. There are also more circumstances to consider, but they will be broken down and discussed
where relevant.

The first overall step is to return a table that will reveal, if any, time gaps between tasks inside the user's
preference window. To do so, the user's preferences are loaded using the loadUsersPref() method, as before. The
prepared statement is then passed a select query that provides a joined table between task and user tasks where
the user_id matches the current session user and the dates match the date specified by the task; if not, it will
default to the system's current date. This table will only include rows with start and end times that fall inside the
user's specified window and the query sorts the entries by time, allowing temporal gaps to be identified and
assessed when appropriate.

A series of variables are then initialised and passed values. These will be explained where relevant but the
majority are intuitive by name.

Figure 6.30 Step 1 of the findFreeTime slot method. This section of the code returns a
resultset of tasks that fit within the users preference window.
The following step is to evaluate the state of the resultSet returned. If the first if-condition is not met, i.e. the
resultSet is empty, indicating that the entire window is available for task allocation, the overall method transfers
the job to the emptyWindow() method. This method accepts a taskItemClass object, the user's preferred start
time, date, an integer tracking recursion, a boolean indicating whether the task is a programme task, and finally
the resultSet itself. Because we are only referring to one job in this instance, courseTask will be null.
Check7days is an integer supplied into the findFreeTime slot to determine how many days the system has been
looking for free slots if none have been found on the current date. It will increment every time the date must be
changed owing to a lack of sufficient time gaps and will exit the recursion if no spare time is available within
the next 7 days. The rest of the parameters are self-explanatory.
 Figure 6.31 Step 1 of the findFreeTime slot method. This section of the code returns a
resultset of tasks that fit within the users preference window.

emptyWindow(): As previously indicated, emptyWindow() is called when no results are found inside the
specified window. The first step is to determine how long the task will take in minutes. The tic object's potential
time, end date, and finish time are then set using familiar code. The code then moves on to a precautionary if
condition that checks to see whether the task exceeds the user's preference window. If it is, it signifies that the
task will not fit within the window regardless of the day, and the user must adjust their settings. To force this
result, check7Days is set to 7 and findFreeTimeSlot() is called again. The break condition in findFreeTimeSlot()
is encountered during this recursive call, and it will quit all functions and notify the user via the alert warning
that their preferences must be modified. If this condition is not met, the user's task can be injected at the stated
time, and a method identical to storeToDoItem begins (see section 6.5.2). This time will be the start time of the
user's preference window (as indicated by the variable prefTime), as the developer believes all users will want to
complete tasks as soon as feasible). The only difference in the following insertion code is that a successful
insertion returns true, whilst a failed one returns false. This is done so that after the method finishes and returns
to the method caller, the entire programme is completed by writing a success message to the terminal and
exiting the findFreeTimeSlot () method (see the end of findFreeTimeSlot() in figure 6.29.). For the time being,
the try catch is omitted because it is irrelevant for single tasks, but this will be addressed when discussing the
insertion of entire course programmes.

Another option is that the initial result set returned only includes one row, implying that the first if condition is
met and so emptyWindow() cannot be activated. In this case, the procedure leads you to an if else statement,
which checks to see whether there is time before or after the task that will keep both tasks within the defined
frame. This method is called CheckSpaceBeforeOrAfterSingleItem() and it accepts the following parameters:
the tic object, the duration of the task, resultSet, recursive break condition, attempted date, and the id of the
course task, which is null in this example because course programmes are not yet relevant.
CheckSpaceBeforeOrAfterSingleItem(): It is critical to consider the variables here. doesItFit is a boolean that
will be used to indicate whether the task fits within the user's preference window before, after, or at all. The time
and complete time of the task within the window, as well as the user's specified start and end time, with familiar
calls to the softreference class and getters via the resultSet object. Using the aforementioned, the first if
condition checks to see if adding the task's length to the chosen start time will overlap with the single time
already defined within the window, as well as not surpassing the preferred end time. If this condition is met, the
tic object's time will be set to the start time of the preference window, and doesItFit will be set to true. If this
condition is not met, the else if condition performs a last check to determine whether adding the task at the end
time of the single task inside the specified window will not exceed the preferred end time. Similarly, if this
condition is met, the task's time will be set to the end time of the previous task, and doesItFit will be set to true.
The final section of this method then checks whether doesItFit is false. If it is, it increments check7Days, and
makes another recursive call to findFreeTimeSlot, now checking the next day.If it is not, the task will be stored
in the database using the storeCourseItemDB method, which works exactly as storeToDoItems (see figure 6.27).
Again, prevCourseID and findpreviusTime() are disregarded because they are concerned with whole course
programme insertions discussed later in the report; nevertheless, prevCourseID will be set to 0 if the insertion
does not concern a course task. As a result, it meets the if-else condition for storing the task (see the second to
last else statement on figure 6.31).

The final possibility is that the resultSet returns a table with multiple rows of tasks. Unlike the aforementioned,
this is handled by the findFreeTimeSlot() method itself, but future iterations could break this down further/

findFreeTimeSlot(): The first thing this method does is initialise a do while loop. Initially, it was a regular
while loop but the problem encountered was that the while condition (resultSet.next) would move the cursor
before the system gets a chance to check a time gap. This do-while loop then keeps track of the row number via
rowNum, incremented on each iteration. Then it checks to see if the row is the first task, and whether inserting
the task before the first row fits within the window. If this condition is met, it will set the time of the object at
the start of the preference window, and the date as the current date. It then proceeds to check whether it is a
course-task which it will not be on this occasion and stores the task within the database as usual via the
storeAutoItemDB method.

Figure 6.33: Database demonstration of the findFreeTimeSlot method

looking for gaps inbetween tasks.
 Always returns false in this example

Always triggered in this example

Figure 6.35: Section of findFreeTimeSlot() that searches for gaps

inbetween tasks

If the condition is not met, the programme looks for gaps in the timetable. To do so, it considers two rows at a
time, specifically the time difference between them, if any. They will be known as Row A and Row B. Row A
will always correspond to the endTime of the previous row. This is because the system is concerned with when
the task will be completed. Row B is the current row that the resultSet cursor is pointing at, and it is concerned
with the time it begins (see figure 6.33 for a graphic demonstration). On the second iteration, Row A is always
initialised within a try-catch block before the while loop condition is reached. Indeed, before proceeding to the
next row, it initialises prevEndTime with the endTime of the previous row. Thus, if prevEndTime is not null, the
programme proceeds to set the current rows startTime from Row B. This is represented by the variable
nextStartTime. The duration between Row A (previous row end time) and Row B (present row start time) is
then calculated using the next two lines of code. This time is then converted to minutes and fed into an if
condition. This condition determines if the duration between these two rows is sufficient to insert the task and
whether doing so will fit within the preferred window. Assuming it meets these criteria, it then determines
whether the assignment is a course task, although as previously said, this will be explored in section 6.6 Since it
will ignore this, it will be inserted into the database at the time referenced by Row B which was the endTime of
the previous task. On the occasion that it does not meet the criteria, the while loop will traverse to the next row,
thus resetting Row A and Row B to re-assess whether the task can fit into this new time gap.
If no time can be found in between tasks then the last thing the program checks is whether the task can be
inserted after the last task. Similarly to the first condition, this part of the code is only triggered if the cursor
points to the last row in the resultSet. It then captures the end time of that row in a variable named
lastRowEndTime. LocalDateTime variables are then initialised, one capturing the date and end time of the last
row and the other capturing the date and end time of the users preference window. It then proceeds to enter an if
condition that checks whether adding the duration to the end time of the current row - which in this case is the
last row - will exceed the preference window. If it does not, it proceeds to set the tic objects date and start time
to current rows end date and time and insert the record into the database ignoring the parts of the code that
checks to see if its a course task. If this also fails, the else statement will increment the “check7days” variable
and recursively call findFreeTimeSlot() but with the next date in search of space to insert the task.

Figure 6.36: Section of findFreeTimeSlot() that searches for a gap after

the last row within the window
6.6: Edit task window

6.6.1 Front End

The “edit task window” appears when a user selects a task from the task list view. This window gives users
complete control over task details. In many respects this aspect of the program is identical to the new task
window and as such not all of its code base will be re-explained (see section 6.3.2 on populating the new task
window). Indeed, like the new task window it has its own controller that ultimately defines the user interface
(how it collects and presents predefined values) and this is referenced in the homepage controller when loading
the window. The differences that will be discussed however are the additional options that are given here.
Specifically these are: A delete button and complete toggle button, the process of updating a specific task in the
database and finally refreshing the task list view to immediately reflect modifications.

Figure 6.37: Demonstration of the ‘edit task window” pop up and the options available to the
user

Figure 6.38 Unique delete button option in the

displayEditTaskWindow method within the homepage
controller

Delete Button

The UI design decision made in this case is straightforward. The delete button is a JavaFX button that can be
seen on the top outer left of the side menu. This button has a plain grey tone and the word "delete" written on it.
When a user clicks on the delete button, the code in figure 3.36 is deployed. Here an onAction lambda function
is mapped to the delete button waiting for user interaction. When the user clicks the button the first task is to
find the ID of the task selected and pass it to the model layer (i.e. taskData class) to find the task in the database
and delete it. This specific method functions as follows:

Figure 6.39 Method located in the model layer class taskData to find a task within the
database and delete it from memory

deleteToDoItem(): the deleteToDoItem method is simple. It takes the tasks unique ID and performs a delete
query on the tasks table where the task_id matches the task_id of the task selected in the tasklistview. Given that
there are no more rows to return other than the number of rows affected, this query is then carried out as an
executeUpdate() query. The number of rows that were impacted is then determined by the if statement. If the
number is greater than 1, the administrator will see in the terminal that the query affected more than one record,
which is against business logic. Given that task_id must be unique due to database restrictions, this is more of a
precautionary approach. If only one row is impacted, the deletion was successful. If no rows are affected,
however, it's possible that the task does not exist in the database and needs to be addressed by a potential
administrator. Finally, a removeIf() function named taskItemLoad is added to the taskItemClass list. This
function is a collection method that iterates over a collection rapidly in search of an item that meets a specified
criterion. The taskItemClass object whose task_ID matches the task_id supplied to the method is the condition
in this case. When this is discovered, it is removed from the collection to guarantee that all records of the task
are deleted.

Once control is returned to the method caller, the next objective is to refresh the tasklist view to reflect changes.
This is explained below

Refresh TaskListView

The developer's initial problem was that, despite updates in the database, the general application context would
cache loaded information that did not reflect changes. Indeed, the task list view either stayed untouched or
duplicated values (for example, during update queries). To remedy this, it was essential to first erase the
"cached" information before replicating the initialization process by reloading the user's personal task details. To
accomplish so, the tasklistview had to be cleared first. This is accomplished using a simple clear() method given
by the lists feature, namely taskListView.getItems.clear(), which clears each list cell. The model layer is then
invoked in order to load the specific users task objects into the taskItems lists. This is accomplished using the
familiar td.loadToDoItems() function, which chooses any tasks in the database that match the current session's
user ID as obtained during the login step. Finally, as detailed in section 6.3.2, the tasks for the current date are
precisely sought for in the database and placed onto the tasklistview.

Marking a task as complete

The completion checkbox button indicates whether or not the user has finished a given task. This is represented
by the JavaFX checkBox UI element, which displays a tick to signify completion or no tick to indicate
incompleteness. In order to track whether a task is complete or not various methods are employed. The first is
the checkTaskStatus method which is an anonymous inner class event listener mapped to the complete checkbox
element named taskStatus

Figure 6.40 Event listener that checks the status of the taskStatus checkbox
so that regardless of how many times its clicked its status is tracked ready
to be updates in the database

changeTaskStatus(): listens for changes in the value of the taskStatus checkbox. When the checkbox is
selected it returns a boolean value of true and false for when it is unselected. Subsequently the value of the
taskStatus checkbox determines whether the if or else statement is triggered. If it is true then it will contact the
model layer class task data and pass updateStatusOfTask a true value as well as the taskId of the current task. If
it is false then it will do the same thing but pass it a false value instead.

Figure 6.41 Method to update the status of a task in the database. Located in the taskData class
which is in the model layer.

UpdateStatusOfTask(): As previously said, updateStatusOfTask may be found in the model layer class
taskData. The method accepts the selected task's status and task_id. It then executes a SQL query to update the
task's status column with a corresponding task_id - either true or false. ExecuteUpdate() is then called, yielding
the number of rows affected, which in all cases will be either 1 to signal a valid update, greater than 1 to indicate
an update that is theoretically not feasible due to unique limitations on the task_id column, or less than 1 to
indicate no changes at all. In any case, the three possibilities are indicated in the terminal for an administrator to
correct if necessary.

Figure 6.42 A getter method from the taskItemClass class to get the status of the task. This
way the checkbox is already ticked or unticked on launch of the edit task window

The final relevant method is located in populateWindow in the edit task controller. All this section of the
method is doing is taking the status of the task from the task object itself and setting it on the checkBox UI
element. As a result whenever a user selects a task the status of the task is evident.

Editing an existing task

Figure 6.43: editTask() method located in the taskData class responsible for editing a
task the user has changed

editTask(): The editTask() method is called when a user clicks the "confirm" button in the edit task box. This
method, which is found in the data layer taskData class, accepts all potential user inputs as parameters. Most
frequently, users will change the description of a task or its due date. These parameters are then accepted, and
some java logic is executed to include the task's duration in minutes, as well as the task's end date and time. A
database connection is subsequently established, and an update query is launched. This query receives the
method parameters and locates the particular ID of the task in question. Because each job in the task list view is
an object to which a taskID is assigned via the class constructor, it was simple for the developer to match tasks
with their taskID (see section 6.3.2 for more information on matching tasks with their taskID). Similary to
storing a new task, a prepared statement accepts each of the parameters and executes the query within the
postgresSQL database and returns an integer, indicating to the developer on the success of the query. As long as
only 1 row is affected, it is certain that the update query was successful, an integer greater than 1 means multiple
 items were updates and an integer below 1 suggests no such taskID was found, both of which are failures and as
a consequence must be rectified.

6.6: Community Programmes

Figure 6.44 : The left is the community program pop up and the right is a summary of a particular program and the users
progress with the program thus far

The community program window is a feature that allows users to integrate predefined programs into their
personal schedule. Ideally these programs would be created and provided by endorsers or online course
providers but due to time constraints and software incompatibility the developer opted to create them himself.

6.6.1 Front-End

As can be seen in figure 6.44, the community program design closely resembles the wireframes presented in
figure 5.10. In the first pop-over, a familiar program directory appears. The entire frame here is a two-column
gridpane that separates a side-menu from the primary context of the selected category. Here however the only
category with courses to integrate is technology, but in future iterations users should be able to select a category
and have the courses filtered accordingly. In the 2nd column (primary content) each course is its own two-row
gridpane, with the first row displaying an image representing the relevant course and the second row its title and
summary. Since some categories can contain more courses than can fit within the frame ,a slider element is used
to store and filter through an endless number of courses for integration. Each of these courses are clickable
elements and as such selecting one of them opens the second figure, from figure 6.44, which is the course
summary.

The course-summary contains numerous UI elements, most of which are intuitive including: Labels for instance
to summarise the selected course or buttons either to redirect the user to the community program window or to
open the settings drop-down menu. The most important UI elements however are those in project details. Due to
time-constraints these are mainly placeholders, but ideally in future iterations users can see how much of the
program they have completed if they've chosen to integrate it and how much of the program they have got left to
complete. Using these statistics, the progress indicator will then provide a visual representation of the course's
completion. Finally, and most importantly, the “Personal approximate completion time” will tell the user how
long it will take them personally to complete the course, given their current schedule and preferences. These
aforementioned features are expanded on in the design section, with how they could function hypothetically
within the codebase.
6.4.2 Backend

As indicated in the introduction, it would be impractical to explain all parts of the system implementation due to
the vast scale of the Gole application. This is especially applicable here, because creating the community
programme and the course summary from scratch required creating multiple classes and isolating functions to
keep code readable. Thus, the following will concentrate on the most significant aspects of this feature, leaving
the more mundane to intuition.
 Program Directory: Initialising courses

To ensure dynamism, the courses added to the programme directory are taken directly from the database. This
means that if no courses are available, the programme directory will be blank. To accomplish this, all of the
courses had to be loaded from the database and stored as objects.

Figure 6.45 : The left is the community program pop up and the right is a summary of a particular program and the users
progress with the program thus far

There are three relevant classes to load course data and store them into objects. The first is communityPrograms
which is a class that stores a community program object and its relevant details, i.e. title, description, number of
tasks etc. The second is courseItemClass which is a class used to store the details relevant for display on the
program directory i.e. course image, title and summary and finally the data layer class taskData. To load the
courses from the database a familiar approach was used. In the taskData class loadCourses() sent a select query
to the course table and parsed the relevant columns into values that could be stored as community Programme
objects and then this object was passed as an element to the courses FXCollection.

Figure 6.46 : The left is the community program pop up and the right is a summary of a particular program and the users
progress with the program thus far
This collection of course-programme objects are then iterated through in a getData() method found in the
programDirectoryController - the controller layer responsible for the UI of the program directory. Within the
for-loop a courseItemClass is instantiated and passed the course name, course description, courseID number and
the relevant image from image file. To ensure each course was mapped to the correct image, the images are
stored in number order that corresponds with the courseID. Each of the courseItemClass objects are stored in a
List and returned to the following discussed initializer.

The next logical step is to initialise the ascertained course item objects onto the program directory before it is
opened. Each course object is added to a large gridPane to achieve the gridlike layout in the programDirectory
(see figure 6.44).

Figure 6.47: The initialiser method for the community program interface
Figure 6.48: Two individual method abstracted and called within the initialiser. The first clears all of the course data within
the Java context. The second sets course details onto the individual course boxes on that course program interface.

The initialiser's first action is to ensure that there are no items in the course lists that could cause duplication or
out-of-bounds exception errors. To do so simply, the first line of code in the initialiser clears the relevant course
list The list from the aforementioned getData() method is then passed as a parameter to a courseItemClass list.
Following that, it sets two integer values, column and row, which will be used to arrange the course items in the
programme directory. The for loop is then used to iterate through each course item in the course Item List -
filled in the aforementioned getData() method. Inside the for loop it first loads the courseBox.fxml file using an
FXML loader and assigns it to an Anchorpane. courseBox.fxml simply dictates the layout of each specific
course, which as aforementioned is a 2-row gridpane with an image on the top and description on the bottom
(see figure 6.44). courseBox.fxml personal controller is the courseItemClass controller and its setData() method
is then called to map the data from the course to the UI element displayed on the program directory (see figure
6.48). The method then checks if the current column value is equal to 3. If it is then the column is reset to 0 and
the row is incremented by 1. This ensures that the course items are displayed in a grid-like layout on the
program directory window. The Id of the anchorPane is then set to the course ID which will allow for easy
identification and access to the specific course item when loading its course summary. Subsequently the
anchorPane is added to the gridPane with the column and row values as its parameters - i.e. where the object
should sit on the grid. Next the gridPanes width and height are set to computed or preferred size values, which
here is of little importance since the developer has chosen not to allow users to resize the overall application
window size. Finally an event handler is added to each anchorPane so that when it is clicked the
openCourseSummary method is triggered accepting the id number of the relevant course, so as to fill the
summary window with its unique information.

openCourseSummary() is responsible for opening the course summary of the selected course object. It is also
the method that connects the programDirectoryController with the courseSummary controller, who is
responsible for the UI elements of the course summary in figure 6.44. In terms of opening a pop-up window it
functions exactly as aforementioned in section 6.2.1 and thus that aspect will be ignored. What is unique here is
how the code determines which information to set onto the course summary UI elements.
 Figure 6.49 Method to populate the content of each unique courses summary window.

Since each Anchorpane is given an ID number that corresponds with one of the objects within the
communityProgram list, loaded in the getData(0 method, initialising the course summary window with unique
information was simple. Here the method loops through the list collection of communityProgram object and
checks whether the community each iterations id number matches the anchor pane's ID number passed through
in the initialiser. Once a match is found, the title and description is taken from the communityProgramInstance
and is set onto the courseSummaryControlerl instance to be displayed once opened. As a result, each unique
clickable course item on the program directory leads to a courseSummary window opening with values
associated to the relevant course (see figure 6.44 for an example).

Program Directory: Auto-Scheduling Course Programs

After establishing how to initialise the programme directory with courses recorded in the database, the
developer needed to decide how they would be added into a user's schedule. To accomplish this, it was
determined that readjusting the current methods for auto-scheduling single tasks would result in less code
redundancy than designing a largely duplicated version for courses. To do this a few new conditions/methods
had to be added to each procedure. To begin, the programme must decide whether the activity being added is a
course task or not. This allows you to easily reroute the execution of the findFreeTimeSlot method based on the
context of the request. Second, it must ensure that the order of the course tasks is maintained regardless of where
 they are put. The following will explain how these two were accomplished, along with essential code excerpts
for emphasis.

Figure 6.50 : A data layer class that loads tasks associated to a course as opposed to individual tasks

Figure 6.51 : Method that iterates through the courseTaskItems array and only passes those tasks with a coursID into the
findFreeTimeSlot() Method.
To add whole programmes to a user's timetable, the user must press the integrate button situated on the course
summary (see figure 6.44). An onAction event listener is assigned to the button in the openCourseSummary()
method (see figure 6.49), which calls the integrateProgramIntoSchedule() method with the id number of the
selected course object as a parameter. This method then executes three successive methods. The first is
loadUserPref(), which simply loads the user's personal preferences to determine when and where jobs are
scheduled automatically. The second method is loadCourseTasks, which takes the course id and loads each task
into taskitemClass objects before saving each instance in a collection list. Finally, findCourseItemInList()
iterates through the previously mentioned collection, passing each task via the findFreeTmeSlot() method to
begin automatically scheduling each of the tasks. It should be noticed that when dealing with course tasks,
courseTask is supplied as true rather than false, ensuring that the function is aware that the job is part of a larger
course and hence must be scheduled in a specific order. This idea will be expanded upon more below.

Figure 6.52 : Method that ensures the pre-defined order of course tasks remains upon each insertion.

The findFreeTimeSlot() adjustments

As previously stated, courseTask is now returned as true, indicating that the work requiring scheduling is part of
a broader collection of tasks, namely the selected programme. The key change required here is a technique of
guaranteeing that the task entered does not come before any tasks from the same course that already exist in the
user's schedule. findPreviousCourseTime() is the method that achieves this. This method accepts the task's
courseID as well as the attempted date and time of insertion. It then runs a select query against the database to
find the most recent task in the user's schedule that belongs to the course and hence has a courseID. If such a
task exists, it saves the task's start and finish dates. It then checks to see if (a) the attempted insertion time is
equal to the end time of the most recent job in the schedule, in which case it returns true, or (b) the attempted
insertion time is earlier than the end time of the most recent task, in which case it returns false (see figure 6.52).
 Figure 6.54 : Recursive section of the findFreeTimeSlot() method that checks for gaps in the next day.

A true return statement means the method can proceed with inserting the task at the identified time triggering
the storeCourseItemDB method (see figure 6.53). This method functions like every other data storage method,
except it additionally stores the tasks order number and courseID. After it stores the task it continues to the next
task back in the method caller. A false statement indicates that the current insertion time will disrupt the task
order of tasks and thus trigger the method to continue looking for appropriate insertion times as done with single
tasks (see section
Figure 6.54). a course task in users database as long as it does not ruin the pre-defined order of tasks
6.53 : Storing

6.7: Calendar Figure 6.55 : Calendar user interface

When a user clicks "Schedule" on the side menu on the homepage, they are taken to a calendar interface (see
figure). This is where consumers get a broad overview of their entire programme rather than just a single day.
Figure 6.49 illustrates the majority of the primary capabilities accessible on the calendar interface, however
some notable functions that are missing are: a PDF document of your tasks for a specified date or range of dates,
a search function to identify specific tasks, and a variety of calendar sources.
 Figure 6.56: openSchedule is a method located in the homepage controller for opening the calendar
interface. For a detailed explanation of how these type of methods work see section 6.2.1 on event
listeners

6.6.1: Frontend

Once a user selects the schedule button on the side menu, the controller is relieved from the homepage controller
and handed to the calendar controller. This is because the calendar controller controls the user interface of the
"calendarView.fxm" fxml file that the openSchedule method invokes.

Here the calendar framework used by this application, known as calendar fx, is an open source tool specifically
designed for JavaFX. By incorporating this framework into the project and including its dependency in the POM
file, the developer was able to utilise a variety of professional custom controls provided by calendar fx. While
not all of these controls were utilised in this particular application, their availability added an extra layer of
functionality and customization options for the calendar interface. As JavaFX supplies the UI for the calendar
interface, the developer's only task for the front end was to arrange it in an appropriate container. Because the
side menu was required for navigation elsewhere inside the programme, the same gridpane structure as on the
homepage was employed, with two columns separating the primary content and the side menu. The calendar
interface was then placed and measured to fill all available space in the second column.

6.6.2 Backend

As previously stated, many of the controls provided through the calendar interface were not used in this
application since an MVP should focus only on the most crucial functions. One of those crucial functions is
having the user's tasks loaded onto their calendar. To do so it was first necessary to allow communication with
the database to retrieve the users personal tasks.

Figure 6.57: Method to load the users tasks into a new observable list for the calander interface
As aforementioned, during the login phase, the model layer collects the user's userID() and stores it as a static
variable, making the user's individual tasks available to all instances of the taskData class. The method
getTaskItemsLoad() is thus referenced by a global observable list variable, which is initialised whenever the
user selects the schedule button from the side menu. This variable is then utilised in the calendar controller's
getTasks() method, which iterates over the list in search of taskItemClass objects. A while loop is set up using
the familiar iterator() function to iterate through each tic object in the list. The Entry class is the important
concept in this while loop. In calendar fx, an entry represents an event or task that can be added to the calendar.
This data structure can contain information such as a task's title, start and end time, and an ID to identify the
task, which is ideal in the context of the Gole application for determining which object to call when you choose
an entry on the calendar. For each task in the userTasks list, a new entry is created, with taskItemClass given as
the type of objects that can be placed on the entry. After creating the entry, the task's start and end times are
specified using entry.SetInterval(): the start and end times of the interval are determined dynamically by adding
the duration to tic.getTime. The task's title is then set using entry.SetTitle() and entry.setID() is used to set the
tasks ID - this will be useful later on to identify the object and retrieve its individual details when a user picks a
calendar entry. Finally the newly produced entry object is added to the calendar via the calander.AddEntry
method, ready to be utilised as a possible calendar source to display on the interface in the calendar controller
later on.

The next natural step was to display the task entries directly on the calendar. It was straightforward to do so.
Calendar source is a data structure that represents a calendar source. It could have several calendars, each
indicating a particular timetable or group of activities. The developer has chosen to include only one source in
this application, which includes all of the users' task entries, but separating those tasks apart is feasible, maybe
with course tasks in one source and personal duties in another. The term "calendar view" refers to the UI
element that presents the calendar to the user. Logically, this might potentially include one or more calendar
sources, each representing a unique set of calendars. By calling getCalanders().add(calendar) on the
calanderSource variable here, the calendar with all the task entries - via getTasks() - is made available as a
source of entries. Then by calling getCalanderSources.add(calanderSouce) on the UI element calendar view
those tasks are then added as a source for the user's personal calendar interface.

Figure 6.59: Method to load the calendar filled with user task entries onto the calendar interface

Figure 6.60: Initialiser called when the schedule button is clicked to load the users calendar

Finally these two methods are called sequentially in the initialiser to ensure seamless operation each time the
user clicks on the schedule button.
 Figure 6.61: A method for opening the familiar
taskEdit window whenever a user selects on a
task entry on the calendar.

Edit tasks via the calendar interface: Model and Controller Layer

The next objective was to give users the option to edit tasks while still in the calendar interface. The difficulty
here however was that calendarFX already provides a seamless pop-up interface or when users click on calendar
entries. Thus, the developer decided that it would be preferable to alter this default pop up rather than create a
brand-new one. CustomPopOver() was developed to achieve this. The procedure starts by loading the
"editTaskWindow.fxml" FXML file with an FXML loader. This is done so that the pop-up window's look and
layout blend in with the rest of the Gole application. Then, using getController(), it retrieves the FXML file's
root element and assigns it to the variable edit. The method then establishes a callback function, which is just a
function that is supplied as an argument to another function and performed when that function is finished or
when an event occurs. Here the event is clicking on an entry. Inside the call back function it iterates through a
list of taskItemClass objects to find the task object whose ID corresponds with the ID of the entry, specified in
the getTasks() method (see above figure 6.61). As shown in section 6.3.2, the populateWindow function from
the editTaskController is called once the appropriate object has been located. This method populates the custom
pop-up window with the details of the selected entry. Then, it assigns the appropriate behaviour after retrieving
a reference to its confirm, cancel, and delete buttons from the editTaskController. These are as follows:

cancelButton: If the user clicks the “cancelButton '' then the lambda function triggers the closeWindow method
passing the cancelButton as a parameter. closeWindow is a simple method that grabs the scene of the button it's
passed and hides it. This way only the edit window of that entry is closed.

confirmButton:It is presumed that the user has modified certain task-related details if they click the
"confirmButton" after selecting a task. This method accepts the button, the taskItemClass object, the id number
of the entry as parameters. Within saveDetails a sequence of familiar actions are performed. Similarly to
storeToDoItems, the details of the task are taken from the user's input in the relevant UI elements. Examples are
the task description, if it has been changed, dates, times etc. Once these are all selected, the relevant variables
are passed as a parameter to a taskDate method called editTask (see section 6.6). As a result that particular task
is now updated in the database.

The issue that arose here however is that the calander would not reflect changes made once the user pressed
confirmed. This was despite changes being made in the databse. The developer found that this was because the
calendar view was not calibrated to listen for changes on its entries – instead only adjusting them on
initialisation. This meant that even thought tasks were altered, they were not immediately reflected in the
schedule unless users refreshed it by opening a new window and reinitiating the calendar by selecting it from the
side menu. To circumvent this the developer created a method that imitates an “update procedure to fix this. The
final method called in saveDetails, updateEntries(), was invoked in this instance.
 Figure 6.62: method for updating the calander view when a task is edited

In general, updateEntries() works by re-uploading the tasks to reflect the updates after clearing the entire
CalendarView. In order to achieve this, it first loops through the calendarView in order to store a reference to
each of its calendars in a variable called cl. The calendar is then cleared, and this process is repeated for each
calendar in the display. Then, it performs the identical action for each of the calendarSources. It then does the
exact same for each of the calanderSources. After the for loops, the userTasks list and any residual calendar
sources or calendars are then cleared out as a precaution. This will prevent duplicate jobs from appearing in the
list when they are reinitialized. The final step is to carry out the same initializer actions, which include loading
the tasks from the database, adding them to the userTasks list, and adding them to the calendar. Every time a
user modifies the specifics of a task, the illusion of an update is thus performed in a split second.
6.7 Burn-Out Notification

The burnout notification is one of the more simpler parts of the entire system. Here the user is told how many
hours of tasks they are scheduled to perform in the day and week every time they add a new task or integrate a
new program into their schedule

Figure 6.63: Example of a burnout notification triggered whenever a user inserts a new task or course
program
6.7.1 Front-End

Figure 6.64: Method to modify UI of the default notification pop-up

Unlike the other UI components of the system, the notification class's default UI is used here. Instead, the
developer modifies the text, title, visuals, and behaviour. To accomplish this, the developer uses the
Notification.create() method to construct a notification object. It then specifies the title, text, graphic (image),
location (top-right corner), owner (the stage of the UI in this case is the homepage controller), and style class,
which is a plain grey background colour. Lastly it displays a terminal message every time the notification
function initiates successfully for administrative purposes. The following will expand on the content of each
variable.

6.7.2 Backend

Figure 6.65: Settings window to adjust the users burnout rate

Event listener

Figure 6.66: Notifications listner waiting for a user to click the confirm or integrate button when inserting
tasks or courses into their schedule.

The notification is triggered every time a new task or program is integrated into their schedule. To do so the
developer simply opts to trigger the createNotification() method whenever the create button is clicked in the
new task window or the integrate button is clicked in the courseSummary window (see figure 6.66).
Notification Object

Figure 6.67: CreateNotifications() method located in the notifications controller. This method passes
different values to the notification depending on how many tasks are in the users schedule

The createNotifications() method must first collect a user's personal burnout preferences, then determine
whether the user's current schedule is approaching the threshold before presenting an appropriate warning to
encourage either slowing down or the confidence to add further tasks to their schedule. To do so the user must
first get their personal preferences.
Since the intialising the burnout combo-boxes work exactly the same as initialising values in the duration hour
and minute combo boxes in the populateWindow method, selecting values and having them stored will not be
re-explained (see section 6.3.2). Abstractly however the user's input is taken and stored in the relevant columns
within the autoref table, just as the start & end times are, and when loaded are stored onto the same
softPreferences object to present to the user within the settings menu.

Figure 6.68: Method to accumulate in minutes amount of tasks scheduled to perform on the current date and
for the current week
After the user's personal preferences are collected, the amount of time allocated to tasks on the current date and
weekly thus far must be collected. To do so the task data method getUserWeeklyOrDailyTasksDuration()
method is employed.

Getusersweeklyordailytasksduration(): This method accepts a single value which in this case can only be two
things. “w” for weekly and “d “for daily. Using these values it will then determine which query to execute but
either way both queries return a resultset of tasks: for the daily tasks associated with the current date and weekly
tasks set for the current week. To get the correct tasks for the week it was necessary to apply some java logic
that would figure out what the first date of the week is. To do so it first initialises the current date using the
localdate class method . Now(). Then it retrieves the temporalfield for the day of the week in iso format - i. E.
Fields of date time such as year, month, day etc - from the iso calendar system. The firstdayofweek.
With(dowfield, dowfiled, range(). Getminimum(), statement then sets the day of the week of the firstdayofweek
variable to the minimum value allowed by the dowfield. This effectively sets the first day of the week and is
passed into the prepared statements for the weekly burnout period. Using the temporalfield in this way was
useful because it allowed the developer to manipulate the dates by specifying individual date fields (such as the
day of the week) without changing other parts of the date. Lastly from the resultset returned, the duration of
each task is accumulated and returned to the method caller.
Now that the preferences and currently duration of daily and weekly tasks have been accumulated these values
must now be presented to the user in a useful way.

Figure 6.69: The two choices of graphics to pass to the notification pop up. The right is initialised when the
users burnout rate is approached whilst the left is intialised when the user has adequate time to insert new
tasks

The method createNotifications() then proceeds to initialise the title and warning message depending on how
much time the users has thus far allocated to tasks. If the value is 3 hours off their specified burnout range for
the daily and 5 hours from the weekly it will encourage the user to prioritise taking breaks in between tasks.
Otherwise it will inform the user that they can still reasonably allocate themselves tasks for the day or week. A
graphic image is also attached, whose only purpose is to reinforce the warning message, with additional width
and height preferences. These two images are shown in figure 6.69. Ultimately these variables are passed
through the notifications object and displayed whenever a user adds a new task or integrates a new program into
their schedule.
Chapter 8: Testing

Software testing is an integral component of software quality assurance. Defined as a “process of executing a
program with the goal of finding errors” (Jovanović, 2009) the following section will determine the probability
that the Gole application will experience undesirable events. To accomplish this, three types of testing were
used: unit testing, component testing and system testing. Testing in this order, means the system has been tested
in totality from an isolated unit of code to the entire network of interacting components.

8.1: Unit Testing

Unit testing the act of exercising a unit of code in isolation and comparing its actual with expected results
(Dorota Huizinga and Kolawa, 2007). In Java, the unit is usually a class, which will invoke one or more other
classes to produce observable result. The biggest advantage of unit testing is early bug detection, since issues
can be caught and addressed quickly from their individual units before it becomes problematic to fix once it’s a
part of a large component. To do so the developer employs whitebox testing which can be defined as testing
software with the knowledge of the internal structure and code inside the program (Jovanović, 2009).

8.1.1: Unit Testing: Strategy

White Box testing was employed because the developer would have complete visibility and understanding of the
internal workings of the software. This made fault localization easier since the developer could pinpoint exact
location of defects or failures within the code, particularly since the code was isolated in this instance. Dummy
data was also generated and stored in a dummy.sql file to quickly retrieve test cases

On completion, each unit of the Gole programme was tested and recorded in table 8.1. However, because the
codebase contains over 3800 lines of code, not every test case is shown below. Instead, some of the more crucial
aspects are sampled, providing readers a general notion of how functional the system works.

8.1.2: Unit Testing: Results

Test Number Test Expected Outcome Actual Outcome Results

1. The system should An new-task As expected the new Passed

compile and window that task window pop-
initialise the new- resembles the over opens with the
task window screen wireframe in figure relevant UI
once a user selects 5.6 appears, for elements.
the “add new task” users to enter details
button about the task

2 The user types in a The system should As expected users Passed

title and description allow users to input can input an infinite
for the task large amounts of about of text into the
text concerning the relevant title and
specified task. description boxes.

3 The system should A small calendar As expected a Passed

open a calendar interface opens miniature calendar
interface for users to when users select interface pops up for
select a date for a the Date UI element users to select any
task in the new task date irrespective of
window. day,month or year.

4 The Auto Button is The AutoButton As expected the Passed

selected to either toggles between button toggles
 turn it on or off grey and grey to between a grey and
indicate that the greenshade to
system must auto- indicate that a task
schedule a given must be auto-
task. scheduled or not.

5 As above but with The flexibility As expected the Passed

the flexibility button button toggles button toggles
between red and between red and
green to specify the green infinitely.
priority of the task

Table 8.1: Results table for Component Tests conducted on the new-
task pop-up.

Test Number Test Expected Outcome Actual Outcome Results

1 The system should The system redirects As expected the Passed

compile and users to their calendar interface
initialise the personalised opens similar to
schedule interface calendar. figure 5.8 either
once a user selects filled with tasks
the “schedule” corresponding to
button on the side- their user or empty
menu due to no tasks.

2 The system should If the user has tasks As expected all Passed
display the current scheduled for the tasks for the current
date's tasks. current date, those date are visible to
tasks should be the user.
visible on the first
calendar screen,
labelled with their
title, date and time

3 The system should If a user begins to As expected the Pass

filter tasks to the type “I” for instance search bar functions
contents of the all tasks with titles correctly and
search bar and that match are displayed expected
display the results displayed as results. results
underneath as
clickable list items.

4 Changes to the If a user replaces As expected “Buy Pass

search bar are “ask” with “mask” mask from aldi” was
immediately then “Buy mask added to the search
reflected in the from aldi” would be results
search results added to search
results

Table 8.2: Results table for Component Tests conducted on the new-
task pop-up.
8.2: Component Testing

Component testing can be a form of black-box testing, which unlike unit testing evaluates the behaviour of the
program without considering the details of the underlying code. However since a form of user-testing will be
conducted in isolation, component testing will also be conducted like unit-testing in the form of a white-box.
Ideally, here the developer would like to demonstrate that the component interface behaves according to their
specification, replicating real-life scenarios and testing the system against those scenarios from a user’s
perspective.

8.2.1 Component Testing: Strategy

Component testing is classified into two types: component testing in small (CTIS) and component testing in
large (CTIL). CTIS is evident when a component can be tested in isolation without other components, whereas
CTIL occurs when a component cannot run in isolation from other software components - for example, if there
is a dependency on the functionality flow of the components and thus we cannot isolate them (Shekhar et al.,
2023).

As with Unit-Testing this was conducted after every major component was completed and recorded in table 8.3.
Since there are numerous modules within the application not all of them are presented below but a sample for
both CTIS and CTIL is provided, giving users an overview of the quality of the Gole application.

8.2.2: Component Testing: Results

Test Number Test Expected Outcome Actual Outcome Result

1 A user enters a The system should The user is correctly Pass

correct username redirect users to the redirected to a
and password homepage display homepage that
combination and (see figure 5.4) contains their
presses the login unique set of tasks if
button. any are scheduled
for the present day.

2 The system flashes a A red warning A red warning is Pass

red warning if the beneath the login correctly displayed
username and button at the bottom below the login
password of the screen. button suggesting to
combination is false. the user that either
the username or
password are false.

3. The user selects the The user is The user is correctly Pass
sign-up button redirected to the redirected to the
sign-up page with sign-up page to
UI elements to enter register a unique set
an email and of credentials to
password register an account.
combination to
register an account

Table 8.3: Results table for Component Tests conducted on the login
page.

Test Number Test Expected Outcome Actual Outcome Result

 1 The user clicks the A drop down menu The drop down Passed
“settings” button to appears immediately menu opens
select an option giving users the correctly giving
from the drop down option to either open users the
menu the preference aforementioned
window or log out options

2 User selects the The soft-preferences The pop-over Passed

auto-preferences pop-over window is window opens
option on the opened as shown in correctly with all the
settings drop down section 5.2.7. It has relevant UI elements
menu. various choice
boxes, the first with
the periods of the
date, the next 2 with
start and end times.
There are also
buttons at the
bottom of the pop-
over to cancel or
apply changes. Each
section of UI
elements has a
description box.

3 User selects the A pop-up window As expected the task Passed

“add a new task with various options window shown in
button” to provide details for figure 5.6 opens.
a new task appears.

4 The user selects the The user is As expected the user Passed
schedule button the redirected to a is redirected to their
side menu calendar interface personal calendar
similar to the with all of their
wireframe in figure tasks available.
5.8 displaying their
tasks.

5 The user selects the A pop-over window As expected the Passed

“community opens with the “community
programs’ button relevant community programs” window
the side menu programs available similar to figure 5.9
to choose from. appears with an
empty search box to
specify the name of
a program.

6 The user selects a A pop-up window The relevant pop-up Passed

task displays the task window opens as
details, along with expected.
the relevant UI
elements to further
customise the task.

8.3 System Testing

System testing assesses how well the various components of an application interact once a fully integrated
system has been constructed. This is the logical next step after component testing before conducting a black-box
test with real-life users. The developer had three key objectives in mind when testing the integrity of the Gole
application: (1) End-To-End Testing: This entails testing the Gole application to see how the various
components interact with one another and with the system as a whole. (2) Pre- and post-conditioning to test each
input in the programme and ensure the expected outputs; (3) Testing the user experience with the application.
Since users are specifically assessed in a separate user-experience section only the first two sections will be
evident within the following.

8.3.1: Strategy

System testing was conducted after every major component was built but the most relevant was the testing
conducted once the entire project was complete. To do so two user stories were created - for convenience the
users are named Loic & Mathew. Loic is looking to pass his personal work schedule into the system and have
tasks and community programs scheduled around it. Mathew on the other hand would just like to use the Gole
application as a to-do list, at times auto-scheduling tasks. The following two tables explore their journeys from
the onset, noting whether or not the desired actions were achieved.

8.3.2: Results

As previously stated, the two user-stories that follow cover two sorts of users who may utilise the Gole
programme. By doing so, all of the system's functional criteria are tested, ultimately evaluating whether or not
the prototype is a viable MVP before building a deployed version of the application.

Step Step Details Expected Outcome Actual Outcome Results

Number

1 Open the application The login page As expected the Pass

should open user is unable to
immediately and proceed past the
allow no redirection login page unless
to other pages they enter the
unless the user has a correct details or
valid login or wants attempt to register
to register a new
account

2 Log into the application The users username As expected the Pass
and password user is redirected to
combination is their personal
cross-referenced in homepage but the
the database. If the current date was
user exists they are empty as they were
redirected to their yet to pass in any
personal homepage. task items

3 Press the “add a new task” The “new task As expected the Pass
button window” pop up user was able to
window should begin entering task
appear in centre of details onto the pop-
the screen up window.

5 Select the apply button The task should be As expected the Pass
stored and mapped users work schedule
in the database and for the current date
be immediately was visible on the
visible on the homepage, proving
homepage if the that the task was
task is set for the stored in the
 present date. database.

6 Select the settings button A drop down menu As expected once Pass
should appear with the user selects
two options: Auto- settings
preferences or log immediately a drop
out. down box follows
with the relevant UI
elements.

7 Select “Auto-Preferences” A pop-up should As expected a pop- Pass

from the drop-down menu appear, giving the over opens
user options displaying the
concerning the relevant UI
preferences that elements.
guide the auto-
scheduler

8 Adjust preferences The user can select As expected the Pass

the following: A user can first select
period of the day to a period of the day
have tasks which is the
scheduled i.e. morning and then a
Morning, Afternoon start and end time
or Evening. The that fit within that
starttime and period.
endtime of that
window i.e. start
scheduling tasks at
7am and finish at
12PM.

9 Press the apply button The users As expected the Pass

preferences are users preferences
stored in the were stored and
database henceforth mapped into the
dictating the times a database. Everytime
task/program is the user logged in,
auto-scheduled into the specified
their program. preferences were
loaded.

10 Select community programs A pop-over window As expected a pop- Pass

button is opened displaying up window displays
a range of programs a range of computer
to choose from and science programs,
integrate into your each of which are
schedule uniquely selectable.

11 Select a program The community As expected, when Pass

program window is the user clicked on
closed and a new the “introduction to
pop-up window python course”, the
opens summarising summary was
the details of the displayed in another
program, as well as pop-up window as
a button to have the well as the option to
program integrated integrate it into their
into your schedule. schedule
12 Press the “integrate The program should As expected when Pass
program” button be stored into the the user selected
database, mapped to “Introduction to
the user and then be python” course, the
immediately program was
available visually on moulded around
the homepage if the their current tasks
task fits within their and only inserted
preference window within their
preference window.
Two of the tasks
were present on the
homepage, as there
was no more space
due to other tasks.

Table 8.5: Results table for System Tests conducted on the “Loic” User story.

Step Step Details Expected Outcome Actual Outcome Results

Number

1 Open the application The login page As expected the Pass

should open user is unable to
immediately and proceed past the
allow no redirection login page unless
to other pages they enter the
unless the user has a correct details or
valid login or wants attempt to register
to register a new
account

2 Log into the application The user's username As expected the Pass
and password user is redirected to
combination is their personal
cross-referenced in homepage but the
the database. If the current date was
user exists they are empty as they were
redirected to their yet to pass in any
personal homepage. task items

3 Select “Auto-Preferences” A pop-up should As expected a pop- Pass

from the drop-down menu appear, giving the over opens
user options displaying the
concerning the relevant UI
preferences that elements.
guide the auto-
scheduler

4 Adjust preferences The user can select As expected the Pass

the following: A user can first select
period of the day to a period of the day
have tasks which is the
scheduled i.e. morning and then a
Morning, Afternoon start and end time
or Evening. The that fit within that
starttime and period.
 endtime of that
window i.e. start
scheduling tasks at
7am and finish at
12PM.

5 Press the apply button The users As expected the Pass

preferences are users preferences
stored in the were stored and
database henceforth mapped into the
dictating the times a database. Everytime
task/program is the user logged in,
auto-scheduled into the specified
their program. preferences were
loaded.

6 Press the “add a new task” The “new task As expected the Pass
button window” pop up user was able to
window should begin entering task
appear in centre of details onto the pop-
the screen up window.

7 Press the auto-button The auto-button The expected Pass

should turn green to outcome is reached
indicate that the task
will be scheduled
automatically

8 Press the apply button The user should be As expected the task Pass
redirected to the was automatically
homepage, where inserted into the
there auto- database, according
scheduled task is to their personal
either present on the preferences and was
homepage because present on the
it was scheduled for homepage since
the current date or they had time
appears on their available within the
calendar. current date.

9 Press the “schedule button” The user is As expected the Pass

redirected to other user is redirected to
personal calendar the calendar where
were they can see they can see a
their current task summary of their
and all previous current tasks
tasks

10 Press the “month view” The interface As expected the Pass

changes to the users tasks were
monthly view were visible dating back
tasks scheduled 2 months from the
throughout the year current date
are all visible by
title

11 Select a task to view details The selected task is As expected the Pass
opened and its selected tasks
details revealed in detailed are opened
 the ‘edit task” pop- and are clearly
up window. customisable

12 Change the date of the The date UI element As expected once Pass
selected task is selected and a the user selects a
new date is selected. new date and clicks
In doing so the tasks the apply button the
appears in a new task is immediately
position of the visible in the
monthly view to following month, as
reflect changes well as being
updated in the
database

Table 8.6: Results table for System Tests conducted on the “Mathew” User story.

The aforementioned user stories demonstrate how the system meets its functional criteria as defined in Section
4. It should be noted, however, that they are from the developer's perspective and may have a natural bias due to
the developer's expertise of the codebase. As a result, some user testing in the form of black-box tests was
required to complete the quality control of the Gole prototype.

8.4: User-Testing

User testing is crucial when developing most applications, but to-do list applications are especially important
because of their emphasis on user productivity, workflow optimisation, and potential for complexity. Thus, the
subsequent tests verified that the application actually satisfied the user's needs. This refers to a programme that
tailors tasks and activities specifically to fit a user's schedule and offers an easy-to-use task management
interface. To test for these factors effectively, user testing is conducted in a black-box manner. This is where no
knowledge about design or implementation is assumed (Jovanović, 2009)..

8.4.1: Context

There are three main research methods that guide the following tests:

1. Attitudinal vs Behavioural: Understanding or measuring a user's expressed beliefs is important, but it is

constrained by the information that the developer discloses to them and the information that they are
prepared to supply (Rohrer, 2022).
2. Qualitative vs Quantitative: When conducting qualitative research, information about user actions or
attitudes is gathered by direct observation or user feedback. On the other hand, quantitative analysis
accomplishes this by tracking specific behaviours using a tool like an analytics programme or survey
(Rohrer, 2022).
3. Context Of Use: This strategy takes into account how and whether participants are using the
aforementioned product or service. This section will specifically focus on a scripted use of the product
because it is not a fully developed version of the application (Rohrer, 2022).

8.4.1: Strategy

Given that the Gole application is not at industry standard for market deployment, it is unrealistic to employ an
entire set of techniques that satisfy the aforementioned research methods. However, an abstract test was
undertaken to satisfy aspects of each study methodology, providing an overall grasp of the prototypes' present
state. Since the prototype's only programmes are technological in nature, the group of users selected have a
STEM background from The University of Birmingham. These users were then given a series of scenarios to
guide their interaction with the application (the context of use), but were encouraged to insert their own
schedule into the prototype. Based of these scenarios, a questionnaire was conducted consisting of questions
about the users experience using the application (quantitative & qualitative as-well as attitudinal). The
aforementioned was conducted with Google slides and google forms. Low response rates are typically a
drawback of surveys, but since the application had to be used on the device it was developed on, all of the test
users response was accounted for.
8.4.2: Results

The questions on the form were designed to assess how useful the programme was in managing a user's
hypothetical schedule, specifically whether it helped align their perceived control over time and ease
procrastination. It also gathered user feedback on its overall appearance and chances of being shared with a
friend. The poll was kept anonymous, and a total of 15 responses were collected. The age range was 20-31, with
60% being under 25 and 40% working part-time to full-time roles. A Likert scale was utilised to quantify users'
opinion at times, and open-ended questions encouraging written response for qualitative research were
employed at others. The results obtained were positive and are surmised in the following.

Does this app make you feel more in control of time

Figure 8.1: Usability rating

How satisfied were you with the overall functionality of the app?

Figure 8.1: Functionality rating

How likely are you to recommend this app to others based on your experience?

Figure 8.1: Likelihood of resharing rating

Figures 8.1 - 8.3 depict the Likert scale rating distribution. In terms of time management, the overall rating was
on the high side, with 80% of users finding it useful. The application's overall functionality was likewise high,
with 73.3% of users satisfied. Many users commented on how easy the system was to operate, which may have
contributed to its high overall rating. The final quantitative question was if users would recommend the
programme to friends, achieving a 100% likelihood receiving the highest rating of all. Respondants were then
encouraged to offer written responses on the various areas of the system in order to receive detailed feedback on
the functionlaity. Considering the rating on the overall functionality it was no surpise to find that when asked
about the ase of navigation users often stated that they found it very straightforward and intutitive.

Chapter 8: Project Management

The system development employed here can be divided into two pathways: Product Development and Research.
The majority of the research was conducted before the development phase, which like all software products, is
necessary to define the objectives of the product. However, considering the limited time constraints, the
developer took precautions and at times performed development and research in parallel. Indeed, It is not
uncommon for junior developers to pre-define unduly ambitious features during the planning stage. Henceforth
in order to remain dynamic throughout the development phase two methodologies were employed: Plan-Driven
Methodology & Agile Methodology.

Section 8.1: Software Methodologies

A plan-driven methodology typically pre-defines the objectives at the project's beginning phase. The waterfall
approach for instance consists of sequential phases, each of which is dependent on the results of the previous
steps (Imani, 2017). A general linear evolution of how these initiatives could unfold looks like the following: To
begin the developer will gather requirements such as features and functionalities and document them
comprehensively. The system is then developed and tested. This comprises designing, coding and implementing
software in accordance with requirements. The final step is to deploy and maintain the product. Here developers
will need to respond to the demands of the end user and carry out the necessary maintenance. Overall a plan-
driven approach is perfect for projects with a stable scope, where the objectives are clear and unlikely to change
significantly during the course of development. It also goes without saying that it is majorly beneficial for when
there is a need for extensive documentation and a formal process, as necessary for this final report.

The second methodology is the Agile methodology . Unlike a plan-driven approach, this project management
concept divides projects into numerous dynamic phases commonly known as sprints (Srivastava, 2017). These
sprints are carried out iteratively. The 4 main agile manifestos that any agile framework must embody is:

1. Individuals over processes or tools

2. Working software over comprehensive documentations

3. Customer Collaboration over contract negotiation

4. Responding to change over the following plan

Generally the agile methodology is employed in fast-paced and ever changing business environments. Its
emphasis on adaptability, collaboration and frequent iterations allows developers to effectively respond to
shifting demands and consumer needs.

Naturally, neither of these techniques is completely ideal for developing the Gole application. Indeed, a junior
software developer's insufficient knowledge of software development equates to severely limited foresight when
it comes to pre-defining the development process. Indeed, a junior software developer's lack of software
development experience translates into significantly limited foresight when it comes to pre-defining the
development process. It would consequently be illogical to rely solely on the documentation completed before
the development period. Similarly, choosing to be flexible from the start would almost certainly result in
wasteful resource utilisation and an inability to set performance standards or steer development initiatives. As a
result, it was determined that the best software approach would be a combination of a Plan-Driven methodology
and an Agile methodology, specifically the Scrum framework. In this way overall aims were made that split the
project into logical steps over time (plan driven) with micro-goals condensed into sprints in between, flexible
enough to respond to priorities in the moment. 4 main tools were used to do so: (1) Sprints: these are timeframes
in which the developer planned to perform a specified amount of work. (2) Backlog: This was a priority to-do
list where objectives could be reformed to meet sudden changes in the development of the product. (3) Sprint
Planning: An assessment of the highest priority backlog tasks, each of which were given an estimated
completion time. Finally (4) Sprint Retrospective: This was an opportunity for the developer to evaluate
completed work, and list the ways in which future tasks can be made more efficient.

8.2 Project Timeline

The figure below depicts a list of the project's overarching goals, as well as its start and completion dates. These
deadlines were not always met, as the agile methodology's flexibility was used at times to prioritise one goal
above another. Nonetheless, some dates were non-negotiable, as shown in table 8.1. These dates include project
proposal submission, formal project inspection, and final submission.

Figure 8.1 Ideal project timeline from research phase to submission

date

Task Submission Date

Project inspection week 10-14 July 2023
Project demonstration week 4-8 September 2023 (week 13)
Project report deadline 18 September 2023 at 12pm noon UK time

Table 8.1: Non-Negotiable Submission

Dates
8.3: Updated Timeline

As expected, the original schedule required modest revisions as time passed. Indeed, additional study was
required at times to solve various technical hurdles. Table 8.2 lists some of these new tasks that were added to
the timetable, although the overall scope remained largely unchanged. Further review of the development cycle
is noted in section x.

Task Start Date Completion Date

Academic Research 12-06-2023 30-07-2023
Market Research 12-06-2023 30-07-2023
UI/UX Design Research 26-06-2023 01-07-2023
Requirements 01-07-2023 08-08-2023

Design Gole User-Interface with 26-06-2023 07-07-2023

Figma

Create User Interface With Scene- 01-07-2023 31-08-2023

builder

Design database 01-07-2023 31-07-2023

Implement core back-end 01-07-2023 31-08-2023

functionality

Research Methods Of Encryption 24-07-2023 26–07-2023

Research the options for Java 01–8-2023 03-08-2023

desktop app third-party
authentication

Unit Testing

Component Testing

System Testing

Prepare presentation

Final Report 01-07-2023

8.4: Tools

A range of tools were used throughout the project to guide research and aid development and overall
management. These are:

● Google Docs: Google Docs was used as the primary source of documentation to guarantee a clean and
uniform interface. It has a variety of formatting features that help the writer to improve the visual
appearance of the written material. Furthermore, because it was cloud-based, it was accessible from
any device with an internet connection, making it convenient to operate from different locations or
devices. Finally, it includes auto-saving and version history. Saving the work automatically lowered the
danger of losing progress. A detailed version history also allows the writer to monitor and refer to
earlier modifications as needed.

● IntelliJ: IntelliJ was chosen as the IDE mostly because it was preferred by the developer. Nonetheless,
it is a popular cross-platform tool with various features that make it excellent for developing Java
prototypes. One of the primary benefits is increased speed and performance. Its intelligent code editor,
which provides real-time code analysis and suggestions, significantly boosts productivity during
development. It also has strong refactoring features, making it simple to change and rearrange code.
 This is supplemented with sophisticated code navigation features like detecting usages, navigating to
the definition, and selecting fixes, all of which are useful when prototyping. Finally, and most
critically, its Maven and Grade support is unparalleled. Having build automation tools like Apache
maven made it simpler to manage dependencies and quickly set up a project with the required library
and frameworks

● GitHub: Github is an industry standard for repository hosting services. This tool was mainly used to
save the project on the cloud as a precaution for hardware failure. Its interface displays source code
side by side and highlights any parts that have been modified making it easy to keep track of revisions.
Ultimately it was used as backup storage for the Gole prototype.

● PGAdmin4: PGAdmin is a popular PostgreSQL database management tool. There are three primary
reasons for the developer to use this. The first advantage is that it is simple to use. Its user interface is
simple and intuitive, with visual representations of database objects (such as tables and views), and its
drag-and-drop functionality simplifies database management operations. The query editor and visual
query builder are the next advantage. With aided SQL queries, syntax highlighting, code suggestions,
and query execution plans for optimisation, the query editor speeds up the workflow. Finally, it
streamlines administrative work by providing complete server control and monitoring. It enables you to
manage several Postgres servers from a single interface, all of which may be created, recovered from
backups, and performance monitored. When combined with IntelliJ, it increased overall productivity.

● Figma: Figma is a strong tool for producing wireframes for software products. It includes an intuitive
and user-friendly interface that simplifies the wireframing process and allows developers to quickly
bring design concepts to life. It is also cloud-based, making it available from any device. Finally, the
combination of a large UI-components library and CSS code made it easier to synchronise the move
from design to prototype.

● Wondershare Filmora Pro: The video editor Wondershare Filmora was used to demonstrate the
capabilities of the Gole prototype. Its simple interface made demonstrating software functionalities and
features quick and easy. It has a plethora of advanced video editing tools and effects, such as
interactive elements, animations, and transitions, to smoothly exhibit user interactions. Its large
collection of pre-designed templates also aided in the design process, saving time and effort.
Chapter 9: Software Risk Assessment

Software risk assessment is described as the “process of identifying, analysing and prioritising risks”
(Mohamud Sharif and Basri, 2011). This is an important step in software prototyping since it allows you to
detect and eliminate potential risks early on, as well as improve overall product quality and reliability. There are
two main components to any risk assessment the first being Risk Assessment and the second Risk Control. Risk
assessment usually entails the following steps: Risk Identification, Risk Analysis and Risk Priorities. Risk
Control, on the other hand, examines how risk management can be planned ahead of time, as well as risk
monitoring and risk resolution (Khalid, 2022) . The following is an abstract risk assessment completed prior
to the development of the Gole Application.

Section 9.2: Estimating Risk Exposure

Estimation of risk exposure helps to determine the severity of the risks the software project might face. The risk
exposure (RE) analysis thus takes two key parameters into account: Size Of Potential loss in time (S), and
Probability that a corresponding risk will occur (P) (Khalid, 2022).

RE = P * S

A relevant example would be: There is a 45% chance that a key piece of technology cannot be implemented into
the desktop application. The estimated impact of delay on finding an alternative is 1 week. Thus the risk
exposure can be measured as 0.45 * 1 week = 3-4 days.

Section 9.3: Risk & Mitigation Technique

The following is a selection of realistic risks that may delay or modify the trajectory of the Gole application. It’s
important to note however the developers limited experience and as such, some solutions may not be as feasible
in practice.

● Risk Factor: The developer underestimated the time of product delivery

- Explanation: Due to the developers' insufficient experience in software engineering, it is

possible that the delivery date underestimates the project's difficulties. This risk must be
addressed because the completion of the prototype (whether functional or not) is required for a
complete final report.

- Risk Exposure: 0.5 * 2 weeks = 1 week

- Mitigation Strategy: Ultimately there is no solid way to mitigate this risk. To minimise this
risk however the project's schedule must be mapped using a timeline or gantt chart with
regular progress checks to estimate the plausibility of the completion date.

- Status: No Risk

● Risk Factor: Integration Challenges

- Explanation: Integrating numerous programmes into a user's personal programme may

present integration issues, especially if the developer is unfamiliar with the relevant
programmes' APIs and protocols. Furthermore, the prototype is being developed as a desktop
 programme, which is behind contemporary developments (web stack). As a result, integration
issues are likely to occur due to a lack of cross-platform support.

- Risk Exposure: 0.7 * 1 week = 5 days

- Mitigation Strategy: To mitigate this, alternatives to the integration of programmes from

online platforms must be pre-defined. For example, if the Udemy API does not
support/provide instructions for integration with a Java-based desktop application, dummy
courses will be created in the database. For demonstration purposes, this will be used to
simulate the integration of an online education programme.

- Status: This risk occurred and was solved as aforementioned in the mitigation strategy.

● Risk Factor: Hardware Failure

- Explanation: The application will be built on the developers macbook m1. Thus it is possible
that the macbook may suffer damages that destroy or prevent access to it’s content.
- Risk Exposure: 0.2 * 1 week (replacement arrival) = 1 day and half approx.
- Mitigation Strategy: There are no measures that can prevent hardware failure but to reduce
the impact the entire codebase must be regularly pushed on github.
- Status: No Risk

● Risk Factor: Negative user-adoption/acceptance

- Explanation: It is possible that the ideal consumer may find the Gole application and
insufficient solution to the problem of time management. Similarly they may find it difficult to
manoeuvre, being perhaps unfamiliar with the tools.
- Risk Exposure: 0.4 * 2 = 6 days approx
- Mitigation Strategy: Regularly asking for user input as the Gole application develops allows
the developer to remain responsive early on to user criticism.
- Status: No Risk
Chapter 10: Evaluation

The following chapter will assess the Gole prototype's overall strengths and drawbacks in relation to the initially
set objectives. The functional requirements, LESP guidelines, and an Author's personal evaluation will be
employed to accomplish this. The objective is that by doing so, future iterations will have a clear roadmap on
how to directly improve the overall performance of the Gole application.

10.1: Functional Requirements

Table 10.1 lists the updated functional requirements, whether the author believes those requirements were met
and a brief evaluation of how this was done.

Requirement Expectation Evaluation Result

F1 The system must access and store The system mimics the process of Partial
accessing third-party data (such as courses)
third-party data
via the database. As explained in the
implementation, desktop applications are
not appropriate for web based API.

F2 The system should allow users to
automatically insert tasks into their
schedule
Users are able to specify the title,duration Pass
and description of a task and have it
automatically scheduled within the next 7
days of the present date.

F3 The system must allow users to
integrate community programs into
their personal schedule
Users are able to select a course program Pass
from a list and have it moulded around
their schedule automatically.

F4 The system should allow users to Users are able to define a task as flexible Pass
or non-flexible so that future iterations can
decide the priority of an identified
move the given task if necessary
goal.

F5 The system shall allow users to Users are able to create, read, update or Pass
delete tasks that are uniquely associated to
perform all CRUD operations with
their account.
tasks

F6 User aggregated data in the system
must belong solely to a single
individual at maximum
Users are only able to access the tasks
associated with their login details. It is not
possible to enter another persons account
unless you have the correct username and
password combination.

F7 The system must store input data The system keeps track of all user-input Pass
 obtained from users for potential unless the user specifies they would like to
delete the task.
natural language processing for
future task suggestions

F8 The system must provide an The system is intuitive, simple and easy to Pass
navigate. It uses a familiar format to other
engaging, focused and informative
productivity applications on the market
way of presenting tasks to users which reduces the necessity to teach users
how to utilise the system

F9 The user interface must provide The user can perform all objectives within Pass
the application with ease.
appropriate functionality for a user

F10 The user must be able to view
there tasks on a calendar
Users can view their entire schedule on the Pass
calendar, including tasks completed in the
past. The calendar interface highlights the
tasks that are of the present date and they
are fully customizable.

10.2: Non-Functional Requirements

Similarly to the functional requirements the non-functional requirements will be listed in table 10.2 and
evaluated to assess whether they were met or not

Requirement Expectation Evaluation Result

NF1 The system must be Each class in the codebase Pass

addresses a specific
modular
function of the program.
They are also named and
organised appropriately to
make the entire codebase
easy to navigate

NF2 The system should be Along with the final Pass

report, specifically the
maintainable, commented
implementation chapter
and provide strong the codebase itself has
numerous comments to
documentation for future
explain how each method
iterations functions and the relevant
components.

NF3 The system should be Users' details are Pass

encrypted making it
secure
virtually impossible for
developers to reverse
engineer a user's
password. Every
interaction with the
database uses a prepared
statement which means
users cannot perform
harmful SQL injections.
 NF4 The system shall load a Per user-testing the Pass
system loads in a
users information in a
reasonable amount of
reasonable amount of time time. Future iterations
built with updated
frameworks such as
react.js will naturally
improve the time (see
section 10 for further
discussion)

NF5 The system should be Users found the system Pass

easy to navigate and
easy to navigate and
intuitive
understand

NF6 The application must be Assuming the Gole Pass

accessible to users at all
times of the day
application is launched on
the desktop it was built in
or that the users has the
relevant software &
backend data, there are no
limitations to accessing
the Gole application
except from having the
incorrect login details.

10.3 Legal, Ethical, Social and Professional Evaluation

10.3.1: Legal

The main concern with the Gole programme was that it could infringe on GDPR by collecting users' personal
information - in this case, a username and password. Because the Gole application is a prototype rather than a
finished product, the GDPR compliance requirements outlined in the Data Protection Act 2018 are fully met.
The application merely captures a user's email address and password and encrypts their login information using
an industry standard encryption algorithm. Furthermore, users can delete shared data, such as their personal
schedule, which is quickly and irreversibly removed from the database. Furthermore, there are no difficulties
with copyright infringement or patenting because the application employs fake courses produced by the
developer to simulate future updates that use Udemy or Coursera. Finally, users are given access to terms and
conditions during registration as well as on the login page, ensuring that there are no implications in terms of
total application context transparency. Naturally, a future deployed version of the Gole programme would
necessitate extensive legal consulting to assure proper terminology, data storage and gathering.

10.3.2: Ethical

As previously stated, the application only captures a user's username and password, which is encrypted, making
it impossible for users or engineers to reverse engineer login information. Furthermore, these are stored in a
database that can only be viewed by administrators with the necessary administration credentials. In terms of
content screening, the developer wrote every component of the application, therefore the prototype has no
unmoderated language. However, future iterations may need to prevent users from storing tasks that use explicit
language.

10.3.4: Social
The main societal issues boil down to ensuring the user is not overworked by the auto-scheduler. To mediate
this, the application will give the user a warning whenever there total working hours exceeds 60 hours 1. Due to
time constraints it was not possible to add a variety of productivity frameworks like the Pomodoro technique for
users to customise how they approach tasks, but as hypothesised in the evaluation chapter, this will
appropriately guide the user into efficiently completing tasks.

10.3.4: Professional

The Prototype only comprises courses that the developer has defined, ensuring high quality and professionalism.
However, delegating this task to third-party providers - udemy or coursera - by integrating their programmes
into the scheduler would be advantageous in order to focus on the app's core functions. However, future Gole
app iterations will almost certainly require a team of specialists to revise information provided by private
endorsers to guarantee that it is accurately instructing users how to approach their goals. Such would be the
case, if users are able to upload their own programs, a feature the Developer did not have time to introduce to
the prototype

10.4 Project Management

As seen in section 8.3 the general project management was a success. Regular meetings between the developer
and supervisor acted as quality control as each milestone was completed and were critical in maintaining overall
organisation. The sections that follow will break down the specific components of project management and
provide an abstract assessment of its success.

10.4.1: Software Development Methodology

The software methodology used was a hybrid of plan-driven and agile methodologies. In this project there were
a number of obvious advantages to doing so but the most prevalent was risk mitigation. Combining the
methodologies enabled proactive identification and management of project risks whilst embracing change to
prevent potential issues from escalating. An example of this was making the decision to build proof of concept
with respect to authentication and integrating course programs, as opposed to wasting time forcing incompatible
Web-API’s to communicate with the Java desktop framework JavaFX. Furthermore, the documentation of
sprints made it easier to be specific when reflecting on implementation errors or setbacks throughout the final
report. Indeed since each sprint specifically described a task, the approach to completing it and a reflection of
what went wrong, writing a detailed and comprehensive report was simple and efficient.

10.4.2: Project Schedule

As alluded to at the introduction of this section, the predefined project schedule and actual time-line were
practically seamless. The key to success in this area was not underestimating the developers' understanding of
software development. While using frameworks in which the developer already had experience meant that
certain features had to be redefined due to incompatibility issues, the developer was able to spend the majority
of the allocated time debugging primary features and making logic-based calculations. The alternative would
have been wasting the limited allocated time, first learning the foundations of new frameworks to then figure out
how they can be translated into the specific context of the Gole prototype.

10.4.3: Risk Management

Taking precautionary measures for high-probability risks was imperative in ensuring a fully-functioning
prototype and comprehensive report were made. Once again as alluded to previously, the biggest risk identified
and subsequently rectified was an incompatibility issue between the chosen frameworks and the tools necessary
to perform some of the key features of the Gole application. Had the developer not considered that this was a
possibility it is probable that the prototype would have taken too long to complete, assuming it did, and thus
taken time away from creating a full report.

10.5 Authors Evaluation

1https://pubmed.ncbi.nlm.nih.gov/27158959/#:~:text=Conclusions%3A%20Long%20working%20hours
%20are,over%2060%20hours%20per%20week.
The preceding presents an objective examination of overall project management, however it does not take the
author's point of view into account. The following is the author's assessment of some of the important topics
mentioned in this research, as well as the usefulness and limitations of the proposed built solution.

Why should this contribution be considered of relevant and importance to Computer Science?

Productivity management does not have a direct relationship with the study of Computer Science, although this
is true of most software-related initiatives. Instead, the project utilised all of the skills and information acquired
over the course of a year as a Computer Science Masters student. Indeed, the project required a combination of
software engineering, database management, desktop development, and algorithm development, all of which are
necessary if one wishes to succeed as a software engineer. Building on these foundations in a real project led
only by the developer, rather than a predefined academic programme, ultimately serves to reinforce all of the
essential principles in computer science.

How effectively did the research address the identified important topics

There is no definitive way to measure whether the solution offered is adequate in addressing procrastination,
perceived control of time and overall self-management. However it does serve as a foundation for improving the
way the market's current offerings respond to these difficulties. Indeed, most of the solutions assume users are
already aware of how to manage their time effectively to achieve their goals, and even when offering templates
make an assumption that a user will know how to fit this program within their own schedule. If many users have
a warped perception of time, it is reasonable to assume that a project like Gole that moulds the program around
users

Why should this project be considered an achievement?

In and of itself, creating a full-stack development project from scratch is a large endeavour for someone with
little experience in the field, especially if they come from a legal background rather than a technological one.
Nonetheless, the application meets the functional requirements established at the start of the project. The
existing Gole application demonstrates that it is possible for a software to mould around a user's schedule,
alleviating them of the obligation of scheduling goals around their lives. As a result, it relieves them of the duty
to (1) find time in their schedule to finish tasks/programs and (2) provides them with a superior perspective on
the length of time it will take them individually to reach their goals, a foresight that is not as natural to perform
mentally. It is also worth mentioning that the developer intends to pursue this project beyond the scope of this
report, which makes this current iteration of the program a building block for a real-world product.

What opportunities for improvement or further exploration exist on the research and built solution

The main tool that a future iteration must consider is Artificial Intelligence. There are numerous frameworks
like spaCy and Google’s NLP that can aid in making suggestions to users on how to organise their schedule,
what an optimal use of time could look like and the type of programs currently suited to their present skillsets.
Using such tools is certainly becoming the industry standard, with competitors like Motion currently using it
with their AI personal assistant. This is elaborated on in the conclusion (see section 11).

What are the limitations of this project?

As alluded to throughout the paper, the current Gole application is only a proof of concept and not a finished
product ready for market. Many features may have been built more efficiently or with better third-party tools.
Furthermore, it is a desktop-based application, whereas the majority of competitors are web/mobile phone
based, a criteria that a deployable version of Gole must meet before launch. Finally, having access to users'
personal calendars raises a number of security and privacy concerns, which the developer chose not to
completely address in a functional prototype. Again, if the application is to be deployed, this area must be
inspected beforehand and security best practices must be followed.
Chapter 11: Conclusion

This chapter will give a general overview of the project, emphasise its most significant successes, and consider
any potential follow-up work that could be required.

11.1: Summary

Overall the current iteration of the Gole application serves as a fully functioning prototype for users that would
like to curb procrastination and relieve themselves of the responsibility off finding time to complete tasks or
programs. The two key components are (1) an automatic plan for jobs based on soft preferences and (2) the
integration of whole programmes into your schedule based on the same preferences. Although users thought the
programme offered a unique service and had the potential to adapt to users more effectively than the alternatives
on the market, it still has to undergo significant changes before it is market ready. It's also important to keep in
mind that in order to obtain more trustworthy results and feedback, a larger, more diversified sample size of
users would be required. However, the project should be deemed successful based on the belief that it meets the
functional criteria.

11.2: Future Work

As aforementioned there are plenty of modifications the Gole application could make not only to better mould
around users but better compete or out perform current market offerings. The following sections will discuss a
selection of these ideas in more detail.

11.2.1: Rescheduling Capabilities

The Gole application's current version can automatically arrange tasks and programmes into a user's schedule.
To make room for incoming priority tasks, it does not, however, relocate non-priority jobs. Instead, it will scan
the present schedule for gaps and keep looking until an adequate one is identified. This could unnecessarily
lengthen the time a programme is supposed to take to finish, giving tasks that aren't as urgent priority for
completion. Currently the application allows users to indicate the priority of the task with the flexibility toggle
button and this choice is noted in the database. Thus, in subsequent iterations, tasks whose duration matches a
current priority task trying to locate space can retire there spot move accordingly.

11.2.2: Course Suggestions

While the Gole application allows users to look for educational programmes and have them integrated into their
schedule, it does not give any recommendations. Considering the assumed users of the application it is not
uncommon for people to feel stagnant in their career progression or unaware of there options post-university. As
a result an opportunity arises to release a feature that further relieves them of the responsibility to research
alternatives.For example, data collection could gather and provide important data regarding educational
programmes, their content, outcomes, employee statistics, and the socioeconomic impact they have on
individuals. Furthermore, an AI-driven recommendation engine might examine the user's profile, goals, and
interests using NLP techniques and develop personalised pathways to socioeconomic advancement. Finally, data
analysis and matching might be used to further evaluate the user's profile, present job, and education, as well as
suggest gaps or places for improvement. Matching this data with available educational programmes in the
system that have a proven track record of positively improving socioeconomic status could further encourage a
proactive approach to job dissatisfaction. Overall AI-Based recommendations could empower users to make
informed decisions, explore growth opportunities and enhance their current socio-economics status. The
following abstractly outlines the relevant methods required to achieve the aforementioned, relating them to
industry standard tools.

Data Collection: As stated above, the application would need to gather information about various
course programs. This would include their curriculums, prerequisites, job market demand, salary
potential and other relevant factors. There are several options for doing so. Web-scraping libraries such
as BeautifulSoup, JSoup, and Selenium can extract data from education websites, employment boards,
salary databases, and other relevant tools. However, additional raw data filtering . Thus another option
 is to use available course APIs to retrieve their data programmatically. Udemy, for example, provides a
third-party API for integrating course information into software platforms. This data might then be
analysed using Python tools such as Pandas or Matplotlib, allowing this information, which could be
raw, to be presented in useful ways.

AI Recommendation Engine: Machine learning algorithms are an industry standard for developing any
form of recommendation systems. Such a system should take user profiles as input and suggest
appropriate course programs based on the correlation between the input factors and potential socio-
economic improvements. There are a number of frameworks available to do so. TensorFlor for instance
is an open-source ML framework that provides a range of tools to build and deploy AI models.
Examples of such models are collaborative filtering algorithms that analyse user behaviour and
preferences to make recommendation based on similar users or similar items 2. Items to compare and
match users into groups in this case could be education or skill sets, to which the system recommends
the higher paid occupations of the group to the rest.

11.2.3: Contextual Reminders

Applications for making to-do lists frequently include reminders, however they currently lack context. The Gole
application could incorporate location services or other geo-fencing technologies in future versions to deliver
reminders based on the user's precise location. When a user visits a certain place, like a store, for example, the
programme will alert them of the associated task they have planned, like buying groceries, encouraging early
completion of tasks.

11.2.4: Integration with third-parties

Third-party integration is a feature that the Gole prototype intended to include but was unable to do so due to
incompatibility difficulties between web-based APIs and desktop frameworks. As a result, it's an obvious
change for future editions. To improve productivity even further, users could be relieved of the responsibility of
entering their work schedules into the programme by integrating third-party tools like Google Calendar or Apple
Calendar - both of which are popular tools for employers to upload work schedules - into the app's calendar and
automatically filling in time slots assigned to work. On the occasion that a work schedule is not provided on the
aforementioned calendars, and is instead filled on excel spreadsheets or other read-only formats users could be
encouraged to screenshot the program and have the relevant information extracted. The relevant technology to
do so is Optical Character Recognition Technology. Per IBM this is a program that extracts and repurposes
data from scanned documents, camera images or image-only PDF’s. Since screenshots are typically in image
format, developers can use an OCR to convert the test within the image into machine-readable text before
applying java logic to filter the relevant work-times associated with the user. There are plenty of OCR libraries
and APIs to do this but the industry standards include Google Cloud Vision OCR3 or Amazon Textract4.

11.2.4: Intelligent Automation

A feature missing in many of the other market offerings other than Trello is intelligent automation - Although
Trello is more of a project management application than a single user to do list.. A future iteration of the Gole
programme could address this void by automating mundane chores with ML algorithms. Because the system
records user history (current tasks and completed tasks) in the database, there are several solutions for
implementing this feature. To begin, user history such as due date, priority, and labels can be tracked for pattern
recognition. Machine learning algorithms like k-means clustering can then be used to learn user behaviour and
preferences over time and thus predict tasks that are likely to be routine as they are scheduled. Furthermore,
NLP frameworks like spaCy can be used to extract information from task descriptors or titles in order to identify
specific keywords or phrases that trigger automation for routine chores. For example, a user is more likely to
repeat behaviours such as paying bills or going to the gym, and the software may intelligently detect these
behaviours and automate reminders or even initiate the relevant payments. Finally, users can also be given the
option to customise their own automation rules. This feature enables the app to automatically schedule and
populate routine tasks at the press of a button as opposed to recreating them each time.

2 https://realpython.com/build-recommendation-engine-collaborative-filtering/#:~:text=Collaborative
%20filtering%20is%20a%20technique,similar%20to%20a%20particular%20user.
3 https://cloud.google.com/vision/docs/ocr
4 https://aws.amazon.com/textract/
11.3 Commercialising the application

There are various strategies available to create awareness for a product of this category. The following will
briefly discuss some of the more popular techniques.

11.3.1 Freemium Model

The freemium model is a two-tiered user acquisition model that categorises customers as either free or premium
based on whether they pay for an account. Because consumers are less likely to download an app they cannot try
before downloading it, it may be desirable to provide a free basic version of the app displaying limited versions
of its major features. For example, having access to the auto-scheduler solely for singular activities rather than
full course programmes. However, the disadvantage of this strategy is that free consumers are not guaranteed to
convert to paid users. Users may not find the integration of full programmes appealing if they have never tried it
or simply just become free riders.

11.3.2 Ad-Supported Model

A possible supplement to the freemium model is an Ad-Supported architecture. Providing the app for free but
displaying ads within the interface could be an appropriate way to deal with free-riders assuming one adopts the
freemium model. Revenue is generated by partnering with advertisers who are interested in targeting users
interested in productivity and organisational tools. In this example, an ideal partner would be Udemy or
Coursura, whose revenue model would benefit from consumers having access to their courses and the ability to
integrate it directly into their programme. If the programme incorporates AI and ML capabilities, these adverts
can be focused to specific individuals whose present skill sets coincide with or complement a certain course. It
is crucial to note, however, that advertisements can frequently be distracting and detract from the overall user
experience, potentially leading to app uninstallation. User retention is a priority with a productivity programme
like Gole, therefore the risk to return of this strategy should be thoroughly reviewed before committing.

11.3.3 Integration with Productivity Tools

Another approach to commercialising would be to integrate with other popular productivity tools or project
management platforms. By developing integrations with tools like Trello, Asana or slack users can have work-
related allocated tasks seamlessly integrated into their own personal program, as well as offer superior metrics
as to what time they have to dedicate to work-related projects. This integration can be offered as a premium
feature, bringing value to users who heavily rely on those tools already, saving them time and effort in switching
between different applications. Partnerships with these platforms also provide chances for co-marketing
initiatives, reaching larger audiences, and driving subscription-based revenue.

11.3.4 Gamification and rewards

Finally, commercialization could be accomplished through gamification elements that reward users for
accomplishing activities or reaching specific milestones. Users can participate in community challenges to gain
points or virtual currency for completing activities. These points can then be used to unlock new features or
incentives within the app. Ultimately, the notion here is that gamification can increase engagement and user
loyalty by tapping into the user's natural motivation and desire for achievement. This strategy could be
supplemented with sponsorship agreements or collaborations in which the rewards and advantages include
exclusive access to real-world goodies such as discounts on partner services or products.