This is my own version of the Inventory Application. This is a real-world app with real business data. The housekeeping department is responsible for cleaning the guest rooms in the hotel. The hotel sends questionnaires to the guests about their stays. The guests can give a score between 1 and 10 to the cleanliness of the guestroom. The hotels use a percentage measure to describe guest satisfaction. This measure is the ratio of the numbers 9 and 10 scores to the total number of scores. We get this percentage measured every month and year.
This program follows the daily tasks of the cleaners in the housekeeping department. We can input the data of the daily tasks manually or from a report file (text file). The same is true for the guest feedback data. When all the data is available, the program filters the guest feedback data between the cleaners and calculates the percentage values for each cleaner and other statistical measures. This can be used for quality assurance purposes.
This program is in daily usage and the manager asked me for a new feature. The supervisors do spot checks on the serviced rooms and give a score to the cleaners. The score is a percentage between 0 and 100. The 100% is the perfect room without any issues. The program is capable of storing these audit scores as well and can calculate the average for the cleaner's daily, monthly and year-to date.
When you open the page the first view summarizes the data uploaded about today.
You can see in the middle that all the services are 0. This simply just means, that there is no data in the database
about this day yet. You can see the days in the current month in a diary component at the right bottom corner.
No days have green ticks, which means that no service data has been uploaded for the current month yet. Where can you see
some uploaded real-life data?
You can change the date at the left-hand side with the date input. Let's go back for example to 15/12/2021.
The above view is visible after you click the Home link at the left top corner. In the middle, you can see
that on 15/12/2022 the team serviced 67 depart rooms and 52 stay-over rooms. There was no linen change in any
stayover room, there was no service stayover room (guest, who refused stayover service) and no DND (guest,
who put on the Do Not Disturb sign, so the team could not service the room). On the right side, above the diary
component, you can see where the daily service records can be uploaded. You need to know the password for this.
These files are generated by the paper-free system (called Synergy), which the hotel uses to manage the workflow.
How can you see what exactly happened in the hotel?
If you press the Visit Page button at the bottom left corner the following page appears:
You can see for example that room 2028 was serviced by Wendy as a depart room (she cleaned the room after
the guest checked out). This is the view where you can modify daily service records or delete them. You need the
password for this too. The hotel is divided into 9 different sections, which are described by 9 different pages like
this page. You can navigate between these pages by the << and >> buttons at the top right or just change the page
number at the left and press the Visit Page button again. How can we see the guest feedback data?
Now click the Feedbacks link at the left. After a while of loading, you will get the following view:
This is the view where you can see monthly guest feedback data and upload the files, which contain this data.
Uploading data is protected by the password. You can see here for example that the hotel received feedback in
December 2021 for Room 2032. The guest checked in on 27/12/2021, checked out on 29/12/2021 and gave a score number 10
for the cleanliness. You can also see that the room was serviced as departed before the guest arrived by Wendy and
later during the stay by Thisarani. This is the 5th row in the table.
You can analyse the guest feedback data by pressing the Analyse button. This gives a monthly analysis of the depart
services. You can see this:
The first line shows that the hotel received 148 feedbacks with a cleanliness score. The average ratio of the good
scores (9 and 10) to the number of all scores is 70.27%. This is the 1st row and the Salt (Satisfactory And Loyalty Tracker)
column. The other important column is the Complain one as this shows the ratio of bad scores (7 or below) to the total number
of scores. We also calculate the mathematical average and standard deviation, which are statistical estimates of the performance
of the hotel and the individual cleaners' performance. The monthly cleaners' data is strongly influenced by the statistical
fluctuations as the number of individual feedbacks is relatively low. The same analysis can be executed for all the data in 2021.
All you need to do is check the Yeartodate checkbox and press the Analyse button again. This leads to much more accurate results.
It is interesting to see the individual performance compared to the hotel's overall performance in the form of bar charts. Just
press the show link in the graph column in the relevant cleaners' row. For example, pressing the show link in Wendy's row leads to
the following view:
The graph shows that Wendy's performance in December 2021 is way above than the hotel average. She has a much higher number 10 score
ratio than the hotel average and no bad scores at all. The hotel averages are the blue bars. The score ratios of good cleaners are
represented by green bars as opposed to red bars for bad cleaners. You can see this in Zsuzsanna's graph:
Please turn off AdBlock software on this site, because this software blocks client-side JavaScript and the site relies on this.
The website is a Node.js app. The backend framework is Express. The view engine is EJS. The database is MongoDB on the Atlas cluster. MongoDB is handled by Mongoose. No other technology has been applied apart from Bootstrap 5 for styling, basic HTML, CSS and client-side JavaScript. The technology has been just enough to build the app. I felt a lot that it would have been easier to build the app with a frontend framework like React. The biggest issue was that the UI could not have a state, which is stored only on the client side. In my opinion, it is itself a great achievement that I managed to build this kind of app with such a restricted technology. Regarding this I strictly followed the project description.
As the presented data is not mission-critical, the simple password protection, which can be cracked relatively easily, seems to be satisfactory. If the data gets compromised, we will restrict the network access for post requests. If only the actual users had network access the security would be much stronger than with this basic protection.
Most of the app is believed to be accessible apart from the graph data. I could have added a table of this data for users with accessibility needs, but it would have made the deployment even longer, so it remains an opportunity for future improvement. Any feedback is well appreciated from users with accessibility needs.