Skip to content

Filters phase 1: predefined filters for post list and UI for choosing one (set as default for that community + category) #755

@cellio

Description

@cellio

Filters proposal on meta: https://meta.codidact.com/posts/285370

In the first phase, we want to define some built-in filters, implement them on top of search (expanding the search language if necessary), and add some UI for choosing a filter for a category post list. The choice should be sticky, and "no filter" should be an option (to clear the choice). I think this bit of UI should be a widget in the right column; in future phases it will need more vertical space than just a selector, so don't put it at the top of the posts list.

The filter framework should not care what kind of post list it's looking at; assume this could be used later for profile pages or search results. But the UI now is only for category post lists.

Remember that a post list can contain post types other than questions; filters will need to specify post type. Ideally, the UI would gray out or not offer filters that don't apply -- for example, "open questions" would not be offered on the Meta blog, which uses the article post type. This might mean that a filter has a "prerequisite" (post type) and a "body" (the actual definition), so that the code can easily check which filters are available.

These are my notes on what I think is a sound approach, but people with deeper knowledge of the code can obviously override.

What initial filters should we offer? Not necessarily a complete list, but some ideas:

  • Open questions: post_type:q status:open (we'll need to add something like a status option)
  • Unanswered questions: post_type:q status:open answers:0
  • Exclude low scores (needs a better name): post_type:top-level score:0.4 (do we have the concept of top-level post available? or do we need to enumerate them?)

A nice bonus would be a filter for "my tags" that shows only your favorite tags, but I don't know how to express that in search or what it would take to do it. We'll need it; I don't know if it's part of the first phase.

Metadata

Metadata

Assignees

Labels

area: backendChanges to server-side codecomplexity: unassessedNeeds further developer investigation before complexity/feasibility can be determined.priority: medium

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions