Welcome to your coding adventure! You’ll experience how software developers build real apps—scrum, MVPs, and all—while having fun with flashcards. You’ll need a sponsors (a teacher) to try out your game and give feedback. We work in three sprints (1 week each). You can code solo or with a buddy! 🤖✨

Prerequisites: Basic familiarity with Scratch—knowing how to create sprites, lists, variables, and use broadcast messages and event handlers.

Checkout also: https://en.wikipedia.org/wiki/List_of_flashcard_software

1. Teacher Admin: “I want to add word pairs by week using a simple input interface before students play, then lock access so no further edits are possible during gameplay.” 🔒
2. Student Player: “I want to pick a week and practice the flashcards to learn English!” 🌟
3. Student Player: “I want to hear both English and Swedish pronunciations of each word to improve speaking and listening skills.” 🔊

These stories form our scope and define the features (MVP—Minimum Viable Product).

Note: Scratch does not support simultaneous multi-user editing in one project.

You can complete this project in three weeks, spending a few hours each week. After each week’s work, your sponsor (teacher or mentor) will test your game to make sure everything works and give you feedback.

At the end of each week, a quick demo to your sponsor helps catch issues early and makes your game stronger!

flowchart TD
  Sponsor["👩‍🏫 Sponsor/Teacher"] --> ScratchApp["🖥️ Scratch App"]
  ScratchApp --> DataStore["📦 Data Store\n(lists + vars)"]
  ScratchApp --> Control["⚙️ Control Logic\n(Load, Flip)"]
  ScratchApp --> UI["🎨 UI Modules\n(Week, Card, Next)"]
  Students["👩‍🎓 Students"] --> ScratchApp

• Data Store: Maintains all lists and variables.
• Control Logic: Implements user stories via broadcast messages and handlers.
• UI Sprites: Separate sprites handle user input (buttons) and output (card display, audio).

Define the core data structures that represent the application’s state:

A well-defined data model serves as a blueprint; changing variable names or list structures mid-project can introduce errors across all scripts.

Hint (KISS & DRY): Keep names clear (no E1/S1) so you don’t confuse lists. DRY = Don’t Repeat Yourself; reuse variables instead of new ones for each week.

Assigning each user story to a distinct module increases separation of concerns, simplifying debugging and future enhancements.

1. Set up Data (like defining your DB tables):
   • Create lists: EnglishWeek1…EnglishWeekN, SwedishWeek1…SwedishWeekN
   • Create variables: CurrentWeek, CardIndex, FrontSide, BackSide, IsLocked
2. Admin Mode:
   • In Admin sprite: on green-flag → set IsLocked to 0.
   • If IsLocked=0, ask [Week?], ask [English?], ask [Swedish?], add answers to correct lists.
3. Lock Admin:
   • Teacher clicks a custom button or script to set IsLocked to 1.
4. Week Buttons:
   • Each WeekX button: on click → set CurrentWeek to X → broadcast LoadCard.
5. Card Sprite:
   • On LoadCard:
     • set CardIndex to pick random 1 to length of EnglishWeek(CurrentWeek)
     • set FrontSide to item CardIndex of EnglishWeek(CurrentWeek)
     • set BackSide to item CardIndex of SwedishWeek(CurrentWeek)
     • say FrontSide
   • On click:
     • play sound [FrontSide_EN]; say BackSide; play sound [BackSide_SE]
6. Next Button:
   • On click → broadcast LoadCard
7. Test & Iterate:
   • Run each module (Admin, Load, Flip) separately; fix bugs; refine UI positions.

Due to the way Scratch is built, projects are owned by individual user accounts, and there is no built-in feature for collaborative editing or role-based access control. This means that managing roles such as “teacher” (admin) and “student” requires a structured workflow.

• Student Developer: Holds the Scratch account that owns the project. Responsible for implementing features, updating content, and managing the project’s development.
• Teacher (Admin): Acts as the end-user who provides weekly word lists and feedback. While the teacher does not directly edit the project, they play a crucial role in guiding its content and functionality.

1. Teacher
   • Provides Word Lists: Each week, the teacher compiles a list of new vocabulary words to be added to the flashcard game.
2. Student Developer Updates the Project:
   • Accesses the project using their Scratch account.
     • Utilizes the Admin UI within the project to input the new word pairs.
     • Ensures that the IsLocked variable is set to 0 to allow editing.

Locking the Admin Interface

• After updating, the student sets IsLocked to 1 to prevent further edits during gameplay. This ensures that students using the flashcard game cannot modify the content.
• Teacher Reviews the Updates:
• The teacher plays the updated game to verify that the new words have been correctly added.
  • Provides feedback to the student developer for any necessary adjustments.

• Scratch & Community: Check Scratch’s built-in docs (Help → About Blocks) or the Scratch Wiki.
• YouTube & Google: Search "Scratch flashcard tutorial" or "Scratch get random item" for example projects.
• Rubber Duck Debugging: Explain your script to a buddy or even a stuffed toy! Bugs often vanish when you talk through them.
• Refactor Early: If your code feels messy, pause and reorganize sprites or variable names—clean code is happy code!
• Separation of Concerns: Keep data-loading logic separate from UI logic. Changes in one module should not break another.
• Consistent Naming: Use descriptive names (e.g., EnglishWeek1 rather than EW1) to avoid confusion when referencing lists in scripts.
• Modularity: Encapsulate each feature (admin, week select, card display) in its own sprite to support independent testing and future extension.
• Error Handling: Consider adding feedback (e.g., say "No cards available") if a list is empty or IsLocked = true when trying to add cards.

• MVP (Minimum Viable Product): The simplest version of your game that works.
• Sprint: A short, time-boxed development cycle.
• Refactor: Reorganize or clean up code without changing behavior.
• Debug: Find and fix errors (bugs) in your scripts.
• KISS: Keep It Simple Stupid.
• DRY (Don’t Repeat Yourself): Avoid copying code—reuse variables and scripts.
• Modularization: Split your game into small, independent parts (sprites) for easy maintenance.
• User Story: A concise description of functionality from an end-user’s perspective.
• Data Model: The schema or organization of data (lists, variables) in the app.
• Module: A self-contained component (sprite) responsible for a specific feature.
• Broadcast: Scratch’s messaging system to signal between sprites.
• Separation of Concerns: Design principle to divide a program into distinct features that overlap in functionality as little as possible.
• Sprint: A fixed-duration period in agile development for completing a set of tasks.
• Iteration: Repeated cycles of development, testing, and refinement.