Project

As a team (2-3 people), you can build whatever you want for your project. By the end of the semester, your app must be deployed and fully functioning. The course staff will evaluate the application online directly.

Your project will be evaluated based on the richness of the web interactions. However, here are things that will not be taken into account:

• wether the application is useful or not
• all things unrelated to web development (game play, machine learning model, 3D models and so on)

Constraints

1. Your frontend must be a Single Page Application (SPA) built with either:

   • A production-grade React either Next.js , Remix or Gatsby (but you CANNOT use create-react-app or Expo)
   • Angular
   • View
   • or Vite

   Indeed, you can combine that framework with other UI frameworks such as Material UI, Bootstrap, Tailwind CSS and so on. If you believe that nonce of these frameworks are appropriate for your project, let’s discuss it. We can make exceptions on a case by case basis if it is justified.

2. On the backend you can use whatever Javascript/Typescript framework you want. Note that some of the React frameworks are full-stack (meaning they can be used in the backend as well).

3. The Web API should be either:

   • RESTful
   • GraphQL
   • or JSON-RPC

4. The application must be entirely deployed on the provided Virtual Machine. The application must be publicly accessible via the VM URL. Optionally, you can have your own custom domain pointing to the VM.

5. The application must have both local authentication and third-party authentication (OAuth) as either: Google, Github or Discord. Optionally, you can also add Multi-Factor Authentication with email verification or a TOTP code.

Marking

The grading rubric is decomposed as follows:

• Team registration and project proposal: 5%
• Beta version: 10%
• Presentation: 10%
• Final version: 75%

Your final version will be evaluated as follows (out of 75%):

• does it work well? 15%
• does it follow the best practices and design principles? 15%
• is it secured? 15%
• is it well implemented? 15%
• how is the quality of the UI/UX? 15%

When comes the time for the course staff to grade your work, keep in mind the following:

• The course staff will not execute your source code but it will directly test your app using the deployed URL. If your application does not work from this URL, your work will get a 0.
• The course staff will checkout your code at the latest commit on the main branch of your official course repo for that work (created through Classroom 50). Code pushed to different commit or different branch will be ignored.
• The code deployed should be exactly the same as the source code on Github. If we notice any difference (even the smallest one) between the source code the deployed version and the source code on Github, your work will get a 0.

All team members must put their best effort to contribute to the project. The instructor reserves the right to assign different grades to each of the team members based on their individual contributions on Github.

Academic Integrity

The course policy on academic integrity applies to this project. This means that all code developed for this project must be written exclusively by the members of the team. Any use code snippet on the source code must be properly cited as code comments. Any UI element under copyright must be clearly cited in the credit page of the application.

You have the freedom to build whatever you want as a project, however the following restrictions strictly apply:

1. the deliverable cannot contain any piece of work that was developed outside of the scope of this course
2. the deliverable cannot contain any piece of work that will also be used for another paid work
3. the deliverable cannot contain any piece of work that will also be used for another course deliverable

Each team member is responsible and will be held accountable for the work he or she submits to the Github repository.

On the Responsible Use of AI

You are permitted to use AI tools to assist you in writing your code. However, you must clearly identify all AI-generated portions. That said, you remain the full owner of the code and you are fully responsible for all code submitted under your name. Therefore, you must be able to explain every part of it in detail. Any part that you cannot explain properly can result in mark deductions or failing the project completely.

From past experiences, AI-generated code is often unnecessarily over-engineered and may fail to follow best practices. Projects that relied too heavily on AI have generally received lower grades as a result.

My recommendation is to use AI critically and thoughtfully. Always question what the generated code does, verify its correctness, and ensure it truly and precisely solves the problem at hand.

Project Requirements and Challenge Factor

In the end, the course staff will not judge the idea itself but the overall effort that was put in the project. Instead, we will evaluate the quality of the application and assess whether the application is substantial and challenging.

Indeed, we acknowledge that it is harder to deliver higher quality when the project idea is challenging. Yet, we want to encourage you to explore complex web interactions for your project.

Therefore your project will receive an challenge factor that ranges between 0.5 and 1.5 that we will use to adjust your project final mark. For instance, a challenging project with a challenge factor of 1.2 and a score of 78/100 will receive a final mark of 93/100.

Deliverables

Team Registration on Classroom 50

One team member only should create the group by accepting the assignment on Classroom 50, then adds teammates up to the max group size.

Project Proposal

As a team, you will submit your proposal on Github. Your proposal should be in the PROPOSAL.md file at the root of your Github repository. Make sure that your proposal is properly formatted in Markdown format.

To receive full credits, the proposal should contains the following information:

• project Title
• a description of the web application
• a description of the key features that will be completed by the Beta version
• a description of the additional features that will be complete by the Final version
• a description of the technology stack that you will use to build and deploy it
• a description of the top 5 technical challenges. Understand that a challenge is something new that you have to learn or figure out. Anything we have already covered in class cannot be considered as a challenge. Making the application work and deploying it is not a challenge but a project requirement.

Beta Version

By the beta version deadline, your team should have:

1. pushed the beta version to the project repository on Github
2. deployed the application
3. fill the design document (README.md file)
4. scheduled a 20 min meeting to demo and discuss the beta version (coming soon).

The meeting with the TA must be scheduled before the deadline but it can take place after the deadline. To receive full credits, your team should demonstrate that the key features of your application work on the deployed application.

Final Version

By the final version deadline, your team should have:

1. pushed the final version to the project repository on Github
2. deployed the application
3. update the design document (README.md file)

Filling the design document is very important to help the instructor grading the project. A vague or shallow design document might result in a lower overall project grade. However, it is very important to keep in mind that quantity does not beat quality. Unnecessarily verbose design document and/or excessive use if AI will be penalized as well.

Make sure that your design document is properly formatted in Markdown format.

Since every project is unique, grading is subjective. While evaluating the application, the course staff will take into considerations:

• is the idea challenging and substantial?
• what is the amount of new things that the students have had to learn?
• it it complex to build? Is it complex to deploy?
• is the user interface user-friendly?
• is the application working well?
• is the application secured?
• is it well implemented? does it covers the concepts seen in class correctly?
• is the source code clean and well organized?

Presentation

Given that we’ll have about 50 projects. It is not possible to ask all of you to give a presentation in class. Instead, you are going to take a video demoing your app. This video must 3 min long (+-20 seconds). It should show your web app only (no slide, no code) and the soundtrack should be you explaining what you are doing on screen. To make this video, you can either use Zoom or VLC.

[possibly] Code Interview

The instructor reserves the right to ask all team members for an in-person meeting after the submission of the beta version and/or the final version in which you will be asked to justify your design choices and and explain your code in details.

Recommendations

Here are some key recommendations to consider:

• Work on the most challenging parts first. Have them ready by the beta version.
• Deploy early, deploy often. Deploying is harder than you think and it requires major changes in the code most likely.
• Be careful with third-party APIs. Be aware of their limitations and restrictions.