This file explains how the project has fulfilled each functional requirement, and what we have done to exceed the requirements to make an even more user friendly and realistic website.
The minimum requirement for search functionality was "Søkemulighet eks. med en dialog/form/søkefelt for input av søk". Our searchbar component fulfills this requirement as it makes it possible for users to search for products with a search query.
We also added extra functionality to the search component; search recommendations and debounce for the recommendations. The recommendations fetches up to 3 products that match the given query, using neo4j's built in full-text search support. The debounce functionality makes it so that the backend isn't queried until 300 milliseconds have passed since the user last typed a character in the input. This reduces the amount of unnecessary queries to the backend, and only queries when the user is done typing.
We fulfilled the requirement of "Listebasert presentasjon av søkeresultat hvor det er lagt opp til håndtering av store resultatsett med enten blaing i sider, eller dynamisk laster av flere resultater ved scrolling" by displaying products matching the search query and filters in a list viewing on the "Explore" page.
We added pagination to the explore page to reduce the amount of products displayed at a time. This was done to both reduce loading time and reduce the amount of data that needed to be transferred from the backend on every fetch. Our first implementation of the pagination was made using neo4j's cursor based pagination. After we began implementing full-text search we found that neo4j did not natively support cursor based pagination with full-text search. We chose to prioritize having good search-functionality over a slightly better pagination, and therefore switched to offset-based pagination. We felt that the positives of being able to have more precise search outweighed the negatives of offset-based pagination, like slower loading times when having a large offset and the possibility of inconsistencies if new products are added or removed between requests.
We also thought about the scalibility of offset-based being worse than that of a cursor-based pagination, but seeing as our website is based on selling and buying used items, we thought it was realistic that the amount of data over time would somewhat stagnate, as products would not be added at a much faster rate than other products being either sold, or deleted because of no one buying them.
We fulfilled the requirement "Mulighet for sortering og filtrering av resultatsettet" by having a sorting dropdown along with several filter buttons on the explore page. The music filter also includes a music genre dropdown to filter by genres. The filter buttons will become dropdowns on smaller screens.
We made the filters dynamically hide or show themselves based on the searchquery or other filters chosen, to improve the user-experience and avoid showing zero results when filtering. Unless the user searches with a search string that doesn't match anything in the full-text search, the user will not be able to filter out all products, the filters shown will always be filters that has at least one result. We accomplished this by sending queries to the database fetching the "available" filters based on the search query and other filters. The genre filters will for example narrow themselves down based on which category is chosen, so that the genres shown will have at least one product in the category chosen.
The filters and sorting both query to the database so that they sort and filter the results based on all products in the database before returning the results.
The way we solved the "Det skal inngå en eller annen form for brukergenererte data som skal lagres (persistent på databaseserveren) og presenteres" was by having functionality for creating a user, and for the user to be able to create their own product listing. Since there wasn't any need to have secure user creation and login, we decided to let the user log in with it's username, and not require a password. We store the users ID in localStorage after logging in. In addition to relevant data about the user, the user is able to upload a profile picture, which is uploaded to a dedicated Amazon Web Services S3 Bucket we use for storing images.
The user is given the option of creating a listing for either a music product or an electronics product (music related accessories). They can then fill in relevant information like the name of the product, description, location, and the price for the listing. The user is able to attach 4 images to the product, which is also uploaded to the S3 bucket.
We also added functionality for favoriting products so that users can track items they are interested in, as well as a chat page so that buyers can communicate with sellers about buying items, by sending messages. A user's favorites are displayed on their profile page.