Decision Wheel

The Decision Wheel randomly selects one option from a list and turns a small choice into a visible, shared process. Common contexts include classrooms, team activities, choosing food, presentation order, lightweight giveaways, brainstorming, and situations where several options are roughly acceptable. Its value is reducing decision fatigue and making the selection feel transparent. It should not replace judgment when options carry different risks, costs, fairness concerns, or responsibilities. For serious drawings, participant lists, weighting, exclusions, and record-keeping should be defined before spinning so the outcome remains explainable. The wheel is best for low-stakes decisions where randomness is acceptable and everyone understands the rules.

The wheel is a Canvas 2D drawing layered with a deterministic random pick. Each slice is rendered with ctx.beginPath(); ctx.moveTo(cx, cy); ctx.arc(cx, cy, r, startAngle, endAngle); ctx.fill() where N equal options take an arc of 2π/N radians each — fifteen slices is therefore 24° of arc apiece, which is also why the input is capped at 15 to keep labels readable. The winning slice is decided BEFORE the animation: a 32-bit unsigned integer is drawn with crypto.getRandomValues(new Uint32Array(1))[0], reduced modulo N, and that integer is the answer. The animation then computes a target rotation of fullSpins × 2π + (2π − winnerIndex × sliceAngle − sliceAngle/2) so the pointer at the top of the canvas ends up aimed at the centre of the chosen slice, and tweens to it inside requestAnimationFrame using an easing curve such as easeOutCubic, f(t) = 1 − (1−t)³, or easeOutBack for the small overshoot that mimics a physical wheel slowing down. crypto.getRandomValues is the Web Crypto CSPRNG (specified in the Web Crypto API), seeded from the OS entropy pool, so unlike Math.random the pick cannot be predicted by reading the page's state. Weighted variants build a cumulative-probability array of length N and binary-search the random draw across it in O(log N). Outputs are entirely visual and ephemeral — nothing is logged, so any audit trail (timestamp, option list, screenshot) must be captured externally before the page is refreshed.

• Canvas rendering: each slice is ctx.arc(cx, cy, r, startAngle, endAngle) with sliceAngle = 2π / N — 15 options gives 24° per slice, which is the practical readability ceiling
• Winner selection uses crypto.getRandomValues(new Uint32Array(1))[0] % N — Web Crypto CSPRNG, seeded from OS entropy, suitable for fair single-shot draws but NOT for replayable lotteries (no audit trail)
• Animation runs in requestAnimationFrame at the display refresh rate (typically 60 Hz) with easeOutCubic f(t) = 1 − (1−t)³ or easeOutBack for a slight overshoot — the curve is cosmetic, the winner is already chosen
• Final rotation is targetRotation = fullSpins × 2π + (2π − winnerIndex × sliceAngle − sliceAngle/2) so the top-pointer lands on the slice centre, not its edge
• Weighted-options mode builds a prefix-sum array of weights and uses binary search to map a uniform random number to a slice in O(log N) — equivalent to inverse-CDF sampling
• Modulo bias is negligible when N ≤ 15 and the draw is 2³² values wide (bias ≈ N / (2 × 2³²) ≈ 1.7×10⁻⁹), so no rejection-sampling loop is needed
• Each spin is i.i.d. — consecutive spins can repeat the same option and that is correct uniform behaviour, not a bug; deduplication across spins requires an external record