An AI builds the lab. I designed how students work in it.

Galileo is a text-to-3D system for science classrooms, built by AAIC for Activate Learning. A curriculum specialist picks an investigation, and an AI assistant turns it into a lesson script: which objects are on the bench, what each step asks the student to do, and what should happen. The system works out the rest. Watch the three-minute product video.

Each step has two modes: Frozen, where the student acts, and Simulating, where they watch the computed run and read the result.

Each component had to take as few script fields as possible, fall back to sensible defaults, and work in labs nobody on the team had seen.

Every component in the kit has written rules: when it appears, what it says, where it goes and what it won’t do. A generated lesson follows them when nobody configures anything. Three examples:

Working within other teams’ systems

The lesson format, the pipeline and the physics belong to other teams. I fixed what I could inside the kit. My first rework of the time control extended the dev team’s events, so it was rolled back and rebuilt inside the kit. Where a change needed another team, I wrote an assessment brief or a data request instead of changing their code.

In the first month I set standards in Figma. After that I designed in code, against the real 3D scene. Subject-matter experts took an active part in building the labs’ experience, and the client’s specialists reviewed live builds, so their corrections were about behavior.

Generated labs framed their subjects unpredictably. Instruments ended up under the step bar, and on drag steps the drop target could be off screen. Lessons are increasingly written by models, which leave out camera instructions without any error.

I audited the camera moves in eight labs. Eight of fourteen in-step moves used the same preset, and one preset was never used. I rewrote the library as twelve roles, each with a stated purpose, and seven rules for when each applies.

The safe zone

The step bar and the time control cover part of the canvas at every window shape. The pipeline sends the box a step needs to show, and the kit widens the field of view and shifts the orbit target, within set limits, until the box clears the bars. It never moves the camera closer or further, because the distance is the student’s. It is recomputed from the authored view each time, so adjustments don’t stack.

A density lab has five graduated cylinders, four beakers, a pipette and a scale on one bench. In 3D every liquid is a clear fluid in glass, so water, hot water and hydrochloric acid look the same. A student could pour the acid without knowing it wasn’t water.

Three models in three months

The July model labels the object in hand, a vessel receiving a pour from the start of the step, and a drag destination once the object is picked up. Of a cable, only the end in hand is labeled. I gave up the always-on overview, and kept the background layer behind a switch instead of deleting it.

What a label can say

Worked out in the kit

The lesson format has a fixed list of object properties, so authors can’t add a hazard or a temperature. The kit works the marks out itself, and I sent a data request for temperature, substance and display names to the team that owns the format. Authors can still show, hide or pin a label for a step, or replace its wording.

Placement took five attempts, from fixed pixels above the object’s pivot to an offset in world space that holds at any zoom. Leader lines were rejected because they looked like callouts.

The drag sequence

When the step opens, the object to move has only its outline and its label. Nothing yet says where it goes. The first click picks it up, and everything about the destination appears at once: a ghost at the landing pose, an arc to it, a ring on the landing spot and the destination’s label. The second click commits. On the ghost, the object settles into place. Anywhere else, it eases back to where it started and the cues go away. Either way the step resolves on the drop, so the student never has to tap the destination.

The single-label model, derived hazard marks, per-step overrides for authors and the clearance around the interface ship in the customer release.

Investigations often say ‘give the cart a gentle push’ or ‘crank the generator faster’. In the labs built so far, the student clicked the cart and the lesson decided how hard.

I audited the curriculum before designing anything. Force accounted for 22 of the 46 steps, and just over half of the steps asked for a feel instead of a number. So the brief was one control with two readouts: a word when the lab says ‘gently’, and a number only when a real instrument is on the bench. Qualitative examples come first.

Seven designs, three kept

I built seven gesture designs as live prototypes and cut four:

A separate wave widget went too. The procedures have no continuous wave: ‘amplitude’ is a ruler pulled back a few centimeters, and ‘frequency’ is a count of releases. Of the three that stayed, the drag-arrow sets a direction, the slider is read against a graduated scale, and the crank sets a rotation by hand.

One sequence for every design

Click to start, move to set, click to lock. It works on a touchpad without holding a button down. A value that only passes through the range doesn’t enable Confirm, and there is no Reset button: to try again, the student makes the gesture again.

What testing changed

Where it stands

The three designs and the two-sided arrow ship in the customer release. The dev team wired them into the step engine and added a keyboard commit. Five investigations use the control, mostly in its qualitative mode.

Every run is computed on a server and played back, so every run starts with a wait. My first waiting state was a centered ‘please wait’ card over a faint wash, meant to stop stray clicks during the calculation. It also blocked orbit and zoom, which are the useful things to do while waiting. The client flagged it.

Where the signal could go

The time bar keeps its frame, its place and the speed dial. Only its middle changes, to a spinner and the word ‘Calculating’. It appears after 2 seconds, so a quick run shows nothing, and once shown it stays at least 1.5 seconds, so it doesn’t flicker. Nothing covers the experiment.

A reversal from live testing

I first kept Previous available during a calculation, as a way out. In live testing, a result that arrived after the student stepped back was applied to whichever step was on screen. Previous is now hidden for the two or three seconds a calculation takes.

The floating cockpit

I compared four screen layouts: a bottom dock, a side rail, a folded top and a floating cockpit, with each device control anchored beside its object. I chose the cockpit, and reversed it four days later. The floating controls took too much of the scene, moved unpredictably as the camera turned, and needed too many new rules. A stack replaced it: one device control at a time, at the bottom center, above the time bar.

One way to move things

I made click, carry, click the only way to drag, and migrated 87 authored steps from press-and-hold. It uses the same sequence as the gesture controls and the same cues as the labels: the destination appears on the first click, and near the target the ghost turns bright green. The dev team built the carry itself.

The kit is the student-facing layer in code: about forty native web components in HTML, CSS and Canvas 2D, drawn over the Unity scene. Unity doesn’t report where an object is on screen or what hides it, so the kit works that out from positions and the camera. The labels and the camera’s safe zone depend on it.

Lab DS, the labs’ visual system, has 159 design tokens. The kit catalog runs on the production code, so a page that looks wrong means the product is wrong. The dev team and the client review against it.