Update UI with pleasant UX for manual entry of model parameters versus published model parameters

ashokkrish commented 2 months ago

Selecting Manual Entry would ask the user to input the numbers. All fields would be validated. Once all the validation passes the mainPanel() prints the results.

Selecting Published Model Parameters would come up with a dropdown menu for all rows filtered by the chosen model from the spreadsheet.

bryce-carson commented 2 months ago

@ashokkrish I quickly made these mockups in Penpot. Do you think this would be more intuitive than a radio button and a second drop-down?

I think the following flow is reasonable:

Select a compartmental model type (e.g. SEIRS)
If desired, select an alternative default source of parameters from the literature using the drop-down box, or search for an author or DOI using the search field. Both of these would offer results from the spreadsheet we've been working on.
- The underlined default selection, Ashok et al. 2024 JOSS, is representative of the set of default parameters used based on your own knowledge of epidemiology and the literature; these parameters could be published in a table in an article in JOSS, a "developer-friendly" journal often used to publish articles about new open-source software used in the scientific community, such as scientific R packages and Python libraries. This would also help to raise awareness of the application among the epidemiology community, as many people subscribe to RSS feeds from such journals.

State	Mockup
On initial load
After selected SEIRS

bryce-carson commented 1 month ago

[ ] shinyWidgets::pickerInput with live-search option TRUE

  pickerInput(
     inputId = "Id084",
     label = "Live search", 
      choices = attr(UScitiesD, "Labels"),
     options = list(
        `live-search` = TRUE)
  )

[ ] Grouped pickerInput with Ashok and Literature groups

bryce-carson commented 1 month ago

Situation

@ashokkrish, @kle6951, @Toby-exe, please see the previous comment. That's a design that will work well with the current scaffolding we have.

What we need are user-visible names, like 'SEIR:Ashok' or 'SEIR:Ma and Li (2009a)'. To be clear, please don't preprend the model type to every "readable name." That'd be unreadable. We will be using a grouped picker input, so there will be groups underneath which the readable model name will be available.

Example format one

Krishnamurthy Lab defaults
- SIR
- SIRS
- SIRD
- SEIR
- SEIRS
- SEIRD
Literature
- SIR: Example.org et al. (666 A.D. b)
- SIRS: Ma and Li (2009a)
- et cetera

Example format two

[Select grouping] SIR
- Application default
- Ma and Li (2009a)
[Select grouping] SIRS
- Hiornes and Cooke (1981)
[Select grouping] SEIR
- etc.

Situation cont'd

In either case, live searching should work on both the user-visible names and their category. Searching for "SEIRS" should show all the SEIRS models from the literature as well as the application default.

For this to work the pipeline inside the defaults reactive will need to be edited to filter for only the application defaults. The reactive currently filters the defaultInputValues dataframe; that should be renamed once literature is integrated into it, because it will contain more than just defaults; inputValues is appropriate.

A consequence of providing the literature parameter values is there will no longer be default parameters (no more defaults() reactive!; it would be obsoleted) for a given model type. The 'Ashok' or app defaults for SEIRS are only that, the values for the 'Ashok app SEIRS' model. Ma and Li's SEIRS parameters are just as valid. This will have consequences that you'll need to be careful about which span the breadth of the application's functionality. The defaults() reactive is consumed in several important places, like the reset functionality (which will need to reset input values to the values not for just a model type, but for the currently selected model instead. Not too different.

I have confidence that if @kle6951 and @Toby-exe spend a couple hours reviewing the server functionality and discuss the issue that they should be able to implement the literature feature before your conference, @ashokkrish. There might not be many examples in it, but there'd be a couple and the feature would be present. The only necessary going forward would be to just edit the spreadsheet on Google docs and then download it and overwrite the repository copy. At that point, it may even make sense to switch to using the googlesheets4 package; but only then.

The list of options for the model selection would be populated directly from the dataframe read in from the spreadsheet. This also has consequences throughout the application, but with the re-engineering work I did it should be very workable to find where those locations are and modify them easily enough.

bryce-carson commented 1 month ago

https://shiny.posit.co/r/gallery/widgets/option-groups-for-selectize-input/

Please see this example shiny app

bryce-carson commented 1 month ago

Related to #49

bryce-carson commented 1 month ago

An important thing to understand is that afterwards, you must update the radio buttons and the checkbox according to the modelSelect dropdown. At the moment, changing model has no effect on those widgets; afterwards changing a model will set those widgets to the default for that model, which are alongside all the other widget defaults in the spreadsheet.

bryce-carson commented 1 month ago

I think, going forward, the plan should be to use the first format until there is an overwhelming amount of options, then we should use the second format.

ashokkrish / episim