How do we most effectively use Filters/Facets and Target Terms?

Data Management
1

One of the most popular features on sites like [search.wa211.org](https://search.wa211.org) is the sidebar filters ([see an example search for Utility Assistance in Spokane County]( https://search.wa211.org/search?query=BV-8900.9300&query_label=Utility+Assistance&query_type=taxonomy&location=Spokane+County,+Washington,+United+States&coords=-117.42503,47.659016 )).

Our clients often debate how these filters should work, and it sometimes causes confusion. When someone selects a facet like “Veteran,” should it boost results that have that facet, or filter out results that don’t?

A solution to this question needs to balance the needs of both help seekers and data managers. I think of these needs as two user stories:

  1. As a help-seeker, I want to quickly find the resources that fit me best, so I can focus my time where it counts.
  2. As a data manager, I want facets to make resources easier to browse without adding much work to managing data.

What doesn’t work

One approach I’ve seen fail is adding a facet, like “Veteran”, and then tagging every record that veterans qualify for. This causes two problems:

1. It’s the most work for data managers. Every record a veteran might qualify for has to be tagged, or it gets left out.

2. It hides specialization. Many resources serve veterans, but there may be a few that are extra relevant. When _everything_ is tagged, those few don’t stand out.

A better approach

I propose an approach that minimizes management and helps prioritize relevant results at the same time:

1. Data managers should be able to create and add facets to any resource.

2. Beyond just selecting facets for resources (think a checkbox), let each facet be set as either a Target or a Requirement:

  • Target: Boost this resource when the facet is selected.

  • Requirement: Hide this resource when a *different* facet in the same group is selected.

Today, filters usually work like this: “Hide everything that doesn’t have this facet.” That forces data managers to tag every possible record for each facet, which is especially arduous for broad facets such as target populations.

Instead, we should add facets only when they are significant differentiators; otherwise, they should be left blank by default. Further, Requirements should only be used when a help-seeker would be turned away for not meeting it.

An example

Say we have a “Gender” facet group with three options: “Woman,” “Man,” and “Other” (kept short for this discussion).

  • Target: I mark “Woman” as a Target on a transitional shelter. The shelter serves all genders but focuses on women. If someone selects “Woman,” the shelter is boosted. If someone selects “Other,” the shelter still shows up, just not boosted.
  • Requirement: I mark “Woman” as a Requirement on WIC. If someone selects “Woman,” WIC stays in the results, along with everything else tagged “Woman” and everything with no Gender facet selected. However, if someone selects “Man,” WIC is filtered out.

In short: WIC is for women. If we don’t know someone’s gender, we keep WIC in the list because they might be a woman. Once they select “Man,” we can safely remove it. For resources where gender doesn’t matter, we ignore the Gender group entirely.

Where this gets tricky

Requirements work best in groups where a person usually fits only one option. Then, when someone picks one option, it’s safe to hide resources that require a different one.

Some facet lists in use today would need reorganizing to work this way. For example, I’ve seen “Target Populations” lists with more than a dozen options. Even if one of them, like “Veteran,” is sometimes required, a veterans-only resource shouldn’t disappear just because someone selected “Homeless,” because a person can be both homeless and a veteran.

From this, I’d suggest two tips, although I’d love feedback on them:

  1. Split large facet groups into smaller groups of related options where a person would only pick one.
  2. For large groups that can’t be split, skip Requirements and only use Targets.

Open questions

  • Are there cases where a resource needs more than one Requirement in the same group?
  • If so, does that usually mean “requires any one of these” or “requires all of these”?
  • Are requirements and eligibility one and the same? Under what conditions could requirements be _not_ eligibility-related?
  • What other questions should we be asking about facets?

Conclusion

My thoughts are heavily informed by years of feedback from Hannah Newton, Lindsay Paulsen, Sasha Rienoso, Cathleen Dwyer, and others.

I’m keenly interested in feedback from our stakeholders in Connect 211 and the broader Open Referral community.

2

Just a small caveat since it is a resource from my system that was highlighted :slight_smile: the data manager for that area definitely over tagged services with filters, and we have been removing them as we can.

I like the idea of boosting vs. hiding, but I am not sure the Requirement option is workable because there are too many and/or variables. Like in your scenario, a person would need to check homeless and veteran, but for shelter a person couldn’t be a woman with children and a woman without children even though it is a requirement that someone be one or the other.

To answer your question, “Are requirements and eligibility one and the same?” I would say no. If a food bank is only open on Wednesdays, I would put Wednesday as a requirement, but it is not an eligibility.

What I wish filters did better is not just boosting resources you are eligible for but actively removing resources you are not eligible for. For instance with rent assistance, we have resources for veterans, for college students, for people with cancer, etc. and sometimes it’s hard to find the services that aren’t targeted. I created a “General” Focus Population, but it’s not intuitive and is probably not widely used.

3

Thanks, Hannah. I agree that “boosting” results based on targets is easy to understand, and it seems like a relatively light lift for data managers, too. We need to look into this more deeply in Connect 211.

…sometimes it’s hard to find the services that aren’t targeted.

Could you explain that a little further? I’m not sure I fully understand.

Also, related to these two thoughts:

I am not sure the Requirement option is workable because there are too many and/or variables.

I wish filters did better… [at] actively removing resources you are not eligible for.

Are there any requirements you think would be a no-brainer for hard filters without adding too much burden for data managers?

I’m starting to wonder how feasible requirements really are.

4

Let’s say you do a search for Rent Assistance. Two results are for veterans, one is for college students, one is for someone with cancer, for one you have to be Native American, and three are for everyone. If someone is not a veteran, a college student, with cancer, or a Native American I would like to narrow it down to the three that they should be aware of. My workaround is adding a filter called “General.”

5

Here at Wyoming 211 we have used intended participants field as the filter. Therefore if we have a target population that we want this narrowed down to we have used that field to narrow down who the referral would go to. That has been the biggest help.

6

Thanks, Jane! It sounds like you are using “Intended Participants” in a similar way to “Target Populations” to filter results down instead of boosting them. That’s helpful info.

@HannahN In your use case, are things improved if you break out a separate category called “Military Status” that houses “Veteran”, “Active Military”, etc.?

I’m wondering if AND/OR logic can be simplified intuitively by breaking big groups into smaller groups. Within groups, we assume OR logic, and between multiple groups, we assume AND logic.

Does that kind of make sense, or am I just lost in my own head on this one?

Here’s an alternate but related thought: what if a data manager audited their application of facets and gave each one a rating:

  1. Low - This facet is inconsistently applied and may be useful for targeting
  2. Medium - This facet is consistently applied and is definitely useful for targeting.
  3. High - This facet is rigorously applied and is useful for excluding non-relevant resources.

Based on those classifications, both internal and external (power users) could make an informed decision about whether they want a given facet to:

  1. Boost results
  2. Filter results

I think AI could be used to help audit and classify specific facets these days, especially if there were a relatively small, fixed set used across many data sets. Is that kind of audit and classification useful? What’s a better way to manage facets?

7

I have seen filters done so badly that I have generally steered clear of them. We have one specialized program that uses a filter on our website (Military Connected).

What I’ve seen often within databases are filters for Adults, Older Adults, Children, Women, Men, etc. that are available and (sort of) used on every service record. This has always left me with more questions than answers about how this improves searching. Generally, I’ve been told that the filters aren’t used by staff or helpseekers, so I’m not sure what the benefit is to maintaining them.

I think WA211 has the code cracked here. The filters aren’t generalized to the entire database; they are dynamic based on what someone is searching for.

I agree completely that facets should be added only when they are significant differentiators. If I could customize how my software works, I would want certain facets only available when specific taxonomy terms are used. If I add ‘Homeless Shelters’ to a record, the facets available might be Women, Men, Couples, Parent(s) with Children, etc. But I don’t need those same options for any other service in the database. Right now, I can do something like that with Target Terms, or I can create policies that when we list this type of service, we check the boxes for these facets, and when we list other services we don’t…and I’m not sure we have the bandwidth to do that well.

8

I’m really intrigued by this idea, @lpaulsen. Thanks for sharing!

If I’m reading the room correctly, consistently maintaining target terms and requirements is resource-intensive for data management teams, so it’s hard to do well.

Hannah’s feedback and Lindsey’s idea make me wonder if we should ask a more focused question: what’s the smallest set of facets that would make the biggest difference in helping the public and third-party navigators narrow down results?

@HannahN @lpaulsen Is that a worthwhile question, or is there a better one to ask?

@gavi Would love your input here based on our recent conversations.

9

I’d be curious to explore a combination of sort and filter with AND/OR logic. Similar to Hannah, we use and often recommend including an “Open to all” option to easily clear out any resources with restrictions, but because it works in the exact same way as actual special populations, it’s difficult for users to narrow lists without selecting and deselecting filter options and re-reviewing search results.

The behavior I’d love to see (though I’d have to think further on exact technical implementation) is that any actual special population is in conflict with another unless multiple boxes are checked, in which case the user is prompted whether the additional filter(s) should be used to expand results (OR) or further narrow (AND). They should also always have the option to include resources without any filters at all (or tagged some variant of “Open to all”) mixed in with their targeted results.

The sort behavior would also likely need to allow users to toggle between “Most Relevant” (which would first display the resources matching the criteria of the filters, followed by those open to all) and the more straightforward “Distance” (which still filters results but doesn’t weigh any of them differently based on what’s specific to certain populations vs what’s open to all).

10

Thanks, Sasha. From a user experience standpoint, I try to avoid complex interfaces that require users to implement AND/OR logic, but it may be unavoidable.