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

Originally published at forum.openreferral.orgJoin the conversation in the forum

One of the most popular features on sites like search.wa211.org is the sidebar filters (see an example search for Utility Assistance in Spokane County).

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.