Tracking Student Data and Managing Club Communication¶
Summary¶
This chapter covers saving and protecting student data, then tracking student progress with a simple dashboard or spreadsheet. It introduces the communication tools a club relies on -- email, shared calendars, notifications, and feedback forms -- with an emphasis on data privacy and consent. You will be able to set up a basic student-progress tracker and a family communication channel.
Concepts Covered¶
This chapter covers the following 21 concepts from the learning graph:
| Concept | Concept Impact Score |
|---|---|
| Saving Student Data | 1016 |
| Student Data Privacy | 196 |
| Tracking Student Progress | 195 |
| Progress Dashboard | 194 |
| Simple Spreadsheet Tracking | 193 |
| Spreadsheet Template Design | 192 |
| Managing Email Communication | 191 |
| Email List Segmentation | 113 |
| Setting Up A Calendar | 112 |
| Shared Calendar Access | 111 |
| Notification System | 110 |
| Email And Chat Tools | 109 |
| Group Messaging App | 108 |
| Forms And Feedback Tools | 107 |
| Survey Tool Selection | 106 |
| Feedback Loop Design | 105 |
| Data Backup Routine | 104 |
| Data Retention Policy | 103 |
| Consent For Data Collection | 102 |
| Anonymized Reporting | 101 |
| Parent Communication Log | 100 |
Prerequisites¶
This chapter builds on concepts from:
- 3. Writing Your Club Charter and Safety Policies
- 11. Choosing a Schedule and Building Registration
- 22. Purchasing and Configuring Club Devices
Chapter 23 got every laptop, printer, and access point onto a network that behaves itself session after session. The moment students start actually using those devices, a second infrastructure question appears: where does everything a student types, builds, or submits actually go, and who else can see it? This chapter answers that question in two halves. The first half covers the sensitive part -- saving, protecting, and eventually deleting student data responsibly. The second half covers the more routine part -- the email, calendar, chat, and feedback tools that keep mentors, students, and families connected between sessions. Both halves share the same guiding instinct: collect and keep the least amount of information a club actually needs, whether that information is a student's saved Python file or a parent's phone number.
The data behind every session
Let's build something great -- every badge a student earns, every spreadsheet row a mentor updates, and every reminder email a family opens all rest on decisions this chapter walks through: what data to save, how to track progress without overcollecting, and which tools keep everyone talking. By the end, you'll be able to set up a privacy-respecting student tracker and a family communication system your club can run for years.
Saving Student Data: Collect the Least You Need¶
Saving Student Data¶
Saving student data is the ongoing decision a club leader makes about which pieces of information -- a name, an email address, a badge earned, a photo, a saved code file -- actually get written down and kept, as opposed to used once in the moment and then discarded. It is the single most consequential decision in this chapter, not because any one piece of data is dangerous by itself, but because every other concept covered below -- privacy, retention, backups, dashboards, even the calendar shared with families -- only exists because some earlier decision already said yes to saving something. Get this first decision right, and everything downstream gets simpler.
Think of student data the way an experienced camp counselor thinks of a first-aid kit packed for an overnight trip. A counselor doesn't throw in everything the drugstore sells -- they pack exactly what a two-day hike is likely to need: a few bandages, sunscreen, one dose of a medication a specific camper actually requires. Anything extra is just weight to carry, one more item that could get lost, and one more thing that must be accounted for when the kit comes home. Student data works the same way: every field a club chooses to record is something it now has to protect, back up, and eventually decide what to do with. A club that collects a home address "just in case" is carrying a bandage roll it will probably never open, but that a lost backpack could still spill onto the trail for anyone to find.
That instinct -- pack only what the trip needs -- is easiest to see side by side against two ways of tracking the exact same Tuesday-night session.
| What's Recorded | Identifiable Roster Spreadsheet | Anonymized Attendance Count |
|---|---|---|
| Student names | Every row | None |
| What it can answer | "Did a specific student attend last week?" | "How many students attended last week?" |
| Data collected per session | One row per student, updated weekly | One number, updated weekly |
| Privacy exposure if lost | High -- a full list of which named children attend which sessions | Low -- a single number with no names attached |
| Good for | Tracking an individual student's progress across weeks | Reporting overall club attendance to a funder or board |
Both are legitimate. A mentor helping a returning student pick up where they left off genuinely needs the roster. A grant report showing "average weekly attendance: 14 students" needs none of that student's name at all -- the anonymized count answers the funder's question completely, at a fraction of the privacy exposure. The mistake worth avoiding is defaulting to the roster for a task the count would have handled just as well.
A worked example makes the underlying decision concrete. A new mentor, eager to be thorough, drafts a sign-up form asking for each student's full name, home address, school, allergies, and a parent's employer. A more experienced co-leader reviews it before it goes out and asks one question of every field: "What does the club actually do with this?" Full name and a parent's email survive the review, because the club uses them to send session reminders and track attendance. Home address and employer don't survive -- the club has never once needed either to run a session -- and allergies get redirected to a separate, physical index card kept with the club's first-aid kit rather than a shared spreadsheet, since that information matters to whoever is supervising snacks that day, not to anyone reviewing enrollment data later. The revised form collects four fields instead of seven, and every one of the four has a specific, nameable use.
Diagram: Do You Actually Need This Data Field?¶
Do You Actually Need This Data Field?
Type: microsim
sim-id: saving-student-data-decision-tool
Library: p5.js
Status: Specified
Template: https://github.com/dmccreary/data-science-course/tree/main/docs/sims/data-selection-playground-microsim
Purpose: Let a club leader test a proposed data field (such as "home address," "email," or "allergy") against a minimal-data-first decision path before deciding whether to collect it at all.
Bloom Taxonomy: Evaluate (L5) Bloom Taxonomy Verb: justify
Learning objective: Given a proposed data field, the learner justifies whether the club should collect it by walking through a minimal-data-first decision path.
Instructional Rationale: An Evaluate-level objective needs the learner to weigh a real field against explicit criteria and reach a justified decision, not watch a pre-scripted animation -- a step-through decision path with the criteria visible at each stage keeps the reasoning, not the visuals, in front of the learner.
Canvas layout: - Left (450px): the current field name plus two stacked decision questions, each answered Yes/No - Right (150px): a running verdict panel reading "Collect it," "Don't collect it," or "Collect a safer substitute"
Data Visibility Requirements: Stage 1: Show the field name, typed or chosen from a dropdown of examples (name, email, home address, allergy, birthdate, photo, parent employer) Stage 2: Show Question 1 -- "Does a specific, current club task need this?" -- with Yes/No buttons Stage 3: If Yes, show Question 2 -- "Is there a less identifying version that would still work?" (for example, birth year instead of a full birthdate) Stage 4: If a safer substitute exists, show it as the recommended field instead of the original Final: Show the verdict plus a one-line reason, such as "Don't collect -- no current club task needs a home address"
Interactive controls: - Dropdown: choose an example field, or select "custom" to type one - Button pair per question: "Yes" / "No" - Button: "Try Another Field"
Default parameters: Field = "Home Address"; walking the default through the two questions ends in "Don't collect it -- no current task needs it."
Implementation notes: p5.js canvas with createSelect for the field dropdown and createButton for each Yes/No pair; store the seven example fields and their correct verdicts in a lookup table so the tool gives consistent, correct feedback regardless of the path taken; a text input allows a custom field name, in which case the tool asks both questions without a pre-loaded answer and lets the learner reason it through independently.
Every saved field is something you now have to protect
Notice the real shift in mindset here -- the question is never whether a piece of data could be useful someday, since almost anything could be. The real question is whether a specific task today actually needs it, and a club that asks that every time ends up protecting a much smaller, much safer pile of information.
Protecting the Data You Do Save¶
Once a club has decided which fields actually earn a place in its records, a second set of decisions takes over: how that smaller, leaner pile of data gets protected, whether guardians agreed to it being collected in the first place, how long it's kept, and how a club can still report meaningful numbers to a funder or board without exposing any of it.
Student Data Privacy¶
Student data privacy is the set of practices a club follows to limit who can see, copy, or misuse the student data it has decided to save -- covering everything from who has the login to the tracking spreadsheet, to whether that spreadsheet ever gets shared with a public link by accident. Where saving student data decides what to collect, student data privacy decides what happens to it after collection, and it applies to every field a club kept, no matter how minimal that list already is.
A short list of practices covers most of what a small club needs:
- Limit spreadsheet or system access to the mentors and leaders who actually need it, not the entire volunteer roster
- Never share a link to a student tracking sheet set to "anyone with the link can edit"
- Store data in the club's own accounts, not a personal email or personal cloud drive that leaves with a departing mentor
- Ask before posting any student's name, photo, or work publicly, even in a celebratory newsletter
A worked example shows a near-miss caught in time: a mentor exporting a spreadsheet to share badge progress with a co-leader accidentally sets the sharing link to "anyone on the internet with this link" instead of "specific people." Because the club's data privacy habit includes a quick permissions check before sending any link, the mentor catches the setting before sending it, switches it to the two co-leaders by name, and the export never becomes publicly searchable.
Because a school-affiliated coding club in the United States can fall under student-data-privacy expectations depending on its venue and exactly what it collects -- rules that vary by state, by whether the club operates on school property, and by whether it partners directly with a school -- this book does not attempt to give a definitive legal answer for every situation. If your club operates inside a school district, a library system, or any organization with its own data-privacy office, ask that office what applies to you before finalizing your data practices; this section covers practical habits, not a legal determination.
This can sound like legal territory -- it mostly isn't
If terms like data retention or student data privacy sound like something only a lawyer should touch, that reaction is completely normal for a volunteer-run club. Most of what this section describes is a habit, not a legal filing, and if your club sits inside a school, library, or other organization with its own privacy office, they are the right people to confirm exactly what applies to you.
Diagram: Student Data Privacy Principles¶
Student Data Privacy Principles
Type: diagram
sim-id: student-data-privacy-principles
Library: Mermaid
Status: Specified
Template: https://github.com/dmccreary/information-systems/tree/main/docs/sims/privacy-regulatory-landscape
Purpose: Show the four privacy practices feeding into one protected outcome, so a mentor can click any practice and see the specific risk it closes.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: explain
Learning objective: Given one of the four student data privacy practices, the learner explains the specific risk that practice reduces.
Steps (hub-and-spoke diagram): 1. Center node: "Protected Student Data" -- click reveals "The smaller, already-reviewed pile of data a club decided to save, now handled so only the right people can see it." 2. Spoke: "Limit Access" -- click reveals "Only mentors and leaders who need the data get a login, not the entire volunteer roster." 3. Spoke: "No Public Links" -- click reveals "A sharing link set to 'anyone with the link' can spread far beyond the two or three people it was meant for." 4. Spoke: "Use Club Accounts" -- click reveals "Data stored in a personal account leaves the club the moment that mentor does." 5. Spoke: "Ask Before Posting" -- click reveals "A name or photo posted publicly without asking undoes every other privacy practice in one step."
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: Blue for the central "Protected Student Data" node; four distinct accent colors for the surrounding practice nodes.
Implementation: Mermaid flowchart (graph TD with the center node linked to each spoke) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node, opening a side-panel infobox.
Consent For Data Collection¶
Consent for data collection is a guardian's informed, advance agreement to a club collecting and using specific pieces of their child's data, obtained before that data is collected rather than disclosed afterward as a policy buried in fine print. For minors, this is not optional politeness -- it is the practical foundation everything else in this chapter sits on, since a club that skips it has no standing to call its data handling responsible, no matter how careful its backup routine or retention policy might be.
A worked example shows consent working as intended: before a club's first session, every family receives a one-page form listing exactly what the club collects (student name, one contact email, badge and progress records) and exactly what it does not (home address, photos posted without separate permission, or any data shared with a third party). A parent signs and returns the form before their child's first session, and the club keeps the signed copy on file for as long as the corresponding data is retained.
Consent is also not a one-time event for a student who stays with the club across multiple years. A club that adds a new kind of tracking -- say, a photo-sharing badge gallery introduced two years into a student's membership -- needs a fresh, specific consent for that new use, since the original form never mentioned it. Re-confirming consent whenever what's collected genuinely changes keeps the agreement honest, rather than stretching an old signature to cover something a guardian never actually saw.
Never collect first and ask permission later
Watch out for this common trap: it is tempting to start a sign-up sheet on the night of your first meeting and sort out the paperwork later. The fix is simple and non-negotiable -- always get written guardian consent before collecting anything from a minor, and delete any data you no longer have a current use for.
Diagram: Guardian Consent Collection Workflow¶
Guardian Consent Collection Workflow
Type: workflow
sim-id: consent-collection-workflow
Library: Mermaid
Status: Specified
Template: https://github.com/dmccreary/health-education/tree/main/docs/sims/consent-requirements-explorer
Purpose: Trace the sequence from drafting a data-collection notice through filing a signed consent form, so a mentor can see exactly where "collection begins" sits relative to "consent obtained."
Bloom Taxonomy: Analyze (L4) Bloom Taxonomy Verb: sequence
Learning objective: Given the steps of a club's consent process, the learner sequences them correctly and identifies which step must precede any data collection.
Steps (flowchart with a decision diamond): 1. Start: "Draft Data-Collection Notice" -- click reveals "Lists exactly what will be collected and exactly what will not, in plain language." 2. Process: "Guardian Reviews Notice" -- click reveals "Sent before the student's first session, giving the family time to ask questions." 3. Decision: "Guardian Signs?" -- click reveals "A club may only collect data for a student whose guardian has signed; declining is always an option." 4a. Branch "Yes" leads to "Data Collection Begins" -- click reveals "Only the fields listed in the notice are collected, starting from this point forward." 4b. Branch "No" leads to "No Data Collected" -- click reveals "The student may still participate in sessions; the club simply keeps no data-collection-dependent records for them." 5. Both branches converge on End: "Signed or Declined Form Filed" -- click reveals "The form itself is kept on file for as long as the data it covers is retained, per the club's retention policy."
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: Gray for the start and process nodes, purple for the decision diamond, green for the "Yes" branch, amber for the "No" branch, gray for the converged end state.
Implementation: Mermaid flowchart (graph TD) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node, opening a side-panel infobox.
Data Retention Policy¶
A data retention policy is a club's written rule for how long each type of saved student data stays on file before it is deleted, stated as a specific duration -- such as "attendance records: two years after a student leaves the club" -- rather than an open-ended "we'll keep it as long as we might need it." Without a stated retention period, data has a way of accumulating forever, quietly growing the privacy exposure described above with no decision ever having been made to allow it.
A worked example shows the policy doing its job at a specific moment: a family that left the club four years ago asks what happened to their child's records. Because the club's retention policy states that individual student records are deleted eighteen months after a student stops attending, the leader can answer honestly that the records were deleted on schedule, rather than searching through an old spreadsheet no one ever decided to prune.
Because a retention policy only works if the mentor who eventually has to act on it can find it, a club should write the policy down in the same charter or handbook that already holds its other operating rules, rather than leaving it as something only the founding leader remembers. A policy that lives in one person's head disappears the day that person steps away from the club -- exactly the single-leader dependency this book has warned against from its opening pages.
Diagram: Data Retention Schedule by Type¶
Data Retention Schedule by Type
Type: infographic
sim-id: data-retention-schedule
Library: Interactive Infographic Overlay (grid-diagram.js, annotation-free poster + rectangular hover zones)
Status: Specified
Purpose: Let a mentor see how long each type of club data is kept and what triggers its deletion, so a retention question can be answered by glancing at one poster instead of hunting through a written policy document.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: classify
Learning objective: Given a type of club data, the learner classifies how long it is retained and what event starts the deletion clock.
Image style: Flat stacked-band poster, four full-width horizontal bands from bottom to top, each with a bold printed band label baked into the image since grid overlays hide chip labels by default
Image dimensions: 1000x700 (portrait, to accommodate four stacked bands)
Zones (4 horizontal bands, each with id, label, color, approximate x1/y1/x2/y2 percentage boundaries, one-line summary, and 3 bullet facts), ordered bottom to top from longest-kept to shortest-kept:
consent-forms-- color #4A90D9 -- boundaries approximately x1:3,y1:76,x2:97,y2:96 -- Summary: "Kept as long as the data they cover is retained." Facts: signed or declined guardian consent forms; retained alongside whatever data they authorize; deleted only when the covered data is deletedprogress-records-- color #50C878 -- boundaries approximately x1:3,y1:52,x2:97,y2:74 -- Summary: "Retained eighteen months after a student leaves." Facts: badge, attendance, and skill-tracking records; clock starts the day a student stops attending; deleted automatically once the window passescontact-information-- color #F5A623 -- boundaries approximately x1:3,y1:28,x2:97,y2:50 -- Summary: "Retained only while a family is actively enrolled." Facts: name and one contact email; removed promptly once a family is no longer active; never kept "just in case" of future re-enrollmentsurvey-responses-- color #9B6BC7 -- boundaries approximately x1:3,y1:4,x2:97,y2:26 -- Summary: "Kept in anonymized form only, indefinitely." Facts: individual free-text responses are summarized and the originals discarded within 90 days; anonymized summaries may be kept for year-over-year comparison; no names are ever attached to a retained summary
showLabels: false (band titles are printed in the generated image)
Interactive features: Click or hover any band to highlight its hover zone and reveal its full fact list, including the specific event that starts its deletion clock, in a detail panel; explore mode only.
Implementation: Interactive Infographic Overlay Guide (grid engine) -- grid-diagram.js + grid-overlay.css render the four rectangular hover zones over the generated poster image; data.json holds the 4 zones per the overlay-grid-data-json-schema.
Data Backup Routine¶
A data backup routine is a scheduled, repeated copy of a club's saved student data -- the tracking spreadsheet, signed consent forms, feedback responses -- stored somewhere separate from wherever the original lives day to day, so a single lost laptop, a deleted file, or a canceled account doesn't erase months of records in one stroke. A backup routine only protects the leaner, already-reviewed pile of data described earlier in this chapter; it is not a reason to collect more, just a way to keep what's already been decided worth keeping.
A worked example shows the routine catching exactly the failure it exists to prevent: a club's laptop used for attendance tracking is accidentally left on a bus after a session. Because the tracking spreadsheet lives in a cloud-based account with automatic version history, rather than only as a local file on that one laptop, the club loses nothing but the laptop itself -- a hardware problem, not a records problem.
A backup you've never tested is just a hope
Here's a shortcut: don't just schedule backups and assume they work -- actually restore one file from the backup once a semester to confirm it is not silently broken. A backup no one has ever tested is really just an unverified hope.
Diagram: Data Backup Routine Timeline¶
Data Backup Routine Timeline
Type: timeline
sim-id: data-backup-routine-timeline
Library: vis-timeline
Status: Specified
Purpose: Show a recommended backup and restore-verification cadence across a semester, so a club leader can see when backups happen and when they should actually be tested.
Bloom Taxonomy: Apply (L3) Bloom Taxonomy Verb: schedule
Learning objective: Given a semester calendar, the learner schedules backup and restore-verification checkpoints at appropriate intervals.
Time period: One 16-week semester
Orientation: Horizontal
Events: - Week 1: "Confirm Cloud Sync Is Active" -- automatic backup enabled on the tracking spreadsheet and consent-form folder - Week 4: "Automatic Backup Running" -- ongoing, no action needed - Week 8: "Mid-Semester Restore Test" -- restore one file from backup to confirm it isn't silently broken - Week 12: "Automatic Backup Running" -- ongoing, no action needed - Week 16: "End-of-Semester Restore Test and Archive" -- verify backups again and archive the semester's records per the retention policy
Visual style: Horizontal timeline with alternating above/below event placement
Color coding: Blue for ongoing automatic backup events, amber for the two manual restore-test checkpoints
Interactive features: - Click any event to see what it involves and roughly how long it takes - Hover to preview the event title before clicking
Implementation: vis-timeline library rendered in main.html with a select event handler opening a detail panel for the clicked item.
Anonymized Reporting¶
Anonymized reporting is the practice of summarizing club data as aggregate counts or trends -- total attendance, number of badges earned, average session rating -- with every individual name stripped out before the summary ever leaves the club's own records, exactly the technique the compare-and-contrast table earlier in this chapter set up when it weighed a roster against an attendance count. Most of the audiences a club reports to, such as a funder, a school administrator, or a board of directors, only ever need the aggregate number, never the underlying names.
A worked example shows the substitution in practice: a club leader preparing a grant renewal needs to show consistent attendance over the past semester. Rather than exporting the full roster spreadsheet with every student's name and weekly attendance mark, the leader instead exports a single anonymized chart of total attendance per week, with no names attached, which answers the funder's actual question just as completely, without a single identifiable record ever leaving the club's system.
Diagram: Anonymized Attendance Chart¶
Anonymized Attendance Chart
Type: chart
sim-id: anonymized-attendance-chart
Library: Chart.js
Status: Specified
Chart type: Bar chart
Purpose: Show how weekly attendance can be reported as a fully aggregate number, with hover detail but no names anywhere in the underlying data.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: interpret
Learning objective: Given an anonymized attendance chart, the learner interprets the weekly trend without any access to individually identifiable data.
X-axis: Week number (1 through 16) Y-axis: Number of students present (count only)
Data series: 1. Current Semester (blue bars): sample values ranging 10-16 students per week across 16 weeks, with a visible dip around week 9 (a school break week) and a recovery afterward 2. Prior Semester (light gray bars, toggle to show/hide): a comparable sample series for year-over-year comparison
Title: "Weekly Attendance -- Aggregate Count Only" Legend: Position top-right, includes a toggle for the "Prior Semester" series
Interactive features: - Hover any bar to see the exact count and week number in a tooltip - Click the legend entry to toggle the "Prior Semester" series on or off - No drill-down to individual students is possible from this chart, by design
Annotation: A caption below the chart reading "This chart contains no student names -- only weekly totals."
Implementation: Chart.js bar chart with two datasets and legend-click toggling enabled.
Tracking Progress Without Overcollecting¶
Attendance and consent records answer who is here and whether the club has permission to keep their data. A club also wants to know whether a specific student is actually progressing through its curriculum, which calls for a narrower, more purpose-built kind of tracking.
Tracking Student Progress¶
Tracking student progress is the ongoing practice of recording which skills, badges, or challenge cards a specific student has completed, updated regularly enough that a mentor picking up with a returning student can see where that student left off rather than starting the conversation from scratch. It is the minimal-data version of a much heavier idea -- a full academic transcript -- scaled down to exactly what a volunteer-run club needs: a short, current picture of what a student has already mastered.
A worked example shows the payoff for a substitute mentor: a regular mentor is out sick, and a substitute steps in for a student they have never met. Glancing at that student's row in the tracking sheet -- completed: Scratch basics, blinking-light kit; in progress: LED strip patterns -- the substitute picks up exactly where the previous mentor left off, instead of guessing at the student's skill level from scratch.
Diagram: Student Progress Tracking Cycle¶
Student Progress Tracking Cycle
Type: workflow
sim-id: progress-tracking-cycle
Library: Mermaid
Status: Specified
Template: https://github.com/dmccreary/reading-for-kindergarten/tree/main/docs/sims/reading-progress-path
Purpose: Show the repeating cycle a mentor follows to keep a student's tracked progress current, so the practice reads as an ongoing habit rather than a one-time form to fill out.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: explain
Learning objective: The learner explains what happens at each stage of the ongoing progress-tracking cycle.
Steps (circular flowchart): 1. "Observe" -- click reveals "A mentor watches a student work through a challenge card or kit during a session." 2. "Record" -- click reveals "The mentor marks the completed skill or badge in the tracking sheet before the session ends." 3. "Review" -- click reveals "Before the next session, a mentor -- often a different one -- reviews the student's row to see what's already mastered." 4. "Adjust" -- click reveals "The mentor picks the next appropriate challenge card based on what the record shows, then the cycle repeats at 'Observe.'"
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: Four evenly spaced colors around the cycle, with an arrow from "Adjust" back to "Observe" to make the repeating nature visible.
Implementation: Mermaid flowchart (graph LR arranged to suggest a loop, with an explicit arrow from the last node back to the first) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node.
Progress Dashboard¶
A progress dashboard is a single at-a-glance view -- a small set of charts or summary numbers -- that turns a full tracking spreadsheet's rows and columns into a picture a mentor or club leader can read in seconds: how many students have completed each badge, which challenge cards are proving hardest, how attendance trends over the semester. Where the underlying spreadsheet is built for entering and looking up one student's data at a time, a dashboard is built for seeing the whole club at once.
A worked example shows the difference in practice: at the end of a session, a club leader wants to know whether the LED-strip-patterns badge is turning into a bottleneck before planning next week. Scrolling through forty rows of a spreadsheet to count how many students have that badge checked off would take several minutes; a dashboard's badge-completion chart shows the same answer -- six of fourteen students -- in a single glance, because the dashboard already did that counting automatically.
Diagram: Progress Dashboard Explorer¶
Progress Dashboard Explorer
Type: microsim
sim-id: progress-dashboard-explorer
Library: Chart.js
Status: Specified
Template: https://github.com/dmccreary/infographics/tree/main/docs/sims/dashboard-builder
Purpose: Let a mentor explore a filterable dashboard summarizing badge completion across a mock cohort, using only initials rather than full names, to model both the tool and the minimal-identifiability habit from earlier in this chapter.
Bloom Taxonomy: Analyze (L4) Bloom Taxonomy Verb: examine
Learning objective: Given filter controls, the learner examines a dashboard to identify which badge is currently the biggest bottleneck for a cohort.
Canvas layout: - Left (500px): a bar chart of badge-completion counts across the sample cohort - Right (150px): filter controls and a summary readout
Interactive controls: - Dropdown: filter by cohort (Tuesday Group, Thursday Group, All) - Dropdown: sort bars by completion count (highest first, lowest first) - Button: "Reset Filters"
Data Visibility Requirements: Stage 1: Show the unfiltered bar chart -- one bar per badge, height equal to number of students (identified only by initials in the underlying mock data) who earned it Stage 2: Show the same chart re-rendered after choosing a cohort filter, with bar heights updated to that cohort's numbers only Final: Clicking a bar shows a small list of the initials that have earned that badge, modeling how a real dashboard would summarize without ever displaying a full name
Default parameters: Cohort = "All"; sample data includes 6 badges across a mock cohort of 14 students, with one badge intentionally set low (6 of 14) to illustrate a visible bottleneck
Implementation notes: Chart.js bar chart rebuilt on every filter change from a small in-memory mock dataset; initials only, never full names, even in sample data, to reinforce the chapter's minimal-identifiability principle.
Simple Spreadsheet Tracking¶
Simple spreadsheet tracking is the practice of keeping the raw progress data described above in an ordinary spreadsheet -- one row per student, one column per badge or skill -- rather than a purpose-built student information system, because a spreadsheet is free, familiar to any volunteer, and entirely sufficient for the record-keeping scale of a single club. A later chapter on analyzing club data revisits when a club has genuinely outgrown a spreadsheet; for the vast majority of clubs this book serves, it never does.
A worked example shows a minimal, working layout in practice: a club with fourteen regular students keeps one spreadsheet tab with a row per student and columns for name, join date, and one column per badge, marked with the date each badge was earned. Updating it takes a mentor about thirty seconds per student at the end of a session -- far less overhead than any dedicated tracking software would demand for a club this size.
The sample below uses initials rather than full names, the same minimal-identifiability habit introduced earlier in this chapter, even for an internal working sheet.
| Student | Join Date | Scratch Basics | Blinking Light | LED Strip Patterns |
|---|---|---|---|---|
| A.K. | 2026-01-10 | 2026-01-24 | 2026-02-07 | -- |
| J.R. | 2026-01-10 | 2026-01-24 | 2026-02-07 | 2026-02-21 |
| M.T. | 2026-01-17 | 2026-01-31 | -- | -- |
Spreadsheet Template Design¶
Spreadsheet template design is the up-front decision about which columns a tracking spreadsheet will have and how they're organized -- a header row, one block of columns per badge category, a final notes column -- designed once before student data starts flowing in, rather than added piecemeal as a mentor thinks of something new to track mid-semester. A well-designed template keeps a spreadsheet legible even after a year of weekly updates from several different mentors; a template that grew ad hoc usually doesn't.
A worked example shows a template design decision paying off months later: a club that designs its template with a fixed block of identity columns, a separate fixed block of badge columns, and a separate attendance block can hand the same spreadsheet to a new mentor in year two without a walkthrough, since the column headers alone explain the layout. A club that instead added new columns wherever there was room, in whatever order a mentor typed them, ends up with a spreadsheet only the original mentor can navigate confidently.
Diagram: Spreadsheet Template Zones¶
Spreadsheet Template Zones
Type: infographic
sim-id: spreadsheet-template-zones
Library: Interactive Infographic Overlay (grid-diagram.js, annotation-free poster + rectangular hover zones)
Status: Specified
Purpose: Show the three functional zones of a well-designed tracking spreadsheet template, so a new mentor can recognize why the columns are grouped the way they are.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: classify
Learning objective: Given a column from a tracking spreadsheet, the learner classifies which template zone it belongs to and why.
Image style: Flat mock-spreadsheet poster showing a header row and a few sample rows, with three vertical column-block zones outlined
Image dimensions: 1000x500 (landscape, to resemble an actual spreadsheet)
Zones (3 vertical column blocks, each with id, label, color, approximate x1/y1/x2/y2 percentage boundaries, one-line summary, and 3 bullet facts):
identity-columns-- color #4A90D9 -- boundaries approximately x1:3,y1:5,x2:30,y2:95 -- Summary: "Who the row is about." Facts: name (or initials) and join date; never reordered once set; the only columns a substitute mentor needs to find a specific studentbadge-columns-- color #50C878 -- boundaries approximately x1:32,y1:5,x2:75,y2:95 -- Summary: "What has been mastered, and when." Facts: one column per badge or skill, in the order they're typically earned; each cell holds a completion date, not just a checkmark; grouped together so progress is scannable left to rightnotes-column-- color #F5A623 -- boundaries approximately x1:77,y1:5,x2:97,y2:95 -- Summary: "Anything that doesn't fit a fixed column." Facts: free-text field for context a mentor wants the next mentor to see; kept to short, factual notes, not a substitute for the parent communication log; always the rightmost column so it never disrupts the badge block
showLabels: false (zone titles are printed in the generated image)
Interactive features: Click or hover any zone to highlight it and reveal its full fact list in a detail panel; explore mode only.
Implementation: Interactive Infographic Overlay Guide (grid engine) -- grid-diagram.js + grid-overlay.css render the three rectangular hover zones over the generated poster image; data.json holds the 3 zones per the overlay-grid-data-json-schema.
Running Club Email and Calendars¶
Progress data tells a mentor where a student stands. Getting that same family to show up to the next session, or to hear about a schedule change, depends on an entirely different set of tools: the email, calendar, and notification systems covered next.
Managing Email Communication¶
Managing email communication is the practice of sending and organizing the club's outgoing messages -- session reminders, schedule changes, newsletters -- from an account and process the whole club can rely on, rather than from whichever individual mentor's personal inbox happens to have everyone's address saved. A club's email approach usually falls into one of three tiers, each trading setup effort for capability.
| Approach | Setup Effort | Capacity | Best For |
|---|---|---|---|
| Personal email, BCC list | None | A few dozen addresses before BCC gets unwieldy | A brand-new club's first few sessions |
| Free dedicated club email account | Low -- one account, shared login | Comfortable for most small clubs | Most established clubs |
| Email marketing or newsletter service | Moderate -- account setup, list import | Built for hundreds of recipients with delivery tracking | Clubs sending regular newsletters or using segmentation |
A worked example shows the first transition point: a club starts by BCC-ing thirty families from a mentor's personal email. By the second semester, that mentor has moved on and taken the family list with them by accident, since it only ever lived in one person's personal inbox. The club's next leader sets up a dedicated club email account instead, moves the family list into it, and the list now survives any single mentor coming or going -- the same continuity principle that runs through this entire book.
The BCC approach has a second, quieter failure mode worth watching for even before a club outgrows it: a family that replies "reply all" by mistake exposes every other recipient's address to everyone else on the list, since BCC only hides addresses on the way out, not on the way back. A dedicated club account sidesteps this by letting the sender reply from an address families already expect to hear from, rather than a personal inbox address families were never meant to see in the first place.
Email List Segmentation¶
Email list segmentation is dividing a club's full contact list into smaller, purpose-specific groups -- active families, waitlisted families, mentors, alumni -- so a message only reaches the people it's actually relevant to, instead of every message going to everyone regardless of whether it applies to them. Segmentation matters because the groups genuinely overlap: a mentor might also be the parent of an active student, and an alumni family might still want event announcements even after their own student has moved on.
A worked example shows the overlap in action: a club needs to announce a mentor-only training session. Sending it to the full list would confuse dozens of families with an irrelevant announcement; sending it only to the mentors segment reaches exactly the people who need it, including the one parent-mentor who belongs to both the active-families and mentors segments at once.
Diagram: Email List Segments¶
Email List Segments
Type: diagram
sim-id: email-list-segments-venn
Library: p5.js
Status: Specified
Purpose: Show how a club's four common email segments overlap, so a mentor can see why one contact might belong to more than one group.
Bloom Taxonomy: Analyze (L4) Bloom Taxonomy Verb: differentiate
Learning objective: Given a sample contact, the learner differentiates which segment or segments that contact belongs to.
Visual style: Four overlapping circles (a Venn-style diagram): Active Families, Mentors, Waitlist, Alumni
Overlaps of interest: - Active Families and Mentors overlap (a parent who also mentors) - Waitlist does not overlap with Active Families (a contact is in exactly one of the two) - Alumni overlaps only slightly with Mentors (a former family member who stayed on as a mentor)
Interactive controls: - Click any region (including an overlap region) to see which segment(s) it represents and a sample message type sent to it - Button: "Highlight Overlaps" -- flashes the two overlapping regions to draw attention to them
Default parameters: All four circles visible at load; no region pre-selected
Implementation notes: p5.js canvas drawing four semi-transparent circles positioned so the two intended overlaps are visible; a lookup table maps each region (including overlaps) to its label and example message, checked against mouse position on click.
Setting Up A Calendar¶
Setting up a calendar is the one-time task of creating the club's shared calendar -- naming it clearly, choosing who can see it, and adding the semester's recurring session dates -- so that "when is the next meeting" has one authoritative answer instead of living only in a mentor's memory or a single old email. An earlier chapter already covered choosing a schedule; this step is where that chosen schedule becomes a calendar object other tools and people can actually reference.
A worked example shows the setup sequence: a club leader creates a new calendar with a clear name rather than leaving it as an unlabeled default, sets its default visibility to view-only for anyone with the link, and adds every session date for the semester as a single recurring weekly event in one pass, rather than adding each week's session one at a time as it approaches. Setting the calendar's time zone correctly during this same pass matters more than it might seem -- a club that skips it can send a technically correct event time that displays an hour off for any family whose device defaults to a different zone, a confusing problem that a five-second setting avoids entirely.
Diagram: Club Calendar Setup Workflow¶
Club Calendar Setup Workflow
Type: workflow
sim-id: calendar-setup-workflow
Library: Mermaid
Status: Specified
Purpose: Sequence the one-time steps of creating a club calendar, ending at the point where shared access -- covered next -- takes over.
Bloom Taxonomy: Apply (L3) Bloom Taxonomy Verb: sequence
Learning objective: The learner sequences the steps required to set up a new shared club calendar correctly the first time.
Steps (flowchart): 1. "Create New Calendar" -- click reveals "A calendar distinct from any mentor's personal calendar." 2. "Name It Clearly" -- click reveals "For example, 'Tuesday Coding Club 2026,' not the default 'Calendar 3.'" 3. "Set Default Visibility" -- click reveals "Typically view-only for anyone with the link, reserving edit access for the lead mentor." 4. "Add Recurring Sessions" -- click reveals "Every session date for the semester added as one recurring weekly event, not one at a time." 5. "Share the Link" -- click reveals "The link goes out to families and mentors, and shared calendar access rules take over from here."
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: A single consistent color for all five steps, since this is a simple linear sequence rather than a branching decision.
Implementation: Mermaid flowchart (graph TD) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node.
Shared Calendar Access¶
Shared calendar access is the set of permission levels a club grants to different people viewing or editing that calendar -- typically view-only for parents and students, and edit access reserved for the small group of mentors who actually schedule events -- so the calendar stays accurate without becoming editable by everyone who can see it.
A worked example shows a permission mismatch causing a real problem, and the fix: a club initially gives every mentor edit access, and one mentor accidentally deletes a recurring session while trying to change its time. The club switches to a model where only the lead mentor holds edit access and everyone else has view-only, and that specific kind of accidental deletion becomes impossible for the other mentors to cause.
| Role | Access Level | Can Do |
|---|---|---|
| Lead Mentor / Club Leader | Edit | Add, move, or cancel events |
| Other Mentors | View only (or edit, for a small trusted team) | See upcoming sessions; request changes through the lead mentor |
| Parents and Students | View only | See upcoming sessions; cannot change anything |
Notification System¶
A notification system is the scheduled sequence of reminders a club sends in the days and weeks before an event, timed so a family hears about an upcoming session with enough advance notice to plan around it, and again close enough to the date that it's still fresh in mind. A single reminder sent only the morning of a session reaches families too late to rearrange a conflicting commitment; reminders sent only weeks in advance get forgotten by the time the date arrives.
A worked example shows a two-touch pattern working well: a club sends one reminder email two weeks before a special weekend event, giving families time to plan around it, and a second, shorter reminder the day before, as a same-day-relevant nudge. Attendance at that event turns out noticeably higher than at a similar event the club had only announced once, three weeks ahead, with no follow-up reminder.
Diagram: Notification Lead-Time Timeline¶
Notification Lead-Time Timeline
Type: timeline
sim-id: notification-lead-time-timeline
Library: vis-timeline
Status: Specified
Purpose: Show a recommended two-touch reminder cadence counting down to an event, so a mentor can see when each reminder should go out and why.
Bloom Taxonomy: Apply (L3) Bloom Taxonomy Verb: schedule
Learning objective: Given an event date, the learner schedules reminder notifications at appropriate lead times before it.
Time period: 14 days before an event through the event itself
Orientation: Horizontal, counting down to a fixed "Event Day" marker
Events: - Day -14: "First Reminder Sent" -- gives families time to plan around the event - Day -1: "Second Reminder Sent" -- a short, same-day-relevant nudge - Day 0: "Event Day"
Visual style: Horizontal countdown timeline with the event day marked distinctly at the right edge
Color coding: Blue for the first reminder, amber for the second reminder, green for event day
Interactive features: - Click either reminder event to see a sample message and the reasoning behind its timing - Hover the event-day marker to see a summary comparing this two-touch pattern's attendance outcome to a single-reminder baseline
Implementation: vis-timeline library rendered in main.html with a select event handler opening a detail panel for the clicked item.
Chat and Group Messaging Tools¶
Email and calendars handle scheduled, planned communication well; they are a poor fit for the kind of quick, time-sensitive message a club sometimes needs to send, such as "session starts in ten minutes and we're running late" -- which is where chat and group messaging tools take over.
Email And Chat Tools¶
Email and chat tools together make up a club's full communication toolkit, and the two channels serve genuinely different needs: email suits anything that benefits from a searchable written record and doesn't need an instant response, such as a schedule change or a consent form, while chat tools suit short, time-sensitive messages where a same-day or same-hour response actually matters.
| Aspect | Chat / Group Messaging | |
|---|---|---|
| Speed | Hours to a day is normal | Minutes |
| Formality | Higher -- suits official announcements, consent forms | Lower -- suits quick logistics |
| Written record | Strong, easily searched later | Weaker -- messages can scroll past unnoticed |
| Best for | Schedule changes, newsletters, consent forms | "Running 10 minutes late," last-minute room changes |
A worked example shows both channels used correctly in the same week: a club sends the semester's full session schedule by email, a document families can refer back to for months, and then uses a group chat the morning of a specific session to say the room changed at the last minute because of a building conflict -- a message no one would have opened in time if it had gone out as an email instead.
One boundary is worth holding firm regardless of how convenient chat feels: anything tied to the consent and privacy practices earlier in this chapter -- a signed permission form, a change to what data the club collects -- belongs in email, where it creates a searchable, dated record, never in a group chat message that could scroll past unread and leave no retrievable trace that consent was ever requested.
Group Messaging App¶
A group messaging app is the specific chat tool a club chooses -- often the same one most families already use for other group coordination -- for the fast, informal messages described above, set up as a single group so a message reaches every current family in one send rather than as separate one-on-one conversations a mentor has to repeat by hand. Choosing an app most families already have installed lowers the barrier to actually using it; asking every family to install something new just for the club often means several never do.
A worked example shows the channel choice actually mattering: a mentor needs to tell families that a session is moving to a different room five minutes before it starts. Posting once to the group messaging app reaches every family checking their phone on the way in; the same message sent by email might not be opened until that evening, well after the session already ended.
Diagram: Message Channel Decision Tree¶
Message Channel Decision Tree
Type: workflow
sim-id: message-channel-decision-tree
Library: Mermaid
Status: Specified
Template: https://github.com/dmccreary/token-efficiency/tree/main/docs/sims/conversation-message-structure
Purpose: Help a mentor decide, for a specific message, whether email or the group messaging app is the right channel.
Bloom Taxonomy: Evaluate (L5) Bloom Taxonomy Verb: determine
Learning objective: Given a message's urgency and audience, the learner determines which communication channel is appropriate.
Steps (decision tree): 1. Start: "New Message to Send" -- click reveals "Any outgoing message a mentor needs to send to families or mentors." 2. Decision: "Needs Action Within the Hour?" -- click reveals "A same-day room change or a running-late notice both count as urgent." 3a. Branch "Yes" leads to "Send via Group Messaging App" -- click reveals "Reaches families checking their phones in real time; not meant to be a permanent record." 3b. Branch "No" leads to Decision: "Needs a Searchable Written Record?" -- click reveals "A schedule change, a newsletter, or anything a family might need to reference weeks later." 4a. Branch "Yes" leads to "Send via Email" -- click reveals "Easily searched later; appropriate for anything semi-official." 4b. Branch "No" leads to "Either Channel Works" -- click reveals "For a low-stakes, non-urgent note, mentor judgment and family preference can decide."
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: Purple for decision diamonds, green for the group-messaging-app outcome, blue for the email outcome, gray for the "either channel" outcome.
Implementation: Mermaid flowchart (graph TD) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node.
Closing the Loop With Feedback¶
Every tool so far pushes information out to families. The last four concepts in this chapter cover the tools that bring information back in -- forms, surveys, and a record of what families actually said -- and close the loop by making sure that feedback leads somewhere.
Forms And Feedback Tools¶
Forms and feedback tools are the online forms a club uses to collect structured input from families and mentors -- a post-event survey, a badge self-assessment, an incident report -- built from a small set of question types, such as multiple choice, short text, and a rating scale, rather than free-form email replies that are harder to compare across dozens of responses.
A worked example shows why structure matters: a club that asks "How was tonight's session?" by email gets thirty different reply formats, some one word, some three paragraphs, that take real time to compare. The same question asked as a 1-5 rating scale plus one optional short-text field produces answers a leader can average and skim in minutes. Keeping the whole form short enough to finish in under two minutes matters just as much as the question types themselves -- a ten-question form left for "whenever there's time" reliably gets fewer completed responses than a three-question form a family can finish while still standing at pickup.
Diagram: Annotated Feedback Form¶
Annotated Feedback Form
Type: infographic
sim-id: feedback-form-annotated
Library: Interactive Infographic Overlay (grid-diagram.js, annotation-free poster + rectangular hover zones)
Status: Specified
Template: https://github.com/dmccreary/search-microsims/tree/main/docs/sims/feedback-loop-sim
Purpose: Show a sample post-event feedback form with three question types, so a mentor can see why each type was chosen and what it measures well.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: explain
Learning objective: Given a question on a feedback form, the learner explains why that question type was chosen over the alternatives.
Image style: Flat mock-form poster showing three stacked questions with their answer widgets
Image dimensions: 1000x600 (portrait, three stacked question zones)
Zones (3 horizontal bands, each with id, label, color, approximate x1/y1/x2/y2 percentage boundaries, one-line summary, and 3 bullet facts):
rating-scale-question-- color #4A90D9 -- boundaries approximately x1:3,y1:70,x2:97,y2:96 -- Summary: "How was tonight's session? (1-5 scale)" Facts: fastest to answer and to average across many responses; best for tracking a trend over time; loses nuance a written comment would capturemultiple-choice-question-- color #50C878 -- boundaries approximately x1:3,y1:38,x2:97,y2:68 -- Summary: "Which activity did you enjoy most? (pick one)" Facts: easy to tally into a simple count per option; best when the possible answers are already known; forces a choice even if a respondent liked two activities equallyshort-text-question-- color #F5A623 -- boundaries approximately x1:3,y1:4,x2:97,y2:36 -- Summary: "Anything else you'd like us to know? (optional)" Facts: captures detail the fixed question types can't anticipate; optional, so it doesn't slow down a respondent in a hurry; harder to summarize across many responses than the scale or multiple-choice questions above
showLabels: false (question labels are printed in the generated image)
Interactive features: Click or hover any question zone to highlight it and reveal its full fact list in a detail panel; explore mode only.
Implementation: Interactive Infographic Overlay Guide (grid engine) -- grid-diagram.js + grid-overlay.css render the three rectangular hover zones over the generated poster image; data.json holds the 3 zones per the overlay-grid-data-json-schema.
Survey Tool Selection¶
Survey tool selection is choosing which specific form-building service a club standardizes on -- a free online form builder, a paid survey platform, or a simple paper form for a low-tech venue -- weighing cost, ease of building a new survey, and whether responses need to stay anonymous.
| Tool | Cost | Ease of Use | Anonymous Responses? | Works Without Internet |
|---|---|---|---|---|
| Free online form builder | Free | Easy, no training needed | Yes, if configured that way | No |
| Paid survey platform | Subscription | Easy, more advanced question types | Yes | No |
| Paper form | Free (printing only) | Simple to fill out; someone must transcribe results | Yes, naturally | Yes |
A worked example shows the paper option earning its place: a club meets in a community center basement with unreliable Wi-Fi. Rather than fight the connection every post-event survey night, the club prints a one-page paper form, collects it at the door, and one mentor transcribes the dozen responses into the free online tool later that evening once the connection is stable -- combining paper's reliability with the online tool's easier long-term analysis.
Whichever tool a club settles on, it is worth a quick look at that tool's own data-handling settings before committing to it -- confirming responses can actually be set to anonymous, and that exported data lands in the club's own account rather than a personal one, applies the same privacy habits from earlier in this chapter to the survey tool itself, not just to the tracking spreadsheet.
Feedback Loop Design¶
Feedback loop design is making sure that feedback a club collects actually leads to a visible action and a response back to the people who gave it, closing a cycle that starts with collecting responses and ends with reporting back what changed, rather than a survey that gets sent, collected, and then never looked at again. A feedback loop with no visible closing step teaches families that their input doesn't matter, which quietly discourages them from bothering to respond to the next survey.
A worked example shows the loop closing visibly: a post-event survey reveals that several families found the session's start time too early for after-school pickup schedules. The club analyzes the responses, decides to shift the start time by fifteen minutes starting the following month, and sends a short follow-up message explaining the change and crediting the survey for prompting it, so the families who responded can see their feedback actually changed something.
Diagram: Feedback Loop Cycle¶
Feedback Loop Cycle
Type: workflow
sim-id: feedback-loop-cycle
Library: Mermaid
Status: Specified
Template: https://github.com/dmccreary/xapi-course/tree/main/docs/sims/instructional-design-feedback-loop
Purpose: Show the four-stage cycle that keeps feedback from disappearing into an unread inbox, using the start-time worked example to make each stage concrete.
Bloom Taxonomy: Understand (L2) Bloom Taxonomy Verb: explain
Learning objective: The learner explains what happens at each stage of a closed feedback loop, and why skipping the last stage undermines the whole cycle.
Steps (circular flowchart): 1. "Collect" -- click reveals "A post-event survey gathers responses, such as families noting the start time is too early." 2. "Analyze" -- click reveals "The club reviews responses for a pattern, such as several families raising the same start-time concern." 3. "Act" -- click reveals "The club makes a real change, such as shifting the start time by fifteen minutes." 4. "Report Back" -- click reveals "A follow-up message tells families what changed and credits the survey, then the cycle repeats at 'Collect.'"
Interactivity requirement (satisfied): every node has a Mermaid click directive tied to an infobox showing its revealed text.
Color coding: Four evenly spaced colors around the cycle, with an arrow from "Report Back" back to "Collect" to make the repeating nature visible.
Implementation: Mermaid flowchart (graph LR arranged to suggest a loop, with an explicit arrow from the last node back to the first) rendered in main.html with click NodeId call showInfo("NodeId") directives for every node.
Parent Communication Log¶
A parent communication log is a written record of individual conversations a club has with specific families -- a phone call about a scheduling conflict, an email exchange about an accommodation request, a note from pickup -- kept so that a conversation had by one mentor is still visible to whichever mentor interacts with that family next, rather than existing only in one person's memory. It differs from the progress-tracking spreadsheet covered earlier in this chapter, which records what a student has learned, by instead recording what a family and the club have discussed.
A worked example shows a log preventing an awkward repeat: a parent already explained by phone, two weeks earlier, that their child has a scheduling conflict on the third Tuesday of every month. A different mentor, unaware of that earlier call, would otherwise ask the family the same question again at pickup -- but a quick glance at the communication log shows the conversation already happened, letting the mentor instead simply confirm the arrangement is still working.
Log it the same day, not at the end of a long night
Want to save yourself an awkward repeat conversation? Log a call or a tricky email exchange the same day it happens, while the details are still fresh, rather than trying to reconstruct it from memory at the end of a long session.
The sample below again uses initials rather than full names, consistent with the minimal-identifiability habit that runs through this chapter.
| Date | Family | Topic | Follow-Up |
|---|---|---|---|
| 2026-02-03 | R. family | Third-Tuesday scheduling conflict | Noted; no action needed monthly |
| 2026-02-10 | K. family | Requested a badge-progress update | Sent current progress summary by email |
| 2026-02-17 | T. family | Asked about the loaner laptop policy | Referred to the device loaner agreement from Chapter 23 |
Chapter Summary¶
This chapter turned two related instincts -- collect less, and communicate more reliably -- into a working system. On the data side, a minimal-data-first habit decides what gets saved at all, privacy practices and guardian consent govern what happens to it afterward, a stated retention policy and a tested backup routine keep it safe and finite, and anonymized reporting lets a club share meaningful numbers without exposing a single name. On the communication side, a simple spreadsheet and dashboard track progress without needing more than a name and a badge date, email and calendars carry planned announcements, chat tools carry same-day logistics, and a closed feedback loop makes sure family input actually changes something instead of disappearing into an unread inbox.
You can now run a club's data and communication with confidence
You just built a complete, privacy-respecting system for saving only the student data your club truly needs, tracking progress simply, and keeping every family in the loop. That's the kind of infrastructure that protects students and keeps families engaged long after any one mentor moves on.