Code in a Browser Tab: Cloud Notebooks in Teacher Training

Press Run under each task. The first task starts with a small mistake: change range(10) to range(1, 11) and run it again. Nothing here was installed on your device; the code runs inside this page, the way the teachers’ code ran inside a web page during RAMPED. That one change in setup is the subject of the paper.

These are the two cloud questions from the paper’s assessment: print the numbers 1 to 10 (question 14, from the Space session, in Python) and swap two numbers (question 17b, from the NetLogo session, in Logo; the notebook runs it in Python). Load Common mistake on Task 2 to see why swapping needs a third variable: after a = b, the old value of a is gone.

Every cell talks to one kernel, the process that holds the notebook’s variables. Run Task 2, then Cell 3: the third cell reads a and b without defining them, and its last line appears as Out. Run the cells out of order, or press Restart kernel, and Cell 3 raises a NameError. Hidden state like this is the notebook’s main teaching hazard and also what makes it feel like a live workspace. The variable table below the notebook shows the kernel’s state after every run.

RAMPED hosted its Python materials on a JupyterHub instance, a multi-user server that gives each participant a notebook kernel through the browser; the paper does not describe the server, accounts, or costs. This page cannot run a Python server, so it runs MiniPy, a Python subset written for the page (loops, conditionals, functions, lists, strings, and Python’s integer and float arithmetic). MiniPy’s output matches CPython 3.13 exactly on 114 reference cells, including error messages, and on 1,850 randomized arithmetic expressions; the test files ship with the page in papers/cloud-notebooks/reference/.

RAMPED (Robotics, Applied Mathematics, Physics, and Engineering Design) ran for 16 days: two weeks in the summer and six follow-up days during the school year. Thirty teachers took part. In the summer, each teacher picked four of six two-day sessions, and each session ran twice with 10 seats, so 20 teachers went through every session. The researchers quizzed teachers before the summer, before and after each session, and at the end of the summer. Click a session with an item to follow it through the page.

The paper’s data come from four sources: use of the cloud tools, formal and informal interviews, content scores at each checkpoint, and an implementation survey about three months after the summer. Each assessment item belongs to one session, and Table 5.3.1 labels each item’s session Local or Cloud. Two sessions taught C++ (Robotics and Raspberry Pi) and two used browser environments (Space in Python and Naturally Inspired, or NNI, in Logo through NetLogo). The paper does not define the labels further or report them for the Virtual Reality and Arduino sessions.

Each line is one quiz question; the shaded band is the two-day session that taught it. Every question improved during its session. The difference shows up afterward. The two questions from the browser-based sessions (blue) kept climbing until the end of the summer, to 86 and 80 percent. The two questions from sessions the paper labels local (gray, dashed), which taught C++, fell back. The authors read this as support for browser tools: teachers could keep using them after the session ended.

Switch to Change between checkpoints to see Table 6.2.2. A change is the later percentage minus the earlier one: question 14 rose from 55 to 86 percent after its session, a change of +31 points. Pick an item to read its numbers. Question 7 is the only item answered with pictures instead of code, as the paper notes; keep that in mind when comparing its 45-point jump with the others.

Turn on the Local and Cloud means (computed by the page, unweighted across two items each). Across the two-day session, the local items gained more (+35.5 points against +10.0). From the end of the session to the end of the summer, the order flips: Cloud +26.0, Local −13.0. The paper’s averages in Table 6.2.2 have a simple form, since the three changes add up to the whole span: the average change is (post-post − pre-pre) ÷ 3. That identity makes the table easy to check, and it shows that Q5’s printed 3.33 does not follow from its row (the row gives 6.67).

The contrast rests on two items per group, and the groups differ in more than location: language (C++ against Python and Logo), session content, and item format (Q7 is graphical). Post-post comes at the end of the summer for everyone, so the post to post-post interval also depends on where in the two weeks a teacher took the session, and the paper does not report session order. Neither table reports item-level counts, standard errors, or a test; the percentages are presented descriptively.

After the summer, teachers presented their classroom plans at a partnership conference. The squares are the slides in two of those presentations, with the slides about each tool filled in. A high school physics teacher, new to teaching, used the notebooks to learn Python on her own and built part of her class around them. A fourth-grade teacher turned NetLogo Web into lessons, and she reported that students who had never coded before were changing the model’s code within 15 minutes.

The case studies answer the first research question qualitatively. The physics teacher (under two years of experience) devoted eight of 24 slides to Jupyter, and a follow-up interview matched that emphasis to her implementation plan; the elementary teacher (about 10 years) devoted more than half of 23 slides to NetLogo. The authors’ reading: teachers with continuous web access to a working environment became self-learners and carried CS into class, while tools that needed district technology support or per-student purchases were less likely to be adopted.

How many teachers answered

Table 6.2.1 is printed as the percentage of 20 participants answering correctly, but a percentage of 20 must be a multiple of five, and only five of the 16 entries are (45, 90, 55, 55, and 80). The page asks, for every group size n, which entries some whole number of correct answers out of n can produce when rounded. No single n from 10 to 30 fits all four checkpoints of any item; the smallest that does is 34 for Q5 and between 44 and 49 for the others, more teachers than the 30 in the whole PD. The most likely reading is that the number answering changed from checkpoint to checkpoint. This search is the page’s analysis, not the paper’s.

• Teachers improved on all four coding questions during the two-day session that taught each one.
• By the end of the summer, the two questions from browser-based sessions had climbed to 86 and 80 percent correct.
• The two questions from the sessions labeled local fell back after their sessions ended.
• Teachers were frustrated and hesitant at first, then more willing to use free web tools than tools that needed extra support or money for each student.
• A physics teacher and a fourth-grade teacher both built classroom lessons around the browser tools.

• Gains during instruction on every item. Percent correct rose from pre-pre to pre to post on all four items (Table 6.2.1).
• Cloud items kept rising afterward. From post to post-post, Q14 gained 31 points and Q17b 21; Q5 lost 18 and Q7 lost 8 (Table 6.2.2).
• Adoption favored free web tools. After initial frustration, teachers were more willing to adopt free web-based technology than tools requiring added support or per-student spending.
• Self-learning followed access. Instructors with web-based programming access were more likely to keep learning on their own and to implement CS in class (two case studies).
• Stated limits. Twenty self-selected participants in a paid PD, mostly from one district; a short PD for a new technical area; a survey only three months out; and expert staff unusually experienced in outreach.

Many schools want computer science in every grade but lack the computer labs, software licenses, and technical staff to support it. This study suggests a lighter path: browser-based tools let teachers keep practicing after a training ends, and teachers adopt the tools that cost their schools nothing and need no installation. Ultimately, the barrier the authors removed was setup, and the teachers did the rest.

Short web activities, such as an Hour of Code, end where the activity ends; moving on to real programming usually means a local install, which the paper argues stalls learners. Fully functional environments in the browser close that gap for teachers and, through them, for students. The paper’s implication for PD designers and university outreach: use cloud-based coding environments to get K–20 instructors incorporating CS into the STEM courses they already teach.

The design is a pilot, and its quantitative evidence is four items without item-level counts. Its value lies in the question it isolates, retention and reuse after instruction as a function of where the code runs, and in a measurement plan (seven checkpoints through a school year) that a larger study could carry out in full. The same PD appears in the authors’ journal study of the NetLogo session (Education Sciences, 2019), which reports the same four items among seven, and the team later moved to fully online, self-paced formats with cybersecurity microcredentials for teachers (Education Sciences, 2021).

Notes from building this page

• Q5’s average. Table 6.2.2’s average change equals (post-post − pre-pre) ÷ 3 on three rows; for Q5 that gives 20 ÷ 3 = 6.67, against the printed 3.33 (exactly half). The three printed changes for Q5 are correct.
• Denominators. Only five of 16 entries in Table 6.2.1 are whole numbers of 20, and no single group size up to 30 reproduces any item’s four checkpoints. The number of teachers answering most likely varied by checkpoint; reporting those counts would allow a paired test. The 2019 journal paper prints the same values for these four items and also averages “across all 22 participants,” which supports varying counts.
• What Local and Cloud mean. The labels appear only in Table 5.3.1 and attach to sessions, so each comparison also contrasts C++ against Python or Logo, robotics and Raspberry Pi content against space science and bio-inspired models, and one graphical item against code items. With two items per group, the contrast cannot separate these.
• Timing of post-post. Post-post follows the whole summer, so the interval after a session depends on when a teacher took it; teachers who took a session in the second week had less time to forget, or to keep practicing. Session order is not reported.
• Three or two case studies. The abstract describes three case studies, including a university instructor’s PD and undergraduate teaching; the body presents two (Case Studies I and II).
• Survey results. Methods state that implementation survey results appear in “Table 6.2.1,” which reports assessment scores; the survey results themselves are not tabulated.
• Small details. Thirteen of 20 is 65 percent (63 percent printed); “about 12% of their students (16)” reads as 16 of the average 125.5 students, which is 12.7 percent.

Try this in class

1. Give the class the two notebook tasks above on paper first: write code that prints 1 to 10, and code that swaps two numbers. Collect the answers without grading them.
2. Open this page, run each task’s Starter, Common mistake, and Solution, and ask students to explain each output before they press Run.
3. A week later, ask both questions again, on paper and without the page, and compare the percent correct with the class’s first try, as the RAMPED researchers did with teachers.