Project demonstration
Overview¶
For your team to complete the Working System and Value Enhancing Features tasks, you will need Project Demonstration video, that satisfies both task's requirements.
Two tasks, one video; Car analogy
It might be confusing, why two tasks have one combined video output, but think of it like this:
-
When you buy a car it has a set base price. On its own it fulfills everything a car should, but it has no extra services. In your project this is the Working System.
-
You can pick and choose extra features for your new car, like seat heating or a rear camera, and you will have to pay for those separately. In our case these are the Value Enhancing Features.
Without buying a car, there is no reason to talk about extra services, but without these complemetary features driving the new car could be bland - this is why you will need to demonstrate the basic and advanced parts of your project in one video.
Rules and Video Settings¶
1. Length and Format¶
- Total Time Limit: The video must be between 15 and 20 minutes long. If your video is longer than 20 minutes, tutors will not watch it, and you will get 0 points for your features.
- How to Submit:
- Option A: One long video that shows everything.
- Option B: A YouTube Playlist with shorter videos for different parts. Important: The total time of all videos in the playlist must still be between 15 and 20 minutes.
- Warning: YouTube asks you to verify your account to upload videos longer than 15 minutes. This is free and standard. Please verify your account at the start of the semester so you do not have upload problems later.
2. How to Record the Video¶
- Show the App, Not the Code: Show your program running in the terminal or in an app window. Do not show your code, your IDE (like VS Code or Eclipse), or your source files.
- Voice and Audio: You must talk and explain the program in the video. Speak slowly and use simple words. Make sure your microphone is clear and your text font size is large enough to read. Subtitles alone are not allowed.
- Style: The video should be a professional presentation for targeting the end-user, NOT a pal, a peer, a teammate, the tutor etc.
- Language: The video must be in either Hungarian or English, but not a mix of the two.
Video Structure¶
The video has two main parts, for which teams will receive the most points:
For your video to be well-rounded we recommend it to follow these four parts in order:
Section 1: Project Introduction (1–2 minutes)¶
Open your video and briefly tell us:
-
The name of your project.
-
The main goal of your system.
-
The real problem that your application solves for the user.
Section 2: The system is working¶
Show one main story of your program from start to finish with no errors or crashes. You must show:
-
How to start the program.
-
How to type in the basic inputs.
-
How the user interacts with the app.
-
The final result or output screen.
-
Note: You do not need to show every feature here, only the main steps to make the program finish its basic job.
Example: Tamagotchi Project Main Story
For a digital pet game, the main story shows starting the app, creating a new pet, feeding or cleaning it, and letting the game run until a clear end (for example, the pet grows up safely or dies).
Example: Team 'ByteBusters' Main Demo
For a book catalog system, the team starts the video with a one-sentence introduction. Then, they open the terminal app. They add two books, search for the word “Dune,” and show the book details on the screen. They only show the running app—no code editors.
Section 3: Value-Enriching Features¶
Show the features that you chose and priced with your tutor before building them. For each feature, you must show:
-
What problem the feature solves for the user.
-
What the system looks like before you start the feature.
-
How to use the feature live on screen.
-
The successful, expected result to prove it works every time.
-
The GitLab issue ID number for this feature.
Examples of Features
These are things that add value to your app, such as:
-
Mini-Games: An interactive game (like a Monty Hall game) inside your app.
-
Data Systems: A system to Save and Load your progress.
-
Statistics: Screens that show charts, results, or data reports.
-
Customization: Changing colors, dark mode, or user profiles.
-
Data Export: Saving your data into an external file to share it.
Example: Team 'NullPointers' Feature Demo
To show a "Load CSV file" feature, the team uses a small test file, types the command, and shows the success screen. They also show what happens if the file is missing to prove the app handles errors correctly without crashing.
Example: Team 'PixelPenguins' Feature Demo
For a simulation grid feature, the team opens the grid, clicks a few blocks, runs the simulation to show them moving, and explains why this helps the user. They switch to the next feature smoothly without showing any algorithm code.
Section 4: Closing & Reflection (1–2 minutes)¶
End your video with a short summary:
-
What your team successfully built and achieved.
-
Be honest: list any known bugs, errors, or limits still left in the application.
-
What features you would add in the future if you had more time.
Links and Timestamps (Mandatory)¶
Video link
Copy your final YouTube video or playlist link and paste it into your project's README.md file under a clear ## Product Demonstration title.
You must map your video chapters or playlist videos to your GitLab issues in the YouTube description box. If you do not add links and timestamps, you will get 0 points for your features.
Providing links and timestamps is a good practice, since it helps the users navigate the system and identify agreements.
Your YouTube description must look like this:
Example: Timestamps
1 2 3 4 5 6 7 8 9 10 11 | |
Copy your final YouTube video or playlist link and paste it into your project's README.md file under a clear ## Product Demonstration title.