Lab 7: Milestone 2 Demo Preparation - bounswe/bounswe2025group5 GitHub Wiki

Demo data strategy

Data

The application should be populated with a reasonable amount of high-quality data to best reflect the core characteristics of our system during the Milestone 2 demonstration. A well-populated dataset is also essential for testing all features thoroughly, especially those related to waste tracking, challenges, user interaction, and community features.

Quality

For demonstration purposes, the data should be high quality and should show realistic, meaningful interactions that align with the app’s sustainability mission. This includes:

  • Users actively interacting about waste reduction, recycling tips, and eco-friendly habits through the forum.
  • Challenges with good titles and descriptions, along with populated and competitive leaderboards.
  • Waste goals that make sense and show real user progress.
  • Users following each other, forming a small but active network.
  • Posts that reflect our core content style: sustainability discussions, waste reduction stories, recommendations, and community support.

For testing, the dataset should include enough volume to push system limits:

  • Heavy amounts of waste logs to test logging overload and analytics stability.
  • Dense follow networks (many users following one another).
  • A spread of likes, comments, saves, reports, and other post interactions.
  • High variation in post content to test semantic search, tagging, and moderation workflows.

Quantity

  • 50–100 posts, each containing interactions (likes/comments/saves), with some posts highly active and others less active.
  • ~3 personal waste goals per test user where applicable.
  • ~10 challenges, each with a description, duration, and a leaderboard with many competitors within.
  • 100–200 users, each following at least 1–10 people, ensuring the follow network graph is realistic and not empty.

These quantities ensure the system can be demonstrated meaningfully while also being stressed enough to uncover bugs and performance issues.

Data Population

To facilitate data generation, we frequently sought insights from communities like Reddit that align with our objectives. Since we had previously analyzed similar communities in our research linked here, we encountered no difficulties in generating synthetic part of our data. We implemented the following steps to incorporate both synthetic and organic data:

Postman

In the first stage, a curated set of meaningful and high-quality seed data will be generated (with the help of AI tools where appropriate).
This chunk of well structured data will be inserted into the database using Postman and the associated backend endpoints.
The goal is to ensure that the app opens with a realistic, populated environment from the very first load.

Friends & Organic New User Interaction

Parallel to the Postman population, we will recommend the app to friends and close network groups to gather organic usage for at least one week.
This will naturally increase both the amount and quality of data, especially in areas such as:

  • post interactions (likes/comments/saves)
  • following/unfollowing
  • joining and completing challenges
  • organic waste logging
  • real behavior patterns for semantic search and tagging

Organic usage increases authenticity and helps us observe real user flows before the milestone demo.


Demo Case and Plan

We are planning to deliver the whole demo in a single, comprehensive scenario. The goal of our scenario is emphasizing all our new and key features on action in a realistic scenario. Our scenario is the next chapter of the story we started in the first milestone demo, consisting of granddad and his grandson. The actors will remain the same, granddad for Yusuf Onur Öksüz and the child for Ali Bartu Konca.

The first 10 minutes of the presentation is planned to be spent on scenario presentation, which will deliver all content and features. In this part, we are planning to present everything that customer wants to see, without an introduction or any explanation. The remaining 5 minutes is saved for questions from the customers and constructive feedback on our progress. The customer's reaction throughout the demo will be observed by our team members so that we can get clues from non-verbal actions.

Here we have our detailed and step by step demo that we will perform for ~10mins for the MVP: MVP Scenario

Status of software requirements compliance

The project is currently in the implementation stage. Group members are actively working within their respective branches. Code is being merged into the develop branch after dedicated testing, with the final merge into the main branch scheduled upon completion of implementation and comprehensive testing. Unit tests are being implemented concurrently with code development.

Key Deliverables Status

RELEASE

  • Status: The team is not yet ready to create a tag or pre-release, as implementation and testing are still in progress.
  • Next Steps: Following the completion of implementation, it is estimated to take a few hours to build the mobile APK and push the final release.

SUBMISSION

  • README.md file: The project root is missing a complete README.md file. Both the frontend and mobile teams are required to contribute their respective sections, including necessary information regarding relevant .env files.
  • Estimated Completion: Approximately 2 days to finalize the complete README.md.

DELIVERABLES

1. Web Deliverables

  • Docker Compose: A draft Docker Compose file is awaiting review and finalization by the frontend and backend teams.
  • Status of Files: The frontend is currently missing a .env.example file.
  • Estimated Completion: Finalizing the Docker Compose file, creating the .env.example file, and completing the README.md section are estimated to take approximately 2-3 days.

2. Mobile Deliverables

  • Current Build Environment: APK files are currently generated using an external build provider (Expo). The codebase connects to a remote machine for all backend requests.
  • Status of Files: The mobile group is missing a .env.example file. A working Dockerfile is not yet available
  • Estimated Completion: Providing and integrating the .env.example file is a short task, planned for completion within the implementation stage (a few hours). Switching to a new building environment and providing a dedicated, fully working Dockerfile are estimated to take roughly 2 days.

ASSESSMENT

The estimated time for deliverables of teams do not depend on each other. So it can be done in parallel although both web and mobile applications need 2 days to fully deploy the application. The README.md file will be written easily after the deployment is successful. The estimated goal is to finish the implementation and testing phase at least 2.5 days prior to the deployment stage, allowing sufficient time for compliance checks and the final release push.