Improve Filter by Intersection UX

[clhenrick]

Based on comments to GreenInfo-Network/nyc-crash-mapper-chart-view#73

It seems like Intersections are a much different geography type than contiguous polygon boundaries and that they warrant their own special handling in terms of using them to filter crashes.

Instead throwing a 1,000 tiny polygons on the map and cramming intersection names into the side of the UI next to the filter by area buttons, why not just make a separate UI for them that lists them so that they're readable and easier to interact with / find?

There could be a search input with a dropdown below it that allows for a user to type in the name of an intersection and/or select one from a drop down. When the app loads, the names of all the intersections could be fetched to create the dropdown list which would be hidden until a user starts typing in the input. A text search in the input could filter the names displayed in the dropdown as the user types. When an intersection name is selected from the dropdown or by hitting "enter" on the keyboard when the input is focused, a network request would be made for the crash data and the map would zoom to the area of interest.

The search input and dropdown could live in the upper left of the page, similar to a search input for geocoding an address.

A couple downsides with this approach I see are

1. It doesn't live in the filter by area panel and may be inconsistent with the map's filter UIs

2. It could be confused with an address search rather than intersection search

3. It might be difficult to know which intersection I'm selecting as intersection names are not unique

For #1 I think this is justified because intersections aren't really boundaries, so it's odd for them to live under filter by boundary. For #2 I think either having an explicit "search by intersection" or even a toggle that switches between searching by "intersection" and "address" if address geocoding is a desirable feature to have at some point in the future. For #3 the borough name and perhaps neighborhood name or zipcode could be listed next to the intersection name to help clarify.

Currently selecting intersections on the map is problematic. When I enable intersections by clicking the button in the UI and am at the default zoom level of the map (zoomed out pretty far), it's not apparent that anything happens / I can't see the intersections on the map. Only when I start zooming in do I actually see the intersections appear, so the "select by clicking" only method has some usability issues.

---

@danrademacher's response to the above:

The best solution here would probably be to replace the boundary buttons on the map with the more flexible module we use in the chart UI. That would address UX issues you highlight, and which we’d already considered, but without introducing an entirely new element.
But client priority at present is seeing Intersections in chart views, so we needed to take a minimalist approach to adding them to the map. I expect we’ll get another bite or two at this apple.

Re-purposing the list UI from the chart view would be helpful, but how would that solve the "select by clicking polygon on the map" for intersections? For other geographies having the list and being able to click on the map would be a usability improvement for filtering by a geographic area, but with intersections the polygons would still not be visible on the map at the default zoom level, which would still leave the inconsistent UX with how other geographies can be selected. Furthermore many intersection polygons overlap with one another which makes selecting an intersection area confusing.

Listing the intersections without other information such as borough / neighborhood / zipcode would also make their selection via a list cumbersome and confusing as intersection names are not unique, and adding that extra info to only intersections would still mean cramming it into a small side bar.

Having a separate UI and UX for searching by intersection would be more "natural" to how one searches for an address in Google Maps and allow for more screen real estate to display other geographic info to an intersection such as the borough name.

[danrademacher]

One challenge with an address search approach is that we are not actually including all ~20-30k Intersections in the app, but only the 500 most dangerous over last 36 mos. Not workable to have them all. Though we do need to make clear that we’re talking only about a subset of Intersections.

I’ve wondered about finding a way to show markers when more zoomed out and circles only when zoomed in, but first we have to address other tasks in getting top 500 Intersections working in charts

[clhenrick]

For the map, why not just add a geocoding / address search option, then pass the result to PostGIS with a buffer radius to intersect the crashes? The user flow could be:

1. user performs an address / intersection search
2. show result on map and zoom and center the map to it
3. give the user an option to filter crashes by search result lat lon
4. buffer lat lon by n meters and use that to do a spatial join with crashes

realize that this doesn't mesh with the 500 top intersections of the charting part of the app but it would be fairly simple to implement.

Alternatively, markers could be used for all zoom levels, is there a reason why the buffered intersection polygon needs to be displayed when selecting? I could see displaying the outline after selecting the intersection being useful, but beforehand it seems odd.

[clhenrick]

Noting that I began to implement the address search --> filter crashes feature in #81

Still some work left to do but shouldn't take long.

[gregallensworth]

Dan and I agree, this is a nice new tool, the address-and-circle system.

Would it make sense to bounce the geocode-point off CARTO to generate a 90-ft (27.4 meter) circle in GeoJSON format, then apply that as a custom geography as if drawn? Custom geom already has URL param support, charting support, etc. so that route could be the most parsimonious.

• text input box, styling: font size, font color and fill color, etc.
• text input box, position to alignment with +- buttons
• popup geocode result box, style and color
• popup geocode result box, alignment to +- buttons and input
• popup geocode result box, Search Again just closes; X instead?
• map marker add 24.7m circle to pre-indicate area

I have some availability this week, and would be glad to take on some of this as well.

[gregallensworth]

The above set of commits brings stylistic updates, and a minor functional update:

• Styles, colors, and positioning on the geocoder box and the results panel
• Results panel has a X to close, instead of Search Again
• Geocode on-map marker is now supplemented with a L.circle

And one item not closely related, but opportunistic:

• GeoJSON polygons style is now defined as the geoPolygonStyle constant, instead of hardcoded into LeafletMap/index.js

Still to do:

• Styling of result box, if any (approval of grey, or not)
• Discussion & implementation of filtering technique here: remap to a Custom shape, or what?

[clhenrick]

Nice improvements @gregallensworth 👍

I think we might be able to use the existing "filter by custom area" logic, but it seems that we should be careful of side effects and to not force that part of the code to be too flexible / abstracted.

For example, if the search geom is stored in the query params, and the app is loaded with it, does the app load with "custom area" selected? That might be confusing for users. An alternative could be to store the search lat lon and geo=search in the query params. Then when the app loads it would use the buffered lat lon to spatially intersect the crashes.

Question: Would this feature replace the existing "intersections" in "filter by boundary"? Or just augment it? I would argue for replacing it as it's an improved UX. We could also pipe the intersection from the chart app to the geocoding API if a user moves from the chart app to map app with an intersection selected as the primary entity. On the other hand a user would probably run into a situation where they selected an intersection in the map that might not exist in the list in the chart app. Though the chart app could be modified to use similar SQL in the map, to buffer the search lat lon and do a spatial join with the crashes. cc @danrademacher

[gregallensworth]

As of 03b2da2 the result popup now clearly states the filtering radius.

[danrademacher]

Regarding this:

Question: Would this feature replace the existing "intersections" in "filter by boundary"? Or just augment it?

I don't see this replacing the "500 Worst Intersections" as we have them now. The core use case for Christine is the intersection rank view, and everything else supports that.

I can see that she'll be delighted to be able to compare any arbitrary location as a Custom Geography to those 500 (under Trend or Compare views), but I can't see that she'd be satisfied with removing the Rank list in favor of a single intersection view on the chart application.

[clhenrick]

Okay but the "500 Worst Intersections" as currently implemented in the map app under "filter by boundary" is a broken UX.

I still think the search UI could provide a way to show a dropdown list of the 500 that would provide a more intuitive way for a user to select them and then see what they've selected instead of truncating the intersection street names to a few characters to the right of the buttons. Selecting the "intersections" option doesn't reveal to a user that anything happens or that a next step can be taken.