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 and so on)

Your frontend should be built on either React (strongly recommended), Angular or View. 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.

Marking

The grading rubric is decomposed as follows:

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

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

• 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? 10%

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 of UI elements and snippets of code found on the web must be clearly cited in the credit page of the application.

You have the freedom to build whatever they 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.

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 and project proposal

After registration, each team will be assigned a new private Github repository for the project. By the project proposal deadline, the team should have pushed the proposal to their project repository. The proposal will take the form of a README.md file at the root of your project repository on Github. This file should be properly formatted in markdown.

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

• project Title
• team Members
• 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. scheduled a 20min meeting to demo and discuss the beta version.

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.

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 and provide its public URL in the README.md file
3. filled the design document template (coming soon)

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?
• it it complex to build? Is it complex to deploy?
• is the user interface intuitive and appealing?
• 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 (no slide, no code) and the soundtrack should be you explaining what you are doing on screen.

To make sure that this video is of good quality, here is a good way to proceed:

1. take a video of you demoing your app. Do not film your physical screen with your phone. Instead, make a video by capturing your screen and your microphone directly on your computer. You can easily do that using VLC: open “File” > “open capture device”, select “screen” and check “use mic”
2. Check the video quality, edit the video if necessary. Again VLC can do this with VLC.
3. Upload this video on Youtube (either as a private or public video) and share the video URL on your Github README file.

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 API. Be aware of their limitations and restrictions.