twgardner2 / navy_psr Goto Github PK

Starting work on this.

...so no other elements have a higher z-index and interfere with hover over behavior

The table doesn't handle ampersands well.

Reproducible example:

• Edit a command name, adding text that includes an &
• Save the row
• Re-edit the row
• Notice that it now displays the character reference for & (i.e. &)

Should show the dates of the gap, at a minimum

Make 3 categories: Regular, IDT, AT

Allow Reporting senior to compare multiple Fitreps at once.

Hovering over the text in the bars is interfering with the hover behavior.

Add filters to reduce the number of FITREPs rendered. Something like:

• Deselect ranks
• Set the timeframe to show
• Define how many years back from the end of the PSR to display

Port into Electron App (as a submodule) to allow individuals to download and run locally.

While effectively the exact same thing as running in a web browser, it might make people feel warmer and fuzzier about using (rather than in their web browser)

Maybe use ellipses?

I got this feedback from multiple people this weekend. The table was always intended to be the bridge between how people are currently used to looking at PSRs and my new way of doing it. I just never took the time to make the table look exactly like a PSR because it's not going to be fun.

Thoughts?

Right now it looks like the system is set to flag concurrent reports as "AT Commands." Is this the correct nomenclature? There are several situations where AD receive concurrent reports.

• On hover, the darker background doesn't extend all the way down on the first two nav bar items
• I originally didn't intend for the "contact us" nav bar item to have onhover styling, since it's not actually a link to anything

Idea: Page starts off with something like "PSR - Example PSR" across the top. After parsing a PSR, this changes to "PSR - Thomas W. Gardner, II"

Web app size is currently 1.64 MiB.

• Look into code splitting with webpack's import statement to reduce size/load time.
• Examine if this would break the Electron App implementation

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:

• Show edited fields shaded
• Make edited fields revertable to the original

PSRreport_Redacted.pdf

Possibilities:

• Fade them out a little bit, since they typically don't matter much
• If it's a 1 of 1 and not an EP, draw attention to it somehow

Try to pick a natural break point, rather than just dividing into two

"Your example depicts about 15 years of service.  I think that is likely about the maximum length of a single timeline for readability in a tank.  To account for 30+ YOCS, could the timeline be “continued” as a second timeline below the top timeline, i.e., “stacked” so as to display on a single monitor/projectors screen (in a tank.)  Perhaps utilizing a triggering “event” to break/wrap the timeline (other than a set number of years or a set paygrade change) might be preferred – like 13.5 to 16.5 YOCS that corresponds with a change in billet or change in reporting senior.  The latter wrap point would be beneficial when connecting stars, diamonds, etc.  In the case of over 30 YOCS, I think we could just delete O1 service, then O2 service, then start whittling away at O3 assignments from the visualization.  An officer’s performance while an O1, O2, O3 has (arguably) little bearing on whether a senior O6 or O7 selects to O7 or O8, respectively.  Plus, the PSR table entries are still there.  As an aside, I bet any PSR entries prior to ~1996 likely cannot be supported anyway.  I think that’s the year when the current the PSR version came into play."

How is this secure? No PDF information is transmitted to our server All PDF parsing occurs in your browser. If you're really curious, go ahead and open the network panel. You'll see nothing goes over the wire.

What if your site gets hacked? We don't receive or retain any visitor data on the site so there's nothing to steal.

What if someone's listening without you knowing? Check the SSL lock in your browser. If the lock's green, no external sources are loading and you can be sure it's our site. If it's not green, STOP, do not upload your PDF and contact us.

I really don't trust you, but I want a report. No problem it's just gonna be a little more work, you'll need to use the interactive table below and manually enter the data off your report. If you want to be really cagey, you can even use imaginary names for your Reporting Seniors (I recommend characters from Under Siege, but it's your choice).

Idea: Maybe we find a really nice module for tables.

Preferred features:

• We can make it look exactly like a PSR
• Non-janky editing
• Edited cells shaded to indicate they've been edited
• Make edited fields easily revertable to the original
• This one is asking a lot, but would be really cool: some form of the ability to draw the contents of a cell down to copy values, like in an Excel worksheet. This would be much easier than fixing a bunch of differently-spelled command names. If you could just drag one name down and apply it to all FITREPs from that command, it would be freaking awesome