Projects

1. Project One - TMBD PWA
2. Project Two - NextJS Crapr

1. PWA Project

An installable, Offline-first PWA, with a responsive layout, that will have parts that work when offline.

This is a joint project between MAD9022 and MAD9124. The PWA portion of the app will be the deliverable for MAD9022 and the server-side API portion will be the deliverable for MAD9124. Each part has its own due date. Both parts need to be working for your MAD9022 PWA to work. If you don't have a working API then there is no way to have a working PWA.

The app starts with a search screen that lets the user enter a keyword and select how they want to sort the results. Submitting the search form takes the user to the search results screen and runs the fetch call to your API. The results of the call to your API get displayed on the search results screen as a series of list items. Each of the images for movies in the search results should be saved in the cache to save time later.

Each of the list items has a thumbnail image, an icon, and a movie title. If the user clicks on one of the thumbnails the app will navigate to a details screen that shows a bigger movie image, the movie title, plus other information about the movie. The details of a selected movie need to be saved in a separate cache as a JSON file.

The app needs to meet all the PWA requirements so the install icon appears in the location bar.

When the browser is offline, the service worker should return all the static files from the cache. The user should still be able to go to the home page fill in the form and submit it. This will take the user to a results page, but a cache results page will load instead of the search results page. The cache results page will display list items like the search results page but the content of those list items will be the list of movies from the JSON in the second cache, the movie one with the JSON files.

App Screens

The different screens in the app are:

1. Home screen - shows a title header and a search form with a search input, a way to pick the sort preference, and a search button.
2. Search Results screen - shows a title header and list tiles with thumbnail images, movie titles, and icons.
3. Cache Results screen - looks like the search results screen but only displays movies that are in the cache.
4. Movie Details screen - display a bigger image and lots of details about a single movie.
5. 404 Error screen - when the user asks for a page that does not exist in the cache or online, return a custom 404 error page.
6. Favorites Screen - Display a list of movies marked as favorites by the user. Data fetched from a local cache or database.

Home Screen

In the search form you need an <input type="search" /> to hold the keyword, a button to click to submit the form, and some way of choosing the sorting preference for the results - release date, popularity, or votes.

Submitting the form will navigate to the search results page and pass the details from the form through the query string.

Search Results and Cache Results Screens

When this page loads, the script needs to read the values from the querystring and make the fetch call to the API that you are building for MAD9124.

If the browser is offline, and the user navigates to the search results page, the service worker will send back the cache results page instead.

If the browser is offline and the cache results page has loaded, the fetch call to the API does not happen because there is no connection to the API. Instead, the fetch call gets intercepted by the service worker and it will return an array of all the JSON data in the Movie details cache. ALTERNATIVELY, you can have the script use postMessage to send a request to the Service Worker to get all the cached movie details. Only the service worker knows the name of the cache with the movie details JSON files. It needs to be the service worker the retrieves and send the JSON from the cache to the main webpage script.

Both the search results and the cache results pages will display list tiles. Each list tile shows a thumbnail image for the movie, the movie title, and some icon. If the user clicks on a list tile, get the movie id from a data- property in the list tile and send the user to the movie details page with the movie id in the querystring.

Movie Details screen

When the movie details screen loads, the script will read the movie id from the querystring and make a fetch call to the API that you are building for MAD9124 to get the details. If the browser is online, then the service worker continues to make the API request. If the browser is offline then it looks in the cache.

When online, the results of every API search for a specific movie get saved in a movie details cache.

Custom 404 screen

Create a custom 404 error screen that is saved in the cache. If the user tries to navigate to a page that does not exist or is not in the cache then this custom 404 page should be returned to the browser and displayed.

Favorites screen

Display a list of movies marked as favorites by the user. Data fetched from a local cache or database.

Design Requirements

Your app needs a custom colour scheme that passes accessibility testing.

Your app needs a custom web font. (saved in the cache)

Your app needs an icon web font. (saved in the cache)

The interface layout responsively scales to work on any screen size.

Text sizes should responsively adjust for the available space as needed.

All the design elements should work when the app is offline too.

PWA Requirements

There is a manifest file that includes all the different icon sizes.

There is a service worker that handles the install, activate, and fetch events.

File and Cache Paths

All the paths for the files in your cache and in your pages and scripts need to work locally when testing AND when the app is running off of Github Pages.

The lighthouse PWA test passes in Chrome when run on the Github Pages version of your app and it can be installed.

There are TWO caches - one for the app files (like index.html) and one for the MOVIE .json files.

Demo Video

Here is the demo video that outlines the functionality for this app.

Tips for Success

• Start your project early. Don't wait until a couple days before the due date.
• Make many commits to your repo.
• Push to Github and update your hosted site early and often.
• Test the production version early and often.

Submission

1. Create a private Github Repo and invite shah0150 to the repo.
2. Create a Github Pages site, or Vercel site, or Netlify site using the main branch for your private repo.
3. Fully test your app on Github Pages, or Netlify, or Vercel to make sure that all the paths and functionality works.
4. Submit the public URL for your website.
5. Submit the URL for your private Github repo that contains your project to BS LMS.

Due Week 7 (See BS LMS for exact date and time)

2. NextJS Project

//TODO: Update this for s2024 semester

For the final project you will be working with a partner to create a full-stack NextJS app version of the Crapr app.

This project is a joint project between MAD9022 and MAD9124. The client-side React part of the project is for MAD9022 and the server-side MongoDB, NodeJS, Passport, and Express part is for MAD9124.

Make sure you let your instructors know who your partner is so the groups can be created in BS LMS for the assignment submissions.

Project Summary

We are building a website that lets people get rid of unwanted crap from their homes. Everyone who visits the site needs to register and login in order to use the site. While not logged in they only see the homepage and the about page. Any user can post about crap to get rid of or express interest in taking the crap. Let's call these different roles the seller and the buyer.

After logging in, the seller can create a post about what crap they are trying to get rid of. They can also view a list of all their own crap which has been posted. This list can be filtered by sold or not sold status.

After logging in, the buyer can search for crap based on their current location, filtered by keyword.

When a buyer finds something they want they can click a button to indicate that they want to have the crap.

After a buyer has clicked the button, a seller can see that interest has been expressed in the item by viewing their own posted crap list. The seller responds by providing a pickup date and time range, plus the actual physical pickup address. Alternatively the seller can cancel the transaction telling the buyer that they have decided to continue hoarding their crap.

The buyer finalizes the process by agreeing to the pickup time and date.

The seller marks the crap as sold or "flushed" after it has been picked up.

When a seller or buyer logs on, they should be notified about a change in status of one of their items OR taken directly to the page for the first item with an updated status.

User Roles

While we will often use buyer and seller to refer to a user, this only applies to the role that they are currently fulfilling on a page. Any user can be both or either. There are not two kinds of users.

When someone posts some crap on the website, they are being a seller.

When someone expresses interest in a piece of crap, they are being a buyer.

It all has to do with the users' relationship to a single item.

Navigation Routes

Here is a list of the routes for the website.

• / : the home page which will display either the login/signup form OR a search form if you are logged in.
• /offer : page where a user can offer their crap to the world.
• /crap : results from a search based on keyword and location. Shows only the unclaimed crap.
• /mine : shows all the crap posted by the current user. Can be filtered with querystring param.
• /crap/[id] : shows the details for a specific unclaimed crap. From this page the buyer and seller can interact with each other.
• /wiped : the redirect page for a specific crap if it has been flushed or doesn't exist or is under negotiation and does not belong to the current user or the user who expressed interest.

Functionality and Features

The user needs to be logged in to be able to use any features of the site.

From the home page, a user can log in and then, after being logged in, do a search for items. The search form needs to have an input for a keyword plus a selection of the distance range for searching.

On the search results page /crap the results should display the titles and descriptions. Each result should be styled to indicate if an item belongs to the current user or not. Clicking on an item will take the user to the /crap/[id] page. Items that appear on this page will only be items with a status of AVAILABLE.

On the /offer page, the user should be able to upload a new piece of crap. The new item needs to include a title, a description, and an image. After uploading a new item, redirect the user to the /mine page.

The /mine page should display a series of cards with the title, description, status, AND image for each piece of crap. The statuses for an item are AVAILABLE, INTERESTED, SUGGESTED, AGREED, and FLUSHED. Clicking on any of the cards will take the user to the /card/[id] page.

On the /card/[id] page, the user can see all the same details of the item PLUS a button to delete the item AND a form for changing the status of the item. The delete button is only shown IF the current user owns the item. Depending on the current status of the item, there may be additional information like the address, date, and time for pick up.

The form for changing the status of the item changes depending on the current status.

• If the current status is AVAILABLE, then the user needs a button to change the status to INTERESTED. Only a user who is NOT the owner of the item will see the form and be able to make the status INTERESTED.
• If the current status is INTERESTED, then the user needs to be able to post an address, a date for pick, and another string that represents the time for pickup. Only the owner of the item can add this information and change the status to SUGGESTED.
• If the current status is SUGGESTED, then the user must NOT be the owner to change the status to AGREED with a click of a button.
• If the current status is AGREED, then the OWNER of the item will get a button to FLUSH the item. This means that it has been picked up.

Design

Your Layout must be Accessible and Responsive.

Hosting and Routing

You will need to create a private Github Repo that holds the code for your React app.

You will need to connect your repo to Vercel, which will be responsible for the build process and hosting of the website.

Remember to set your ENV variables on Vercel, so you have a different set on localhost than on Vercel.

Optional bonus / future features

• rate the buyer
• rate the seller
• propose alternate pick up time and date
• push notifications about buying and selling

Submission

Code Review Interview

20% of your grade for this project will be for completing an interview with your instructor during class in week 15.

BOTH partners must be present at the same time for the interview. Missing the interview means that the missing person gets zero for that 20%. Your project does not need to be complete to take part in the code review interview process.

The interview will consist of two parts, for each person:

1. You explain how the code for one feature works.
2. Your instructor will ask you to explain one or two items your code.

Code submission

Submission for this project requires multiple steps.

1. You will need to submit the private Github repo URL for your NextJS project.
2. Submit the private Github repo URL for your MAD9124 API.
3. Submit the public URL for your MAD9124 API plus
4. Submit the public URL for your production Vercel NextJS site.
5. Invite your instructor to BOTH your private repos.
6. Invite your instructor to your Vercel dashboard.

See BS LMS for the exact due date and time.

Late submissions will NOT be accepted.