Team functional expressionism - Nguyen Quang Vinh & Wong Chee Hong

Frontend: https://github.com/cheehongw/functional_expressionism

Backend: https://github.com/cheehongw/functional_expressionism-API

TinFood is envisioned to be a platform where visitors can easily find detailed information about NUS food stalls. While NUS Office of Campus Amenities (NUS OCA) has a page dedicated to listing all the food and beverage locations in NUS, we find the information provided to be lacking and leaves more to be desired. For example, the page does not list the food stall available at certain locations and does not carry the menu of said stalls.

As such, TinFood aims to provide detailed information about each F&B stall in NUS, including information about the menu and pricing, which hopefully will be a better alternative to the one provided by NUS OCA.

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. We elaborate further on the difficulties faced in this section here.

The website's layout is currently designed for mobile use only, so do view the site in mobile.

The prototype of the website can be found at:

https://functional-expressionism.vercel.app/

Here we provide a walkthrough of the web app, and the purpose of each feature. You can just explore the prototype, but come back here if you have questions.

There is no need for visitors to login to use our website, although there are extended features we intend to implement for logged in users. Visitors can choose between the two features available.

This feature remains the core of our website. It provides the information visitors want when they visit the website.

1. Locations Listing page

   • List of locations in NUS

2. Stall Listing page (⚠️ Unimplemented)

   • List of stalls at a particular location
   • Clicking on the stall will bring up a floating preview card of the stall
     • preview card shows stall information such as opening hours, price range, halal info etc.
     • click again to enter menu listing page

3. Stall-front page (⚠️ Unimplemented)

   • Landing page associated with the stall
     • Display Ratings, comments and description of the stall
     • Scroll down to view menu of the stall

This page aims to serve suggestions to the user when they have no idea what to each. It offers a Tinder-like layout for users to choose among a set of options presented to them.

1. A "I am feeling lucky page" - recommend the dish for the user. Users can:
   • Swipe right/ Click on the right arrow if the user like the recommended dish.
   • Swipe left/ Click on the left arrow if the user disliked the recommended dish.
   • The cards swiped right will reappear until the user settle on one single choice.

Clicking on the login button on the header bar will direct users to a login/signup page.

Here, users can sign up with their own username and password or with their Google account.

The profile page for a logged in user. A user can control their account from this page.

1. Control account credentials

   • Change profile pic/ display name/ password
   • Delete account

2. User interactions(⚠️ unimplemented)

   • Shows stall visit history
   • Show comments and reviews made by user in timeline

We aim to develop a mobile-friendly web app by adhering to progressive web application guidelines.

Our application will adopt the MERN stack to build and create our frontend and backend application, with the use of Firebase for authentication. Sticking to a full javascript stack allows us to make development easier and consistent.

The frontend will be built on the industry standard ReactJS Framework, with pure React (create-react-app) being the flavour of choice. React will and send requests to the backend.

We will rely on firebase for the authentication service to provide the frontend application a secure and easy way to recognise the user. Firebase abstracts a lot of secure authentication work and provide a great documentation to use the platform.

We are using NodeJS server with ExpressJS web framework to expose a set of frontend agnostic API endpoints. These endpoints can be used to query and send data to the mongoDB database.

The choice to separate the frontend and backend makes development more modular and easier to handle. Moreover, the backend API can still serve the NUS community if anyone decides to access a list of NUS foodstalls.

To achieve the goals set out, we drafted a set of user stories to justify the features that we want to implement in Milestone 1:

https://github.com/cheehongw/functional_expressionism/blob/main/README.md#15-user-stories

However, noting that we had fallen behind schedule, we have decided to re-prioritize certain features. Moreover, the development phase has also made clear certain features are more essential than we thought.

On the front end side, we had initially set out to implement the following features as listed out in our user stories. However, some of their following components are incomplete, and we had to reassess the priority of certain components.

They are sorted broadly into the following categories:

This feature is encompasses the display of stall information to the visitor. We intend to finish this feature by milestone 3.

Priority	As a...	I want to be able to...	So that I can...	Current State
3/3	Visitor	view the full menu,prices, halal-ness, opening hrs of food stall	know the food choices available to me	❌ Core, incomplete
3/3	Visitor	know my current distance to nus food locations	make informed decisions	✔️ Core, completed
1/3	Visitor	check the real time crowd level of a location	to make informed decisions	❌ Extraneous, dropped
1/3	Visitor	find the shortest path to food location	find food quickly	❌ Extraneous, dropped

We have yet to implement proper display for listing the locations and stall information due to the lack of a dataset to work with. The implementations for listing the stalls and displaying stall information have not been coded out, and have yet to be connected to the backend.

There are also several components that are of low priority that we decided to not pursue in milestone 3.

This feature helps users to decide what food to eat.

3/3	Visitor	generate random suggestions for food based on presets such as menu, prices, distance	have something help me decide what to eat	✔️ Core, completed
2/3	Registered user	generate random suggestions based on my eating history	have something help me decide what to eat efficiently	❌ Low priority, incomplete

We believe we have a minimum viable product to ship with, and hence this feature is generally complete. However, we have yet to connect this feature with our backend.

Allows users to login and perform user-level tasks.

3/3	User	Login securely	Keep my account safe	✔️ Core, completed
2/3	Registered User	reset/change my username/password	have control over my account.	✔️ Core, completed

Allows users to contribute missing information to our database.

1/3	Registered user	contribute to the database of foodstalls	help keep information up to date for other fellow users	❌ Core, incomplete
1/3	Administrator	Vet and approve contributions made by fellow users	to prevent abuse of database	❌ Core, incomplete
1/3	Administrator	Receive notification to approve contributions	approve contributions ASAP	❌ Core, incomplete

This feature was originally low priority, as we thought it would be easy to gather a database of all the food stalls and their respective dishes in NUS. However, we were sorely mistaken and it is almost impossible to handle such a monumental task on our own. As such, this feature is promoted to be a core feature that we will implement by milestone 3.

Review and rating system so that visitors can see what others say about the food.

3/3	Visitor	see reviews and ratings on stalls and food items	make informed decisions	❌ Low priority, incomplete
2/3	Registered user	post reviews and ratings on stalls and food items	provide feedback about the food	❌ Low priority, incomplete

We intended to have this feature so that users can draw more functionality from our website. However, our website can still serve its original goal of providing stall information without user reviews. As such, we have decided to push this back in favor of the user contribution system.

We intended to expose a RESTful API for anyone to fetch information from the database. This way, the backend can still serve a purpose for the NUS community if anyone intends to use a database of NUS food stalls.

View the repository here:

https://github.com/cheehongw/functional_expressionism-API

Method	Endpoint	Purpose	Details
GET	/location	Returns a list of locations in NUS
GET	/location/<Location_Name>	Returns details of a particular location.	<Location_Name> is the name of the Location, replace any spaces with underscore.
GET	/location/<Location_Name>/<Stall_Name>	Returns details of a particular stall at a particular location

We started the backend quite late into milestone 2, and were unable to complete the set of endpoints that will support our frontend. As such, while we may have coded out parts of the frontend, it is still not ready for deployment.

We have a rough list of endpoints left to expose, as listed below:

Name	Purpose
get_stalls	Return the list of stalls at a particular location for frontend Stall info feature
get_stall	Return the detailed information about a stall for frontend Stall info feature
get_dishes	Return the list of dishes at a particular stall for frontend Stall info feature
get_random_dishes	Return a set of dishes for the frontend Dish Suggestion feature
post_location	Allow users to contribute to the set of locations in the database
post_stall	Allow users to contribute to the set of stalls in the database
post_dishes	Allow users to contribute to the set of dishes in the database

Difficulty in performing data entry, as well as the unexpected nature of the data formats out in the wild delayed our plans. For example, in our Dish model, we expected 1 pricing for every dish. However, the reality is that there are multiple pricing for the same dish, such as a student and public price.

In order to deliver a satisfactory product by the end of Orbital, we have come up with a timeline of how we intend to achieve this goal. Given that most features are almost completed, we will prioritise completing each feature based on their relative importance to our website.

Week	Development plan
28 June - 4 July	Finish and connect the set of API endpoints needed for dish suggestion feature Finish coding out the missing pages for stall information feature
4 July - 11 July	Implement user contribution system and implement relevant API endpoints Implement responsive CSS to handle desktop viewports
12 July - 19 July	Code Review Implement Review system User Tests
20 July - 25 July	Code Review Integration & unit testing

This section outlines the tools that the team is currently employing that adheres to some of the industry best practices.

Git is used for version control, with the repositories being hosted on Github. The development process makes use of one single branch. Despite this, the workload allocated to both members is not related to one another thus there is low chances of conflict. Issues are raised in the repository to organize the priority of work and clearer allocation.

ESLint is used to ensure that the code written adheres to the industry standard linting practices. The linting convention used is the AirBnB standard, with the default linting rules for the React components. This should help standardise the codebase, ensuring that code is neat and readable, boosting the debugging progress. Prettier is also used to take care of the code formatting

You can view the commit log of the two repos here:

Frontend: https://github.com/cheehongw/functional_expressionism/commits/main

Backend: https://github.com/cheehongw/functional_expressionism-API/commits/main

No.	Task	Date	Chee Hong (hours)	Vinh (hours)	Remarks
11.	Develop full authentication system	1 - 23 June	0	95	Implementing these pages: Sign In, Sign Up, Sign In Done, Sign Up Done, Profile, and One-time setup for user signed in for the first time to set their username and avatar image. Adding in support for signing in using Google account. Setting up Firebase to store images and user details. Implementing the pages to change password, username, avatar image, and to delete account. Creating an user context to help other components of the web application reference the data they need. Applying basic CSS for the pages above Optimizing the performance of querying the database for username uniqueness and getting the avatar image URL. Fixing bugs related to authentication.
12.	Add frontend components headerbar, index page	1 - 7 June	13	1
13.	Code review	11 June	3	3
14.	Add components for location list view page	11 - 16 June	20	0	List component List item component
15.	Add sorting for location list component	18 - 20 June	15	0	Add List sorting functionality Implementing Geo-location API for sorting by distance Implement visual components for sorting
16.	Create backend server with NodeJS	20 - 21 June	10	0
17.	Implement data models for database	22 - 23 June	7	0
18.	Research for the I’m feeling lucky (Suggestion) page	23 - 26 June	0	20	Researched and tested the possible libraries to use for the “Tinder-like” swiping animation.
19.	Initialised mongo cloud database and getters for locations and locationList	24 - 25 June	8	0	Researched and play around with the database to understand how it works
20.	Design food recommendation card	26 - 27 June	0	10	Designed the card for the I’m feeling lucky page with basic CSS.
21.	Data entry and image uploading + Heroku deployment	25 - 27 June	40	0	Key in data for 100+ entries, upload respective images to image hosting websites Bulk upload data to mongoDB Deploying app to Heroku
22.	Merging components and CSS for I’m feeling lucky page	27 - 28 June	0	10	Applied the library for the designed cards, add a dummy list to test the animations, added buttons for swiping left and right for PC users with basic CSS
23.	Improve look of index page	28 June	3	1	Closes issue.
Hours spent		Subtotal	119	140	Total: 259hrs