⚙️📊 Make the In-App Dashboard configurable

e-mission / e-mission-docs

Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.

BSD 3-Clause "New" or "Revised" License

15 stars 34 forks source link

In the current version of the app, the Dashboard tab is completely hidden if survey_info . trip-labels is set to ENKETO. This is largely because we couldn't compute carbon footprint without a MODE input.

However, the DFC fermata project will use Bluetooth sensing to detect mode. This means we will be able to show the carbon footprint even without user input. We also want to show other metrics, including new sections for survey response rate, and potentially user engagement / gamification

I think we should expand the metrics field of the dynamic config. It already has one field include_test_users. I propose adding a sub-field "phone_dashboard" that contains options that control the UI.

{
  ...
  "metrics": {
    "include_test_users": false,
    "phone_dashboard_ui": {
      "sections": ["footprint", "active_travel", "summary", "engagement", "surveys"],
      "footprint_options": {
        "unlabeled_uncertainty": false
      },
      "active_travel_options": {
        "modes_list": ["walk", "bike"]
      },
      "summary_options": {
        "metrics_list": ["distance", "count", "duration"]
      },
      "engagement_options": {
        "leaderboard_metric": ["distance", "e_car"]
      },
    }
  }
  ...
}

`sections`

A list of sections to show in the dashboard UI. They will appear in the specified order from top to bottom. Options are footprint, active_travel, summary, engagement, surveys. Whichever sections are omitted will not be shown in the UI. Default: ["footprint", "active_travel", "summary"]

`footprint_options` . `unlabeled_uncertainty`

Whether to show the uncertainty on the carbon footprint charts. Programs using MODE / PURPOSE labels will need this true. Programs using Bluetooth sensing can set this false. Default: true

`active_travel_options` . `modes_list`

Which modes to consider as "active" for the purpose of calculating "active minutes". Default: ["walk", "bike"]

`summary_options` . `metrics_list`

A list of metrics for which to show a graph and descriptives summarizing the metric by mode. Options are distance, count, duration. (mean_speed used to also be one but it was removed because the computations were wrong. We can add it back if we fix it) Default: ["distance", "count", "duration"]

`engagement_options` . `leaderboard_metric`

What metric to use as the basis for the leaderboard. (I am not sure yet how this will be represented, but maybe something like ["distance", "e_car"] to rank participants on miles driven in an EV. But if we do incentives based on survey response % instead, it will look different)

@jiji14 and I will work together on implementing this

While implementing this, we are going to transition from server-side computation to client-side computation for user metrics.

In the current version on master, all metrics are computed on the server and organized by date. The in-app Dashboard tab fetches the metrics from the server for the selected date range.

Transitioning to client-side computation for user metrics has a few advantages:

The dashboard tab will be able to update in real time because it can include unprocessed labels and unprocessed trips. So if a user labels a large batch of trips and switches to the Dashboard tab, they will be able to see the effects of all their new labels
We can share data between the Label tab and the Dashboard tab. With client-side metrics, the basis of the metrics computations will be composite trips, which are already being retrieved by the Label tab. This can give a much better UX because there will be fewer network calls and less loading time.

One caveat is that these advantages apply only for the user's metrics. Aggregate metrics (used for group comparisons, summaries for whole cohort, etc) will still need to be computed on the server. I still think that this client-side computation is worth it for the UX because it allows us to show the most pertinent information upfront (which is the user's own metrics). It gives us flexibility to potentially lazy-load aggregate metrics while the user is already looking at their own metrics.

The steps I think are needed to this to happen for GPG:

[x] Hoist the state for the fetched composite trips (and all associated "timeline"-related state) higher in the component tree, such that both the Label tab and the Dashboard tab will be able to access the same data.
[x] Sync up the datepickers for Dashboard tab and Label tab, putting a limit on the range if necessary (perhaps a maximum of 2 or 3 months can be loaded at a time)
[x] Refactor the Dashboard tab to compute user metrics using e-mission-common, passing the timeline data as input. User metrics will no longer be fetched from the server, but aggregate metrics will stay the same
[ ] Implement the new metrics components (with computations performed in e-mission-common) and make the dashboard configurable

At a later point in time, or gradually:

[ ] Refactor the server code to use e-mission-common similarly for aggregate metrics
[ ] After a while, remove obsolete code on the server

e-mission / e-mission-docs