Major components of the site should be easily added/removed through configuration

[anselmbradford]

The bay area pilots and others have requested that the inclusion of major components of the site be configurable through settings. As a start this should target the search filters and provide a means to easily add and remove them site-wide without needing to hunt through the code for dependencies. This might look something like a boolean setting in config/settings.yml for each search filter. When set to true the filter would be included, when set to false the filter would be excluded, filter-specific links would be disabled, tests would be disabled, etc.

[declan]

This is interesting. What other major components are we talking about, beyond the search filters?

[anselmbradford]

Right now this would be:

• Search filters (as you mentioned).
• Geolocation (if this sounds like a reasonable direction for #471).
• Possibly possibly the fields shown on a location details view. The data could also be removed from the API directly so it won't show up in ohana-web-search, but there may be circumstances where it's desirable to have ohana-web-search have control over these field's visibility as well. For example, two ohana-web-search interfaces that are interested in different data targets, but are feeding off the same API. Or an ohana-web-search instance may want to include keywords while another may not, as surfaced in https://github.com/codeforamerica/ohana-web-search/issues/476.

Any other components you are interested in including/excluding?

[monfresh]

Let's be careful not to take customization too far here. Once we get beyond simple localization of text and logo changes, and into HTML restructuring and conditional disabling of tests, then we need to assess the situation a little more closely. @anselmbradford What exactly was the original ask from the bay area pilots? Did they specifically ask for search filters customization or was that your suggestion?

[anselmbradford]

Search filter customizations were @declan's request. @siruguri asked about adding/removing components of the site through configuration in regard to the pilots, maybe @siruguri can clarify what was desirable to be able to include/exclude here?

[siruguri]

Hmm... @anselmbradford, I'm not quite sure what I had said, that you were referring to, sorry abt that :) My most recent memory is basically the fdbk from Declan, maybe I talked about wanting to have a more general architectural discussion, about what such a configuration would look like? For example, would there be separate conversations about pluggable backend (search behavior) vs frontend (filters shown) customization?

I agree with @monfresh that we shouldn't take customization too far, maybe starting with where @declan is at, is reasonable.

[declan]

This might sound silly since I know I've done nothing but make customization requests for the past six weeks, but I actually agree with @monfresh that it would be possible to take customization too far here.

The client app is really, really good. It's got a smooth UI and a simple code base, and it's been getting better by the week in the brief period of time that I've been using it. While I have made a bunch of customization requests and will probably continue to do so, I really don't want that to interfere too much with your efforts to improve the core application.

Is there currently any yardstick for evaluating how much customization is reasonable? Knowing what's fair game for customization has been an open question for me for the past six weeks and I still don't feel like I have a very good understanding of it. I know this has been frustrating for you at times, so maybe this is a good opportunity to lay out some overall guidelines so that I'm not constantly trying to pull you in a direction you don't want to go.

[declan]

I'm going to try to answer my own question about a yardstick here, summarizing from a handful of different conversations over the past weeks. It seems like Ohana Web Search is intended to

• Work out of the box on Mac and Linux
• Be customizable by non-coders
• Only support customizations that most deployments will need

Does that match up with the understanding of everyone involved?

[monfresh]

Kind of. The basic customization (settings.yml, application.yml, en.yml) should be as simple as possible. Obviously, more complex customizations will require some coding or hiring someone.

Nothing will "work out of the box" on a brand new machine. Installing the app locally has prerequisites, and deploying the app to Heroku requires at least the Heroku toolbelt as mentioned in the Wiki.

I would also add that the base layer should be as simple as possible. For example, we recently simplified the search filters to be 3 simple search fields that everyone knows how to use and that provide a quick way to enter a search term. What we had before was too complex, required about 400 lines of JS, a bunch of logic in the view that was very hard to read and understand, some inefficient code in the controller, and intermittently failing specs.

[monfresh]

Can we close this? I think we came to an agreement that this is not a desired direction.