Revaluate the dashboard visual design

[ctyrrellnrel]

Maybe we should redesign of dashboard before migrating the dashboard from angular to react? (Issue #857)

I think there are a few things to change:

• having a dashboard with fewer numbers and more graphics
  • could use a pictogram chart to represent energy, distance
• units such as calories don't always make sense to use as a measurement of energy (for non scientists)
  • Kg of CO2 is a more common unit, but still a bit abstract
• not obvious the bottom cards could be swiped

potential tasks

• Change units of measurement from calories to gallons of gas
• change the bar graph to a pictogram bar graph
• change how unlabeled data is represented in a graph
• change the swiping mechanic for bottom cards that display metric
• display data in bottom dashboard so that the mode of travel is in the left column and amount is in right column (instead of top row and bottom row)

Current Design

[ctyrrellnrel]

pictogram chart :

could use a pictogram like this represent units of energy, by displaying gallons of gas, cookies or lightbulbs, etc

[shankari]

Change units of measurement from calories to gallons of gas

So the calories don't represent the energy for travel, they represent the calories expended by the participant while using active transportation.

So because you rode your bike, you can eat another cookie...

[JGreenlee]

So the calories don't represent the energy for travel, they represent the calories expended by the participant while using active transportation.

So because you rode your bike, you can eat another cookie...

I had no idea! We can definitely redesign to make that clearer to the user.

[shankari]

Yeah, not only do you save the earth by using active transportation, you also get a workout at the same time 😄
Particularly for bicycling, that is called "utility cycling" (https://en.wikipedia.org/wiki/Utility_cycling)

On a personal note, we drive to a specialty grocery store once a week but the rest of the time we walk or bike to grocery stores within a 3 mile radius - it's essentially walking or biking with weights. Sometimes it takes multiple trips to finish the shopping, but you should really exercise every day, right?

We actually have some fairly complicated calculations using the MET values, and you can put your height and weight to get even more accurate numbers.

[Abby-Wheelis]

Would it be possible to hide the panel about calories and how it relates to food? I think emphasizing the benefits of active transport is really cool, and an important feature, but I would advocate for doing so in a way that doesn't promote calorie-counting or ideas about earning food, since those can be harmful to people's mindsets around food and/or exercise. It probably won't bother most people, so just an option to hide that panel would likely be a sufficient accommodation to people who don't want to see it.

I personally like the feature where it shows you your distance traveled by different modes a little more. Maybe we could highlight that information more, allowing for people to see how far they went in active transport, and feel accomplished?

It could be an unpopular opinion, but I thought I'd at least share my perspective.

[shankari]

@Abby-Wheelis thank you for your thoughtful comment about messaging around food. I agree that the notion of "earning treats" can foster an unhealthy relationship wrt eating in general.

And the option of hiding highlights a struggle with the dashboard in general - there are people who like data and nice graphs, and there are people who want simplicity and a "one number" abstraction - how do we accommodate all of them? Since we are supporting configurable modules now anyway, maybe it is time to think about both how to support admin-decided configuration (as part of the dynamic config) and potentially user-led configuration (bring on the data!)

However, to make sure that we can get a basic redesign done by the time Kellen's internship is done, I would suggest that we at least finish a "mass-market" version that we hope can be broadly appealing.

And for that, maybe it would make sense to focus on exercise rather than food.

The CDC has exercise recommendations (https://www.cdc.gov/physicalactivity/basics/adults/index.htm) of "150 minutes of moderate-intensity physical activity and 2 days of muscle strengthening activity a week". Would it be helpful to show people how their physical activity from active transportation helps them make progress towards that goal?

Note that this is still a research project, so if we have time, we can show both data-heavy and summarized versions of the dashboard and see which people choose 😄

[Abby-Wheelis]

@shankari It makes sense that customizable dashboards would be a feature that we might look into a little further down the line, I definitely want Kellen to be able to finish his project!

And yes, I think that showing active transportation as contributing towards a baseline exercise goal could be a nice way of showing people how their transportation choices are helping them in addition to helping the planet the planet.

[ctyrrellnrel]

Change units of measurement from calories to gallons of gas

So the calories don't represent the energy for travel, they represent the calories expended by the participant while using active transportation.

Okay yeah, that makes sense. And I do think that even with the possible reasons to focus on exercise rather than calories, I think the goal in total is to simply make the dashboard feel more understandable in terms of what participants may have experience with or care about. So, using units like minutes of exercise, gallons of gas saved or potentially calories burned I think all can be relatable measurements to participants.

Perhaps we can have the ui reflect that? Maybe just make a few javascript functions for each potential unit someone might be concerned about (gallons of gas used / saved, exercise, Kg CO2, etc), then the user can pick and choose from a menu which they want. Then a card will be presented to the user for each that they picked. Luckily, due to react we will only really need one definition of a card element.

I think we get some of those for free. KG of CO2 to gallons of gas, duration (of relevant modes of travel) to minutes exercised.

But, also I understand concerns about the potential time crunch of this, or the decision fatigue it may give the user.

[ctyrrellnrel]

I guess this is kind of happening right now, except the user at the moment doesn't have the option of choosing what particular metrics will be on the dashboard (calories, kg co2)

[shankari]

my original goal for OpenPATH was a carbon footprint "meter" where people would understand the changes they needed to make to meet our 2030 and 2050 CO2 reduction goals at a per capita level.

If you open the footprint tab, you can see that comparison (with the color as red if you aren't meeting those goals).

This allows people to think about their "carbon budget" and what they want to spend it on. In my case, that is long trips for recreation in buses/hybrid cars with family. I will rarely drive for shorter "around town trips". But there might be people (maybe who have mobility issues) who drive everywhere around town, but don't go on vacation that often. There is no one size fits all - people and their needs are different. But for the sake of our planet, it would be good if we would meet those needs within our individual carbon budgets.

I know that is complex, and maybe others don't care about their carbon footprint, but I had a magic wand, it would be to somehow highlight that.

I understand the desire to make the metrics meaningful by converting them into gallons of gas saved. But even that metric is a bit context-free. Ok so I saved 10 gallons of gas. Is that good or merely "meh"? How much is really meaningful? what is my goal?

[shankari]

Since we are focusing on measurement and psychology, I would like to point out that there are well known issues with using an easily-measured proxy for the real metric that we want to optimize.

@Abby-Wheelis's example about food is similar - we sometimes use weight as a proxy for health since it is so easily measured. That is not completely wrong - being overweight is the single biggest risk factor for a variety of cardiovascular diseases. But an over-emphasis on the proxy can lead to optimizing the proxy (weight) while actually hurting the real metrics (health) through eating disorders.

Again, I don't know that we can resolve this fully, but I would be open to doing a test on various metrics and their representations using something like Mechanical Turk if you wanted to explore some options and write a paper.

[ctyrrellnrel]

Okay, all of that makes a lot of sense and is giving me something to think about. Perhaps having a default set of measurements, such as Kg C02 to start out with, that most people would likely not change, but give the ability to see a few other measurements if the participant is interested? I think that it would not be too difficult.

Like the current mechanism to switch calorie measurements in terms of different types of food, you could visualize carbon footprint in different ways, starting with Kg CO2, but also gallons of gas, etc. Health related measurements could be shown as time exercised, calories burned, etc.

[JGreenlee]

A suggestion from @asiripanich was to show the cumulative amount of time spent at different locations (or types of locations)

This may yield metrics like:
How much time have you spent in a park in the last week?
-vs-
How much time have you spent at home?

This may be a healthier and more useful way of promoting fitness and well-being alongside sustainability.

To accomplish this, I think we could grab some zoning information from OSM, at least to get general categories like recreational vs. residential, and compare this with places in the timeline. It could probably be implemented client-side if we don't want to bother the server with non-essential analysis tasks.

[JGreenlee]

my original goal for OpenPATH was a carbon footprint "meter" where people would understand the changes they needed to make to meet our 2030 and 2050 CO2 reduction goals at a per capita level.

If you open the footprint tab, you can see that comparison (with the color as red if you aren't meeting those goals).

I think this 'meter' idea can remain an effective focus for the Dashboard tab.
The comparisons against 2030 and 2050 emission goals give the users a tangible and comprehensible goal to work towards. Measurements of Kg CO2 on their own mean nothing, but when you put this up against some expectation that people should be meeting, I do think they are very insightful.
We just need to represent this information in a more intuitive way. Perhaps ideally, a visual representation of an actual meter. Or simply a barchart, since we have error bars we'd want to show.

(with the color as red if you aren't meeting those goals).

This is another thing I never knew or never noticed. I think it should be made perfectly clear to the user whether they are meeting the goals or not.
People check the Dashboard and they want to know "How am I doing? Has my footprint been good or bad lately?" Whatever element is given primary visual focus, likely at the top of the Dashboard, should answer that question.

[JGreenlee]

With "My Calories", my suggestion would be to remove calorie-counting altogether, and, if we wish to keep some health or fitness metrics, we pivot to something like 'active minutes' or 'time spent on recreation' (ie. at the park / other recreational zone)

[ctyrrellnrel]

Proposed Wireframe:

additions / changes:

• My Active Minutes card
  • instead of My Calories
  • bar is sum of all minutes of active transport for each day
• graph views for My Footprint, my active minutes
  • Dashed lines represent goals
  • percent change in top right between last two complete weeks
  • dates are shortened to month/day to keep things manageable
  • each pair of bars consists of personal and average performance
• bleeding edges to indicate metric cards can be swiped
• The chart page is now a second view for each metric card
  • tapping button in top right switches between numeric and graphical views
  • To keep the view from being crowded, potentially limit number of bars shown in graph mode to top 3 biggest modes

Wireframe

Wireframe 1	Wireframe 2	Wireframe 3

[ctyrrellnrel]

Two things of note:

• there is no color right now
  • I think that adding color to the percent difference (green or red) will be a powerful way of indicating success)
  • bars differentiated by color
  • Still could have stacked bar chart for my active minutes
• There are no keys for the graphs
  • There may be a more convenient way of doing this with the graph library then I can write down
  • could have a card expand downward to show key for what different colors mean

[JGreenlee]

This design already feels much cleaner and intuitive to me.

First, some general comments:

To keep the view from being crowded, potentially limit number of bars shown in graph mode to top 3 biggest modes

I don't think you need to. We have no restrictions on how tall or long this page is; it will scroll as long as we need it to. And no one's saying the cards need to be a uniform size, or a fixed size. Each card can grow to however large its content needs to be.

I think we should be able to keep all the "Chart" features that we had before the migration started. But if you're hesitant to embed that much chart detail in a card and do want to show a simplified graph, then we could consider having a more detailed graph accessible by clicking a button on the card that opens another view.
However, this could be too many clicks to get there (we already spent a click getting to the simplified graph in the first place).

In general, I think we can space out the content way more. I would increase the margins and padding on nearly everything, especially vertically. Designers would tell you to embrace the negative space; it will feel more comfy and less overwhelming that way.

Some specific comments:

• I would suggest "-4% this week" rather than just "-4%"
  -- maybe "-4%" can be big / bold, while "this week" can be small / italicized
• I would want that first card to be about twice as tall, in effort to not overwhelm the user with a lot of information right away. It should definitely be the first thing they notice when they open the Dashboard (and maybe the only thing initially).
• Yes, the graphs will easily have keys
  -- look at the demo in Add ChartJS BarCharts to Dashboard "Chart" tab e-mission-phone#997,
• We had talked about stratifying "Active Minutes" into "High-Intensity", "Low-Intensity", and maybe "Moderate Intensity"
  -- If we were still going to show that, how would you represent it? Would it be on another card you can swipe to? Would you have a button on that card that opens another view showing the "Breakdown"? Or something else?
• What do you think about the Date picker being in the top bar: next to, or potentially replacing, the refresh button?
  -- (why is the refresh button even necessary on this page? @shankari)

[shankari]

If we were still going to show that, how would you represent it?

I would suggest using a stacked bar for the "active minutes"

(why is the refresh button even necessary on this page? @shankari)

Because AFAIK, the page is not refreshed on resume. So if people had the app in the background but not killed (which is what we recommend for iOS) and then brought the app to the foreground, it would still show their last set of results. Not sure if this has changed in the multiple rewrites.

While we are asking questions about that, the "share" button is definitely not necessary. It was a misguided attempt (back when this was e-mission, not even emTripLog) to see if people would get their friends to join them. It's now taking up precious space and when clicked, generates a completely obsolete message.

If we wanted to keep the button, we could have it be a "social share" button which would share the dashboard with friends/family via email/social media.

[ctyrrellnrel]

Thanks for the suggestions!

• I agree with having the first card be bigger, as it should be the focal point of the dashboard
• Within the "my footprint" card -4% should definitely be the highlighted aspect of the card, as that really sums up the info the user needs to know about their footprint from week to week.
• In looking at the demo mention above here, I think I'm pretty excited to see that on the cards. It looks very smooth
• I think that one card with a stacked bar chart would be a good way of showing low, medium and high activity levels.
• I'm honestly not sure whether or not it would be worth replacing the refresh button entirely. It seems like the refresh button is not necessary if you are only looking at your own statistics, because updating those would necessitate going to a different screen anyway.
• Also, I do actually like the numerical view of the metrics already present, but I'm not sure if it would be too much work to both have those and the graphs.

[JGreenlee]

I would suggest using a stacked bar for the "active minutes"

I think this makes sense if there is one dashed 'target' line and it is in reference to the total active minutes (ie. 30 minutes of physical activity). So if my chart shows 15 minutes of low-intensity, 15 minutes of moderate intensity, and 5 minutes of high-intensity, I can see that I met the goal because the bars stacked together will surpass the target line.

But if there are target lines for specific levels of intensity, it wouldn't be easily conveyed without having separate bars

the "share" button is definitely not necessary

Sure, we could just replace 'share' then. If we want socials sharing later on, we can have 3 buttons or a menu or something.
If we put the datepicker in the top bar, we can use the same datepicker as on the label screen, and reduce the complexity that Ionic's datepicker adds

[JGreenlee]

We should probably use react-native-paper-dates https://www.reactnativepaperdates.com/
Because it supports picking ranges, not just a specific day
It also looks really nice in my opinion and will integrate into the other RN Paper components we've been using

[shankari]

I think this makes sense if there is one dashed 'target' line and it is in reference to the total active minutes (ie. 30 minutes of physical activity). So if my chart shows 15 minutes of low-intensity, 15 minutes of moderate intensity, and 5 minutes of high-intensity, I can see that I met the goal because the bars stacked together will surpass the target line.

Yes, this is what I had in mind. The CDC guidelines are 30 minutes of moderate intensity. Not sure that there are guidelines for low/high intensity. Would be interesting to think through how we might be able to display if we can find separate guidelines for different intensity levels @ctyrrellnrel any thoughts? separate bars with one separate goals? Separate slidable tabs?

[JGreenlee]

I will work on getting stacked bars working in e-mission/e-mission-phone#997

[ctyrrellnrel]

Would be interesting to think through how we might be able to display if we can find separate guidelines for different intensity levels @ctyrrellnrel any thoughts? separate bars with one separate goals? Separate slidable tabs?

That's a good question, I think that having different colors of dashed lines may accommodate that, but the confusing part is that the high, medium and low intensity exercise should be weighted differently, but that is not reflected in a bar chart, which only measures minutes. But also, I think they are adding towards the same goal, so it may not make sense to have them have different goals, as having more of one may make up for less of another.

I found something here that shows different guidelines for medium or high intensity exercise, which says 150 minutes of moderate intensity exercise, or 75 minutes of high intensity exercise, or a mix of both with amount of time somewhere in the middle. I don't know if there is a good way of reflecting that in a bar chart.

Perhaps we could have one card that has total minutes, without intensity level considered, and another card with "weighted exercise minutes" that considers the statement above, and weights high intensity minutes as being worth 2 "exercise minutes" (which we could explain in a drop down tab below). moderate intensity minutes would be worth 1 "exercise minute". We don't necessarily have to call them exercise minutes, but something that shows different exercise intensity is weighted differently The total goal of "exercise minutes" is 150, but high intensity minutes would count as double towards this.

[JGreenlee]

That's a good question, I think that having different colors of dashed lines may accommodate that, but the confusing part is that the high, medium and low intensity exercise should be weighted differently, but that is not reflected in a bar chart, which only measures minutes. But also, I think they are adding towards the same goal, so it may not make sense to have them have different goals, as having more of one may make up for less of another.

I think that for simplicity and for consideration of our timeline, it is okay to just have one target of 30 minutes for overall active minutes. We can indicate in a footnote that it pertains to 'moderate intensity'.

I think that our design discussion has been valuable, but we should begin on the implementation soon. @ctyrrellnrel After a final wireframe applying the recent discussion from above, I believe we will be ready to do so.

[ctyrrellnrel]

New Wireframe:

additions / changes:

• My Footprint card
  • Made larger
  • Added keys
  • Changed the percent change to have this week and a bold percentage
• My Active minutes
  • See My Footprint card
• My average speed (graph)
  • Made larger
  • added keys
• Title bar
  • replaced share button with change dates

Wireframe

my average speed numerical	my average speed graph

[ctyrrellnrel]

I realized at Jack's comment here that I still don't think I made them big enough, so here's another wireframe with sized up cards

I would want that first card to be about twice as tall, in effort to not overwhelm the user with a lot of information right away. It should definitely

Top of dashboard	scrolled down dashboard

These are slightly sloppier, but hopefully they are enough.

[shankari]

I am just a bit concerned about the sizing. It looks like we are relying a lot on bleeding edges to ensure that people know that there is more to swipe. But different phones have different form factors. So if we have a shorter phone, will we see the bleeding indicating the summaries? I know that reactive design can address quite a bit of this, but in my experience, reactive design primarily works for big differences in form factors - e.g. desktop versus mobile. I am not sure it can capture the differences between iPhone XS and iPhone Pro and iPhone Pro Max (for example).

@JGreenlee are there tools for this in ReactJS/React native paper?

[JGreenlee]

I am not too worried about whether there is a visible bleeding edge vertically. Vertical scrolling is standard on web and mobile. If there's more content below, I think people will find it.

Horizontally, I do think it's important to signify that the cards are swipeable. Horizontal scrolling is easier to miss as a user.
We can do a bleeding edge on those cards without any third-party library by using React Native's ScrollView, making it horizontal, and using its snapTo properties https://snack.expo.dev/H1CnjIeDb

Note to self: the above works in RN but doesn't snap on RN Web. For snapping to work before the migration is done, we may need the CSS workaround from necolas/react-native-web#1250

[JGreenlee]

Web and mobile layouts grow and expand vertically. We shouldn't try to force a layout to be a certain height. On a tiny screen, you might only see one card at a time. On a bigger screen, you might see 2 or start to see the third. That's perfectly fine, and actually much better than trying to cram the same content on different screens

[shankari]

Horizontally, I do think it's important to signify that the cards are swipeable. Horizontal scrolling is easier to miss as a user.
Note to self: the above works in RN but doesn't snap on RN Web. For snapping to work before the migration is done, we may need the CSS workaround from necolas/react-native-web#1250

Given this complexity, should we even use bleeding to signify that cards are swipeable? There are other cues that are commonly used (e.g. dots below the content, < > at the edges, etc - think "carousel"). Again, given our limited bandwidth, testing capacity and control, I would err on the side of simple visualizations and not choose super-complex UI layouts that are optimized down to the pixel level.

Big companies have the resources to build separate screens for every single iOS phone dimensions out there. We don't.

[JGreenlee]

@ctyrrellnrel I think this design gives us what we need to start working on the implementation.

The first thing I'd do is embed a chart inside a card. Look at e-mission/e-mission-phone#997 and clone my add-chartjs-plots branch.
Notice how <bar-chart> is used in main-metrics.html.

Try to replicate this, not inside the Chart tab, but inside the 'details' cards - (for Distance, Speed, etc). The chartData can be hardcoded placeholder data for now; I just want to see how the charts show up inside the card.

Once you have a barchart showing up, try adding lineAnnotations (an array of 'goals'/'targets' that display as dashed lines). Any arbitrary value is fine for now.

Share some screenshots so we can see how it looks and whether I need to modify the BarChart component. If you get stuck or need clarification about the data structure that barchart accepts, feel free to ask.

[JGreenlee]

Given this complexity, should we even use bleeding to signify that cards are swipeable? There are other cues that are commonly used (e.g. dots below the content, < > at the edges, etc - think "carousel"). Again, given our limited bandwidth, testing capacity and control, I would err on the side of simple visualizations and not choose super-complex UI layouts that are optimized down to the pixel level.

Big companies have the resources to build separate screens for every single iOS phone dimensions out there. We don't.

I don't think it is too complex, but if you're worried about it then the < > arrows are fine too.

The ScrollView is very flexible and responsive, and I think the horizontal bleeding edge will work on any screen size. There's nothing about this mechanism that is pixel perfect or specific to any screen size. The only relevant consideration is that each card must be less wide than the screen itself, so that the next card shows at the edge of the screen. This is easily done with RN's useWindowDimensions, and taking width * .9 or something like that.
How about we try it and consider the < > arrows if it doesn't respond well?

[shankari]

How about we try it and consider the < > arrows if it doesn't respond well?

I just didn't want us to get too stuck on the bleeding design and spend a lot of time tweaking it back and forth

[ctyrrellnrel]

Okay, was just working up a design for the arrows and dots, but I guess we should just start on it, and figure out what works and doesn't work while doing that. We could have every option is represented by an icon at the bottom of the card, and instead of swiping, one just clicks on the relevant icon. *like in the My Calories Card

I will start working on getting that graph into the card.

[shankari]

After we get the basic chart working, we should decide which color palette to use. Ideally this would:

• be the NREL palette by default
• be easily changeable by other deployers

e-mission/e-mission-phone#997 (comment)

Alternatively, are there standard palettes in chartjs like the Tab10 or Tab20 palettes in matplotlib?

[ctyrrellnrel]

I just quickly put in the chart, and it was EXTREMELY easy to do so. Just a quick plop in to one of the cards, and it fit perfectly, no issues. Also, didn't try to do new inline objects in angular, not sure if you even can do that, just defined them in the function themself (for creating the bar lines). But not too worried about that, as likely the variables concerned with the goals won't need to be passed into the function, as they are not dependent on what the user is doing or which user it is. (unless we could use a user-dependent bar to show their average over the past certain number of days / weeks).

[JGreenlee]

An example I created for the carousel, which we can refer back to once we get to that step of the migration

https://snack.expo.dev/@jgreenlee/carousel-scrollview-with-bleeding-edges

[shankari]

@ctyrrellnrel so is there a draft PR somewhere? Is there an ETA?

[JGreenlee]

Ideally this would:

• be the NREL palette by default
• be easily changeable by other deployers

I think for charts, our palette needs at least 8 distinguishable colors, but company/brand color palettes don't tend to have that many.
NREL's palette has 4 or 5 distinct hues: https://www.nrel.gov/comm-standards/web/typography.html
So I think it makes sense to treat the charts as a separate component with its own color palette. It can still be customizable if that's important.

Alternatively, are there standard palettes in chartjs like the Tab10 or Tab20 palettes in matplotlib?

ChartJS does have a default palette, but there are only 7 colors and I don't think it's colorblind-friendly.

Seaborn improves on Matplotlib's palette a bit. There's a colorblind variant that I think would be good to use.
I made a short script to extract the Seaborn palettes as JSON: https://gist.github.com/JGreenlee/b03534aad580cbfd6649729e61b0a376

Conveniently, the NREL palette has blue as primary and orange as secondary; these are the first two in matplotlib/seaborn. We can probably play it off as some fusion of the two, with a little tweaking if necessary

[ctyrrellnrel]

@ctyrrellnrel so is there a draft PR somewhere? Is there an ETA?

Yes, I will be working to put out a draft pr by the end of the day.

[ctyrrellnrel]

Currently have a working button that switches between two different views, that graph and 'details', although the details isn't actually fleshed out yet, just placeholder text. e-mission/e-mission-phone#1002 (comment) @shankari @JGreenlee

[JGreenlee]

Good!

I don't know who jackcsullivan is, but it isn't me..

[shankari]

FYI: jackcsullivan was a Berkeley undergrad/MS student who worked on e-mission in the past - the TripAware project (https://bets.cs.berkeley.edu/publications/2019buildsys_tripaware.pdf) and this MS thesis (https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-69.html)

[ctyrrellnrel]

I don't know who jackcsullivan is, but it isn't me..

oops switched that

[shankari]

Closing since this is superceded by #961