A group poll shows three films and a Vote button. At the deadline, two candidates have the same score, one participant has never responded, and another has submitted twice after a network timeout. The interface has collected clicks, but its decision is still ambiguous.
This is a conceptual product design for a small private movie-night group. It proposes approval voting: each participant can mark any eligible candidate as acceptable. It is not a feature currently implemented in our store.
Separate eligibility from preference
Before opening the poll, create a reviewed candidate set that meets the group's practical requirements: available time, playback access, and agreed content boundaries. A vote should not be used to override an accessibility requirement.
Keep personal reasons out of the shared candidate data. If the application supports private boundary checks, define who can see those inputs and retain only what the product needs. The shared poll can explain that a candidate is ineligible without identifying whose private information caused that decision.
Freeze the candidates when voting opens
Give the poll, its participants, and each candidate stable IDs. Snapshot the eligible candidate IDs, deadline, voting method, and tie rule when opening the poll. Film titles are display text, not identities.
If the organizer needs to change the candidate set, create a new revision and explicitly reopen voting under that revision. Do not quietly insert a fourth candidate into a poll whose early voters saw only three choices. Previously submitted ballots need a clear review or replacement path.
Treat a ballot as one participant's current answer
Enforce one current ballot per poll revision and participant. A ballot can contain several approved candidate IDs because this design uses approval voting. Validate that every selected ID belongs to the frozen candidate set.
Accept an explicit empty ballot as “none of these works for me.” Distinguish it from an absent ballot and from “no preference.” In this model, no preference is a separate response with no scoring contribution, not approval of every candidate.
That distinction makes the tally understandable: a missing answer is unknown, while an empty ballot is an actual response. Neither should become an automatic positive vote.
Make resubmission predictable
While the poll is open, a participant can replace their answer. Store the ballot as a complete selection, rather than incrementing counters every time the client sends a request. A retry after a lost response should return the established result for that submission identity.
Check authorization and poll state on the server. OWASP's Authorization Cheat Sheet recommends checking permissions on every request. A visible Vote button is not an authorization boundary, and disabling it after the deadline is not sufficient enforcement.
If two devices edit the same ballot, use an expected version or another declared conflict policy. Do not silently combine their candidate selections unless merging is explicitly the product's behavior.
Define the deadline using server state
Persist a closing instant and render it in the participant's local time with a clear timezone context. The server decides whether a submission is admitted, using a documented rule about when the request is accepted. A device clock should not extend the deadline.
Closing the poll must produce a consistent result from the ballots admitted under that rule. Coordinate closing with ballot writes so a request cannot be counted halfway through the finalization process. Late requests should receive a closed-poll response and the confirmed result.
For this design, no quorum is required. Show the number of submitted responses, no-preference responses, and missing responses so the result does not imply that everyone participated.
Persist the tie rule and the result
Suppose the group agrees that the organizer chooses among candidates tied for the highest positive approval count. Store that rule before voting opens. If the count is tied, finalize to “awaiting tie decision” rather than displaying the first database row as the winner.
Record the organizer's final choice and who is authorized to make it. If every candidate has zero approvals, use a separate “no acceptable result” state and propose a new shortlist. Do not invoke a tie-break to manufacture enthusiasm that the ballots did not express.
A completed result references the candidate ID, poll revision, and tally snapshot. Reloading the page should display that saved result, not recalculate a different winner from later edits.
Review the cases that change the meaning
Check a duplicate submission, ballot replacement, an empty ballot, no preference, an unanswered invitation, a same-score result, a zero-approval result, a candidate revision, and a request arriving during closure. Verify the displayed explanation as well as the stored counts.
Our DVDWholesaleShop catalog supplies the movie-selection context for this hypothetical design. The broader lesson is that a poll needs explicit rules for participation, closure, and unresolved outcomes. Counting selections is only one part of producing a decision people can understand.
Top comments (0)