codeforamerica / trailsy Goto Github PK

Adding text/numeric fields to the tables is easy. Adding a picture, unless we want to store a whole bunch of binary data in a table, can be problematic.

We can:

1. do that, or
2. we can find someplace to store static images, or
3. we can create/move-to a more fully-fleshed out REST resource server instead of using the current simple staticJS->CartoDB setup, or
4. something else I haven't thought of yet.

We have no geodata for the MPSSC Freedom Trail, so clicking on the trail name causes an error.

There are two MPSSC "Parcours Trails." Perhaps the trail name should include the park name.

There are one CVNP and two MPSSC trails called "Ledges Trail". This causes confusion within the Trailsy MCP. Should probably tie a park name to the trails somehow.

Each trail (or combination of trails) typically includes several segment linestrings. Leaflet can display them all at once, but the overlap is visible at times. Changing the trail stroke opacity to 1 should fix it, but there may be less ham-fisted ways to change the trail display. (on the data side, a normalized DB--less likely given the data standard--or a trickier SQL query might do the trick.)

The Towpath, Bike & Hike(, and Freedom?) Trails aren't typically used for their entire length, so reporting lengths and filtering on them may be misleading.

A couple of options off the top of my head: 1) Treat them as special cases with no real length for filtering and reporting. They might show up for all searches regardless of length filters. 2) Chop the trails into segments at trailheads and report on them individually. (1) seems like a more practical idea at the moment.

I am not sure it is necessary since the listview highlights which trials are part of this trailhead.

Also, it obscures map.

If I'm interested in starting my trail trip from a particular area, and I zoom into that area on the map, then click on a trailhead that connects to a large path like the Towpath, the map zooms all the way out to display the entire trail, and I've lost my current map location.

Perhaps on a trailhead click we should only zoom in, and never zoom out automatically, or not zoom out beyond a certain amount. That could make the zoom action less likely to be disruptive.

If we are going to enable one photo per trail, why not enable a carousel.

Photos are an asset folks have in spades.

Should look into RRose (http://erictheise.github.io/rrose/) for popups that react to div edges appropriately.

see: Mingo Trail

it feels weird

Clicking on a trailhead brings the relevant trailDivs to the top of the trailList: that's good.

It selects the first trail for that trailhead and highlights it on the map: that's good.

It doesn't show that first/selected trail in the detail panel if it's already open: that's bad.

Clicking on a trailDiv in the list shows a marker icon (pointing to the trailhead) and the popup (pointing to the marker).

Clicking on a trailhead on the map just brings up the popup (pointing to the trailhead directly).

There are some trails and trailheads that are in both the CVNP- and MPSSC-provided data. Right now we're displaying both. As part of upcoming data discussions, the partners should probably try to decide who will be responsible for which parts of the data.

I think one of the easier ways we can communicate the somewhat complex filtering scheme is by using visual communication.

We could design icons for bikes, dogs, wheelchairs, length, distance, etc. and use a highlighted/greyed-out dichotomy to communicate which filters are active.

What do you think @katielewis ?

What is the extent of a given implementation? How do we communicate that? What are our funnels for folks that live outside the relevant radius?

This is a lower priority feature, since we have not seen much interest in the use case. However, it seems like a valuable feature, particularly on mobile when the user is on-trail.

...so we can transfer it to the Code for America Github account.

Using the data we've already received, we should produce trail standard (as it is now) .csv and .geojson files for the partners to use as examples.

Leaflet's popups always point south towards their target, which works great, except when the trail is primarily to the north of a trailhead, in which case the trail can be covered up by the popup. Need to look into the Rrose plugin (http://erictheise.github.io/rrose/) and see if its directional popups can be used outside of that plugin's primary use.

Sometimes, when clicking from trailhead to trailhead, the popups start appearing offset from their intended position. It may have something to do with the timing of the zoom/pan.

Once #11 is resolved, that location needs to be used to sort the trails on startup and on "redo search" button.

To facilitate quick scanning and decision making, we should try and surface the most relevant bits of metadata on the trails as easily as possible.

One way to do this would be through some "progressive reveal/disclosure"

https://blog.recurly.com/2013/04/masking-complexity-through-progressive-disclosure/

For example, on hover or click of a list item, we could show some metadata (dogs OK, etc.) that would allow for easy comparison, without opening a full detail panel.

Some trails have duplicate entries--could be a data issue or a logic issue. Tends to happen with trailheads that have three trails, but not exclusive to those.

Like "Wetmore: Valley Trail"

This way, other info can go in that space (trail length, difficulty)

The detail pane shows the last trail listed for a trailhead regardless of which trail is selected. Guessing it's a loop/closure issue.

Clicking directly on a trail at the moment shows a popup with the trail name. Should that also change the current trail selection in the trail list and detail pane if it's visible?

There are still a couple of trailheads without matching trails. Need to investigate.

based on feedback that people would like to see what trails are nearby and routes to get to them

If you don't know any better, the organization of information isn't immediately grok-able. Trails vs. Trailheads is inside baseball. Thus, it's confusing to see a trail multiple times in the list, when it appears due to it's multiple access points.

Let's visually, and in interactions, associate list items that share the same Trail Name.

Should look into the built-in leaflet.js tracking methods.

The Oxbow and Overlook Trails in Cascase Valley Metro Park - South are listed as individual trails on the web site, but the GIS data supplied has one "Oxbow/Overlook" trail. They either need to be separate trails in the trail metadata file or in the geodata.

On rare occasions (5-10% of the time?), the colors of the trails on the map are out of sync with the colors of the trails in the popup.

UPDATE:
The active trail order should be stored in the trailhead object, not created based on the order of trails returned from a trail path request. Currently active and inactive trails are both in the trailhead "trails" array.