nychealth/EH-dataportal

Data Explorer Enhancements

mmontesanonyc opened this issue · 20 comments

mmontesanonyc commented

Consolidating issues and packaging some items together for a later-fall revision release.

Bugs:

  • Maps occasionally defaulting to number instead of a rate (eg here)
  • Add units to map spec, subtitle
  • Unreliability flags

Enhancements:

  • Enable multiple years in summary table
  • Revise console logs to be more descriptive - print and describe things like: names of variables/objects used, indicator ID, data source file; console.table(data)? etc.
  • Consider hconcat for map and bar
  • Enable specified multiple measures in Trend chart - see own issue
  • Add color directionality to maps: use greens if more=good and use purples is more=bad (using map.rankReverse, which is currently in indicators.json)
  • When showing counts, show values as integers.

Drinking-water-quality enhancements

  • un-default single measures as Trend display (in favor of comparisons)
  • limit to 3-years
  • label quarters

Restaurants with A grades and scaling: consider way of setting min and max on maps? Or other way of communicating map change over time.

mmontesanonyc commented

re: enabling specified multiple measures in Trend Chart: I was thinking about this recently and had an idea involving creating new frontmatter. But then I realized that a) that would mix-and-match what Hugo is doing vs what JavaScript is doing, and b) I already had an idea in the original issue that relies on JS only - essentially, adding a multipleMeasures array to the metadata in indicators.json:

            "Trend":[
              {
                "On":0,
                "Disparities":0,
                "multipleMeasures": [XXXX,YYYY,ZZZZ],
              }
            ],

In trend.js, we can run a test to see if, for a selected measure, does multipleMeasures contain anything. If no, then, show the trend chart as expected. If yes, then also ingest those measures (we might have to re-structure Trend.multipleMeasures to include both IndicatorID and measureID to make it easier - if we don't want to loop through indicators.json to find something by measureID) into the Arquero table that winds up getting delivered to the chart spec.

Would there be an advantage by doing this via frontmatter, instead? The advantage is that content managers (instead of just data manager) could specify multiple measures functionality. There is some existing Hugo code that builds the Indicator Selection menus on the page template - some additional code could dump page variables into JS variables that subsequent JS code could reference. Not sure if there's a great case for one approach or the other, but it seems more straightforward to do it with indicators.json and JS, rather than to combine .md, Hugo, and JS.

mmontesanonyc commented

re: unreliability flag:

Hard-coded way: check the unreliability column after loading the indicator, then show or hide the elements of a pre populated list. 

Programmatic way: take the unique values of the unreliability column and dump them into list elements.
mmontesanonyc commented

Just noticing these - I like that approach of having the topojsons be, like, NTA2010.topo.json and having a new field, GeoTypeDescr be what we display on the tables and page. Nice.

mmontesanonyc commented

Just for record keeping, I"m checking off unreliability flags. And were the geotype changes you made a couple of weeks ago the fix necessary for the nyckids/geos-by-year issue?

cgettings commented

I haven't pushed those geo changes yet, but I just have a little more to do to protect the oldportal.

mmontesanonyc commented

OK, sounds good. Thanks for the update!

mmontesanonyc commented

@cgettings - one thing I added in just now was the displayType on the map view. Wendy had identified that as missing (thought it had been there! Oops).

Also noting that you'd switched the topo.json reference to a baseURL reference instead of data_repo/data_branch reference, which broke the maps (broken on production). Switched it back here.

mmontesanonyc commented

@cgettings, hoping that you can do a QC on this when you have a few minutes. In hotfix-default-map-measure I edited renderMeasures.js.

For setDefaultMapMeasure setDefaultTrendMeasure and setDefaultLinksMeasure, there's a test to see if one of the MeasurementTypes in visArray includes "Age Adjusted Rate," then "Rate" then "Percent." This was failing because of our copy changes to measurement types: "Age Adjusted Rate" is now "Age-adjusted rate."

So, I updated to "Age adjusted rate" and changed "Rate" to "rate" so that it would catch "Estimated annual rate." I also realized I needed a condition to find things that start with Rate (capitalized), eg: in Elevated blood lead levels: one of the measures is Rate (10+ mcg/dL). So I added another condition for isRate, after hasRate.

I did this for the default Map loading, default Trend loading, and also default Links loading. I hadn't noticed any strange behavior on Links, but had noticed that it was the same code, so figured I'd edit it.

I'm going to click around and see if I can find anything amiss, but would love a second set of eyes on this. Thank you!

mmontesanonyc commented

Merged to dev.

mmontesanonyc commented

A few notes about possible revisions to maps. Here is a gist using hconcat for the map/bar.

  • I like this layout better
  • But, dimensions present a problem - we can't use "width": "container" since we also have to set widths for the bar and map. We could do that using JS, grabbing the dimensions of the parent element, taking percentages of that, and passing that to the spec.
  • This uses purplered as the color scheme and 0.25 to 1 as the extent, and I think it has some advantages over just purples.
  • And, I'd like to grab rankReverse and have the spec display greens for "positive" indicators.
mmontesanonyc commented

@cgettings - you mentioned color preferences. I went with purplered and blues. Thoughts? purplered seems to address the issue that we have with purples being a bit too pale at the bottom end of the spectrum, and blues lets us avoid a purple/green scheme.

This is just in map.js, testing defaultMapMetadata[0].VisOptions[0].Map[0].RankReverse and coloring accordingly.

However, am noticing some indicators where rankReverse = 0 where it should = 1. (in Housing Maintenance, housing Stability in particular - can create a list). Just an FYI - I'll do a review and drop into an issue in EHDP-data.

mmontesanonyc commented

@cgettings, the menus are looking great!

There are a couple tiny things I'd like to add to our list for this round. Could you let me know where branching stands? are m2m and separate-menus merged together somewhere?

  • Menus: let's change "Time period" to just "Time" (consistent with Table view) and let's pull the ellipses out of the menu labels too.
  • Trend charts: the button to chart label spacing on these is a bit different than the others - might be the pb-2 class on the menu button?
  • I'm not super happy with the indicator name chart title. I wonder if it's best to pull it out of the page, and put it into the chart spec.

By the way: @etorem mentioned being interested in color palettes generally, and @cgettings, I know you weren't thrilled with some of the colors in the DE. Let's put this in the back of our brains esp as we start the front-end support contract. The pink active state on the view tabs, the blue of the options buttons, and the colors particularly for the trend and links charts - all up for conversation.

  • 👍1
cgettings commented

My favorite palette is viridis and its siblings.

HVI uses magma from 0-0.9

——
The branch I merged into dev has all of my DE changes

I like the idea of putting the chart title into the spec. Super easy with the specs defined in the JS. Also means a saved chart PNG would have the title.

  • 👍1
mmontesanonyc commented

viridis has the benefit of basically being a shibboleth, a wink about being in the know to certain data-y types. One question I'd have is, how much do we want to work with the site's greens - or establish a vis scheme that's agnostic to that?

mmontesanonyc commented

hey @cgettings, I revised the title situation to pull it out of the page context and just use the title and subtitle in the VL spec. I think these match each other a bit better, now. We could also bold the title, but, I don't know if it's too necessary to get aggressive with titling. One thing we could do - but this might wait until we have professional design input - is to put the indicatorName and the options menu in a sort of surbar (think nav bar or breadcrumbs bar) above the chart. Would be best if that's fully integrated with the view tabs above it - but I think that all may be something that professional input would help with.

cgettings commented

@mmontesanonyc Cool. I was working in the -prod version of the branch, but I just integrated our changes. In my version, the map's measure dropdown says "Measure", the trend's dropdown says "Compare", and links' says "Link".

I merged into the non-prod branch, so you can pull that and see what it looks like.

mmontesanonyc commented

@cgettings - tons of stuff in here done. Should we close this out and make a new note-sy issue for things that we want to kick the can down the road on?

cgettings commented

Yeah, let's do that. Maybe when we start work on one of them, we can create a new issue for just that, the opposite of what we did here.

mmontesanonyc commented

Heh. Sounds perfect. I'll set that up.

mmontesanonyc commented

Issue revised, #534