Designing Computing
for Learning

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”

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

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.

  Slides (PDF)Required reading: The Gears of My Childhood

  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.

  Slides (PDF)Google Form: team + project ideaRequired reading: The Gears of My Childhood

  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.

  Slides (PDF)Worksheet form: Learning theoryRequired reading: Fifty Years of ConstructionismOptional reading: Designing Constructionist Futures

  Finish the required reading — a 19-page chapter — before the Sep 9 lecture. The optional one is the full volume it introduces; dip into a chapter that interests you rather than reading it end to end.

  Starts tonight · final version due Dec 9

  Your final project report is one document you build across the whole semester, not something you write in December. Every section maps to a worksheet you have already filled in.

  ↓ Download the report template

  Start a shared copy with your team tonight — one document, every member with edit access — and add to it every week. You submit it with your final project deliverables on Dec 9.

  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.

  Slides (PDF)Worksheet form: Requirements, design & Agile

  ↑ Project report: add §2.2 (feature list as built) and §5.1 (scope decisions) from tonight’s prioritisation.

  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 by Sun, Sep 27 · 11:59 PMStudio worksheet: how the tool engages the target learner.

  Slides (PDF)Worksheet form: Scratch & beginner computing

  ↑ Project report: add §2.3 (designing for your learner) — the change you made from partner feedback.

  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.

• —

  Before Sep 30 — not a class day

  Team task before the Sep 30 studio

  Find three papers describing a design similar to yours, ideally in its learning goals. Each one should:

  • be specific — not broadly about games or about technology, but a project that looks arguably like yours;
  • describe an evaluation of that project using qualitative use data;
  • ideally build on theories of constructionist design and learning.

  All you have to do now is pick the three — the links themselves go in your Week 5 worksheet, which you have already submitted. Nothing extra to hand in for this task.

  From Week 9 onward the instructors will pick one of your three papers for your team to present in a later session. You do not choose which one, so pick three you would each be willing to stand up and talk about.

  Two samples below. Both are larger projects with several activities inside them — skim to get a sense of what this kind of paper looks like.

  Sample: Data in Motion — sports as a site for expansive learning Sample: Equitable approaches to computational thinking
• 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.

  Slides (PDF)Worksheet form: Studio 1

  ↑ Project report: add §5.3 (your riskiest assumption) and the test you planned for it.

  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.

  How the evening runs

  Two halves. A short pitch from every team, then the room turns into an open demo floor.

  First: 5-minute pitch per team — no break between teams Then: open demo

  • 4:10 – 4:15How the evening runs
  • 4:15 – 4:55Seven pitches, back to back
  • 4:55 – 5:10Set up your table
  • 5:10 – 6:45Open demo summit
  • 6:45 – 7:00Wrap, and what happens in Phase 2

  Part one — the pitches

  Five minutes each, back to back. Cover the learner, the learning goal, and the core interaction. Show the running artifact briefly here if you want to, but you do not have to — everyone will try it properly in part two. Teams pitch in this order:

  • 1Bookworms
  • 2Plant Life
  • 3Teachers_Techs
  • 4Awesome
  • 5EcoLogic
  • 6The_Vets!
  • 7Masari

  Part two — open demo summit

  Set up a table. Every team needs at least two laptops running your project, so two visitors can try it at once. Bring chargers.

  Rotate your team. Some of you stay at the table to help visitors use your tool while the rest go out and try other projects, then swap. Do not all leave at once, and do not all stay.

  Everyone else walks the room, tries each project properly, and completes that team’s evaluation form. Ninety minutes to get around the other six tables — about fifteen minutes each.

  Peer evaluation — one form per team

  Fill in a team’s form after you have actually tried their project at their table — not from the pitch alone. Six forms across the demo session, so finish each one before you move to the next table rather than leaving them all to the end.

  Every student fills in their own forms — unlike the studio worksheets, these are not submitted once per team. You do not fill in the form for your own team.

  • Bookworms
  • Teachers_Techs
  • The_Vets!
  • Awesome
  • Plant Life
  • EcoLogic
  • Masari

  Slides (PDF)

  ↑ Project report: capture screenshots of your runnable artifact tonight for §4 while it is fresh.

  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.

• —

  Before Oct 14 — not a class day

  Required reading before the Oct 14 lecture

  Turkle & Papert, “Epistemological Pluralism: Styles and Voices within the Computer Culture” (1990). The paper behind next week’s title — read it before class, because the session assumes it.

  Required reading: Epistemological Pluralism (Turkle & Papert)
• 08

  Oct 14

  Epistemological pluralism — feedback & pivot

  Vishesh

  Submit by Sun, Oct 18 · 11:59 PMStudio worksheet: Phase 2 revised design + build plan.

  Slides (PDF)Worksheet form: Feedback & pivot

  ↑ Project report: add §6.1 (keep, change, or pivot) and what the showcase feedback revealed.

  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

• —

  Before Oct 28 — not a class day

  Required reading before the Oct 28 lecture

  Brennan & Resnick, “New frameworks for studying and assessing the development of computational thinking” (2012). Read it over the break — it is the framework the Oct 28 session builds on.

  Required reading: Assessing computational thinking (Brennan & Resnick)
• —

  Paper presentations — Oct 28 and Nov 4

  Your presentation schedule

  From Week 9 each session opens with team paper presentations. Each team has been assigned a paper, carefully selected for your project. Find your team below — the date, the paper you present, and whether you also have an optional paper.

  25 minutes per team: 15 minutes presenting, 10 minutes of discussion. All seven run across two sessions only — deliberately early in Phase 2, so what you take from the papers can still change your build.

  When	Team	Paper you present	Also for you
  Oct 28 · Wk 9	Teachers_Techs	A textile-based learning game	—
  Oct 28 · Wk 9	Masari	DeVane et al. — Economists who think like ecologists	Optional paper
  Oct 28 · Wk 9	EcoLogic	Sustainability game	—
  Nov 4 · Wk 10	Awesome	Squire & Barab — Replaying History	—
  Nov 4 · Wk 10	The_Vets!	Veterinary game	Optional paper
  Nov 4 · Wk 10	Bookworms	Purgina et al. — WordBricks	Optional paper
  Nov 4 · Wk 10	Plant Life	Plant Life paper	Optional paper

  Required paper vs optional paper

  The paper you present is the one you read closely, summarise, and lead a discussion on. Every team has one.

  The optional paper is not for presenting and not for everyone — only some teams have one. It is there because it is especially close to your own project, so read it for your own design rather than for the presentation. Nothing about it is graded.

  What your presentation should cover

  • Describe the paper across all sections — theoretical frames, research goals, design, analytical methods, findings, and conclusions.
    • For design, look beyond the paper at the project or games it mentions, to get a detailed sense of how that game or project actually works. This is key to explaining and understanding the paper, and to drawing inspiration from it.
  • At least 2–3 design ideas for your own project that this paper inspires.
  • 2–3 discussion questions that provoke how this could inspire design ideas for other teams too. Put these on your last slide and end on them — they are what the 10 minutes of discussion runs on.

  Listening teams: you are expected to come up with ideas in advance, so read the presenting team’s paper before the session.

• 09

  Oct 28

  Assessing computational thinking

  Vishesh (tentative)Team presentations begin

  Team presentations start today From this session onward, teams present a paper. Every team has been assigned a paper chosen for their project. The schedule, the papers, and what your presentation should cover are all in the row just above this one.

  Paper presentations tonight

  Presenting tonight: Teachers_Techs, Masari and EcoLogic. 25 minutes each — 15 presenting, 10 discussing.

  Teachers_Techs: A textile-based learning gameMasari: DeVane et al. — Economists who think like ecologistsEcoLogic: Sustainability game

  Everyone else: read all three papers before class and come with ideas. Each presenting team ends on discussion questions and the room is expected to answer them.

  Submit by Sun, Nov 1 · 11:59 PMStudio worksheet: evaluation / demo plan.

  Slides (PDF)Worksheet form: Evaluation

  ↑ Project report: add §7.1 (your evaluation plan) straight into the report table.

  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

  Paper presentations tonight

  Presenting tonight: Awesome, The_Vets!, Bookworms and Plant Life. 25 minutes each — 15 presenting, 10 discussing.

  Awesome: Squire & Barab — Replaying HistoryThe_Vets!: Veterinary gameBookworms: Purgina et al. — WordBricksPlant Life: Plant Life paper

  Everyone else: read all four papers before class and come with ideas. Each presenting team ends on discussion questions and the room is expected to answer them.

  Submit by Sun, Nov 8 · 11:59 PMStudio worksheet: working prototype checkpoint.

  Slides (PDF)Worksheet form: Build

  ↑ Project report: add a row to §6.2 (what peer testing changed).

  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.

  Slides (PDF)Worksheet form: Build

  ↑ Project report: add §6.3 (the idea you adapted from another team).

  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.

  Slides (PDF)Worksheet form: Pre-demo

  ↑ Project report: add §6.2, §10.1 (what is unfinished), and finish §9 on AI use.

  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

  Studio 6 — final build before demo day

  Vishesh + Yu

  No worksheet this weekLast build night. Nothing to submit — spend it getting your project and your table ready for Dec 9.

  Slides (PDF)

  ↑ Project report: last build night — finish §10.1 and read the whole report end to end before demo day.

  Session detail

  Session plan

  One more full-session studio. Last chance to fix what the Week 12 run-through exposed, finish your table setup, and rehearse the demo end to end. Instructor checkpoint with each team.

• 14

  Dec 9

  Phase 2 demo day — all teams

  All teams

  Graded milestonePhase 2 demo, all seven teams. Peer grading in class, and final project deliverables due.

  Final evaluation — one form per team

  Fill in a team’s form after you have actually tried their project at their table. Six forms across the evening, so finish each one before you move to the next table rather than leaving them all to the end.

  Every student fills in their own forms — unlike the studio worksheets, these are not submitted once per team. You do not fill in the form for your own team.

  • Bookworms
  • Teachers_Techs
  • The_Vets!
  • Awesome
  • Plant Life
  • EcoLogic
  • Masari

  Slides (PDF)

  ↑ Project report: final report due with your project deliverables — see the checklist in Appendix B.

  Session detail

  Session plan

  Demo summit. Every team presents, then hosts a table demo. While each team is at its table the rest of the class circulates: try the tools, ask questions, give feedback, and complete 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

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