Related to T153949: Update RC page results without reloading the page (AJAX) when filters are changed

Namespaces and tags are more complex pieces of information, but I was wondering for the date range and pagination if it won't be simpler to convert them into drop-downs. It was not in the initial scope, but since we are touching these elements we can reduce the number of links exposed to the user as we are working on this:

Yeah that looks like a good idea. It might be easier to do that if we're gonna touch it anyway.

To whomever ends up taking this task: just do whichever is easiest first. If it's easier to rig up AJAX to the existing links, do that and do the dropdowns some other time, but if it's easier to replace them with dropdowns and integrate those with the AJAX code, then do that.

Let's pause to consider the UX here...

Before we go too far down the road of making the old stuff work more like the new stuff, let's pause for a second and consider the user experience. The plan was that all the stuff in the old-style filter box would work in the old-style way. With this approach, people can, arguably, understand intuitively that we changed some features and left other features alone. (And if the old stuff doesn't work correctly, then it's not on us. Or not as much.)

It's a kludgy system, but here's the thing: there are significant ways beyond the look and feel that we're not integrating the old stuff. Off the top of my head: 1) settings for old-style filters don't show up as tags in the Active Filters display area. 2) we're not evaluating the old filters— Namespace etc.—for conflicts, as we are all the new-style filters. I'm sure there are more. So if we make the old stuff //a little more// like the new stuff but don't really integrate it, aren't we making the disconnect more confusing?

Imagine the user under the Ajax scenario: he opens the Dropdown Panel, makes settings, sees them reflected in the Display Area and gets his results. He closes the panel and starts adding Namespaces and Tags. Maybe the page results update, maybe they don't (because his settings didn't change the results). He doesn't see his settings reflected in the Display Area. Won't he wonder, "Hey, where are my namespace and tag settings? Are these filters broken?"

The alternative is that he opens the new filter panel, makes all his new-style settings, sees the settings reflected in the Active Filter Display Area and gets results. Then he closes the panel and, in a separate step, goes through and adds Tags and Namespace settings, and presses "Show." The page reloads. I think he understands that that latter was totally separate.

Clearly, we need to make it so that the "Show" button doesn't erase the user's settings, as it was doing. But maybe that's all we should do? @Pginer-WMF, am I worrying about nothing?

===And a question about old-style filters

How do these filters work anyway? Specifically:

• Do Namespace and Tag filters add more AND conditions, as everything else does? I assume that, unlike the old "Exclude/OR" filters, these are AND and Include?
• Are Namespace and Tag filters in separate "groups", from a Boolean viewpoint? Again, I assume so.

(If that's true, then just to point out, I'm sure there will be additional Conflict states. E.g., I imagine there are namespaces ORES doesn't score?)

In T157594#3031849, @jmatazzoni wrote:

• Are Namespace and Tag filters in separate "groups", from a Boolean viewpoint? Again, I assume so.

Yes, they are AND at a group level (like our groups), and the groups are what you said.

Within the namespace group, there are five possibilities (due to the drop-down and two checkboxes, 'Invert selection' and 'Associated namespace'.

1. Normal namespace, like 'Portal', both unchecked. Edit/log entry must be in/regarding 'Portal' namespace.
2. Normal namespace, like 'Portal', only 'Invert' checked. Edit/log entry must *not* be in/regarding 'Portal' namespace.
3. Normal namespace like 'Portal', only 'Associated' checked. Edit/log entry must be in/regarding 'Portal' or 'Portal talk' namespace (associated namespace of 'Portal' is 'Portal talk', associated namespace of 'Portal talk' is 'Portal', etc.)
4. Normal namespace like 'Portal', both 'Invert' and 'Associated namespace' checked. Edit/log entry must *not* be in/regarding 'Portal' namespace or 'Portal talk'
5. Namespace 'all'. Full coverage/no effect.

Tag filters are more straightforward. It just must be a tag, e.g. 'huggle', with that exact name.

In T157594#3031849, @jmatazzoni wrote:

With this approach, people can, arguably, understand intuitively that we changed some features and left other features alone. (And if the old stuff doesn't work correctly, then it's not on us. Or not as much.)

In my opinion, the user will see it as one unified form, and expect it to act consistently. Although some users might recognize different parts look different, they will probably expect it to act consistently anyway (and ask that we make it look more consistent).

In T157594#3031849, @jmatazzoni wrote:

Let's pause to consider the UX here...

Before we go too far down the road of making the old stuff work more like the new stuff, let's pause for a second and consider the user experience. The plan was that all the stuff in the old-style filter box would work in the old-style way. With this approach, people can, arguably, understand intuitively that we changed some features and left other features alone. (And if the old stuff doesn't work correctly, then it's not on us. Or not as much.)

The "old stuff" is a bit of an arbitrary division. From the old filters we are integrating some in the new system (e.g., "show bots") but not others (e.g., "namespaces").
Our ultimate goal should be to integrate all of them into the new system. That would provide a single clear entry point for filtering that works consistently.

In the old filters, there is also an inconsistency on how filters are applied, while link-based filters are applied immediately, namespace and tags require the user to click the "show" button. The inconsistency already exists so I considered ok to live with it for a while (since the new filters are exposed as a beta feature), but that does not mean that is a good thing. I think that in order to move out of beta, we need to provide a unified system that works consistently.

There are challenges in integrating more complex filters such as "tags" or "namespaces" (related to the number of options and the need to reverse them) but I think those are solvable. I don't see the conflicts between those filters to be a blocker since those conflicts are going to happen anyway as the users apply them, regardless of them being in one or two groups. Other options from the "old filters" such as pagination and date range that clutter the UI with many links, can be easily simplified (as proposed in T157594#3026591).

Pau, I'm sorry if I didn't make my question clear. The purpose of this ticket is to make the old filters work more like the new ones in the sense that the page will dynamically update when people choose a namespace, etc. While it seems, or seemed to me, like dynamic is better in general, 'm saying a) we have not really thought this through and b) it might be that we don't want to do it. That yes, the ultimate goal is to integrate the features, but in the absence of true integration (which we will not have initially), maybe keeping them separate is better.

In T157594#3033440, @jmatazzoni wrote:

Pau, I'm sorry if I didn't make my question clear. The purpose of this ticket is to make the old filters work more like the new ones in the sense that the page will dynamically update when people choose a namespace, etc. While it seems, or seemed to me, like dynamic is better in general, 'm saying a) we have not really thought this through and b) it might be that we don't want to do it. That yes, the ultimate goal is to integrate the features, but in the absence of true integration (which we will not have initially), maybe keeping them separate is better.

Ok, I think we are in the same page: Ideally we want to integrate those filters into a unified solution, but for now we can live with how they are right now (especially if it is not a trivial change, there are cases to figure out, etc.).

I'm going to wait and look at this on beta, then decide what to do. The minimum is to fix the part where it erases the filter settings, which is just wrong.

Change 340270 had a related patch set uploaded (by Mooeypoo; owner: Mooeypoo):
[wip] RCFilters UI: Ajaxify everything

https://gerrit.wikimedia.org/r/340270

I'm sure there are a lot of things we could do to fix the interface for the old parts of the page. But I don't want to do them for the first release. Let's please leave the interface as it is (i.e., don't change the time options to a dropdown), and just make the changes necessary so that this works with the new system and works dynamically as it does insofar as possible.

Change 340270 merged by Mooeypoo:
[mediawiki/core] RCFilters UI: Ajaxify everything

https://gerrit.wikimedia.org/r/340270

@Mooeypoo

(1) Cannot discard previously selected 'Invert selection' and 'Associated namespace' options. Once selected, they become sticky. It happens only if "New filters for edit review" beta feature is selected.

Steps to reproduce:

1. Enable "New filters for edit review", go to RC page - the default filters selection result is displayed.
2. On RC page select 'Portal' namespace (any namesapce option should be fine too). Click 'Show'. There is a Console error complaining about ajax stuff:

GET https://en.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hideliu=0&…s=0&hidenewpages=0&hidecategorization=1&hidelog=0&namespace=100&tagfilter= 404 ()

ajax
mw.rcfilters.Controller.fetchChangesList
mw.rcfilters.Controller.updateChangesList
mw.rcfilters.ui.FormWrapperWidget.onFormSubmit
dispatch
elemData.handle

3. Then, with 'Portal' namespace selected, check 'Invert selection' or 'Associated namespace' (or both) Click 'Show'.
4. Un-select 'Invert selection' and click 'Show' - when the page reloads, 'Invert selection' will be displayed as selected.

@Mooeypoo Another, more minor issue.

(2) The Collapse/Expand link ("mw-changeslist-legend mw-collapsible") disappears if any change is made for the options on RC page - e.g. changing the number of days to be displayed, adding/removing filters.

(3) 'Invert selection' and 'Associated namespace' options can be selected with 'Namespace' - all.
Without 'New filters for edit review' beta feature enabled, the selection of 'Invert selection' and 'Associated namespace' with 'Namespace' - all is not possible: the checkboxes cannot be clicked.
Note: when only default filters are displayed, the checkboxes are not selectable. But if some options are changed, the checkboxes can be selected. If the default filters are restored while the checkboxes were selected, the checks become greyed out. This is the old behavior which doesn't need to be corrected right away:

Change 342930 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Fire 'wikipedia.content' hook when updating the fieldset

https://gerrit.wikimedia.org/r/342930

Change 342930 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Update fieldset as in load

https://gerrit.wikimedia.org/r/342930

Checked on plwiki and ptwiki. No issues found.

QA recommendation: Resolve

Sorry, but I don't understand how the page behaves differently now from before. What changed?

@Mooeypoo, can you please comment on my question above? Thanks.

The page used to reload completely when you interacted with non-implemented things like limit and from/to dates and namespaces, etc (anything inside the fieldset under the full RCFilters dropdown) -- the new fix makes sure that these operations are done consistently (they update the URL the same way that the other filters do) and without reloading the page.