Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on Proposal: filters for post lists

Parent

Proposal: filters for post lists

+10
−0

Several discussions have touched on the idea of being able to filter the contents of the post list. Whether your goal is to find unanswered questions, hide closed questions, hide ignored tags, or build a more complex filter, this is something we've wanted to be able to support for a while. A design mockup earlier this year showed one possible approach.

I have some ideas for how we could approach this feature and I'd like to hear what y'all think. Please note that this is a proposal; where I use language like "you can", I mean that's how I imagine this working, not that I'm promising that specific behavior. (I'm not in a position to make promises like that.)

Key idea #1: anything you can define in a filter, you can also search for, but not necessarily the other way around. Our search interface is pretty expressive (there's always more to do), and it would be silly to write a second search-like thing. Filters will be implemented on top of search. If we need to expand the search language, we will.

That said, there are searches you can do that don't make sense as filters for the post list -- for example, you can search specifically for answers. Filters are a subset of search.

Key idea #2: filters can be defined, named, and reused, and we'll provide some built-in ones. "Unanswered questions" seems like one that would be popular, for example. And if you want to refine the built-in "unanswered questions" filter (for example), you can.

You'll have access to all your defined filters in all categories and on all communities -- so if you want to have that meta "exclude status-completed" filter, you only have to write it once. When you choose a filter for a category, it'll stay that way until you choose another (or clear it).

Key idea #3: filters are based on properties of the posts, not properties of the users (at least for now). This is both a performance consideration and a complexity consideration. "Questions asked by new users" or "questions answered by people whose answers I tend to upvote" aren't really workable, I don't think. After we have something built and people are using it, if this is posing a problem we can revisit it then. Sure, it's all SQL under the hood, but we don't want to jump straight there.

Note that "my favorite tags" or "my ignored tags" would be ok -- that's just a shorthand for "posts with (or without) these tags". Those are properties of the posts.

Key idea #4: start simple, then expand. Ultimately, we might find people wanting to write filters with complex boolean expressions based on scores, ages of posts, numbers of answers, scores of answers, tags, "questions I haven't answered", and more. We don't know everything that will be needed or requested. By basing it on search from the beginning, I think we avoid making early decisions that would preclude future expansion. I'd rather refine and if necessary rework the UI later than try to build the giant union of all things that might be needed at the beginning. We're going to learn as we go, together, based on your feedback; let's take an iterative approach.

Enough talk; show me a picture.

I see filters as going in the right column (on the desktop site; mobile would be behind a button most likely). There would be a "filter" widget that, by default, just shows the selector, like this:

filter selector, current value "no filter selected"

When you select a filter, the widget would expand to show its definition. This would include all the parts that can be customized, even if the current filter doesn't set them, so that you'll have access to them. For example:

"Unanswered": question status open, answers 0, spaces for score/age/when active/tags, "save as" button

If you edit the filter, the UI would somehow signal that you have unsaved changes and enable the "save as" button. I haven't given enough thought to the UI around "save" (edit) versus "save as" (clone and modify), and maybe a "save as" button isn't the right way to do this, but the goal would be to support both editing your own existing filters and creating new filters.

I don't know if this is the right list of filter properties. It's a first draft.

A post list is not necessarily questions; it could be articles, articles and questions, or other post types not yet defined. We'll need to offer only the filters that make sense for the current post list. I used questions in my examples here because that's what's most common.


What feedback do y'all have? What did I not get quite right, what did I miss, and what do we need to be thinking about that we aren't yet?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Public (shared) filters? (2 comments)
Post
+2
−0

Key idea #2: filters can be defined, named, and reused, and we'll provide some built-in ones. "Unanswered questions" seems like one that would be popular, for example. And if you want to refine the built-in "unanswered questions" filter (for example), you can.

You'll have access to all your defined filters in all categories and on all communities -- so if you want to have that meta "exclude status-completed" filter, you only have to write it once. When you choose a filter for a category, it'll stay that way until you choose another (or clear it).

(my boldface changes above)

I'm not sure how that would really work out in practice. There are some cases, like your example of Meta categories' status-* tags, where it would probably work out very nicely, but also what seems like a large number of cases where it could lead to confusion.

Specifically, what I have in mind here is filter selection interaction with different (or the same) tag sets.

As a slightly contrived, entirely hypothetical example, not matching any community currently on Codidact so as to try to avoid stepping on anyone's toes. Imagine that there were two Codidact communities that do not currently exist, namely Aviation and Rail Transportation. Both of those have a tag named atc. However, on the Aviation community, atc means Air Traffic Control, and on the Rail Transportation community, atc means Automatic Train Control.

If I set up a filter such that it lets me see only questions tagged atc and use it on each of those respective communities, what do I see on each? What's reasonable to expect to see? (I'm not sure I have any good answer to that latter, but consider that to the typical user, tags are their names with some attached properties allowing the selection of a subset of posts; the typical user won't be considering tag sets when setting up a filter.)

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Need idea of "available here"? (3 comments)
Need idea of "available here"?
Monica Cellio‭ wrote almost 3 years ago

That's a good point. Not all filters would work in all contexts, so I guess that list you can choose from needs to gray out the ones with conditions that don't apply (for example, anything involving questions/answers on the Meta blog or Code Golf sandbox). For the case of the same tag on different communities (with different meanings), I think the filter would use the tag and if you don't care about that tag on that community, you won't use that filter. I don't think we want to tie filters to the tag set because then you'd never be able to write an "all metas" filter.

Canina‭ wrote almost 3 years ago

Monica Cellio‭ Not being able to set up a filter at all because you're in the wrong category for the particular selection you want to make for the filter sounds like a recipe for confusion, especially if coupled with filters, once created, being accessible across all of Codidact. ("Why in the world doesn't it let me create it here, but does let me use it when I've created it elsewhere?") Sure, it might be reasonable for us more technically inclined canines and for people who are more familiar with the inner workings of the software, but like with tag sets, the vast majority of users (hopefully) won't be in that category.

Again, I don't really have any answer here, but I think it's something that needs to be considered in design so that whatever ends up being decided as the "correct" behavior is reasonable from an end-user perspective.

Monica Cellio‭ wrote almost 3 years ago

Canina‭ another answer suggests being able to choose, when creating/editing a filter, whether it's local or global. This seems a good approach to me, especially if we couple it with some sort of preconditions so a question-based filter won't be selectable on the blog, for example. We'll need to work out how to specify and communicate about this to minimize confusion.