WIP: Combined Filter/Layer UI

[NealHumphrey]

This is a partially working demo of a proposed combined UI for filter/layer data sets. This arose because both a) anything that is a layer could be a filter ("buildings in neighborhoods with..."), b) our test users didn't engage much with the separate 'layers' panel, and c) those that did engage with the layers panel were using it as a guide for filtering (i.e. see which Ward has the highest income level and then use that to dig into those buildings). Instead of having two separate ways to select data sources, we are proposing having only one list of data sets that can trigger both filters and layers.

Those who were discussing this last night, take a look and see what you think: @ostermanj @ptgott @wassona @jkwening @ableo57 , plus @thischrisoliver .

Things demonstrated:

• One single left hand sidebar
• Proposed icons to indicate neighborhood vs. building-specific data fields
• Proposed behavior of color coding triggered only with neighborhood specific data fields
• Demo with 2 data fields of 'neighborhood' data type

What's not done:

• Legends for overlays need to be put somewhere (probably at the bottom of the map per our earlier mockups)
• Zone selection has not been moved yet, so this demo cannot change zone type (i.e. ward vs. tract)
• In reality we'd want some big cleanup to refactor the code - this code imitates the layer functionality without actually removing the layer code.

[NealHumphrey]

Note, we'll probably want to have a bit more tweaking to the icons that are used for the two data types to better guide users to understand why some fields show zone data and some don't. Fundamentally it is whether the data is about the project or about the area that it is in, which should click pretty quickly. Maybe the best way to handle this is via a small-font, colored text just above the description that says something like "Project-specific data source" or "Data about surrounding area" (need better wording...)

[ptgott]

@NealHumphrey

This is looking good! Here are some thoughts:

1. I like the use of icons, since they indicate that the filter types are fundamentally different. If we want to make them even more distinct, we could go back to the original orange/blue coding. For instance we could give each title bar a white-ish background on mouse-out and a blue or orange background on mouse-over (depending on the data type). In any case, it might take the user a bit of practice before learning what the distinction between data types means. That's fine for me!

2. At the same time, would it be possible to turn all of the continuous filters (even some categorical filters) into chloropleths by aggregating the point-based data? This way we wouldn't need to distinguish between zone-based and project-based filters, and it might be visually interesting to represent conditions beyond the selected projects.

3. We could integrate the zone-focused categorical filter selections with the old 'divide by' zone selections. You'd choose a zone type, then between 'all zones' and an individual zone. We talked about using something like the dropdown menu from the righthand sidebar -- we could use the multi-select menu instead. This could also mean making the choose-a-zone menus visually distinct from the remaining filters.

4. I'm okay using this PR as the starting point for a broader reorganization. Shall we make it a separate branch that we can produce PRs against, like a parallel 'dev', until it's got all the features we want from 'dev'?

[NealHumphrey]

@ptgott thanks for your review!

1. Maybe a middle ground is making the icon itself blue if the data is chloroplethable? In my current demo, I switch the color of bar itself to blue when that item is the currently activated chloropleth, so doing the same on mouseover might be confusing. If this dual-purpose system is going to work we have to make sure users know what to expect to happen.

2. I don't think we can turn all things into chloropleths. For instance, 'subsidy program' is something that is specific to each building, but it's categorical. What would a chloropleth of subsidy program mean? The only way to make it work would be 'count of buildings that match your selected subsidy program' or perhaps 'percent of buildings that match', but then we're muddying the water between what a chloropleth means for neighborhood data vs. what it means for project data.

3. Yep, we might need to do some integration pull requests. You can in fact do PR's against any branch, and since I made this PR it's actually in the Code for DC repo instead of a fork. But, let's wait until the Thursday planning meeting to decide if we should actualy go down this path or not. Between now and then, I think doing a few more demos (either in code or in sketches) of our proposed changes - similar to this PR and to John's color coding PR - would aid our discussion a lot.