Nothing Special   »   [go: up one dir, main page]

Page MenuHomePhabricator

Provide UI for paging through Watchlist and Recent Changes results in the JS-enhanced UI
Open, Needs TriagePublic

Assigned To
None
Authored By
Pginer-WMF
Apr 20 2017, 10:07 AM
Referenced Files
F8460991: Screen Shot 2017-06-14 at 4.05.52 PM.png
Jun 14 2017, 11:06 PM
F8443744: RC-next-overview.png
Jun 12 2017, 9:38 AM
F8443746: RC-next-pagination-reverse.png
Jun 12 2017, 9:38 AM
F8443676: RC-next-overview.png
Jun 12 2017, 9:16 AM
F8443678: RC-advanced-filters-sticky-bar.png
Jun 12 2017, 9:16 AM
F8413519: RC-advanced-filters-sticky-bar.png
Jun 8 2017, 2:01 PM
F7663139: RC-advanced-filters-sticky-bar.png
Apr 20 2017, 10:21 AM
F7663016: RC-advanced-filters-pagination.png
Apr 20 2017, 10:07 AM
Tokens
"Love" token, awarded by Prototyperspective.

Description

Pagination controls enable users to move forward and back though the Watchlist and Recent Changes results a in order to move backwards in time. These controls enable users to "walk" back through results to survey changes in a continuous stream, or to jump ahead or back to particular locations in the results queue.

The 'Newer X' and 'Older X' buttons

  • "Newer X" and "Older X" buttons are provided to navigate through the Recent Changes queue one page at a time.
  • When users click these buttons, they will move either forward or backwards through the results queue by the number of results currently selected in the "Number of Results Selector" (T162786)
  • The labels of the Newer and Older buttons will reflect the the number of results currently selected in the "Number of Results Selector" (T162786). E.g., if the Selector is set to 100, the Older button label will read: Older 100 >
  • As the user pages backwards or forwards in the queue, the user remains at page top and the Search tools remain visible and available, showing all the current search terms.
  • When the user first loads a page of new results, the "Newer" button is grayed out. It changes back to the black, active state as soon as the system determines that the first new result matching the current query has entered the queue. (This test needs to be made for the "View Newest Changes" function anyway T163426. Thus these tools will both update at the same time.)
    • If the user presses Newer at the moment the button changes color, the one available result will display (meaning that this is really the "up to 100" button.)
  • The Recent Changes queue drops older changes when they are > 30 x 24-hours old. If the user loads the very last, oldest available page of results, or loads that page by going into Oldest First mode (see below), the "Older" button grays to show that the limit has been reached.
    • If a user, having loaded that very last page, a) sits on the page for a time and then b) presses "Newer," it's likely that the temporally continuous results the user might have expected will no longer be available (because they are now > than 30 x 24-hours old). In this eventuality, the system will simply load a page full of X results that are as close as it can get to what the user requested (i.e., a page of results that are discontinuous from the former "last" page).
  • When the user scrolls down the page, the Newer/Older buttons become part of the Sticky Control Panel (T167932), which means we don't need to reproduce them at the bottom of the page.

'Live update' mode

  • If a user with Live Update ON presses the "Older x >" button to go back in the queue, the following happens: 1) Live Update turns off, 2) the next older page of x results loads.
  • If a user with it Live Update OFF uses the "Older x >" button to page back in the queue, and then turns Live Update ON, the following happens: 1) the page reloads with the user at the top of the queue (and the newest x results showing) and 2) the Live Updates begin rolling onto the top of the page. In other words, we do not start loading new results on top of an older page.
  • If a user with it Live Update OFF uses the sticky pagination controls (T167932) to scroll down the main page of results and then turns Live Update ON, 1) the page reloads with the user at the top of the queue and 2) the Live Updates begin rolling onto the top of the page.

'Oldest first' mode

When results are in "Oldest first" mode (T162786):

  • The "Newer X" and "Older X" pagination buttons continue to do what their names suggest. But now, as each newer or older page of results loads, the order of the page is reversed, with the oldest results at the top.
  • If a user in Oldest First mode gets to the "last" page in the queue (i.e., the one with the newest results), the "Newer" button is grayed out—and it stays grayed out (and we don't show the "View Newest Changes" link, either, as per T163426). I.e., the Newer x > button does not become active again as new results become available.

View Newest Changes

  • If the user clicks View Newest Changes when the number of new changes is greater than the currently set number of changes displayed per page, the "Previously viewed changes" marker (T172213) WILL be displayed on the spillover pages. I.e., if the user pages back through older changes to the point where the previously viewed changes marker should be, the marker is displayed there.
  • If the user has used the "Older x >" button to load a previous screenful of results, The View Newest Changes link does not appear on that page. I.e., the View Newest Changes link appears only when the user is on the top (most recent) page of results.

Screen Shot 2017-06-14 at 4.05.52 PM.png (761×978 px, 248 KB)

See also

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
jmatazzoni renamed this task from Provide navigation controls to move though the results of the new filters for edit review to Provide UI for paging through RC page results.Jun 8 2017, 12:13 AM
jmatazzoni renamed this task from Provide UI for paging through RC page results to Provide UI for paging through Recent Changes results.
jmatazzoni assigned this task to Pginer-WMF.
jmatazzoni updated the task description. (Show Details)

@Pginer-WMF, I think we should put pagination navigation at the bottom of pages as well, since getting to the bottom and then wanting to go to the next page is a common pattern. Roan says we can't have fancy controls, like the Google bottom navigation, that let you skip 4,5,6 etc. pages ahead or back. So, we're limited to one page at at time plus "oldest" and "newest" links. Do you want to use the nav we already have, e.g, at the bottom of History page? Or would you like to repeat the Older and Newer buttons and add to them Oldest and Newest links... What do you think?

@jmatazzoni my initial thoughts were about making the header to become sticky presenting some of the controls easier to reach at hand. This was part of the description before being edited:

The mockup below illustrate how navigation controls can be provided as part of a sticky header along other entry points to quickly access filtering functionality:

  • The search button provides a quick access to jump into the filters on top
  • Access to quick links can be provided to facilitate the switching between review activities.

RC-advanced-filters-sticky-bar.png (768×1 px, 334 KB)

Note that some of the controls (such as the "advanced settings") are outdated, but this approach allows users to move around and jump between saved filters not only at the beginning/end of the list. With the current controls, it could be more close to this:

RC-advanced-filters-sticky-bar.png (768×1 px, 333 KB)

@Pginer-WMF, two things in answer to why I specified that the search tools just stay at top: 1) it's useful for users to be able to see what their filter selections were as they page back, and 2) Roan says that his plan for implementing pagination is that as you press the Older and Newer buttons, it's really just another search. So the Results area updates, just as though you'd changed your search parameters. Given this, both technically and from a UX perspective, the simplest thing is just to leave all the tools at top, I think.

What I didn't think about is what happens if you change your parameters. E.g., if you just change blue highlighting to green, do you return to the top of the queue? I think you do...

@jmatazzoni I updated the description based on our latest conversation. I included a video to illustrate the idea of the sticky header.

There is one aspect that is not completely clear to me form the description:

The "Newer X" and "Older X" pagination buttons continue to do what their names suggest. However, this means the perceived "direction" of navigation they facilitate is reversed. I.e., "Newer" takes users "back" away from the top RC Page and toward what's now the bottom of the queue (where results are newest), while the "Older" takes users toward the top of the queue and the first RC Page (where results are oldest).

I'd expect the newer and older buttons to keep the same functionality but be ordered in reverse order based on the sorting direction. That is, moving forward (i.e., to the right*) means to advance through the most recent changes (to the oldest) or advance through the backlog (to the most recent) depending on the sorting order. I captured this in the mockups below:

Newest fist (review the most recent changes)Oldest first (review a backlog)
RC-next-overview.png (768×1 px, 245 KB)
RC-next-pagination-reverse.png (768×1 px, 245 KB)

*On left-to-right languages the order of the buttons will be the reverse for internationalisation reasons, but that is a different story.

jmatazzoni updated the task description. (Show Details)

Many gadgets hook into RC and watchlists, and these cannot handle them changing dynamically. Especially for watchlists, that might become an issue when this reaches the phase where such changes leave Beta mode.

We should have mw.hooks, providing the new content of a page, so that JS tools can hook into those instead of document.ready, as we have wikipage.content, wikipage.diff, wikipage.editform, mmv, map hooks etc.

Many gadgets hook into RC and watchlists, and these cannot handle them changing dynamically. Especially for watchlists, that might become an issue when this reaches the phase where such changes leave Beta mode.

That's absolutely right. We know about "Navigation popups" (tracked in T172957) but there's probably many others. We hoped the beta period would bring some of them to light but it's been pretty quiet on that front.

Please let us know if you encounter any weirdness (visual or functional) on RC or WL with gadgets.

We should have mw.hooks, providing the new content of a page, so that JS tools can hook into those instead of document.ready, as we have wikipage.content, wikipage.diff, wikipage.editform, mmv, map hooks etc.

wikipage.content is fired once on load on the current pages and we fire it whenever there's new changes for any reason (filter update, live update, etc) with the beta feature. Gadgets can migrate to use it today to stay compatible with or without the beta feature.

@SBisson wikipage.content is however intended for content of wiki pages, not special pages.... I guess that could work, but... not really what the original intent of that hook was (You might be triggering other scripts that will now encounter content that they are not expecting).

This sounds like something that should be discussed by Front-end-Standards-Group or something.

kostajh subscribed.

If/when this gets done, let's make sure that the changes in T172031: Small language tweak in 'Changes to show' menu are incorporated.

jmatazzoni renamed this task from Provide UI for paging through Recent Changes results to Provide UI for paging through Watchlist and Recent Changes results.Nov 1 2018, 5:36 PM
jmatazzoni updated the task description. (Show Details)

I updated the title of this to include Watchlist, where pagination features are more useful and arguably even required.

Tgr renamed this task from Provide UI for paging through Watchlist and Recent Changes results to Provide UI for paging through Watchlist and Recent Changes results in the enhanced UI.Feb 21 2023, 5:32 AM
Nardog renamed this task from Provide UI for paging through Watchlist and Recent Changes results in the enhanced UI to Provide UI for paging through Watchlist and Recent Changes results in the JS-enhanced UI.Feb 21 2023, 2:07 PM

@SBisson wikipage.content is however intended for content of wiki pages, not special pages.... I guess that could work, but... not really what the original intent of that hook was (You might be triggering other scripts that will now encounter content that they are not expecting).

This sounds like something that should be discussed by Front-end-Standards-Group or something.

My team is looking at making some improvements to Recent Changes over the coming months, so I wanted to check if it still seems to be the case that the FESG should discuss this before any attempt is made to implement the feature described above?

@SBisson wikipage.content is however intended for content of wiki pages, not special pages.... I guess that could work, but... not really what the original intent of that hook was (You might be triggering other scripts that will now encounter content that they are not expecting).

This sounds like something that should be discussed by Front-end-Standards-Group or something.

My team is looking at making some improvements to Recent Changes over the coming months, so I wanted to check if it still seems to be the case that the FESG should discuss this before any attempt is made to implement the feature described above?

Per brief off-wiki conversation, this is probably not a blocker to the feature requested in this task.

We should be cautious about deployment and let folks know in advance so that gadgets/scripts can be updated.