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 Sun, Sep 6 · 11:59 PMOne file to Brightspace listing every team member: name, VUID, email, and CS or EDU. Only one person per team needs to upload it — if several of you do, no harm done. Tentative only; you can still adjust the roster next week.
You were expected to finish this before tonight — 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: the add/drop deadline is Friday Sep 4, so rosters only settle just before. Submit your proposed team by Sunday Sep 6.
-
03
Sep 9
Learning theory in depth
Vishesh
Teams lock tonight — final adjustmentFinal team roster confirmed at the end of class. Studio worksheet: map design idea to learning principles.
Session detail
- Session plan
- Teams are finalised at the end of class — the last chance to adjust, now that add/drop has closed. 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 this weekStudio 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.
-
05
Sep 23
Scratch & beginner computing modalities
Vishesh
Submit this weekStudio 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 this weekStudio 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 this weekStudio 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 this weekStudio 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 this weekStudio 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 this weekStudio 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 this weekStudio 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 Sunday Sep 6 and make final adjustments by the end of Week 3, after add/drop closes. 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 night of class
They leave the room with a decision written on them. Hand them in during class or upload them to Brightspace. 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