Problems encountered - cheehongw/functional_expressionism GitHub Wiki
In Milestone 2, we had originally planned to implement many features, but we either failed to realise them, or had to reconsider the feasibility of these features. This section outlines some of the problems faced by both team members during development.
Software design
The design for the frontend application leaves much to be desired. As this was the first time that either member did any frontend implementation, the file structure and application design failed to adhere to known architectural/design patterns, making development and coding feel cluttered and messy.
Problems with dataset
As we started late with the backend server, we did not have time to anticipate the problems that may arise when we initialise the database.
One problem was underestimating the scale of the data available. However, there are hundreds of dish entries per stall and 20 over stalls per location, making it near impossible for 2 people to finish on their own. We realised this quite late into milestone 2 and did not have time to implement a user contribution system.
Moreover, the unexpected nature of the data formats out in the wild delayed our plans. For example, in our dishModel
, we expected 1 pricing for every dish. However, the reality is that there could be multiple pricing for the same dish, such as a student and public price, different prices for different portion sizes etc.
Authentication and user-related
- Firebase authentication system does not have a way to ensure the username uniqueness of users. We resolve this by using a Firestore database to store the existing username
- Firebase authentication system does not have a to store user's avatar image. We can resolve this by using Firebase storage to store the user image in a folder which has the name of the user's UID (to avoid clashing of file name) then store the avatar image URL to Firestore.
- Query the username and avatar photo URL from the Firestore database takes noticeable amount of time, leading to user experience issues such as slow load of the avatar image on the drop down menu on the Header bar and hard to verify if the user has done the One-time setup. This can be solved by creating a context which stores the current Firebase user. This user will also contain information about the username and avatar URL.
- First load of the user avatar is slow because React has to first download the avatar image, then scale it down to the desired size. This directly harms user experience as load time is noticeable (especially with 5 MB pictures). We can design a backend system to scale down the image to a desired size when the user uploads an avatar image to the Firebase storage. This is not implemented yet.
- Users signed in using a Google account cannot delete their account. This can be solved by letting the user reauthenticate then pass the credentials to the delete account method that Firebase provides. This is not implemented yet.
- Google sign in state does not persist. This can be solved by setting the persistance of the logging state to Local.
- User can send unlimited password forget email. There should be a limit to how many password reset email can be sent to a email address everyday. This problem currently does not have a solution yet.
- Users registered but have not verified their account for a long time still have their account entries in the database. There should be a system for clean up of the database to maintain performance and to avoid account spamming (as there is currently no solution to disallow the creation of illegal but correct syntax email)
- Users deleting their account should have the user entry in the Firestore database (which contains the username and avatar URL) and storage (which stores the avatar image itself). This can be solved by calling the delete method of both Firestore and Firebase Storage after we execute the account delete method of Firebase authentication.
- The default crop for the avatar image is the centered slice of the image. Hence, if the user uploads some picture where the part of the picture they want to include in the avatar is to the left of the picture, it might not appear on the cropped version of the avatar image. This can be resolved by implementing a system to allow users to crop the original image and choose the part they want (react-image-crop is one possible library). This solves the problem of slow avatar image loading time as well, by limiting the size of the crop to a fixed value.
I am feeling lucky page
- The react-tinder-card library can not reliably detect swiping in four directions, and does not allow double-tapping the card. This leads to a revamp to the swiping system. We have to limit the direction to only left and right and cycle the food suggestions until the user picks one from the system generated suggestions.
- There are some dish where people felt a bit 50-50, and want to have a "nudge" to finally settle on a decision. We can resolve this by retaining the dishes that the user like and let them compare the dishes until only one option is chosen.
- Due to the limited space, a short user guide on how to use this page is not possible. We can work around this by giving clues on how to use the page on the buttons below the cards.
- The image on the card showing the preview of the dish takes a noticeable amount of time to load. This can be resolved by scaling down the images to 300 x 300 px and store in a database.
- User has to scroll the page to see the full card if the title of the dish is too long, causing the length of the card to increase. A responsive version of this page is needed to avoid this issue.
- Cycling of the cards until the user settle on a choice is not supported by Array.prototype.map (which is used in the library example - rendering the whole stack of cards when the page first loads). We can resolve this by rendering the cards one by one.