Run a random wheel presentation with countdowns, mystery labels, themes, and sound

Step 1

Separate the selection rule from the presentation layer

Write down what the wheel is allowed to decide before choosing a palette or sound. The eligible entries, enabled states, weights, winner count, replacement rule, and acceptance policy define the selection. Theme, spin duration, countdown, labels, confetti, and audio explain or dramatize that selection; they do not add eligibility and must not create a second draw.

Random Wheel Tools secures the winner before an optional three-second countdown begins. The animation and procedural sound follow that stored outcome. Canceling during the countdown discards the pending presentation without adding history, changing scores, eliminating an entry, or selecting again. This distinction lets an operator stop a mistimed cue without quietly substituting a different winner.

Step 2

Choose a readable theme and label strategy for the actual room

Select one of the twelve palettes for contrast with the room display, stream composition, or projected background—not merely for decoration. Test it on the least favorable screen in the workflow. A bright projector, compressed video call, or small embedded player can erase subtle color differences. Keep the result label as the authoritative output and repeat it aloud; color should never be the only carrier of meaning.

The adaptive label option displays every label on ordinary wheels up to eighty entries. Above eighty, it renders an evenly distributed sample of at most eighty labels so the browser does not create hundreds of tiny text nodes. Every one of the maximum 1,000 validated entries still contributes its segment and remains eligible. Balanced and sparse modes show sixteen and eight representative labels respectively, which is often clearer for a distant audience.

Shorten public-facing labels before the session and distinguish duplicates with a safe qualifier such as team, seat, or ticket alias. Do not rely on hover titles, an editor panel, or a private roster being visible to the audience. A result should be understandable when read from the dialog, spoken by the host, or copied into the event record.

Step 3

Use mystery labels only when concealment fits the activity

Mystery mode replaces disc labels with numbered placeholders while retaining the real labels in the local wheel model. It is useful when a prompt reveal is part of a game, when choices should not bias volunteers before selection, or when a projected disc would otherwise expose a planned sequence. The exact selected label still appears in the result dialog and history because a result that never becomes identifiable cannot be accepted or recorded.

Mystery mode is not a privacy boundary. The entries remain in the page, local browser workspace, full JSON exports, and any eligible share fragment. An operator, browser extension, screen reader in the editing view, or anyone who receives the full share URL may access them. Do not load secrets, contact details, student records, or unreleased project names and assume numbered segments have redacted them.

Tell the audience what kind of items are hidden and when the reveal becomes official. If participants need to review eligibility, do that before enabling mystery mode or provide an approved list through another channel. Surprise should concern which eligible item appears, not whether the host inserted an unknown or unsafe option.

Step 4

Coordinate countdown and sound as accessible cues

Enable the three-second countdown when the room needs a shared start cue. It announces 3, 2, 1 through the live status region, displays a large visual number, and locks conflicting editing controls. The visible Cancel countdown action remains keyboard reachable and stops the pending action without altering entries, history, scores, modes, or settings. Use it for a premature click, a missing participant, or an interrupted broadcast cue—not for shopping among outcomes.

Choose among five short procedural sound packs: clear chime, bright bell, arcade, fanfare, or soft cue. They are generated locally with Web Audio and do not fetch recordings or send wheel data. Test browser permission, output routing, meeting echo cancellation, OBS capture, and room volume before the session. If audio initialization or playback fails, the accepted result remains in the dialog and history and the page reports that only the sound failed.

Pair every sound with a visual result and a spoken announcement. Some participants will have muted audio, hearing differences, or a delayed stream; others may prefer reduced motion or a quieter cue. Do not make the ability to hear a tone a condition for knowing who or what was selected.

Step 5

Prepare large lists and multi-wheel sessions without hidden loss

A local or imported wheel accepts exactly 1,000 non-empty rows; row 1,001 is reported rather than silently discarded. A workspace can contain four independent wheels. The complete workspace JSON is bounded at 3,100,000 characters and imported JSON files at 9.3 MB, which covers the tested escape-dense four-wheel maximum with headroom. Check both active and total counts after TXT, CSV, or JSON import, then search for the final expected row.

Share links intentionally remain smaller: no more than 200 entries per wheel and a 30,000-character fragment. They omit history, scores, and local images. Export a validated workspace JSON for a larger setup, move it through an approved channel, and import it in the presentation browser before rehearsal. A file or fragment containing participant labels should still be treated as sensitive even though the site does not upload it.

For several stages, name each wheel after its role and decide whether Spin all is logically valid. Presenter, topic, room, and time slot may depend on one another; simultaneously combining them can create an invalid assignment. Use Spin all only when every possible combination is acceptable, and state the order in which the host will read the results.

Step 6

Separate the local audience and preserve mixed image entries

In Host and audience, choose 16:9, 4:3, or square and open the audience window from the host. It is read-only, shows the current wheel and the same accepted result, and never runs its own random draw. Keep both windows on the same device and browser. Refreshing the audience requests current state without drawing again; after the host closes or reloads, reopen the audience from it. Use OBS Window Capture for this window, not a Browser Source expecting another browser profile's data.

The primary roster can mix text-only entries and local entry thumbnails. Keep a text name for every participant, including image entries. JPEG, PNG, and WebP inputs are limited to 8 MB and 24 megapixels, then re-encoded as static WebP thumbnails no larger than 256 by 256 pixels and 80 KB. All entry pictures, center logos, and backgrounds together share a 1.1 MB workspace budget. These are decimal byte units; adding pictures does not increase the 1,000-entry limit. A failed or stale conversion leaves the original entry intact.

Images are keyed to participant identity, not the displayed name. Use the roster editor for renaming, and save full workspace JSON for image backup or transfer. URL shares omit all pictures, and local templates omit them too; both keep text entries. Reopen the exported JSON during rehearsal to verify names, thumbnails, weights, enabled states, and scores before relying on it. Local processing is not a license to publish someone's photo: obtain permission for any picture that will reach the audience.

Embedding the primary wheel in another page creates an isolated temporary workspace from the start, without reading or overwriting a saved local workspace. A parent page can request control, but only explicit approval of its exact origin grants a short-lived session. Do not authorize an unfamiliar parent. Export JSON before closing if you need that session's list later; it is not automatically saved to your normal workspace.

Step 7

Rehearse the complete cue, cancellation, result, and recovery path

Build a rehearsal workspace with unmistakably fictional labels. Test keyboard-only operation, fullscreen entry and exit, focus after countdown cancellation, result-dialog close actions, mystery reveal, sound on and off, reduced motion, a 320-pixel viewport, and the actual projector or capture crop. For a 1,000-entry list, confirm 1,000/1,000, the final imported row, an eighty-label adaptive disc, and a result from the approved population.

Practice three failures: audio is blocked, the display or source refreshes, and the operator starts the countdown too early. An audio failure keeps the result; read it aloud and continue. A premature countdown can be canceled without a draw record. A lost workspace should be restored from the tested JSON backup, then checked against the frozen list before any official selection.

During the live run, one operator should control the wheel and one verifier should confirm the list or result when the stakes justify it. Record accepted outputs and declared exceptions, not a collection of exploratory spins. Afterward, export only the record you need, remove participant data from shared devices, and retain backups according to the event's privacy policy.