and it stays removed even when you select another icon

lots of our data is just enumerations of labels.

be able to display only a subset of point by selecting some labels. Deciding on a good interface for this is part of this story.

interface possibility: http://jiren.github.io/filter.js/filterjs-map.html
(filter.js itself is probably too heavy for this project though)

A couple weeks ago, there was discussion about possible map styling. I ran into this today for Google Maps:

http://snazzymaps.com/

And probably shows the titles for all the fields even when they're missing data. The templating should change to skip missing fields entirely.

live version via watchify

I'd like to make make the site as data driven as possible, while still allowing people to fine tune things with the config file if they want.

Things in the config file that might be possible to replace with sensible defaults:
map.center - calculate the center of the data
map.zoom - pick a good default zoom level
map.bounds - no default boundaries
max.zoom - hardcode this in based on the resolution of the

properties - if there are no properties then display every item in the properties section of the json intelligently.

• use the key for each item (converted to Title Case) as the title
• recognize email/web addresses and display as mailto/href links.
• display lists as lists

search - include the search by default and allow the config file to turn it off?

facets - probably just make these off by default. If there was an easy way to pick facet-able properties that would be cool, but I can't imagine one.

There are also some config features I'd like to add (while keeping the current defaults.) Where the border between what should be a config file change and what should require a code change should be are not clear. If anyone has thoughts on how to finesse this split please discuss.

• allow people to change the default tileset with their own

There should be a way to see a list of the items, in addition (or instead, in the case of mobile) to the map view.

let people search (aka center the map) by their current location or a user-supplied location. Zoom to an appropriate level to show a reasonable number of locations.

If people are going to use Finda instances on mobile, it'll be more convenient if it gets an icon on their homescreen like their regular apps.

Idea via http://www.quirksmode.org/blog/archives/2014/03/the_app_is_a_we.html

Might need to add a config element for which property is the name.

Pantry Pickup has nice mobile support, and it would be nice it we replicated that here. Probably a chunk of the CSS could be used fairly directly.

Right now, there are parts of style.css which configure things for the user (the #phone_number/#address/#organization_name lines) and the rest which set up the default styles for Finda. For clarity, maybe this should be refactored, either:

• moving the Finda-defaults into a file we @import from style.css, or
• moving the user-customized styles into a local.css (or similar) which we include from style.css.

Make a place for users to drop in a logo.

If they drop in a logo, the application name in the nav is replaced by the logo.

Should use sensible defaults re: sizing.

Look into leaflet's bounding box functionality.

http://leafletjs.com/reference.html#latlngbounds

It would be nice to track who's using Finda, what browser/OS they're using, and what they do with the app (do they search for addresses? Do they filter? How many features do they look at.

We should hook up some kind of analytics so that we can get some of this data, at least by default. Probably it should be configurable, so privacy-conscious groups can disable it.

@ohnorobo suggested a sparse map with streets and some features.

tiles.mapc.org seems like a good choice considering those criteria.

JSBin gives people an easy way to show off little snippets they've written. It would be nice if Finda had an interface that had Finda on one side, and config/data boxes on the other. Then users could put data right into the page and immediately see what it would look like.

Since a lot of the datasets to be used by Finda may be public-services related, maybe we should look into a dead-simple integration with Ohana API as a configurable alternative to local JSON.

I don't really like the word "requirements" (is there a better word?), but there are some things that pull requests should have and we should write those down so we can point people at them.

• tests/lint should pass (npm test)
• Javascript changes should have tests
• documentation?
• other things?

It might also be good to a have a pointer to codeforboston/lgbtq-data for data changes.

It should be possible to interact with Finds:

• with the keyboard
• with a screen reader
• if you're color blind

Bootstrap has some docs, and there are some testing resources online.

Once you've opened the collapsed menu (small screen) it doesn't roll back up.

Current code in infotemplates.js was originally written for Mustache.js. Handlebars has somewhat more powerful tempting. Refactor to use partials and/or helpers.

I genuinely think this platform could be the next Adopta. And while the documentation says Finda, the repo is still called filter-template.

I'd like to propose that we change the project name & repo name to Finda. I'd like to do a temperature check on this to see what people are thinking. (This is not a poll.)

Would you please leave a 👍 in the comments if you agree, a 👎 if you do not? Thanks! (Type ':' followed by a +1 or -1 to get the thumb icons.)

dropping people straight into a map is probably confusing. Instead some sort of directed landing page will help people understand what they're seeing.

I'm partial to http://www.smc-connect.org/ 's landing page. Part of this story is to discuss design choices and options.

Right now, the default grays aren't particularly exciting, especially in contrast to the OSM map tiles. It would look much nicer with some color.

Ideally, this would be commented well in styles.css so that it's clear what needs to be updated if other users of Finda want to update the visual style to match their own group's style.

config.documentation.md is slightly out of date:

• doesn't include project or search or geojson_source
• maxZoom should say what the highest value is (18?)
• properties documentation:
  • should include 'image'
  • should be clearer that having an empty property list in the config displays the property value as plain text
  • (maybe) clarify that the properties get an ID with their name, for styling

All good projects have a logo.

There should be a link in the app to the repository so users have a way to get started with contributing.

Perhaps this is something for #14?

@calvinmetcalf pointed out that we're in violation of the Google TOS by using their geocoder without the maps. We should switch to the OSM geocoder.

even if the icon is still visible under the new facets.

I've heard reports of troubles using the site in IE. Legacy browser support is probably too much to ask, but compatibility across all modern browsers should be a goal.

in this issue: include any browser specific problem you're seeing with browser and version number.

I had the interesting experience of searching for a solution to something, and finding some code that was very similar to what we're already doing.
recline.js's view.map.js
demo select the map view

Recline already used backbone to structure its data. This is something I
a. already wanted to do
b. am not really qualified to do
before I got too far into the whole filtering/events part of this application

so having something which already sets backbone up sensibly would be helpful, and using a framework for a lot of other things would also be nice.

For making admin updates, it would be nice if there was a mode which allowed changing the data for the feature and exporting the updated data.

The best way to make this app really general is to test it out with lots of different datasets.

Tasks:
find/create geojson formatted data
make git branches with different data and config files

find pain points/needed features in the current setup and make other issues as needed.

• When a feature is selected, the hash (part after a #) should update with an ID for the feature
• if the page is loaded with a hash that matches a feature, it should select that feature

Whenever we replace the icon/feature (i.e change from blue to gray icon on click event) we have to rebind the tooltip to the feature w/ an offset to get it in the right spot. This does not happen when you close the info section & the icon reverts to default blue.

Currently, they're always displayed as a blue (grey if clicked) pin. It should be possible to have them displayed with different images. Ideally, it would be possible to tie the image to a property in the GeoJSON file, so different types of features could be visually distinguished.

Not sure we want to support this in the default Finda installation (since we'd have to update it on pulls), but we should at least document how to use the application cache to make Finda work offline.

Right now, when the user is geolocated the map centers on that location, but there isn't a visual indication of where that is.

Needs some discussion about how it works.

to reproduce:
zoom out
click an icon near the edge

problem:
the map moves twice, once to center the icon, and once when it bounces back inside the 'maxBounds'

solution:
increase the max bounds so even fully zoomed out every selection only causes the map to move once.

Nomatim returns the type of node with the result. We should zoom to an appropriate level for that base.

and go back to their normal color when another icon is clicked

Right now, once you've clicked on a facet there's no way to close the popup. Especially on mobile, this makes the app hard to use.

We recently added better docs for users. We s should also have some getting-started docs for developers:

• links to docs for the libraries we're using
• how the code is organized
• code expectations (tests, organization, &c)?
• style guide?

The facets take a big chunk of the page on smaller screens. Some things I can think of:

• have the facet popup roll up to just show a title, and then tap on it to unroll
• have a set of tabs at the top (like Pantry Pickup) and include a "Filter" tab
• have an icon at the bottom to reveal the facets, and a close button to hide again

If we know where the user is (either via geolocation or by then searching for a location) and they don't have the infobox open, then we should open the closest one for them.

For now, maybe desktop only since the infobox takes up the whole screen?

MAPC tiles are very cool looking, but they only cover Mass.
A sensible default would be to use the old Mapquest tiles (or something more neutral if you can find it), and have a config option to change the map/attribution.

The gh-pages branch should be configured to use the current MAPC tiles.

When values are selected for a facet, there should be a clear link which resets the state.
#12 has a relevant screenshot.