New report parameters may require a rethinking of the reports page UI

[tw4l]

(Text copied from original discussion here)

Given that we seem to be moving toward a future application state where we have a handful of reports, each of which may have a variable number of available report types (e.g. print table, CSV, pie chart, scatter plot, time series) and parameters (e.g. start date, end date, file type, file format, PUID), we may eventually need to rethink our current reports selection UI, which currently looks like this:

One way to move forward might be a more reactive UI that lists a number of reports, and then allows the user to specify further refinements after one is selected (e.g. in a modal, as an in-between step to generating a report), based on what that particular selected report supports.

I played around with one example of what that could look like with a very simple and rough-around-the-edges Vue app embedded in a Flask template:

Demo code repo on GitHub (again, just for demo, lots of rough edges here): https://github.com/tw4l/aipscan-reports-ui-demo

Definitely not the only way to approach it, but I think one potential solution for down the road. The main benefit being that ultimately down this path, you can have the UI be responsive to the data it's being passed - e.g. displaying different report types and parameters in the modal depending on the underlying data about each report.

My experience with Vue is that it's a joy to work with, well documented, and more stable than most popular JS frameworks (e.g. Vue 3, the most recent release, keeps backwards-compatibility with Vue 2). But using it in AIPscan would introduce new dependencies and tooling and potentially a frontend build step (the demo doesn't need one and one of the nice things about Vue is that you can sort of sprinkle it here and there into otherwise server-rendered apps, but further complexity might warrant it at some point), so is not trivial and would need to be discussed and prioritized accordingly. Even if we found a different path forward with our current approach of server-rendered code with a bit of jQuery on top, it would likely be wise to invest into user stories, wireframes, and some collective brainstorming and refinement before embarking in a new direction.

[tw4l]

Closing because it seems that for now, our static Flask template will do