Synchronized interaction with phones: what are the limits?
This documentation only covers interactions synchronized with the screen, for example when everyone tries to answer a question at the same time.
A Wi-Fi network built for a few dozen devices, a weak mobile network, a phone screen that goes to sleep.
Incidents most often come from your network.
This page goes through each problem a room runs into, and how to handle it.
How many participants can you host?
The number of participants depends on the plan you choose, and sometimes on the type of game.
- A cap stated along with what it counts. Depending on the case, the cap applies to current connections, to the participants of one game or one event, or to a cumulative total.
- A lower cap for timed games. A real-time leaderboard asks more of the server than a simple vote: the limit for a quiz can be lower than for a poll.
- When the room is full. The extra participant gets a message, which the organizer can write, or waits in a waiting room and enters as soon as a place frees up. The host is warned before the limit is reached.
- A display delay rather than a refusal. Beyond a certain number of participants, the real-time display may lag slightly instead of closing the door.
- Places added during the event.
- Very large events are prepared. Beyond a few thousand participants, give advance notice, with the date and the start and end times. A team tests the setup, and a dedicated server can be put in place.
The venue Wi-Fi
A consumer router often accepts only ten or twenty connections: for a whole room, you need a network built for it.
- Mobile data first. Participants play on their own data plan rather than the venue's Wi-Fi: no network to join, no password, and a mobile network that is often better sized than a room's Wi-Fi.
- A light page. The participant's page loads once, in a handful of seconds even on 3G. After that, each answer weighs only a few kilobytes.
- If Wi-Fi is the only option, you need a professional network, with several access points for a large room, and preferably the main network rather than the guest network.
- Bandwidth estimated from the audience. The bandwidth the room needs depends on the number of participants expected, and is measured on site with a speed test.
- The host's computer kept apart. It does not share the participants' Wi-Fi: network cable, or failing that a separate mobile hotspot.
- A backup connection for the host: 4G dongle, or tethering from a phone.
The corporate network
In a company, a school or a convention center, the network sometimes filters certain connections: the page opens, but the exchanges do not get through. This is settled beforehand, with the IT department.
- A clear list of what to allow, to pass on to the IT department: the service's addresses, the usual web ports, and the connections that stay open (WebSocket).
- A one-click connection test, which tells you whether the browser and the network get through.
- A fallback when the persistent connection is blocked. The game carries on, with a slight delay, instead of stopping.
- A separate address for participants, short and easy to allow, distinct from the host's.
- Mobile data as an alternative. When the venue's network blocks, try 4G.
- A security message that prevents the page from opening can come from a VPN, a firewall or a company-managed device: ask the IT department to allow the service's address, or switch to mobile data.
Join the event
When a participant cannot join, a few causes come up again and again: an expired code, a session not yet open, a phone that is too old, or a network that filters.
- Nothing to install. People join from the phone's browser, by scanning a QR code or typing a code at a short address.
- QR code, code and address stay on screen throughout sign-up, and you can leave them visible for latecomers. An instructions screen comes back with one key.
- One code per session. The code or QR code from an earlier session, or an old screenshot, opens nothing. Share the one for the current session, and ask people to type it exactly as displayed.
- The session must be open. Until the host has started it, nobody can get in: open it before displaying the code.
- Restricted access. Entry can be limited to identified people: those who have not completed the verification do not get in.
- Old phones. A recent browser is required. Very old phones or uncommon brands may not keep up: have a loan device ready.
- Latecomers. A participant who arrives after the start joins the game in progress and lands on the current question. The host can lock entry.
When a phone disconnects
A screen that locks, another app opened, a brief network drop: a phone can disconnect mid-game. Here is what comes back on its own, and what needs planning.
- Automatic reconnection. When the participant returns to the page, after sleep mode, an app switch or a brief Wi-Fi drop, the link restores itself and they rejoin the game where it now stands.
- The participant is recognized. Their browser keeps their nickname, avatar and answers, for a few hours or a few days depending on the tool, and they get their score back.
- What loses the identity. Another browser, another device, private browsing or a cleared cache: the participant starts over as a new one. To come back from another device, they identify themselves again by email or phone number, or rejoin their team with the host's approval.
- No duplicates. When a page is reloaded, the participant chooses between continuing and starting from scratch, and the host can remove a duplicate.
- A team's score can be weighted so that disconnected members do not drag it down.
- The participant knows where they stand. A warning appears on their phone when the connection is slow, and a message warns anyone who answers too late.
- The host sees the state of the link: reconnecting, unstable connection.
- Sleep mode. Browsers put inactive tabs to sleep: the advice is to reload the page shortly before the start. An installed app can keep the screen awake during the game.
- On the host's side. If their computer restarts or loses the connection, the game resumes where it stopped, and the display carries on. A backup computer can take over.
Who keeps the clock?
Tools set the clock and measure response time in several ways. Here is what you will find.
- A timer per question, adjustable, or none when the game is meant for discussion. The countdown appears on the phone as on the big screen, and can be hidden.
- A single clock is authoritative, the server's: it sets the end time and rejects whatever arrives after. The phone measures its offset from the server and corrects its countdown.
- Time to read. The question appears, then the answers open after a short delay, or when the host opens them.
- Speed in the points. The calculation is a choice: points that decrease over time, a bonus for the fastest, points by order of arrival, speed used only to break ties, or no speed at all.
- A late answer is rejected, with a message to the participant. An adjustable extra delay can also be granted to make up for a slow network or a video lag.
- A pause. The host stops the countdown, and the phones display that the game is paused.
- Remote play. When the game runs over a video call or live video, where the picture arrives several seconds late, the opening of questions can be delayed by a few seconds to let the picture catch up.
When are the buttons active?
In a synchronized game, the host moves the questions forward, and the phone displays each step.
- One question, several steps. Waiting, before opening (time to read), answers open, answers closed, then the reveal of the correct answer and the leaderboard. The host triggers each step, and the phone displays it.
- The phone follows the host. It moves to the current question on its own, with nothing for the participant to click.
- Answers can stay hidden until the question opens: the phone displays the question without the buttons, or only shapes and colors, with the question staying on the big screen. The display is chosen for each game.
- The correct answer only arrives at the reveal. It is not sent to the phone in advance, where a participant could read it by inspecting the page data.
- Closing. When time runs out, as soon as everyone has answered, or by hand: the host closes the answers, and can reopen them. Once closed, the question accepts no more answers, and a message warns those who answer too late.
- A waiting screen between two questions.
- The result on the phone. After the question, each participant sees whether they were right, their position or the leaderboard.
- Going back to a question already played restarts the timer, but only those who had not answered it yet can answer.
Schedule a game in advance
A game can start and run without the host being there at the start.
- A scheduled start. Choose the date and time, and the game starts on its own. A daily or monthly series is prepared ahead, a late game is scheduled in the afternoon, and several time zones are handled without logging back in to launch each game.
- A scheduled end. You can set a duration, after which the game ends on its own.
- A start countdown. It begins at the scheduled time: to start at 8 pm with a fifteen-minute countdown, schedule 7:45 pm. The time chosen is in the host's time zone.
- Automatic sequencing. Questions and screens follow one another with no host, the game can loop all day, and a participant who arrives joins the current question. This is the mode for trade shows, bars and stands.
Without the venue network, or without internet
If the venue's Wi-Fi is unreliable, several solutions let you do without it, or do without internet.
- A local network brought by the organizer. A small Wi-Fi router is connected to the host's computer, by cable and not over Wi-Fi. Participants connect to it, with no internet. Ask them to turn off mobile data, forget other Wi-Fi networks and stay within range of the router. In this mode, a dedicated app is required on the phones, and the number of participants depends on the Wi-Fi hardware: one access point for about fifty participants.
- Radio keypads. Wireless buttons talk to a USB receiver plugged into the computer, with no Wi-Fi, over about a hundred meters. They use the same frequency band as Wi-Fi and change channel automatically to avoid conflicts. They can be mixed with phones, provided you avoid the question types reserved for phones (letter, digit, text).
- Answering by SMS. The participant sends the event code to a number displayed on screen, then answers certain questions by SMS. This is a paid option, off by default.
- A device-free mode. The host reads the question, participants answer with colored cards, gestures or slates, and the host clicks the chosen answer. The group's score is counted, not each person's.
- Games downloaded in advance. Without internet, games that do not need phones run from the host's computer. Teams answer out loud and the host keeps score.
- A fallback with no interactivity. Paper answer sheets with a rule for extending the time in case of failure, or a PDF export of the key slides.
Nicknames, duplicates and cheating
With a phone in every hand, a few precautions keep inappropriate nicknames off the big screen, and prevent duplicate votes and answers looked up online.
- Nicknames. A generator assigns a random nickname (an adjective and an animal, three tries allowed), a filter replaces inappropriate words, and the host removes a participant in one click from the lobby, or hides a name in the leaderboard.
- One vote per device. The browser is recognized, with no account to create: a device that has voted cannot vote again, and the reloaded page says “already voted”.
- Moderated audience questions. They go through a review before appearing on screen, ideally by a second person while the host presents.
- Cheating by searching online. One possible answer is a short timer (ten to fifteen seconds) with points that decrease: time spent searching costs points. Monitoring page exits was requested by one host, and judged excessive by the vendor, since a participant can leave the page for a legitimate reason, such as a message or a call.
When everyone arrives at once
At very large events, tens of thousands of participants can arrive within a few seconds, and the server has to absorb that peak.
- Identical requests are grouped so they are sent only once.
- Counters are lightened. The number of people connected is not sent at each arrival, but in limited bursts once the room exceeds about thirty people.
- The leaderboard is loaded when it comes on screen, not updated continuously.
- Audience questions are loaded in batches, a hundred at a time.
Prepare for the day
Before the event
- Test with the same screen and the same connection as on the day, and join yourself as a participant to see what they see.
- Run the connection test, which checks the browser and the network.
- Ask the venue how many devices its Wi-Fi supports, and whether it filters certain connections.
- Measure the speed on site, where the participants will be seated.
- Rehearse from start to finish, with the transitions and the lines to cover an incident.
- Plan for a second person, who watches the audience questions, or follows the game as a remote participant. For a remote game, they listen to the feed and run the console.
- Have a plan B: paper, PDF, backup connection.
- Do a final run with the vendor's team before the event, sometimes free of charge.
On the day
- Display how to join, and allow time: in a large room, connecting takes longer than you think.
- Repeat the address to type, rather than leaving people to look it up in a search engine.
- Recommend mobile data to participants.
- Let the answers build up before moving on.
- If something seems stuck, reload the page. This fixes most problems without affecting answers already sent. If the Wi-Fi is down completely, switch to plan B and tell the room you are fixing the problem, instead of going quiet.