Minor cosmetic changes to the dashboard

[shankari]

• [x] Change the "unconfirmed" table column header to "unlabeled"
• [x] Change the other table columns headers to also be meaningful (@shankari add meaningful values)
• [x] Larger font size for the variables in the data plot
• [x] make the display of the sign-in trend a configurable option that is passed in to the emdash::runapp function (similar to the current anon_locations)
• [x] the list of columns in the participant table would be configurable somewhere as an option
  • [x] for our particular use case, we will probably want to hide the first_XXX since we only care about the last_XXX

[shankari]

there can be a distinction between the people who deploy the dashboard and the people who use it.

In the CanBikeCO deployments, I deploy the dashboard, the program administrators use it. In the UNSW deployment, Amarin both deploys the dashboard and uses it

We are doing a long-term (2-year) data collection from a specific group of people Amarin is doing 1 week of data each but from way more people recruited via the internet

So there modules important to us that are not important to amarin and vice versa with configurable options, each of us can deploy the dashboard that is most suitable for our needs without having to change too much code And this is only going to be more true going forward.

[shankari]

Here are my suggestions for the non-code headers for the columns in the participant table. Feel free to replace them with more meaningful values if you can think of them

• user_id -> user id
• update_ts -> last profile update (hide by default for our deployment)
• client -> UI channel (hide by default for our deployment)
• client_app_version -> smartphone app version
• client_os_version -> android/iOS version
• curr_platform -> android/iOS
• manufacturer
• phone_lang -> language
• n_trips -> Total trips
• n_trips_today -> Trips today
• n_active_days -> Number of days with one trip (hide by default for our deployment)
• first_trip_local_datetime -> First trip date
• last_trip_local_datetime -> Last trip date
• n_days -> Number of days since app install
• unconfirmed -> unlabeled
• first/last get call -> first/last app communication
• first/last put call -> first/last data upload
• first/last diary call -> first/last app launch

For the last three entries, you can hide the first_XXX by default for our deployment and only display the last_XXX

[shankari]

The trips table seems pretty self-explanatory and haven't heard a lot of feedback on changing it. I would keep that unchanged for now until we get more feedback.

[shankari]

there are two places where you can rename columns.

1. In R/mod_load_data.R, or
2. in an observeEvent callback from the table

Today we got (1) to work. I suggest that you comment (1) out, and spent tomorrow morning exploring how to get (2) to work.

For (2) the callback actually appears to work but the display is not updated. Understanding how to reactively update the display seems like a valuable skill.

[asiripanich]

* for our particular use case, we will probably want to hide the `first_XXX` since we only care about the `last_XXX`

Agree to all your suggestions. Should we explore if we can use a setup file (e.g., .yaml) to customise the dashboard? so we don't need to pass the same argument each time to get our customised dashboard.

[asiripanich]

Here are my suggestions for the non-code headers for the columns in the participant table. Feel free to replace them with more meaningful values if you can think of them

* user_id -> user id

* update_ts -> last profile update (hide by default for our deployment)

* client -> UI channel (hide by default for our deployment)

* client_app_version -> smartphone app version

* client_os_version -> android/iOS version

* curr_platform -> android/iOS

* manufacturer

* phone_lang -> language

* n_trips -> Total trips

* n_trips_today -> Trips today

* n_active_days -> Number of days with one trip (hide by default for our deployment)

* first_trip_local_datetime -> First trip date

* last_trip_local_datetime -> Last trip date

* n_days -> Number of days since app install

* unconfirmed -> unlabeled

* first/last get call -> first/last app communication

* first/last put call -> first/last data upload

* first/last diary call -> first/last app launch

For the last three entries, you can hide the first_XXX by default for our deployment and only display the last_XXX

This will make the table very wide, but i also agree that it is necessary to display something more meaningful.

[shankari]

An alternative would be to move the participant status information (first get/first put/first diary) to a separate table.

[shankari]

I think you can go ahead and submit a PR for the changes you have made so far Next, let's look at putting the mapping from the model to the view in a yml file once we do that, other configuration options will be much easier.

[shankari]

there is a full spec for YAML but here's an example that is not too complicated https://blog.stackpath.com/yaml/

Basically YAML looks like a tree with mappings and arrays

a: b
   - c
   - d
   - e

[shankari]

wrt mapping from the model to the view, what we are essentially doing is i18n. So there is a code oriented text field, and we are mapping it to human readable text (that can be different in different languages)

does shiny already have i18n support? looks like it does, and supports mappings via csv or json https://appsilon.github.io/shiny.i18n/

so for the features implemented so far, we can just use that directly

[shankari]

for additional configuration around default language, which columns to include, which graphs to include, etc we would then need to have a separate config file. It looks like this module https://kellobri.github.io/shiny-prod-book/connecting-to-data-in-production.html might help to have different config files and choose between them when launching the app

[shankari]

if we switch to a config file based approach, then the existing config options (anon_locations and the mongo DB URL) can both move in there as well. I don't think we need a mixture of config file and launch time arguments.

[shankari]

With the merge of the config file PR, I think all the changes outlined initially have been completed. I am closing this issue. Congrats, @allenmichael099!