Page MenuHomePhabricator

Build all front-end elements for the new Recent Changes (RC) Page user interface
Closed, ResolvedPublic

Description

Implement the front-end elements of the new RC Page design described in T142785. (View current prototype.) This encompasses the following elements, whose behaviors are described in their separate tasks:

  • The Active Filter Display Area T149391
  • The Filter Search Bar T149435
  • The Dropdown Filter Panel T149452
  • The Highlight Tools and display of highlighting in the Edit Results List T149467
  • Help Texts T146669
  • Link to full documentation T147054
  • (Look here to find approved interface text for all elements: T149385)

(This tracking task for UI enhancements complements T144451, which tracks development of the RC page filters.)

Features Included in the First Release

The prototype includes new designs for a number of filtering groups and other functions that will NOT be in the first release of this product. Here is a breakdown of what is included in the first release

Features that will work as before (i.e., will NOT be in release 1)

  • Content Type (namespace)
  • Edit Tags
  • Content Categories
  • Show last 50 | 100 | 250 | 500 changes in last 1 | 3 | 7 | 14 | 30 days
  • Show new changes starting from...
  • Applying the filter system to similar pages (T145155)

Filtering groups to be included in the new interface

  • Contribution Quality filters (ORES)
  • User Intent filters(ORES)
  • User Registration filters
  • User Experience level filters
  • Edit Authorship filters
  • Automated Contributions filters
  • Review Status filters
  • Significance filters

This screenshot shows how the new filtering tools integrate with existing page tools that will continue to work exactly as they do currently.

Details

Related Objects

StatusAssignedTask
DuplicateQgil
ResolvedQgil
ResolvedQgil
OpenNone
ResolvedJohan
ResolvedTrizek-WMF
ResolvedDannyH
ResolvedDannyH
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
OpenPginer-WMF
ResolvedPginer-WMF
OpenPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedCatrope
ResolvedSBisson
ResolvedNone
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedCatrope
DuplicateNone
OpenNone
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedMooeypoo
ResolvedSBisson
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedSBisson
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedSBisson
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedMooeypoo
ResolvedPginer-WMF
Resolved jmatazzoni
Resolved jmatazzoni
OpenNone
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedMooeypoo
ResolvedMooeypoo
DeclinedNone
ResolvedMooeypoo
ResolvedMooeypoo
Resolved Mattflaschen-WMF
Resolved Mattflaschen-WMF
Resolved jmatazzoni
ResolvedNone
InvalidNone
ResolvedSBisson
ResolvedMooeypoo
Resolved jmatazzoni
ResolvedSBisson
ResolvedCatrope
Resolved jmatazzoni
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedTrizek-WMF
Resolved jmatazzoni
ResolvedCatrope
ResolvedCatrope
ResolvedSBisson
ResolvedHalfak
Resolved jmatazzoni
ResolvedTrizek-WMF
Resolved jmatazzoni
Resolved jmatazzoni
Resolved jmatazzoni
ResolvedTrizek-WMF
ResolvedPginer-WMF
Resolved jmatazzoni
ResolvedCatrope
ResolvedPginer-WMF
Resolved jmatazzoni

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Trizek-WMF updated the task description. (Show Details)Oct 28 2016, 6:00 PM
jmatazzoni added a subscriber: dchen.
Pginer-WMF updated the task description. (Show Details)Oct 31 2016, 12:03 PM
Mooeypoo added a comment.EditedNov 1 2016, 6:44 PM

Some of the old behavior is kept, but that may actually make things a bit weird in terms of behavior, so I could use @Pginer-WMF and @jmatazzoni's input here:

The filters that we're "not touching" from the current RC page, for example the "Namespace", the "Tags" and the pagination, all refresh the page. This doesn't really work for what we're doing with the filter drop-down that doesn't refresh the page, but rather pulls information from the API and refreshes only the list itself (not a hard-refresh of the entire page)

This means one of two options:

  1. (Probably prefered) We intercept the actions on those inputs, either by replacing them outright with OOUI elements or by (meh) grabbing their DOM elements and interrupting the currently setup event to refresh the actual page.
  2. We leave the behavior as-is, which means some filters refresh the page and some don't.

I think #1 is prefered, but it also means that if we put those filters outside so we "don't touch them" then it defies the point. We will have to do something there anyways, and being outside the main UI makes them more of a 'hack' than an actual system to listen to. Do we want to keep that? Do we want to replace them with OOUI widgets? Is the design the same?

We can also decide we are using JavaScript for some of the filters and not others (allowing others to refresh the page with the URL that defines the other filters?) but then we'd have to decide which ones follow which behavior. For example, I think it would make more sense to have the pagination completely through JavaScript, but perhaps the "Show new changes starting from..." could be non-JS in the MVP, and turned JS only later.

Ideally, the entire page will use filters that aren't refreshed, but if we take them out of the main filter list, we need to understand their behavior more so the architecture of the code works. Are they "rigid" (do we allow adding filters to that area of the search, like we will in the filter drop down? that's something the current behavior allows, but it also makes things more complicated for other extensions and coders to "pick" where to put filters)

So if all filters are inside the filter drop down, we know that the code just pulls in the data and arranges it in there. If we split them up, we need to make a determination about which filters appear where. There are, currently, other extensions that add filters to RecentChanges (like Wikidata and ORES, most notably) -- do we assume any extension adding filters should format them for the drop down, or do we have another area of the page - under "namespace" and "tags" where they can attach themselves to - and if they do, do they refresh the page or do we define an AJAX way to do it?

Let me know if any of these questions need clarification.

Just for organization sake, these are the three filters added in production by extensions:
'hideWikibase' (added by Wikidata), 'hideReviewed' (added by FlaggedRevs) and 'hidenondamaging' (added by ORES)

We are going to replace the ORES one, but we have to take into account that other extensions are adding filters through hooks. We don't have to use the same hook for the new JS feature, necessarily, since we will also probably have to redo the way these filters are defined if they appear in the filter (like definition of i18n messages and such) -- but we definitely need to be aware that (a) they exist and (b) we allow external extensions to add whatever filter they need to the list of filters.

We could leave a section outside the drop-down filter for those filters, and they could just refresh the page when selected (current behavior) but we need to figure out how to let extension developers define where they go.

For example - the code may live, right now, in ORES, but the feature is potentially ORES-independent (and will work eventually in the future for wikis that don't have ORES enabled, giving them the other base filters) -- that means that ORES will ahve to add its filters to the drop-down, and not the box outside the drop down. We can do that by defining some variable for filters noting whether they're inside or outside of the filter (similar to 'prioritized' in Notifications?)

Whichever we do we need to make a decision on what we support.

Change 319251 had a related patch set uploaded (by Mooeypoo):
[wip] RecentChanges Dynamic Filters

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

Thanks for your input @Mooeypoo, here are some considerations in this area that may be helpful:

  • New filters should be reflected in the URL. That allows vandal fighters to bookmark a filter targeting "damaging edits by unregistered users" or the Teahouse to craft a link pointing to a filtered Recent Changes showing "newcomers acting in good-faith making bad edits". I guess this can be captured as a hash parameter if we want to manipulate on the client side, which may make it possible to update the existing link-based filters to include the current state too. In any case, the idea is that the user should not lose the state when clicking the "refresh" button, clicking to an external link and going back, or clicking in another filter.
  • There are two kinds of existing filters. Pagination and date selection are based on links. If we consider replacing these by OOUI components it would be better to replace them with a dropdown as illustrated in the prototype. Namespace and Tag selection, are based on a form submission so we may include additional information as part of the form. For namespaces and tags, our long term goal is to integrate those in the new filtering entry point but we still have some aspects to figure out.
  • New filters are extensible The idea for the new filter system is to be scalable. Extensions should be able to indicate filters by providing the needed information about the group (name and possible help link) and the filters (name, description and info on incompatibilities between filters in the group). We probably need to define what to do with the extensions that provide filter extensions with the old format.

Are those helpful to inform the technical decisions? Is there any other detail that may help?

SBisson reassigned this task from MSchottlender-WMF to Mooeypoo.
SBisson added a subscriber: MSchottlender-WMF.

Change 320332 had a related patch set uploaded (by Mooeypoo):
[super-atomic-WIP] Adding filters to RecentChanges

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

Change 326064 had a related patch set uploaded (by Mooeypoo):
[wip] RCFilters UI: Read preferences as base state

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

Change 326208 had a related patch set uploaded (by Mooeypoo):
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

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

Change 320332 merged by jenkins-bot:
Adding new interface for review filters to RecentChanges

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

Change 319251 abandoned by Mooeypoo:
[wip] RecentChanges Dynamic Filters

Reason:
Unnecessary experiment, overriden in other commits.

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

Change 326064 merged by jenkins-bot:
RCFilters UI: Read default states of filters

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

Change 326208 merged by jenkins-bot:
RCFilters UI: Add 'remove' and 'restore defaults' to filter list

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

@Pginer-WMF - just a side not (feel free to ignore). Your initial design, that you mention in view current prototype, places the filter feature right above the results which makes easier (in my opinion) for users to see that the filters give them the results they want.

Of course, since we keep many RC old options, the RC page' look is different for now, but it still look cleaner when the filters are placed right above the result set. The 'Recent changes options' area is quite large and it's challenging to constantly switch the attention (and move eyes) from results to filters and vice versa.

The screenshot illustrates the case when the filters are above the result set.

@Pginer-WMF - just a side not (feel free to ignore). Your initial design, that you mention in view current prototype, places the filter feature right above the results which makes easier (in my opinion) for users to see that the filters give them the results they want.

Ideally we want to have a single filter area and not two of them. In the long term, the idea is to integrate more of the old filters into the new system, making it more lightweight and connected to the list of results. In the short term, removing the borders around the old filter area to make it look more unified would help.

Jan_Dittrich renamed this task from Build all front-end elements for the new RC Page user interface to Build all front-end elements for the new Recent Changes (RC) Page user interface .Feb 16 2017, 9:14 AM

We generally don't put these epic tracking tasks on the quarterly board. Moving it back to Triage.

Quiddity removed a subscriber: Quiddity.Mar 6 2017, 10:12 PM
Pginer-WMF updated the task description. (Show Details)Mar 8 2017, 12:00 PM

Just for organization sake, these are the three filters added in production by extensions:
'hideWikibase' (added by Wikidata), 'hideReviewed' (added by FlaggedRevs) and 'hidenondamaging' (added by ORES)

Have we solved the question concerning "hideReviewed"? I have a question about it here.

Jdforrester-WMF closed this task as Resolved.May 4 2017, 12:40 AM