New filters form old
Title:
New filters form old
Area:
Subscription filters
Summary:
You should be able to derive new filters via logical operations on your existing filters
Description:
You should be able to create a new filter by preforming operations on another filter or filters.
For example, if you have the following subscription filters:
Comics
Close
Friends
You could:
Create a filter of every post -not- in any of the above filters.
Create a filter of Friends + Close without duplication.
Concat (not)(Comics+Close+Friends)+Friends; the result is the new Friends.
Create a filter of every post of the users listed among Comics that doesn't appear in that filter
You'd want to separate "invert inclusion list", "invert tags", and "invert ratings" -- as they have different purposes.
Operations:
Add two (or more) filters.
Invert (inclusion list +/or tags exclusions +/or tag inclusions +/or ratings)
While you're at it, it would be useful to be able to bulk modify filters -- if you could specify "exclude all tags like meme*" from these users, it would save a lot of effort even if you had to manually check it.
Actually, another thing that would be useful is letting you do more than just (all except x,y,x) and (only containing (x,y,z) -- just specifying both would help a lot (but if you wanted real concatination as I describe above, you'd need logical composition, which does get complicated).
This suggestion:
Should be implemented as-is.
13 (48.1%)
Should be implemented with changes. (please comment)
4 (14.8%)
Shouldn't be implemented.
0 (0.0%)
(I have no opinion)
8 (29.6%)
(Other: please comment)
2 (7.4%)

no subject
I'd like to see a more structured design process and prototype testing for both reading and posting filters.
no subject
no subject
The big question, really, is whether to impliment proper logical tag inclusion/exclusion (e.g. "posts from frank tagged with (apples (but not grapes), peaches, or cherries, but not meme posts) or (meme and star trek)") rather than the current optional not + sequence of ors.
The reason this is significant is that filter/inversion, etc requires these operators if it's to get at all involved (unless one implements virtual filters that are displayed -only- as combinations of other filters -- but I'm inclined to think that those are a bad idea unless they're implemented exactly this way -- by producing a more complicated logical expression from the source filters). If you have a filter containing all posts from joe with cats in them then inverting it is easy -- all posts from joe without cats in them. But if you add that filter to one from joe without chickens, you end up with "posts from joe (with cats) or (without chickens)", which the current engine doesn't support. And if you try to invert that (getting all posts from joe not matched), you get "posts from joe (without cats) and (with chickens). Adding in more filters (on joe) will even further complicate things.
My last point (bulk tag editing within a filter) is comparatively simple.
no subject
no subject
My thought is that you wouldn't be creating virtual filters (as useful as that -could- be for longterm maintenence) that are displayed as combinations of other filters. Instead, you do some set of combinatoric operations on filters, and you get a new filter that says exactly who's in it and what tags/ratings it's using for them (based on how you composed the original filters). This is really useful for producing superset filters from several smaller sets -- as well as for the occasional operation of making a filter containing all the things on your watchlist that you've forgotten to put into a filter.
no subject