1/8 — Start-Up via Ultrasonic Sensor

1/8
Start-Up via Ultrasonic Sensor

Upon opening the application, the user is greeted with a waiting screen. In effect, the application waits for a user to come within range of the computer and hardware to begin the screening process. The HC-SR04 sonar, via the Johnny-Five hardware libraries, is assigned an event listener. On a change of reading, the back-end checks if a person is within 50 centimeters of the computer, and changes a global boolean to reflect this change. Meanwhile, the front-end sends get requests to the back-end via Axios. The back-end, via Express.js, handles requests and returns the aforementioned boolean. When the front-end receives the value true, a new page displays, starting the screening.

2/8 — Questionnaire via Buttons

2/8
Questionnaire via Buttons

The first thing a user must do is answer a series of questions regarding potential symptoms or close contact. However, instead of clicking a yes or no button on the screen, the user must instead press physical buttons. Similarly to the HC-SR04 sonar, each button had an event listener attached, which on a click sets one of two booleans to true for 100ms. Another get request pulls the two boolean values. If "no" is selected as an answer, the screening process would abruptly end. If "yes" is selected, the next question is displayed. After all questions have been displayed and "yes" has been answered for all, the front-end navigates to the next part of the process.

3/8 — Temperature Measurement

3/8
Temperature Measurement

Next, the user must measure their temperature using a body temperature probe thermometer. The user is instructed to sanitize the thermometer, with a GIF displaying the example. After clicking a button to continue, the user is then told to play the thermometer on the underside of their elbow with a new GIF. Continuing, the user holds the thermometer in place for 30 seconds, and the temperature measurement takes place. In the same way as the previous two features, the value is recorded via an event-listener-called function and transfered via a get request. After 30 seconds, the result displays on the screen. If the temperature value is too high, the user is not permitted to continue. A timeout function triggers the navigation to the next page, which depends on the above result.

4/8 — ID Scans

4/8
ID Scans

One of the last things a user must do is scan their vaccination card and government ID. Due to user privacy, we didn't build a way of scanning actual IDs, but we substituted via custom QR codes. npm's react-qr-reader component was used to read a QR code from the user's webcam, showing the webcam footage on the screen via the <QrReader> tag. The QR codes are then read and the string result is sent via a callback function and then a post request to the back-end to parse. Each set of identification scans had separate purposes and associated functions.

1. Vaccination Card: this QR code contains the first and last names of the individual, and the vaccination status, and the associated parser turns the resulting string into an object. The back-end then checks if the card itself is valid by checking if it matches an ID in a database of cards in a different file. If the vaccination card is valid, and the vaccination status is set to true, the front-end navigates to the next ID scan. Otherwise, access is denied.
2. Government ID: this code contains the first and last names as well, coded in a more government-style format. The parser grabs these names, then checks another database of user information, grabbing the user's email if the user has previously registered. If the user's name matches that of the vaccination card, and the user is already registered for the day, access is finally granted as no more steps need to be taken. If the user's name matches but the user hasn't been registered yet that day, the user must input their email. This email is then included with the vaccination ID and name of the user to add to the user information database under the date they used this tool. Once the user's info has been added, access is granted. If user's name doesn't match, access is denied.

5/8 — Granting Access

5/8
Granting Access

Throughout this process, there are several times when access can be denied: failed questionnaire, high temperature, invalid ID, or unvaccinated status via ID. In these cases, the front-end will navigate to the "Access Denied" screen, and after timeout back to the waiting page. However, if the user passes the screening, the front-end displays the "Access Granted" page. At the same time, a get request sends which triggers a servo motor to rotate, simulating the opening of a door as if the person can now enter whichever building employs this system. On a 5 second timeout, the front-end then signals the back-end to return the servo back to it's original location, closing the hypothetical door, and returning to the waiting page to start another cycle.

6/8 — Admin Login

6/8
Admin Login

All previous entries have discussed how a regular user would interact with this project. The rest of these entries deal with how the administrative team (the four of us who worked on this project) can use the data collected. However, since not everyone is allowed access, a login system was used in order to access the administrative dashboard. This process was done using HTML forms, with inputs for username and password. When submitted a very quick post request checked if both username and password were valid. If they were valid, the admin would gain access to the dashboard, otherwise a message would appear under the form informing the inputter of the incorrect information.

7/8 — Access Graph

7/8
Access Graph

The admin dashboard can be split into two parts; this is the first part (on the left). The graph is created using npm's recharts library, specifically component for a line graph. The data for this graph is taken from the user information database mentioned in Feature 4. As this database groups users based on the day they access the application, the back-end compiles the number of people who accessed the graph each day and sends the data to the front-end to be used by the graph. Contained in a <ResponsiveContainer> element, when you hover over each dot on the graph, the <Tooltip> element displays a small box with the specific datum. An administrator using this application may want to know which individual days or days of the week are busiest or most inactive.

8/8 — Mass Email

8/8
Mass Email

The second part of the admin dashboard is the mass email feature (on the right). This feature is extremely important to an administrator, as if there is a COVID breakout in the location in which this app is used, the admin can send an email to everyone who may be affected on the day contact with the virus occured. When the "send mass email" button is clicked, a callback function sends a post request to the back-end. The back-end first gathers an access list of individuals' emails from the date sent in the post request. An object is then organized with to, from, subject, text, and HTML sections; the to: section contains the previously created list, and the HTML: section effectively the text: section with formatting HTML tags included in the string. Finally, @sendgrid/mail is employed to send multiple messages to each of the emails included in the list.