investigate repeated NEWs when same team already has a NEW within continue time

[caver456]

Observed at Donner MRA mock 8-17-24, and probably reported many times before by others. This interfered with getting coordinates from a team, which didn't happen often at that session, so should be easy enough to track down). A NEW was already open for that team, with some typing in it, but each new call from that team (BOT and also EOT and/or GPS?) opened a new NEW on the stack which immediately stole focus. I wanted to put the coords with the already-existing NEW so this caused a train wreck.

First step is to check the log files around times of entering coordinates.

[caver456]

(Pretty sure there was no subject or clue dialog open at the time - the log file will tell the tale.)

[caver456]

Found the apparent smoking gun, from the first MRA mock session (radiolog_log_2024_08_17_091327.txt)

note that the entry in question that has typed coords, 1119, wasn't actually accepted until 112210

111946: BOT from 100:3137 (Medical 1)
111946: no other new entry tab for this team: calling openNewEntry
111949: EOT from 100:3137
111949: checking: matching tab with lastModAge=1; not opening a new one
111950: GPS-only from 100:3137
111950: checking: matching tab with lastModAge=0; not opening a new one
111954: BOT from 100:3137
111954: checking: matching tab with lastModAge=3; not opening a new one
112004: EOT from 100:3137
112004: checking: matching tab with lastModAge=-1; not opening a new one
112005: GPS-only from 100:3137
112005: checking: matching tab with lastModAge=-1; not opening a new one
112133: BOT from 100:3137
112133: checking: matching tab with lastModAge=86; 'no other new entry tab was found for this callsign'; calling openNewEntry
112137: EOT+GPS from 100:3137
112137: checking against 2 tabs: Medical 1 lastModAge=90; Medical 1 lastModAge=2; not opening a new one
112141: BOT from 100:3137
112141: checking against just 1 tab: Medical 1 lastModAge=94; 'no other new entry tab was found for this callsign'; calling openNewEntry
112151: EOT+GPS from 100:3137
112151: checking against 2 tabs: Medical 1 lastModAge=104; Medical 1 lastModAge=0; not opening a new one
112159: BOT from 100:3137
112159: checking against 2 tabs: Medical 1 lastModAge=112; Medical 1 lastModAge=7; not opening a new one
112201: EOT+GPS from 100:3137
112201: checking against 2 tabs: Medical 1 lastModAge=114; Medical 1 lastModAge=9; not opening a new one
112210: accepted: ['1119', 'FROM', 'Medical 1', 'vitals stable, still a&w, 31115 56144', '31113  56143', '', 1723918786.8062472, '100', '3137', '3919.4306|N|12019.1357|W']

Everything looks like it was basically behaving as designed. Problems started showing up with the first BOT after the continue time had elapsed on the existing tab, at 112133. This was a real problem for the operator - the real desire was for the verbalized 5x5 to go with the other 86-second-old new entry widget, but a new one popped up each time. Very frustrating and ended up doing copy-and-paste to get it into the right entry.

So - maybe what's needed is a rethinking of the continue-time concept. Has there been an occasion where a second new entry dialog for that team SHOULD happen? The easiest way to "disable" the continue-time concept would be to just crank the continue time way up high. Need to ponder.

[caver456]

Summary of the scenario that caused the problem:

IC requests update on patient condition, and coordinates. The condition update comes back quickly, and radio operator types it in right away, but, the coordinates take a while - longer than the continue time - while the recipient initially responds with "standby" or such, gets their phone out, etc etc. - complicated here by the fact that this was the medic which is non-ideal! The radio operator leaves the condition-update new entry widget open, with the expectation of typing the coordinates into the same message.

When the coordinates get called in to IC, continue time has elapsed, so a new entry widget gets opened - a new tab on the stack - and also takes focus since 'hold' time has elapsed too.

From here, it's hard to exactly recount the rapid-fire confusion. Probably something like this:

Radio operartor clicks on the elapsed tab, to try to type the coordinates there instead of in the new blank tab that stole focus. But, EOT and/or GPS on the current call, or even the BOT of the next call, and so on, steals focus again to the new blank tab... hold time should keep focus on the elapsed tab if typing had already restarted in the elapsed tab... so either hold time wasn't functioning as expected, or no typing had happened in the elapsed tab? Either way, the root issue is continue time.

[caver456]

Possible actions to mitigate all this:

1) get rid of the continue time concept, with no other changes 2) increase continue time by a lot, to effectively disable it 3) replace the continue time concept with a 'stale entry time' concept: for stale non-blank entries, prompt the user to either accept, cancel, or continue for another period of time (and possible make a note in the entry as such) 4) if BOT successfully opened a new entry widget, or prompted a check for existing new entry widget, then don't do so again on EOT or GPS - note, this should probably be done anyway, but might really help this issue

The main question is: what's the easiest and most intuitive for most radio operators? Obscure solutions that require obscure hotkeys or specific training are probably not ideal. The problems can arise in rapid-fire sequence, so, the solution needs to be extremely intuitive.

3) and 4) seem like the winners so far, even if 3) is a bit involved. In the case of 3), does this mean that continue time is effectively infinite, i.e. if there is any existing new entry tab from the same team, it should receive focus?

[caver456]

5. on incoming transmission, if an elapsed entry is still on the stack from the same team, prompt the operator with a quick simple question: continue the elapsed conversation, or save it and start a new conversation (or delete it and start a new conversation?) - this concept would also replace the continue-time concept

[caver456]

Currently thinking that option 2 is the right way to go. Try-and-see seems like the best option, so: make continueSec into a config file option, and default it to the current value of 20sec if not specified in the config file. Then NCSSAR can set it very high (3600 = 1 hour?) and see how it goes over time. Having a default means that other users that don't specify it in their config file won't be affected.

[caver456]

Additional mitigation: since the time of the saved log entry will be equal to the time that the new entry widget was first opened, but having a large continueSec enables a long time to pass between the opening of the widget and the finishing of the message: if the difference is more than a minute, add some automated text to the message pointing out that there was a delay (and how much).