nychealth / EH-dataportal

Source code for the Environment & Health Data Portal
https://a816-dohbesp.nyc.gov/IndicatorPublic/
Apache License 2.0
10 stars 4 forks source link

Improve trend charts #1127

Open mmontesanonyc opened 1 week ago

mmontesanonyc commented 1 week ago

Hey folks, I've been mulling over the trend charts for a while and want to brainstorm ways to improve them. There are a few challenges:

Legends/labelling. We chose to go for legends instead of the usually-preferred labels (or label-final) because we have a lot of closely-clustered data that results in overlapping labels at the final value. Legends have their own challenges, especially on mobile display, so we wind up calculating a number of columns for the legend, based on screen width, and passing that into the spec.

Tooltip. I liked the approach we chose at the time, but now I think it's overwrought and doesn't adequately identify one series. If we had highlight-one-line-on-hover, then we might not need the legend - or could greatly de-emphasize it.

A few standard approaches:

I think my ideal approach would be something that:

@cgettings, @etorem what do you think?

mmontesanonyc commented 6 days ago

I have a spec here that is pretty different from the existing spec:

A few things I'd like to add to this:

A strokeWidth or opacity conditional that gives more weight to New York City. But every time I add a strokeWidth condition test, it doesn't work as expected. @cgettings I know your time is precious this month, but if you have a few minutes I'd love to see what you make of it. i would expect the below to work in a number of places but it does not.

    "strokeWidth": {
      "condition": {"test": "datum.properties.Geography === 'New York City'", "value": 5}, 
      "value": 3
    },

Label final value on hover. Adding the below gets us part of the way there, but not quite. (Shelving this until we figure out the x-axis thing, and picking up from there, might let us use end_period which can probably aggregate in a way that TimePeriod can't.)

    {
      "encoding": {
        "x": {"aggregate": "max", "field": "TimePeriod"},
        "y": {"aggregate": {"argmax": "TimePeriod"}, "field": "Value"}
      },
      "layer": [
        {
          "mark": {"type": "text", "align": "left", "dx": 4},
          "encoding": {
            "text": {
              "condition": {"param": "hover", "field": "Geography"},
              "value": ""
            }
          }
        }
      ]
    }
mmontesanonyc commented 6 days ago

In this I've incorporated our new approaches for x-axis labelling and scaling. I also got a start on label-final-value, but despite what the code is telling me, it's labelling every value and not triggering on hover.

mmontesanonyc commented 6 days ago

Updated spec with the hover working as intended. Thoughts on this as a replacement? I might need to back this in to comparisons.js to test it out with a variety of datasets for us to properly evaluate. @cgettings @etorem

May be easier to do left-side labels without overlap or padding issues. One issue re: using this approach is the lack of legend for screenshot/re-use purposes.

etorem commented 5 days ago
Screenshot 2024-09-12 at 9 34 08 AM

I think I like it with a slightly thinner line, like this (line 664, strokeWidth: 3). Or 3.5. What do you think? @mmontesanonyc

I think it looks great, I'm glad we can display single borough values now and the palette is really nice.

mmontesanonyc commented 5 days ago

@etorem agreed! thinned. I also revised dimensions, changed "For" to "Group" and did a little management of the x-axis labels as they respond to width. A bit of "manual responsiveness" built in.

I'm going to let this marinate for a bit.

Semi-related - since this work is taking place on a branch initially about reviewing colors - @cgettings and I talked about using viridis for the maps. I speculate that the colors don't have built-in judgement and we may not need to have the red and blue alternates. Will make for an interesting conversation.