Every teacher who has run a digital quiz has a version of this story. Thirty devices join at once, the room goes quiet, and then a hand goes up at the back: "Miss, it's stuck." Within a minute it is six hands, and the lesson you planned is now a lesson about connectivity.
The instinct afterwards is to blame the tool, or to stop doing digital quizzes. Neither is quite right. The failure is predictable, it has a specific cause, and it can be designed around.
Why it fails at exactly that moment
School networks are usually provisioned for a realistic average load — a few devices per classroom, browsing and streaming at different times. A class quiz breaks that assumption in a specific way: thirty devices attempt to connect within the same ten seconds, and then keep a connection open for the whole activity.
Three things tend to go wrong, often together:
- Access point saturation. A single AP serving a classroom has a limit on simultaneous clients that is lower than most people assume, and a room of phones plus a room of laptops can exceed it.
- The captive portal. Guest networks that require a login page will ask thirty devices to authenticate at once, and the portal is rarely built for that.
- Filtering and shaping. Traffic passing a content filter can be slowed or blocked when a pattern looks unusual — and thirty identical requests in ten seconds is unusual.
Notice that none of these are "the internet is down". The connection usually comes back within a minute or two. The damage is done in that minute, and it is done by the software's reaction to it, not by the outage.
The real problem is not the outage, it's the design
A quiz that sends every answer to a server the moment it is given, and refuses to continue until the server confirms, treats a ten-second gap as a fatal error. Students see a spinner, press things, refresh, and lose their place — which is the part that actually costs you the lesson.
A quiz that saves the answer locally first and syncs afterwards treats the same ten-second gap as nothing at all. The student answers question seven while the network is down, answers eight and nine, and the queued answers upload when it returns. Nobody notices.
The design rule: the network should be required for starting and finishing, not for every question in between.
This is what "offline-first" means in practice, and it is the single most important thing to check before you commit a graded test to a tool. It is rarely on the feature list, because it is invisible until the day it matters — and it is the one thing that separates an offline quiz app for teachers from one that merely runs in a browser. It is one of the eight checks in how to choose a classroom quiz app.
Practical steps before the lesson
Stagger the join
Do not put the code up and say "everyone go". Ask half the room to join, wait fifteen seconds, then the other half. This alone avoids most access point problems and costs nothing.
Get devices onto the network before the quiz starts
If your network uses a login portal, have students connect at the start of the lesson rather than at the start of the quiz. The portal handles thirty logins over five minutes perfectly well; it is thirty in ten seconds that breaks it.
Share the code in a way that does not need the network
A code on the board works when the projector does not, when the shared link does not load, and when a student's device has dropped off the network entirely and rejoined. A six-character code read aloud is the most robust delivery mechanism available to you.
Allow mobile data as a fallback
Where school policy permits it, a student whose device falls off the Wi-Fi can finish on mobile data without anything being lost. This only works if the quiz does not tie a session to a single network connection — worth testing once, on purpose, rather than discovering mid-test.
Test it deliberately
Run a three-question quiz on your own phone, and put the phone in airplane mode halfway through. What happens next tells you everything: either the answers queue and the quiz continues, or you have just watched what your class will experience on Thursday.
What to do when it happens anyway
- Do not tell them to refresh. This is the instinct and it is the worst available action — on a tool that caches locally, a refresh is the one thing that can actually lose work.
- Tell them to keep answering. If the tool is offline-first, the answers are already saved. Silence for sixty seconds is usually all that is required.
- Extend the time rather than restarting. Restarting a quiz because of a network wobble punishes the students who were furthest ahead.
- Check the sync before you let them leave. If answers upload on completion, a student who walks out with an unsynced device has their answers in their pocket rather than on your screen.
When the network is unreliable all lesson
If your network is genuinely unreliable rather than occasionally congested, the honest answer is to design for it rather than hope. Run the quiz with the expectation that sync happens at the end; collect the results when devices are back on a working connection; and accept that live progress monitoring will not work. That is a real cost, but it is much smaller than an abandoned test.
The one moment you cannot route around is the start. Nearly every tool of this kind — Quizoma included — has to reach the server once to look the quiz code up and sign people in. So spend your good network minutes there: get everyone joined first, then stop worrying about the connection.
What to look for in an offline quiz app
- Are answers saved on the device before they are sent?
- Does the quiz continue while the connection is down, or block?
- Do queued answers sync automatically, or does someone have to notice?
- Can a participant switch networks mid-quiz without losing their place?
- Is joining possible with a short code, not only a link?
Quizoma is built to answer yes to all five: answers are written to the device the moment they are given and synced afterwards, and joining is a six-character code or a QR. Written answers are handled by typo-tolerant grading once they reach you, so a patchy connection does not turn into a marking problem either. See the full feature list.