-
Notifications
You must be signed in to change notification settings - Fork 1
Lab 7: Milestone 2 Demo Preparation
Comprehensive mock data generation system using Django management command (create_mock_data) that produces realistic, reproducible test/demo data for the Zero Waste application.
- Curated Content: 50+ recycling tips, achievements, post captions, and comments themed around sustainability
- Realistic Relationships: Activity-based follow network (active users get more followers), natural engagement patterns
-
Reproducible Generation: Seed support (
--seed=42) for deterministic output - Flexible Modes: Generate full dataset or target specific types (users, posts, follows, wastes, tips, challenges)
-
Safe Testing: Dry-run mode (
--dry-run) validates without persisting - Domain Logic: Waste-type weighted distribution, points/CO₂ calculations, challenge participation
# Full dataset (default: 100 users, 100 posts, 30 tips, etc.)
python manage.py create_mock_data
# Small reproducible test set
python manage.py create_mock_data --num-users=20 --num-posts=30 --seed=42
# Validate without saving
python manage.py create_mock_data --dry-run --seed=test
# Generate only follow relationships
python manage.py create_mock_data --mode=follows --num-users=50Every generation includes: test_user / [email protected] / test123 with guaranteed followers/following
6 modes (full, users, posts, follows, wastes, tips, challenges) × 10+ CLI options for complete control over data volume and characteristics
Our demo data strategy consists of a configurable create_mock_data script. It can generate any number of relevant instances of any type that we can specify the type of. This approach allows us to worry less about test data corruption and allows us to have less overhead on data creation. We will keep on improving this script as we develop new features for our application. For specific cases we will resort to adding data manually on top of the generated data for the case; since, automating it would require more overhead than we can afford to.
Ayça is a stay-at-home mom with two kids (ages 5 and 8). She manages the household and is conscious about creating a better environment for her children. She's moderately tech-savvy and values practical solutions.
Her neighbor mentions the app during a parent-teacher meeting, saying it helped her family develop recycling habits. Ayşe downloads it that evening and registers with her email account.
- Explores Tips Tab during breakfast: Finds "Teaching kids about recycling through games"
- Introduces the app to her kids as a "family game"
- First entry after weekend cleaning:
- Plastic:
<unit> - Paper:
<unit> - Glass:
<unit>
- Plastic:
- Kids get excited seeing the points accumulate
- Makes recycling a Saturday family activity
- Tips Tab becomes her morning reading: "Reducing kitchen waste," "Composting at home"
- Creates a Personal Challenge: "Collect 2 liters of cooking oil monthly"
- Starts saving used cooking oil after reading tips about its environmental impact
- Joins Community Challenge: "Family Recycling Month"
- Posts in Community Tab: "How I got my 5-year-old excited about recycling" with photos
- Receives likes and many supportive comments from other parents
- Discovers that organic waste (vegetable scraps) also earns points
- Starts a small compost bin on the balcony after seeing tips
- Organic waste:
<unit> - Finds old batteries in the garage (from kids' toys) → High-value e-waste!
- Batteries:
<unit> - Achievement unlocked: "Eco Warrior Family" badge
- Checks Leaderboard casually — not competitive but enjoys seeing progress
-
Total Points:
<quantity>points -
Leaderboard:
<rank>th place - Achievements: Badges (Eco Warrior Family, Green Parent)
- Community: Active in "Parents for Planet" group
- Impact: Family develops sustainable habits, kids learn environmental responsibility
- Practical benefit: Saves money by reducing waste and reusing items
Key Features Demonstrated: Tips Tab (practical daily use), Personal Challenges, Community Challenges, Achievements, Community Tab (parent network), Points System (family motivation), Organic Waste & Oil categories
User Persona: Ayşe, a Turkish speaker living in United Kingdom. Her phone's system language is English, but she prefers to use the app in Turkish.
Objective: A new user, Ayşe, downloads the app, selects her preferred language during onboarding, and confirms that accessibility features like text scaling work correctly.
Why this scenario: This demonstrates the new user-level language management, internationalization (i18n), and WCAG text scaling features in a single, seamless flow. It proves the app can adapt to user preferences beyond system defaults.
Pre-demo data to seed:
- At least two languages available: English (en) and Turkish (tr).
-
First Launch & Language Selection: Ayşe downloads and opens the app for the first time on her phone, which is set to English. The app initially displays a language selection screen. Ayşe scrolls and taps on "Türkçe" (Turkish). The entire interface immediately and seamlessly transitions to Turkish.
-
Onboarding in Turkish: She proceeds through the onboarding screens. All text, from welcome messages to feature descriptions, is now in Turkish. She taps the "Hesap Oluştur" (Create Account) button.
-
Sign Up & Profile: Ayşe enters her details and signs up. After logging in, she navigates to her profile page.
-
Testing Accessibility: Curious about readability, Ayşe goes to her phone's system settings and increases the font size to 150%. She returns to the app. All text, including the bottom navigation tabs ("Anasayfa," "Topluluk," "Profil") and headers, has scaled up perfectly without breaking the layout or overlapping.
-
Consistent Navigation: She taps the "Topluluk" (Community) tab at the bottom, then taps on a post to see its details. The top app bar consistently shows a "Geri" (Back) arrow on the left, which takes her predictably back to the community feed. The structure feels intuitive and reliable.
Success criteria:
- User can select a language on the first launch that overrides the system default.
- The entire app UI correctly reflects the chosen language (Turkish).
- Locale-aware formatting (date) is applied correctly.
- The app layout remains functional and readable when system font size is increased to 200%.
- Navigation (Back button, Bottom Nav) is consistent and predictable across different screens.
Inclusive UX notes:
- Language selection is one of the first steps, empowering users immediately.
- WCAG 2.1 AA text scaling compliance is directly demonstrated.
- Predictable navigation aids users with cognitive or motor impairments.
User Persona: Omar, an Arabic speaker who uses the app daily.
Objective: An existing user with his language preference set to Arabic logs in and interacts with the app, showcasing a fully functional Right-to-Left (RTL) layout.
Why this scenario: This is a crucial validation of the foundational internationalization work. It proves that the app's UI is not just translated but is dynamically mirrored to support RTL languages, ensuring a native-feeling experience.
Pre-demo data to seed:
- An existing user account with language set to Arabic (ar).
- A 3-day streak to show on the home screen.
- A few community posts in Arabic.
-
RTL Login & Home Screen: Omar opens the app. He is already logged in. His preference is set to Arabic, so the app loads directly into an RTL layout.
- The home screen text "أهلاً بعودتك يا عمر" (Welcome back, Omar) is right-aligned.
- The profile icon is on the top-left, and the main page title is on the top-right.
- His "سلسلة 3 أيام" (3-day streak) card has its icon on the right and text on the left.
-
Logging Waste in RTL: He taps the "أضف سجل اليوم" (Log today's entry) button. On the logging screen, the form labels are right-aligned, and the input fields expect text to be entered from the right. He logs 0.5 kg of plastic.
-
Navigating the Mirrored UI: He opens the navigation drawer (if applicable) by swiping from the right edge of the screen. He closes it and uses the bottom navigation bar. The order of icons is mirrored from the LTR layout (e.g., Profile is on the far left, Home is on the far right).
-
Interacting with RTL Content: He taps on the "المجتمع" (Community) tab. The feed of posts is laid out from right to left. Each post has the user's avatar on the right, with their name and the post content flowing to the left.
Success criteria:
- The app correctly loads the RTL layout based on the user's language preference.
- All key screens (Home, Log Entry, Community, Profile) display a correctly mirrored layout.
- Interactive elements like navigation drawers and bottom tabs function correctly in RTL.
- Text alignment and component placement are correct across the entire app.
Inclusive UX notes:
- Full RTL support provides an equitable and intuitive experience for millions of users.
- Consistent mirroring of navigation patterns ensures predictability for RTL speakers.
User Persona: Elif, a user with low vision who relies on her phone's screen reader (e.g., TalkBack/VoiceOver) to navigate apps.
Objective: Elif navigates the app using only a screen reader, successfully logging her daily waste and browsing challenges, demonstrating the app's compliance with WCAG 2.1 AA for non-visual navigation.
Why this scenario: This directly tests the accessibility and navigation consistency changes, proving the app is usable for people with visual impairments. It highlights clear labels, logical focus order, and accessible announcements.
Pre-demo data to seed:
- An active user account for Elif.
- Several challenges available in the challenges list.
-
Logging In & Home Screen Narration: With her screen reader active, Elif opens the app.
- The screen reader announces: "Email address, text field." She enters her email.
- She swipes right. "Password, secure text field." She enters her password.
- She swipes right again. "Log In, button." She double-taps to log in.
- On the home screen, the focus moves logically. It announces: "Welcome back, Elif. Heading level 1." Swipe. "Current streak: 4 days." Swipe. "Log today's waste. Button."
-
Navigating with Clear Labels: Elif wants to explore challenges. She navigates to the bottom navigation bar.
- She swipes until she hears: "Challenges Tab, 3 of 4." She double-taps to select it.
- The screen reader announces the new screen title: "Challenges. Heading level 1."
-
Logical Content Order: As Elif swipes through the challenges list, the screen reader reads out each challenge card in a logical sequence.
- "Challenge: Plastic-Free July. Created by Admin. 150 participants. Button."
- "Challenge: Cycle to Work Week. Created by Ben. 32 participants. Button."
- The heading structure and tab order are predictable and easy to follow.
-
Performing an Action: Elif decides to log her waste first. She navigates back to the "Home Tab, 1 of 4" and activates the "Log today's waste" button.
- On the logging screen, the screen reader clearly announces each option: "Paper. Button." "Glass. Button."
- She activates the "Glass" button. The screen reader announces the input field: "Enter weight in kilograms. Text field."
- After she enters the weight and confirms, a success message appears. The screen reader immediately announces: "Log saved. Your streak is now 5 days." This confirms her action was successful without her needing to visually search the screen.
Success criteria:
- All interactive elements (buttons, fields, tabs) have clear, descriptive labels for screen readers.
- The focus order is logical and follows the visual layout of the screen.
- The screen reader correctly announces screen titles and headings upon navigation.
- Dynamic changes and confirmation messages (like "Log saved") are announced accessibly.
Inclusive UX notes:
- Ensures the app is fully usable for screen reader users, meeting WCAG 2.1 AA criteria.
- Consistent and predictable navigation structure is critical for non-visual navigation.
- Clear route names and labels prevent confusion and create a seamless experience.
- State the core problem we're solving.
- Explain the objective of the MVP.
- Highlight the main user value in one sentence.
- Briefly outline what the audience will see in the demo.
- Walk through the UI using the prepared demo case.
- Showcase the primary user flow:
- Entering required inputs
- Triggering the main action or process
- Displaying results and interactions
- Highlight any UX considerations or design decisions.
- Continue the demonstration from mobile viewpoint.
- Present the remaining user pathways or alternate views.
- Show additional functionality .
- Emphasize consistency, responsiveness, or component reuse.
- Open the floor for questions from the audience.
- Each presenter addresses questions related to their part.
- Summarize key takeaways before closing.
This document provides a comprehensive assessment of the current status of software requirements compliance for Customer Milestone 2. The assessment includes workload estimates for both mobile and web platforms to complete pending requirements.
There are still accessibility related W3C Standards that needs to be implemented e.g. internationalization. The corresponding issues have been opened and waiting for further implementation.
Following from the W3C standards that will be implemented, some UX design changes will be made, e.g. Dark mode. The corresponding issues have been opened and waiting for further implementation.
Unit tests are comprehensive for Backend, Frontend and Mobile. These tests can still be expanded, improving the coverage. Integration, E2E (User Workflows), CI/CD Integration with Github Actions or Jenkins need to be implemented.
Mobile Dockerfile and .env.example files need some work, which is mandatory for Milestone 2. Similarly for web application docker-compose.yml and .env needs to be reviewed prior to the Demo.
| Platform | Critical Tasks | Estimated Time |
|---|---|---|
| Mobile | Dockerfile, .env.example, 80% test coverage, CI/CD | 3-4 days |
| Web | .env.example, 80% test coverage expansion, CI/CD | 4-5 days |
| Backend | Test coverage expansion, CI/CD setup | 2-3 days |
| Total | All platforms (can be parallelized) | 4-5 days (with team collaboration) |
Goal: Complete requirements for Milestone 2 submission
- Create Dockerfile (1 day)
- Increase test coverage to 80%+ (1-2 days)
- Complete .env.example (0.5 days)
- Test Docker build locally (0.5 days)
- Document mobile setup in README (1 day)
- Accessibility improvements (2 days)
- Expand test coverage (2-3 days)
- Add tests for pages without coverage
- Integration tests for critical workflows
- Set up coverage reporting with Jest/Vitest
- Complete .env.example (0.5 days)
- Update web setup documentation (1 day)
- Accessibility improvements (2 days)
- Lab1
- Lab2
- Lab3
- Lab4
- Lab5
- Lab6
- Lab7
- Lab8
- Lab9
- Weekly Reports
- Lab Meeting Notes
- Customer Feedback Meeting Notes
- LAB 5: MVP Implementation & Planning
- Lab 7: Milestone 2 Demo Preparation
- Lab 8: Requirements Review & Acceptance Planning
- Lab 9: Milestone 3 Demo Preparation