Same Reporting Senior, Different Non-Contiguous Times

[twgardner2]

I showed the website to some people in my new command. One guy put his PSR in it and revealed a bug with an edge case I'd never considered before:

He had the same Reporting Senior at two different commands, separated by one command. The block for this Reporting Senior spanned from the first FITREP to the last FITREP he ever wrote on this guy, with a block for the intervening command's Reporting Senior superimposed over it. Once he told me about having the same RS twice, it made sense to me that the app would do what it was doing, but we need to fix that.

Reproduced with the sample data:

[ChaseWPDEV]

Interesting... Currently, this is kinda a "feature" in the app is that it creates this spanning block when there are unlikely repeats -- often times it's a problem of the reporting command's name being spelled slightly different between two fitreps, Or a space ommited in the RS's name. The spanning block serves as a visual indicator that there's weird data, that needs to be editted in the table.

In the case of this edge case, the no code solution would be to sightly tweak the reporting senior's name in the second instance (e.g. add a tilda or something to the second instance). It chafes though, because we have to have the user hack around good data in a weird edge case.

The trade off is that, if we fix the bug, we'll loose that visual indicator of bad data that needs to be tweaked. (Which based on our sample size of 3 PSRs, is a very frequent occurrence)

I think instructional videos are definitely in our future, as this becomes more feature rich and complex -- would this visual "spanning bars" be something we want to address in that format?

[twgardner2]

Yeah, I know what you mean about the weird spanning blocks, but I've never felt comfortable that actual users would view it as a feature rather than a bug. I think most people are already skeptical that this thing will actually work, then they upload their PSR and see a jumbled mess at the top and start to write the site off.

I think videos are a good idea, but, as I'm experiencing right now myself with eNAVFIT, I'm the kind of person who really just wants the app I'm using to make intuitive sense and has a natural aversion to clicking on and sitting through a video just to do something I think should be self-evident. That's not to say we shouldn't make videos eventually; I think a lot of people do want to watch a video to learn the app.

So I guess I'm of the opinion that the command and RS blocks should never overlap (fully admitting that they do so because of the logic I wrote :laughing:). Maybe I'll find some time to fix this sometime soon.

I don't think this would be necessarily easy, but what about a "validation report" that would appear after the initial PSR parsing and flag anything that we can tease out as a potential flaw in the underlying PSR data. We could maybe use Levenshtein distance to identify commands/RS who are very close to being the same, but aren't exact, prompting the user to check if they should be.

Long-term, I'd also like to improve the UI of the table below the viz. Right now it's clunky and sucks, especially with the dimensions changing when you go into edit mode, making the whole thing jump around. I actually think I have a local branch where I was trying to fix that, but didn't have the time to complete the job.

It would be really nice if there was a way to quickly associate commands and RS, telling the app to make them all the same, without touching the keyboard. Like some kind of click and drag type of operation.

What do you think?

[ChaseWPDEV]

I don't think this would be necessarily easy, but what about a "validation report" that would appear after the initial PSR parsing

Yes. This is the right answer. We'll probably need a modal popup that presents some sort of summary, and allows the users to "merge" RS/Command combos that are slightly different but should be the same.