[AirClass Dev Log 5] Keeping Prompts from Passing By: First Classroom Use of AirClassSlide

What this post covers

Why I built AirClassSlide
How the problem resembled the earlier Display problem
What functions I attached directly to slides
What changed in the first classroom use
Why this experience led toward integrating the AirClass tools

After AirClassQuiz reduced friction in quiz lessons, the next problem was slides. This time the setting was a vibe-coding class at Busan Mathematics Culture Center.

The problem: prompts kept passing by

In a vibe-coding class, students repeatedly type prompts, check outputs, and revise them. But in practice, once the prompt passed on the screen, the class flow often broke.

Some students were still listening. Some had just started typing. Some mistyped one line and needed to see it again. But the screen had already moved on, so the same questions repeated and the pace spread out.

This resembled the Display problem from Part 3. Again, the core issue was that students could not recheck the content they needed at their own pace.

The first goal: slides that can be edited and reflected immediately

This time the goal was clear: slides that can be edited during class and reflected immediately on student screens.

A finished slide deck was not enough. In a vibe-coding class, I often need to change a prompt, rewrite example code, or reorder the explanation based on student questions. The slide screen had to stay alive during class.

So AirClassSlide started as a real-time editable slide runtime rather than a presentation tool.

The second problem: submitting work was also friction

Students also struggled with submitting their work. Previously I often asked students to email files, but many students had trouble with the email flow itself.

Some finished the task but attached the wrong file. Some used the wrong title. Some stopped at the sending step. The submission method became a barrier before I could even check the work.

So I wanted the slide to also handle:

distributing code examples
distributing assignment files
uploading student results in the same flow

The slide needed to become a classroom work surface, not just an explanation screen.

The implementation matched the class flow

The project structure also reflected this classroom flow.

src/routes/teacher: teacher creates a room, selects a deck, and controls class
src/routes/student: student enters with a room code and name
src/routes/room/[code]: student lesson screen
src/lib/airclass-slide/runtime/ws/client.ts: WebSocket client for real-time teacher/student connection
src/lib/airclass-slide/runtime/stores/*: stores for teacher and student room state
src/lib/airclass-slide/core/schema/*, core/protocol/*: room, deck, slide, command, event, and snapshot rules
data/library-decks/*.json: deck storage format prepared before class

A simplified flow looks like this.

Slides became containers for classroom components

The important part was that slides were not just text. I wanted to insert classroom functions as components inside the slide.

The code structure showed that direction:

content/extensions/component-block.ts: insert components as slide blocks
content/renderers/code-block-view.svelte: render code examples
student/result-upload-panel.svelte: student result upload panel
src/routes/room/[code]/handouts/download/+server.ts: download distributed files
src/routes/room/[code]/upload/+server.ts: store student uploads

As a classroom flow, the idea looked like this.

The first use immediately made a difference

I used it in class for the first time that day. It was only one use, so I do not want to exaggerate, but the difference was clear.

The most noticeable change was that repeated questions decreased. Before, students kept asking things like "Can you show the prompt again?", "Where is the code?", "Which file should I download?", or "How should I email it?" This time, they could recheck the needed elements inside the slide, and distribution/submission happened in the same flow.

As a result, more students reached implementation successfully. Reducing the friction points gave students more time to actually build.

It led naturally to thinking about integration

This mattered not only because the slide worked. It also made me feel that Display, Quiz, and Slide should not remain separate tools forever.

Display: the screen students need to see
Quiz: the response and record flow
Slide: explanation, prompts, handouts, and submission

In a real class, these do not exist separately. They continuously connect. That is why the experience led me to think about integrating AirClass as one classroom operating flow.

Closing

AirClassSlide began from the problem that prompts and materials passed by too quickly in vibe-coding class. It resembled the earlier Display problem, but this time I could build a more direct structure where students recheck and act at their own pace.

Real-time editable slides, code distribution, handout distribution, and result upload reduced repeated questions and improved implementation success in the first use.

The next step is to connect Display, Quiz, and Slide into one natural classroom flow.