What the course is
Most educational software is built by people who understand code, or people who understand learning. Rarely both.
This course puts the two in one room and asks them to ship something together. You keep your own major — CS students enroll through Engineering, Education students through Peabody — and you work in a mixed team all term.
What counts as “computing for learning”
A learner
A specific person, with existing knowledge, motivation, and limits.
A learning goal
Something they should come to understand or be able to do.
A computational medium
Software that changes what that learner can do, see, or notice.
The test: a grade book is educational software, but it is not computing for learning — nobody learns anything by using it. Ask what your tool changes inside the learner. A game, a microworld, a practice-and-feedback tool, an explorable explanation, a teacher-facing tool, a making-and-sharing platform: all fair game.
Who you will be working with
People
Instructor · Learning sciences
Vishesh Kumar
Constructionism and design for learning; beginner computing environments.
Instructor · Computer science
Yu Huang
Human-centered AI for software engineering; requirements, design patterns, Agile, and AI-assisted development.
Teaching assistant · PhD candidate, CS
Zihan Fang
How novices read and understand code, studied with eye-tracking; accessibility in programming; open source for social good.
Fourteen Wednesdays
Schedule
Each bar shows how that evening is split. Anything you have to hand in is flagged in red. Open “session detail” for the session plan and the in-class exchange.
- Lecture
- Team studio
- Pitch or demo
-
01
Aug 26
Course intro & inspiration tour
Vishesh + Yu
Complete by Fri, Sep 4 · 11:59 PMOpen the pre-course survey — it covers the skills and interest inventory too. Also bring a light reflection: two or three tools or studies from tonight that sparked an idea.
You are expected to finish this reading before the Sep 2 session.
Session detail
- Session plan
- Course vision and motivation: computational tools for education. Why interdisciplinary CS + Education teams. Syllabus, policies, AI policy. Overview of the two-phase project and showcase structure. Inspiration tour: a sampler of education research and computational learning tools to widen the solution space.
-
02
Sep 2
Learning theory intro + ideation workshop
Vishesh + Yu
Submit by Fri, Sep 4 · 11:59 PMOpen the team + project idea form — your tentative team (name, VUID, email, and CS or EDU for each member) and a brief description of your tentative project idea. Filling in the form is the whole submission; nothing goes to Brightspace. Only one person per team needs to submit it; if several of you do, no harm done. Both the team and the idea are tentative — you can still adjust next week.
You were expected to finish the required reading before the lecture today — the discussion assumes it.
Session detail
- Session plan
- Opens with a short learning-theory intro (constructionism; how people learn by making) to frame the design task. Then deliberate-practice ideation in three moves: work alone to form a concrete project idea; share round-robin so every idea surfaces; open conversation so you learn each other's ideas and names. Teams form around shared ideas at the end of class. Formation is tentative at this stage — Friday Sep 4 is also the add/drop deadline, so rosters are still settling. Submit your tentative team and project idea through the Google Form by Friday Sep 4; you can still adjust next week.
-
!
Fri, Sep 4 — not a class day
Two things due tonight · 11:59 PMThe pre-course survey set on Aug 26, and your team + project idea form set on Sep 2. Friday Sep 4 is also the add/drop deadline.
-
03
Sep 9
Learning theory in depth
Vishesh
Submit by Sun, Sep 13 · 11:59 PMStudio worksheet: map your design idea to learning principles. The worksheet also asks for your final team members — whatever you enter there is your locked roster for the term.
Session detail
- Session plan
- Teams are finalised tonight — the last chance to adjust, now that add/drop has closed. You confirm the final roster inside the worksheet rather than as a separate submission. Lecture: a deeper dive into constructionism and theories of learning (Papert); epistemological pluralism and diverse styles of building and expression; design-for-learning principles. Studio: teams apply the principles to their emerging idea, guided by a worksheet.
- Connect & compare
- Guess the learning theory. Each team designs one feature, describes it to a partner team, and the partner team names the learning theory or principle they think it reflects.
-
04
Sep 16
Requirements, design patterns & Agile
YuLive vibe coding demo
Submit by Sun, Sep 20 · 11:59 PMStudio worksheet: requirements + feature list + first sprint plan.
Session detail
- Session plan
- Merged software-engineering session. Lecture: requirements engineering (eliciting needs, user stories, scoping a feature set from a learning goal), software design patterns for structuring the tool, and Agile development (tasks, sprints, iterating on a prototype). Includes a short live vibe coding demo — building something small with AI in front of you, mistakes and all — with AI as the medium rather than the topic. Studio: teams draft requirements, structure, and a first sprint plan.
- Connect & compare
- Must have / nice to have / why? Each team shares four to six possible features. The partner team sorts them into must have, nice to have, and remove. Teams compare against their own prioritisation.
-
—
Before Sep 23 — not a class day
Required reading before the Sep 23 lecture Three pieces. Read the facilitation guide for how to notice each other’s learning and struggles — what your teammates and your learners actually understand, and where they are stuck. Read the other two to generate new design ideas for your own project.
-
05
Sep 23
Scratch & beginner computing modalities
Vishesh
Submit by Sun, Sep 27 · 11:59 PMStudio worksheet: how the tool engages the target learner.
Session detail
- Session plan
- Lecture: Scratch and beginner-friendly computing modalities such as MakeCode; strengths and limits of platforms for learning and self-expression across contexts. Studio: hands-on exploration tied to each team's target learners.
- Connect & compare
- Design for this learner. Each team describes its target learner and one planned interaction. The partner team considers it from that learner's perspective and suggests one way to make the interaction easier to understand, use, or engage with.
-
06
Sep 30
Studio 1 — converge and stress-test
Vishesh + Yu
Submit by Sun, Oct 4 · 11:59 PMStudio worksheet: Phase 1 design idea near-complete (draft); feasibility spike attempted, with findings recorded.
Session detail
- Session plan
- Full-session team studio with instructor and peer consults at the table. Teams converge on a complete design idea ahead of the Phase 1 pitch. Feasibility spike: each team builds the riskiest ~10% of the idea — the one interaction or technical piece they are least sure of — before pitching it. A paper prototype, a throwaway script, or a clickable mock all count; the point is to reality-test the core before committing to it.
- Connect & compare
- What could go wrong? Each team explains the riskiest assumption in its idea. The partner team generates possible failure cases and one quick way to test the assumption.
-
07
Oct 7
Phase 1 showcase — design pitches
All teams
Graded milestonePhase 1 design pitch + runnable artifact. Peer and instructor feedback collected.
Session detail
- Session plan
- Phase 1 milestone. Every team gives a short design pitch — idea, target learner, learning goal, activity, planned implementation — and shows a runnable artifact rather than slides alone: a working fragment, a hacky demo, or a clickable prototype of the core interaction. Structured whole-class feedback after each pitch.
-
08
Oct 14
Studio 2 — feedback & pivot
Vishesh
Submit by Sun, Oct 18 · 11:59 PMStudio worksheet: Phase 2 revised design + build plan.
Session detail
- Session plan
- Phase 2 begins. Full-session team studio: teams integrate Phase 1 feedback, revise or substantially pivot their design, and push implementation forward. Instructor checkpoint with each team.
- Connect & compare
- Keep / change / pivot. Each team shares one important piece of Phase 1 feedback. The partner team picks one of the three responses and works through a concrete next step.
-
—
Oct 21
No class — Fall Break begins Oct 22
-
09
Oct 28
Evaluating education tools
Vishesh (tentative)
Submit by Sun, Nov 1 · 11:59 PMStudio worksheet: evaluation / demo plan.
Session detail
- Session plan
- Lecture: evaluation methods for education tools — assessing learning and usability, and gathering evidence that the tool works. Studio: teams plan their own evaluation and demo.
- Connect & compare
- Evaluate my tool. Each team introduces its tool and intended learning goal. The partner team applies the evaluation methods from class to propose ways to assess learning effectiveness and usability.
-
10
Nov 4
Studio 3 — build
Vishesh + Yu
Submit by Sun, Nov 8 · 11:59 PMStudio worksheet: working prototype checkpoint.
Session detail
- Session plan
- Full-session team studio: teams implement and refine core features, with instructor and peer consults at the table.
- Connect & compare
- Try my tool. Each team lets a partner team try one core interaction with minimal explanation. The partner team notes confusing steps, unexpected behaviour, and usability issues.
-
11
Nov 11
Studio 4 — build
Vishesh
Submit by Sun, Nov 15 · 11:59 PMStudio worksheet: feature-complete checkpoint.
Session detail
- Session plan
- Full-session team studio: continued implementation and integration. Instructor checkpoint with each team.
- Connect & compare
- Steal one good idea. Explore another team's project and identify one idea, AI workflow, interface pattern, or technical approach you could adapt to your own.
-
12
Nov 18
Studio 5 — pre-demo build
Vishesh + Yu
Submit by Sun, Nov 22 · 11:59 PMStudio worksheet: demo-ready build + presentation prepared.
Session detail
- Session plan
- Final build session before demos. Teams finalise features, prepare their demo and table setup, and rehearse. Instructor checkpoint with each team.
- Connect & compare
- Final check. Each team lets a partner team try its near-final tool and demo flow. The partner team gives feedback on what works, what could improve, and one concrete way to strengthen the final presentation.
-
—
Nov 25
No class — Thanksgiving Break, Nov 21–29
-
13
Dec 2
Phase 2 demos — first half of teams
First half of teams
Graded milestonePhase 2 demo, first half. Peer grading sheet completed in class.
Session detail
- Session plan
- Phase 2 demos. The first half of teams each present, then host a table demo. The rest of the class circulates as a summit: try the tools, ask questions, give feedback, and complete peer grading.
-
14
Dec 9
Phase 2 demos — second half of teams
Second half of teams
Graded milestonePhase 2 demo, second half. Peer grading in class, and final project deliverables due.
Session detail
- Session plan
- Same summit format. The remaining teams present and host table demos; the rest of the class circulates, gives feedback, and completes peer grading.
Tentative and subject to change. Week 9 is a flexible placeholder. Where one instructor is named, the other need not attend.
Two phases
The project
Design idea and pitch
Find a learner, a learning goal, and a design worth building. In the Week 6 studio you build the riskiest ~10% of the idea first — a feasibility spike — so the pitch rests on something you have actually tested.
At the Oct 7 pitch you show a runnable artifact, however rough: a working fragment, a hacky demo, or a clickable prototype of the core interaction. Slides alone will not pass.
Build and demo
Integrate the Phase 1 feedback — keep, change, or pivot — then build across five studio sessions and plan how you will know whether it works.
Demo nights are a summit. Half the teams present each evening, then host a table. Everyone else circulates, tries the tools, gives feedback, and completes peer grading.
How you are assessed
Grading
- 40% Final demo + project deliverables
- 25% Phase 1 design pitch + runnable artifact
- 15% Participation + peer grading
- 10% Studio worksheets (submitted by team)
- 10% Team contribution (graded by your teammates)
The pitch and the demo are 65% of your grade
Both are scored half by your peers and half by the instructors and TA, using the same criteria on the same sheets.
Inside the peer half: every peer scores you, then the highest and lowest scores are dropped and the rest averaged.
One harsh review or one friend cannot move your grade. Everything in between counts.
The rules
Policies
Studio time cannot be made up alone
Half of most sessions is your team working together. If you have to miss, tell your team and us in advance.
Proposed in Week 2, locked in Week 3
You submit a tentative team by Friday Sep 4, then confirm your final roster inside the Week 3 worksheet, due Sunday Sep 13. After that they are fixed. If a teammate disappears, we cannot do their work for you — but team contribution is 10% of the grade and your own teammates assign it. Tell us early anyway: we cannot add hours to your week, but we can help you cut scope.
Worksheets are due the Sunday after class
Every worksheet is due the Sunday after that class, 11:59 PM, submitted through its Google Form linked on the session. You start it at the table and finish it at home — the point is that it leaves the room with a decision on it. Milestone dates are fixed.
Small and working beats large and broken
We would rather see a modest tool a stranger can use than an ambitious one that does not run on demo night.
AI policy
Use it. Then tell us how.
We are not merely allowing AI — we are asking you to use it. Build with it: scaffold, debug, refactor, generate. Think with it: argue about your learner, ask it to attack your design, then make the call yourself. Week 4 includes live AI-assisted demos.
Disclosure is the rule, not permission. Every studio worksheet has an AI-use section: what you used it for, what you kept, what you rejected, and what you had to verify. That reasoning is the graded part. Undisclosed use is the violation — not use itself.
“If AI could obviously have helped and you refused to use it on principle, I will be a little heartbroken.” — Yu