TPPN Syllabus Design Guidelines

What this is: A reference standard for everyone writing a TPPN syllabus. It ensures 3 tracks ×
multiple ability levels produce consistent, usable documents — and that every syllabus doubles as a
reference book for instructors.
What this is not: A lesson plan. You fill in the content; this is the container.

1. Core Philosophy
1.1 Ability Over Age
Students are grouped by demonstrated ability, not birth year. A 14-year-old who's been coding for
2 years does not belong in the same room as a 14-year-old who's never touched a keyboard. The 3
tracks (below) each have ability tiers — instructors assess and place students accordingly.

Tier Label Typical Student

Foundation First contact Never used the tool. Needs
basics, vocabulary, confidence.
Core Can operate independently Has done a few projects. Needs
structure, debugging skill,
syntax depth.
Advanced Ready to build Can research solutions
independently. Needs project
architecture, real constraints,
peer review.

A single cohort may contain Foundation-level students in one track and Core-level in another. The
syllabus must provide clear placement heuristics so instructors can decide without testing anxiety.

1.2 The Three On-Site Tracks

Track What Students Do Tools (locked)
Coding Block-based → text-based Scratch / ScratchJr → Python
programming, logic, (Thonny / Replit)
automation
Art / Design / Graphics Visual content creation, digital Canva, Krita / Photopea, Figma
art, design thinking, media (browser)
literacy
General (MS Office & Document production, Google Docs / Sheets, Slides,
essential digital skills) spreadsheets, email, AI literacy, browser-based AI tools
career prep

Why locked tools: Syllabus writers need to depend on specific software so they can write specific
instructions. If instructors want to swap a tool, they file a change request — they don't improvise
mid-session.
1.3 The Pixel Mechanic (Mandatory — This Is The Brand)
Every syllabus must end with the student creating their own Pixel — a showcase piece that contains
everything they learned:
 Coding Pixel: A working program (game, tool, script) that the student can explain and
demo.
 Art Pixel: A finished visual piece (poster, animation, design system) ready for portfolio.
 General Pixel: A complete document/spreadsheet/presentation bundle solving a real-world
problem.
All graduate Pixels feed into the TPPN Mosaic — a living gallery of student work that grows over
time. The syllabus should reference this explicitly at Week 1 and Week 6 so students understand
why their final project matters beyond the classroom.

2. Syllabus Structure (Required Sections)

Every syllabus document MUST contain these sections, in this order:

2.1 Overview
 Track name (Coding / Art & Design / General)
 Ability tier (Foundation / Core / Advanced)
 Age range (informational only — actual placement uses the heuristics in 2.2)
 Prerequisites (specific: "Can open a browser" vs "Knows what a variable is")
 Total duration (default: 6 weeks, 2 sessions/week, ~1.5h per session)
 Tools & materials needed (specific versions, offline vs online)

2.2 Placement Heuristics

A short checklist the instructor uses to decide which tier a student belongs in. Example:
Coding — Foundation placement:
 Has never opened Scratch before OR
 Can move a sprite but doesn't know what a loop is OR
 Needs help reading on-screen instructions
Coding — Core placement:
 Has completed at least one Scratch project independently OR
 Understands loops + events + basic variables OR
 Can debug a simple broken sequence without help
2.3 Week-by-Week Matrix
Week Session 1 (Concepts) Session 2 (Build) Soft Skill
1 What students learn What students make One explicit soft skill
2 ... ... ...
3 ... ... ...
4 ... ... ...
5 ... ... ...
6 Pixel Lab + Showcase — Presentation / review

Rules for the matrix:

 Each week builds on the previous. If a student missed Week 3, the Week 4 syllabus should
say what catch-up is needed.
 Session 1 is concept-heavy (why, how it works). Session 2 is build-heavy (make something
that uses it).
 The soft skill column is not filler — it must be a taught skill (there's a mini-activity or
discussion for it), not just a label.
 Every week moves the Pixel forward, even if it's just "choose your topic" (Week 1) or
"sketch your layout" (Week 2).

2.4 Session Blueprint (per session)

Each of the 12 sessions must have:

Field Required? What to put

Time estimate Yes e.g. "15 min" — instructors
plan around real clock time
Materials needed Yes Specific: "ScratchJr open on
tablet" not "device"
Instructor does Yes Exact steps or script prompts —
remember the instructor may
not know the tool
Student does Yes What the student produces by
end of this block
Check for understanding Yes A 1-sentence question or
observation that tells the
instructor "yes, they got it"
Troubleshooting / edge case Recommended "If the sprite disappears, check
the X coordinate hasn't gone
off-screen"
Motion-reduced alternative Recommended "Skip the animation intro —
show the screenshot version
instead"
2.5 The Instructor Quick-Reference (at the back)
A 1-2 page cheat sheet with:
 Screenshots of what a correct project looks like at each milestone
 The 3 most common errors per week and how to fix them (README, not code — the
instructor may not code)
 A glossary of terms the instructor will hear students say
 Placement re-evaluation guide: "If a student is flying through the Foundation track, here's
how to bump them to Core mid-course"

2.6 Accessibility & Edge Case Appendix

This is where the syllabus accommodates the real world. Every syllabus must address:
Equipment constraints:
 Offline fallback: Can this session run without internet? How?
 Device shortage: Pair programming protocol (Driver + Navigator, swap mid-session)
 OS variation: Does the tool work on Windows, Android, ChromeOS? What breaks?
 Power/reliability: What if the device dies mid-session? Paper backup activity ready.
Student needs:
 Low vision / screen reader: Does the tool support it? What's the workaround?
 Color vision deficiency: Never use green/red as the only signal (pair with text/shape/label)
 Fine motor / mobility: Can all interactions be done with keyboard-only? If drag-and-drop is
required, what's the alternative?
 Hearing: All video content must have captions or a text equivalent
 Reading level: Instructions at Foundation tier should be at a ~6-year-old reading level even
for older students — don't shame by making them look childlike, but don't assume literacy
Behavioral / attention:
 Extended focus break pattern: Foundation sessions need a movement break every 20-25 min
 Overstimulation management: Scratch sounds, bright flashing animations — flag which
sessions may trigger this and offer a muted alternative
 The 15-minute self-reliance rule: Required for Core and Advanced tiers. Students must
attempt to fix an error for 15 min before asking for help, and state what they tried.
Language / culture:
 Nepal-specific: Keyboard layouts (US vs UK vs Nepali Unicode), language of instruction,
whether examples use Nepali names/contexts
  Assumed knowledge: Don't assume familiarity with Western cultural references, specific
brands, or English idioms

3. Terminology Standards (Do Not Deviate)

The following terms are locked. All syllabi must use the exact same words so a student who
switches tracks has consistency.

Use this Not this

Pixel Final project, capstone, portfolio piece
Mosaic Student gallery, grad wall
Session Class, lesson, period
Track Course, stream, path
Foundation / Core / Advanced Beginner / Intermediate / Expert
Facilitator Teacher, instructor, sir/mam
Check for understanding Quiz, test, assessment

Track-specific terms:
Coding track only:
 Block / Code block / Script (not "puzzle piece")
 Sequence (not "order")
 Loop / Repeat (both — they're different in Scratch vs Python)
 Condition / Conditional (not "if-then" alone — name the concept)
 Variable (not "score box" or "counter")
Art & Design track only:
 Canvas / Frame (not "page")
 Layer (not "level")
 Asset (not "thing" or "image")
 Palette (not "colors")
 Export (not "save as picture")
General track only:
 Document / Sheet / Slide (not "file" generically — be specific)
 Formula (not "function" generically — functions are a subset of formulas)
 Template (not "copy" or "format")
 Recipient / Audience (not "person reading it")
4. Design Rules (How It Should Look)
4.1 Visual Structure
 One page per week (two facing pages if printed, one spread)
 Session content is left-aligned, not centered
 Icons (where used) are consistent — same icon always means the same thing
 Checklists for each session the instructor can tick off

4.2 Voice & Tone

 Active voice, short sentences. "Open Scratch. Click the green flag." not "The student should
open Scratch and then click on the green flag."
 The syllabus talks to the facilitator, not about them. Second person: "You'll need to check
that each student has the right tab open."
 The Pixel sections talk to the student. Direct, encouraging. "This week you decide what your
Pixel will be about."

4.3 Output Format

 Source: Markdown (this file)
 Delivery: Converted to Google Docs for the team to collaborate on
 Print: PDF export from Google Docs — test that the matrix tables render correctly in print
layout

5. Review Checklist
Before a syllabus ships, it must pass:
 Every session has a time estimate
 Every session has a "Check for understanding"
 Equipment edge cases addressed (offline, device shortage, power)
 Accessibility edge cases addressed (vision, motor, reading level, hearing)
 All terminology matches Section 3 standards
 The Pixel is introduced by Week 1 and completed by Week 6
 Placement heuristics are on page 1 (after the overview)
 Instructor quick-reference is included at the back
 Soft skills are actually taught (not just labeled) — each has a concrete activity
 Each week builds on the previous (can you trace the dependency chain?)
 Reduced-motion alternatives exist for any session with animation
 The Mosaic is mentioned at least twice: Week 1 (introduction) and Week 6 (showcase)
Appendix: Edge Case Library
A non-exhaustive list of situations a syllabus should anticipate. If a syllabus doesn't address it, the
instructor has to invent a solution — the goal is to eliminate that.
 One device for two students: Pair programming protocol. Driver/Navigator roles, swap at
the halfway mark.
 No internet today: Which exact step of this session works offline? If none, there must be a
paper backup.
 Power cut mid-session: Have you trained the save reflex? "Save after every step" should be
in the session structure.
 Student finishes early: Extension activities for each session (not busywork — real next-
step exploration).
 Student is 2 weeks behind because they joined late: A per-week catch-up note saying
what's truly essential vs nice-to-have.
 Student is visually impaired and the tool doesn't support screen readers: What's the
paired activity they can do with a sighted partner?
 Student has a seizure condition and the session has flashing Scratch blocks: Warning
flagged at the top of the session + static alternative.
 Student doesn't speak the language of instruction well: Pair with a bilingual peer. Key
vocabulary list with translations.
 Student's Pixel is incomplete by Week 6: What does the showcase look like for them?
Partial credit is fine — they still present what works and explain what they learned from the
broken part.