Voting for chancellor buggy on slow connections

[kaylee42]

Describe the bug
When voting yes or no on the person selected as chancellor, the lag for slow connections (and perhaps also on the server side?) makes it difficult to all players to select at the same time. What we were seeing was because clicking a yes or no card TOGGLES your selection (ie, clicking an already selected yes card unselects yes but does not select no) but there is no loading indicator or debouncing, users would often unintentionally click the card multiple times, getting them into a state where 10-15 seconds after they thought they had made their selection it became unselected again, and sometimes if clicking happened too many times they wouldn't be able to figure out if they would ultimately end up in a selected or unselected state. In a game with 7 players all having the same problem, this resulted in us having to completely restart the game several times because we couldn't get to a point where everyone had entered their vote for the chancellor.

What does this issue relate to? Please put an X in the [ ] (i.e. turn [ ] into [X]) for the relevant choice.

• Gameplay
• User Interface
• Game Modes
• Mod Tools
• Replays
• Something Else: Please describe

To Reproduce
As far as I could tell this was likely largely due to server lag, but I was experiencing it every time I voted for chancellor. It's likely that throttling connection speed would also recreate the issue if server wasn't lagging.

Additional context
I haven't gotten into the code yet, but just based on what I was seeing I have a few potential suggestions on how this could be improved, and if there's one that's preferable to the maintenance team I'm happy to try and take a look through the code and fix sometime this week:

• Rather than making the two cards buttons, make them styled radio buttons and only fire the api request on a change event (clicking an already selected radio button will not change the value of the input, meaning to change your vote you could click the other card but clicking an already selected card wouldn't unselect it)
• Make the endpoint idempotent - basically a way of achieving the previous result with a server-side change rather than a client-side one, so that sending up a yes value can only set a yes, not toggle whether yes is selected or not
• Change the interface to require an affirmative submit, so the user selects a value but the value is not sent to the server until they click submit, after which there is no option to change your vote
• Implement loading indicators or disable card buttons until the API has returned so that you can't get into this delayed state (probably not ideal as a singular solution considering server lag, but could be a UX improvement anyway)

Please let me know if you need any additional information from me, and thank so much for your work on this game!

[stevenruidigao]

I think the reason it is toggling right now is because some players maybe want more time to decide, and if everyone votes before they can change their vote, they are stuck with the vote they had before.

[kaylee42]

Sure, I can understand why you might want to undo voting, but the issue is that with lag it becomes impossible to discern what state your vote is ultimately going to end up in, so that even if you wanted to undo your vote you could accidentally click too many times and wind up in a situation where you voted and didn't mean to, or a previous vote could register at the same time everyone else had completed voting and your final vote wouldn't be the one that's included. Wanting to "undo" an accidental click so you haven't voted yet could be accomplished with a separate button if it's that important; the issue now is that if you click more than once on any card and there's lag, it becomes impossible to figure out what the ultimate result of your action is going to be.

I also think there's an argument here to be made for a "confirm" button rather than just having clicking on a card mean you submit, so you do actually have to click twice to lock in your vote. This would also mean we're working with an actual <form /> proper for submitting data, which improves accessibility.

[cozuya]

Honestly can't disagree here, if this was like an actual good UI what would happen is there would be a UI state (loading) on click that didn't depend on the websocket emit etc etc. A PR would be great! But fixing the lag/single core issue that has plagued (heh) us in the last couple months should address this, hopefully in the next few days.

[jthemphill]

I see fairly long sleeps in the election code: https://github.com/cozuya/secret-hitler/blob/master/routes/socket/game/election.js#L655

If these are the issue, it looks like @kaylee42 may want to enable “experienced mode” for their next game. “experienced mode” has shorter sleeps, presumably because with shorter sleeps everyone has less time to lock in their decisions.

@cozuya : I feel like adding a “confirm” button would also allow people to think before they lock their choice in. How do you feel about removing these sleeps and using a "confirm" button instead?