What this post covers
- Why the first part of
AirClassI tried to build wasDisplay - What mattered most in that first attempt
- What worked reasonably well
- Why it stopped before becoming a classroom tool
As I wrote earlier, AirClass did not begin from a large architecture. I started with the most immediate inconvenience in my own classes. That is why the first thing I tried was not Quiz or a full platform, but Display.
Why I tried Display first
While teaching with a tablet, the first problem I noticed was that students could not always follow the screen comfortably. The advantage of using the same material was clear, but in a real classroom that advantage could quickly become a weakness.
The class keeps moving forward. Some students want to see the previous explanation again. Others miss one part and then struggle to follow the next part.
So what I wanted was not just screen sharing. I wanted something like this:
- The teacher's lesson screen reaches students smoothly.
- Students can see it on their own devices.
- They can revisit recent content when needed.
- The system is more flexible than ordinary Miracast.
So the first idea behind AirClassDisplay was not simply "broadcasting a screen." It was closer to helping students lose less of the lesson flow.
Latency was the most important criterion
The key criterion was clear: latency had to be low.
A classroom tool is not useful if the screen appears several seconds later. If the teacher's explanation and the student's screen are out of sync, the lesson flow breaks. So I cared more about responsiveness than resolution or extra features.
The target was:
- rendering at least as smoothly as
Miracast - showing teacher screen changes almost immediately
- letting students watch on their own devices without breaking the lesson rhythm
That led naturally to a WebRTC-based structure where the screen would be sent to a server and redistributed to students.
The implementation had a fairly clear structure
At the repository level, AirClassDisplay was divided into clear roles.
backend/: aFastAPIbackend controlling sessions and streaming flowfrontend/: web screens where teachers and students could view stream statusandroid/: an area where I tried to connect a teacher-side input appdashboard/,gui/: operation and execution helpers
It was not just "show one tablet screen." It was becoming a system with separate layers for input, real-time transmission, student viewing, and operation control.
A simplified flow looked like this.
I wanted more than simple mirroring
Ordinary Miracast can display a screen on the classroom display. But that alone did not solve the problem I cared about.
I wanted each student to be able to check the class screen on their own device, and eventually to revisit recent content. In other words, Display was an attempt to treat the lesson screen as something that could be delivered, reviewed, and reused.
The result was not bad technically
The implementation did reach a meaningful point. It was not a polished product, but the smoothness and responsiveness were better than a mere idea. I could feel that the direction might work.
If I only looked at technical performance, AirClassDisplay seemed like a promising start. The real problem was not whether the stream could work. The real problem was whether this workflow could fit into an actual classroom.
But it increased the amount of equipment and preparation
My ordinary tablet lesson was simple. I could bring a tablet and a dongle and start quickly. That simplicity was important.
With AirClassDisplay, the flow became heavier.
- I needed to bring a laptop too.
- I needed to open a browser and control screen.
- I had to check monitor connections.
- I had to test the whole flow before class.
The project started to improve the student experience, but it increased the teacher's operational burden. In real classes, the simplicity of preparation can matter more than one additional feature.
The decisive problem was sending the tablet screen to the server
The bigger problem was how to send the tablet screen to the server. In the structure I imagined, the tablet screen needed to go up to the server and then be delivered to students.
But in the actual tablet-based class flow, I often used Miracast. When the tablet was connected through Miracast, capturing and separately sending the screen through WebRTC was not smooth.
That meant the source step itself was blocked. The desired tablet-centered workflow and the transmission structure required by AirClassDisplay collided.
- I wanted to teach simply with only a tablet.
- To send student screens, I needed a server streaming structure.
- Miracast made screen capture difficult.
- So I needed an additional laptop and a separate flow.
This was more fundamental than a small bug.
So it did not become a classroom tool
AirClassDisplay was not a complete technical failure. It worked enough to show possibility.
But a classroom tool is not a demo. A teacher has to be able to use it repeatedly without too much burden. From that viewpoint, this attempt was not ready.
Students might gain something, but if the teacher's preparation cost becomes too high, adoption becomes difficult. So the attempt stopped before actual classroom use.
What the attempt left behind
Even though it did not settle into class, it clarified important principles.
First, an education tool is not enough just because it is technically possible. It must fit into the preparation flow of a real class.
Second, a feature that improves the student experience can still fail if it makes teacher operation too heavy.
Third, the Display problem was not just an output problem. It remained a core design question for the rest of AirClass: what should be delivered to students, and at what operational cost?
Closing
The first implementation attempt in AirClass was Display because my first concern was how students could follow the class screen.
I confirmed some possibility around latency and smooth rendering, but the classroom workflow became the bigger wall. Keeping a tablet-centered lesson while also sending the screen to students was harder than expected.
In the next post, I will write about how this experience led me to look at AirClass differently.
💬 댓글
이 글에 대한 의견을 남겨주세요