Hypatiamat - I want to solve questions about...
Abstract
Hypatiamat is a Portuguese project comprised of several applications that aim to develop the Math skills of students from the 1st through 9th grades (Basic Education). The ingraining of mental calculation strategies, numbering systems, and logical operations lead to a better success rate in this subject in later years. One of the project’s components is the online platform (https://www.hypatiamat.com), which aims to foster autonomous learning through more interactive practices due to the current ease of technological access in this age group, by trying to appropriate teaching to everyday life. Several tools are made available, such as videos, tutorials, explanations, questions, etc. on various Math topics that students can easily access at any time. Teachers that aim to enhance their students’ learning process using this digital approach can exercise it in multiple applications provided by the platform, where the interactions are carried out and controlled through these means. The monolithic architecture (written in PHP) has received contributions from multiple developers over the years in order to address the scalability issues introduced with this platform’s growing popularity, which thus far demanded manual efforts for maintenance and content insertion. As such, there has been an incremental process of modernization, turning the various constituent applications into distinct microservices. "I Want to Solve Questions About..." is one of these applications where students are provided with a large selection of questions in the form of mini-games (multiple choice, true or false, ...), regarding the themes mentioned above. The first objective of the dissertation is to develop a back-office that allows the teachers in charge of the project to manage existing questions as well as add new ones for the students, since the current process requires updating the database manually. The second one is the modernization of the application’s interface at the technological level, by making use of adequate frameworks and programming languages and at the user level, by making an effort to maintain the intuitive workflow that led to its popularity but with a modernized design, in order to be consistent with other online tools.
Full text
Universidade do Minho Escola de Engenharia Departamento de Informática Válter Ferreira Picas Carvalho Hypatiamat - I Want To Solve Questions About... November 2022
Universidade do Minho Escola de Engenharia Departamento de Informática Válter Ferreira Picas Carvalho Hypatiamat - I Want To Solve Questions About... Master’s Dissertation Master’s Degree in Informatics Engineering Dissertation supervised by José Carlos Leite Ramalho Ricardo Manuel Neves Pinto November 2022
i AUTHOR COPYRIGHTS AND TERMS OF USAGE BY THIRD PARTIES This is an academic work that can be used by third-parties as long as the internationally accepted rules and good practises are respected on what the copyright and related rights are concerned. Therefore, the present work may be used on the terms foreseen by the licence indicated below. In case the user needs permission to use this work in any unforeseen conditions by the indicated license, he should contact the author, through RepositoriUM at University of Minho. License provided to the users of this work Attribution-NonCommercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/
ii STATEMENT OF INTEGRITY I hereby declare having conducted this academic work with integrity. I confirm that I have not used plagiarism or any form of undue use of information or falsification of results along the process leading to its elaboration. I further declare that I have fully acknowledged the Code of Ethical Conduct of the University of Minho. Assinado por: Válter Ferreira Picas Carvalho Num. de Identificação: 15212853 Data: 2022.11.08 13:59:29+00'00'
ACKNOWLEDGEMENTS First and foremost, I want to thank the supervisors, Professor José Carlos Leite Ramalho and Doctor Ricardo Manuel Neves Pinto, for their unwavering support and availability throughout the entire project. They provided me an efficient asynchronous means of communication, their years of experience and technical expertise which led this dissertation to its completion and consequently marks my presence in the academic world, albeit small, as a scientist. These past five years have been an incredible journey and I never thought I could learn so much in such a short time frame, which is something that I never took the time to really think about until recently. To put things into perspective, on a technical level I went from writing my first "Hello World" to deploying several full-stack web applications and writing technical papers and, on a personal level, I am now a more efficient communicator, I learned the importance of teamwork and how much it matters in building trust with your team, I am now a more disciplined individual who thrives when given the opportunity to grow and learn and I was taught that perseverance is the key to success. It is hard to imagine what the future holds because if you told me, five years ago, that I would get this far, I would have called you a lunatic on the spot. I hope that five years from now I will be having the same thoughts and saying "I cannot believe I have gotten this far", for that is who I strive to be, someone that at any given moment is a downgrade compared to its future counterpart. Along the way, I have met so many incredibly talented people and, as such, they have motivated me in their own way to become a better and more complete software developer and person. To the percentage of them that I can safely call friends, I am grateful for allowing me to create so many wonderful memories and experience so many joyous moments. It is so rare having such a large group of like-minded people that shared notes taken in classes, did group studies at the library together and never allowed anyone to fall behind. Nobody did this for a reward, to be noticed or to be praised, everyone just wanted to keep facing new obstacles, together. Lastly, to my family that provided me with something I can call a home, raised me, fed me and kept me safe, thank you, from the bottom of my heart. That is all I can say as I cannot express with words the gratitude I feel and the warmth I receive from them daily without ever expecting anything in return. I am humbled by the fact that I would not be here had the circumstances been any different. iii
ABSTRACT Hypatiamat is a Portuguese project comprised of several applications that aim to develop the Math skills of students from the 1st through 9th grades (Basic Education). The ingraining of mental calculation strategies, numbering systems, and logical operations lead to a better success rate in this subject in later years. One of the project’s components is the online platform (https://www.hypatiamat.com), which aims to foster autonomous learning through more interactive practices due to the current ease of technological access in this age group, by trying to appropriate teaching to everyday life. Several tools are made available, such as videos, tutorials, explanations, questions, etc. on various Math topics that students can easily access at any time. Teachers that aim to enhance their students’ learning process using this digital approach can exercise it in multiple applications provided by the platform, where the interactions are carried out and controlled through these means. The monolithic architecture (written in PHP) has received contributions from multiple developers over the years in order to address the scalability issues introduced with this platform’s growing popularity, which thus far demanded manual efforts for maintenance and content insertion. As such, there has been an incremental process of modernization, turning the various constituent applications into distinct microservices. "I Want to Solve Questions About..." is one of these applications where students are provided with a large selection of questions in the form of mini-games (multiple choice, true or false, ...), regarding the themes mentioned above. The first objective of the dissertation is to develop a back-office that allows the teachers in charge of the project to manage existing questions as well as add new ones for the students, since the current process requires updating the database manually. The second one is the modernization of the application’s interface at the technological level, by making use of adequate frameworks and programming languages and at the user level, by making an effort to maintain the intuitive workflow that led to its popularity but with a modernized design, in order to be consistent with other online tools. Keywords: API, REST, Node.js, Strapi, Vue.js, Vuetify, JavaScript, Back-End, Front-End, Full-Stack, MySQL, NoSQL, Web Application, Swagger, Documentation. iv
RESUMO OHypatiamat é um projeto português constituído por várias aplicações que visa desenvolver as aptidões, na disciplina de Matemática, de alunos do 1º ao 9º ano de escolaridade (Educação Básica). O enraizamento de estratégias de cálculo mental, sistemas de numeração e operações lógicas originam uma melhor taxa de sucesso nesta disciplina em anos posteriores. Uma das componentes deste projeto é a plataforma online (https://www.hypatiamat.com), cujo propósito é fomentar a aprendizagem autónoma através de práticas mais interativas, devido à facilidade de acesso tecnológico atual desta faixa etária, tentando apropriar o ensino ao quotidiano. São disponibilizadas várias ferramentas, tais como vídeos, tutoriais, explicações, questões, etc sobre os vários temas da Matemática (Ensino Básico) que os alunos podem facilmente aceder a qualquer momento. Professores que pretendam enriquecer a aprendizagem dos seus alunos com esta metodologia digital podem exercê-lo nas várias aplicações que a plataforma disponibiliza, onde a interação é realizada e controlada através destes meios. A arquitetura monolítica (escrita em PHP) tem recebido contribuições de vários desenvolvedores ao longo dos anos de modo a colmatar os problemas de escalabilidade introduzidos com a popularidade crescente desta plataforma, que até agora exigia esforço manual para manutenção e inserção de conteúdo. Assim, tem existido um processo incremental de modernização, tornando as várias aplicações constituintes em microsserviços distintos. A"Quero resolver questões de..." é uma destas aplicações, onde são disponibilizadas aos alunos várias questões, sob a forma de mini-jogos (escolha múltipla, verdadeiro ou falso, ...), relativas aos temas mencionados anteriormente. O primeiro objetivo da dissertação é o desenvolvimento de um backoffice que permita aos professores responsáveis gerirem as questões existentes assim como adicionarem novas para os alunos, visto que o processo atual obriga a atualização manual na base de dados. O segundo é a modernização da interface da aplicação ao nível: tecnológico, utilizando frameworks elinguagens de programação adequadas ao problema; do utilizador, de modo a manter o fluxo intuitivo que gerou a sua popularidade mas tendo em conta um design mais atualizado para manter a consistência com outras ferramentas online. Palavras-Chave: API, REST, Node.js, Strapi, Vue.js, Vuetify, JavaScript, Back-End,Front-End, Full-Stack, MySQL, NoSQL, Aplicação Web, Swagger, Documentação. v
CONTENTS 1Introduction 1 1.1Context 1 1.2Motivation 2 1.3Objectives 3 1.4Methodology 4 1.5Document Structure 4 2State of The Art 6 2.1Alternative Initiatives 6 2.2Study of the Platform 7 2.3Study of the Technologies 8 2.3.1Client-Sided vs Server-Sided Approaches 9 2.3.2NoSQL vs SQL 10 2.3.3MEAN vs LAMP 12 3Question Submission Back-Office 14 3.1Requirements Specification 14 3.1.1Functional Requirements 15 3.1.2Non-Functional Requirements 17 3.2Initial Assessment 18 3.2.1Teachers 19 3.2.2Questions 21 3.3Technology Selection 24 3.4Logical Data Model 26 3.5Back-End Development 30 3.5.1Initial Setup 31 3.5.2Creation of the API Endpoints 37 3.5.3Authentication and JWTs 45 3.5.4Protecting the API 48 3.6Front-End Development 50 3.6.1Initial Setup 51 3.6.2Creation of the Interfaces 51 3.6.3Saving the User State 78 4I Want To Solve Questions About... 81 4.1Requirements Specification 81 vi
contents vii 4.1.1Functional Requirements 82 4.1.2Non-Functional Requirements 85 4.2Initial Assessment 86 4.2.1Favourites 86 4.2.2Likes 87 4.3Technology Selection 88 4.4Logical Data Model 89 4.5Back-End Development 91 4.5.1Initial Setup 91 4.5.2Creation of the API Endpoints 94 4.5.3Authentication 96 4.5.4Protecting the API 97 4.6Front-End Development 99 4.6.1Initial Setup 99 4.6.2Creation of the Interfaces 100 4.6.3Saving the Blocked User State 114 5Deployment 116 5.1Back-End Servers 116 5.2Front-End Servers 118 5.3Image Server Redirects 119 6Documentation 122 7Conclusion 127 7.1Outcome 127 7.2Future Work 128 7.3Closing Thoughts 129 aMock-Ups - Question Submission Back-Office 133 bMock-Ups - ”I Want To Solve Questions About...” 139
1 INTRODUCTION Before diving into the development phase of the project, it is necessary to point out some necessary concepts about Hypatiamat itself. The Hypatiamat project was created as a response to the growing concern of the educational community over academic underperformance, especially in Math, of students from the 1st through 9th grades (Basic Education)(Hypatiamat). The main goal of this chapter is to show why this is a relevant project for the problems it attempts to solve and how it interlaces with Hypatiamat’s objectives in the Portuguese community. 1.1 context Math in schools is typically taught incrementally, i.e, it is assumed that the student, if they achieved a passing grade, has the capacity to learn new topics that require others that are covered in previous years. This implies that if they do not have a solid grasp on these concepts, they will struggle later on due to the various Math terms and the extensive range of knowledge about strategies, such as mental calculus, numbering systems, logical operations, among others. These terms and strategies are directly associated with the development of logical reasoning, therefore it is fundamental for students to achieve overall academic success on their journey and, consequently, succeed in learning Math effectively. Nowadays, with the large-scale adoption of Internet services, teachers and schools have ways of fitting new interactive teaching methods into the daily lives of students, who usually find them very easy to use. These strategies that diverge from the traditional classroom or even gamifying the multiple branches of Mathematics lead to greater student engagement and foster the pursuit of knowledge (Pinto,2014). One of this project’s facets is the online platform (https://www.hypatiamat.com) and it has a large national adherence, where it counts with the contribution of teachers and students from various municipalities (Redação,2019) and other educational communities (Martins,2014), both monitored by the Hypatiamat team using the multiple back-offices available. 1
1.2. Motivation 2 Figure 1: Homepage of the Hypatiamat website It provides a database with over 3,000 questions that grows monthly, which can be true or false, open ended responses, multiple choice, and others; assessment sheets; educational material in the form of videos, explanations and tutorials, and other resources intended for classroom usage. 1.2 motivation Initially, the team responsible for developing the digital platform did not expect this boom in popularity, so they built it using a monolithic stack of technologies that are currently in disuse due to their scalability problems (Karanjit,2016), which will be explored in the next chapter, as well as not providing the necessary functionalities for the project’s current use cases. The platform has been undergoing a modernization process in terms of its global architecture with the collaboration of several developers, who have been making the continuous effort of deploying the various constituent applications using microservices with the appropriate technologies and functionalities for each case. ”I Want To Solve Questions About...” has not yet been migrated using these techniques. It is responsible for presenting a set of questions in the form of mini-games - multiple choice, true or false, among others - which the students or teachers can answer. They are stored in a database (currently it has more than 3000 distinct entries, as mentioned above), so it is up to the team in charge to edit, insert, add and remove questions manually, since there is no backoffice for this purpose. Naturally, there will always be problems that arise from directly
1.3. Objectives 3 manipulating persisted data such as errors, inconsistencies, unintended changes or the loss of information, in the worst case scenario. Figure 2: Web page for the ”I Want To Solve Questions About...” application The interface itself is outdated considering that it was developed more than 15 years ago. The way in which the software was written makes it too rigid and difficult to change, so it naturally is comprised of patchworks that accumulate and quickly become unsustainable. There are also consistency issues due to the huge disparity between it and the current revamped services. 1.3 objectives The main objective is to update ”I Want To Solve Questions About...” in order to fit the current standards of the Hypatiamat project, which implies undergoing the mutation process that the other applications and microservices went through. Understanding the constituent problems of the application depicted previously and their resolution form the two main steps required in order to accomplish this goal. Firstly, a back-office that allows CRUD operations to be performed on data such as the questions needs to exist. It would minimize human error rates due to the automatic checks done before permanent changes are made to the database; it would remove man-hours dedicated exclusively to dealing with technical computer jargon by people with expertise in other areas and it would speed up and facilitate the process of maintaining the application in the future. Its interface should be similar to the other services already in operation, so that the consistency is kept between all of them.
1.4. Methodology 4 Regarding ”I Want To Solve Questions About...” itself, it needs to be modernized using more appropriate technologies with greater longevity and ease of maintenance, to ensure that the current situation is not repeated in the future. In addition to the technological improvement, it also needs a visual update (design) so that it is consistent with the other applications of Hypatiamat and other online tools. However, it is crucial to maintain the intuitive workflow that has made it popular in the first place, as the primary audience is mainly children, with possibly limited technical skills. Thus, a responsive, efficient, intuitive and visually appealing interface is desired, above all. 1.4 methodology The work methodology regarding the creation of both applications (”I Want To Solve Questions About...” and the question submission back-office) will be comprised of: • Study of the monolithic web application Hypatiamat; • Study of the recently developed microservices and applications, based on their relevance to the topics that are covered in this paper; • Requirements gathering and analysis; • Study of the suitability of technologies in relation to the requirements; • Usability analysis (if applicable); • Software development taking into account the requirements and the elected technologies; In order to ensure that the resulting software implementation is coherent and consistent with the requirements, periodic meetings will be held, depending on availability between the supervisors and the student, online or in person as needed. 1.5 document structure This document is divided into multiple chapters named after an overarching subject. Each one of them aggregates a number of sections and corresponding subsections, where the information that relates to them is displayed. This initial chapter contains a brief descriptive introduction of the Hypatiamat project, namely the reasons behind its existence and the goals it intends to achieve. Simultaneously, it contains the motivation for the dissertation topic, which is directly related to the platform’s ecosystem of already existing applications, as well as its utility when materialized. Finally, the proposed methodology for its development is outlined.
1.5. Document Structure 5 Chapter 2is exclusively dedicated to technological analysis and initial insights on the platform in order to ensure that its technical integration is adequate in function of the current market and tools available. Chapter 3goes over all development phases of the question submission back-office project, starting with requirements gathering, and then starts mentioning the technological decisions, initial approach, front-end mock-up prototyping and explaining the process of creating a new API server from the ground up. Similarly, chapter 4follows a similar structure but it refers to the development of the new ”I Want To Solve Questions About...”, which adds an extra chapter dedicated to usability analysis. All of these applications need to be fully deployed in their production servers, so chapter 5will follow the steps taken in order to achieve exactly that. Since the documentation of the API server endpoints is a good practice in software development, chapter 6will explain the steps behind its creation and making it accessible to any software developer that may need it. Lastly, chapter 7includes the final notes and future work that may be done in order to improve their functionality and efficiency.
2 S TAT E O F T H E A RT There is one more additional step before starting the development itself, the foundation and basis in which any carried assumption will be based on. Understanding not only the technologies but also their context in the market is fundamental in order to complete a functional end product, and it is exactly what will be detailed in this chapter. 2.1 alternative initiatives There are currently several similar alternatives to Hypatiamat in the market that seek to combat the academic underachievement that students suffer in several courses, not only Math. The non-profit organization Khan Academy aims to provide free and high-quality education for anyone that requires it. The digital platform (https://khanacademy.org/) offers several educational resources on a variety of subjects such as Math, Physics, Medicine and Economy to the users. Its worldwide success demonstrates the potential for educational projects of this kind and the adoption of online didactic models. Like Hypatiamat, it offers mini-games linked to each subject by the form of multiple choice questions and the like, however, it lacks the personalized aspect that the former provides, that is, the possibility of educators being able to work directly with their students using the tools available on the website. Skillshare (https://www.skillshare.com) offers thousands of free lessons created by the community for other users. These can also be monetized in several tiers, which ultimately gives the creators the freedom to modify the accessibility of their content as they please. This platform creates a self-feeding cycle to its advantage where the lessons they offer directly depend on the number of users that are using it. The more people use the Skillshare, the more content is provided to the community and thus more users are attracted to it, which is where the cycle appears. In contrast to Khan Academy, this platform is typically more business-oriented, which when it comes to having a more personal bond between student and teacher, it is at a greater disadvantage than the former. 6
2.2. Study of the Platform 7 Wordwall (https://wordwall.net/pt-pt/community/) is an online application that allows the users to create their own didactic resources on several topics. This initiative had the support of multiple schools and colleges such as Marista (Marca, 2021) because of how easy it is to create personalized content using the templates it provides, such as questionnaires, crossword puzzles, diagrams, etc. Despite its vast library of content, it lacks an efficient search engine, so a large majority of these mini-games end up not being found by other users simply because they are not easily accessible. There are numerous web applications that aim to provide entertainment via more complex games, but despite the development of motor and intellectual skills, they do not provide educational resources. Namely, Coquinhos (https://www.coquinhos.com/), Poki (https://poki.pt/) and Brincar (https://www.brincar.pt/) have several video games available but they do not provide the means by which the students can learn the underlying topics for each one. Evidently, there are considerably more alternatives, but it is important to refer to the previous ones as a point of comparison with Hypatiamat, in order to analyze their virtues and market relevance. 2.2 study of the platform In the previous chapter, it was stated that ”I Want to Solve Questions About...” is still hosted on the monolithic web application, which requires a study on its underlying architecture before writing the software itself. There are 4key pillars to this platform, described by the LAMP stack, which was commonly used in the industry back when the project was initially developed. This software bundle has many alternatives in its constituent layers, however the ones that make Hypatiamat as a whole are: • Linux: it is the stack’s base layer, the remaining ones were picked based on their compatibility with this operating system; • Apache Web Server: used as a web server that is responsible for processing and responding to HTTP requests that target the application; • MySQL: relational database management system that persists and allows access to data using tables derived from the application; • PHP: scripting layer built on top of the stack that abstracts the access to the previous layer and renders the HTML web pages with its data.
2.3. Study of the Technologies 8 Figure 3:Hypatiamat’s LAMP architecture This architecture is typically referred to as monolithic because all these layers coexist in the same system. It typically suffers from poor overall performance since all the machine’s resources are shared by all the layers, which causes a bottleneck and consequently impacts its availability and scalability. Therefore, rendering pages using PHP is done on the server. Assuming it has 100 daily requests to fetch the home-page, it will mindlessly execute the same rendering routine for those 100 requests, which contributes to the waste of resources and processing power that could be better used elsewhere (this is discussed in more detail in section 2.3.1). The performance is effectively lower than other modern alternatives, such as MEAN, which are the foundation of the various microservices that currently form Hypatiamat’s backbone. 2.3 study of the technologies Nowadays, web applications provide a wide range of options regarding the technologies that can be used and the difficulty lies in picking the ones that fit some scenario the best, since they all specialize in different aspects such as the programming language, scope, interoperability, etc. The gradual process of technological development is especially noticeable in this area, in which the main problems are usually consequences of the poor scalability, both horizontal and vertical that they initially had. The creation and investment in cloud services (Rahman,2021) such as GCP, Azure and GCP initially emerged as a response to the growing demand from users, since the servers they had did not have the capacity to handle all the requests successfully due to hardware and software limitations. Consequently, latency problems, low availability and errors in
2.3. Study of the Technologies 9 handling the requests themselves were frequent and, in fact, were generating net capital losses for the companies. One of the main causes for the aforementioned problems was the large-scale adoption of tools that tended to use server-sided approaches for all routines related to dispatching requests, which entails the entire process from validating them to rendering the HTML page that would be sent to the client, which will be explored in more detail in section 2.3.1. Traditional relational databases are hard to scale horizontally, as they satisfy the ACID principles. However, they were the primary choice as the persistence layer for most applications that existed in the start of the 21st century because there simply did not exist any strong alternatives effectively mitigated the issues that these systems brought (covered in section 2.3.2), which led to monolithic architectures being seen as the norm back then. Thus, the industry trend has moved from using LAMP systems, or variations thereof, to MEAN systems (2.3.3), as well as its alternatives, which implement the many different tools that arise from technological developments across all elements of the depicted stack. 2.3.1Client-Sided vs Server-Sided Approaches The overwhelming majority of web applications work via the client-server model where the communication method is based on requests and responses to a central server by a client, using HTTP. Figure 4: Client-Server Model In this view, all processes that take place on the client side are called client-sided. Alternatively, server-sided are the ones that execute solely on the server side (Cloudflare). In the past, the entire request handling process was server-sided, which included rendering the HTML pages, accessing the persistence layer, validating requests, formatting several types of data, among others. The client-sided process was much simpler, as they would only receive text in the form of HTML and it would be the user’s responsibility to display it and apply the respective styling correctly (after the introduction of CSS to the Internet), which was typically performed by the average web browser.
2.3. Study of the Technologies 10 This strategy faces the problem that the vast majority of these renderings have the exact same result, effectively wasting computational resources that could be used for other tasks. It is not enough to generate the HTML, which takes a certain amount of time, it is also necessary to access the data layer in order to retrieve the information required for it, which also uses a time frame for its execution. In pages with dynamic content, one would observe poorer performance due to this increase in latency. As seen earlier (2.2), PHP is one of the technologies that employ this method. Recently, technologies have begun to emerge that try to mitigate this problem, that is, instead of assigning the role of scripting and rendering the pages to the server, these are carried out on the client side instead. In this paradigm, they are typically referred to as API servers, which only provide the data needed to build the page, which frees the computational burden on the server side of rendering HTML that can be used to handle more clients and in a more efficient manner, achieving less latency and a higher availability rates. For example, Node.js, Java Spring, Ruby On Rails, Flask are typically used in this fashion. To complement this new server-sided approach, on the client side, frameworks like Vue, React and Angular currently dominate the market, as well as other key responsive engines for recent web applications (Kaluža and Vukelic,2018), as they only consume the data provided by API servers and render HTML responsively, which allows for a better user experience and more creative freedom for developers. 2.3.2NoSQL vs SQL The data definition language is used in relational database management systems such as MySQL and Oracle Database, which typically consist of strict data models based on their table and column structure. One of their main features is the adherence to the ACID principles in their handling of transactions: • Atomicity - A transaction is only completed if all the steps that comprise it are fully executed; • Consistency - A transaction must not cause inconsistencies in the transition between states defined before and after its execution, that is, all the associated invariants must be kept; • Isolation - A transaction, although there may be several others running concurrently, should not interfere with the result of any of them, that is, the final state should be identical to the outcome of running them sequentially; • Durability - A completed transaction should persist in the database even after a system failure.
3.1. Requirements Specification 17 It is important to note that every single question that is selected for any edition should be hidden until the reset day arrives, since the students could just easily search the solution prior to the submission. Keeping the history of previous editions of the monthly questions would be a favourable addition as it would allow the owners to keep track of which questions were already selected in order to keep a large variety of questions every month. 3.1.2Non-Functional Requirements A basic requirement of the back-office is that it has to be a cross-platform web application, it should work both on an average computer and on a mobile device, granting the user the possibility to access it from anywhere. However, the priority is a functional version for desktop computers and laptops, having it be mobile-friendly is a plus. Evidently, the fact that it will be developed as a web application means that it should be taken into account it may be accessed by the many different browsers in the market. Making it compatible with them, ensuring that it at least works on the most popular ones (Chrome, Safari,Edge and Firefox) (Statista,2021), is fundamental since the teachers do not use the same browser every time nor are they expected to do so in the future, due to their individual preferences not being final. Initially, it was mentioned that interface has to be consistent with the multiple microservices of Hypatiamat. In particular, the basis of comparison will be with the TPC management system designed by João Vieira (Vieira,2021), since it was conducted in exactly the same way, by following the guidelines from previous projetcts. Figure 7: Interface for the insertion of a new TPC
3.2. Initial Assessment 18 Regarding the interface for inserting a new TPC, available when a user successfully authenticates, there are a few caveats regarding its design. Namely, there is a retractable navigation bar on the left that fills a percentage of the screen vertically and it contains all the relevant navigation links for the application. The remaining space is filled with the specific content that needs to be displayed in each page. In addition to this, the color palette is also important. The content section (right) uses shades of green to highlight titles, buttons or any element that needs to draw more attention; white for empty sections; black for general-purpose text; shades of grey for text that requires a more subtle presence such as help messages, as well as borders for input sections; red to indicate some kind of error. The navigation bar (left) only uses green as a background color and white text (preceded by explanatory icons) to contrast it. The font is identical between these two components, where only the sizes vary depending on the information that needs to be rendered. The back-office must keep these design choices in order to achieve the desired consistency between all the applications that comprise Hypatiamat. It is not enough to follow these guidelines, it should also be intuitive to use, with a simplified user flow, since the platform will be used by teachers of varying technical expertise. In order to achieve this, the use of tools that allow the creation of responsive and reactive web applications, such as the ones used by João in the TPC manager, are critical to its success. Any question, whether they are quarantined or not, should also not break any application previously developed, as stated previously. There should be mechanisms in place that thoroughly error-check them and ensure that no corruption of data occurs. 3.2 initial assessment Hypatiamat already has a database server in production with multiple databases to ensure that the different types of data are compartmentalized and organized. It is currently deployed using MySQL and they all have the same prefix (”hypati67_”) followed by their identifier that represents what type of tables are contained within it. For example, ”hypati67_aplicacoes” has all the tables related to the types of users that are registered in the platform, which can be a teacher or a student, their school and class (if applicable), and so on. As seen in 3.1.1, the back-office should only allow access for its data-manipulating functionalities to the owner teachers of Hypatiamat itself who stand at the top of the hierarchy, as they are the only ones who ultimately give the final decision on what gets added or not into every application the website offers. What this entails is an authentication system that filters out anyone that is not part of this very small group of people and, in order to do that, it needs access to the database responsible for storing all of the information necessary for this process, which is the focus of section 3.2.1.
3.2. Initial Assessment 19 The main features of this application revolve around manipulating the database that stores all the question data (3.1.1). For this to become possible, the back-office will also need access to the database that currently holds all the data on the ever-increasing amount of distinct questions and their associated types, explored further in 3.2.2. Naturally, both of these very distinct databases must not be corrupted in any way and since they are the foundation for the wide variety of applications Hypatiamat offers. Adding to this, it is of utmost importance that the structure of the tables are not changed since they can have negative impacts on the already established services due to incompatibilities between data and can cause total shutdown for maintenance, in the worse case scenario. Assuming these databases are permanent, since as seen above it is unlikely there will ever be any change regarding which one the tables are saved in, the back-office only needs access to these 2existing databases. Evidently, since this a new application it will most likely need new tables (especially because of the ”quarantine” feature) which begs the question: where do they go? There are several possibilities, however, it is important to note that this application should not interfere in any way with the current compartmentalized structure of the MySQL server and the corruption issues mentioned above, which means the best option in these circumstances is to create a new database that contains only the tables related to the question submission back-office, leaving the others the way they are. All that remains is to settle on a name for this new database, which must follow the aforementioned rule in order to maintain consistency with the others. After the approval of the owners, it will be named ”hypati67_questoes” and will be initially empty, as expected, and permission to execute any operation on its content by the back-office. It is important to note that, henceforth, any database schema or image that may appear as a representation of any database or table in the MySQL server will be a simplified version with only the necessary information, i.e, without all its relations, foreign keys and indexes as they are too many and would cause unnecessary confusion and visual clutter. 3.2.1Teachers In the previous section, it was given as an example that the database ”hypati67_aplicacoes” hosts all the information on teachers, students, schools, classes, etc and that one of the requirements for the back-office is blocking out the access of anyone that is not an owner. Thus, the first step in designing a solution for the authentication is studying and understanding the teachers table specifically. Simultaneously, it is important to note that the schools table is also important since it contains specific information of the school where they teach at, which will be relevant further into the paper.
3.2. Initial Assessment 20 The logical model below represents the schools and teachers tables, where the ”escola” column in ”professores” (teachers) is a reference to the ”cod” column in ”escolas” (schools). Figure 8: Teachers and schools tables in ”hypati67_aplicacoes” On the left side, the table ”professores” contains the following columns: •id - auto-incremented primary key; •codigo - unique identifying code of the teacher; •nome - name of the teacher; •email - email of their Hypatiamat account; •password - hashed password of their Hypatiamat account, calculated with BCrypt; •confirmacao - whether or not their account has been confirmed; • premium - integer in the interval 0-5that indicates the permissions they have in the platform, where 5is only given to the owners of the platform; •validade - date when their permissions expire; •socionum -Hypatiamat partner number (if applicable), •projeto - which project is associated with them; •school - unique identifying code of the school where they teach at; On the right side, the table ”escolas” contains the following columns: •id - auto-incremented primary key; •nome - name of the school;
3.2. Initial Assessment 21 •localidade - town where the school is located; •distrito - district where the school is located; •pais - country where the school is located; •cod - unique identifying code of the school; After analysing this logical model, the immediate conclusion is that ”email”, ”password” and ”premium” columns are relevant to the authentication, since they provide a way to identify the user that attempts to log into the platform. However, there is one more condition that needs to be validated, which is whether the date when their permissions get revoked has been reached or not, accomplished via the ”validade” column. 3.2.2Questions The questions are the main focus of the back-office, in fact, its purpose is to offer several functionalities that interact with them in some way. Therefore, analyzing the type of questions and its quirks present in the MySQL server is fundamental to achieving a successful end product. The database responsible for hosting them is ”hypati67_testeconhecimentos” and it also contains other important information, most of which is not relevant for the completion of this project. The only exception is the themes table, which contains the names of the themes and sub-themes of the questions, granting less redundant and repeated entries. The logical model below represents these two tables, where "Base_dados" is the aforementioned questions database and ”subtemas” contains the themes and sub-themes associated with them. The columns ”tema” and ”subtema” in the former refer to ”codtemaN” and ”codsubtema” in the latter, respectively.
3.2. Initial Assessment 22 Figure 9: Questions and themes tables in ”hypati67_testeconhecimentos” The questions table is comprised of the following columns: •id - auto-incremented primary key; •codigo - unique identifying code for the question; • questao - question statement that may contain the following sequence of special characters: – <br>: line break; – x<sub>y<sub>: powers (xy); – <raiz>x<raiz>: square roots (√x); – %2B: addition symbol (+); – +xpto e -xpto:+∞e−∞, respectively. • resposta1... resposta6the information these columns store may also contain the same sequence of characters as before and their content depends on the ”tipo” and ”auxiliar” fields, which are explained below; • examesn - binary value that indicates whether the question came from an exam/test or not; •idexame - the name of the exam/test the question came from, if applicable;
3.2. Initial Assessment 23 • unidade - if ”tipo” is 1and the statement requires a measurement unit, this column contains it; •tema - identifying code of the question theme; •subtema - identifying code of the question sub-theme; •resolucao - contains the URL to the image of the question’s solution in case it exists; •pista - redundant legacy column; • niveldificuldade - integer in the interval 1to 4that indicates the difficulty level of the question; • ano - integer in the interval 1to 9that indicates which grade this question is aimed at; • figura - contains the URL to the image that is used in junction with the statement for better clarity or auxiliary information in case it exists; • tipo - integer in the interval 0to 7that indicates the type of the question itself, which in turn indicates the contents of ”resposta1” through ”resposta6”: – 0multiple choice with 4available text answers, each one of these will occupy the slots ”resposta1” through ”resposta4”; – 1open-ended question with several text options, where the contents of ”resposta1” through ”resposta6” are determined by the ”auxiliar” column as seen below; – 2multiple choice with 4available image answers, each one of these will occupy the slots ”resposta1” through ”resposta4” using their URLs; – 3true or false with only 2possible answers which only use the ”resposta1” and ”resposta2” columns; – 4multiple choice with 3available text answers, similar as type 0but requires one less ”resposta” column (”resposta1” to ”resposta3”); – 5multiple choice with 5available text answers, similar as type 0but requires one more ”resposta” column (”resposta1” to ”resposta5”); – 6multiple choice with 6available text answers which require the slots ”resposta1” through ”resposta6”; –7grid symmetry, where ”resposta1” is used to store its layout and axis; • auxiliar - integer that defines variants within the open-ended type of questions and its default value is 0to the others:
3.3. Technology Selection 24 – 0all the answers in any of the columns from ”resposta1” up to ”resposta6” are accepted; –1only ”resposta1” exists and is the only acceptable answer; – 2only ”resposta1” and ”resposta2” are filled and the correct answer is the irreducible fraction resulting from (resposta1/resposta2); – 22 - similar to 2but it accepts any equivalent fraction to ( resposta1/resposta2 ), it does not have to be in its irreducible form; – 10 - indicates that a protractor is required in order to calculate some angle, where the correct answer is in the interval between ”resposta1” and ”resposta2”; – 1000 - only ”resposta1” and ”resposta2” are filled and both have the correct solution. The themes table is simple when compared to the previous one: •tema: name of the theme; •subtema: name of the sub-theme; •codtema: redundant legacy column; •codtemaN: unique identifying code for the theme; •codsubtema: unique identifying code for the sub-theme; It is important to note that any question that may be added in the future to the database must maintain this format and follow all of the rules above, since all the other micro-services that use these it would break in some way were there to exist any deviations, something that is extremely against the main goals of the project. This also includes using valid codes for the themes and sub-themes. 3.3 technology selection After many iterations, the following image shows the technological stack that will be the foundation for the back-office’s development:
3.3. Technology Selection 25 Figure 10: Technological stack for the back-office As stated previously in chapter 2.3.3,MEAN architectures are currently dominating the market when it comes to developing full-stack web applications, mainly because they offer a greater scaling capability when compared to the LAMP alternatives. Thus, it makes sense that the back-office should follow a similar or equal ideology since it is also going to be a web application. The selected stack in figure 10 depicts a slight variation on MEVN, namely on the MongoDB, Express.js and Vue layers. In this paradigm, Strapi will act as a RESTful API server and whenever the client (Vue.js) needs access to the persisted data, it will send a request which will be handled by the server and it will send back a response with the resulting JSON object. The browser running Vue.js will then render the HTML pages using this data. Starting with the persistence layer, MySQL is used in every single application that the project offers and it contains all the necessary data for their functionality. Assuming a new MongoDB server instance is created, it would have to keep an updated read-only version of all the necessary databases (3.2) and extra local collections to ensure that it works seamlessly in tandem with MySQL, which requires a lot of processing power and maintenance. It would be the optimal solution if the back-office were to be a totally independent application but this is not the case, so, a compromise has to be made and that is to use the already existing MySQL instance, despite the loss of performance when handling persisted information (transforming result-sets into JSON instead of using only JSON like in MongoDB), it pales in comparison to the performance hit the MongoDB alternative would cause in the overall system.
3.4. Logical Data Model 26 Express.js is a very powerful framework that automatically creates templates with boilerplate JavaScript (Node.js) code and modularizes the REST routes in folders so that they are easily created and accessible. Strapi goes a step further and automatically generates CRUD routes for every table that it is given access to and it also offers complete compatibility. The administrator has access to a web application where they can visually set up the tables and their relationships, create permission levels and associate any route with them and use a complex querying system on any table to avoid using directly, just to name a few features. Evidently, this tool is extremely powerful and it still uses the ”blazing-fast” Node.js engine that Express.js is built on, while adding a few improvements and features that greatly improve the developer’s efficiency. Similarly, Vuetify is a framework that adds new user interface functionalities to Vue.js, by providing a wide variety of easy to use components that positively impact the user experience on the end product. It is extremely popular since it is an easy way for a developer to create complex-looking applications without having a deep understanding of CSS, since it is abstracted by the use of Vuetify-specific classes. It makes sense to use it in this particular back-office because it was also used in the other projects, which makes it is possible to reuse their components without ”reinventing the wheel” and adding new content pages quicker. In short, the final structure of the back-office follows a relatively close variant to MEVN with a front-end built using Vue.js and Vuetify, a back-end built with Strapi and Node.js and MySQL as the persistence layer, by tweaking or improving the layers in order to comply with the implicit rules imposed by the other micro-services. 3.4 logical data model The first step in implementing the functional requisites is designing the tables and relationships between them which will fill the ”hypati67_questoes” database. This can be done using a logical data model, as seen below:
3.5. Back-End Development 33 On a side note, there is no need to specify the existence of an ”id” field, Strapi automatically generates an auto-incremented one and hides it from the collection schema. These are the collections the back-end is currently using (translated to English) and the tables they link to: •School - ”escolas” in ”hypati67_aplicacoes” Figure 14: Strapi School Collection •State - ”estado” in ”hypati67_questoes” Figure 15: Strapi State Collection •Notification - ”notificacoes” in ”hypati67_questoes”
3.5. Back-End Development 34 Figure 16: Strapi Notification Collection •Question Backup - ”perguntas_backup” in ”hypati67_questoes” Figure 17: Strapi Question Backup Collection •Questions - ”Base_dados” in ”hypati67_testeconhecimentos”
3.5. Back-End Development 35 Figure 18: Strapi Question Collection •Hidden Question - ”perguntas_escondidas” in ”hypati67_questoes” Figure 19: Strapi Hidden Question Collection •Teacher - ”professores” in ”hypati67_aplicacoes” Figure 20: Strapi Teacher Collection •Quarantine - ”quarentena” in ”hypati67_questoes”
3.5. Back-End Development 36 Figure 21: Strapi Quarantine Collection •Deleted Submission - ”submissoes_eliminadas” in ”hypati67_questoes” Figure 22: Strapi Deleted Submission Collection •Theme - ”subtemas” in ”hypati67_testeconhecimentos” Figure 23: Strapi Theme Collection
3.5. Back-End Development 37 There are three more that are explained in section 4.4in more detail, including pictures: •Theme Order - ”tema_ordem” in ”hypati67_qrq” •Theme Image - ”tema_imagens” in ”hypati67_qrq” •Monthly Question - ”questoes_mensais” in ”hypati67_qrq” In this back-office, using relationships between collections is not particularly useful because all of them are done explicitly through queries using the knex NPM module. Configuring collection relationships are, in fact, useful when creating new applications that are not very complex in nature, which is not the case. For instance, Strapi does allow joining multiple tables but it does not allow nested selects in its query language, which is a major disadvantage when attempting to build API paths that require this operation. So, instead of using collection relationships in some cases and explicit queries in others, it is better to just stick with one for consistency and ease of maintenance which, in this case, is the latter. 3.5.2Creation of the API Endpoints One of the most time-saving features of Strapi is the automatic creation of commonly used CRUD routes. Whenever a new collection is inserted, the following paths are automatically added to the server: •GET /{{collection}} - returns a list with every entry in the collection; •GET /{{collection}}/count - returns the total number of entries in the collection; • GET /{{collection}}/:id - returns the entry in the collection with the specified id, if it exists; •POST /{{collection}} - creates a new entry in the collection; • PUT /{{collection}}/:id - updates an entry in the collection with the specified id, if it exists; • DELETE /{{collection}}/:id - removes an entry from the collection with the specified id, if it exists. Strapi saves theses routes in a folder, ’/api/’, which is automatically setup for each one of the defined collections. For example, the School collection is located in ’/api/escola’ and has the following structure:
3.5. Back-End Development 38 Figure 24: Strapi School Collection Folder The ’/config’ sub-folder only has one JSON file that defines the routes that exist for that specific collection. { 2"routes" : [ { 4"method" :"GET " , "path " :"/escolas" , 6"handler" :"escola . find " , "config" : { 8"policies " : [ ] } 10 } , { 12 "method" :"GET " , "path " :"/escolas/ count" , 14 "handler" :"escola . count" , "config" : { 16 "policies " : [ ] } 18 } , { 20 "method" :"GET " , "path " :"/ escolas /: cod" , 22 "handler" :"escola . findOne " , "config" : { 24 "policies " : [ ] } 26 (...) 28 ] 30 }
3.5. Back-End Development 39 This JSON file only has one object called ”routes” that defines an array of objects and each one of those elements are the defined API paths. The ”method” key refers to the HTTP method; the ”path”, as the name implies, is the API endpoint; the ”handler” is the identifier for the asynchronous function that is executed when that endpoint is accessed and the ”config” can have some complex security configurations that are not relevant for this application. The ’/controllers’ folder also only has one JavaScript file, named after the collection, where all the aforementioned functions are defined. Peeking inside it, this is the entire file: "use strict" ; 2 /* * 4*Read the documentation ( https :// str api . io/documentation/developer −docs/ l a t e s t / concepts/ c o n t r o l l e r s . html# core − c o n t r o l l e r s ) *to customize t h i s c o n t r o l l e r 6*/ 8const { s a n i t i z e E n t i t y } = r equ ire ( "strapi -utils" ) ; 10 module . exports = { async findOne ( ctx ) { 12 const { cod } = ctx . params ; 14 const ent it y = await s trap i . ser vic es . escola . findOne ( { cod } ) ; return s a n i t i z e E n t i t y ( e nti ty , { model : s t r a p i . models . e sc ola } ) ; 16 } } ; So, how exactly does Strapi connect the ”handler” keys to these functions? Analysing those keys reveals that they follow a pattern, a string followed by a ’.’ and another string where the first one defines the collection and the second one is the function in its correspondent ’/controllers’ file. The escola.findOne handler refers to the async findOne(ctx) function, which is visible above, for example. However, there are some functions that are not defined in this file, such as the one that ”escola.find” refers to. This is another of Strapi’s features, the automatically created routes have default functions that they use instead of copying and pasting them inside every single file inside the project. As seen above, the ”findOne” function is supposedly one of these default function but it is explicitly defined in the JavaScript file, which overrides the original one for that particular collection.
3.5. Back-End Development 40 The ’/documentation’ folder will be analyzed in chapter 6but it refers to the documentation for that particular collection. Inside the ’/models’ folder, there are two files: a JavaScript file and a JSON file. The first one is not used for this particular project, but essentially it allows defining additional behavior to the created collections such as relationships. The second one is the collection configuration, exactly as seen in figure 14, that contains the database connector, table name and attributes. 1{ "kind " :"collectionType" , 3"connection" :" aplicacoes " , "collectionName" :"Escolas" , 5"info " : { "name " :"Escola" , 7"description" :"" } , 9"options" : { "increments" :true , 11 "timestamps" :false , "populateCreatorFields" :false , 13 "draftAndPublish" :false } , 15 "attributes" : { "nome " : { 17 "type " :"string" } , 19 "cod" : { "type " :"string" 21 } , "localidade" : { 23 "type " :"string" } , 25 "distrito " : { "type " :"string" 27 } , "pais " : { 29 "type " :"string" } 31 } } Lastly, the ’/services’ folder also contains a single file and its intended purpose is to save some auxiliary functions or variables, as a way to make the code more organized and
3.5. Back-End Development 41 maintainable. This collection in particular does not contain anything inside this file, but the teachers one does, for example: "use strict" ; 2 /* * 4*Read the documentation ( https :// stra p i . io/documentation/v3. x/concepts/se rvi ce s . html#core − serv ices ) *to customize t h i s s er v ic e 6*/ 8const md5= require ( " md5" ) ; 10 module . exports = { validatePassword ( password , hash ) { 12 let code = md5( password ) ; return code === hash ; 14 } , fetchAuthenticatedUser ( id ) { 16 return s tra pi . query ( " professor " ) . findOne ( { id } ) ; } , 18 } ; In order to create custom endpoints, the following steps must be followed: 1. Define the function in the ’/controllers’ folder; 2. Create the necessary auxiliary functions in ’/services’ (Optional); 3. Add a new element to the ”routes” list in ’/config’ with the correct handler link, HTTP method and unique path. After repeating these steps for all the necessary API routes in every collection, the result is a very complete set of distinct paths that work in tandem with the front-end. The following routes are only the custom ones, since the default paths are common for every single one of them and they do the same thing. Documentation •GET /documentacao - contains the Swagger documentation for the back-end; •GET /documentation - exactly the same as the previous one.
3.5. Back-End Development 42 School • GET /escolas/:cod - overrides the original ’/escolas/:id’ since it is easier to access the code that identifies the school instead of the database auto-incremented identifier. State This one does not contain any custom routes, this table is only useful when joined with the submissions table, therefore the basic CRUD routes are plenty for what is required of it. Notification • GET /notificacoes/utilizador - returns a list with all the notifications that can be seen by the user that sent the request; • DELETE /notificacoes/utilizador - deletes all the notifications from the user that sent the request. Question Backup • GET /pergunta_backup - overrides the default route with a new one that lists every entry but removes questions of invalid types and with the correct text formats; • GET /pergunta_backup/:cod - overrides the original ’/pergunta_backup/:id’ since it is easier to access the question given its code instead of the auto-incremented identifier and applies the text transformations. Question • GET /perguntas - overrides the default route with a new one that lists every entry but removes questions of invalid types and with the correct text formats; • GET /perguntas/diretas - does the same as the previous one but it does not apply the text transformations; • GET /perguntas/visiveis - returns a list with all the questions that are currently marked as ’visible’; • GET /perguntas/invisiveis - returns a list with all the questions that are currently marked as ’hidden’; • GET /perguntas/exames - returns a list of all the distinct tests or exams in the questions table;
3.5. Back-End Development 49 Evidently, these are just the ones that are shipped with Strapi, an arbitrary number of other roles can be created. However, in this particular application, it is only necessary to know whether the user is authenticated or not, there is no need to differentiate between authenticated users since they are all teachers that belong to the same group. Considering that the ’Public’ role will only be used by anyone that has no token, they must not have access to any of the routes since an ill-intentioned intruder may cause irreversible damage to the database server. The only exception is the documentation endpoint, which must be available for any future developer that may use the API server. Figure 26: Strapi ’Public’ role and its linked handlers (Example) In contrast, the ’Authenticated’ role must have every box ticked so that the teachers can effectively use the platform. Were these boxes unticked, everytime they accessed the endpoint(s) that execute the asynchronous handler, they will be given a 403 - Forbidden HTTP status response.
3.6. Front-End Development 50 Figure 27: Strapi ’Authenticated’ role and its linked handlers (Example) The teachers will not directly use the API server, as this is something typically not humanreadable. It is the front-end’s responsibility to consume these endpoints and allow the user to have a more dynamic and human-friendly approach to them. 3.6 front-end development The selected technology is Vue.js, as seen in chapter 3.3, due to its numerous advantages both for the developer, the end-user and the Hypatiamat servers. Vue is a complex framework aimed at building responsive and reactive user interfaces, via a SPA approach. In order to mimic the behaviour of entering different pages inside the application, it uses a built-in router that injects the HTML content for that specific page, which is defined inside components. These are files that contain three sections: • template - an HTML-based syntax that defines the page’s layout with multiple quality of life features such as two-way data-binding, conditional rendering, reactivity and many other recent technologies; • script - will be executed as an ES6module in run-time and contains all behaviour regarding the page’s reactivity, computing and importing other components (children); •style - contains the CSS styles for that page (or its children). Because these components are written in separate files, it is possible to re-use them in other different applications as simply as pasting them inside the project’s folder without
3.6. Front-End Development 51 having to rewrite their content, if they do not include any component dependency, which will be explored in subsection 3.6.1. Henceforth, during this chapter, it is implicit that whenever any view is mentioned and it contains data of any kind, it should be assumed it came from the back-end API server mentioned in the previous section, as the ’script’ module inside each component can have HTTP requests executed via JavaScript and their response data can be saved using local variables or browser storage. 3.6.1Initial Setup When compared to the back-end server, the front-end was had a quick and straightforward process to get its development started due to it being a completely isolated entity that only interacts with the API endpoints using HTTP requests. As seen in section 3.1.2, the interfaces need to be consistent with João Vieira’s TPC management back-office. They were also built using Vue.js and with his and Hypatiamat’s permission, it is possible to re-use the most important ones for this project aswell, namely the authentication and main layout components. This modularity brings an effective way of building cross-platform components, which will be great for any future application that needs to be developed following these guidelines, as they do not need to be rebuilt and mimicked from the ground up and avoids the risk of not exactly matching the original in both behaviour and appearance. The next step is to construct the views themselves in order to complete the requirements set at the beginning of the project, which does not require any initial setup. 3.6.2Creation of the Interfaces The interfaces are effectively where everything is linked together, the business logic, persistence and view layers work together to allow the back-office to have its requirements fulfilled. There are 10 different pages in total, each using a different Vue component, and they suffered an incremental process where features and design were tweaked in order to achieve a good work environment for the teachers, where the priority was keeping them simple and intuitive. A logical first step is mocking up the interfaces in order to provide Hypatiamat with a concise idea of what the end application would look like, they are not meant to be the final version but rather a guide to what should be expected of it. These prototypes also ensure that no time is wasted on developing an interface in real-time since they may not work as envisioned.
3.6. Front-End Development 52 If the idea and design is approved, it will then pass to its development phase in code. In the following sub-sections, the final interfaces will be compared with their mock-ups in order to show the process behind creating a finished functional product. On a side note, all these interfaces were prototyped using Justinmind, a popular tool that contains many readily available components such as buttons, forms, text inputs and geometric shapes for use in designing interfaces for any screen size or pixel density. Authentication This is one of the few interfaces that did not need to be prototyped first before developing, because the Vue component itself is being reused from João Vieira’s project, who conducted their research on the matter and concluded this would be the final design to be used in the application. Figure 28: Authentication Interface This is a very simple interface and it has two main components: a body and a footer, it does not have the navigation bar on the left side yet because the authentication process has not been completed yet. The body has a simple authentication form where the user inputs their username or e-mail and password and, if these values are validated by the back-end, they are successfully logged in, granting them access to the back-office. The footer contains the links to Hypatiamat’s social media platforms and a small information modal that contains some credits to the author and supervisors of the project.
3.6. Front-End Development 53 Dashboard The dashboard, on the other hand, suffered some changes when compared to its mock-up (figure 118). The first major change was the inclusion of two graphs using the ”highcharts” NPM module: 1. Submission Distribution - uses a pie chart to represent the total number of submissions and the users that created them; 2. Current Submission State - semi-circle pie chart that represents the percentage of the user’s submissions with a given state (pending, accepted or rejected). Figure 29: Dashboard Interface The second was on the notifications themselves, which were simplified to align the text to the left side and including a redirection button on the other side, which makes it more visually appealing than the prototype. Some additional information such as the submission’s state was also added and the title was reworked to better represent the two different notification types. Submission Form This is the most complex interface in the entire application because it contains many details and it suffered the most changes when compared to its prototype (figure 119). It was clear from the start that there needed to exist a form of some kind in order to allow the teacher to fill the fields in their entirety with the correct information, however, there exist
3.6. Front-End Development 54 some steps that have an extra complexity layer in order to fulfill Hypatiamat’s needs and improvement requests. Instead of having a single-page form, it has been divided in segments using a stepper component (Vuetify). In the first step, the form has been improved visually by using titles in order to remove the cluttered and clumped together fields that the prototype has. Figure 30: Form Submission Interface (1st step) The input fields equate to every column on the database, except the questions and answers themselves. Due to their large variety of different types, there have to be some auxiliary interface elements in order to complete an effective algorithm that takes these elements and figures out the correct types and underlying columns. These auxiliary elements are the type and sub-type selectors in the section for filling the question information, which change the answers input fields accordingly. When the question is a multiple choice, the following changes will occur in the interface according to the selected sub-type: • Text - since the number of answers can range from a minimum of 3to a maximum of 6,3input text fields are created by default. The last input will always contain two buttons, one that increments the number of fields up to 6and one that removes a field, down to 3. It is very intuitive to use and allows the teachers to rapidly create or remove answers without having to leave the one they are currently working on.
3.6. Front-End Development 55 Figure 31: Form Submission Interface (1st step) - Text Multiple Choice • Image - the range displayed above does not apply here, only 4answers are allowed and they must all be images. Therefore, each one of the answers must be a file input instead of text, allowing the users to submit images from their own computer and previewing them using the eye icon on the right side of each one of these fields. Figure 32: Form Submission Interface (1st step) - Image Multiple Choice Regarding the open-ended questions, they have 6different types that dictate their ’auxiliar’ column (more information in chapter 3.2.2) and thus need to be explicitly defined:
3.6. Front-End Development 56 • There only exists one answer and that is the correct one - this would give a value of 1 to the ’auxiliar’ column. Since there is only one accepted answer, there only needs to exist a single text input field for it and the optional unit of measure. Figure 33: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 1 • There only exist two answers and both are correct - same as before but creates only two input fields, giving the ’auxiliar’ column the value of 1000. Figure 34: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 1000 • Multiple answers and all are correct - this would give the ’auxiliar’ field a value of 0. It works similarly to the text multiple choice answers, reusing the increment/decrement buttons but this time for a minimum of 1answer, instead of 3.
3.6. Front-End Development 57 Figure 35: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 0 • Equivalent fractions - ’auxiliar’ is 22 in this case. There are two input fields, one for the numerator and one for the denominator, along with the optional unit of measure. Figure 36: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 22 • Irreducible fraction - the ’auxiliar’ column is 2and it has the same fields as the previous one.
3.6. Front-End Development 58 Figure 37: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 2 • Protractor required - the ’auxiliar’ column is 10 and it indicates the need of a protractor, requiring two text input fields that contain the lower and upper ranges of the accepted values. Figure 38: Form Submission Interface (1st step) - Open Ended, ’auxiliar’ 10 The true and false questions are very simple, as they only need two input fields for the true and false or its equivalent expressions.
3.6. Front-End Development 65 If they confirm that they want to submit the question, they get an alert that a new submission was created and they can now freely leave the page. Naturally, this entire process is very similar in editing submissions or questions. The first difference is in the first step, where the fields come automatically filled with the question’s information, because it would make no sense to force the user to input the fields manually when they are already persisted in the database. Figure 50: Form Submission Interface (Edit) - 1st Step The next difference is on the steps 2and 4. Instead of giving the user only one option, which is whether to use a template or not, they now have three different options: Figure 51: Form Submission Interface (Edit) - 2nd and 4th Steps
3.6. Front-End Development 66 This selection menu replaces the first one if the question/submission does not contain the reference or resolution image, otherwise it just follows the same flow as before. The first option allows the user to edit the current saved image, which will open the ToastUI editor in step 3or 5with it; the second one, if checked, completely removes the image from the question or submission being edited and the third one, if selected, opens the template menu for that particular step and opens ToastUI with it in the following step. If no option is selected, the image is kept as it is with no changes. Approved Questions This one suffered very little changes when compared to its mock-up (figure 120). The main difference between the two is the way the questions list is presented, where in the final version it ended up becoming a table for a number of reasons. First, it allows the user to display the items in the table in ascending or descending order of the columns. Second, it is more organized and more intuitive to understand what each field represents. Third, it allows a larger ammount of information to be displayed in a more compact manner. Figure 52: Approved Questions Interface Instead of hiding the filters, this version leaves them fully visible for the sake of convenience since it would be counterproductive to hide them from the teachers when it is expected that they will use them frequently. The filters are also executed in real time and simultaneously, allowing the teachers to get specific questions that fit their criteria quickly and efficiently. Each of the table’s items can be expanded, showing a preview for the selected questions. Its structure is transversal to every one of them, containing only four main elements:
3.6. Front-End Development 67 • Question statement; • Answer(s); • Reference Image (optional); • Resolution Image (optional). The only difference that may appear is in the answers component, since they depend on the question’s type, just like the previous interface. The multiple choice questions have two types, and they change the preview accordingly: • Text - the answers ranging from 3to 6are displayed in sequence. The first one is considered the correct one, which the preview represents with a green check mark after the answer itself. Figure 53: Approved Questions (Preview) Interface - Text Multiple Choice • Image - similar to the text answers, except images are displayed instead. Figure 54: Approved Questions (Preview) Interface - Image Multiple Choice
3.6. Front-End Development 68 As for the open-ended questions, they change according to the value of the ’auxiliar’ column in the database: • 1There is only one answer that is considered correct for that question and it is displayed below the input. Figure 55: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 1 • 1000 - there are only two answers that will be considered correct for that question, displayed sequentially below the input field. Figure 56: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 1000 •0similar to the previous one, except there can be up to 6answers.
3.6. Front-End Development 69 Figure 57: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 0 • 22 - the answer can be any fraction equivalent to the one displayed below the input field. Figure 58: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 22 • 2the answer can only be the irreducible fraction in the answer displayed below the input field.
3.6. Front-End Development 70 Figure 59: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 2 • 10 - the answer must be calculated via a protractor and it must be between the lower and upper bounds defined below the input field. Figure 60: Approved Questions (Preview) Interface - Open Ended, ’auxiliar’ 10 The true or false questions are very similar to the text multiple choice ones, the difference is that they only have 2possible answers instead of a minimum of 3. They also display the check mark after the first answer to indicate that it is the correct one.
3.6. Front-End Development 71 Figure 61: Approved Questions (Preview) - True or False As it was shown in the previous interface section, the symmetry questions can either be: • Vertical Figure 62: Approved Questions (Preview) - Vertical Symmetry • Horizontal
3.6. Front-End Development 72 Figure 63: Approved Questions (Preview) - Horizontal Symmetry The grid color scheme is also kept, where orange indicates the symmetry question statement and green refers to the expected solution, i.e, the correct answer. After the preview, the operations buttons were also slightly redesigned, so they appear cleaner and tidier. Their function is to edit, remove or hide the question, respectively. Active Submissions List As it was the case with the approved questions list, this interface also changed from what was prototyped (figure 121) to a table-based approach for the same reasons as before. Figure 64: Active Submissions List Interface
3.6. Front-End Development 73 There is no need for a filter because not many submissions will be active at any given time and they are ordered by default from the oldest to the most recent, ensuring that older ones are not left forgotten. One small addition was the inclusion of a check box that displays the user’s submissions, which are hidden by default. The reason for this is because they can not be accepted by the same person that submitted them, they would just clutter the list with submissions that would obfuscate the ones that are from someone and are currently pending approval. The same previews as before are reused here to give visual information on how the question looks like to the user, instead of using text-intensive approaches. The buttons were reworked once again to fit the design of the page and to be more visually appealing, and their functions are to approve, edit or reject the submission, respectively. Hidden Questions Similarly to the last two interface sections, this one also swapped to a table-based view instead of what was planned at the beginning (figure 122). Figure 65: Hidden Questions List Interface This one only has one button, that follows the same design as the other ones for the sake of consistency, and its function is to mark the question as visible. Submission History The table-based approach is also used in this interface, instead of the prototype’s initial idea (figure 123).
3.6. Front-End Development 74 Figure 66: Submission History Interface This page’s main quirk is the division of the submissions in three different tabs: pending, accepted and rejected, respectively, that contain them listed using the aforementioned table. The main advantage of this design is that it is more efficient, if the questions were grouped in a single table it would be necessary to use filters, which would also make the page more cluttered and cumbersome to navigate. There is also additional information after the preview for each submission, where it appears who accepted or rejected the question and the reason why, which the user can take as feedback and re-submit the question for approval if they deem necessary, otherwise they can just delete them. Order Themes This was a very straight implementation from its prototype (figure 124), since the concept itself is quite simple and there is not much room for improvement. It was only slightly redesigned to be consistent with the other interface’s color scheme, mainly in the color of the theme list containers.
4 I WANT TO SOLVE QUESTIONS ABOUT... This chapter denotes the development of the new ”I Want To Solve Questions About...” application, which is similar to the back-office in terms of its underlying architecture. As it was the case previously, there needs to be a first step of understanding the problems and thinking of ways to fix them before attempting to develop the code and logical models themselves. Creating a coherent final product that aligns with the teachers’ vision is fundamental not only for the products success but also for the platform’s relevance in the market. 4.1 requirements specification According to the teachers, the previous application does not fit their needs, both visually and technologically, hence the need for the creation of a new one that attempts to mitigate these issues. As it was the case with the previous chapter, this section is extremely important not only to understand what the teachers require from the new application, but also what exactly is wrong with the current one, so that a consensus can be reached on what needs to be changed and why. Therefore, it is important that before any code is developed, all the features are outlined and fully understood before committing to the task, where its complexity lies in how the interfaces can have improved usability and appeal. These improvements should also give the students a more complete and organized application to work with, which should further improve the way the consume knowledge in it. 81
4.1. Requirements Specification 82 4.1.1Functional Requirements The goal of this application is to replace the current version in production, currently lacking in a modern user interface and technologies, causing it to not work properly in mobile devices such as tablets and phones. As such, the main improvements that need to be done are on a visual level, specifically the uncluttering of the information displayed to the user at once, and making sure that the consistency with the other Hypatiamat’s applications design choices. The following figures represent its current state and can be accessed at the following URL: https://www.hypatiamat.com/questoesde/resolverquestoesde.html. Figure 72: Current ”I Want To Solve Questions About...” landing page The landing page of the current ”I Want To Solve Questions About” is relatively simple to understand, as it is just a theme selector (the big squares on the image) with three pages, currently. On the left and right sides, the user can go to the next or previous pages by clicking the yellow arrow buttons. Note that the theme selection concept itself, despite its outdated look, is not exactly a bad design choice for this applicaton, it works perfectly well on a mobile environment due to its oversized buttons and in the computer aswell, since it can fit the screen with more items according to the user’s resolution or screen size. This particular application does not take that into account due to technological limitations, it simply scales down the canvas size in order to fit the screen, rendering it completely unusable in smaller screens.
4.1. Requirements Specification 83 The order of the themes is also hard-coded, something that the teachers deeply regret doing as they can not easily change their order. In the new version, it is expected that the themes appear in the set order saved in the back-office. Another thing that looks somewhat out of place in this page are the buttons in the bottom left corner, which represent the user’s favourite questions, a search bar and instructions, and on the top right corner, which is a simple login button. Instead of having them clutter this page, because they look like afterthought additions instead of design choices, it is better to give them their own dedicated areas on the new interface. Figure 73: Current ”I Want To Solve Questions About...” question solving page Whenever a theme is picked, this page will be shown to the user with the questions for that particular theme. On the left of the canvas there is the sub-theme selector and, once they click one of them, the question solving screen will be appear in the center of the screen. On the top of the screen, the question’s code appears on top of the question statement and the page’s numeration on the right. There is also the difficulty selector right at the middle, represented by the buttons from 1to 5and a T that represents any difficulty. On the reference picture at the right side, there is a small star on its top left corner, which allows the user to mark this question as a favourite. However, it only allows the user to have one list, which needs to improve in the new application and scale to any number of lists, similar to how YouTube implements it. This is a direct requirement from the teachers, since they could create these lists with some questions for their next classes, which is currently unfeasible with the available version. This would also benefit the students, as they could save their favourite questions and browse through them quicker due to them being better organized.
4.1. Requirements Specification 84 There are three other buttons on top of the image that enable a protractor, show the favourites list and open a search bar, respectively. The first one should not be enabled by default, as only one specific type of question makes use of it, so it just becomes useless and wasted space in all the remaining types. The second one, opens the favourites list, which was explained above. Figure 74: Current ”I Want To Solve Questions About...” favourites page The way it displays the information does not fit its purpose. Every item on the drop down list contains only the code, theme and date when it the question was added to the list, which does not suffice the teachers’ needs. They have no way of quickly navigating to the question other than memorizing those codes and typing them in the search bar, which is the third button. This problem also applies to the students, it is not expected of these young students to memorize the codes either. This is another improvement that must be done in the new application, reworking the favourites to grant all these features. Figure 75: Current ”I Want To Solve Questions About...” search bar
4.1. Requirements Specification 85 The search bar, simply put, is inefficient and inadequate. The only way for the user to search a specific question is by knowing its specific code and the user should never have to memorize anything that can possibly be over 10 digits long, considering that there are over 3000 questions in the database currently. Therefore, the teachers asked for a major improvement on this functionality and allow the user to search questions based on any of their meta-data, not only its code. On the bottom right side, the previous and next buttons indicate that the user can scroll through all the questions in that particular sub-theme, whenever they want to, an unlimited number of times. This is not something that will be kept in the new application, the idea is that unauthenticated users can only view up to 5questions maximum of all themes and sub-themes combined per day, whereas authenticated ones have unlimited access, in order to incentivize them to create an account on the website and make use of all of its features, which is proven to boost overall engagement and assiduity in the platform. The page also features a ’Like’ button, which works as intended and the teachers and students are happy with its functionality, where the users can only use it if they are logged in, which avoids them maliciously trying to break the website and, in case they do, they can be tracked more easily. The page overall is efficient and intuitive, it only needs some slight touch ups to ensure that it is on par with the other Hypatiamat applications. Along with these improvements to the existing features, the new application should also implement new ones to further deepen and boost its gamification factor. These should also be locked behind authenticated accounts, so that ”free” users consider creating an account even more. The first gamification feature is the monthly questions, which was explained in detail in section 3.1.1. The existence of a leaderboard that keeps track of how many correct answers the students got each month is fundamental for this feature’s success, since it incentivizes them to solve the questions correctly by making them compete against each other. It should be updated whenever the monthly questions reset, which is on the first day of each month, and should be organized by school year. After this reset, these questions should be added to an history (also explained in 3.1.1), so that the users can see if they got the questions wrong or right and their respective resolution. 4.1.2Non-Functional Requirements The first part of these requirements are exactly the same as the ones in 3.1.1, i.e, making sure that the interface is consistent with all the other applications in the platform.
4.2. Initial Assessment 86 There is one major difference between the two, which is not only being compatible with the popular browser choices, but also with multiple mobile devices. In this application, it is no longer considered a bonus to support these devices, but a requirement, since many of the students have tablets at their disposal. The currently solution is scaling the canvas itself, suitable for when the user is using a computer. However, if they swap to a smartphone or tablet, the buttons become too small to use, which severely hinders the application’s usability. On the new application, the interface itself should be responsive and change according to the device the user is on, which is possible using the current available technologies. 4.2 initial assessment As seen in section 3.2, the Hypatiamat database server already contains a large number of tables, some of which were relevant for the back-office. In this application, both databases will be also be necessary, i.e, both the teachers ("hypati67_aplicacoes") and questions ("hypati67_testeconhecimentos") and all their related tables, for the same reasons as the ones explained in that chapter. It will not access any of the back-office’s specific tables ("hypati67_questoes") since it will only display non-quarantined questions. The first extra database was created to allocate space for all the new tables related to the back-office, which contains a bunch of tables automatically generated by Strapi. If one were to use two Strapi instances on the same database, they would rewrite each other and soon become unusable, which is something that needs to be avoided in order to ensure that the applications work in parallel. In the next section, it will be defined that Strapi will be the choice for the back-end of this application, just like the back-office. Therefore, there is a need to create a new database for it, in order to contain all the new tables necessary to implement the set requirements. After contacting the owners, the final name will be ”hypati67_qrq” and will be initially empty, as expected, where it will be the new back-end’s responsibility to manage, since it will have full permissions on it. As it was the case previously, any database schema or image in the following sections will be a simplified version of the current database, since it is a complex database with many relationships and tables intertwined. 4.2.1Favourites One of the requirements is the rework of the favourites feature that the previous application provides.
4.2. Initial Assessment 87 In the ”hypati67_testeconhecimentos” database, there is a table called ’favoritos’ containing all the favourites of every user: •id - auto-incremented primary key; •coduser - foreign key to the users table; •codquestao - foreign key to the questions table; •folder - legacy column, every entry has the value ’root’ and is currently unused; •nome - legacy column, every entry has a string value and is currently unused; •datacriacao - date when the favourite entry was created by the user. As a reminder, the requirement was that instead of only having one list of favourites, there should be the possibility for the user to use an arbitrary number of lists, for better organization and efficiency. Another important requirement is that the new application should not break previous Hypatiamat services, such as massively changing the tables’ structure. Thankfully, in this case it is rather easy to implement this feature by making use of one of the unused columns which is conveniently named ’folder’ and its functionality would the same as the required lists. By allowing the user to create new folders, it is possible to save different favourite entries according to its folder, which means that the user could, in theory, create any number of folders they like. Note that this would not break in any way the existing applications, as this field is unused and any of the ’root’ entries would be considered the default folder for legacy accounts. The current ”I Want To Solve Questions About...” would also work the same way as it currently does, it would simply list every folder as if they were a single list because it does not take this column into account, only the new version would show the division correctly. 4.2.2Likes The current version of the application currently has a feature that allows the user to add or remove likes on questions, allowing other users to see the approval rate of the question (higher is better). The table is called ’likequestions’ in ”hypati67_testeconhecimentos” and it is very simple in nature, as it only needs to save which user placed the like and where: •id - auto-incremented primary key; •user - foreign key to the users table;
4.3. Technology Selection 88 •questionid - foreign key to the questions table. It does not need any changes nor additions, its structure will be kept for the new application aswell. 4.3 technology selection The technology selection was a straightforward process, as the reasons behind them are the same as the ones discussed at 3.3. Figure 76: Technological stack for ”I Want To Solve Questions About...” In addition to the numerous benefits detailed in the aforementioned section, it will also allow a quicker and easier development of responsive interfaces for multiple devices, as Vuetify features an extensive library of built-in components that scale according to the screen size and resolution. Another great benefit of keeping the same technological stack is that Vue also allows the developer to reuse interface components, as long as they do not have any pending dependency. Not only that but also some configuration files from Strapi can also be reused, specifically the ones that relate to the questions and teachers tables, they do not change since the connection parameters are exactly the same, another great benefit of keeping the same back-end technology.
4.4. Logical Data Model 89 MySQL will also be kept as the only persistence layer, as the overhead of creating a new database server does not outweigh the performance improvements they could potentially bring for the same reasons as before. 4.4 logical data model The logical model below only adds four extra tables and relationships to the existing ones in ”hypati67_testeconhecimentos” (chapter 3.4) in order to fulfill all the set requisites. Figure 77: Logical data model for ”hypati67_qrq” (Simplified) Starting with the themes, the front-end application needs to display them by the currently saved ordering system, which is represented by the ”tema_ordem” table. Its structure is simplistic: •id - auto-incremented primary key; • ordem - integer from 1to N, where N denotes the total number of different themes currently in the database and it represents the current order for each one; •temacod - foreign key to the theme. Each theme has an image associated to it, currently hard-coded in the original application, as seen before. By using a new table, it is possible to create or edit these links in the back-office, since every theme is supposed to have one. Therefore, the creation of the table ”tema_imagens” is necessary for the new application to correctly display the user the intended picture for each case: •id - auto-incremented primary key;
4.4. Logical Data Model 90 • image - name of the image, the URL is obtained by concatenating it to the back-end’s static resources endpoint; •tema_cod - foreign key to the theme. The monthly questions, as the name implies, are questions that teachers highlighted for a particular month of a given year, organized by categories (3.1.1). The table ”questoes_mensais” has all the necessary fields in order to save this data: •id - auto-incremented primary key; •year - year the question appears in; •month - month the question appears in; •categoria - the question’s category; •data_alteracao - date when the question was added to the monthly questions; •codquestao - foreign key to the questions table. The students have the option to submit their resolutions on the current rotation of questions, so that they can later have their position on the leaderboard updated. Therefore, they need to be persisted in a table, which in this case is ”questoes_mensais_resolucoes”: •id - auto-incremented primary key; •year - year the question appears in; •month - month the question appears in; •categoria - the question’s category; •resol - the answer the student gave; •resolvido_por - foreign key to the student table; •resultado - whether the answer is correct or not (saves computational efforts later); •codquestao - foreign key to the questions table. With the logical model fully complete, it is now possible to start the development of the back-end server, which is the next section.
4.5. Back-End Development 97 5} , "user " : { 7"id" :40182, "user " :" hypatia01 " , 9"numero" :1, "nome " :" Hypatia 01" , 11 "datanascimento" :" 12/12/2012" , "escola" :" hypatia01 " , 13 "turma " :"3A-21-1" , "email " :" agoraninteressa@nexiste .pt " , 15 "password " :"4297f44b13955235245b2497399d7a93" , "codprofessor" :"hprof2" , 17 "pais " :" Portugal" , "confirmacao" :1, 19 "published_at " :"2021 -04 -14 T22 :48:34.000Z" , "created_at " :null , 21 "updated_at " :null , "type " :" aluno" 23 } } The front-end will then be able to differentiate between these two types of user accounts and change the interfaces accordingly. 4.5.4Protecting the API In chapter 3.5.4it was revealed that every single API endpoint was protected by the authentication procedure. However, in this new application the user is not only teachers but also students and they may opt to use the limited unauthenticated features that the website provides, such as solving at most 5questions daily. By using Strapi’s default ”Public” role, any endpoint that is added to it will not require the user to be authenticated.
4.5. Back-End Development 98 Figure 85: Strapi ’Public’ Role - Questions API In contrast, the ”Authenticated” role will require the user to add their JWT authentication token to the request, such as the monthly questions that the free users will not be able to access unless they create an account. This effectively prevents the free users, even if they somehow manipulate the interface to bypass the built-in functionality of blocking their access to the monthly questions, from consuming the API endpoints directly and getting that information. Figure 86: Strapi ’Authenticated’ Role - Monthly Questions API This marks the end of the back-end development and the creation of the API endpoints, which will be consumed by the final front-end application to complete the new version of ”I Want To Solve Questions About...”.
4.6. Front-End Development 99 4.6 front-end development 4.6.1Initial Setup The new interface will be built using Vue.js, making it possible to re-use the back-office’s front-end components previously developed. In addition, João Vieira also developed a digital keyboard that will be useful for open ended questions, where some symbols such as the infinity and square root are built-in with the correct formatting (Vieira,2021). Figure 87: First iteration of the digital keyboard (João Vieira) However, the keyboard itself does not have a fitting color theme, making the characters harder to read. For example, the red button with black text can only be properly read if squinting or giving it a lot of attention. The same can be said for the green and yellow buttons, however the effects are much more diminished than the previous case. Figure 88: Second iteration of the digital keyboard By making the characters white on the keys that have the aforementioned background colors, it becomes much clearer and easier to read at a glance, which the students will appreciate in the long run. It was slighly enlarged for better readability aswell. This is the version that will be used in this application, with João and Hypatiamat’s permission.
4.6. Front-End Development 100 4.6.2Creation of the Interfaces The application itself is very similar to the previous back-office, in terms of its design. This is intended as every single Hypatiamat service, as mentioned before, needs to maintain consistency with all the others. Keeping the green and white color palette and the navigation bar on the left is the only way to achieve that, as all the others applications follow these exact same rules. Every single interface went through a large number of iterations, where the final product was approved by the Hypatiamat team for production. Authentication The first front-end application had to force the user to authenticate before attempting to use the application, something that is not needed here. ”I Want To Solve Questions About...” does not lock the user behind an authentication wall, it just incentivizes them to do it, due to the question blocking requirement. Therefore, it makes sense to allow the user to login whenever they want to and allow them to see the website in its entirety. By using a login modal, the user is not redirected to a specific login page, allowing them to continue their uninterrupted workflow in the application. Figure 89: Authentication Interface This modal blocks the entire website behind it and dims its color, emphasizing the authentication screen and giving the user the option to either quit it or input their login
4.6. Front-End Development 101 data. Either choice will not redirect them out of the current page, it will simply remove the modal and the dimming effect from the screen. Theme Selector The theme selector is very similar to the current version of Hypatiamat, the only difference is that the images were reworked in other to fit the green and white color palette. The prototype (128) is also similar to the final version. Figure 90: Theme Selector Interface Every theme image also contains a rounded green border, for contrast and visual appeal. Note that the layout is not static, the themes shift around according to the screen size and resolution. For example, this is how it would look like in a tablet:
4.6. Front-End Development 102 Figure 91: Theme Selector Interface (Tablet) This way the application works seamlessly between devices, without the user having to worry about compatibility issues. Question Solving The final version of this interface is very similar to its prototype (figure 129), which in turn is based on the current version of the application. The main issue with the current live version is that the screen is too cluttered, which makes the sub-theme selector occupy too much space on the screen and rending it not intuitive to use.
4.6. Front-End Development 103 Figure 92: Current Question Solving Interface Instead of having the sub-themes on the left side of the screen, it is better to list them on top, since the user must first choose one before being shown the questions themselves. It makes for a much cleaner interface, where the information is presented from top to bottom, there is no visual clutter in between. Figure 93: Question Solving Interface
4.6. Front-End Development 104 At the very top of the page, there is the back button represented by two left chevrons with the theme’s name next to it, allowing the user to quickly return to the theme selector if they want to. The difficulty selector itself was slightly reworked from the original version. Figure 94: Current Question Solving Interface (Difficulty Selector) The numbers 1to 5represent difficulty levels and the character ’T’ represents any difficulty. All of these buttons can be toggled, filtering any question that is not of that difficulty level. By taking a look at these definitions, the ’T’ character is redundant since if all the buttons are toggled, it essentially means that the user wants the questions of all difficulties. Figure 95: Question Solving Interface (Difficulty Selector) This simplifies the interface a bit and makes it more intuitive, the user simply selects all the difficulty levels they want, where they are all selected by default. Next up, regarding the original search functionality (figure 75), it needed a rework, as it was previously mentioned. By placing a magnifying glass next to the difficulty selector (it works as a type of search, in a way, so it makes sense to group them together) that opens up a search modal.
4.6. Front-End Development 105 Figure 96: Question Solving Interface (Search) The filters work exactly the same as the ones on the back-office, the user simply has to write anything they might remember on the question(s) and, if it/they belong(s) to that theme and sub-theme, it/they will appear in the same page seamlessly. Figure 97: Question Solving Interface (Favourites)
4.6. Front-End Development 106 The favourites (figure 74) also needed to be reworked due to their poor functionality and lack of customizability. Instead of allowing the user to only use a single list, they can now create multiple lists on the fly and add the question to any of them. This menu is accessed by clicking the green star button on top of the image, just like the original version. This interface is also very similar to YouTube and its playlists, which served as direct inspiration for this interface and it is an efficient way of solving the issue. The like button below the image was just slighly tweaked to fit the green and white theme better, its functionality and flow are kept the exact same. The interface where the question actually appears and allows the user to solve it just has to take four different types of question into account. Every single question hides its resolution, if it has one, and only enables it if the user has gotten the wrong answer three times in a row. For every answer the user submits, it can either be correct (green) or incorrect (red) and it is displayed accordingly, along with a sound for better audiovisual feedback. • Open-Ended - the different types of open-ended questions are not visually different, they are just background checks. What matters is the single input field that the user interacts with, via the digital keyboard. If the user submits a correct answer, the keyboard is disabled. Figure 98: Question Solving Interface (Open-Ended) - Incorrect
4.6. Front-End Development 113 Figure 110: Monthly Questions Interface The question preview screen is a slight rework on the one used at the back-office. The only addition is a red cross for the wrong answers that the user submitted. This way, the users can quickly view the correct answer, what their answer was and the resolution for it, in case they need extra help. Leaderboards The leaderboards had some improvements done to it in relation to its mock-up (figure 133), mainly focusing on presentation and gamification for better student engagement. The leaderboards are divided by school year and category, where the user can see where they place in relation to their peers, according to their monthly questions performance.
4.6. Front-End Development 114 Figure 111: Leaderboards Interface The first major change was the addition of bronze, silver and gold trophies for the third, second and first places, respectively. This adds a bit of a competition between the students, so that they have a reason to reach the number one spot. The next was the addition of the score itself, having it hidden makes no sense because the user ends up knowing if they got the question wrong or right, it is better to simply show them as a differentiating factor. 4.6.3Saving the Blocked User State One of the requisites for this application was that unauthenticated users get blocked after viewing five different questions daily. In order to achieve this, there are two different possible approaches: • client-sided - keep a local counter on the browser and if it reaches the daily limit, block the user’s access to the interface; • server-sided - save the user’s IP address after the limit has been reached, needs constant polling after a question is loaded to ensure the limit has not been reached yet. The second option is not ideal for this particular use case, despite it being the safer approach, making the client-sided approach the better fit. The first reason is due to security risks not applying for a question solving application, the authentication is optional and the questions are free to begin with, there is no need to even consider it when everything is publicly available.
4.6. Front-End Development 115 The second reason is that the target audience are primarily young students, many of them with limited technological knowledge, let alone understanding how a full-stack web application works. Therefore, implementing complex server-sided solutions is a much worse strategy than implementing simple and yet effective client-sided blocking strategies, which can be easily done with Vue and Vuex. In addition to the user state that was developed for the back-office, that will be reused for this application, there also needs to be a new module dedicated to this blocking procedure. The first variable that needs to be taken into account is the viewed questions list, which needs to work as a set, ensuring that no repeated elements are contained within it. The second is the limit itself, defaulted to and it is only used to limit the set’s size and verify whether the cap has been reached or not. The last one is the date when the block will be removed, if it exists. Since this information is persisted in the local storage, when restoring the Vuex timer instance it needs the information to restart it. Figure 112: Timer Interface The flow is also simplistic, whenever the user views a question, it is added to the set. If the limit has been reached, it simply blocks the user from clicking the previous and next buttons and displays the blocking modal instead, visible in the picture above. This concludes the development of the front-end server, all that remains is deploying both applications, which is the focus of the next chapter.
5 DEPLOYMENT The Hypatiamat services are hosted in PTServidor, a portuguese company that provides web services and domains. Since all the new micro-services on the platform need their own domain and address, they are all managed by an instance of a NGINX server acting as a reverse proxy for all of them. In this particular case, 4new domains need to be created, namely the two back-end and front-end servers for each application. Evidently, these are web applications developed taking only HTTP requests in consideration, so, it is only necessary that these domains provide these services, resulting in the following URLs being made available: •Question Submission Back-Office 1.https://apibckqr.hypatiamat.com - back-end server; 2.https://bckqr.hypatiamat.com - front-end server, •”I Want To Solve Questions About...” 1.https://apiqr.hypatiamat.com - back-end server; 2.https://qr.hypatiamat.com - front-end server. Naturally, tests were done before being placed in production, in order to ensure that the applications’ existence would not cause any damage, especially to the databases. Rolling out the current application versions into a production build was made easier by the GitHub repositories where their source code was hosted. Essentially, there is one for each server and there is a copy from all of them saved locally, so they can be easily updated after any future change. The deployment process for these entities (back-end and front-end) differs from one another, so they will be explained in different sections. 5.1 back-end servers There are many ways to deploy an API server, however, Hypatiamat is currently using PM2, a process manager package for production usage, for all its micro-services built with Node.js. 116
5.1. Back-End Servers 117 This tool allows for better maintenance and its features include a CLI interface, auto-start scripts, load balancing, logging, and many others, which is a great way to ensure that the applications work flawlessly while they are live. The deployment process is identical to both back-end servers, and they both include creating a new PM2instance for each one. Whenever a new production build is ready to be deployed, the first step is updating the repositories to the most recent version. On a typical Node.js server, it would suffice to execute the following command on the file that contains the code related to starting the HTTP server: pm2s t a r t server . j s However, this particular file does not exist in Strapi and, as such, PM2can not start a new instance on it. However, due to popular demand, Strapi’s creators already sorted this issue in previous versions, but it has to be done manually by the developer. The solution is creating a new JavaScript file inside the server’s root folder, where the Strapi server instance is manually started, which has the exact same behaviour as if it was started in the command line using NPM or Yarn. 1const stra p i = require ( 'strapi') ; 3stra pi ( ) . s t a r t ( ) ; This way, the previous command can now be executed using this file (assuming it was named ’server.js’, just like the example above), and the server can now be a PM2instance and thus benefit from its features and interfaces. After being created, it will be given a new identifier which, as an example, let it be the number 0going forward. PM2does not copy the current files to a new folder in order to create a new server instance, it simply saves the folder where they are located. This way, whenever the back-end needs to be updated, it is not necessary to completely remove the previous version from PM2, updating the local files to the most recent version and restarting the instance is the most efficient way to complete the process: 1pm2restart 0 This process is relatively simple to execute and can be done in a manner of minutes, which is a great time-saver considering PM2and Strapi do all the heavy-lifting in the background.
5.2. Front-End Servers 118 5.2 front-end servers Both front-end applications were built using Vue.js, which works in a vastly different manner than Strapi. A feature it provides is compiling the entire build as static files, meant to be served by another HTTP server. By executing the following command inside the project’s root folder, a new folder named ’dist’ will be created that contains these files: 1npm run build When examining the folder structure, it has multiple folders divided by the data types used in the application, such as ’css’, ’img’, ’js’ and ’media’ and, for each one, it contains multiple files related to the folder they are in. For example, inside ’js’ there is the entire website’s functionalities and inside ’css’ there are the entire Vue.js and custom user-made CSS files. There is also one single short ’index.html’ file where it has these folders linked correctly in the header for the browser to fetch when appropriate. 1<!DOCTYPE html> <html lang="en"> 3 <head> 5<meta charset="utf -8"> <meta http −equiv="X-UA - Compatible " content="IE=edge "> 7<meta name="viewport " content=" width= device -width ,initial - scale =1"> <l in k r e l ="icon" href="/favicon.ico"> 9< t i t l e >Hypatiamat − Quero Resolver Q u e s t e s de . .. < / t i t l e > <l in k r e l ="stylesheet" href=" https :// fonts .googleapis .com/css ?family =Roboto :100,300,400,500,700,900"> 11 <l in k r e l ="stylesheet" href=" https :// cdn .jsdelivr. net /npm/ @mdi /font@latest / css/ materialdesignicons.min.css"> <link href="/css/app.a1f9a827 . css" r e l ="preload" as=" style"> 13 <link href="/css/chunk - vendors .3 d7720a4 .css" r e l ="preload" as="style"> <link href="/js/ app .290 ebf01.js" r e l ="preload" as="script"> 15 <link href="/js/chunk -vendors .68 f663a2.js" r e l ="preload" as="script"> <link href="/css/chunk - vendors .3 d7720a4 .css" r e l ="stylesheet"> 17 <link href="/css/app.a1f9a827 . css" r e l =" stylesheet "> </head> 19 <body><noscript ><strong >We're sorry but frontend doesn ' t work properly without Ja vaScript enabled . Please enable i t to 21 continue . </ strong ></noscript > <div id="app"></div> 23 < s c r i p t sr c="/js/chunk -vendors .68 f663a2.js"></script > < s c r i p t sr c="/js/ app .290 ebf01.js"></s cr ip t > 25 </body>
5.3. Image Server Redirects 119 27 </html> As mentioned previously, Hypatiamat relies on NGINX as a reverse proxy, so, whenever a user attemps to access https://qr.hypatiamat.com, it simply returns the HTML file and everything else is the user’s responsibility. Assuming the user is on a typical browser, once they have the ’index.html’, it will scan the links inside the HTML file’s headers and send requests to fetch them from the NGINX server and, once that is complete, it saves them locally until they are changed (caching), which avoids repeating this costly process in the near future. The following code is a simple NGINX configuration parameter that allows this process to happen: 1location / { t r y _ f i l e s $uri $uri/ /index . html ; 3} After repeating this process to both front-end servers, they are now ready to be used in production and can fully consume the API endpoints on the back-end servers in order to fully render the website’s pages with the necessary data. 5.3 image server redirects The questions in the database, as seen in previous chapters, have two optional fields that contain the URL to two images, namely ’resolucao’ and ’figura’ (see figure 11). The current Hypatiamat image server is essentially a static file server, where the directory it operates on contains all the images for the applications and is updated manually, whenever a new image must be added. This is where a major problem emerges, and that is that if some application wants access to add a new image to this folder, it must somehow have permissions to make local changes (in the same machine) to it, because there is no upload endpoint due to the nature of these types of servers and security concerns. This is important especially on the back-office, where editing, adding or removing the images is a core feature and if the situation was left the way it is only removing would be possible, since that would entail simply clipping the URL from the fields. So, the possibility of using that static server is completely out of the question. The only alternative is creating a new one where the back-office has total control on its contents and this is easily achievable using Strapi’s built-in upload manager. By default, Strapi has
5.3. Image Server Redirects 120 endpoints that can be used to upload HTML form data and if by chance it contains any file, it will be stored both in the database (only its metadata) and in the server’s physical drives, specifically in the public folder inside Strapi, where they will behave as static resources and served as such. This way, it is possible to edit, remove or add images that are owned by that Strapi instance. The solution then is pretty simple, right? If a new image needs to be added, simply save it in the back-office’s back-end server and use its URL in the field(s). No, this is not quite true and that has to do with how the URLs are stored. Starting with the ’figura’ field, an example of its contents could be ”perimetrosN2/perimimg43.png”. This means that the address is not fully saved, only the folder and file name for that particular image, since originally it was assumed that there would only be one address where the images would be stored, namely https://www.hypatiamat.com/imagens/. By concatenating these two elements together, the final URL that contains the image is https://www.hypatiamat.com/imagens/perimetrosN2/perimimg43.png. This also happens in the ’resolucao’ field where an example of its contents could be ”perimetrosN2/solperimetros3.png”. For this one, it also has a permanent address by default and that is https://www.hypatiamat.com/imagens/propresolucao, where it only differs from the previous case on its ”propresolucao” extension. The concatenation results in https://www.hypatiamat.com/imagens/propresolucao/perimetrosN2/solperimetros3.png and it is where the image is located at. Consequently, for every other Hypatiamat application, this means that any concatenated URL would lead to the places mentioned above and if the image is not on that static server, it would simply be considered as non-existent when it clearly is. They all follow this rule, so attempting to change the format in which the information is saved or storing the new image URLs from the back-office in their entirety are solutions that would not work, they would absolutely break every other application and that is something that must be avoided at all costs. Consider that a new submission was created and a new image successfully added to the back-office’s static server and the information that is stored in the database would be the following instead: •”bckqr/1.png” - for the ’figura’ column; •”bckqr_r/2.png” - for the ’resolucao’ column. Naturally, this by itself does not solve anything, the result is still the same as before. However, if redirects are introduced, that is a different story. Note that no other folder or file exists with these particular names (”bckqr” and ”bckqr_r”) in that static server so there are no conflicting routes. If the NGINX instance is configured in a way such that any incoming requests containing these two keywords are automatically redirected to the back-office instead, this problem
5.3. Image Server Redirects 121 would be fixed for any application, whether new or old, because this redirection process happens in the background and works as if nothing changed in the static image server. The picture below shows a brief overview on what this redirection process looks like: Figure 113: Image Server Redirects Diagram After this implementation, all applications were tested and they worked correctly with this new method of serving images, leaving the teachers the possibility of executing CRUD operations on any image at will and without breaking any existing application. This deployment method brought forth some challenges, related to how the NGINX instance operates in the background, causing troubles in the Strapi’s default documentation endpoints, which will be the focus of the next chapter.
6 DOCUMENTATION The API endpoints might be used by other developers, in the future, for integration purposes in their applications or scripts. Thus, creating a proper documentation page for both backend applications where the routes, parameters, responses types, response bodies and so on is important in this regard. Once again, Strapi makes this entire process easier and quicker since it has a downloadable plugin that automatically integrates Swagger in it. Swagger uses the OpenAPI specification for creating an interface where it is possible to send RESTful requests to consume the API endpoints without any external tool, effectively creating a quick and friendly test environment. On a side note, this paper will not go into a lot of detail on how Swagger operates, as that can be a dissertation by itself, only how it works when integrated with Strapi and how to properly tune it to the application’s needs. As soon as the plugin is installed, it will be generated inside every folder that contains the API routes (see chapter 3.5.2) a new sub-folder called ’documentation’. It has sub-folders aswell, one for each documentation version, which is an useful feature for more complex applications, where the default one is 1.0.0and the only one that will be used for both back-ends. The version folder contains a single JSON file named after the Strapi collection, i.e ’escola.json’, which is where the route information generated on the install is stored. Naturally, this file is incomplete sometimes, it may not have the request body types, status codes or even request response types, it is up to the developer to complete it. Since these files are generated every time the server is restarted, any change is not kept if done inside them, so, Strapi defined a way for the developer to override these default values on their own volition. To achieve this, a new folder named ’overrides’ needs to be created inside that version folder, containing a JSON file named exactly the same as the previous one and containing the fields that need to be updated, added or removed. 122
7.3. Closing Thoughts 129 only one level of nested elements) using the taxonomic classification of each theme and sub-theme would be a great solution for this problem as it would allow the user to visualize the alterations they are doing on them. Additionally, another great feature that could even be its own separate project is exporting and importing the questions data in different formats. For example, this would give the user the possibility to automate the creation of repetitive questions using other external scripts or applications that would be saved in an easily parsable text file such as XML or JSON. Naturally this would have to be made user-friendly and that is where most of the time would be dedicated to. For the ”I Want To Solve Questions About...” application, the main areas for improvement relate to giving the user systems to track their progression. This could be done using achievements or milestones, i.e, number of questions solved, daily login streaks, monthly questions completion ratio and so on. This would also give the leaderboards page a purpose other than vanity, as it would reward users in a more permanent manner for their daily/monthly presence. Another thing the application lacks at the moment is audiovisual feedback. Currently it only plays a sound whenever the user introduces a right or wrong answer. Since it is primarily aimed at young people, it is important to keep them engaged with audiovisual stimuli and that includes notifying them when they skip to the next question, when the question-blocking timer begins, when it ends, etc. Whenever a pop-up appears that shows the user completed a question successfully, it should be more satisfying with animations, slide-ins, fade-outs and the sorts. Naturally, there are infinitely more features that can be added but these are the ones that fit the projects better and would effectively improve the usability and dynamism of them as a whole. 7.3 closing thoughts The projects required a continuous study and research as they were very demanding in terms of technical expertise and knowledge, which was an humbling experience and great for personal development, both as a software engineer and a person. Full-stack development requires extensive knowledge of front-end, back-end and database management systems. Having total control of the outcome as a solo developer is both terrifying, since the end product might not be anywhere near what was originally envisioned, and ensuring since you have total control of how every piece of the stack turns out in the end and it does not depend on other teams. This project highlights that with enough practice and study, amazing results can be achieved.
7.3. Closing Thoughts 130 It is a great relief that not only the project as a whole was a success, but also that it actually contributes to something meaningful. Having a positive impact on the world, no matter how little or marginal it is, is an amazing achievement that brings more satisfaction than any monetary compensation would. Hopefully this project serves as inspiration for any future developer that wishes to delve a bit into full-stack engineering and its intricacies. For them and to any other, never forget: persistence is key.
BIBLIOGRAPHY Cloudflare. What do client side and server side mean? client side vs. server side. https://ww w.cloudflare.com/learning/serverless/glossary/client-side-vs-server-side/ . (Accessed on 17/01/2022). Hypatiamat. Hypatiamat: Apresentação. https://hypatiamat.com/apresentacao.php . (Accessed on 28/09/2021). Marin Kaluža and Bernard Vukelic. Comparison of front-end frameworks for web applications development. Zbornik Veleuˇcilišta u Rijeci,6:261–282,01 2018. doi: 10.31784/zvr.6.1.19. Arpana Karanjit. Mean vs. lamp stack. https://repository.stcloudstate.edu/csit_etd s/11, Maio 2016. (Accessed on 20/01/2022). Marca. Colégio marista apresenta programa de internacionalização do ensino. https: //www.metropoles.com/conteudo-especial/colegio-marista-apresenta-program a-de-internacionalizacao-do-ensino, Novembro 2021. (Accessed on 24/01/2022). Catarina Martins. Guia para um exame sem ansiedade. https://observador.pt/2014/05/ 19/guia-para-um-exame-sem-ansiedade/, Maio 2014. (Accessed on 18/01/2022). MDN. Window.localstorage, 09 2022. URL https://html.spec.whatwg.org/multipage/web storage.html#dom-localstorage-dev. Accessed on 07/10/2022. Miracle Onyenma. Understanding and using relations in strapi, 05 2022. URL https: //strapi.io/blog/understanding-and-using-relations-in-strapi . Accessed on 27/08/2022. Ricardo Pinto. As aplicações hipermédia podem promover o sucesso escolar e a autorregulação da aprendizagem? análise da eficácia de uma aplicação hipermédia. http://hdl.handle.net/1822/35846, Dezembro 2014. (Accessed on 21/01/2022). Md Rahman. Cloud computing technology. 12 2021. URL https://www.researchgate.net /publication/357071610_Cloud_Computing_Technology. (Accessed on 22/01/2022). Redação. Escola básica de prado realizou o ii campeonato de cálculo mental hypatiamat de prado. https://semanariov.pt/2019/06/06/escola-basica-de-prado-realizou-o-i i-campeonato-de-calculo-mental-hypatiamat-de-prado/ , Junho 2019. (Accessed on 19/01/2022). 131
BIBLIOGRAPHY 132 Statista. Market share held by leading desktop internet browsers in the united states from january 2015 to december 2021. https://www.statista.com/statistics/272697/mar ket-share-desktop-internet-browser-usa/,2021. (Accessed on 03/02/2022). Swoop. Token-based authentication: How to optimize your website, 06 2020. URL https: //swoopnow.com/token-based-authentication/. Accessed on 07/09/2022. João Vieira. Hypatiamat: Especificação e implementação de um componente para gestão de trabalhos de casa, 2021. Ruihan Wang and Zongyan Yang. Sql vs nosql: A performance comparison. https://ww w.cs.rochester.edu/courses/261/fall2017/termpaper/submissions/06/Paper.pdf , 2017. (Accessed on 01/02/2022). Matthew West. Requirements Specification, pages 187–196.12 2011. ISBN 9780123751065. doi: 10.1016/B978-0-12-375106-5.00015-4.
A MOCK-UPS - QUESTION SUBMISSION BACK-OFFICE • Dashboard Figure 118: Question Submission Back-Office - Dashboard Mockup • New Submission Form 133
134 Figure 119: Question Submission Back-Office - New Submission Form • Approved Questions Figure 120: Question Submission Back-Office - Approved Questions • Active Submissions List
135 Figure 121: Question Submission Back-Office - Active Submissions List • Hidden Questions Figure 122: Question Submission Back-Office - Hidden Questions • Submission History
136 Figure 123: Question Submission Back-Office - Submission History • Order Themes Figure 124: Question Submission Back-Office - Order Themes • Change Theme Images
137 Figure 125: Question Submission Back-Office - Change Theme Images • Current Monthly Questions Figure 126: Question Submission Back-Office - Current Monthly Questions • Monthly Questions History
138 Figure 127: Question Submission Back-Office - Monthly Questions History