📈 New "Dashboard" tab - Design Considerations

[JGreenlee]

A couple months ago, we discussed in https://github.com/e-mission/e-mission-docs/issues/922 and created some wireframes Now that Abby and I are implementing this Dashboard rewrite in https://github.com/e-mission/e-mission-phone/pull/1018, I am starting a new issue to continue discussion.

These are the wireframes from #922, copied here for convenience:

Here are some initial drafts of the implementation:





Some things to note:

• the carousel mechanism is working really well and makes it way clearer that there are additional cards to swipe to
• units of measurement on the graphs are scaled wrong

---

There are a few things we need to stop and consider.

Daily / Weekly / Monthly / Yearly interval

The old Dashboard has options to change the basis of time on which these metrics are represented:

1) Concretely, what does this do?

2) Do we need to support it? Why not just fetch the data on a daily basis and segment it into week / months that way? Does that put extra stress on the server?

Active minutes

The wireframes showed active minutes per day as a chart. However, the CDC recommendation is on a weekly basis (150 minutes, moderate intensity) I think that weekly goals are generally more appropriate for this, so I am suggesting that we pivot to a simple comparison of "past week" vs "previous week", each of these with stacked 'walk' and 'bike' totals. Then, we can put the target line at 150 and visually see whether, between your cumulative active minutes, you reached 150.

Then, I think we should have a separate card to the right of this (swipable to by carousel) that breaks this down by (i) high-intensity, (ii) moderate-intensity, (iii) low-intensity.

Average speed

We receive average speed metrics from the server. These appear to be the average speed per mode per day.

So if on Monday, I walked to the bank at a speed of 4mph, and return at a speed of 2mph - my average for Monday is 3mph. Then on Tuesday, I walk to the store at 3mph and return at 5mph - my average for Tuesday is 4mph.

But to get my average across both days, I don't think we can just take these two figures (3mph and 4mph) and average them together to get 3.5mph. Because what if the walk to the store was 20 minutes, while to the bank it's only 10 minutes? Then mathematically, my average speed between those days was not 3.5mph, it was greater than that.

The proper way to calculate my Average walking speed for Monday and Tuesday would be to find my total walking distance on those days, divided by my total walking duration on those days. Those are two metrics that we already have - so I don't think we actually have any use for the speed metrics that we get from the server.

[shankari]

From the public dashboard, this is roughly what we should expect for NREL commute

Number of trips	Number of miles

[Abby-Wheelis]

I looked into the carbon footprint values, and I am seeing some differences especially on user footprints for a given week, but I haven't figured out exactly what is happening. I checked the FootprintHelper.getFootprintForMetrics against a sample input of [{key: "drove_alone", values: 100000}] and the output was exactly the input in km * the US intensity for a car, so I have reason to believe that function is working. There are some warnings in the logs about "other" modes, but that is from "unlabeled" distances and the default value (0 for "low estimates" and the highest mode value for "high estimates") is used.

I think there might be a chance that the dates are fetched differently between the two implementations, but I need to keep walking through what's happening in the emulator tomorrow. The other thing I can think of is that somewhere in the summation of the distances there is an error, so I plan to examine that process tomorrow as well.

[JGreenlee]

To see if there are any inaccuracies in our calculations, I thought I'd do a side-by-side comparison between this branch and master to find discrepancies.

But interestingly, I found discrepancies within master itself. Same OPCode, same date range - different values

[JGreenlee]

The left is the devapp running on a real Android phone. The right is the devapp running on an iOS Simulator.

I can't think of any good reason for these to yield different metrics

[JGreenlee]

The new dashboard is at least consistent with itself, but none of the calculations line up with the old dashboard

---

It doesn't seem to be as simple as just being off by 1 day, either. This is going to take some digging...

[Abby-Wheelis]

^I agree that it's taking some digging, so far I've found one different between old and new:

The default calls seem to be different between what's currently in production and the new dashboard, when I opened them both just now, production is showing Sept.8-Sept15, but the metrics used to populate are only the 1st through the 13th (13 days, not 14?) while the new dashboard pulls Aug 31st through Sept14th (15 days of data) by default. The extra day is trimmed off when the data is divided into weeks (31-6 and 7-13).

However, when I set the dates to a single week on my phone (I can't alter the dates on production in the emulator) the numbers are still off by 20-30% between production and the new dashboard, which is very significant.

My next step is to hand-calculate what's on the new dashboard based on the data it's using, maybe something got lost in the math when I was re-writing the formatting functions

[JGreenlee]

Good plan. If the old dashboard is not a reliable source of truth (it seems like it might not be), I think we can use hand-calculations as a better ground truth to compare the new dashboard against

[JGreenlee]

the new dashboard pulls Aug 1st through Sept14th (15 days of data) by default. The extra day is trimmed off when the data is divided into weeks (31-6 and 7-13).

I'm not sure what you meant by this. If you meant Sept 1st through the 14th, that is 14 days. Or did you mean to type Aug 31st through Sept 14th?

[Abby-Wheelis]

I'm not sure what you meant by this. If you meant Sept 1st through the 14th, that is 14 days. Or did you mean to type Aug 31st through Sept 14th?

oops! yes, Aug 31st. I had noted that the userMetrics and aggMetrics received by the CarbonFootPrintCard were for those 15 days by default, but the data used for calculations ends up being the 31st - 13th after the data is split into weeks.

[Abby-Wheelis]

I think we can use hand-calculations as a better ground truth to compare the new dashboard against

The good news is that things check out agains my hand calculations, with the exception of handling "shared ride" modes. When I added up one of my weeks, I had: 78km of driving, 5.2km of walking, and 9.4km of biking. The only emitting mode there is driving, and 78km * 0.1659 = 12.7kg, which is the same thing the dashboard shows. I did the math by hand, then stepped through the footprint calculations in the emulator and saw that the results and the steps matched.

I also calculated a second week by hand, and the answer was still correct, but I noticed my 4km of "shared ride" were treated as the same as "drove alone" as they share the base mode "CAR". If I recall correctly "shared" modes should be calculated as 1/2 the intensity?

Aside from the snag on shared modes, both weeks were the same what I got by hand, and the totals between the two weeks matched the distance card. Carbon and Distance:

My values based on the metrics split into weeks -- I treated this as the input data, summing across the days by hand: 31-6 -> 77km drove alone, 5.2km walk, 9.4km bike = 77*0.17 = 12.7kg 7-13 -> 163km drove alone, 4km shared ride, 5.5km walk, 12km bike = 167*0.17 = 27kg

I now feel confident that the "binning" process is correct, as are the carbon calculations based on base mode and distance.

Next steps: follow up on shared modes and check that the metrics I used as input here match the actual trips

[Abby-Wheelis]

check that the metrics I used as input here match the actual trips

I just added up all the displayed distances by their labeled modes for the same two weeks (8/31-9/14) by scrolling back through my labeled trips and got: drove alone: 152 miles, shared ride: 3.8 miles, walk: 6.6 miles, bike: 13.4 miles -- the three miles different on the "drove alone" can be explained by the fact that I was using the displayed mileage on the label screen and had lots of trips by that mode - so I believe 3 miles of rounding error. And, for the record, the old dashboard shows the same distances within about 0.3 miles.

So I'm now pretty convinced that the calculations are right -- I've checked the distances used for footprint against the actual trips and stepped through the footprint calculations, everything is checking out against what I get by hand.

[Abby-Wheelis]

Looking into the shared mode, and I think I found the explanation for the discrepancies: when calculating the footprint, the mapping of modes to values is retrieved through a method getFootprint() which either fetches a custom footprint, or the current carbon dataset (in our case that's usually US). What the new dashboard is using is the default (US) values, which have less values -- only CAR no e-car, no shared ride. Production uses a custom footprint that has different values as well as many more modes (including e-car, shared ride, etc).

I'll start working on a fix to ensure that the custom footprint is used, when needed, in the new dashboard.

[JGreenlee]

Good catch - that's a mistake I made in https://github.com/e-mission/e-mission-phone/pull/1018/commits/5fcc5d45c601ea8d682dbb687e5658f3088a59be

I was thinking that footprints were tied to base modes, but they are actually specific to each rich mode because we list the kgCo2PerMeter for each mode in label option.

[Abby-Wheelis]

I needed to add code to handle deciding if we used a custom dataset, and also reverted back to using the rich modes rather than the base modes. The production and dashboard now match a little more. If I select the same date range with the same opcode with the new dashboard in the emulator and on my phone on production, the carbon values now match when the mileages by mode match (I've been comparing to compensate for date ranges getting picked differently. For example, 8/29 - 9/11 shows 21+28 on the new dashboard and 49 on production.

The "taxi" values are hard to compare, since we show the whole number now rather than "savings" to stay consistent with the meter. The "group" values still vary a lot between dates, and between production and the new dashboard, so I'll dig into those more next.

[Abby-Wheelis]

I've stepped through a group calculation, and confirmed that the custom footprint is now used for the group as well as individual users, and that the metrics are averaged by dividing the total distance for a mode in a day by nUsers.

"Taxi" values seem to align well, as [week total on new dashboard] + [taxi savings on production] = [if all taxi on the new dashboard] over a given week, which is what we would expect.

[JGreenlee]

New dashboard is now merged into master with https://github.com/e-mission/e-mission-phone/pull/1046