Modernised Learning with Novaheal
This project was carried out as part of the TechLabs “Digital Shaper Program” in Münster (winter term 2021/22).
Nowadays, learning with books is a bit outdated, and Novaheal has set itself the goal of digitally accompanying nursing education throughout its entire course with helpful functions.We worked with them to develop a quiz function to make memorizing content easier.First, we thought about what format we wanted to use to implement this, and the decision was made to go with something similar to the classic driving school apps.Then we developed a first design sketch, improved it and finally implemented it.
As briefly touched upon before, the problem we want to solve with our feature is to replace memorization using books or the like with a digital version, making the whole process more interactive and fun. This way we want to make nursing education a bit more interesting and easier for the learners. From our own experience during our studies, we know how dreary this can be and what a negative effect disinterest can have on one’s motivation. We thought about how we can solve this problem in a way that our function can be used as much as possible, i.e. you don’t have to rely on e.g. a laptop, so you can also learn on the go with your cell phone. That’s why we decided to use a format similar to driving school apps, as this has been proven to work quite well and is also feasible.
First, we thought about a concept for the quiz. What should it look like? What functions should it have? Based on this, we created a design sketch. Based on this draft, we built the frontend with “React” and the backend with a node.js framework called “Express”.
We started developing our frontend by setting up routes for the application. This was done through the React-Router-Dom. After we had created the three routes (novaheal/Homepage, novaheal/Quiz, and novaheal/Results), we could begin building the actual layout for the different pages.
Our homepage was created quickly as we wanted to focus on the actual quiz.
We then began developing the quiz page’s layout. As a first step, we needed to decide how to separate the page into multiple components. The header was already created for the home page, so we could just reuse it here. The body part consists of three sections: the question section, where the user can read the question’s number and its text; the answer section, where the four possible answers would be displayed;
and the bottom section, where the user can go back to the previous question or continue to the next one. This was all implemented using React components and CSS-styles.
After the layout was finished, we implemented the answer box, created the necessary buttons, shapes, and text-fields, and put them into their respective layout components.
The next task would be to make the page respond to user input. In ReactJS, this is done with the help of states.
So there were two major issues to address: which states are required and where should they be placed?
One state variable is the number of the question that is currently displayed. The user can change this state by clicking one of the arrows in the bottom section.
For example, if the user is currently on question 6 out of 10 and clicks on the right arrow, the state would increase by one, causing React to redraw the UI but this time with the 7th question displayed.
The next state variable is a list containing the selected answers to every question. When the user clicks on an answer box to log in his answer to a question, this state is updated, and after the page is rendered again, this answer box will be marked in green.
Both states are stored inside the quiz body component as they need to be accessible by multiple of its inner components.
The review page simply gets the percentage of correct questions and displays it. This did not require much work as its components were simpler than the ones inside the quiz.
We just created some buttons to play again and the frame for the score and inserted these into the layout. Some processes, like correcting questions after the game is played, are normally part of the backend.
For implementing the backend we used a backend generator called “Turbo360” which probably wasn’t our best choice due to its relatively high complexity.
In order to store and manage all the questions and answers for our quiz we decided to use a database. At first we planned to create a local mongoDB database on Lennart’s desktop PC. The implementation worked quite well but we soon had to realize that Jonas could not access the local database on another device as long as the database was not deployed. Thus we decided to use “mongoDB Atlas” which is a multi-cloud database. “mongoDB Atlas” automatically deploys the website which can be seen in the picture below.
In order to connect the database to the backend we used “Mongoose” which is a Node.js-based Object Data Modeling (ODM) library. “Mongoose” allows us to enforce a specific schema for the database similar to SQL databases. This feature is particularly useful for us, because all of our database entries consist of the same attributes.
However, as there was no time for us to connect the backend and frontend, a fake database was created to take care of these tasks so we could get a functional version of our app.
At the end of the project phase, we had a working test version of our application, which includes a frontend with multiple pages in a modern design and also a few simulated questions. However, the frontend and backend are not connected to each other, so the points achieved by a participant are not yet stored decentrally.
Because of that, at this point, our application only works locally, either in the browser of a smartphone, laptop, or a tablet.
Roles inside the team
While Jonas, Linda and Abdul were responsible for the frontend, Jan-Philipp and Lennart took care of the backend.
Linda mainly took over project management tasks in the team along with Jan-Philipp. In addition, she helped drive the content and design concept of the quiz and acted as the main person responsible for pitching the results of the project.
Jonas was mainly responsible for implementing the frontend.
Lennart primarily took care of implementing the backend and the database.