Skip to content

Addressing M1 feedback #21

Merged
merged 2 commits into from
Oct 9, 2026
+29 −19
Merged

Addressing M1 feedback #21

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
efe6f28
Docs: Addressing some student feedback
henrikxn Oct 7, 2026
f23a348
Docs: Updated technical-choices doc with the choice of PostgreSQL
henrikxn Oct 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/PRD.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ Defined further in the technical specification:
- The priority is to get song reviews working. If time allows, we would like to add reviews for whole Albums. An edgecase here is singles (EPs), which we will handle as albums.
- What are the data sources for songs and albums?
- We will be using the Datacogs dataset available here: <https://www.kaggle.com/datasets/ofurkancoban/discogs-data-dumps-december-2025>
- Primary focus is on adding a small set of albums and artists, before adding more later on. The limiting factor, is the storage space on the VM.
- Primary focus is on adding a small set of <100 albums and artists decided on by the group, before adding more later on. The limiting factor, is the storage space on the VM.
- Should all lists and reviews be public, or should users have the option to add friends and set access to public, private, or link-shareable?
- All reviews should be public. Access control is out of scope
- Pagination or infinite scroll?
Expand Down
34 changes: 16 additions & 18 deletions docs/Spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,39 +1,37 @@
# Website Specification — key contents:
# Website Specification — key contents

## Purpose & goals — what the site should achieve, target audience, success metrics

## Purpose & goals — what the site should achieve, target audience, success metrics
* The site will be a platform to view albums from a selection of artist.
* The target audience is anyone interested in music, and vinyl plates.

## Content & structure — site map, pages, content needed, navigation
## Content & structure — site map, pages, content needed, navigation

The website will display shelves of vinyl records in their covers. Each vinyl record will be clickable and open a page that displays information over the songs in the album. In this “details” page you can also select each song to open a separate page where you can add you review and see other reviews. To the right of the vinyls, separated by a stripe, you can select filters to apply to the selection. This will work in addition to the search bar. If the selected vinyls exceed the number that can be shown on one page, a page section will appear between the vinyls and the footer. Here you can navigate through pages.

The data we will use will contain albums, artist and song list at minimum. This is the most critical data we need to show on the website.


## Functionality — features (forms, login, webshop), integrations, user flows
## Functionality — features (forms, login, webshop), integrations, user flows

We will have a button to change the page, a search bar, a way to leave reviews and store them in our database and if time allows we will be making an admin panel. A filter box to change what data is displayed.

## Constraints — timeline, budget, maintenance plan

## Constraints — timeline, budget, maintenance plan

There are several features that will be implemented if we see that we are on schedule and have the extra time to do so. One of them is user accounts with authentication.
There are several features that will be implemented if we see that we are on schedule and have the extra time to do so. One of them is user accounts with authentication.

## Acceptance criteria — clear definition of "done" (must-haves vs. nice-to-haves)
## Acceptance criteria — clear definition of "done" (must-haves vs. nice-to-haves)

The landing page of the website is a view over albums; EPs are also seen as an album. The album count per page changes the default value based on the type of device. Create reviews.
The landing page of the website is a view over albums; EPs are also seen as an album. The album count per page changes the default value based on the type of device. Create reviews.

When clicking in on an album the album view should show which songs the album contains, the user should be able to click on a song in the album and write a review. To ensure content moderation, making reviews with hateful speech disappear, a admin page should be made to ease this process.
When clicking in on an album the album view should show which songs the album contains, the user should be able to click on a song in the album and write a review. To ensure content moderation, making reviews with hateful speech disappear, a admin page should be made to ease this process.

## Design — brand guidelines, responsive/mobile behavior, accessibility

## Design — brand guidelines, responsive/mobile behavior, accessibility
![](./media/Figma-Design-1.png)
![](./media/Figma-Design-2.png)
![Image showing the design](./media/Figma-Design-1.png)
![Image showing the design](./media/Figma-Design-2.png)

Dette er tenkt utforming av nettsiden. Vi har valgt å gå for et retro stil hvor hver plate er et album, og du kan klikke den inn på hver plate for å se hver sang i hvert album. Det skal også være mulig å tab-navigere igjennom hver plate. Mobilversjonen trenger fortsatt litt finpuss, men per nå er siden om lag 700-800px bred, så vi regner med at utforming til mobil ikke blir for vanskelig.
Dette er tenkt utforming av nettsiden. Vi har valgt å gå for et retro stil hvor hver plate er et album, og du kan klikke den inn på hver plate for å se hver sang i hvert album. Det skal også være mulig å tab-navigere igjennom hver plate. Mobilversjonen trenger fortsatt litt finpuss, men per nå er siden om lag 700-800px bred, så vi regner med at utforming til mobil ikke blir for vanskelig.

Technical — platform/tech stack, hosting, performance, browser support, security/GDPR
## Technical — platform/tech stack, hosting, performance, browser support, security/GDPR

We are going to use a mongo database and the same react setup as in project 1. We will be following the technical requirements of the project.
We were initially planning to use MongoDB, but have decided to investigate using a relational database instead. For the frontend we will use the same react setup as in project 1. We will be following the technical requirements of the project.
12 changes: 12 additions & 0 deletions docs/technical-choices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,3 +18,15 @@ We want to store:

- **Current page number** - For user experience in case of page reloads
- **Current filter** - For user experience in the case of page reloads

## Backend

The backend will be an important part of our project. As such, we want to spend an appropriate amount of time on choosing solutions that fit our needs.

### Database

For the backend, the initial plan was to implement MongoDB. Though as was pointed out in the student assesments, the data we plan to present is inherently relational.

Songs relate to albums, which relate to artists. And to top it off, the user reviews are also tied to albums.

Thanks to this, we've decided to replace MongoDB with PostgreSQL. This is due to it's scalability and benchmarked performance for large relational databases. Thanks to it being a popular database, we also get the benefit of many third party database tools to help manage the database.