Remove hardcoded taxonomy terms and replace with customizable list of links

[monfresh]

Currently, the entire OpenEligibility taxonomy is hardcoded and displayed when no search results are found. There are two problems with this:

1. It assumes that the API will be using the OE taxonomy, which is not a valid assumption.
2. It assumes that each OE category has been assigned to at least one Service, which is also not a valid assumption.

Instead, when no search results are found, the entity that is deploying the app should be able to decide which links appear there, if any, and where they point to. For example, they could point to a keyword search or a category search.

I propose adding a new setting in settings.yml that looks something like this:

links_for_no_results:
  type_of_search: keyword | category
  links:
    - Emergency Food
    - Help Pay Rent

The idea is not to have a gazillion links, just the ones that are the most important for the community.

[anselmbradford]

Just food for thought... would it make any sense on the API side to have a keyword search query the categories first and then widen the search to the general keyword search if no results are found? Then the "type of search" in this case could be eliminated. If the categories are customizable I'm still not clear on the difference between category and keyword really. I guess it separates the taxonomy—which might be adhering to a standard set of terms—from any additional terms that might be added. But that seems like a data administration concern. From the search perspective, having a category search for Food and a keyword search for Food return different results doesn't seem like expected behavior to me.

[monfresh]

A keyword search is different from any other search because it is a broad search that looks for the term in many places. A category search, on the other hand, looks only in the Categories table, so I would expect it to return different results. Along with the generic keyword search, the API provides various more targeted searches to allow you to filter more precisely. The category parameter provides one of those targeted searches, just like the org_name parameter. Would you also expect an org_name search for "pantry" to return the same results as a keyword search for "pantry"?

In the example above, I added keyword and category as examples of types of search, but you could put any parameter supported by the API if you wanted to, or even make it an array to use multiple parameters. The whole point is to allow people to customize it however they want. Also, keyword as a type of search is not the same thing as the keywords field. Is that what's causing the confusion?

[anselmbradford]

The org_name difference is clearer, but a category is sort of a descriptive term for an entry, and a keyword is sort of a descriptive term for an entry also. Anyway, like I said just food for thought on whether there was an overlap there that could be eliminated. I guess for adding the filter for category the default label would be "Kind of service"?

[monfresh]

It seems like you are getting hung up on the term keyword. The API parameter names are arbitrary. Maybe the keyword parameter should be renamed to q or something, like other APIs use for a generic search parameter. The keyword API search parameter does not represent a descriptive term for an entry. It does not correspond to any single DB field. It's a way for people to enter a search term that will be matched across many different DB fields to get a broader result set.

There is no overlap between the keyword search parameter and any other search parameter. Each search parameter performs a specific and unique DB query and they can be combined to narrow down the results.

As for adding a filter for category, I don't think it makes sense to have a free-form filter for Categories because not all Categories could be assigned to a location. The best use of a Category filter would be as a link on the details page and on the results page, similar to what Aunt Bertha does. We already have the list of Categories on the details page, but it looks like you disabled the links because you felt there needed to be a corresponding filter in the sidebar. I disagree with that. Not all searches need a corresponding element in the sidebar.

Once the Category links are enabled again, they would be the equivalent of the OE category buttons that Aunt Bertha displays when viewing the details of a location. Aunt Bertha doesn't show you every possible sub-category and you can't manually enter a category name because those are fixed and entering a term can very often lead to no results. For this type of search, it's a much better UX to do the filtering for the user and show them only categories that have results.

[anselmbradford]

The search area is a visual representation of the search that was performed, so yes, I would strongly prefer there was a difference in the search sidebar for http://ohana-web-search-demo.herokuapp.com/organizations?category=Food and http://ohana-web-search-demo.herokuapp.com/organizations, for example. The URL query string, search results and search inputs in the sidebar are all tied together, so any change in one should represent a change in the other two. What is your disagreement with that? I agree free-form text isn't the best input for the categories, but we don't have to use a text input for it.

[monfresh]

Why does the search area have to be a visual representation of the search that was performed? Why do they have to be all tied together? Why would it not be acceptable to have just one general search field, and have all others filters available via links only, like on Aunt Bertha for example?

Or look at GitHub, they have an advanced search with a ton of options that don't follow you everywhere. If you search for repos with the term "ruby" and with 0 to 100 stars, you don't see any UI related to stars in the search results: https://github.com/search?q=ruby+stars%3A0..100&type=Repositories&ref=advsearch&l=
The search results page only has 2 basics filter sections in the sidebar: one for languages, and one for what entity to search in (repos/code/issues/users). That seems perfectly fine to me.

Having a 1-1 mapping between the search parameters and the options available in the sidebar feels like forcing something where it doesn't have to be. As I see it, disabling the Category links in the details page means we are intentionally removing useful functionality, and for a reason that I would wager most people visiting the site do not care about. I don't see any harm at all in enabling the Category filters on the details page while we decide whether or not and how to include them in the sidebar or elsewhere on the results page.

[anselmbradford]

I get what you're saying with links, because the web is filled with links between documents that are one-directional—you click a link and go somewhere. On the web, there are virtually limitless numbers of pages and website designs that are linked together. If we look at the tolerance principle of UI design, which essentially says a system should allow users to undo/redo their actions—the web's not a system that allows undo/redo for clicking a link. So to handle that, the navigation UI has been offloaded onto the browser as the back/forward button; or the linked webpage has a link back to where the user just was (ala 'home' buttons).

I view our project as a web application more than a website, meaning we're not under the constraint of having limitless variations in UI across all accessible pages on the site. We have the luxury that we can include a UI to navigate down all possible roads and back again.

As an analogy, supposed we just had a next page button in the pagination UI control and eliminated the previous page button. We could do that and rely on the browser's back button for navigating to the previous page, but having a mix of methods to navigate around the application isn't very consistent. My problem with the category links is they are dead-end streets, navigationally. They tie into the search results, but unlike other searches, to remove them you have to edit the URL, hit the browser's back button, or perform a new search.

In the github example you do have an update to the search interface in that there's text in the search input box. The search inputs are still changing based on the URL. This is different from http://ohana-web-search-demo.herokuapp.com/organizations?category=Food. I would be fine if the category search term showed up in the main keyword search box, but since they are different searches this wouldn't work unless we performed the category search behind the scenes—which ties into what I was getting at earlier on whether they could be combined.

I think this ties into #483, would you be okay with category filter and links that could be added/removed through a setting?

[monfresh]

I'm not sure what you mean by this statement:

[...] unlike other searches, to remove them you have to edit the URL, 
hit the browser's back button, or perform a new search.

Don't you have to perform a new search in any scenario to "remove" a parameter? How do the keyword, location, or agency searches allow you to remove them without performing a new search? How is a category search a dead-end street? What do you mean by that? You can't go forward after performing that search?

It seems like you think performing a new search to get rid of a search parameter is wrong or cumbersome, but isn't that how everyone uses Google search? Here's a scenario I would consider perfectly normal:

1. I go to http://ohana-web-search-demo.herokuapp.com/
2. I search for "food"
3. I click on "Meals on Wheels - South County"
4. Assuming the Categories there were clickable, I click on "Food", which would take me to this URL:
   http://ohana-web-search-demo.herokuapp.com/organizations/?category=Food
5. Now, if I want to search for something else, I just type a new keyword, or agency name, or location, or any combination of the three. Isn't that what most people would do?

When you click on a Category link from the details page, it performs a search with only one parameter: category. Let's say we had a button on the sidebar to remove that filter and automatically redo the search without the filter. It would just return all locations, which isn't particularly helpful.

If we provided the ability to perform a category search in conjunction with other filters, then it would be helpful to have a way to remove the category filter, similarly to how Airbnb has multiple filters you can turn on or off. But because of the particular nature of the Category, it isn't well suited for this type of filtering from the sidebar.

Using OE as an example, it has 327 categories, and you'd have to present the exact category names to the user, because the API currently only looks for an exact match (I forget why but I think there was a reason for that). But you wouldn't want to show every single category because only a fraction could actually be assigned to a Service. The API could add support for returning only assigned Categories, but that number could still be too large to display each category.

I think the best use of the category filter is what Aunt Bertha is doing, where you start with one of the top level categories, and then you can click on sub-categories to browse that way. Having a category filter in conjunction with a location filter would also be very helpful, but that would mean redesigning the search interface to be more map-driven, so that you could "redo the search in this area" while preserving all other search parameters, like on Airbnb for example.

On Aunt Bertha, you can't change the location, which I've always found strange. You have to enter a ZIP code when you first enter the site, and then after that you're stuck with that ZIP code unless you go back to the home page and start again with a new ZIP code.

As for your last question, yes, sections of a page can be conditionally added based on a setting. I'm assuming that this is something you will be working on later, not as part of my simplify-filters PR, right?

[anselmbradford]

Don't you have to perform a new search in any scenario to "remove" a parameter? How do the keyword, location, or agency searches allow you to remove them without performing a new search? How is a category search a dead-end street? What do you mean by that? You can't go forward after performing that search?

For the existing searches you can add/edit/delete the filter and perform a search. For category, if turned on, you can't. Once clicked, it's added. Depending on what behavior we had for a subsequent search it would be removed or included, but there's no control over widening or narrowing the search in regard to Category. That's what I mean by it being a dead-end street, subsequent searches don't have to do with the Category anymore, at least not under the user's control.

It seems like you think performing a new search to get rid of a search parameter is wrong or cumbersome, but isn't that how everyone uses Google search?

Google is an add/edit/delete search interface.

But because of the particular nature of the Category, it isn't well suited for this type of filtering from the sidebar.

If this isn't a filter that's meant to be combined with the others, I'm still not clear why it couldn't be part of the algorithm for the keyword search, but you'd know better than me on the downside of that.

I think the best use of the category filter is what Aunt Bertha is doing, where you start with one of the top level categories, and then you can click on sub-categories to browse that way.

It seems like this is a UI input issue. Aunt Bertha kind of uses breadcrumbs, but it gets a little messed up... e.g. observe the inconsistencies in clicking "Food" and the various ways to click "help pay for food."
Like you said editable free-form text doesn't make sense, but I'd just like to see some indication that the Category has been applied in the design.

The API could add support for returning only assigned Categories, but that number could still be too large to display each category.

This seems helpful if feasible within our constraints. This would make category > sub-category breadcrumbs possible, if needed and desired, for instance.

[monfresh]

Going back to the original issue, would it make more sense to just re-use the list of links on the homepage here, instead of having to define another set of links? Presumably, the links on the homepage represent the most important or most common searches for a community, so might as well display them when no search results are found.

This is the solution that makes the most sense to me. Keep it simple.

Here's what it looks like:

[anselmbradford]

Sounds good. We can always add more links here if needed.

[monfresh]

Fixed a while back: https://github.com/codeforamerica/ohana-web-search/blob/master/app/views/component/locations/results/_body.html.haml#L13-27