Local roaming judges' storage

[timparenti]

Need from the field, S19:

Local to device, cleared manually. Provide a judge an interface to select which flags/glyphs they are placing during a setup round, and "lock" those. Then, a page with a simple text field for each so they can remember where things are placed.

Bonus points if all such values do make it to the server somehow and can be called upon by the head judge only.

[nwf]

I like it. It's probably straightforward to add another local Activity pane to the app. I suppose I imagine that it's got two combo-boxes, a text field, and a button, and a sorted list for display: "I am placing the [RED] [FLAG H] at [text] [OK]". Selecting an entry from the list brings it up into the edit fields.

As far as interacting with the server, I think we...

1. want the ability to set a username and password in the app for connecting to the MQTT broker.
2. want to define ctfws/judge/stuff/$TEAM/$THING topics, whose message contents are just UTF8 for humans. The app should put persistent messages to these topics, and should update its list of items to display as it gets messages about them.
3. want to go create some not-head-judge accounts on the broker and give these r/w access to ctfws/judge/# (and maybe ctfws/devc/#?) but not write access to ctfws/game/#?
4. want to create a script for the head judge that creates persistent messages ("unplaced") for all ctfws/judge/stuff/$TEAM/$THING in the current game and removes any that aren't.

There's a little unpleasantness in wanting to remove a stuff entry, but I think it's fair to say "hit reload" and let the app rebuild its list of things from scratch between games.

Maybe that's all a bit much. It's late and I shouldn't be designing anything right now.

[timparenti]

So… without regard to the actual architecture, some considerations if anything is sent to the server:

• How will it be done securely?
  • The main problem with "security" here, of course, is that any given judge for any given game may well be playing some other game that night, so how to keep judges-cum-players from snooping is difficult. More a protocol-level discussion, but perhaps each game has its own passcode somehow, which is only given to those who need it?
• Will the data be cleared each game, and if so, how?
  • End of game shouldn't clear this, since that's exactly when the data is most needed! Only start of next game should clear!
  • How to ensure data isn't accidentally cleared?
• How will the judge's device be identified? By ID, sure, but for the sake of head judges, should the form also prompt them to identify by name/handle?
• The client form should require as few explicit saves as possible, but rather save its data periodically upon changes.
• If we're not clearing data between each game (which is arguably safer), how will the head judge be able to easily tell which data is from this round, and which is stale?

Most importantly, this would be push only. It should not be possible for Android devices in the field to receive any of this data from the server; however, it should be expected that an Android device will retain the data it has submitted, at least until the start of the next setup phase.

Here's a rough client-side example I've thought up…

• Start round screen:
  • Compactly displays game number and a prominent setup countdown across the top
  • Two inputs:
    • Type/edit your name/handle (required, don't clear this between rounds)
    • Select which building you're roaming in (buttons presumably shaded based on the territory attribute)
• Once a territory is selected (assuming a name is specified), go to a Stuff-placing screen:
  • Still displays game number and a prominent setup countdown across the top
  • Small text, "$NAME is placing Stuff in $BUILDING", perhaps as a small banner below the timer which has background color matching the appropriate territory color (and thus the color of the Stuff they are placing)
  • Then, two columns:
    • On one side, two buttons with iconography: "🏴 Flag" and "⬛ Glyph" (emoji are merely representative of what should actually be icons)
    • On the other side, a "cart" of Stuff that has already been placed will accumulate.
• Upon selecting Flag or Glyph, a list appears below as appropriate:
  • For flags, buttons A through (X), based on the num_flags attribute
  • For glyphs, buttons for each glyph type (except probably Jail), possibly with iconography as well (match the ordering used in Stuff-counting on ctfws-timer-web)
• Upon selecting a specific flag or glyph, a text box appears and the user can enter free-form text. As soon as they do (either as they're typing, or by pressing the equivalent of "Enter"), text along the lines of "🏴E: $description" or "Recharge: $description" appears in the "cart" of Stuff that has been placed.
  • The "cart" should generally be sorted, flags first, in order, then glyphs, sorted by type in the same order as the buttons are presented.
  • It is permissible to place more than one of the same glyph type, and these can be completely independent.
  • Tapping on any existing "item" in the "cart" should immediately allow the user to edit what was previously entered.
  • While editing/entering, it should also remain possible to fix the identity of an item by tapping the Flag/Glyph buttons accordingly.

The head judges' side is more a ctfws-timer-web thing, if data is sent to the server. Since the idea is that individual roaming judge is the first person to go retrieve flags and glyphs, the client being able to review its own data between game end and next game setup is the most important. In the event that any further investigation is truly necessary, giving the head judge some sort of message tree sorted by item is likely sufficient. (The server shouldn't care whether two people said they placed flag X or no one says they placed flag Y, as there should be enough information to suss out a true-enough state of things in the worst case.)

Bonus points on this client side, though, if it can somehow securely tie into any future implementation of cmukgb/ctfws-timer-web#14, especially after the game has ended, so that the roaming judge who placed flags can know exactly which of the flags they placed need to be retrieved.

[timparenti]

I do think a locally-stored solution (to aid roaming judges' in their own memory) is significantly higher priority than any server-sync work proposed for cmukgb/ctfws-timer-host#2.

[timparenti]

FYI: At today's Rules Committee meeting, a proposal was discussed to codify precedent (not currently in the rules) that a flag-bearer may only have one flag at a time. It was pointed out that, should such a rule go into effect, this feature would be helpful for re-placing any invalidly-returned flags in the event that a player returns to Judges' Room with more than one flag.