TDP013 Web Programming and Interactivity

A social website

Learning objectives

From the syllabus: Link to syllabus

• Create rich web pages that include dynamic information, interactivity and database connectivity;
• Using programming languages such as JavaScript and NodeJS to create interactive Web content;
• Using techniques such as AJAX and REST to create interactive Webcontent;
• Apply the rules of good interaction design for web pages and sites;
• Plan and implement the creation of a website.

Aims

The aim of the project is to independently use and expand the knowledge acquired in the previous lab sessions.

Implementation

The project is intended to be completed in pairs according to webreg and the size of the task is adjusted accordingly.
For a passing grade, the basic requirements must be met. For higher grades, see Requirements for higher grades below.

Requirements for basic (Grade 3)

• Users should be able to register with a username and password.
• Users should be able to log in and log out.
• Passwords should not be sent or saved as readable text.
• Only new information should be updated on the website, i.e. the entire website should only be reloaded in exceptional cases.
• There should be a search function to find other users. You should be able to search for users even if you only know part of the name.
• Users should be able to send friend requests to other users.
• Friend requests must be accepted before becoming friends.
• Friend requests should not be able to be sent to users you are already friends with.
• Users should be able to see a list of their friends.
• Users should have a personal page.
• Users should be able to see their friends' pages.
• Users should only be able to post messages on their own and their friends' pages.
• Users should not be able to act as someone else, i.e. accounts are personal.
• New messages must be validated on the client side. Messages cannot be empty or contain more than 140 characters.
• New messages should be validated on the server side according to the same rules as above.
• Leading and trailing whitespace characters should be trimmed from messages before validation.
• Data should be saved in a MongoDB database.
• The server side should be protected against MongoDB injections.
• Testing/code coverage of the backend should be done with Mocha/Istanbul.
• All elements should be placed appropriately in relation to the space, with appropriate adjustment of components in height and width, and well-chosen distances between components.

The website should use all the techniques used in the labs. All basic functions should be tested and it is important that you can describe and justify both functionality and visual layout.
The website does not have to be graphically "pretty" but should clearly show that it has been built based on conscious choices.

Requirements for higher grades

• req-1: A functionality for friends to chat with each other in real time using HTML5 WebSockets and the socket.io plugin for NodeJS;
• req-2: Use a client framework to build the application (React is recommended but other frameworks are fine to use after consulting with the lab assistant).

Requirements for grade 4: The basic requirements + req-1 or req-2;
Requirements for grade 5: The basic requirements + req-1 and req-2.

Demonstration

Demonstration is done in two parts: submission of code and oral presentation at a seminar.

Submission of code

1. Upload your code and other relevant files for the lab to your assigned repo at gitlab.liu.se.
2. Create a tag (use the format project-v.1.x) for your submission. When correcting, it is always the most recently tagged version of the project that is corrected.
3. Include a README.md file, a description of how to run your project and tests. For example, if you need to change any of the default settings for MongoDB or if you have hosted the website on your own server, please also state this.
4. Send an email to the teacher responsible for your assigned group, including the link to your GitLab repository. Subject of the email: "TDP013_2025_GROUP_NUMMER-project-LiU-ID". You can check your assigned group on webreg.



For group A, please send your code to (to be assigned) .

For group B, please send your code to (to be assigned) .

For group C, please send your code to (to be assigned) .

Oral presentation at a seminar

All students will present their project individually in groups, even if the project was done in pairs. You will be assigned a group and time to present the project. During the presentation, you will briefly describe your app and the techniques behind it. You will also show a demo of the app, which can either be done live (which is preferable) or as a recorded screencast. Feel free to show and discuss some well-chosen parts of your code. The presentation should take about 10 minutes, followed by questions from the audience (about 5 minutes).

Registration on webreg

• Project seminar registration via project seminar on webreg and make sure that you and your lab partner register in two different groups.
• Project group registration via project group registration on webreg and make sure that you and your lab partner register in one group. (same as lab registration and this is for reporting project results).

Demonstration on missed seminar

If you miss a seminar, prepare a 10-minute screencast according to the same instructions as above. Since there is no opportunity to ask any questions, it is important that you are extra clear about how your application is structured. Therefore, plan what you are going to say before you make the recording. Share the video as a downloadable link to huanyu.li@liu.se.

Frist Submission Deadline:13 October 2026 - 23:59 CEST
Revised Submission based on comments from seminars:21 October 2026 - 23:59 CEST

Page responsible: Huanyu Li
Last updated: 2026-08-24